Section 37 – Troubleshooting EIGRP

Section 37 Tasks

  • Read today’s lesson notes (below)
  • Review yesterday’s lesson notes

Enhanced Interior Gateway Routing Protocol is a Cisco-proprietary advanced Distance Vector routing protocol. As a CCNA network engineer, it is important that you understand how to support EIGRP, as it is a very commonly implemented routing protocol. As with the previous technologies described thus far in this guide, in order to troubleshoot and support networks running EIGRP, you must have a solid understanding of the inner workings of the protocol itself.

While it is not possible to delve into all potential EIGRP problem scenarios, this module will discuss some of the most common problem scenarios when EIGRP is implemented as the Interior Gateway Protocol (IGP) of choice.

Today you will learn about the following:

  • Troubleshooting neighbour relationships
  • Troubleshooting route installation
  • Troubleshooting route advertisement
  • Debugging EIGRP routing issues

This lesson maps to the following CCNA syllabus requirement:

  • Troubleshoot and resolve EIGRP problems
    • Neighbour adjancies
    • AS number
    • Load balancing
    • Split horizon

Troubleshooting Neighbour Relationships

It is important to understand that simply enabling EIGRP between two or more routers does not guarantee that a neighbour relationship will be established. In addition to certain parameters-matching, additional factors can also result in a failure of EIGRP neighbour relationship establishment. The EIGRP neighbour relationship may not establish due to any of the following:

  • The neighbour routers are not on a common subnet
  • Mismatched primary and secondary subnets
  • Mismatched K values
  • Mismatched ASN
  • Access control lists are filtering EIGRP packets
  • Physical Layer issues
  • Data Link Layer issues
  • Mismatched authentication parameters

Uncommon subnet issues are one of the most common problems experienced when attempting to establish EIGRP neighbour relationships. When EIGRP cannot establish a neighbour relationship because of an uncommon subnet, the following error message will be printed on the console, or will be logged by the router or switch:

*Mar 2 22:12:46.589 CST: IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 150.1.1.2 not on common subnet for FastEthernet0/0
*Mar 2 22:12:50.977 CST: IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 150.1.1.2 not on common subnet for FastEthernet0/0

The most common reason for the neighbour routers being on an uncommon subnet is a misconfiguration issue. It may be that the router interfaces have been accidentally configured on two different subnets. However, if the neighbours are connected via a VLAN, it is possible that Multicast packets could be leaking between VLANs, resulting in this error. The first troubleshooting step, however, simply would be to verify the interface configuration on the devices. Following this, additional troubleshooting steps, such as VLAN troubleshooting (if applicable) could be undertaken to isolate and resolve the issue.

Another common reason for this error message is using secondary addresses when attempting to establish EIGRP neighbour relationships. Again, the simplest way to troubleshoot such issues is to verify the router or switch configurations. For example, assume the error message above was being printed on the console of the local router. The first troubleshooting step would be to validate the IP addresses configured on the interface, as follows:

R1#show running-config interface FastEthernet0/0
Building configuration...
Current configuration : 140 bytes
!
interface FastEthernet0/0
ip address 150.2.2.1 255.255.255.0
duplex auto
speed auto
end

Next, validate that the configuration is the same on the device with the IP address 150.1.1.2, as follows:

R2#show running-config interface FastEthernet0/0
Building configuration...
Current configuration : 140 bytes
!
interface FastEthernet0/0
ip address 150.2.2.2 255.255.255.0 secondary
ip address 150.1.1.2 255.255.255.0
duplex auto
speed auto
end

From the output above, you can see that the primary subnet on R1 is the secondary subnet on the local router. EIGRP will not establish neighbour relationships using a secondary address. The resolution for this issue simply would be to correct the IP addressing configuration under the FastEthernet0/0 interface of R2, as follows:

R2#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#interface FastEthernet0/0
R2(config-if)#ip address 150.2.2.2 255.255.255.0
R2(config-if)#ip address 150.1.1.2 255.255.255.0 secondary
R2(config-if)#end
*Oct 20 03:10:27.185 CST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 150.2.2.1 (FastEthernet0/0) is up: new adjacency

