Configuração de MultiLink PPP em Roteadores Cisco

Olá Pessoal,

O MultiLink PPP (MLPPP) é uma tecnologia padronizada na RFC 1990 e na RFC 2686 que permite agregar múltiplos links físicos de longa distância (do tipo PPP) através de uma única interface lógica equivalente à soma das capacidades dos links individuais. Trata-se, portanto, de um recurso interessante para obter um link lógico de alta velocidade e com maior disponibilidade a partir de múltiplos links de baixa velocidade. Uma vez que o MLPPP requer configuração coerente em ambas as pontas com a informação de quais interfaces físicas devem ser logicamente agrupadas, não é possível utilizar esse recurso para agregar múltiplos links físicos que sejam providos por diferentes operadoras.

O pré-requisito óbvio para configurar MLPPP é a existência dos links físicos PPP. A configuração do MLPPP é bastante simples, já que basta criar uma interface virtual do tipo multilink que receberá o endereço IP da rede ponto-a-ponto, além de ser referenciada como grupo lógico em cada uma das interfaces físicas. Tomando por base a topologia ilustrada na figura acima, as configurações necessárias estão destacadas abaixo em amarelo. As demais configurações consistem no estabelecimento dos links PPP, assunto abordado em outro artigo intitulado "Configuração de Link WAN PPP em Roteadores Cisco". 

R1(config)# username R2 password SENHA
R1(config)# interface s2/0
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shut
R1(config-if)# interface s2/1
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shut
R1(config-if)# interface multilink 1
R1(config-if)# ppp multilink
R1(config-if)# ip address 203.0.113.1 255.255.255.252

R2(config)# username R1 password SENHA
R2(config)# interface s2/0
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)# no shut
R2(config-if)# interface s2/1
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)# no shut
R2(config-if)# interface multilink 1
R2(config-if)# ppp multilink
R2(config-if)# ip address 203.0.113.2 255.255.255.252

Depois de realizadas as configurações do MLPPP, é possível observar que uma nova interface virtual do tipo multilink passa a compor a relação de interfaces do roteador. Também é possível observar na tabela de roteamento que a rede ponto-a-ponto entre os dois roteadores está diretamente conectada através da interface lógica multilink, ao invés das interfaces físicas do tipo serial.

R1# show ip route
Codes: (...)
Gateway of last resort is not set

     203.0.113.0/24 is variably subnetted, 2 subnets, 2 masks
C       203.0.113.2/32 is directly connected, Multilink1
C       203.0.113.0/30 is directly connected, Multilink1

O comando abaixo é específico para MLPPP e bastante útil para identificar quais interfaces físicas compõem o agrupamento lógico multilink, além de apresentar o status dessas interfaces. Nesse exemplo, é possível observar que ambas as interfaces físicas seriais estão operacionais.

R1# show ppp multilink 
Multilink1, bundle name is R2
  Username is R2
  Endpoint discriminator is R2
  Bundle up for 00:01:22, total bandwidth 3088, load 1/255
  Receive buffer limit 24000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 6 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x16 received sequence, 0x17 sent sequence
  Member links: 2 active, 0 inactive (max not set, min not set)
    Se2/0, since 00:03:25
    Se2/1, since 00:02:22
No inactive multilink interfaces

Para verificar a disponibilidade do agrupamento lógico, basta desativar qualquer uma das interfaces físicas seriais para simular um falha qualquer no link. Mesmo em caso de queda de um dos links físicos, a interface lógica se mantém disponível através do(s) outro(s) link(s) físico(s). Por exemplo, temos a seguinte saída após desativar a interface s2/1 em R2:

R1# show ppp multilink
Multilink1, bundle name is R2
  Username is R2
  Endpoint discriminator is R2
  Bundle up for 00:03:16, total bandwidth 1544, load 1/255
  Receive buffer limit 12000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 12 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x22 received sequence, 0x39 sent sequence
  Member links: 1 active, 1 inactive (max not set, min not set)
    Se2/0, since 00:05:20
    Se2/1 (inactive)
No inactive multilink interfaces

Façam seus testes...

Samuel.

Configuração de Link WAN PPP em Roteadores Cisco

