Minha jornada até o CCIE RS — IP Routing
Este é o terceiro artigo da série com minhas anotações acumuladas durante anos de trabalho e estudos até passar no lab de CCIE RS. Quase 400 páginas de caderno com pontos chave e observações que considerei importantes ao trabalhar com Routing and Switching quase 15 anos. Durante essa série algumas tecnologias não são mais utilizadas, mas postarei mesmo assim porque estou digitalizando tudo :)
Acredito que estas informações ajudarão 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 os artigos anteriores, seguem os 2 links sobre “Switching” e “PPP”. Abaixo segue terceira parte, sobre “IP Routing”, e ao final uma lista de comandos “show” + filtros que considero eficiente.
Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a compartilhar com colegas do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)
IP Routing
3 principais passos:
- Routing — encontrar interface de saída (protocolos de roteamento)
- Switching — mover os pacotes entre as interfaces. Nesta etapa acontece o etherchannel, load balancing e qualquer decisão L2, uso da Global FIB ou Local FIB…
- Encapsulation — construção do cabeçalho L2
A principal diferença entre Routing and Switching é que o processo de roteamento reconstrói o cabeçalho L2 em um processo “hop-by-hop”.
Processo de roteamento
Realiza match da maior quantidade de bits entre rotas e destino utilizando RIB ou FIB “longest match”. Depois utiliza “route recursion” (recursão) para descobrir a interface de destino (saída).
Para múltiplos “longest match”:
- diferentes protocolos -> menor DA
- mesmo protocolo -> menor métrica
Distâncias Administrativas
- 0 — Connected
- 1 — Static
- 5 — EIGRP summary
- 20 — EBGP
- 90 — EIGRP
- 110 — OSPF
- 120 — RIP
- 170 — EIGRP EX
- 200 — iBGP
Preferências entre DAs
- EBGP — Se a rota foi recebida através de EBGP, provavelmente é externa ao AS.
- Internal IGP — Se a rota é interna, portanto devemos usar IGP.
- iBGP — Pela lógica oposta, se a rota é interna devemos sempre tentar usar IGP antes de iBGP.
OBS: OSPF não distingue rotas internas e externas com DAs diferentes e isto pode causar problemas.
OBS: RIP nem consegue distinguir rotas internas e externas, portanto maior parte dos problemas de loop ocorrem entre RIP e outros protocolos de roteamento.
Toda rota estática tem DA 1, apesar de muitos livros dizerem que é 0 (zero). Além disso não há modo de ajustar alguma rota para DA 0.
Switching Proccess
Realiza todas as decisões L2:
- process, FAST, CEF
- load balancing
- usar Global FIB ou Local FIB
- etc
Múltiplas rotas na tabela de roteamento podem ser usadas de forma diferente. Cabe ao Switching Process determinar como usar.
CEF realiza pesquisa determinística sempre com 4 procuras (1 para cada octeto) independente do endereço A.B.C.D. Desta forma CEF popula o data plane inteiramente antes de operar (copia a RIB para a FIB) e sempre obterá sucesso com as 4 pesquisas (portanto comportamento determinístico).
Segue ótimo artigo sobre as formas de switching no IOS: http://www.itcertnotes.com/2012/04/cisco-ios-packet-switching.html
Process Switching realiza a pesquisa “top-down” se baseando na organização da tabela de roteamento. Não há como prever a organização da tabela e a pesquisa é realizada por pacote (que m$#%!!!).
Fast Switching é realizada pelo data plane que copia na cache o mapeamento quando o primeiro pacote é recebido. Portanto o data plane é populado conforme os destinos são utilizados em tempo real (enquanto CEF é inteiramente pré-calculada).
- OBS: Nos equipamentos modulares mais novos (ex: catalyst 6500) os módulos armazenam cópias locais do data plane.
Livros bem low-level sobre o sistema operacional, queueing, gerenciamento de memória, etc:
Geralmente o cabeçalho L2 permanece inalterado entre as interfaces L2, sendo alterado caso se use NAT, alteração de QoS, etc.
- Encapsulamento em interfaces multipoint requer resolução L3 -> L2.
- Encapsulamento em interfaces P2P não precisam de endereço L2 porque por definição são P2P.
Processo de Roteamento
- Para Next-hop
- — realiza recursão para interface
- — se multipoint, realizar resolução L3 -> L2 do next-hop
- Para interface Multipoint:
- — recursão não é necessária
- — realizar resolução L2 para destino final:
- — — ethernet proxy-arp
- — — NBMA mappings
- Para interface Point-to-Point (a mais simples):
- — não é necessária recursão
- — não é necessária resolução L2
Rotear para interfaces multipoint não é uma boa solução porque precisa do endereço L2 de cada destino (e não do next-hop).
É possível utilizar next-hop + multipoint interface, porém desde que o CEF copia o mapeamento do destino para L2 correto no Data Plane (FIB), não há necessidade de especificar a interface.
O modo mais simples e eficiente de rotear é através de interface P2P porque não precisa realizar pesquisa recursiva nem resolução L3 -> L2.
Proxy ARP responde por todos os outros endereços IPs para os quais tiver rotas com seu MAC.
Local Proxy ARP responde por endereços locais (de outras interfaces) com seu MAC.
Default Routing
- Para next-hop
- — Usar endereço L2 do next-hop para todos os destinos
- Para interface point-to-point
- — Nenhuma resolução L3 -> L2 é necessária
- Para interface interface Multipoint
- — Todos os dispositivos requerem resolução L3 -> L2
- — Pode gerar problemas com tamanho da tabela de mapeamento L3 -> L2
OBS: Se o roteador de borda utilizar default routing para uma interface multipoint e seu peer usar Proxy ARP, a quantidade de destinos apontando para o peer pode ser monstruosa e lotar o ARP CACHE (precisa de uma entrada para cada destino).
É possível apontar um range de endereços para interface multipoint e mapear os endereços L3 de destino para o o correto L2. Isso é uma forma de roteamento estático em L2 (…gambiarra).
Resumindo… roteamento estático para interface multipoint é cagada :)
- ip default-gateway
- — somente com roteamento desabilitado
- ip default-network
- — prefixo é marcado como default nas propagações de roteamento
- — precisa ser uma rede classful que não esteja diretamente conectada
“ip default-network” foi criado basicamente porque RIP v1 e IGRP não suportavam anúncio de rota 0.0.0.0. Ele não instala uma rota default, apenas adiciona uma tag de “candidate default”.
On-Demand Routing (ODR)
- Utiliza CDP para propagar redes diretamente conectadas para o “hub”.
- “Hub” propaga somente rota default para o “stub” router através de CDP porque o stub só tem 1 link de saída.
- Protocolos de roteamento não são permitidos no stub. No momento que algum protocolo é habilitado, a propagação do prefixo é desabilitada do CDP.
OBS: CDP é desabilitado por default em interfaces principais frame-relay multipoint (em subinterfaces vem habilitado).
ODR é baseado em CDP, portanto:
- Para desabilitar propagação de ODR basta desabilitar CDP
- CDP timer = keepalive do ODR
- CDP holdtime = holdtime do ODR
Rotas Estáticas Flutuantes
- São rotas estáticas com DA mais alta usada como backup para outra rota.
- As rotas devem ser de mesmo tamanho.
- O tempo de convergência é diretamente relacionado ao status da interface.
OBS: no lab CCIE podemos usar qualquer solução, mas quase sempre estará escrito que não pode.
Backup Interface
Originado das “tecnologias dial” (dial backup) onde a interface discada só deveria ser habilitada se o principal caísse, porque normalmente se paga por uso.
Realiza tracking do “line protocol” da interface primária.
- Se line protocol está UP, interface backup permanece em “standby”.
- Se line protocol está DOWN, interface backup permanece em “ativa”.
Possui uma opção de load threshold da interface principal.
Desabilitar manualmente a interface primária não habilita a interface backup 😞 A backup permanece em disabled para evitar que as conexões discadas fossem ativadas sem intenção ($$$). Portanto para testar precisa derrubar a principal de outra forma (line protocol).
Porém o status da line protocol não é um bom indicativo de conectividade fim-a-fim. Isso acontece com qualquer tecnologia que disponha de dispositivos intermediários (ex: switches, frame relay, etc).
OBS: Essa feature é independente de DA, portanto pode retirar rotas de melhor preferência da RIB ao colocar a interface como backup.
No Frame relay:
- Interface principal só é afetada por falhas no link local, portanto derrubar a interface do outro lado não afeta a interface principal porque interface multiponto faz tracking de múltiplos circuitos.
- Subinterface multipoint permance UP/UP se qualquer DLCI permanecer ativo.
- Subinterface P2P permance UP/UP se o DLCI permanecer ativo.
OBS: Se houver possibilidade, sempre utilize P2P porque simplifica resolução L3 -> L2 e teoricamente é um bom indicativo de conectividade fim-a-fim.
F-relay entre ISPs geralmente trafega através de tunnel MPLS, portanto LMI fim-a-fim não funcionará nesses casos (afinal não passa LMI).
Enhanced Object Tracking (EOT)
É o tracking tradicional que conhecemos, conhecido no passo como RTR (response time reporter).
Basicamente monitora de forma confiável qualquer coisa visando conectividade fim-a-fim.
EOT adiciona “application inteligence” ao serviço de confiabilidade fim-a-fim porque existem dúzias de protocolos para monitorar com EOT (telnet, ssh, ping, etc). O teste mais comum é “echo” (ping).
DOC: IP Application Services Configuration Guide
DOC: IP SLAs Configuration Guide
EOT não é recomendado para ambientes muito complexos, mas adiciona certo nível de inteligência em ambientes simples. Um bom exemplo é um roteador de acesso que está atrás de um modem ou transceiver utilizar EOT para verificar conectividade com o destino.
Policy Routing
Enquanto roteamento normal é baseado em destino, Políticas de Roteamento podem ser decididas baseadas em:
- Origem
- Destino
- Tipo de protocolo
- Interface de entrada
Basicamente tudo que cabe numa ACL estendida pode ser usado para ajustar Política de Roteamento.
Um ponto negativo é que a configuração deve ser realizada manualmente e portanto não é escalável de jeito nenhum. Além disso, a maioria das plataformas suportam policy routing somente em software (processamento vai pra Lua).
- OBS: Equipamentos high-end suportam policy routing em hardware dependendo da PFC que está usando.
Critério de tráfego é definido por um match em route-maps:
- permit — roteado pela política
- deny — encaminhado normalmente através da RIB
Ação é definida por um “set” em route-maps:
- pode encaminhar para next-hop ou interface.
OBS: Ao encaminhar diretamente para uma interface devemos utilizar sempre interfaces P2P evitando problemas de resolução L3 -> L2.
OBS: Como routing policy geralmente é realizado em software pode gerar altas taxas de processamento. As versões mais novas possuem “policy cache”.
DOC: PBR
2 modos de policy-routing:
- policy — aplicado ao tráfego de entrada
- local policy — aplicado ao tráfego originado localmente
OBS: Alguns equipamentos tinham um bug que incluia na “local PBR” o tráfego do próprio control plane (ex: protocolos de roteamento), alterando o comportamento do roteamento.
OBS: No lab CCIE o uso típico do PBR geralmente é sobrescrever o roteamento padrão.
OBS: Jamais rodar “debug ip policy” jogando a saída para console, pode travar o roteador (aí já era…). Melhor método é habilitar uma ACL no roteador que deveria receber o tráfego apenas para contar pacotes através dos matches.
Ponto negativo do PBR é que não há forma de checar através do control plane se o PBR criou um loop na topologia. Um loop quando o router encaminha o pacote pela mesma interface que ele chegou (geralmente o pacote é descartado).
Para aplicar PBR é preciso ter a visão da rede como um todo. Misturar PBRs pode dar m%$#!, cuidado.
Quando o PBR é direcionado para uma interface multipoint, ele também consulta a RIB para decidir o next-hop e encapsular L3 -> L2 (ou apresentará falha de mapeamento). Portanto sempre usar interface P2P ou IP next-hop.
OBS: Ideal é sempre checar através de debug filtrando com ACL.
Se o PBR não conseguir definir a interface de destino através de recursão na RIB, o PBR será rejeitado e o tráfego será encaminhado normalmente (FIB policy rejected — normal forwarding).
É necessário entender o comportamento da rede, portanto sempre verifique se a topologia concorda com o que pretende fazer antes de aplicar o PBR… ou o pacote pode tomar um caminho errado e gerar loop.
Configurando o route-map sem ACL de “match” significa que TUDO será tratado no PBR.
Quando o PBR apontar para next-hop em ethernet deve-se usar <set ip next-hop verify-availability>. Isso porque o PBR utiliza para recursão o line status da interface e não a conectividade fim-a-fim.
- Sobre interface serial e frame relay funciona.
- Verify-availability sobre CDP não funciona bem em ethernet porque vai detectar o SW diretamente conectado (e não os roteadores ou equipamentos conectados ao SW).
- — OBS: o problema sobre ethernet pode ser corrigido com “L2 protocol tunnel” (muito ruim) ou com EOT (tracking) porque é fim-a-fim (muito melhor!!!).
OBS: Traceroute no IOS não usa ICMP, usa UDP ECHO. Portanto tudo que alterar ping não funcionará com traceroute (debugs mostram comportamento diferente para cada um). Portanto se for testar com ping (ICMP) já adiciona UDP para testar traceroute junto.
Generic Routing Encapsulation Tunnel (GRE)
- Protocolo IP 47 (IP in IP é 4)
- Usado para transportar outro protocolos como payload sobre uma rede IPV4 (ex: IPV4, IPV6, etc).
A principal diferença entre GRE e outros protocolos de encapsulamento é que GRE é multiprotocolo e pode encapsular praticamento tudo.
Passos:
- Criar interface tunnel (modo default é GRE)
- Definir a origem e destino (testar conectividade entre elas)
- Aplicar os protocolos de payload
- keepalive opcional (off por default)
Falha recursiva no túnel:
- O destino do túnel não deve permitir recursão para a própria interface do túnel:
- — 1.1.1.1 via tunnel 1 -> tunnel 1 via 1.1.1.1 -> 1.1.1.1 via tunnel 1 -> …
- O IOS detecta tal falha e desabilita a interface.
- Pode acontecer devido a uma falha de roteamento estático ou dinâmico onde o roteador aprendeu o IP da interface de destino do túnel através do próprio túnel. A principal causa é quando utilizamos roteamento dinâmico no tunnel e na interface de origem do tunnel, usando métricas ou DA incorretas.
GRE (assim como PBR) é process switched, porém algumas plataformas suportam GRE em hardware.
Por default, o tunnel permanece UP/UP se houver uma rota para o IP de destino mas não significa que há conectividade fim-a-fim. Para realizar este tracking fim-a-fim devemos habilitar keepalives bidirecionais. Se você não habilitar um protocolo de roteamento confiável no túnel, sempre use keepalives em ambos os lados.
GRE possui mecanismo de proteção default dando menor prioridade para rotas aprendidas dinamicamente através do túnel. O IOS realiza isso utilizando uma BW bem baixa nos túneis (ex: 100Kb) e um delay bem alto (ex: 50000 usec) para que os protocolos de roteamento dêem preferência para as outras rotas apreendidas através de interfaces físicas.
Portanto o principal cuidado é que a interface de destino NUNCA seja aprendida através do túnel. Ambos os roteadores NUNCA devem propagar o endereço de origem do túnel através do próprio túnel. A solução chave neste caso é filtrar tal endereço (ex: para RIP e EIGRP podemos usar distribute-list).
- OBS: O endereço filtrado deve ser da rota divulgada pelo protocolo de roteamento e não o endereço de destino em si (ex: loopback 1.1.1.1/24 será aprendido via EIGRP 1.1.1.0/24).
Interface Backup Confiável com GRE
GRE pode ser utilizado para monitorar link fim-a-fim (principalmente multiponto) usando keepalives bidirecionais. Uma boa solução utilizada para sistemas mais antigos onde outras soluções não são suportadas.
- Basta configurar origem, destino, keepalives, retries e nem precisa protocolo.
- Ponto negativo é que o tempo de convergência é alto (quase 30 seg).
Primeira opção é “backup interface” configurada no túnel que faz o tracking da interface multiponto, apontando o backup para algum link secundário. Ex: frame relay quando um circuito cai e a multipoint permanece UP… qualquer cenário que não permita confiabilidade fim-a-fim.
Segunda opção é aplicar uma rota estática apontando para o túnel e uma rota flutuante apontando para o link secundário. Ponto negativo é o constante overhead do GRE (cabeçalho, processado em software etc).
Outros túneis:
- GRE encapsula tudo. Necessário para encapsular CLNS (IS-IS).
- Ip in IP é mais eficiente, com cabeçalho menor, mas só encapsula IPV4.
- IPV6-IP só encapsula IPV6.
Comandos Show para IP Routing
ping X sou Y
trace X sou Y
sh arp
sh nhrp (para DMVPNs)
sh ip int bri
sh ip int bri | ex una
sh ip route
sh ip static route
sh ip policy
sh ip int
sh route-map
sh ip sla stat
sh ip sla conf
sh track
sh track bri
sh backup
Esse conteúdo de IP Routing ajuda no dia-a-dia?
Faltou alguma coisa importante?
Fala pra mim nos comentários.
Se gostou do conteúdo, peço para 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