EIGRP K values are constants that are used to distribute weight to different path aspects, which may be included in the composite EIGRP metric. Once again, the default values for the K values are K1 = K3 = 1 and K2 = K4 = K5 = 0. If changed on one router or switch, then these values must be adjusted for all other routers or switches within the autonomous system. The default EIGRPK values can be viewed using the show ip protocols command, as illustrated below:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is 1
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150, ospf 1
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    10.1.0.0/24
    172.16.1.0/30
  Routing Information Sources:
    Gateway         Distance      Last Update
    (this router)         90      15:59:19
    172.16.0.2            90      12:51:56
    172.16.1.2            90      00:27:17
  Distance: internal 90 external 170

When K values are reset on a router, all neighbour relationships for the local router will be reset. If the values are not consistent on all routers following the reset, the following error message will be printed on the console, and the EIGRP neighbour relationship(s) will not be established:

*Oct 20 03:19:14.140 CST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 150.2.2.1 (FastEthernet0/0) is down: Interface Goodbye received
*Oct 20 03:19:18.732 CST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 150.2.2.1 (FastEthernet0/0) is down: K-value mismatch

NOTE: While EIGRP K values can be adjusted using the metric-weights command, this is not recommended without assistance from seasoned network engineers or the Technical Assistance Centre (TAC).

Unlike OSPF, which uses a locally significant process ID, EIGRP requires the same ASN (among other variables) when establishing neighbour relationships with other routers. Troubleshoot such issues by comparing configurations of devices and ensuring that the ASN (among other variables) is consistent between routers that should establish neighbour relationships. A good indicator that neighbours are in a different AS would be a lack of bidirectional Hellos, even in the presence of basic IP connectivity between the routers. This can be validated using the show ip eigrp traffic command, the output of which is illustrated in the section that follows.

ACLs and other filters are also common causes for routers failing to establish EIGRP neighbour relationships. Check router configurations and those of intermediate devices to ensure that EIGRP or Multicast packets are not filtered. A very useful troubleshooting command to use is the show ip eigrp traffic command. This command provides statistics on all EIGRP packets. Assume, for example, that you have verified basic connectivity and configurations between two devices, but the EIGRP neighbour relationship is still not up. In that case, you could use this command to check to see whether the routers are exchanging Hello packets, before enabling debugging on the local device, as illustrated below:

R2#show ip eigrp traffic
IP-EIGRP Traffic Statistics for AS 2
Hellos sent/received: 144/0
Updates sent/received: 0/0
Queries sent/received: 0/0
Replies sent/received: 0/0
Acks sent/received: 0/0
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0
Hello Process ID: 149
PDM Process ID: 120
IP Socket queue:   0/2000/0/0 (current/max/highest/drops)
Eigrp input queue: 0/2000/0/0 (current/max/highest/drops)

In the output above, notice that the local router has not received any Hello packets, although it has sent out 144 Hellos. Assuming that you have verified IP connectivity between the two devices, as well as the configuration, you could also check ACL configurations on the local routers, as well as intermediate devices (if applicable), to ensure that EIGRP or Multicast traffic is not being filtered. For example, you might find an ACL that is configured to deny Class D and Class E traffic, while allowing all other traffic, such as the following ACL:

R2#show ip access-lists
Extended IP access list 100
    10 deny ip 224.0.0.0 15.255.255.255 any
    20 deny ip any 224.0.0.0 15.255.255.255 (47 matches)
    30 permit ip any any (27 matches)

Physical and Data Link Layer issues, and ways in which these can affect routing protocols and other traffic, have been described in detail in previous modules. You can troubleshoot these issues using the show interfaces, show interfaces counters, show vlan, and show spanning-tree commands, among other commands described in those modules. To avoid being redundant, we will not restate the Physical and Data Link Layer troubleshooting steps.

Finally, common authentication configuration mistakes include using different key IDs when configuring key chains and specifying different or mismatched passwords. When authentication is enabled under an interface, the EIGRP neighbour relationships are reset and reinitialised. If previously established neighbour relationships do not come up following authentication implementation, verify the authentication configuration parameters by looking at the running configuration or using the show key chain and show ip eigrp interfaces detail [name] commands on the router. Following is a sample output of the information that is printed by the show key chain command:

R2#show key chain
Key-chain EIGRP-1:
    key 1 -- text “eigrp-1”
      accept lifetime (always valid) - (always valid) [valid now]
      send lifetime (always valid) - (always valid) [valid now]