Olá Pessoal,

O PPP (Point-to-Point Protocol) é uma tecnologia padronizada na RFC 1661 e que consiste em um conjunto de protocolos da camada de enlace (layer-2) para controle de links de longa distância. Assim como a tecnologia Ethernet possui protocolos adicionais de suporte no contexto das redes locais (por ex. STP), a tecnologia PPP possui vários outros protocolos complementares. As duas principais categorias de protocolos complementares são:

• Link Control Protocol (LCP): Esse protocolo implementa as funções de controle em nível de enlace (layer-2) de maneira totalmente independente do protocolo de rede utilizado nas camadas superiores, afinal o PPP é independente da tecnologia de rede utilizada em layer-3. As funções de controle estão relacionadas a diversos aspectos da conexão que envolvem o estabelecimento, configuração e verificação do link, além da autenticação (opcional);

• Network Control Protocol (NCP): Na realidade o NCP é uma categoria de protocolos de controle que contém vários sub-protocolos, de forma que cada sub-protocolo está associado com uma tecnologia de rede layer-3 específica. Exemplos comuns de sub-protocolos dessa categoria são o IP Control Protocol (IPCP), o IPv6 Control Protocol (IPv6CP) e o Cisco Discovery Protocol Control Protocol (CDPCP).

Outra característica importante do PPP é a autenticação das partes envolvidas na comunicação. No contexto de um link de longa distância (WAN), o processo de autenticação é importante para que as interfaces seriais de dois roteadores provem suas identidades antes de estabelecer o link. Dois protocolos de autenticação utilizados em conjunto com o PPP são o PAP e o CHAP, sendo que o procedimento de configuração de ambos é basicamente o mesmo. O PAP não é seguro porque faz o envio do usuário e da senha como texto simples (sem criptografia), enquanto que o CHAP é considerado mais seguro pela forma como faz a troca de mensagens entre as partes (hash MD5).

A topologia exibida na figura abaixo será utilizada para exemplificar a configuração de um link WAN PPP entre dois roteadores Cisco. Observem que propositalmente os dois roteadores serão configurados com endereços IP pertencentes a diferentes sub-redes, algo que a princípio faz parecer impossível a comunicação entre os dois roteadores. No entanto, a surpresa é que depois de configurado o link WAN PPP entre R1 e R2 a comunicação ocorre com sucesso. Por que isso acontece?

Antes de responder essa questão, vamos às configurações necessárias para estabelecer o link PPP. Um detalhe na configuração da autenticação é que em R1 deve ser criado um usuário na base local equivalente ao hostname de R2 e vice-versa. O nome do usuário a ser autenticado deve ser exatamente o nome de host que foi configurado no roteador da outra ponta, caso contrário a autenticação falhará.

R1(config)# username R2 password SENHA
R1(config)# interface s0/3/0
R1(config-if)# ip address 203.0.113.1 255.255.255.255
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap
R1(config-if)# no shut

R2(config)# username R1 password SENHA
R2(config)# interface s0/3/0
R2(config-if)# ip address 198.51.100.1 255.255.255.255
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap
R2(config-if)# no shut

Uma vez configurado o laboratório proposto, agora podemos voltar à discussão das razões pelas quais o ping entre os dois roteadores funciona mesmo quando as interfaces seriais são configuradas com endereços em diferentes sub-redes. Se utilizássemos o mesmo cenário para configurar uma WAN entre os roteadores R1 e R2 através de links seriais com encapsulamento HDLC (padrão), o ping não funcionaria com as duas interfaces seriais configuradas com endereços em sub-redes diferentes. Isso ocorreria porque os roteadores R1 e R2 não teriam uma rota diretamente conectada que fosse comum a ambos, ou seja, seria impossível direcionar a saída do tráfego ponto a ponto. 

Esse comportamento padrão muda bastante quando configuramos o encapsulamento para PPP, já que os protocolos de controle da categoria NCP são responsáveis por tratar automaticamente das informações de roteamento. No contexto do IPv4, o IPCP do PPP automaticamente adiciona uma rota de host (/32) apontando para o endereço IP do roteador vizinho. Essa característica pode ser observada nos destaques em amarelo das tabelas de roteamento listadas abaixo. 

