EIGRP – Faster Convergence vs Optimal Traffic Flows

Enhanced Interior Gateway Protocol (EIGRP) is a distance vector protocol, originally a dynamic routing protocol created and made proprietary by Cisco.  By default, EIGRP supports equal cost load balancing and when configured, EIGRP supports unequal cost load balancing.

Design Thoughts

Often when we design and engineer our networks, we are presented with a lot of challenges and hurdles to overcome of which should be because you are trying to marry technology and business requirements.

Depending on your business requirements, you may need to choose the most cost-effective way to get your data from A to B and downtime, no matter how short may not be an issue, due to fault tolerances in applications.  However, sometimes the opposite is apparent, whereby fast convergence is valued due to the type of data you are your applications, are processing.

Think of stock exchanges, uptime and low latency are often the utmost importance to the business, therefore our networks must reflect this.  Often, this isn’t achieved by just implementing EIGRP by itself, assistance from protocols such as bidirectional forwarding detection (BFD) is appreciated here.

Now, let’s think about feasible successors. All well thought out network designs ensure that for fast convergence, a feasible successor for each route is present within EIGRP’s topology table.  Upon fault detection, a feasible successor can be promoted directly to the routing information base (RIB), without EIGRP having to send a query to its peers.

Although minor, believe it or not, there is a potential that EIGRP that from promoting a feasible successor can cause a spike in a CPU resources on a device but marginal gains are still gains, right?

Convergence Thoughts

There are two sections to this, the first – detecting the dead neighbor, which can be achieved easily with BFD, which allows for sub-second convergence.  The second is moving the route from the topology table to the RIB, although this is usually very quick, it still takes time – time which sometimes business cannot afford.

I want to focus on moving the route from the topology table into the RIB.  This is where you need to make the decision I touched upon at the start of the article – what’s do you want more of – load balancing, either equal or unequal or the ability to have fast convergence? If you chose fast convergence or unequal cost load balancing (active/standby) one option we have is to change the traffic-share that EIGRP uses.

By default, EIGRP is configured with “traffic-share balanced” configured, you will not see this in the running configuration, however as this is a hidden command. This is what allows you to perform load balancing and if you have not configured unequal cost load balancing and have no equal cost paths, this can be added by configuring variance and maximum paths.

Changing this to “traffic-share min across-interfaces” will mean that EIGRP only uses the minimum cost path at a single time, however, the feasible successors will be in your RIB rather than the topology table.

Case Study

Scenario

Services hosted behind R2 need to contact a server with the IP address of 1.1.1.1/32 (configured as a loopback on R1 for this task).  The business Giants & Runtington’s has two circuits to get to said prefix,  one that goes via R3 and the other that connects to R1.

The circuit between R2 and R1 is legacy and in the process of being migrated to the circuit connecting to R3 however, the business would like to use the circuit between R2 and R1 as a backup for the time being.

The business would like to see two routes for the prefix 1.1.1.1/32 in the RIB at all times.

Please use the below topology as a reference to this case study:-

Screenshot_1

All routers are participating in EIGRP, AS 100 and R1 has a loopback 0 configured with the IP address 1.1.1.1/32.  In addtion to this, R2 has a variance of ‘5’ set:-

interface Loopback0
ip address 1.1.1.1 255.255.255.255
end
!
router eigrp 100
variance 5
network 0.0.0.0

R2 has two unequal cost paths for the prefix 1.1.1.1/32

R2#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via “eigrp 100”, distance 90, metric 921600, type internal
Redistributing via eigrp 100
Last update from 23.1.1.3 on Ethernet0/0, 00:01:08 ago
Routing Descriptor Blocks:
23.1.1.3, from 23.1.1.3, 00:01:08 ago, via Ethernet0/0
Route metric is 921600, traffic share count is 12
Total delay is 26000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
* 12.1.1.1, from 12.1.1.1, 00:01:08 ago, via Ethernet0/1
Route metric is 1006848, traffic share count is 11
Total delay is 6000 microseconds, minimum bandwidth is 3000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

The fix

As you can see, the traffic share count is being shared on a 12:11 basis.

Now, by changing the traffic-share to “traffic-share min across-interfaces” on R4, look what happens.

R2#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via “eigrp 100”, distance 90, metric 921600, type internal
Redistributing via eigrp 100
Last update from 12.1.1.1 on Ethernet0/1, 00:02:32 ago
Routing Descriptor Blocks:
* 23.1.1.3, from 23.1.1.3, 00:02:32 ago, via Ethernet0/0
Route metric is 921600, traffic share count is 1
Total delay is 26000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
12.1.1.1, from 12.1.1.1, 00:02:32 ago, via Ethernet0/1
Route metric is 1006848, traffic share count is 0
Total delay is 6000 microseconds, minimum bandwidth is 3000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

The above command ensures that the minimum path cost is installed in the routing table, while all other paths for the prefix are installed within the RIB with a traffic count of ‘0’.

References

http://blog.ine.com/2009/05/01/understanding-unequal-cost-load-balancing/

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s