Olá Pessoal Bom Dia, hoje decidi mudar de tópico, e em vez de ver python vamos tratar algum tópico de networking, especialmente tópicos do CCNA.
MultiLink PPP
Multilink PPP, RFC-1990, é uma tecnologia que permite agregar vários links físicos PPP em um único link lógico chamado de Multilink.
Dessa forma podemos obter um link com uma maior largura de banda, redundante, e com balanceameto de carga.
O MLPP vai fragmentar o pacote IP, encapsular cada fragmento com um cabeçalho PPP e vai enviar os fragmentos por todos os links simultaneamente (balanceamento de carga em camada 2), ditos fragmentos tem uma ordem de sequência, e o MLPP irá utilizar essa sequência para juntar os fragmentos e poder obter o pacote IP original.
Para poder configurar um MLPP, é preciso configurar tanto do lado do cliente como da operadora, então não podemos ter MLPP com links de operadoras diferentes.
Vejamos um exemplo:
Precisamos configurar um MLPP nos roteadores R1 e R2, sendo que temos três links seriais.
Configurando PPP nas interfaces seriais, a configuração é a mesma para os dois:
Rx(config)#int se0/0
Rx(config-if)#encapsulation ppp
Rx(config-if)#no shut
Rx(config)#int se0/1
Rx(config-if)#encapsulation ppp
Rx(config-if)#no shut
Rx(config)#int se0/3
Rx(config-if)#encapsulation ppp
Rx(config-if)#no shut
Criando a Interface Multilink 1, em ambos os roteadores:
R1(config-if)#int multilink 1
R1(config-if)#ip address 192.168.100.1 255.255.255.0
R1(config-if)#
R2(config-if)#int multilink 1
R2(config-if)#ip address 192.168.100.2 255.255.255.0
R2(config-if)#
Adicionando as interfaces Seriais, ao multilink group:
Rx(config-if)#int se0/0
Rx(config-if)#ppp multilink group 1
Rx(config-if)#int se0/1
Rx(config-if)#ppp multilink group 1
Rx(config-if)#int se0/3
Rx(config-if)#ppp multilink group 1
Verificando a interface Multilink em R1:
R1#sh ppp multilink
Multilink1, bundle name is R2
Endpoint discriminator is R2
Bundle up for 00:01:33, total bandwidth 4632, load 1/255
Receive buffer limit 36000 bytes, frag timeout 1000 ms
0/0 fragments/bytes in reassembly list
0 lost fragments, 1 reordered
0/0 discarded fragments/bytes, 0 lost received
0x6 received sequence, 0x6 sent sequence
Member links: 3 active, 0 inactive (max not set, min not set)
Se0/1, since 00:01:33
Se0/0, since 00:01:33
Se0/3, since 00:00:03
No inactive multilink interfaces
R1#
Interessante notar que o bundle name é o do roteador da outra ponta R2, também podemos ver que a largura da banda do Multilink é de 4632Kb, exatamente 3 vezes a largura da banda de cada link serial individual 1544Kb. O comando também nos mostra quais são os links ativos, e quais fazem parte do Multilink.
Verificando as rotas:
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
192.168.100.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.100.0/24 is directly connected, Multilink1
C 192.168.100.2/32 is directly connected, Multilink1
R1#
As rotas também estão OK, sendo que elas aparecem como diretamente conectadas pelo Multilink.
Agora vamos fazer um teste de fazer shutdown em uma interface serial do R2 e deixar um ping rodando no R1:
R2(config-if)#int se0/1
R2(config-if)#shut
R1#ping
Protocol [ip]:
Target IP address: 192.168.100.2
Repeat count [5]: 10000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.....................
.......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 96 percent (852/880), round-trip min/avg/max = 4/20/52 ms
R1#
No momento que eu fiz o shutdown na interface Se0/1 de R2, o ping falhou e demorou aprox uns 30segundos em voltar, o ping voltou exatamente quando a interface Se0/1 de R1 ficou em down.
Esse valor de 30segundos é devido ao “keepalive”, a cada 10segundos é enviado um pacote de keepalive, e é preciso de 3 keepalive não recebidos para dar a interface serial como down.
Quando Se0/1 de R2 caiu, R1 ficou esperando 3 keepalive via sua interface Se0/1, enquanto isso o Multilink ficou em um estado de transição, passados os 30segundos, R1 considera a interface Se0/1 dela como down e o Multilink coloca a interface como inactive, imediatamente o ping volta a funcionar.
R1#sh ppp multilink
Multilink1, bundle name is R2
Endpoint discriminator is R2
Bundle up for 00:18:16, total bandwidth 3088, load 1/255
Receive buffer limit 24000 bytes, frag timeout 1000 ms
0/0 fragments/bytes in reassembly list
1 lost fragments, 3916 reordered
1/60 discarded fragments/bytes, 0 lost received
0x2D74 received sequence, 0x2D7E sent sequence
Member links: 2 active, 1 inactive (max not set, min not set)
Se0/0, since 00:18:16
Se0/3, since 00:16:46
Se0/1 (inactive)
No inactive multilink interfaces
R1#
Vamos testar modificando o keepalive para um valor menor, uns 2 segundos, vamos fazer essa mudança unicamente na interface Se0/1, que é a interface que estamos testando, de ambos roteadores:
R1(config-if)#int se0/1
R1(config-if)#keepalive 2
R2(config-if)#int se0/1
R2(config-if)#keepalive 2
Testando novamente:
R2(config-if)#int se0/1
R2(config-if)#shut
R1(config-if)#do ping
Protocol [ip]:
Target IP address: 192.168.100.2
Repeat count [5]: 10000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!......!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!.
Success rate is 98 percent (630/637), round-trip min/avg/max = 4/20/44 ms
R1(config-if)#
Dessa vez o tempo que ficamos sem conectividade foi menor, aprox 6 segundos :)
Para ver como os pacotes estão sendo fragmentados podemos utilizar o comando debug:
R1#ping
Protocol [ip]:
Target IP address: 192.168.100.2
Repeat count [5]: 10
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 4/4/4 ms
R1#
R2#debug ppp multilink fragments
Multilink fragments debugging is on
R2#
*Mar 1 00:25:01.959: Se0/1 MLP: O frag 800000A2 size 166 encsize 4
*Mar 1 00:25:01.959: Se0/0 MLP: O frag 400000A3 size 169 encsize 4
*Mar 1 00:25:15.335: Se0/1 MLP: I frag 400000A5 size 60 encsize 4
*Mar 1 00:25:15.335: Se0/3 MLP: I frag 800000A4 size 58 encsize 4
*Mar 1 00:25:15.335: Se0/3 MLP: O frag 800000A4 size 58 encsize 4
*Mar 1 00:25:15.335: Se0/1 MLP: O frag 400000A5 size 60 encsize 4
*Mar 1 00:25:15.339: Se0/0 MLP: I frag 800000A6 size 58 encsize 4
*Mar 1 00:25:15.339: Se0/3 MLP: I frag 400000A7 size 60 encsize 4
*Mar 1 00:25:15.339: Se0/0 MLP: O frag 800000A6 size 58 encsize 4
*Mar 1 00:25:15.339: Se0/3 MLP: O frag 400000A7 size 60 encsize 4
*Mar 1 00:25:15.343: Se0/1 MLP: I frag 800000A8 size 58 encsize 4
Do resultado do debug, podemos ver que fragmentos estão chegando por todos os enlaces ppp individuais.
Caso seja necessário utilizar autenticação PAP ou CHAP, os comandos de autenticação deveram ser inseridos na interface Multilink.
Autenticando bidireccionalmente (2-way) com PAP:
R1(config)#username ROUTER2 password cisco
R1(config)#int Multilink 1
R1(config-if)#ppp authentication pap
R1(config-if)#ppp pap sent-username ROUTER1 password cisco
R1(config-if)#
R2(config)#username ROUTER1 password cisco
R2(config)#int Multilink 1
R2(config-if)#ppp authentication pap
R2(config-if)#ppp pap sent-username ROUTER2 password cisco
R2(config-if)#
R2(config-if)#
Bom por hoje é isso aí, espero que tenham gostado do post.
Abcs
Jose CCIE#35681
Obrigado pela explicação!!!
ResponderExcluir