Em R1 o PPP criou uma rota de host apontando para R2 (198.51.100.1/32):

R1> show ip route

Codes: (...) Códigos Omitidos

Gateway of last resort is not set

198.51.100.0/32 is subnetted, 1 subnets

C 198.51.100.1/32 is directly connected, Serial0/3/0

203.0.113.0/24 is variably subnetted, 2 subnets, 2 masks

C 203.0.113.0/30 is directly connected, Serial0/3/0

L 203.0.113.1/32 is directly connected, Serial0/3/0

R1> ping 198.51.100.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 198.51.100.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/8 ms

Em R2 o PPP criou uma rota de host apontando para R1 (203.0.113.1/32):

R2> show ip route

Codes: (...) Códigos Omitidos

Gateway of last resort is not set

198.51.100.0/24 is variably subnetted, 2 subnets, 2 masks

C 198.51.100.0/30 is directly connected, Serial0/3/0

L 198.51.100.1/32 is directly connected, Serial0/3/0

203.0.113.0/32 is subnetted, 1 subnets

C 203.0.113.1/32 is directly connected, Serial0/3/0

R2> ping 203.0.113.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 203.0.113.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/7 ms

Apesar de ser possível utilizar endereços em sub-redes diferentes, essa prática não é recomendada. Um problema decorrente dessa prática não recomendada é que não será possível executar protocolos de roteamento dinâmico entre R1 e R2, já que para formar a vizinhança de roteamento é necessário que os roteadores compartilhem a mesma sub-rede. Ou seja, sua rede não estará totalmente operacional mesmo que o resultado do ping seja um sucesso! Esse recurso do PPP  é denominado Peer Neighbor Route e pode ser manualmente desativado em sub-modo de configuração da interface serial através do comando "no peer neighbor route". Tenham cuidado com esse detalhe e procurem seguir as boas práticas que recomendam utilizar uma sub-rede /30 em links ponto-a-ponto.

Façam seus testes...

Samuel. 

Configuração de Cliente PPPoE em Roteadores Cisco

Olá Pessoal.

Um dos novos tópicos adicionados ao novo currículo CCNA R&S no que tange às tecnologias de longa distância é a configuração de PPPoE (Point-to-Point Protocol over Ethernet) no lado cliente, uma prática comum entre algumas operadoras que ofertam conexões à Internet via xDSL.

A tecnologia PPPoE é bastante utilizada com DSL porque o protocolo PPP é a opção natural para permitir a autenticação do usuário e o transporte das mais diversas tecnologias através das redes de transporte das operadoras, de forma que, por exemplo, quadros Ethernet encapsulados dentro de quadros PPP podem trafegar através das redes legadas ATM (Asynchronous Transfer Mode) que ainda possam existir em virtude do alto custo de implantação. Atualmente o maior motivador para uso do PPPoE é a possibilidade de autenticar o usuário com CHAP, um sub-protocolo nativo do PPP.

Nessas situações é comum a operadora disponibilizar um software de autenticação no lado do cliente, através do qual o usuário fornece suas credenciais (login e senha) para estabelecer a conexão com a Internet. Em pequenas empresas ou mesmo em ambientes residenciais que tenham várias máquinas ligadas em rede é mais conveniente transferir a responsabilidade de autenticação para um dispositivo central, de forma que o processo de conexão fica totalmente transparente para o usuário final. Esse dispositivo responsável pela autenticação pode ser o próprio roteador. Para exemplificar como seria o processo de configuração de uma conexão cliente PPPoE em roteadores Cisco estaremos considerando o cenário apresentado na figura abaixo.

A interface f0/0 está conectada na rede local (LAN), sendo que seu IP 192.168.0.254 será configurado como gateway da rede. A interface f0/1 está diretamente conectada ao modem da operadora instalado na casa do usuário, também chamado de CPE (Customer Premises Equipment). No lado da operadora existe um dispositivo chamado DSLAM que faz a agregação de vários modens DSL dos clientes e que, por sua vez, está conectado à rede da operadora que possui saída para a Internet. A seguir são apresentados os comandos para configurar o roteador como cliente PPPoE e, em seguida, são feitas algumas observações relevantes.

