Olá galera, tudo bem?
Vamos para mais um artigo na minha série compartilhando anotações acumuladas durante os anos de estudos até o CCIE Routing and Switching, anos atrás. Lembrando que foram centenas de páginas de cadernos com muitas informações e observações que considerei e ainda considero importantes, depois de 15 anos trabalhando com R&S.
Meu objetivo é ajudar não apenas 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, seguem os links dos artigos anteriores sobre Switching e PPP. Neste segundo artigo vamos explorar “Roteamento IP” 😉
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.
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.
Leia o resto do artigo no link abaixo:
Se gostou do conteúdo, peço que informe que o conteúdo foi útil aqui na Comunidade Cisco, clicando em "útil" ao final do post.
1 Comentário
