Manipular o EIGRP de Métrica Superior para Métrica Inferior

Introdução

Este documento descreve o problema com a manipulação métrica de rotas do Enhanced Interior Gateway Routing Protocol (EIGRP), em que a métrica modificada não entra em vigor devido ao comportamento conhecido do EIGRP.

Background

O problema foi observado em uma das implantações da Intelligent WAN (IWAN) em que o operador de rede tentou influenciar a preferência de caminho de tráfego com uma métrica de atraso EIGRP nos roteadores das filiais. A preferência de caminho foi influenciada pela lista de distribuição na configuração do EIGRP e pelo ajuste da métrica de atraso. Examine a topologia mostrada na Figura 1.

Figura 1 - Topologia da IWAN

Nessa topologia, o operador de rede tenta executar a manipulação de rota com distribute-list em todos os roteadores de filial em ambos os data centers para fornecer preferência aos prefixos para tomar um determinado link como o caminho preferido. Por exemplo, o prefixo 10.2.0.0/16 em DC2 é a rota preferencial no roteador spoke nesta sequência de preferência: DC2-BR2, DC2-BR1, DC1-BR2, DC1-BR1. Em outras palavras, a preferência de caminho para enviar o tráfego para o roteador spoke, por exemplo, Spoke-1, seria primeiro em direção ao roteador DC2-BR2, depois em direção ao roteador DC2-BR1, em seguida em direção ao roteador DC1-BR2 e, finalmente, em direção ao roteador DC1-BR1. O operador de rede também tem um atraso EIGRP configurado na interface DCI no nó DC1-SW1.

Um exemplo de configuração do roteador DC1-BR1 para manipulação de métrica EIGRP é mostrado aqui:

! Configuration from DC1-BR1 router
router eigrp TEST
 !
 address-family ipv4 unicast autonomous-system 100
 !
 af-interface default
 passive-interface
 exit-af-interface
 !
 af-interface Tunnel100
 summary-address 10.0.0.0 255.0.0.0
 summary-address 10.2.0.0 255.255.0.0
 no passive-interface
 no split-horizon
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/1
 no passive-interface
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/3
 no passive-interface
 exit-af-interface
 !
 topology base
 distribute-list route-map set-metric-Gig out GigabitEthernet0/0/1
 distribute-list route-map set-metric-tag-all out Tunnel100
 exit-af-topology
 network 10.1.2.0 0.0.0.255
 network 10.1.10.0 0.0.0.3
 network 10.1.123.0 0.0.3.255
 eigrp router-id 10.1.0.11
 exit-address-family 
!
route-map set-tag-all deny 10
 match tag 102 201 202
!
route-map set-tag-all permit 100
 match ip address prefix-list set-spoke-delay-4000
 set metric 100000 4000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 300
 match ip address prefix-list set-spoke-delay-1000
 set metric 100000 1000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 400
 match ip address prefix-list set-spoke-delay-2000
 set metric 100000 2000 255 1 1500
 set tag 101
 
!
ip prefix-list set-spoke-delay-4000 seq 100 permit 10.2.0.0/16
. . . 
! 

O Tunnel100 é um túnel DMVPN (Dynamic Multipoint VPN) em direção ao roteador Spoke pelo link INET. Na configuração anterior, o prefixo 10.2.0.0/16 é definido com o atraso de 4000. Da mesma forma, o atraso é definido como 1000, 2000 e 3000 nos nós DC2-BR2, DC2-BR1 e DC1-BR2, respectivamente, para o mesmo prefixo para definir a ordem de preferência. Embora o exemplo use um túnel DMVPN para fins de demonstração, o problema não depende da interface.

Problema

O problema é realmente visto nos roteadores spoke, onde o prefixo 10.2.0.0/16 é visto com métricas diferentes quando é recebido de roteadores de filial DC2, mas tem a mesma métrica quando recebido de roteadores de filial DC1. Esta saída do roteador spoke mostra este comportamento:

Spoke-1# show ip eigrp topology 10.2.0.0/16 | in delay
        Total delay is 60000000000 picoseconds  (from DC 2 BR2)
        Total delay is 100020000000 picoseconds  (From DC 1 BR1)
        Total delay is 70000000000 picoseconds  (From DC 2 BR1)
        Total delay is 100020000000 picoseconds  (From DC 1 BR2)

Esse comportamento faz com que a preferência não seja dada em sequência para os caminhos recebidos dos roteadores DC1-BR1 e DC1-BR2.

Solução

A principal causa do problema foi que o operador de rede tentou definir uma métrica para um valor absoluto mais baixo (métrica mais baixa) do que o valor recebido. Isso pode ser verificado com o comando show ip eigrp events nos roteadores de filial DC1. A saída mostra que o mapa de rota tenta manipular a métrica para um valor inferior ao que realmente existe para o prefixo.

DC1-BR1# show ip eigrp events
. . .
06:47:11.891 Can't reduce rtmap metric, old/new: metric(2950430720) metric(1972633600)
. . .

Observe que, para qualquer protocolo de roteamento, você nunca pode diminuir uma métrica, pois isso significaria que você tem uma interface com um custo negativo. Isso, por sua vez, anularia as condições de prevenção de loop e pode causar inconsistência na rede. A solução para o problema pode ser feita de duas maneiras diferentes:

• Reduza o valor de atraso no caminho para o prefixo recebido. No caso anterior, a redução do valor de atraso do EIGRP na interface DCI ajudou a atenuar o problema.
• Configure uma métrica absoluta mais alta ao executar a manipulação de métrica.