Normally for these FFF articles I’ve taken to writing about new protocols as a way of introducing others to it and also edumacating myself about it. For this post I get all nostalgic and look at good old Enhanced Interior Gateway Routing Protocol (EIGRP).
1 – The EIGRP Metric is Calculated From a Formula
Unlike RIP with its simple hop count or OSPF with its simple bandwidth metric, the EIGRP metric is actually derived by plugging a number of values into a formula and solving the formula. The formula looks like this:
Let’s talk about the k values first. The k values are constants that are configured in IOS and fed into the formula. They have the affect of basically turning on and off the variables that are used in the calculation: bandwidth, delay, load, reliability. They also have the affect of giving more or less emphasis to a variable. For example, setting k3 to 50 would give the “delay” variable more emphasis than if k3 is set to 1. The default settings for the k values are:
- k1 and k3 = 1
- k2, k4, k5 = 0
This has the net result of simplifying the formula to this:
A common misconception is that the k values are themselves part of the metric. That’s incorrect. The k values are configured locally on the router and are not exchanged as part of EIGRP update messages nor do they show up in the EIGRP topology table. They are, however, exchanged during neighbor discovery to ensure that all routers in the EIGRP autonomous system have the same k value… erm… values.
Looking back at the original formula, we can see the variables load, delay, and reliability. These are dynamic values calculated by IOS (load and delay can be seen in the output of “show interface”) and change as the load of the interface changes. It would seem to make sense then that whenever these values change that EIGRP will send an update to its neighbors, potentially causing many updates to be sent around the network and an increased load on the control plane. This is in fact not true. Even though these values are updated regularly by IOS, EIGRP does not send updates when the load, delay or reliability of an interface changes.
The formula above is used in EIGRP “classic mode”. EIGRP “named mode” has a slightly different formula, however the concept of the k values and variables is exactly the same
2 – EIGRP Can Pre-compute Loop-Free Alternate Paths
This aspect of EIGRP is really why it can converge so fast. Instead of only choosing a best path for each destination network, EIGRP actually pre-computes loop-free alternate path(s) along with the best path.
In order to compute a path that is loop-free, EIGRP first computes the best path. This is simply the path that has the lowest metric (see above) to the destination network. The metric for the best path is called the Feasible Distance (FD). The FD is the metric that the neighbor router is advertising (called the Reported Distance, or RD) plus the metric that the local router computes by using the formula above.
Put a different way, the FD is the sum of the individual interface metrics for every router along the best path to a destination.
In order to calculate a loop-free alternate path (called a Feasible Successor or FS), EIGRP invokes a rule called the Feasibility Condition which says that a Feasible Successor (the alternate route) must have an Reported Distance (metric reported by the neighbor) that is less than the Feasible Distance (local router’s best path metric) to the destination.
When I first tried to get my head around this idea I had a hard time. What worked for me was an analogy that Donnie Savage used. Incidentally, Donnie is one of the folks behind the EIGRP protocol. His analogy is this:
If you are selling apples, and I am also selling apples, and I am charging MORE for the apples than you are, then you are obviously not buying your apples from me. If you were buying apples from me, then you would have to be charging AT LEAST what I charge, or possibly more. If my neighbor is cheaper than me, then my neighbor is NOT using me.
The ability for EIGRP to pre-compute alternate paths means that it’s able to converge very, very quickly if the best path becomes unusable. Best of all, this is a native feature of EIGRP and doesn’t have to be enabled or configured.
3 – EIGRP Can Do Unequal Cost Load Balancing
Equal cost load balancing (ECLB) is pretty popular, but UN-equal cost? I can’t say I’ve ever seen it explained why EIGRP does this, but I’ll take an educated guess here. Given the formula that EIGRP uses to calculate its metric (see above), the metric values end up being rather large numbers which makes them very, very granular. Hence, a small change in a formula input value can result in a large change in the resulting metric. For example, let’s say we wanted to include the load variable in the metric calculation so we set k2 to “1”. The value for load is between 1 and 255 inclusive, or 0.004% for each increment. So while the actual difference in load between a value of, say, 11 and 12 is tiny, the resulting change in EIGRP metric is not.
My educated guess is that in order to “overlook” these minor changes in formula input values, EIGRP was designed to accept unequal metric routes so that routes that are “close enough” in metric will be considered equal. Here’s how it works.
There’s yet another multiplier, this time called the “variance”. The variance is used to determine which route(s) are “close enough” to the best path route (which is called the Successor). First EIGRP has to determine the Successor by finding out which route received from the neighbors has the lowest metric. The lowest metric is called the Feasible Distance and it creates the baseline here. Next EIGRP calculates all Feasible Successors (alternate routes that are loop free, see above). EIGRP then takes the Feasible Distance and multiplies it by the variance to get a product. This product is compared to the metric of each Feasible Successor route. If the metric is less than or equal to the product, the Feasible Successor route is considered equal to the Successor and is passed on to the routing table along with the Successor.
The comparison is only done with FS routes as they are known to be loop-free. Routes received from neighbors that are not Successors or Feasible Successors are not considered using this process.
Here’s an example.
- Feasible Distance (the best metric): 128010
- Variance set to: 2
- Feasible Successor metric: 129000
- Product: 128010 x 2 = 256020
- FS metric 129000 < product 256020, therefore it’s considered equal to the Successor and can be installed in the routing table along with the Successor
4 – EIGRP Can Summarize Routes Anywhere in the Network
Summarization is the process of taking all the details about a bunch of routes and condensing them down into one route. For example, taking these routes:
- 10.1.0.0/24, metric 110
- 10.1.1.0/24, metric 80
- 10.1.2.0/24, metric 20
And condensing them down to 10.1.0.0/22, metric 20. This summarized route can be advertised to neighbors in place of the 3 other routes. This places less load on the routing protocol (only have to process one route instead of three) and also minimizes memory and TCAM used to hold the Routing Information Base and Forwarding Information Base, respectively.
Since EIGRP is not a link state protocol, it does not actually know the topology of the network. For example, EIGRP does not understand that network a.b.c.d is directly connected to RouterX and that there are two valid, loop free paths through the network to reach RouterX. All EIGRP knows is that network a.b.c.d exists somewhere in the network and to reach it, it sends packets “over there“, out one of its local interfaces. Link state protocols actually know exactly where network a.b.c.d is attached and every router in the area has this information. In order for every link state router to build a consistent topology map, it’s a requirement that no summarization be done inside an area. Summarization hides information and that would violate the principle that every router in an area has the same link state database in order that they all build the same topology map.
With EIGRP not having the requirement that every router have the same database, we’re free to do summarization at any point in the network. In fact, summarization is encouraged as a way to bound the EIGRP query domain and is a way to build a healthier, faster converging network.
Here’s an example where summarization is being done in multiple places.
- The branch routers are summarizing their local networks towards the WAN aggregation router
- The WAN aggregation router is summarizing the summaries received from the branches towards the network core
- The WAN aggregation route is also summarizing the summaries advertised between branch routers
- The core switch is summarizing the core routes towards the WAN aggregation router
This ability to summarize at arbitrary locations is one of the reasons EIGRP is so scalable.
5 – EIGRP Can Differentiate Between Very High Speed Links
As mentioned above, bandwidth is one of the values that goes into calculating the composite metric. At the time of this writing, the economics of 40GigE is getting really good (actually, really good) in the data center and if you consider the use of link aggregation technologies such as Virtual Port Channels, we’re talking 80Gbps and higher link speeds. Can EIGRP properly grok bandwidth values this large?
When EIGRP calculates the composite metric, it takes the bandwidth of the link, converts it to kilobits per second and then divides that number into 107.
Bw = 10,000,000 / (<interface_bandwidth> * 0.001)
For example, a 2Gbps port channel would have an EIGRP bandwidth value of:
Bw = 10,000,000 / (2,000,000,000 * 0.001) = 5
A 10Gbps link would have an EIGRP bandwidth value of:
Bw = 10,000,000 / (10,000,000,000 * 0.001) = 1
Ok, that’s interesting. How about a 20Gbps port channel?
Bw = 10,000,000 / (20,000,000,000 * 0.001) = 0
The bandwidth is calculated as zero. EIGRP calculates a value of zero because it uses integer division. What this means is that any interface with a bandwidth value greater than 10Gbps will have an effective bandwidth value of zero which means EIGRP can’t tell the difference between a 10Gbps, 20Gbps, 40Gbps or 80Gbps link. They all look the same to EIGRP.
Now, everything I’ve written so far is true when running EIGRP in “classic mode” where classic metrics are used. However newer versions of EIGRP support “wide metrics” where this condition doesn’t exist. When wide metrics are being used, two things happen:
- The bandwidth value is not scaled by a constant (like the 107 with classic metrics)
- The EIGRP update message format is changed to allow for larger values to be exchanged between neighbors
The obvious question then is how to turn on wide metrics?
There’s no specific knob for which type of metric to use. Wide metrics are automatically enabled when running EIGRP in “named mode” and classic metrics are used when running in “classic mode”. Classic mode refers to enabling EIGRP with “router eigrp <ASN>” and named mode refers to “router EIGRP <name>”.
!!! Classic mode router eigrp 65201 network 10.1.0.0 0.0.255.255 network 184.108.40.206 0.0.255.255 !!! Named mode router eigrp HQ ! address-family ipv4 unicast autonomous-system 65201 ! topology base exit-af-topology network 10.1.0.0 0.0.255.255 network 220.127.116.11 0.0.0.255 exit-address-family
As long as named mode is configured, wide metrics are automatically in use. And named mode is also backwards compatible with classic mode and can talk to named and classic mode neighbors at the same time.
To learn a whole lot more about EIGRP, check out these resources.