Manipulate EIGRP from Higher Metric to Lower Metric

Introduction

This document describes the problem with Enhanced Interior Gateway Routing Protocol (EIGRP) route metric manipulation where the modified metric does not take effect due to known EIGRP behavior.

Background

The problem was noticed in one of the Intelligent WAN (IWAN) deployments where the network operator tried to influence the traffic path preference with a EIGRP delay metric on the branch routers. The path preference was influenced by the distribute-list under EIGRP configuration and by adjustment of the delay metric. Examine the topology shown in Figure 1.

Figure 1 - IWAN Topology

In this topology, the network operator tries to perform route-manipulation with distribute-list on all the branch routers in both data centers to provide preference to the prefixes to take a certain link as the preferred path. For example, prefix 10.2.0.0/16 in DC2 is the preferred route on the spoke router in this sequence of preference: DC2-BR2, DC2-BR1, DC1-BR2, DC1-BR1. In other words, the path preference to send traffic for the spoke router, for instance Spoke-1, would be first towards the DC2-BR2 router, then DC2-BR1 router, then towards DC1-BR2, and finally towards the DC1-BR1 router. The network operator also has a EIGRP delay configured on the DCI interface on DC1-SW1 node.

A sample configuration from the DC1-BR1 router for EIGRP metric manipulation is shown here:

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

The Tunnel100 is a Dynamic Multipoint VPN (DMVPN) tunnel towards the Spoke router over the INET link. In the previous configuration, the prefix 10.2.0.0/16 is set with the delay of 4000. Similarly, the delay is set to 1000, 2000, and 3000 on DC2-BR2, DC2-BR1, and DC1-BR2 nodes respectively for the same prefix to set the order of preference. Though the example uses a DMVPN tunnel for demonstration purposes, the issue is not interface dependent.

Problem

The problem is actually seen on the spoke routers, where the prefix 10.2.0.0/16 is seen with different metrics when it is received from DC2 branch routers but has the same metric when received from DC1 branch routers. This output from the spoke router shows this behavior:

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)

This behavior causes the preference not to be given in sequence for the paths received from DC1-BR1 and DC1-BR2 routers.

Solution

The main cause of the problem was that the network operator tried to set a metric to a lower absolute value (lower metric) than the value received. This can be verified with the show ip eigrp events command on the DC1 branch routers. The output shows that the route-map tries to manipulate the metric to a value lower than what actually exists for the prefix.

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

Note that for any routing protocol, you can never decrease a metric as it would mean that you have an interface with a negative cost. This would in turn defeat the loop prevention conditions and can cause inconsistency in the network. The solution to the problem can be done in two different ways:

• Reduce the delay value in the path for the received prefix. In the previous case, reduction of the EIGRP delay value on the DCI interface helped mitigate the problem.
• Configure a higher absolute metric when you perform metric manipulation.