EIGRP Inaccessible Routes

Before diving into the mechanics and processes of various routing protocols it is important to grasp what is exchanged when a neighbour relationship is formed. It’s easy to think that when a neighbour relationship is formed the routers just exchange the contents of the IP routing table (RIB) or even just the contents of the IGP specific table (such as the EIGRP topology table)…both assumptions would be incorrect. We’ll use EIGRP as the IGP in this example.

When the neighbour relationship is formed a flurry of updates packets are exchanged between the neighbours. These updates contain *only* the routes from the EIGRP topology table. Assuming no redistribution has been configured these routes will only be routes seeded into EIGRP with the network command.

The second (as most important point to remember) is that the updates will contain routes from the EIGP topology table but ONLY if they appear in the RIB (as EIGRP learnt) as well. This ensures that a router only advertises routes that it actually using itself.

Topology:

topology1

 

In this topology the route we are interested in is 1.1.1.1/32 found on R1’s loopback interface. All routers are running EIGRP with the exception of R2.

1.1.1.1/32 is seeded into EIGRP by R1 and learnt by R3. We can confirm this by looking at R3’s RIB:

shoiproute1

As we’d expect, learnt from internal EIGRP, distance 90 and a metric of 409600 (not great but it’s come over a 10Mbps interface)

The route is also found in our EIGRP topology table:

eigrptop1

 

Again, nothing unusual – 1 successor and a feasible distance. As the EIGRP route is in the RIB on R3 it can also sent to R4 in an EIGRP update. Everthing is stable and good. Nice.

If you look at the topology closely you notice that the link between R1 and R3 is a meagre 10 Mbps. We have a better path if we go via R2 instead…..so let’s do it. As R2 isn’t running an IGP we’ll a have to add some static routes on each hop. For brevity I’ll just include R3’s route:

R3(config)#ip route 1.1.1.1 255.255.255.255 192.168.3.1

Updated now routing table looks like this:

iproute2

 

The EIGRP route has been replaced by a static. In a game of routing top trumps static always wins against an IGP. Let’s look at the EIGRP topology, I mean R1 is still advertising the route so it should look the same as before right?

eigrptop2

Nope! The route was not inserted into the RIB as the static route had a better admin distance. EIGRP is aware of this and marks the route as inaccessible. Another clue that the route is not used is the the Successors has changed to 0. R3 will also send a query to R4 for this route the result of which is that R4 will remove the route from it’s EIGRP topology and routing table.

To summarise an IGP will only advertise routes that it is actually using itself. If the route is learnt from a better source then it will not be advertised in the IGP unless redistribution is configured.