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:

1. The same route is received via another protocol with a  lower AD
2. EIGRP summarization
3. Duplicate Router IDs are present within the EIGRP domain
4. The routes do not meet the Feasibility Condition

In the ROUTE guide, we learned that the administrative distance concept is used to determine how reliable the route source is. The lower the administrative distance, the more reliable the route source is. If the same route is received from three different protocols, the route with the lowest administrative distance will be installed into the routing table. When using EIGRP, keep in mind that EIGRP uses different administrative distance values for summary, internal, and external routes. If you are running multiple routing protocols, it is important to ensure that you understand administrative distance 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 summarizes at Classful boundaries and creates a summary route pointing to the Null0 interface. Because the summary is installed with a default administrative distance value of 5, any other similar dynamically received routes will not be installed into the routing table. Consider the topology illustrated in Figure 5- for example:

Fig. 5-1. EIGRP Automatic Summarization

Referencing the diagram illustrated in Figure 5-1, the 150.1.1.0./30 subnet separates 10.1.1.0/24 and 10.2.2.0/24. When automatic summarization is enabled, both R1 and R2 will summarize 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 administrative distance 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 neighbor 150.1.1.1 with a route metric of 156160/128256. However, DUAL also has the same route locally, due to summarization, 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 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 summarization should be disabled using the no auto-summarycommand on both of the routers, allowing the specific route entries to be advertised instead.

The primary use of the EIGRP Router ID 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 were route redistribution is being performed on more than one ASBR. The originating router ID can be viewed in the output of the show ip eigrp topology command as illustrated below:

If you suspect a potential duplicate router ID 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 shows a sample output of the EIGRP event log, showing routes which 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 neighbor router 10.0.0.1 or on the local router, depending on which one of the two has been incorrectly configured.

And 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 variancecommand will allow EIGRP to load share over the any paths whose route metric is x times that of the successor metric. Consider the topology illustrated in Figure 5-2 for example:

Fig. 5-2. Understanding the Feasibility Condition

Figure 5-2 shows a basic network which includes metrics from R1 to the 192.168.100.0/24 subnet. Referencing Figure 5-2, Table 5-1 shows the Feasible Distance and Reported Distance values as seen on R1 for the 192.168.100.0/24 network.

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, 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 Feasible Distance 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 neighbor 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 Feasible Distance and so this route meets the Feasibility Condition and is placed into the EIGRP Topology table.

The metric for neighbor R2 to the 192.168.100.0/24 network is 30. This value is higher than the Feasible Distance of 25. This route does not meet the Feasibility Condition 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 all routes are considered.