Manipular EIGRP de Métrica Superior a Métrica Inferior

Introducción

Este documento describe el problema con la manipulación de la métrica de ruta del Protocolo de ruteo de gateway interior mejorado (EIGRP) donde la métrica modificada no tiene efecto debido a un comportamiento EIGRP conocido.

Background

El problema se detectó en una de las implementaciones de WAN inteligente (IWAN), donde el operador de red intentó influir en la preferencia de la ruta de tráfico con una métrica de retraso EIGRP en los routers de sucursal. La preferencia de trayectoria estuvo influenciada por la lista de distribución bajo la configuración EIGRP y por el ajuste de la métrica de demora. Examine la topología mostrada en la Figura 1.

Figura 1: Topología IWAN

En esta topología, el operador de red intenta realizar la manipulación de rutas con distribute-list en todos los routers de sucursal en ambos Data Centers para proporcionar preferencia a los prefijos para que tomen un link determinado como la ruta preferida. Por ejemplo, el prefijo 10.2.0.0/16 en DC2 es la ruta preferida en el router spoke en esta secuencia de preferencia: DC2-BR2, DC2-BR1, DC1-BR2, DC1-BR1. En otras palabras, la preferencia de trayectoria para enviar tráfico para el router spoke, por ejemplo Spoke-1, sería primero hacia el router DC2-BR2, luego el router DC2-BR1, luego hacia DC1-BR2 y finalmente hacia el router DC1-BR1. El operador de red también tiene una demora EIGRP configurada en la interfaz DCI en el nodo DC1-SW1.

Aquí se muestra una configuración de ejemplo del router DC1-BR1 para la manipulación de métricas EIGRP:

! 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
. . . 
! 

El Tunnel100 es un túnel de VPN multipunto dinámica (DMVPN) hacia el router de radio a través del enlace INET. En la configuración anterior, el prefijo 10.2.0.0/16 se establece con el retraso de 4000. De manera similar, la demora se establece en 1000, 2000 y 3000 en los nodos DC2-BR2, DC2-BR1 y DC1-BR2 respectivamente para que el mismo prefijo establezca el orden de preferencia. Aunque el ejemplo utiliza un túnel DMVPN con fines de demostración, el problema no depende de la interfaz.

Problema

El problema se observa realmente en los routers spoke, donde el prefijo 10.2.0.0/16 se ve con diferentes métricas cuando se recibe de los routers de sucursal DC2 pero tiene la misma métrica cuando se recibe de los routers de sucursal DC1. Esta salida del router spoke muestra este comportamiento:

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)

Este comportamiento hace que la preferencia no se dé en secuencia para las trayectorias recibidas de los routers DC1-BR1 y DC1-BR2.

Solución

La causa principal del problema fue que el operador de red intentó establecer una métrica en un valor absoluto inferior (métrica inferior) al valor recibido. Esto se puede comprobar con el show ip eigrp events en los routers de ramificación DC1. El resultado muestra que el route-map intenta manipular la métrica a un valor inferior al que realmente existe para el prefijo.

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

Tenga en cuenta que para cualquier protocolo de ruteo, nunca puede disminuir una métrica ya que significaría que tiene una interfaz con un costo negativo. Esto a su vez vencería las condiciones de prevención de loops y podría causar inconsistencia en la red. La solución al problema se puede hacer de dos maneras diferentes:

• Reduzca el valor de retraso en la ruta del prefijo recibido. En el caso anterior, la reducción del valor de demora EIGRP en la interfaz DCI ayudó a mitigar el problema.
• Configure una métrica absoluta más alta cuando realice la manipulación de métricas.