Key-chain EIGRP-2:
    key 1 -- text “eigrp-2”
      accept lifetime (00:00:01 UTC Nov 1 2010) - (infinite)
      send lifetime (00:00:01 UTC Nov 1 2010) - (infinite)
Key-chain EIGRP-3:
    key 1 -- text “eigrp-3”
      accept lifetime (00:00:01 UTC Dec 1 2010) - (00:00:01 UTC Dec 31 2010)
      send lifetime (00:00:01 UTC Dec 1 2010) - (00:00:01 UTC Dec 31 2010)

The following is a sample output of the information that is printed by the show ip eigrp interfaces detail [name] command:

R2#show ip eigrp interfaces detail Serial0/0
IP-EIGRP interfaces for process 1
                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0              0        0/0        0        0/1            0           0
  Hello interval is 5 sec
  Next xmit serial <none>
  Un/reliable mcasts: 0/0  Un/reliable ucasts: 0/0
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0
  Retransmissions sent: 0  Out-of-sequence rcvd: 0
  Authentication mode is md5,  key-chain is “EIGRP-1”
  Use unicast

When troubleshooting in general, it is recommended that you use show commands in Cisco IOS software instead of enabling debug commands. While debugging provides real-time information, it is very processor intensive, and it could result in high CPU utilisation of the device and, in some cases, even crashing the device. In addition to show commands, you should also pay attention to the various error messages that are printed by the software, as these provide useful information that can be used to troubleshoot and isolate the root cause of the problem.

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:

Section 37 – Troubleshooting EIGRP 1

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:

R2#debug eigrp fsm
EIGRP FSM Events/Actions debugging is on
R2#
R2#
*Mar 13 03:24:31.983: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 150.1.1.1
(FastEthernet0/0) is up: new adjacency
*Mar 13 03:24:33.995: DUAL: dest(10.0.0.0/8) not active
*Mar 13 03:24:33.995: DUAL: rcvupdate: 10.0.0.0/8 via 150.1.1.1 metric 156160/128256
*Mar 13 03:24:33.995: DUAL: Find FS for dest 10.0.0.0/8. FD is 128256, RD is 128256
*Mar 13 03:24:33.995: DUAL:     0.0.0.0 metric 128256/0
*Mar 13 03:24:33.995: DUAL:     150.1.1.1 metric 156160/128256 found Dmin is 128256
*Mar 13 03:24:33.999: DUAL: RT installed 10.0.0.0/8 via 0.0.0.0

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 autosummary 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:

R1#show ip eigrp topology 2.2.2.2 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 2.2.2.2/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 156160
  Routing Descriptor Blocks:
  150.1.1.2 (FastEthernet0/0), from 150.1.1.2, Send flag is 0x0
      Composite metric is (156160/128256), Route is External
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 5100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 2.2.2.2
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)

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:

R2#show ip eigrp events
Event information for AS 1:
...
[Truncated Output]
21   03:05:39.747 Ignored route, neighbor info: 10.0.0.1 Serial0/0
22   03:05:39.747 Ignored route, dup router: 150.1.1.254
23   03:05:06.659 Ignored route, metric: 192.168.2.0 284160
24   03:05:06.659 Ignored route, neighbor info: 10.0.0.1 Serial0/0
25   03:05:06.659 Ignored route, dup router: 150.1.1.254
26   03:04:33.311 Ignored route, metric: 192.168.1.0 284160
27   03:04:33.311 Ignored route, neighbor info: 10.0.0.1 Serial0/0
28   03:04:33.311 Ignored route, dup router: 150.1.1.254
...
[Truncated Output]

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:

Section 37 – Troubleshooting EIGRP 2

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

Section 37 – Troubleshooting EIGRP 3

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.

Troubleshooting Route Advertisement

There are times when it may seem that EIGRP is either not advertising the networks that it has been configured to advertise or is advertising networks that it has not been configured to advertise. For the most part, such issues are typically due to router and switch misconfigurations. There are several reasons why EIGRP might not advertise a network that it has been configured to advertise. Some of these reasons include the following:

  • Distribute lists (outside CCNA syllabus)
  • Split horizon
  • Summarisation

