1.3 EIGRP

Reference: https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html

1.3.a Adjacencies

I’m going to burn through these topics pretty quick and just touch on unique scenarios. EIGRP has been around forever and there are a million resources that cover it. So for adjacencies, I’m just going to make up a task that will challenge our knowledge of unicast vs. multicast neighbor relationships.

Task#1: R1 and R5 must share EIGRP routes. Multicast is not allowed.

Let’s assume that the firewall between R1 and R5 is blocking multicast traffic for 224.0.0.10. That means we need to set up a unicast neighborship.

R1
conf t
router eigrp 100
neighbor 192.0.0.18 Gig0/3

R5
conf t
router eigrp 100
neighbor 192.0.0.17 gig0/0

Let’s verify it.

1.3.b Best path selection

A quick reminder, EIGRP AD is 90, routes redistributed into EIGRP have AD 170.

The metric calculation is simply bandwidth + delay. But what about this 256 business? I thought it was something like metric = 256 ((10^7/bandwidth) + (delay/10)). OK, fine, so it’s a tiny bit more complicated than bandwidth + delay.

Bandwidth = [ten million / (the lowest bandwidth along the path, based on what’s configured on the outgoing interfaces)] * 256 OR (10^7/BW)*256

Delay = [the sum of all the delays as configured on outgoing interfaces along the path / 10] * 256

Why are we dividing delay by 10? Because EIGRP counts delay in 10’s of microseconds. The interfaces are in actual microseconds. So we have to divide by 10. Nothing’s ever easy.

1.3.b i RD, FD, FC, successor, feasible successor

We should know all this stuff by heart from CCNA and CCNP exams. But I’ll regurgitate it here to help keep me sharp on it.

• RD: Reported Distance (used to be Advertised Distance, but it was too confusing with Administrative Distance). It’s what our neighbor tells us through routing updates what the metric is to get to route X.
• FD: Feasible Distance is what I figured out the shortest distance is to route X. It’s the reported distance, plus the cost to get me to the neighbor that told me their reported distance.
• FC: Feasibility Condition. I couldn’t remember this one and had to look it up. Good thing I didn’t skip through this section. It’s an easy one, though. This is what you use to determine whether or not you want to keep track of any halfway decent backup routes in your topology table. We might learn a bunch of paths to route X, but we only want to keep them handy if they meet the FC, meaning the Reported Distance that R3 told us is LESS THAN the Feasible Distance by going through R2.
  
  To put it another way, R2 told us we can ride their bus for $100 to get to destination X. R3 can get us there for $120. But I know it’s going to cost me $30 to get to R2’s bus station, for a total cost of $130. So I’m definitely going to take R2’s bus. But I’m going to keep the info for R3 handy, just in case I need it. However, if R3 told us they’d charge $200 to get to destination X, I wouldn’t even consider it, I’d just tear up their estimate and throw it in the trash.
• S
• Successor: That’s just the next hop.
• Feasible Successor: This would be R3 in our scenario above. It’s not in our routing table, but we’re hanging onto the info in our EIGRP topology table, just in case we need it.

1.3.b ii Classic Metrics and Wide Metrics

The Classic metric is just the standard formula. But let’s talk specifically the (10^7/BW) part. The breaks down as follows for different link speeds:

Gigabit: 10,000,000 / 1,000,000 = 10.
So our composite metric is (10 + delay) * 256. Makes sense so far.

10 Gig: 10,000,000 / 10,000,000 = 1.
Composite metric is (1 + delay) * 256. OK, so now the danger is becoming apparent.

11 Gig: 10,000,000 / 11,000,000 = 0 (rounded down to zero).
Composite metric is (0 + delay) * 256. The problem becomes really obvious with 11Gig links, but we can see a problem even sooner. Let’s verify that by checking 3Gig, 4Gig, and 5Gig bandwidth.

Hence the need to introduce Wide Metrics. The solution is to just multiply our classic 10^7 by 65535. So link speeds can scale up to 655 terabits/second.

Delay is also modified. Instead of 10^-6, it becomes 10^-12 (picoseconds).

One more thing, a new K value was added, value K6. It’s set to 0 by default (same as K2, K4, and K5). The idea is it could be used for jitter or some other future use.

So which metric are we using? It’s easy, if we’re in classic EIGRP we’re using the classic metric, if we’re in named-mode EIGRP, we’re using the wide metric. We can do an easy check with show ip protocols. If we see a K6 value listed, we know we’re in wide metric.