cancelar
Mostrar resultados para 
Pesquisar em vez de 
Queria dizer: 
cancel
giuks
Beginner
Beginner

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 😞

  1. logging con 6 — não manda debug pro console
  2. logging buffer 7 — manda debug pro buffer
  3. logging buffer XXXXXX — ajusta um buffer grande
  4. 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

  1. Quem autentica manda o request informando “hostname”.
  2. Host busca na base pelo hostname recebido e retorna um hash MD5 criado a partir da senha (configurada para o hostname) e magic-number.
  3. 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

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:

  1. 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:

  1. 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.
Primeiros Passos

Encontre respostas, faça perguntas e conecte-se com nossa comunidade de especialistas da Cisco de todo o mundo.

Estamos felizes por você estar aqui! Participe da conversa, encontre respostas, faça perguntas e conecte-se com sua comunidade.