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.