Incorrectly configured distribute lists are one reason why EIGRP might not advertise a network that it has been configured to advertise. When configuring distribute lists, ensure that all networks that should be advertised are permitted by the referenced IP ACL or IP Prefix List.

Another common issue pertaining to network advertisement when using EIGRP is the default behaviour of split horizon. Split horizon is a Distance Vector protocol feature that mandates that routing information cannot be sent back out of the same interface through which it was received. This prevents the re-advertising of information back to the source from which it was learned, effectively preventing routing loops. This concept is illustrated in Figure 37.3 below:

Section 37 – Troubleshooting EIGRP 4

Figure 37.3 – EIGRP Split Horizon

The topology in Figure 37.3 illustrates a classic hub-and-spoke network, with router HQ as the hub router and routers S1 and S2 as the two spoke routers. On the Frame Relay WAN, each spoke router has a single DLCI provisioned between itself and the HQ router in a partial-mesh topology. By default, EIGRP split horizon is enabled for WAN interfaces connected to packetswitched networks, such as Frame Relay. This means that the HQ router will not advertise routing information learned on Serial0/0 out of the same interface.

The effect of this default behaviour is that the HQ router will not advertise the 10.1.1.0/24 prefix received from S1 to S2 because the route is received via the Serial0/0 interface, and the split horizon feature prevents the router from advertising information learned on that interface back out of the same interface. The same is also applicable for the 10.2.2.0/24 prefix the HQ router receives from S2. The recommended solution for this problem would be to disable the split horizon feature on the WAN interface using the no ip split-horizon eigrp [asn] interface configuration command on the HQ router.

By default, automatic summarisation at the classful boundary is enabled for EIGRP. This can be validated using the show ip protocols command. In addition to automatic summarisation, EIGRP also supports manual summarisation at the interface level. Regardless of the method implemented, summarisation prevents the more specific route entries that are encompassed by the summary from being advertised to neighbour routers. If route summarisation is configured incorrectly, it may appear that EIGRP is not advertising certain networks. For example, consider the basic network topology that is illustrated in Figure 37.4 below:

Section 37 – Troubleshooting EIGRP 5

Figure 37.4 – EIGRP Summarisation

Referencing Figure 37.4, all routers reside in EIGRP Autonomous System 150. R2 is advertising the 10.1.1.0/24, 10.1.2.0/24, and 10.1.3.0/24 subnets to R1 via EIGRP. R1, which also has an interface assigned to the 10.1.0.0/24 subnet, should in turn advertise these subnets to R3. The EIGRP configuration on router R2 has been implemented as follows:

R2(config)#router eigrp 150
R2(config-router)#network 10.1.1.0 0.0.0.255
R2(config-router)#network 10.1.2.0 0.0.0.255
R2(config-router)#network 10.1.3.0 0.0.0.255
R2(config-router)#network 172.16.1.0 0.0.0.3
R2(config-router)#no auto-summary
R2(config-router)#exit

The EIGRP configuration on R1 has been implemented as follows:

R1(config)#router eigrp 150
R1(config-router)#network 10.1.0.0 0.0.0.255
R1(config-router)#network 172.16.0.0 0.0.0.3
R1(config-router)#network 172.16.1.0 0.0.0.3
R1(config-router)#exit

Finally, the EIGRP configuration on R3 has been implemented as follows:

R3(config)#router eigrp 150
R3(config-router)#network 172.16.0.0 0.0.0.3
R3(config-router)#no auto-summary
R3(config-router)#exit

After this configuration, the routing table on R2 displays the following entries:

R2#show ip route eigrp
     172.16.0.0/30 is subnetted, 2 subnets
D       172.16.0.0 [90/2172416] via 172.16.1.1, 00:02:38, FastEthernet0/0
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D       10.0.0.0/8 [90/156160] via 172.16.1.1, 00:00:36, FastEthernet0/0

The routing table on R1 displays the following entries:

R1#show ip route eigrp
        172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D       172.16.0.0/16 is a summary, 00:01:01, Null0
        10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D       10.1.3.0/24 [90/156160] via 172.16.1.2, 00:21:01, FastEthernet0/0
D       10.3.0.0/24 [90/2297856] via 172.16.0.2, 00:00:39, Serial0/0
D       10.1.2.0/24 [90/156160] via 172.16.1.2, 00:21:01, FastEthernet0/0
D       10.1.1.0/24 [90/156160] via 172.16.1.2, 00:21:01, FastEthernet0/0
D       10.0.0.0/8 is a summary, 00:01:01, Null0

