Minha jornada até o CCIE RS — PPP + Frame Relay

Neste segundo artigo, continuo a série de artigos com minhas anotações acumuladas durante 3 anos de estudos até passar no lab de CCIE RS, anos atrás. Como disse no primeiro artigo, são quase 400 páginas de cadernos com informações e observações que considero importantes ao trabalhar com Routing and Switching por quase 15 anos. Algumas tecnologias não são mais utilizadas, mas postarei mesmo assim (ex: Frame Relay :).

Acredito que estas informações possam ajudar não apenas a passar em certificações, mas no dia-a-dia de outras pessoas (como eu) ao lidar com infraestrutura Cisco.

Para quem não leu o primeiro, sobre “Switching”, segue link. Abaixo segue a segunda parte, sobre “PPP” e “Frame -Relay”.

Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do conteúdo, incentivo a compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)

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).

DOC sobre PPP: https://www.cisco.com/c/en/us/td/docs/ios/12_2/dial/configuration/guide/fdial_c/dafppp.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:

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

Frame Relay

Frame Relay (ou “frelay” pra ficar mais fácil) não é comum hoje em dia porque foi substituído por tecnologias mais rápidas. Mesmo os ISPs que ainda oferecem frelay, só implementam nas bordas com os clientes e mantém o core através de MPLS VPN.

Meios Broadcast

• Ethernet, Token-ring, FDDI
• Suportam broadcast nativo
• Facilita a resolução L3->L2

Meios non-Broadcast Multi Access

• Frame relay, ISDN, ATM, etc
• Origem não pode endereçar todos os destinos conectados simultaneamente.
• Broadcast L2 é enviado como unicast L2 replicado (conhecido como “pseudo-broadcast”).
• Implica em problemas de resolução L3->L2.

Resolução L3->L2

Broadcast: resolução L3 é necessária para atrelar endereços remotos L2 para endereços L3. (conhecemos L3 mas não conhecemos L2)

Non-broadcast: o problema é o contrário do broadcast. Resolução L3 é necessária para atrelar endereço L2 remoto ou local com L3 remotos. (conhecemos L2 mas não conhecemos L3)

Frelay precisa resolver endereços remotos L3 para endereço local L2. Inverse ARP (contrário do ARP) realiza este processo somente para dispositivos diretamente conectados. A outra opção é resolução declarada explicitamente (frelay map).

OBS: como somente os dispositivos diretamente conectados podem ser resolvidos, isso implica em problemas adicionais de resolução em rede partial mesh NBMA.

Interface Multipoint

• Pode ter múltiplos endereços L2 ao mesmo tempo
• Portanto, requer resolução L3->L2
• “main interface” ou “multipoint subinterface”

Interface Point-to-Point

• Só pode ter um único endereço L2
• Portanto, não precisa de resolução
• No caso NBMA, somente subinterfaces P2P

Data Link Connection Identifier (DLCI) é o endereço L2 e tem importância local (entre router e SW Frelay) para os neighbors diretamente conectados.

Local Management Interface (LMI) é o protocolo de sinalização utilizado para informar o status do DTE para a rede do ISP.

OBS: LMI type é automaticamente detectado ao habilitar o Frelay. A interface Frelay só permanece UP/UP se receber LMI e concordar com o tipo do LMI.

LMI informa quais circuitos estão atrelados a uma interface e qual o status individual de cada circuito fim-a-fim.

Status:

• Active — ok fim-a-fim (geralmente)
• Inactive — configurado ok, mas existe alguma falha no caminho
• Deleted — a config do router não é compatível com a do SW Frelay (geralmente DLCI configurado errado em um dos lados).
• Static — LMI está desabilitado (geralmente utilizado para “back-to-back Frelay”).

OBS: Inverse ARP não suporta IPV6 (na realidade IPV6 não suporta InARP), portanto IPV6 sobre interface frelay multipoint precisa ser mapeada explicitamente.

InARP request pode ser desabilitado por interface.

InARP reply não pode ser desabilitado.

Mapeamento estático sobrescreve mapeamento dinâmico, desabilitando InARP para aquele circuito específico (InARP continua operando para demais circuitos). Novamente, não desabilita InARP replies.

Auto-Install via Frelay

Auto-instal é utilizado para carregar automaticamente uma config para um novo roteador.

Se nenhuma config é detectada, o router detecta o encasulamento da interface e envia uma solicitação de endereçamento.

Uma vez que este endereço seja atrelado, o router tenta carregar a config via TFTP.

LAN (DHCP), HDLC (SLARP), Frelay (BOOTP).

