Minha jornada até o CCIE RS — EIGRP

Nesta série de artigos compartilho minhas anotações acumuladas durante 3 anos de estudos até passar no lab de CCIE RS, anos atrás. 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 não somente a 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” e “RIP”. Abaixo segue a parte sobre EIGRP 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 :)

EIGRP

EIGRP não possui tantas funcionalidades e não é tão complicado quanto OSPF e BGP.

Considerado um protocolo híbrido, possui funcionalidades de ambos “link-state” e “distance vector”.

• Forma adjacência como link-state mas ainda usa split horizon como mecanismo de prevenção de loops.
• Algoritmo DUAL garante uma topologia “loop free”.
• EIGRP não tem uma visão geral da topologia. Usa método distance vector “routing by rumor” onde o router só conhece aquilo que os neighbors diretamente conectados estão propagando.

Usa seu próprio protocolo de transporte IP 88 (OSPF é semelhante e usa IP 89). Este protocolo é usado para unicast e multicast.

OBS: Em todo caso, apesar das características link-state e funcionalidades para prevenção de loop, ele ainda é considerado distance-vector.

EIGRP usa multicast 224.0.0.10 para estabelecer adjacências, mas após as adjacências serem estabelecidas, a maior parte da comunicação é unicast para sincronizar a topologia. Quando a topologia converge, multicast é utilizado para updates incrementais e unicast para ACKs.

OBS: Como EIGRP utiliza unicast e muticast, o modo mais fácil de bloquear tráfego é bloqueando IP 88.

EIGRP permite rodar múltiplos processos e o número do AS é significante para toda rede. Portanto podemos ter múltiplos domínios EIGRP rodando na rede inteira.

• OBS: Não confundir com OSPF que permite múltiplos processos mas o número do AS é localmente significante.

OBS: EIGRP usa wildcard mask que é oposto da subnet mask.

EIGRP só propaga as rotas que estão instaladas na tabela de roteamento.

• Este comportamento é o mesmo para RIP e BGP.
• OSPF trabalha todos os links independente da tabela de roteamento.

A recomendação é sempre declarar a rede o mais específica possível para ter controle.

A forma do EIGRP calcular um caminho loop free é utilizar rotas propagadas pelo neighbor com métricas menores que as métricas fim-a-fim do próprio roteador. Isso garante que o neighbor sempre estará mais próximo do destino que o próprio roteador. Isso permite ao EIGRP rotear imediatamente para a próxima melhor rota sem precisar realizar um recálculo completo da topologia.

Auto-Summary

• Assim como RIP v2, EIGRP é classless mas realiza sumarização automática por default.
• VLSM é suportada dentro da mesma rede principal.
• Propagações entre redes principais são resumidas (summaries) em classful, mas não irão resultar em “black holes” porque EIGRP cria discard route para rotas resumidas.

OBS: Neste caso temos a mesma situação do RIP ao misturar 2 redes principais na mesma topologia em que os summaries (resumos) das rotas podem confundir pois o mesmo summary pode vir de locais diferentes. Porém com o EIGRP não ocorre loops por causa da Discard Route.

Split Horizon

No EIGRP, o Split Horizon não é utilizado para prevenção de loops (função da Feasible Condition), mas para melhorar a convergência. Obviamento isso acontece porque não há necessidade de divulgar uma rota para um neighbor e receber de volta esta mesma rota. O único cenário onde isto é válido é em topologias “NBMA partial mesh”.

EIGRP habilita split-horizon em todas as interfaces por default.

OBS: Desabilitar o split-horizon não vai causar loop na topologia por causa da Feasible Condition do DUAL. Portanto, o split-horizon no EIGRP apenas descarta as rotas logo de cara que não usaria.

Tipos de Updates

• Usa multicast 224.0.0.10 para HELLO, QUERY, UPDATE
• Usa unicast para UPDATE, ACK, REPLY

OBS: Como EIGRP usa multicast e unicast protocolo IP 88, precisa tomar cuidado para não bloquear. Ex: podemos permitir somente unicast e esquecer multicast, ou vice-versa.

OBS: Comando <neighbor> habilita unicast e desabilita por completo o multicast para EIGRP (Diferentemente do RIP que continua trabalhando em multicast). Portanto o comando <neighbor> no EIGRP precisa ser habilitado para todos os neighbors deste determinado segmento.

<passive-interface> desabilita unicast e multicast na interface, portanto não há adjacência em links passive. Geralmente é utilizado na camada de acesso por segurança.

OBS: Tanto no lab quanto em produção, sempre enviar os logs para o buffer porque pode sobrecarregar a console.

