Troubleshooting EIGRP Route Installation
The previous section discusses the problems that EIGRP routers have when advertising routes to its neighbors. This section discusses troubleshooting problems when EIGRP doesn't install the routes in the routing table. The most common causes of this problem are as follows:
Auto or manual summarization configured
Higher administrative distance
Duplicate router IDs
The following sections detail the causes of this problem and how to resolve them. For overall troubleshooting methods, Figure 7-24 shows the flowchart for troubleshooting EIGRP route-installation problems.
)
Figure 7-24 Flowchart for Troubleshooting EIGRP Route-Installation Problems
EIGRP Is Not Installing Routes—Cause: Auto or Manual Summarization
When EIGRP fails to install routes in the routing table, the first thing to check is the topology table. Figure 7-25 shows the network setup for this case study.
)
Figure 7-25 EIGRP Network Susceptible to Route-Installation Problem
Example 7-33 shows the configuration for Router B.
Example 7-33 Configuration for Router B in Figure 7-25
Router B# interface ethernet 0 ip address 172.16.2.1 255.255.255.0 interface serial 0 192.168.1.1 255.255.255.0 interface serial 1 192.168.2.1 255.255.255.0 router eigrp 1 network 172.16.0.0 network 192.168.1.0 network 192.168.2.0
Inside network clouds X and Y are networks in the 172.16.x.x space. The problem is that Router C summarizes all the 172.16.x.x networks into one summary route of 172.16.0.0/16 and sends it to Router B. Router B is not installing the routes in the routing table, as shown in Example 7-34.
Example 7-34 Router B's Routing Table
Router B# show ip route 172.16.0.0
Routing entry for 172.16.0.0/16
Routing Descriptor Blocks:
* directly connected, via Null 0
Router B's routing table shows that the route is directly connected to Null 0 instead of learned from Router C. The topology table in Router B shows that the router is getting the routes from Router C but is installing the route as connected because the Null 0 route has a distance of 5, which is an EIGRP summary route. The configuration of Router B shows that EIGRP summarizes the 172.16.0.0/16 route because of autosummarization. Every time autosummarization or manual summarization takes place, EIGRP installs the summary route with the next hop to Null 0. This is a loop-prevention mechanism for EIGRP's summary routes. In this case study, this is exactly what happens—EIGRP does not install a route from its neighbor that falls within its summary range.
The solution to this problem, based on this cause, is more of a design issue. Two places in the network must not send the same summary routes to one another. In this example, you configure the no auto-summary command on Router B to allow Router B to accept the summary routes coming from Router C. Example 7-35 shows the configuration in Router B to fix the problem.
Example 7-35 Configuration Change on Router B to Fix the Problem Shown in Figure 7-25
Router B# interface ethernet 0 ip address 172.16.2.1 255.255.255.0 interface serial 0 192.168.1.1 255.255.255.0 interface serial 1 192.168.2.1 255.255.255.0 router eigrp 1 network 172.16.0.0 network 192.168.1.0 network 192.168.2.0 no auto-summary
With the configuration change in Router B, the routing table shown in Example 7-36 for Router B now shows the summary route of 172.16.0.0/16 coming from Router C.
Example 7-36 Routing Table of Router B Now Showing Summary Route Coming from Router C
Router_B#show ip route 172.16.0.0 255.255.0.0 Routing entry for 172.16.0.0/16 Known via "eigrp 1", distance 90, metric 2195456, type internal Redistributing via eigrp 1 Last update from 192.168.1.2 on Serial0, 00:16:24 ago Routing Descriptor Blocks: *192.168.1.2, from 192.168.1.2, 00:16:24 ago, via Serial0 Route metric is 2195456, traffic share count is 1 Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
EIGRP Is Not Installing Routes—Cause: Higher Administrative Distance
Refer to the network topology in Figure 7-25. Another variation of a similar problem can happen if network cloud Y sends external EIGRP routes of 150.150.0.0/16 to Router B, and Router B is running RIP and EIGRP but is getting the 150.150.0.0/16 routes from the RIP domain from Router A. Because RIP has a lower administrative distance (120) than external EIGRP routes (170), Router B installs RIP routes for 150.150.0.0/16 only from Router A. Example 7-37 shows the EIGRP topology table for Router B.
Example 7-37 Router B's EIGRP Topology Table for 150.150.0.0/16
Router B# show ip eigrp topology 150.150.0.0 255.255.0.0
IP-EIGRP topology entry for 150.150.0.0/16
State is Passive, Query origin flag is 1, 0 Successor(s),
FD is 4294967295
Routing Descriptor Blocks:
192.168.1.2 (Serial0), from 192.168.1.2, Send flag is 0x0
Composite metric is (2707456/2195456), Route is External
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 41000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
External data:
Originating router is 155.155.155.1
AS number of routes is 0
External protocol is OSPF, external metric is 64
Administrator tag is 0
The EIGRP topology table shows that the feasible distance (FD) is inaccessible (4294967295); the route is an external route that has been redistributed from OSPF. This means that Router B is receiving the 150.150.0.0/16 routes from Router C but is setting the FD as inaccessible because Router B is not using the EIGRP route in the routing table. As a matter of fact, the routing table entry in Router B is a RIP route for 150.150.0.0/16, as shown in Example 7-38. In other words, when the FD is inaccessible in the EIGRP topology table, the router is not using that EIGRP route in its routing table. Usually, the route is overridden by another routing protocol that has lower administrative distance.
Example 7-38 Routing Table of Router B Showing 150.150.0.0/16 Route as a RIP Route
Router_B#show ip route 150.150.0.0 Routing entry for 150.150.0.0/16 Known via "rip", distance 120, metric 5 Redistributing via rip Last update from 192.168.2.2 on Serial1, 00:00:24 ago Routing Descriptor Blocks: *192.168.2.2, from 192.168.2.2, 00:00:24 ago, via Serial1 Route metric is 5, traffic share count is 1
To fix this problem, you must change the administrative distance of the routing proto- cols so that external EIGRP routes are preferred. To do so, use the distance command to manipulate the administrative distance of a routing protocol. The configuration of Router B to fix this problem is shown in Example 7-39.
Example 7-39 Configuration Change on Router B to Fix the Route-Installation Problem Because of Higher Administrative Distance
Router B# interface ethernet 0 ip address 172.16.2.1 255.255.255.0 interface serial 0 192.168.1.1 255.255.255.0 interface serial 1 192.168.2.1 255.255.255.0 router eigrp 1 network 172.16.0.0 network 192.168.1.0 network 192.168.2.0 router rip network 172.16.0.0 network 192.168.2.0 distance 180 192.168.2.2 255.255.255.255
The distance command shown in Example 7-39 sets the RIP administrative distance to 180 for any updates coming from 192.168.2.2. This allows the external EIGRP routes (administrative distance of 170) coming from Router C to be preferred over RIP routes. Example 7-40 shows the result.
Example 7-40 Routing Table of Router B Now Showing Summary Route Coming from Router C
Router_B#show ip route 150.150.0.0 Routing entry for 150.150.0.0/16 Known via "eigrp 1", distance 90, metric 2195456, type internal Redistributing via eigrp 1 Last update from 192.168.1.2 on Serial0, 00:26:14 ago Routing Descriptor Blocks: *192.168.1.2, from 192.168.1.2, 00:26:14 ago, via Serial0 Route metric is 2195456, traffic share count is 1 Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
EIGRP Is Not Installing Routes—Cause: Duplicate Router IDs
Many times, EIGRP will not install routes because of a duplicate router ID problem. EIGRP does not use router ID as extensively as OSPF. EIGRP uses the notion of router ID only on external routes to prevent loops. EIGRP chooses the router ID based on the highest IP address of the loopback interfaces on the router. If the router doesn't have any loopback interfaces, the highest active IP address of all the interfaces is chosen as the router ID for EIGRP. Figure 7-26 shows the network setup for such a case study on EIGRP router IDs.
)
Figure 7-26 EIGRP Network Susceptible to EIGRP Not Installing Routes Because of Duplicate Router IDs
Example 7-41 shows the pertinent configurations for the cause of this problem.
Example 7-41 Configurations for Routers A, B, C, and X in Figure 7-26
Router A# interface ethernet 0 ip address 192.168.1.1 255.255.255.0 interface serial 0 ip address 10.1.1.1 255.255.255.0 Router B# interface serial 0 IP address 10.1.1.2 255.255.255.0 interface serial 1 IP address 10.1.2.1 255.255.255.0 Router C# interface serial 0 ip address 10.1.2.2 255.255.255.0 Router X# interface loopback 0 ip address 192.168.1.1 255.255.255.255
Router X is redistributing a route of 150.150.0.0/16 from OSPF into EIGRP and is sending the route several hops to Router C. Router C receives the route and sends the route as EIGRP external routes to Router B. Router B installs the route in the routing table and sends it to Router A. The debug output in Example 7-42 verifies how Router B sends the route to Router A.
Example 7-42 debug ip eigrp Command Output on Router B
Router B# debug IP EIGRP IP-EIGRP: 150.150.0.0/16 – do advertise out serial 0
The problem is that Router A is not installing the 150.150.0.0/16 route in the routing table. As a matter of fact, Router A is not showing the 150.150.0.0/16 route in its topology table. Going back to Router B, the route is in the routing table, and the topology table appears as shown in Example 7-43.
Example 7-43 EIGRP Topology Table for 150.150.0.0/16 on Router B
Router B# show ip eigrp topology 150.150.0.0 255.255.0.0
IP-EIGRP topology entry for 150.150.0.0/16
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3757056
Routing Descriptor Blocks:
10.1.2.2 (Serial1), from 10.1.2.2, Send flag is 0x0
Composite metric is (3757056/3245056), Route is External
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 82000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 7
External data:
Originating router is 192.168.1.1
AS number of routes is 0
External protocol is OSPF, external metric is 64
Administrator tag is 0
Router B shows that it is getting the routes from Router C. By looking at the external data section, notice that the originating router is 192.168.1.1, which is seven hops away. The original protocol that originated the route 150.150.0.0/16 is OSPF with the metric of 64. Notice that the originating router is 192.168.1.1. Looking back at the configuration of Router A in Example 7-41, notice that Router A also has an IP address of 192.168.1.1 configured on Ethernet 0, and it is the highest IP address on the router. All this evidence points to a duplicate router ID problem in EIGRP that causes Router A not to install routes. Because Router X and Router A have the same router ID (192.168.1.1), when Router A receives the route from Router B, it looks at the external data section of the route to see who is the originating router. In this case, Router A sees the originating router as 192.168.1.1, which is its own router ID. Router A does not put the route in its topology table because it thinks that it is the originator of the route and that by receiving the route back from other neighbors, it must be a loop. So, to prevent a routing loop, Router A does not put the route of 150.150.0.0/16 in the topology table. Consequently, the route does not appear in the routing table.
Router A will not install any external routes that originate from Router X because external routes carry the router ID in their EIGRP update packet. Router A will install internal EIGRP routes from Router X without any problem. The duplicate router ID problem happens only for external routes.
The solution to the duplicate router ID problem is to change the IP address of the loopback interface of Router X or to change the IP address of Ethernet 0 in Router A. The rule of thumb: Never configure the same IP address on two places in the network. Change the loopback IP address of Router X to 192.168.9.1/32 to fix this problem (see Example 7-44). The result of the IP address change in Router X is the installment of the 150.150.0.0/16 route in Router A, as shown in Example 7-45.
Example 7-44 Loopback IP Address Change in Router X to Avoid Duplicate Router ID Problem
Router X#interface Loopback 0 IP address 192.168.9.1 255.255.255.255
Example 7-45 Routing Table and EIGRP Topology Table for 150.150.0.0/16 on Router A to Verify the Fix
Router_A#show ip route 150.150.0.0
Routing entry for 150.150.0.0/16
Known via "eigrp 1", distance 170, metric 4269056, type external
Redistributing via eigrp 1
Last update from 10.1.1.2 on Serial0, 00:06:14 ago
Routing Descriptor Blocks:
*10.1.1.2, from 10.1.1.2, 00:06:14 ago, via Serial0
Route metric is 4269056, traffic share count is 1
Total delay is 102000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 8
Router A# show ip eigrp topology 150.150.0.0 255.255.0.0
IP-EIGRP topology entry for 150.150.0.0/16
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 4269056
Routing Descriptor Blocks:
10.1.1.2 (Serial0), from 10.1.1.2, Send flag is 0x0
Composite metric is (4269056/3757056), Route is External
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 102000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 8
External data:
Originating router is 192.168.9.1
AS number of routes is 0
External protocol is OSPF, external metric is 64
Administrator tag is 0