Finally, the routing table on R3 displays the following entries:

R3#show ip route eigrp
        172.16.0.0/30 is subnetted, 2 subnets
D       172.16.1.0 [90/2172416] via 172.16.0.1, 00:21:21, Serial0/0
        10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       10.0.0.0/8 [90/2297856] via 172.16.0.1, 00:01:15, Serial0/0

Because summarisation is enabled on R1, it appears that the EIGRP is no longer advertising the specific subnets encompassed by the 10.0.0.0/8 summary. To allow the specific subnets to be advertised via EIGRP, automatic summarisation should be disabled on R1, as illustrated below:

R1(config)#router eigrp 150
R1(config-router)#no auto-summary
R1(config-router)#exit

After this, the routing table on R3 would display the following route entries:

R3#show ip route eigrp
     172.16.0.0/30 is subnetted, 2 subnets
D       172.16.1.0 [90/2172416] via 172.16.0.1, 00:00:09, Serial0/0
     10.0.0.0/24 is subnetted, 5 subnets
D       10.1.3.0 [90/2300416] via 172.16.0.1, 00:00:09, Serial0/0
D       10.1.2.0 [90/2300416] via 172.16.0.1, 00:00:09, Serial0/0
D       10.1.1.0 [90/2300416] via 172.16.0.1, 00:00:09, Serial0/0
D       10.1.0.0 [90/2297856] via 172.16.0.1, 00:00:09, Serial0/0

The same would also be applicable to R2, which would now display the specific entries for the 10.1.0.0/24 and 10.3.0.0/24 subnets, as follows:

R2#show ip route eigrp
     172.16.0.0/30 is subnetted, 2 subnets
D       172.16.0.0 [90/2172416] via 172.16.1.1, 00:00:10, FastEthernet0/0
     10.0.0.0/24 is subnetted, 5 subnets
D       10.3.0.0 [90/2300416] via 172.16.1.1, 00:00:10, FastEthernet0/0
D       10.1.0.0 [90/156160] via 172.16.1.1, 00:00:10, FastEthernet0/0

Debugging EIGRP Routing Issues

While primary emphasis has been placed on the use of show commands in the previous sections, this final section describes some of the debugging commands that can also be used to troubleshoot EIGRP. Keep in mind, however, that debugging is very processor intensive and should be used only as a last resort (i.e., after all show commands and other troubleshooting methods and tools have been applied or attempted).

The debug ip routing [acl|static] command is a powerful troubleshooting tool and command. It should be noted, however, that while this command is not EIGRP-specific, it provides useful and detailed information on routing table events. Following is a sample of the information that is printed by this command:

R1#debug ip routing
IP routing debugging is on
R1#
*Mar 3 23:03:35.673: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
*Mar 3 23:03:35.673: RT: is_up: FastEthernet0/0 0 state: 4 sub state: 1 line: 0 has_route: True
*Mar 3 23:03:35.677: RT: interface FastEthernet0/0 removed from routing table
*Mar 3 23:03:35.677: RT: del 172.16.1.0/30 via 0.0.0.0, connected metric [0/0]
*Mar 3 23:03:35.677: RT: delete subnet route to 172.16.1.0/30
*Mar 3 23:03:35.677: RT: NET-RED 172.16.1.0/30
*Mar 3 23:03:35.677: RT: Pruning routes for FastEthernet0/0 (3)
*Mar 3 23:03:35.689: RT: delete route to 10.1.3.0 via 172.16.1.2, FastEthernet0/0
*Mar 3 23:03:35.689: RT: no routes to 10.1.3.0, flushing
*Mar 3 23:03:35.689: RT: NET-RED 10.1.3.0/24
*Mar 3 23:03:35.689: RT: delete route to 10.1.2.0 via 172.16.1.2, FastEthernet0/0
*Mar 3 23:03:35.689: RT: no routes to 10.1.2.0, flushing
*Mar 3 23:03:35.689: RT: NET-RED 10.1.2.0/24
*Mar 3 23:03:35.689: RT: delete route to 10.1.1.0 via 172.16.1.2, FastEthernet0/0
*Mar 3 23:03:35.689: RT: no routes to 10.1.1.0, flushing
*Mar 3 23:03:35.693: RT: NET-RED 10.1.1.0/24
*Mar 3 23:03:35.693: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 150: Neighbor 172.16.1.2 (FastEthernet0/0) is down: interface down
*Mar 3 23:03:39.599: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 150: Neighbor 172.16.1.2 (FastEthernet0/0) is up: new adjacency
*Mar 3 23:03:40.601: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
*Mar 3 23:03:40.601: RT: is_up: FastEthernet0/0 1 state: 4 sub state: 1 line: 1 has_route: False
*Mar 3 23:03:40.605: RT: SET_LAST_RDB for 172.16.1.0/30 NEW rdb: is directly connected
*Mar 3 23:03:40.605: RT: add 172.16.1.0/30 via 0.0.0.0, connected metric [0/0]
*Mar 3 23:03:40.605: RT: NET-RED 172.16.1.0/30
*Mar 3 23:03:40.605: RT: interface FastEthernet0/0 added to routing table
*Mar 3 23:03:49.119: RT: SET_LAST_RDB for 10.1.1.0/24 NEW rdb: via 172.16.1.2
*Mar 3 23:03:49.119: RT: add 10.1.1.0/24 via 172.16.1.2, eigrp metric [90/156160]