OBS: Se a solicitação de endereço através de Frelay falhar, o router instala mapeamento para 0.0.0.0 (NULL address). Esse mapeamento para 0.0.0.0 pode causar falhas importantes nos protocolos de roteamento, principalmente entre roteadores que não deveriam estar no mesmo domínio L2. Falhas podem incluir vazamentos no processo de roteamento e multicast. Primeira coisa a fazer nessa situação é salvar a config e reiniciar (como há config, o auto-install não ocorrerá).

Interfaces point-to-point são o design ideal para solucionar problemas L3 relacionados com NBMA (como OSPF e Multicast over Frame relay)

OBS: Como o tipo de interface e resolução é somente localmente significante, qualquer combinação de interfaces frelay é suportada.

Partial Mesh

É quando todos os dispositivos não tem circuitos para todos os outros.

Problemas de design ocorrem quando a rede L3 não está mapeada exatamente para a rede L2. Geralmente:

• Dispositivos não conectados diretamente não conseguem se resolver através de InARP.
• Alguns protocolos de camadas superiores não entendem a falta de conectividade do Partial Mesh (ex: OSPF, PIM, etc).

Cenário ideal no Frelay é usar subinterfaces P2P com subredes IPV4/IPV6 separadas para cada uma.

No frelay, tanto o tipo de interface quanto a resolução L3 -> L2 são localmente significantes para o router.

Os DLCIs da interface principal são movidos para as subinterfaces através do “frelay map” ou do “interface-dlci”. A diferença entre eles é que interface-dlci não realiza L3 -> L2, simplesmente atrela o circuito a interface. Se a interface é multiponto, InARP requests são enviados para cada circuito.

InARP é habilitado assim que o encapsulamento frelay e o endereço IP sejam configurados. Há necessidade de desabilitar InARP quando houver DLCIs não usados.

• “no inverse arp” configurado na interface física não é repassado às subinterfaces. O uso simultâneo de interface e subinterface não é comum mas pode vir a ocorrer (mas é bem estranho…).

Para agilizar, sempre configure a interface Frelay em shut. Se estiver UP, o InARP pode levar até 1 minuto para operar.

• OBS: Outro ponto importante é que o InARP pode mapear os PVCs antes de configurarmos o mapeamento estático.

Obviamente, a recomendação entre estático e dinâmico é estático tanto no lab (até CCIE RS v4) quanto em ambiente real.

InARP é muito imprevisível, portanto não devemos misturar mapeamento dinâmico com estático (principalmente em ambientes “partial mesh”).

InARP request pode ser desabilitado por interface ou por circuito (InARP reply não pode ser cancelado). Outra alternativa é mover os DLCIs para uma interface sem IP (pode ser qualquer uma, geralmente multipoint subinterface).

Não é muito confiável limpar o mapeamento com “clear frelay inarp”. Mais certo é “shut/no shut”.

Durante o lab, InARP deve ser a última opção de escolha :

1. Subinterfaces Point-to-point
2. Subinterfaces Multipoint (oferece mais controle sobre DLCIs)
3. Interface Multipoint com mapeamento estático
4. Interface principal com mapeamento estático
5. InARP (evitar ao máximo)

OBS: Se configurar “frelay map” em uma interface, “frelay dlci” não fará a menor diferença.

OBS: Mapeamento de interface P2P não mostra IP (nem precisa).

Pingar o próprio endereço IP em uma interface frelay mutipoint não significa nada. Para isto o router precisa ter um mapeamento para a própria interface (circuito na interface) e portanto o request e o reply são enviados através deste circuito. O resultado quando pingamos o próprio endereço é que os pacotes acabam indo até o neighbor duas vezes e portanto leva o dobro do tempo. “Se conseguimos pingar o peer, conseguimos pingar nós mesmos”

Ao enviar pacotes Broadcast e Multicast no Frelay, o endereço L3 não é alterado.

Cada circuito mapeado com parâmetro “broadcast” recebe uma cópia do broadcast/multicast. Portanto não se configura “broadcast” no mapeamento para spokes para evitar que o hub receba tráfego repetido.

Durante o “pseudo-broadcast” o router não se importa com o endereço IP, apenas com o parâmetro broadcast configurado nos circuitos durante o “broadcast search” (aparece na log).

OBS: Uma gambiarra é configurar um mapeamento com endereço inexistente apenas com o parâmetro broadcast.

Se aparecer um mapeamento para 0.0.0.0 (bug, auto-install, etc) isso irá gerar problemas. Ex: OSPF envia Hello broadcast e estabelece paridade, porém a sincronização é unicast (0.0.0.0) e não se completa nunca; o timer da adjacência expira… e começa tudo de novo…

• sh frame map = sh arp — mostra bindings L2

Entre spokes podemos usar:

• mapeamento L3 (spoke) — L2 (hub) — mais comum
• mapeamento L3 (spoke) — L3 (hub) — gambiarra com rota estática
• OSPF point-to-multipoint

