Articles
recent

Routing Protocol : EIGRP Metric Manipulation

Today I am going to talk about the EIGRP Metric Manipulation from Higher Metric to Lower Metric. In this case, EIGRP route metric manipulation where the modified metric does not take effect due to known EIGRP behaviour.

This is the one case in Intelligent WAN (IWAN) deployment where the network operator tried to influence traffic path preference using EIGRP delay metric on the branch routers. The path preference was being influenced using the distribute-list under EIGRP configuration and by tweaking the delay metric.

Fig 1.1- Sample Network Topology

In the above mentioned topology, the network operator tries to perform route-manipulation using distribute-list on all the Branch routers in both data centers to provide preference to the prefixes to take certain link as preferred path. For example, prefix 10.2.0.0/16 in DC2 will be the preferred route on Spoke router in the following 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 DC1-BR1 router. The network operator also has a EIGRP delay configured on the DCI interface on DC1-SW1 node.

sample configuration from the DC1-BR1 router for EIGRP metric manipulation
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 DMVPN tunnel towards the Spoke router over the INET link. In the above 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 DMVPN tunnel for demonstration purpose, 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 its received from DC2 branch routers but have same metric when received from DC1 branch routers. The below output from the Spoke router shows this behaviour:

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 behaviour 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 found here was that, the network operator was trying to set a metric to a lower absolute value (lower metric) than the value received. This can be verified using the command show ip eigrp events on the DC1 branch routers. The Output shows that the route-map is trying to manipulate the metric to a value lower than what actually exists for the prefix. 
!
DC1-BR1# show ip eigrp events
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 few different ways:

  • Reduce the delay value in the path for the received prefix. In the above case, reducing the EIGRP delay value on the DCI interface helped mitigate the problem.
  • Try configuring a higher absolute metric when performing metric manipulation

Popular Posts

Powered by Blogger.