OBS: Para bloquear algum tráfego de forma transparente podemos utilizar ACL ou VLAN ACL no SW L2.

OBS: Para o lab CCIE, é interessante memorizar os números dos principais protocolos IP porque não é fácil de achar na documentação.

OBS: Prestar atenção porque o troubleshooting mais complicado é justamente quando se estabelece adjacência mas não prossegue trocando informações sobre a topologia. O neighbor aparece na lista e o queue count permanece > 0.

OBS: Comando <passive> impede a formação de qualquer adjacência (multicast e unicast), portanto não deve ser utilizado em conjunto com <neighbor>.

Timers

• Hello — frequência de envio de hellos no link.
• Hold-time — quanto tempo o neighbor deve esperar para declarar o router down (repare que é um padrão diferente).

No EIGRP os timers não precisam ser iguais entre os neighbors para formar adjacência. Mas normalmente não há motivos para usar timers diferentes.

• Hello
• — Low-speed e NBMA — 60 seg
• — Demais — 5 seg
• Hold-time
• — Low-speed e NBMA — 180 seg
• — Demais — 15 seg

Autenticação

Muito parecido com o sistema de autenticação do RIP. A principal diferença é que só aceita MD5 (não aceita clear text).

Usa sistema de key chain (igual ao RIP) porém as key chains devem ser iguais entre os neighbors porque são trocadas nos pacotes.

• “ignored packet from… (authentication off or key chain missing)”
• “ignored packet from… (invalid authentication)”

EIGRP suporta key rotation baseado em tempo (data e horário). Para isso os relógios dos roteadores precisam estar sincronizados ou os roteadores podem jogar as keys em pontos diferentes no tempo e irão falhar na autenticação.

• OBS: Assim como no RIP, espaços contam como caracteres.

Para sincronizar os relógios dos roteadores podemos ajustá-los manualmente ou usar protocolo NTP. Estranhamente o tempo de sincronização do NTP pode levar vários minutos dependendo da versão de IOS e se os horários estão muito distantes (ex: 10 anos de distância entre os horários).

OBS: Recomendação é ajustar os relógios com horário real (mesmo manualmente) porque isso facilita a verificação e troubleshooting.

Recomendação é sempre ajustar um tempo de sobreposição entre as key chains e ajustar <send> e <accept lifetime> a este tempo de sobreposição. Se houve uma mínima diferença (de segundos) entre o tempo de accept e send dos roteadores, o EIGRP não estabelece (ou pior, interrompe) a adjacência por falha de autenticação.

Path Selection

EIGRP escolhe o caminho com menor métrica composta baseada em:

• Bandwith — valor inverso da menor largura de banda ao longo do caminho, escalado por (10⁷) x 256
• Delay — delay cumulativo ao longo do caminho em dezenas de microsegundos (µs) escalado por 256
• Load — maior carga ao longo do caminho
• Reliability — menor reliability ao longo do caminho

Fórmula da métrica composta = [K1*BW + (K2*BW)/(256 — load) +K3*Delay] *[K5/(Reliability*k4)]

• Na fórmula da métrica, os valores K permitem uma administração manual do peso de cada variável.
• Os valores default para K são K1=1, K2=0, K3=1, K4=0 e K5=0.
• Os valores K devem ser os mesmos para todo roteador no domínio EIGRP (para que as adjacências ocorram).

OBS: Recomendação para manipular rotas é sempre usar delay porque é hop-by-hop. Se usar BW temos que considerar todos os segmentos ao longo do caminho independentemente.

DUAL — Diffusing Update Algorithm

Algoritmo do EIGRP para troca de informações de roteamento e cálculo da melhor métrica fim-a-fim.

Termos usados no EIGRP:

• Successor — como é chamado o melhor caminho para o destino, a própria rota instalada na RIB.
• Feasible Distance (FD) — é a métrica para o melhor caminho (successor).
• Feasible Successor (FS) — é a rota backup pré-calculada e livre de loops para um determinado destino.
• Advertised Distance (AD) — métrica composta aprendida do upstream neighbor (é a FD do neighbor).
• Local Distance (LD) — métrica composta para o upstream neighbor.
• Feasibility Condition (FC) — critério para validar caminhos backup.

1. Toda atualização inclui a métrica do upstream neighbor para determinado destino (AD).
2. O router já conhece a métrica para alcançar este upstream neighbor (LD).
3. O router então determina o Successor escolhendo a melhor métrica AD + LD.

Feasibility Condition (FC)

Depois que o melhor caminho para cada destino é escolhido, o DUAL examina os caminhos adicionais como potenciais rotas backup.

