EIGRP Routing Protocol 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.
In the below 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
The The Tunnel 100 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:
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.
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