Minha jornada até o CCIE RS — Redistribuição

Esta série de artigos compartilha minhas anotações acumuladas durante vários anos de trabalho e estudos até passar no lab de CCIE RS, anos atrás. Foram quase 400 páginas de caderno com informações e observações que considerei importantes ao trabalhar com Routing and Switching quase 15 anos.

Acredito que estas informações ajudam mais do que passar em certificações, mas no dia-a-dia de outras pessoas (assim como eu) ao lidar com infraestrutura Cisco.

Para quem não leu os artigos anteriores, seguem os links sobre “Switching”, “PPP”, “IP Routing”, “RIP”, “EIGRP” e “OSPF”. Abaixo segue a parte sobre Redistribuição.

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

Redistribuição

Redistribuição ocorre a partir da tabela de roteamento e não a partir da database dos protocolos.

Durante a redistribuição os protocolos IPv4 consideram:

• As rotas dinâmicas aprendidas através de um protocolo (<ex: sh ip route eigrp>)
• Incluem implicitamente prefixos das interfaces conectadas rodando este protocolo (<sh ip prot>). No IPv6 isso não é implícito. Esse comportamento nem sempre é desejado quando o objetivo é conectividade entre as edge networks (não necessita de acesso as redes do core).

OBS: EIGRP ou RIP não divulgam rotas que não estão na RIB. OSPF divulga rotas mesmo que não esteja usando. Isto significa que se um router participar de domínios RIP/EIGRP e receber um determinado prefixo através de interface com OSPF habilitado, ele interrompe a divulgação deste prefixo no domínio EIGRP/RIP. Este comportamento é padrão para distance vector.

Durante a escolha de rotas iguais entre processos diferentes do mesmo protocolo (ex: OSPF 11 e OSPF 15) a RIB sempre favorece o protocolo com menor PID.

• OSPF com menor PID
• EIGRP com menor AS

Connected

• Redistribuição connected ocorre implicitamente para links rodando um protocolo redistribuído. Ou seja, ao redistribuir o protocolo A no B, as interfaces conectadas ao protocolo A são redistribuídas implicitamente.
• Redistribuição connected explícita sobrepõe a implícita. Ou seja, ao redistribuir explicitamente interfaces conectadas, desabilitamos a redistribuição implícita.

Distâncias Administrativas

• 0 — Connected
• 1- Static
• 5 — EIGRP Summary
• 20 — External BGP
• 90 — Internal EIGRP
• 110 — OSPF
• 115 — ISIS
• 120 — RIP
• 160 — ODR
• 170 — External EIGRP
• 200 — Internal BGP
• 255 — Infinito

Seed metric

É a métrica assinalada por default às rotas redistribuídas quando nenhuma métrica é configurada manualmente. Cada protocolo de roteamento tem sua própria seed metric e só é importante se houver mais de um caminho para o destino.

http://packetlife.net/blog/2008/nov/07/redistribution-seed-metrics/

Redistribuição no RIP

É a mais complicada porque o RIP não diferencia entre rotas internas e externas e atribui a mesma DA 120 para todas as rotas.

Outro problema importante é que o RIP não possui seed metric default. Portanto, se não declarar a métrica do protocolo redistribuído explicitamente as rotas não vão pra RIB.

OBS: As rotas redistribuídas devem aparecer na DB (database) do protocolo de destino e este deve ser o primeiro lugar a ser verificado.

Redistribuição no EIGRP

EIGRP diferencia rotas internas (DA 90) de rotas externas (DA 170). Esta DA alta previne contra route feedback.

Outra funcionalidade de segurança é que o EIGRP usa o router-id para prevenir contra loops de rotas externas, descartando rotas recebidas que ele mesmo originou (mesmo router-id).

• OBS: EIGRP permite que routers com mesmo router-id formem adj, mas não permite que troquem rotas entre si.
• OBS: OSPF já não permite formar adj entre routers com mesmo router-id (aparece “FLOOD WAR”).

OBS: Sempre estabeleça router-id manualmente para EIGRP, OSPF, BGP.