FC determina rotas backup loop free através da lógica AD < FD. Essa lógica trabalhada por todos os routers do domínio EIGRP garantem que os caminhos são loop free e seus possíveis backups, porque os upstream neighbors precisam obrigatoriamente estarem mais próximos do destino.

Caminhos que satisfazem a FC são chamados Feasible Successors (FS). Somente os FS podem ser usados para Unequal Cost Load Balance.

OBS: Ponto chave na arquitetura de uma topologia usando EIGRP é garantir que todo Successor tenha pelo menos um FS garantindo alta disponibilidade sem necessidade de recálculo completo da topologia.

Traffic Engineering

Para EIGRP, a BW leva em conta a menor bandwidth por prefixo ao longo de todo o caminho. Afinal “uma corrente tem a força do elo mais fraco”.

Delay é um valor cumulativo em uma base hop-by-hop.

Portanto na maioria dos cenários a solução mais simples para manipular rotas é alterar o delay porque é muito difícil prever o que a mudança de BW irá afetar (pode não afetar nada).

• OBS: Diferente do OSPF onde o custo está diretamente associado a BW do segmento e pode-se alterar os custos numa base hop-by-hop.

Por default, Load e Reliability (packet loss) não são usados no cálculo da métrica porque eles mudam baseados na condição da rede. Como as condições geralmente se alteram constantemente, o EIGRP permaneceria sempre recalculando. Este comportamento torna o EIGRP um real time routing protocol, o que pode parecer bom a princípio, mas que na realidade não escala (+routers -> +condições -> +reconvergências).

Unequal Cost Load Balance

EIGRP é o único protocolo de roteamento que permite distribuição de carga entre caminhos desiguais.

Apenas os FS participam da seleção na seguinte lógica:

FD x Variance > FS

Assim que os FS candidatos são eleitos, o EIGRP calcula a taxa de compartilhamento de tráfego e usa os links eleitos de forma proporcional a suas métricas compostas.

• OBS: Lembrando que o balanceamento de carga é controlado na realidade pelo switching path.

Independente do valor da variance (variância) (10.000 etc) ela não define o traffic share, apenas os candidatos ao traffic share. Lembrando que só FS participam da seleção.

OBS: É possível testar a variância loggando estatísticas do tráfego através de ACLs no caminho e habilitar “per packet load sharing”. Não é recomendado utilizar balanceamento por pacote em ambientes reais porque muitas aplicações sensíveis (como voip) não suportam este comportamento.

Escalabilidade

Principal ponto para escalabilidade do EIGRP é atingir rápida reconvergência para rotas backup através de rotas backup (FS) para cada prefixo.

Se não há rotas backup, mensagens QUERY são enviadas a todos os neighbors solicitando caminhos alternativos para cada determinado prefixo.

Principal problema das QUERIES é que precisa esperar a resposta de todos os neighbors para retirar a informação antiga da topologia e recalcular o novo cenário. Quando a resposta não é recebida, por qualquer motivo, dentro do período acordado o prefixo entre em “Stuck in Active” (SIA) e pode resultar no término e restabelecimento da adjacência. Portanto a perda de um prefixo pode resultar na perda de inúmeros prefixos.

Segundo ponto para escalabilidade de EIGRP é segmentar o domínio de QUERY. Pode-se realizar isso através de sumarização e uso de roteadores stub.

Sumarização

• Sumarização no EIGRP é realizada diretamente na interface (similar ao RIP).
• Pode-se usar qualquer mask, inclusive ultrapassar redes principais (diferente do RIP).
• Sumarização suprime o envio de subredes, porém estas subredes podem ser propagadas com uso de leak-maps.
• Usa DA 5 por default e permite o uso de resumos flutuantes.
• A sumarização gera automaticamente uma discard route, que é uma rota apontando para NULL 0.
• A DA da discard route pode ser alterada e até removida usando DA 255.

O objetivo da discard route é, no caso do router perder informação sobre algum prefixo, prevenir contra o envio do tráfego para um neighbor sem informações sobre este prefixo (geralmente um neighbors que propaga uma sumarização mais ampla ou rota default).

Sumarização + leak-map são ótimas ferramentas para traffic engineering propagando rotas mais longas (leaks) e mais curtas (resumos).

Lembrando que os routers irão escolher sempre o longest match, traffic engineering no EIGRP funciona basicamente com: summaries (resumos) + leaks +alterações das DAs.

Stub Router

Router se divulga como Stub Router para os upstream neighbors evitando que os neighbors enviem QUERY messages sobre prefixos de outras partes da rede, geralmente utilizado nos roteadores de acesso.

