(Tudo seria mais fácil se fossem outros termos)
O EIGRP não é um protocolo muito complicado, já falamos um pouco dele neste post, e agora vamos ver mais detalhes de como ele funciona.
No decorrer deste post vamos usar a topologia abaixo como exemplo.
Neighbor e Topology Table
A Neighbor Table é a tabela com informações dos roteadores adjacentes. São armazenados o IP e a interface de cada vizinho, além do HoldTimer anunciado por eles e informações usadas pelo RTP, como número de sequência dos “pacotes confiáveis”.
A coluna H mostra o ID associado a cada neighbor do roteador. Address e Interface mostram o IP do neighbor e a interface onde ele está conectado. Hold e Uptime mostram quanto tempo o neighbor tem para enviar um “pacote confiável” e há quanto tempo a adjacência foi estabelecida.
SRTT (Smooth Round Trip Time) é o tempo entre enviar um “pacote confiável” e receber a confirmação.
Pacote confiável = Update, Query, Reply, SIA-Query, or SIA-Reply
O RTO – Retransmit Time Out, é o tempo que o roteador aguardará pela confirmação de um pacote unicast retransmitido após a entrega anterior não ter sido confirmada. Se o RTO expirar antes de um ACK ser recebido, outra cópia do pacote é enviada. Assim como no SRTT, o tempo é mostrado em milissegundos.
O Q Cnt indica o número de pacotes que foram preparados para envio/enviados, mas para os quais não foram recebidos ACKs. Em uma rede estável, o valor Q Cnt deve ser zero. E por fim o Seq Num, que mostra o número de sequência do último “pacote confiável”.
Já a Topology Table é onde o EIGRP armazena as informações de roteamento, incluindo o prefixo de cada rede conhecida, Feasible Distance para os destinos, endereços dos roteadores vizinhos e a interface de saída para cada neighbor.
Cada rede na Topology Table pode ter o estado Passive, significando que o caminho mais curto para a rede já foi encontrado, ou pode ter o estado Active, quando o EIGRP está buscando a melhor rota para a rede.
Reported Distance e Computed Distance
Reported Distance (RD) corresponde a distância (métrica) do vizinho até o destino anunciado. Podemos ver a métrica deste vizinho até o destino usando os comandos sh ip eigrp topology, sh ip eigrp topology all-links ou ainda sh ip eigrp topology A.B.C.D/nn. O RD é o número entre parênteses, depois da ”/”, nos outputs destes comandos.
A Computed Distance (CD) corresponde ao RD + o custo do link entre o roteador e seu vizinho. O CD é o número antes da barra, também entre parênteses, nos mesmos comandos citados acima.
Considerando nossa topologia de exemplo, temos 4 caminhos de R1 para as redes 10.2.X.0/24. Vamos olhar a rede 10.2.0.0 especificamente.
R2 e R3 tem o mesmo custo (281632) para chegar à rede 10.2.0.0, mas R1 tem custo menor para chegar à R2 do que à R3 (isso porque o delay na interface eth0/0 de R1 é 100, e na eth0/1 é 110).
O objetivo do EIGRP, assim como dos outros protocolos de roteamento dinâmico, é encontrar o caminho com menor custo para cada destino. Assim, a rota com o menor CD é colocada na tabela de roteamento.
Lembre-se que o EIGRP faz o balanceamento automaticamente entre rotas com o mesmo custo, e poderia fazer o balanceamento entre caminhos com custos diferentes, se fosse configurado para isso.
DUAL e Feasible Condition
O Diffusing Update Algorithm (DUAL), é o algoritmo usado pelo EIGRP para convergência da rede. Ele incorpora mecanismos para garantir a escolha de caminhos sem loop, e seleciona as rotas que devem ser colocadas na tabela de roteamento.
Esta parte é um pouco confusa, acredito que mais por causa dos termos utilizados do que pelo funcionamento em si.
-
Feasible Distance: Tanto o CD quanto o RD são as métricas atuais para o destino. Já o Feasible Distance é o registro da menor métrica para cada destino, desde a última vez que a rota foi computada (passou de ativa para passiva). Esta informação tem valor apenas local e nunca é anunciada.
-
Feasible Condition: É a regra que garante que o caminho pode ser usado sem formar loop de roteamento. A condição é a seguinte: um neighbor que anuncia um a rota com RD menor do que meu Feasible Distance, é um caminho seguro (sem loop) para o destino.
-
Feasible Successor: Todo vizinho que atende a Feasible Condition (sabidamente um neighbor que pode ser usado para alcançar um destino sem provocar loop), é considerado um Feasible Successor.
-
Successor: Dentre os Feasible Successors, o vizinho (ou os vizinhos) com o menor CD (Computed Distance) será considerado Successor.
De volta ao nosso exemplo, podemos confirmar que R2 e R3 são Feasible Successors, isto é, atendem a Feasible Condition. E R2 é o Successor, neighbor com menor custo para o destino.
Usando o comando show ip eigrp topology, sem especificar a rede, também podemos validar que apenas R2 e R3 passaram na Feasible Condition.
Importante notar que roteadores que atendem a Feasible Condition são roteadores que fornecem caminhos garantidamente sem loop. No entanto, roteadores que não atendem a FC podem eventualmente também fornecer caminho sem loop (como é o caso do nosso exemplo inclusive).
O que acontece é que o EIGRP usa a Feasible Condition também para garantir a rápida convergência. Ou seja, todos os roteadores que atendem a FC estão “prontos” para serem usados. Assim, no caso de falha do R2, o tráfego passaria a ser encaminhado por R3 quase que instantaneamente.
Se R3 também falhar, aí R1 precisará passar a rota para o estado ativo, perguntar para os neighbors quem conhece a rede, identificar a nova Feasible Distance e então ver quem, neste novo cenário, atende a FC. Obviamente neste caso a convergência não seria tão rápida quanto no caso anterior.
Pacotes EIGRP
O EIGRP usa seis tipos de pacotes para comunicação “normal” entre os roteadores, e ainda dois tipos “especiais” (SIA), conforme descrito abaixo.
-
Hello: Pacotes usados para detectar e manter adjacência. São enviados para o endereço Multicast 224.0.0.10, se não tiver neighbor configurado manualmente (caso tenha, é enviado como Unicast para cada vizinho cadastrado).
-
Ack: Basicamente um pacote Hello que não contem dados, usado apenas para confirmar o recebimento de um pacote EIGRP confiável. Tem número de sequência e é sempre enviado como Unicast.
-
Update: Pacotes com informações das rotas, informações essas que são usadas para construir a Topology Table. Enviado como Unicast para cada vizinho, quando ocorre mudança na tabela de rotas, e requer confirmação de recebimento (Ack).
-
Query: Pacotes Multicast usado para requisitar informações de roteamento. São enviados quando uma rota fica indisponível e o roteador “questiona” o vizinho sobre o status da rota. Se não receber reposta de um dado vizinho, é então enviado um novo Query, em Unicast, para este neighbor. Se o vizinho continuar não respondendo a vizinhança é reiniciada.
-
Reply: Pacote enviado em resposta ao Query. Sempre enviados como Unicast para quem enviou o Query.
-
Request: São usados para conseguir informações específicas de um ou mais neighbors. Podem ser enviados via Multicast ou Unicast, e não tem confirmação de recebimento.
-
SIA-Query: Quando um Query é enviado, o Active Timer é iniciado. O valor padrão deste timer é 3 minutos (pode ser configurado entre 1 e 65535 minutos ou definido como infinito). Se todos os vizinhos não responderem antes do Active Timer expirar, a rota em questão será marcada como Stuck-In-Active (SIA). O vizinho ou vizinhos que não responderam são removidos da tabela de vizinhança, e o DUAL considerará esses vizinhos como tendo respondido com uma métrica infinita. Acontece que eventualmente o vizinho não respondeu porque ele também está esperando a resposta de outro neighbor. Para evitar desfazer a vizinhança, na metade do Active Timer o roteador que enviou o Query envia o SIA Query para o neighbor que não respondeu, para confirmar se o vizinho está envolvido em responder à consulta ou tem algum problema.
-
SIA-Reply: É a resposta ao SIA Query (algo como “calma amigo, também estou esperando a resposta de outro roteador” ou “sim, está aqui a informação daquela rota”).
Mais informações:
Até a próxima.
You must be logged in to post a comment.