EIGRP também não possui seed metric default (como RIP) e somente troca métricas automaticamente entre outros processos EIGRP (<#(eigrp)default-metric>).

Redistribuição no OSPF

Embora distingua entre rotas internas e externas, OSPF utiliza DA 110 para todas as rotas. Porém é possível especificar manualmente DA para internas e externas.

Usa o router-id para prevenir contra loops, não estabelecendo adjacência e descartando rotas (LSAs) de routers com mesmo router-id. Mas isso não é uma grande preocupação porque OSPF não é distance vector.

Preferência de seleção OSPF:

• O -> O IA -> E1 -> N1 -> E2 -> N2
• Entre (E1 e N1) e (E2 e N2) tem preferência a rota com melhor “forward metric” até o ABR/ASBR.

Portanto, no OSPF a métrica só importa quando tivermos mais de uma rota de mesmo tipo (1 ou 2) para o mesmo prefixo.

Por default, OSPF usa Type E2 (normal) ou N2 (NSSA) e seed metric 20.

• Rotas E1/N1 usam metric + forward metric.
• Rotas E2/N2 usam apenas metric, mas comparam forward metric em caso de empate.

É possível criar engenharia de tráfego no OSPF manipulando os tipos das rotas entre E1/N1 e E1/N2 porque as rotas do tipo 1 sempre terão preferência independente da métrica.

OBS: Para checar se redistribuição aconteceu no OSPF basta checar database por LSA tipo 5.

Redistribuição no BGP

BGP diferencia entre rotas internas e externas utilizando o código ORIGIN Internal (i) para rotas internas e Incomplete (?) para redistribuídas.

Durante redistribuição, os mecanismos normais de prevenção de loop são utilizados. EBGP neighbors descartam rotas com seu próprio AS no AS PATH enquanto iBGP neighbors não reencaminham rotas recebidas de outros iBGP.

IGP -> BGP

Por default, BGP nega rotas externas OSPF evitando possível loop BGP -> OSPF -> BGP. Isto só se aplica a OSPF. Estas rotas externas podem ser manualmente permitidas (se o ambiente for livre de loops, claro) <redist ospf X match internal external> (default é somente internal).

BGP -> IGP

Ao redistribuir BGP no IGP, por default somente rotas EBGP são permitidas e rotas iBGP são negadas. Esse comportamento pode ser alterado (<bgp redistribute internal>) mas dificilmente é seguro fazer isso porque ao redistribuir do iBGP (DA 200) para qualquer IGP (DA mais baixa), roteadores que aprenderem via IGP irão invalidar as rotas do iBGP e rotear incorretamente.

OBS: Rotas BGP redistribuídas em qualquer IGP recebem automaticamente uma TAG com o número do AD. Portanto, podem ser filtradas com route-map.

OBS: Router-id é apenas um número de 32 bits e não precisa ser roteável (ex: 1.2.3.4) mas normalmente é uma loopback.

Redistribuição — Continuação

Os protocolos redistribuem por default as rotas na tabela de roteamento + interfaces conectadas rodando o protocolo redistribuído.

Ao usar <redistribute connected> é necessário especificar todas as interfaces a serem divulgadas porque sobrepõe a redistribuição implícita das interfaces conectadas rodando um protocolo redistribuído (ex: redistribuir loopback e mais nenhuma outra). É legal para bloquear a divulgação da interface original rodando o protocolo ou até mesmo para não divulgar nenhuma interface interessante!!!

OBS: Assim como ACL ou prefix-list, route-maps também têm deny implícito.

TCL Script

Tool Command Language (TCL) é uma linguagem de script open source.

É um método rápido de determinar se há conectividade para quais destinos e para quais não há.

IOS da Cisco suporta versão 8.3.4 geralmente utilizado durante redistribuição para checar conectividade com Scripts. Durante execução dos pings (comandos), o prompt aguarda a conclusão do ping antes de enviar o próximo e portanto não sobrecarrega a console.

DOC: IOS Scripting with TCL Configuration Guide

Livro: TcL Scripting for Cisco IOS

OBS: Ao terminar de usar TCL sempre saia do processo TCL <#tclquit> porque o parser TCL tem precedência sobre o IOS parser, podendo dar erros com comandos semelhantes.

Routing Loops

Redistribuições causam loops de roteamento devido a perda de informação fim-a-fim por algum motivo. Isso acontece porque os algoritmos de roteamento são incompatíveis (ex: EIGRP e OSPF).

Loops não podem ocorrer quando há apenas um ponto de redistribuição porque o processo de roteamento interno do router previne isso.

Único problema de loop com redistribuição ocorre quando há múltiplos pontos de redistribuição mútua. Neste caso o caminho errado possui métrica melhor que o caminho correto (mesmo protocolo) ou possui DA melhor que o caminho correto (entre diferentes protocolos).

Para identificarmos loops de roteamento devemos traçar visualmente o caminho de propagação da rota e sermos capazes de prever os problemas de roteamento que podem ocorrer. O ideal é saber de cabeça em que parte da rede e entre quais protocolos pode dar problema. Loops de roteamento podem ser muito difíceis de diagnosticar e consumir muito tempo.

Ordem das principais ferramentas para troubleshooting de loops:

• <traceroute>
• Testes de conectividade via TCL
• <ip route profile> coleta estatísticas da tabela de roteamento
• <debug ip routing> (melhor ferramenta!)
• Loops baseados em métrica são os mais fáceis de corrigir simplesmente filtrando as rotas nos pontos de distribuição (Ex: ACL, prefix-list ou tag-filtering).
• Loops baseados em DAs na grande maioria dos casos só são corrigidos alterando a DA.

Durante o processo de redistribuição a RIB pode apresentar falhas de informação. Quando for este o caso deve-se repopular a RIB <clear ip route *>.

Mesmo que as rotas não estejam instaladas na RIB, as databases devem informar tudo sobre elas.

O valor da DA dos protocolos é localmente significante (esta informação não é propagada) e portanto quando temos dois protocolos, pode-se elevar o mais baixo ou baixar o mais alto (é a mesma coisa).

Ao realizar traceroute para um destino inacessível, o último hop com sucesso não tem rota para frente ou o próximo router não tem rota de retorno.

OBS: No OSPF, ao redistribuir caminhos para diferentes protocolos podemos usar E1 e E2 para identificar de onde veio.

OBS: No EIGRP, quando a FD é infinita (inaccessible) mas a métrica é menor (bem menor) significa que o prefixo foi aprendido mas por algum motivo não foi instalado na RIB.

Ao redistribuir, sempre devemos montar o mapa da redistribuição hop-by-hop. Não existe regras gerais para resolver os problemas.

Roteadores com interfaces em OSPF/EIGRP e mais de uma interface em RIP/EIGRP podem apresentar problemas porque RIP/EIGRP não propagarão rotas que não estejam instaladas na RIB (caso aprendam as mesmas redes via melhor DA).

Loops de Data-plane

• Baseado em métrica.
• Control-plane está estável, porém pacotes trafegam na direção errada.
• Geralmente é mais fácil de detectar porque não há conectividade nenhuma (pacote é reencaminhado até o TTL expirar).

Loops por métrica não devem ser resolvidas alterando as seed metrics (até pode), mas preferencialmente filtrando as rotas redistribuídas de retornarem ao domínio anterior, usando TAG, ACL ou prefix-list.

• Principais ferramentas de diagnóstico são ping e traceroute.

OBS: Redistribuição no OSPF não é determinística. O ABR que redistribuir primeiro será o ponto de saída.

OBS: RIP/EIGRP sempre redistribuem da tabela de roteamento (RIB), portanto sempre checar com <sh ip route rip/eigrp> o que será de fato redistribuído.

Loops de Control-Plane

• Baseado em AD.
• Rotas entram e saem da RIB infinitamente.
• Chamado de “counting to infinity”.
• Pode resultar em conectividade parcial, onde os pacotes são entregues durante o período em que a rede convergiu corretamente e depois voltam a ser descartados.
• Corrigido geralmente manipulando AD.

Loops por DA geralmente são mais difíceis de diagnosticar porque causam route feedback e as rotas são adicionadas e deletadas da tabela de roteamento infinitamente. Quando é o control plane que permanece instável, é mais difícil descobrir quem é o problema. Geralmente ocorrem quando há one-way redistribution em múltiplos pontos

• Principais ferramentas de diagnóstico neste caso são debug <debug ip routing> e route profile <ip route profile>. Com as tabelas alterando constantemente, ping e traceroute não trarão informação correta e também não irão apontar onde está o problema porque os resultados mudam constantemente.
• <ip route profile> apresenta estabilidade da rede através das estatísticas das mudanças na tabela de roteamento (não aponta onde está o problema, mas mostra que há um).
• O problema pode ser analisado e apontado através do <debug ip routing>.

OBS: Obviamente em ambiente de produção a saída dos debugs deve ir para o buffer para não sobrecarregar a console.

OBS: É preciso aprender a desabilitar as interfaces corretas forçando a convergência a partir do ponto de redistribuição (ABR ou ASBR) correto. Portanto a ordem das operações durante a redistribuição é importante.

Evitando Loops

• Proteger rotas com AD mais alta no roteador onde 2 protocolos se encontram.
• Rotas com AD mais alta podem retornar através de protocolo com AD mais baixa.

“Alguns loops relacionados a métrica não podem ser resolvidos alterando a distância (DA). Alguns loops relacionados a distância não podem ser resolvidos alterando a métrica.”

É possível trabalhar e manipular tags entre as redistribuições através de route-maps relacionados em distribute-lists (OSPF e EIGRP carregam a tag de origem durante redistribuição).

OBS: Tags podem resolver todos os problemas relacionados à métrica, mas nem todos relacionados a DA.

A MELHOR maneira (100% garantida) é dar prioridade para rotas externas (DA baixa) e negar o retorno das rotas com filtros.

OBS: O router que gera e retira o update é aquele que apresenta closer admin distance no <debug ip routing>. Os demais routers apenas recebem o update e withdrawn.

Esse tópico sobre redistribuição é importante no dia-a-dia?

Faltou algum ponto importante?

Fala pra gente 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 grandes e médias empresas. linkedin.com/in/giulianobarros