You can use this command in conjunction with an ACL to view information about the route or routes referenced in the ACL. Additionally, the same command can also be used for troubleshooting static route events on the local device. As a side note, instead of using this command, if you are running EIGRP, consider using the show ip eigrp events command instead, as it provides a history of EIGRP internal events and can be used to troubleshoot SIA issues, as well as route flaps and other events. Following is a sample of the information that is printed by this command:

R1#show ip eigrp events
Event information for AS 150:
1    23:03:49.135 Ignored route, metric: 192.168.3.0 28160
2    23:03:49.135 Ignored route, metric: 192.168.2.0 28160
3    23:03:49.135 Ignored route, metric: 192.168.1.0 28160
4    23:03:49.131 Rcv EOT update src/seq: 172.16.1.2 85
5    23:03:49.127 Change queue emptied, entries: 3
6    23:03:49.127 Ignored route, metric: 192.168.3.0 28160
7    23:03:49.127 Ignored route, metric: 192.168.2.0 28160
8    23:03:49.127 Ignored route, metric: 192.168.1.0 28160
9    23:03:49.127 Metric set: 10.1.3.0/24 156160
10   23:03:49.127 Update reason, delay: new if 4294967295
11   23:03:49.127 Update sent, RD: 10.1.3.0/24 4294967295
12   23:03:49.127 Update reason, delay: metric chg 4294967295
13   23:03:49.127 Update sent, RD: 10.1.3.0/24 4294967295
14   23:03:49.123 Route install: 10.1.3.0/24 172.16.1.2
15   23:03:49.123 Find FS: 10.1.3.0/24 4294967295
16   23:03:49.123 Rcv update met/succmet: 156160 128256
17   23:03:49.123 Rcv update dest/nh: 10.1.3.0/24 172.16.1.2
18   23:03:49.123 Metric set: 10.1.3.0/24 4294967295
19   23:03:49.123 Metric set: 10.1.2.0/24 156160
20   23:03:49.123 Update reason, delay: new if 4294967295
21   23:03:49.123 Update sent, RD: 10.1.2.0/24 4294967295
22   23:03:49.123 Update reason, delay: metric chg 4294967295
...
[Truncated Output]

In addition to the debug ip routing command, two additional EIGRP-specific debugging commands are also available in Cisco IOS software. The debug eigrp command can be used to provide real-time information on the DUAL Finite State Machine, EIGRP neighbour relationships, Non-Stop Forwarding events, packets, and transmission events. The options that are available with this command are illustrated below:

R1#debug eigrp ?
  fsm        EIGRP Dual Finite State Machine events/actions
  neighbors  EIGRP neighbors
  nsf        EIGRP Non-Stop Forwarding events/actions
  packets    EIGRP packets
  transmit   EIGRP transmission events

In addition to the debug eigrp command, the debug ip eigrp command prints detailed information on EIGRP route events, such as how EIGRP processes incoming updates. The additional keywords that can be used in conjunction with this command are illustrated below:

