EIGRP uses 3 tables:
- The neighbor table shows you what’s going on with other routers seen as adjacent via “show ip eigrp neighbors”.
- The topology table contains EIGRP update messages, essentially all the prefixes, next hops, etc. that the EIGRP neighbors tell one another about. “show ip eigrp topology”
- EIGRP routes installed in the IP routing table are based on the router’s metric calculation of each route from the topology table.
EIGRP computes the route metric based on several things, by default only bandwidth (in bits per second) and delay (in tens of microseconds). If you use the “metric weights” commands in your router eigrp paragraph, you can also have EIGRP include link load, reliability and MTU in the metric calculation – although this is not recommended by Cisco because it can introduce route instability. Link load and reliability can be fluctuating values causing a higher than usual number of convergence events.
So, assuming we’re using the default K values (ergo, we’re only going to compute the EIGRP metric based on bandwidth and delay), what does the EIGRP metric computations process look like?
- A neighbor (let’s call him R1) advertises a route with bandwidth and delay.
- R2 receives this route and computes the “reported distance” (RD) of the route. RD is the neighbor’s route metric.
- R2 puts this route into his topology table, adding his own delay and bandwidth as appropriate. Delay is aggregate of all hops, whereas the bandwidth only uses the lowest bandwidth link.
- When R2 advertises this route, it will include the new computed delay and bandwidth.
- The default K values EIGRP metric computation formula is pretty easy: EIGRP metric = 256*(10,000,000/bandwidth) + 256*delay.
The topology table will show you a few other good things to know:
- The feasible distance (FD) is the router’s best computed metric when compared to all the possible ways to get to a certain network.
- The FD is then the “successor route”, and is the one installed in the IP routing table. The successor route’s metric in EIGRP-speak is the FD of a route, and therefore this is the metric you’ll see attached to the route when you do a “show ip route”.
- You’ll also see “feasible successors” in the topology table, or routes that EIGRP knows can be used, but don’t have a metric as good as the FD. Feasible successors then are routes that might be installed in the routing table at some point, but only if the successor route fails.
Now, in any network of size, routes will change. Links go up and down, routers become unavailable, etc. When there’s a change to the EIGRP topology, EIGRP neighbors send each other updates about the change. This change is known in EIGRP-speak as an “input event”. When an EIGRP router receives an “input event”, he performs a “local computation” to determine whether the input event is something he needs to do something about or not.
- If the input event indicates that the successor route is no longer available, the routers will install a feasible successor, and then update his neighbors about the change.
- If there is no feasible successor, then the router “goes active” for the route, in essence asking neighbors for a path to his dead successor.
When a router “goes active” on a route, he sends multicast query messages to his neighbors asking for a way to get to the network he just lost a path to. Each of those routers will unicast back a reply message. If the querying router gets a valid path or paths back to the network, he’ll perform normal computations on the routes, and update his topology table and IP route table appropriately. If there’s no path back to the network, then that route simply doesn’t get placed back in the routing table.
Now, when a router receives a query message from another router about an active route, that router can do a few different things:
- If the router has no topology table entry, then the reply message states that the router has no route.
- If the router has a successor or feasible successor, then those details are sent back in the reply message.
- But if there is an entry in the topology table, but yet no successor or feasible successor (a route with recent changes where the route is in limbo), then the queried router itself will go active for this route.
Now a router will keep a route in the active state until he hears a unicast reply from every neighbor. So if that third condition above applies (i.e. the queried router goes active), then that means it’s going to take that much longer for the queried router to reply – because now the queried router has to wait for all of HIS neighbors to reply to his query before he can reply to the initial query about the route. So if you think of this happening, several routers deep in a large enterprise network, you can end up in a condition where a route is considered to be “stuck-in-active”. If all queried routers do not respond before the “active timer” expires, then that route is “stuck-in-active”.
An interesting side-effect of the active timer is that a router will consider his neighbor to have gone down if he doesn’t respond before the active timer expires. If you want to disable that function on the chance that the neighbor is actually good, just not responding quickly enough, you can use the “timers active-time disabled” function in the “router eigrp” paragraph.
You can also handle this situation by limiting the scope of the query. You can reduce the number of neighbors that receive the active route query, and also how many hops away the active query can go. You accomplish this more through design than a magic command.
- Route summarization can keep queries brief. If a router has gone active for 10.1.2.0/24, and sends a query to a neighbor with a 10.0.0.0/8 summary route, the queried neighbor will immediately reply that he does NOT have a route for 10.1.2.0/24. (Remember that he would be advertising the 10.0.0.0/8 route still.)
- Another design element you can use is that of a stub router. EIGRP stub routers sit logically at the edge of your EIGRP autonomous system. They are routers that participate in EIGRP, but are not expected to be used as transit routers. Non-stub routers do not send queries to stub routers, on the general principle that they are supposed to be topology end points, not transit paths.