• OBS: neste caso o router ainda enviar QUERY sobre prefixos perdidos, mas não recebe.

O uso de stub router serve para reduzir (geralmente 1 hop) o tamanho do query domain e para prevenir que o router seja um router de trânsito.

A configuração stub permite controlar que tipos de prefixos são propagados e uso de leak-maps.

OBS: EIGRP suporta a declaração de prefixo que faça match de uma rota causando a divulgação (“redistribuição”) desta rota como interna, ao invés de externa, garantindo assim maior preferência.

ip route x.x.x.x -> network x.x.x.x -> router stub static

Os 2 pontos para escalabilidade do EIGRP são:

• Existem rotas backup (FS) para todos os prefixos?
• Qual o menor tamanho possível para o query domain?

Default Routing

Roteamento default no EIGRP pode funcionar através de <default network> ou <default information>.

Default Network é uma compatibilidade anterior com IGRP que suportava apenas a flag e campo de default network (não suporta 0.0.0.0/0).

<default network> deve ser aprendida através do EIGRP (portanto não pode estar diretamente conectada) e ser classful.

Rota Default (0.0.0.0/0) pode ser propagada via:

• Sumarização direta na interface
• Redistribuição de uma rota estática ou outro protocolo
• Aplicar rota default estática para interface diretamente conectada (mas sem next-hop) +declarar 0.0.0.0 no processo EIGRP.

OBS: Em ambos os casos, redistribuir uma rota estática default para uma interface diretamente conectada (sem next-hop) é entendido pelo EIGRP como sendo uma rota interna (DA 90).

OBS: Redistribuir rota default como interna (DA 90) ou externa (DA 170) só faz diferença quando temos múltiplas rotas e queremos manipular preferências.

Filtering IN

• Distribute-list no EIGRP funciona de forma similar ao RIP.
• ACL padrão e estendida possuem limitação e não conseguem distinguir o tamanho do prefixo (mask) (igual ao RIP) porque foram desenhadas para filtrar data plane.
• Prefix-list é uma implementação bem melhor porque foi desenhado para trabalhar com informações de roteamento (control plane).
• Offset-list é usado para aumentar a métrica além do limite (igual ao RIP, com a diferença que a métrica é muito maior) impedindo a rota de ser instalada na tabela de roteamento.
• Distância administrativa pode ser alterada por prefixo e por neighbor (255 = infinito).
• EIGRP suporta o uso de route-map diretamente no distribute-list filtrando por métrica e tipo de prefixo (TAG).

Filtering OUT

• Distribute-list usando ACL ou prefix-list
• Offset-list
• Passive interface desabilitando adjacências
• Route-map aplicado diretamente no distribute-list

Router-ID

No EIGRP o router-id só é utilizado em rotas externas como mecanismo de prevenção contra loops. No caso de uma rota redistribuída por determinado router no EIGRP retornar para o mesmo router com uma DA mais baixa que o protocolo de origem da rota, esta rota seria aprendida pela tabela de roteamento e poderia gerar um loop. Para evitar isso, EIGRP não aceita rotas com seu próprio router-id.

• OBS: Obviamente para que isso ocorra, a DA da rota externa deve ser diminuída (porque 170 é maior que qualquer IGP).

Router-ids duplicados podem gerar black holes na topologia porque routers descartarão rotas externas.

OBS: É uma best practice definir explicitamente o router-id de todos os protocolos: EIGRP, OSPG, BGP, MPLS, etc.

OBS: O Router-id é utilizado para descobrir quem é o originador do prefixo para OSPF (na construção do grafo) e BGP (na prevenção de loops).

EIGRP Named Mode (ou Multi-AF)

• Modo antigo é conhecido como EIGRP classic mode.
• A principal mudança é a melhor hierarquia da config, onde toda config vai no processo global.
• Também há melhor separação das configs IPv4 e IPv6 porque ambas são unificadas dentro do mesmo processo e separadas por AFs (address-families).
• As novas features mais importantes são:
• — IPv6 VRF lite
• — Wide-metrics

Config:

1. Habilitar processo <router eigrp [NAME]> onde o NOME não é o AS number (AS é configurado no AD)
2. Habilitar AF <address-family ipv4 autonomous-system X> — AS é configurado no AF
3. Habilitar processo na interface <net [address] [wildcard]> — Similar ao OSPF
4. Customizar interfaces <af-interface [default | int]>

Topology-base é a global table, incluindo todas as interfaces, tudo relacionado ao processo.