R1#debug ip eigrp ?
  <1-65535>      Autonomous System
  neighbor       IP-EIGRP neighbor debugging
  notifications  IP-EIGRP event notifications
  summary        IP-EIGRP summary route processing
  vrf            Select a VPN Routing/Forwarding instance
  <cr>

In conclusion, the following is a sample output of the debug ip eigrp command:

R1#debug ip eigrp
IP-EIGRP Route Events debugging is on
R1#
*Mar 3 23:49:47.028: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 150: Neighbor 172.16.1.2(FastEthernet0/0) is up: new adjacency
*Mar 3 23:49:47.044: IP-EIGRP(Default-IP-Routing-Table:150): 10.1.0.0/24 - do advertise out FastEthernet0/0
*Mar 3 23:49:47.044: IP-EIGRP(Default-IP-Routing-Table:150): Int 10.1.0.0/24 metric 128256 - 256 128000
*Mar 3 23:49:48.030: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
*Mar 3 23:49:56.179: IP-EIGRP(Default-IP-Routing-Table:150): Processing incoming UPDATE packet
*Mar 3 23:49:56.544: IP-EIGRP(Default-IP-Routing-Table:150): Processing incoming UPDATE packet
*Mar 3 23:49:56.544: IP-EIGRP(Default-IP-Routing-Table:150): Int 10.1.1.0/24 M 156160 - 25600 130560 SM 128256 - 256 128000
*Mar 3 23:49:56.544: IP-EIGRP(Default-IP-Routing-Table:150): route installed for 10.1.1.0 ()
*Mar 3 23:49:56.544: IP-EIGRP(Default-IP-Routing-Table:150): Int 10.1.2.0/24 M 156160 - 25600 130560 SM 128256 - 256 128000
*Mar 3 23:49:56.548: IP-EIGRP(Default-IP-Routing-Table:150): route installed for 10.1.2.0 ()
*Mar 3 23:49:56.548: IP-EIGRP(Default-IP-Routing-Table:150): Int 10.1.3.0/24 M 156160 - 25600 130560 SM 128256 - 256 128000
...
[Truncated Output]

Section 37 Questions

  1. Name at least three reasons for EIGRP neighbour relationships not forming.
  2. Which command can you use to verify EIGRP K values?
  3. Which command can you use to verify EIGRP packets statistics?
  4. Name at least two common reasons for EIGRP route installation failures.
  5. The administrative distance concept is used to determine how reliable the route source is. True or false?
  6. By default, EIGRP automatically summarises at classful boundaries and creates a summary route pointing to the Null0 interface. True or false?
  7. Which command can you can use to debug FSM events?
  8. Which command can you use to see the originating router ID of a specific prefix?
  9. Which command can you use to show the EIGRP event log?
  10. What is the best command to use when debugging various routing issues?

Section 37 Answers

  1. The neighbour routers are not on a common subnet; mismatched primary and secondary
    subnets; mismatched K values; mismatched ASN; ACLs are filtering EIGRP packets; Physical
    Layer issues; Data Link Layer issues; and mismatched authentication parameters.
  2. The show ip protocols command.
  3. The show ip eigrp traffic command.
  4. The same route is received via another protocol with a lower administrative distance;EIGRP summarisation; duplicate router IDs are present within the EIGRP domain; and the routes do not meet the Feasibility Condition.
  5. True.
  6. True.
  7. The debug eigrp fsm command.
  8. The show ip eigrp topology x.x.x.x y.y.y.y command.
  9. The show ip eigrp events command.
  10. The debug ip routing command.

Section 37 Lab

Repeat the EIGRP lab from the previous day. In addition, test the EIGRP troubleshooting commands presented in this lesson:

  • See the EIGRP parameters using the show ip protocol command
  • Modify K values on both routers and issue the command again
  • Notice that different configured K values lead to EIGRP neighbour relationships being lost
  • Verify the Hello packets being transmited by issuing the show ip eigrp traffic command
  • Test the debug eigrp fsm command
  • Test the show ip eigrp topology command for the advertised route and notice the originating RID; change the RID on the remote router and issue the command again
  • Verify the show ip eigrp events command
  • Start the debug IP routing before advertising the network into EIGRP; notice the generated debug updates


Related Articles

guest
0 Comments
Inline Feedbacks
View all comments