01. Router# conf t

02. Router(config)# interface f0/0

03. Router(config-if)# ip address 192.168.0.254 255.255.255.0

04. Router(config-if)# ip nat inside

05. Router(config-if)# no shut

06. Router(config-if)# interface f0/1

07. Router(config-if)# pppoe-client dial-pool-number 1

08. Router(config-if)# exit

09. Router(config)# interface dialer1

10. Router(config-if)# mtu 1492

11. Router(config-if)# encapsulation ppp

12. Router(config-if)# ip address negotiated

13. Router(config-if)# ppp authentication chap 

14. Router(config-if)# ppp chap hostname LOGIN

15. Router(config-if)# ppp chap password SENHA

16. Router(config-if)# dialer pool 1 

17. Router(config-if)# ip nat outside

18. Router(config-if)# dialer-group 1

19. Router(config-if)# exit

20. Router(config)# dialer-list 1 protocol ip permit

21. Router(config)# ip nat inside source list 1 interface dialer1 overload

22. Router(config)# access-list 1 permit 192.168.0.0 0.0.0.255

23. Router(config)# ip route 0.0.0.0 0.0.0.0 dialer 1

A configuração do PPPoE em roteadores consiste em criar e vincular uma nova interface virtual do tipo dialer à interface ethernet que está fisicamente conectada ao modem da operadora, processo realizado nas linhas 07, 09 e 16 da configuração anterior. Todas as demais configurações relacionadas ao PPP propriamente dito são realizadas na interface virtual dialer, já que esse tipo de interface tem suporte ao encapsulamento PPP. Ou seja, esse processo não passa de um mecanismo de tunelamento...

Em conexões DSL é comum a operadora atribuir dinamicamente os endereços dos usuários através de um servidor DHCP, no entanto é necessário o uso do protocolo IPCP (IP Configuration Protocol) no contexto do link PPP para que essa atribuição funcione. Por isso na linha 12 foi utilizado o comando "ip address negotiated" para habilitar o IPCP. 

Outra configuração extremamente importante é setar o tamanho máximo do quadro (MTU) para 1492 bytes (linha 10), uma vez que o novo cabeçalho PPP possui 8 bytes e o limite máximo do quadro Ethernet é 1500 bytes. Logo, para não estourar o limite do quadro Ethernet é necessário subtrair esses 8 bytes do PPP para que os quadros Ethernet não ultrapassem 1492 bytes antes de receber o cabeçalho PPP de 8 bytes. Todo processo de resolução de problemas em conexões PPPoE deve começar por essa observação, para assegurar que o MTU foi configurado para 1492, caso contrário a comunicação não é estabelecida.

Por fim, nas linhas 13, 14 e 15 são configuradas as credenciais de autenticação do usuário. Reparem que também já estamos fazendo a configuração do NAT, considerando a interface f0/0 como o lado inside e a interface dialer1 como o lado outside. O objetivo desse artigo não é mostrar o processo de configuração do NAT, por isso os leitores que tiverem dúvida nessa configuração podem consultar o Lab10 do livro "Laboratórios de Tecnologias Cisco em Infraestrutura de Redes".

Como complemento, as linhas 18 e 20 trazem uma configuração adicional de segurança que restringe o tráfego na interface dialer para aceitar apenas conteúdo IP, uma prática que não é cobrada no novo exame CCNA R&S (por isso não há destaque em amarelo). A linha 23 cria uma rota padrão apontando que todo o conteúdo direcionado à Internet deve sair através dessa interface virtual que tem conectividade com a operadora.

A título de informação, recentemente criei uma nova categoria no blog com a palavra-chave 200-120, onde estou agrupando todos os artigos relacionados aos tópicos adicionados no novo exame CCNA R&S. Recomendo aos leitores interessados no novo exame CCNA R&S que façam uma busca pela palavra-chave 200-120 porque em outras oportunidades já escrevi vários artigos falando sobre tópicos que foram acrescentados recentemente, a saber: SSH, SNMP, Syslog, NTP, NetFlow, IOS 15, etc.

Abraço.

Samuel.