Olá pessoal, tudo bem?
Continuando minha série de artigos onde compartilho as anotações acumuladas durante 3 anos de estudos até passar no lab de CCIE Routing and Switching, anos atrás. Foram centenas de páginas em cadernos com muitas informações e observações que considerei e ainda considero importantes, depois de 15 anos trabalhando com Routing and Switching.
Novamente, acredito que essas informações ajudam não apenas para quem está estudando para certificações, mas no dia-a-dia de outros network engineers como eu a lidar com infraestrutura Cisco.
Para quem perdeu, segue o link do primeiro artigo sobre Switching. Neste segundo artigo vamos explorar “PPP” 😉
Estejam a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do conteúdo, incentivo a informar que o conteúdo foi útil aqui na Comunidade Cisco, clicando "útil" ao final do post.
PPP
Principal vantagem é ser “media independent”, além de ser considerado um encapsulamento bem leve.
Adiciona funcionalidades importantes que outros meios L2 não suportam nativamente:
- Autenticação
- Fragmentação
- Multilink
- Confiabilidade
LCP PHASE — PPP usa “Link Control Protocol” (LCP) para negociar opções básicas e protocolos da camada superior.
UPPER LAYER NEGOTIATION — cada negociação possui seu próprio protocolo de controle com seus próprios parâmetros de negociação:
- IPCP
- IPv6CP
- CDPCP
- etc
Tais parâmetros podem ser utilizados para negociar endereçamento e roteamento.
Isso vem da época do dial-up para ISP quando o cliente acessava o mesmo Access Server (AS) que servia mais de um pool de DHCP. O AS precisava saber qual era o IP do client (que ganhou via DHCP) porque o AS geralmente estava em outra rede. Então IPCP negocia e instala uma rota “exact match” /32 com endereço do client, permitindo que estejam em subredes diferentes.
Por default, o IPCP aprende sobre o remote host e instala o “exact match” na RIB em links P2P. Isso permite que os hosts estejam em redes diferentes e mesmo assim consigam se comunicar.
- “no peer neighbor-route” desabilita esta função.
OBS: Tudo pode ser verificado através de “debug ppp negotiation”. Sempre jogar este debug para o log porque pode sobrecarregar o buffer de console e ficar travado. Aí só com reload 😞
- logging con 6 — não manda debug pro console
- logging buffer 7 — manda debug pro buffer
- logging buffer XXXXXX — ajusta um buffer grande
- clear log — limpa o log
Password Authentication Protocol (PAP)
Usa clear text para “username” e “password”.
Autenticação acontece em 3 fases:
- Authentication Request
- Authentication Response
- Validation — Accept ou Deny
Validação sempre bate contra uma base de dados local ou remota (TACAS, AAA, etc).
A autenticação sempre é “one way”. Significa que a autenticação em um peer é independente da autenticação no outro peer, permitindo misturar parâmetros e opções.
- Quem autentica manda o REQUEST
- AUTH-NACK significa que a autenticação foi negada
CHAP
- Quem autentica manda o request informando “hostname”.
- Host busca na base pelo hostname recebido e retorna um hash MD5 criado a partir da senha (configurada para o hostname) e magic-number.
- Quem autentica recria o hash MD5 baseado na password configurada para o host e no magic-number e então compara com o hash recebido.
OBS: Não importa o sentido da autenticação, a senha deve ser a mesma (compartilhada) e não pode usar parâmetro “secret” (porque não resultará no mesmo hash em ambos os lados) pois o CHAP criptografaria novamente.
- “ppp chap password” — usa senha default para criar o hash da resposta. Não é usado para validar autenticação. Username e senha específicos sobrepõem a senha default.
OBS: Uma solução simples quando temos muitas interfaces Seriais no mesmo router é ajustá-las como “unnumbered” apontado-as para uma loopback e deixar que o PPP instale rotas /32 garantindo a comunicação.
PPPoFR
O maior cuidado ao usar PPPoX é criar o virtual-template antes de atrelar uma interface. Caso contrário a interface pode não funcionar mesmo com a config ok.
Virtual-template é sempre um link com encapsulamento PPP e se trata de uma interface específica para PPP.
Virtual-access é a instância do virtual-template. Neste caso a access precisa esta UP, enquanto o template sempre permanece DOWN/DOWN.
OBS: Se habilitar debug da tecnologia (ex: debug frelay packets) o protocolo superior irá apontar para PPP e não mais para IP.
Mesmo configurado em interface principal multiponto, a instância lógica virtual-access é P2P porque, por definição, Point-to-Point Protocol só pode ser configurado entre 2 neighbors por vez.
PPP adiciona cabeçalho de 8 bytes ao payload e obviamente pode gerar problema com MTU.
Interface Multilink é similar a interface etherchannel. Interface lógica onde vai a config e o PPP se encarrega de fazer fragmentação e balanceamento entre todas as interfaces do grupo.
Por ser independent é possível unir interfaces de diferentes tecnologias que tenham suporte a PPP (frelay, eth, atm, etc).
Exemplos de Configuração e TechNotes sobre PPP: https://www.cisco.com/c/en/us/tech/wan/point-to-point-protocol-ppp/tech-configuration-examples-list.html
PPPoE
- DOC — Server: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bbdsl/configuration/15-mt/bba-15-mt-book/bba-pppoe-baa.html
- DOC — Client: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bbdsl/configuration/15-mt/bba-15-mt-book/bba-ppoe-client.html
PPPoE é basicamente XDSL.
DSLAM (DSL Aggregation Multiplexer) — Basicamente aprega vários links ATM em links de maior velocidade, fazendo basicamente só L1. Este link de maior velocidade vai para um PPPoE Server.
O cabeçalho do PPPoE tem 8 bytes, portanto se não configurar MTU 1492 para fragmentar… pacotes com 1493–1500 bytes terão na verdade 1501–1508 e não serão fragmentados pelo PPP e portanto descartados pela eth.
Passos no Server:
- Definir interface PPP
- virtual-template X
2. Aplicar opções lógicas
- autenticação, multilink, ip address, etc
3. Definir BBA group (broadband e access aggregation)
- bba-group pppoe [NAME | global]
- virtual-template X
4. Atrelar ao link
- pppoe enable group [NAME | global]
Passos no Client:
- Definir interface PPP
- interface dialer X
- encap ppp (por default PPP usa encapsulamento HDLC) (virtual-template só suporta PPP)
- dialer pool Y
2. Aplicar opções lógicas
- autenticação, multilink, ip address, etc
3. Atrelar ao link
- pppoe-client dial-pool-number Y
PPPoE altera a MRU (Maximum Receivable Unit) para 1492 com 8 bytes de overhead. Neste caso é necessário alterar MTU da Dialer para 1492 porque pode afetar Path MTU discovery ou forçar o router a fazer fragmentação. Pode quebrar camadas superiores de aplicação com mais de 1492 bytes.
- Solicita IP através do IPCP (PPP):
- — ip address negotiated
- Responde através do pool local (negotiated <-> pool):
- — peer default ip address pool POOL
- Solicita IP através do BOOTP:
- — ip address dhcp
- Responde através de DHCP:
- a) Usa pool local:
- — — peer default ip address dhcp-pool
- b) Encaminha para DHCP server:
- — — peer default ip address dhcp
- — — ip helper-address
Nas interfaces, “mtu” especifica o tamanho do frame L2 e “ip mtu” o tamanho do payload L3.
Explicação sobre PPPoE na Wikipedia é muito boa: https://pt.wikipedia.org/wiki/PPPoE
Leia o resto do artigo no link abaixo:
Se gostou do conteúdo, incentivo a informar que o conteúdo foi útil aqui na Comunidade Cisco, clicando "útil" ao final do post.