OBS: <af-interface default> se aplica a todas as interfaces (mais prático né).

OBS: Basicamente tudo fica abaixo de topology base e af-interface.

EIGRP multi-af permite multi-topology routing com múltiplas instâncias do EIGRP.

Config <>address-family ipv4 as X” (não mostra o atalho mas existe)

EIGRP multi-AF utiliza wide-metrics acordada e calculada automaticamente entre os peers. FD é calculada e a partir dela é gerada a métrica na RIB (não utiliza a FD diretamente).

• Mede delay em picoseconds ao invés de usec, levando em conta links tengig.

Conversão automática de configuração: Executa graceful restart automático. <(router) eigrp upgrade-cli NAME>

OBS: Graceful restart (standard) é non-stop forward (Cisco).

IPv4 e IPv6 — suporta ambos, podendo estar em ASs diferentes.

Obviamente EIGRP named-mode suporta múltiplos ASs dentro do mesmo EIGRP [NAME] porque nome é um atributo local.

Wide Metrics

Métrica no classic mode:

• Custo mínimo é 256 para 10 giga
• Delay mínimo (1) é 10 usec
• Com bandas mais rápidas, visibilidade de custo e delay são perdidos

Métrica no named mode:

• Wide metrics é de 64 bits
• BW usa um fator de escala maior
• Delay usa escala em picoseconds
• Métrica é derivada da FD usando escala da RIP 1/128 (default) — <(eigrp) metric rib-scale >

Autenticação no Named Mode

Suporta MD5 e SHA

• MD5 usa key chains como EIGRP clássico
• SHA usa key estática e portanto não suporta automatic key rotation. SHA é mais seguro que MD5.
• OBS: Se EIGRP estiver habilitado em modo named e configurar algum parâmetro na interface, uma mensagem de erro alerta que não é possível (ou pelo menos deveria, porque não funciona).

Sempre use <sh key chain> para verificar senha em modo texto, sem hash.

Autenticação é definida na af-interface

• af-interface default
• af-interface específicas sobrepõem a default

EIGRP sobre DMVPN

• Principal problema é o Split Horizon
• — OBS: Split Horizon não é desejado em redes partial mesh NBMA (Ex:DMVPN).
• EIGRP processa next-hop diferente dos outros protocolos

OBS: Redistribuir com métrica 1 1 1 1 1 no modo novo (named) não é mais permitido porque escala para um valor muito baixo e EIGRP mapeia para infinito.

OBS: <sh ip ei topo all> — mostra todas as opções incluindo as rotas sem FSs. Importante na hora de ajustar as métricas desejadas.

DMVPN não suporta multicast diretamente, ela encapsula o multicast dentro do unicast e replica para cada peer. Portanto, melhor cenário é usar rota default para todos os spokes e não precisar replicar nada.

Processo de Next-Hop

• Updates EIGRP incluem Next-hop Forwarding Address (o next-hop para a rota).
• Se o next-hop forwarding address é 0 usará o IP do cabeçalho, ou seja, IP do neighbor conectado que enviou a rota.
• Onde não usar? Third party next-hop (ex: DMVPN phase 2)

Na DMVPN phase 2, os spokes precisam do next-hop dos demais spokes. Portanto o HUB não deve alterar o “forwarding address” <no next-ho-self> quando desabilitar o Split Horizon.

EIGRP é o IGP preferido para DMVPN porque suporta hierarquia de roteamento (summaries).

• OBS: OSPF não permite isso porque todos os spokes e hub precisariam estar na mesma área e se algum deles flappar, todos precisariam recalcular SPF.

Config Phase 2 (no hub):

• <no split-horizon>
• <no next-hop-self>

Config Phase 3:

• Hub — <ip nhrp redirect>
• Spoke — <ip nhrp shortcut>

OBS: Spoke não estabelecem adj entre si porque DMVPN não suporta multicast diretamente. Portanto não pode encaminhar tráfego multicast diretamente entre Spokes. Não tem como, não insista 😞

OBS: Se DMVPN utilizar OSPF o tunnel deve utilizar modo network broadcast.

DOC: Na Design Zone, busque em “Cisco Validated Design Program” pelos DMVPN Design Guides.

Comandos Show para EIGRP

sh ei prot = sh ip prot | se eigrp

sh ip prot

sh ip ei int

sh ip ei int det X

sh ip ei nei

sh ip ei nei det

sh ip route ei

sh ip cef x.x.x.x

sh ip ei topo = sh ei ad ipv4 X topo

sh ip ei topo x.x.x.x y.y.y.y

Esse resumo sobre EIGRP te ajudará 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