OBS: OSPF point-to-multipoint não propaga a rede em si, só /32.

Local Management Interface (LMI)

Interface principal Frelay permanece UP/UP se receber LMI e concordar com o tipo de LMI. (Pode ser automaticamente detectado ao habilitar Frelay).

Uma subinterface P2P Frelay permanece UP enquanto receber LMI e seu DLCI estiver ativo. Isso é muito melhor para protocolos de roteamento onde não existe o conceito de adjacência, como RIP.

Uma subinterface multipoint Frelay permanece UP enquanto receber LMI e qualquer um de seus DLCI estiver ativo (cuidado).

OBS: Interface principal frelay sempre inicia UP/UP e passa para UP/DOWN quando expira o “keepalive interval” (timeout do LMI).

OBS: Todo pacote originado pelo router ou destinado para ele é processado em software (process switch) enquanto todos os pacotes que atravessam o router são comutados em hardware (CEF switching). Portanto para usar “debug ip packets” ou “debug frelay packets” o CEF precisa estar desabilitado.

• debug frelay events — processo InARP
• debug frelay packets — todos os pacotes IN e OUT
• — mostra informações úteis sobre a pilha de protocolos
• — 0x8000 é a stack IP
• — 0x806 é InARP

OBS: Em Partial mesh, o frelay hub pode gerar um ICMP-redirect para cada pacote que ele recebe porque acredita que os spokes também estão diretamente conectados (enorme desperdício de banda).

OBS: No frelay, sempre testar unicast, broadcast e multicast se-pa-ra-da-men-te.

Frame Relay Switching

• frelay switching
• (if) frelay inf-type -> habilita processo LMI
• (if) frelay route X int Y Z
• (if) frelay route Z int W X

ou

• connect R1_TO_R2 int X A int Y B

OBS: obviamente usar comando “frelay route” e “connect” ao mesmo tempo dá erro.

Frame Relay back-to-back

Pode ser usado em conexões Seriais diretas no lugar de PPP ou HDLC apesar de não haver vantagem nenhuma em fazer isso.

Neste cenário não há SW frelay, portanto nenhum LMI é gerado e é necessário desabilitar LMI (no keepalive) tornando o circuito static.

Se o LMI não é desabilitado, o circuito se mantém DELETED porque envia uma request mas não recebe reply e neste caso o roteador entende que o valor está incorreto.

OBS: Basicamente a única diferença na config é desabilitar o LMI.

OBS: Ambas as interfaces devem concordar com o PVC visto que ele é “link significant”.

Frame Relay End-to-End Keepalive (EEK)

Por default, LMI fim-a-fim é usado para acompanhar o status do circuito. Se um lado estiver DOWN por qualquer motivo, o outro permanece INACTIVE.

Alguns cenários quebram o funcionamento do LMI fim-a-fim:

• quando usamos frame relay over MPLS L2VPN
• quando há transição entre diferentes ISPs, eles geralmente não trocam o status da LMI

EEK opera diretamente entre dispositivos DTE porque o objetivo é não confiar mais no LMI. Portanto deve ser configurado em ambos os neighbors ou o circuito permanece DOWN.

EEK é configurado através de “map-class” (não confundir com “class-map”). Map-class é uma forma antiga de configuração do frelay que permite configurar EEK, frelay shapping, pattern compression, DE bit, etc.

Pode ser implementado de 2 formas:

• classe aplicada no DLCI específico
• — frame-relay interface-dlci X
• — — class CLASS
• classe aplicada na interface, onde todos os circuitos herdam a config
• — OBS: este método é ruim quando queremos alterar parte dos circuitos.
• show frelay pvc — mostra status EEK para todos os circuitos ativos onde o EEK foi aplicado.

Frelay suporta fragmentação em L2, geralmente utilizado para QoS. Ethernet não suporta isso e precisa fazer em L3 (PPPoE).

OBS: Quando o prompt retorna para um prompt superior àquele em que estava é porque o comando inserido faz parte de um modo superior e não do modo atual. Portanto CUIDADO principalmente com classes em DLCIs, subinterfaces e interfaces principais porque pode mudar o que não se quer.

DOC — Frame relay: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/wan_frly/configuration/15-mt/wan-frly-15-mt-book.html

O que achou do conteúdo?

Faltou algum ponto importante?

Fala pra mim nos comentários.

Se gostou do conteúdo, incentivo a compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)

Sobre o autor:

Giuliano Barros é Network Consultant & Founder da Control Plane — Network Services.

Graduado em Ciência da Computação, certificado CCIE RS pela Cisco Systems e trabalha há 15 anos em projetos para médias e grandes empresas. linkedin.com/in/giulianobarros