Troubleshooting Route Installation

There are instances where you might notice that EIGRP is not installing certain routes into the routing table. For the most part, this is typically due to some misconfigurations versus a protocol failure. Some common reasons for route installation failure include the following:

• The same route is received via another protocol with a  lower administrative distance
• EIGRP summarisation
• Duplicate router IDs are present within the EIGRP domain
• The routes do not meet the Feasibility Condition

The administrative distance (AD) concept is used to determine how reliable the route source is. The lower the AD, the more reliable the route source is. If the same route is received from three different protocols, the route with the lowest AD will be installed into the routing table. When using EIGRP, keep in mind that EIGRP uses different AD values for summary, internal, and external routes. If you are running multiple routing protocols, it is important to ensure that you understand AD values and how they impact routing table population. This is especially of concern when you are redistributing routes between multiple routing protocols.

By default, EIGRP automatically summarises at classful boundaries and creates a summary route pointing to the Null0 interface. Because the summary is installed with a default AD value of 5, any other similar dynamically received routes will not be installed into the routing table. Consider the topology illustrated in Figure 37.1 below, for example:

Figure 37.1 –  EIGRP Automatic Summarisation

Referencing the diagram illustrated in Figure 37.1, the 150.1.1.0./30 subnet separates 10.1.1.0/24 and 10.2.2.0/24. When automatic summarisation is enabled, both R1 and R2 will summarise the 10.1.1.0/24 and 10.2.2.0/24 subnets, respectively, to 10.0.0.0/8. This summary route will be installed into the routing table with an AD of 5 and a next-hop interface of Null0. This lower administrative distance value will prevent either router from accepting or installing the 10.0.0.0/8 summary from the other router, as illustrated in the following output:

In the debug output above, the local router receives the 10.0.0.0/8 route from neighbour 150.1.1.1 with a route metric of 156160/128256. However, DUAL also has the same route locally, due to summarisation, and this route has a route metric of 128256/0. The local route is therefore installed into the routing table instead because it has the better metric. The same would also be applicable on R1, which would install its local 10.0.0.0/8 route into the RIB instead. The result is that neither router would be able to ping the 10.x.x.x subnet of the other router. To resolve this issue, automatic summarisation should be disabled using the no auto-summary command on both of the routers, allowing the specific route entries to be advertised instead.

The primary use of the EIGRP router ID (RID) is to prevent routing loops. The RID is used to identify the originating router for external routes. If an external route is received with the same RID as the local router, the route will be discarded. However, duplicate RIDs do not affect any internal EIGRP routes. This feature is designed to reduce the possibility of routing loops in networks where route redistribution is being performed on more than one ASBR. The originating RID can be viewed in the output of the show ip eigrp topology command, as illustrated below:

If you suspect a potential duplicate RID issue, you can check the events in the EIGRP event log to see if any routes have been rejected because of a duplicate RID. The following illustrates a sample output of the EIGRP event log, showing routes that have been rejected because they were received from a router with the same RID as the local router:

The resolution for the solution above would be to change the RID on neighbour router 10.0.0.1 or on the local router, depending upon which one of the two has been incorrectly configured.

Finally, it is important to remember that EIGRP will not install routes into the routing table if they do not meet the Feasibility Condition. This is true even if the variance command has been configured on the local router. It is a common misconception that issuing the variance command will allow EIGRP to load share over any paths whose route metric is x times that of the successor metric. Consider the topology illustrated in Figure 37.2 below, for example:

Figure 37.2 –  Understanding the Feasibility Condition

Figure 37.2 shows a basic network that includes metrics from R1 to the 192.168.100.0/24 subnet. Referencing Figure 37.2, Table 37.1 below displays the Reported Distance and Feasible Distance values as seen on R1 for the 192.168.100.0/24 network:

Table 37.1 –  R1 Paths and Distances

R1 has been configured to load share across all paths and the variance 2 command is added to the router configuration. This allows EIGRP to load share across paths with up to twice the metric of the Successor route, which would include all three paths based on the default metric calculation. However, despite this configuration, only two paths will be installed and used.

First, R1 will select the path through R4 as the Successor route based on the FD for the route, which is 25. This route will be placed into the IP routing table as well as the EIGRP topology table. The metric for neighbour R3 to the 192.168.100.0/24 network, also referred to as the Reported Distance or Advertised Distance, is 10. This is less than the FD, and so this route meets the FC and is placed into the EIGRP topology table.

The metric for neighbour R2 to the 192.168.100.0/24 network is 30. This value is higher than the FD of 25. This route does not meet the FC and is not considered a Feasible Successor. The route, however, is still placed into the EIGRP topology table. However, the path will not be used for load sharing, even though the metric falls within the range specified by the configuration of the variance 2 EIGRP router configuration command. In such situations, consider using EIGRP offset lists to ensure that all routes are considered.