Home > Articles > Cisco Certification > CCNA Routing and Switching > Cisco ICND2 Foundation Learning Guide: Implementing an EIGRP Solution

Cisco ICND2 Foundation Learning Guide: Implementing an EIGRP Solution

Chapter Description

To assist in your studies for the ICND2 exam, this chapter reviews the basics of dynamic routing and examines the operation, configuration, and troubleshooting of EIGRP for IPv4 and IPv6.

Troubleshooting EIGRP

The ability to troubleshoot problems related to the exchange of routing information and missing information from the routing table is one of the most essential skills for a network engineer who is involved in the implementation and maintenance of a routed enterprise network that uses a routing protocol.

This section provides a suggested troubleshooting flow and explains the Cisco IOS commands that you can use to gather information from the EIGRP data structures and routing processes to detect and correct routing issues.

Components of Troubleshooting EIGRP

In troubleshooting EIGRP, as with any networking issue, follow a structured methodology. Figure 3-11 shows a suggested flowchart.

Figure 3-11

Figure 3-11 EIGRP Troubleshooting Flowchart

After configuring EIGRP, first test connectivity to the remote network, using ping. If the ping fails, check that the router has EIGRP neighbors and troubleshoot on a link-by-link basis. Neighbor adjacency might not be running for a number of reasons. Figure 3-12 provides a very basic design with two EIGRP neighbors connected by an Ethernet switch. The HQ router has three loopback interfaces, and both routers have two FastEthernet interfaces. One FastEthernet (0/0) interface from each router is connected to a switch. The switch has only one VLAN for all ports.

Figure 3-12

Figure 3-12 Simple Network Example

Now let’s examine a few potential scenarios, via show commands:

  • The interface between the devices is down:

    HQ# show ip interface brief
    Interface           IP-Address      OK?  Method     Status            Protocol
    FastEthernet0/0     192.168.1.20    YES  NVRAM      down              down
    FastEthernet0/1     10.5.0.1        YES  NVRAM      up                up
    Loopback1           5.5.5.5         YES  NVRAM      up                up
    Loopback30          2.2.2.2         YES  NVRAM      up                up
    Loopback100         1.1.1.1         YES  NVRAM      up                up

    In this case, FastEthernet0/0 is down. Possibilities include a disconnected cable, a down switch, or faulty hardware.

  • The two routers have mismatching EIGRP AS numbers:

    HQ# show ip protocol
    Routing Protocol is "eigrp 1"
    <output omitted>
    
    Branch# show ip protocol
    Routing Protocol is "eigrp 10"
    <output omitted>

    In this case, the Branch and HQ routers are misconfigured with different EIGRP AS numbers.

  • Proper interfaces are not enabled for the EIGRP process:

    HQ# show running-config
    <output omitted>
    router eigrp 1
    network 192.168.1.0 255.255.255.0
    <output omitted>
    
    HQ# show ip interface brief
    Interface          IP-Address         OK?    Method     Status        Protocol
    FastEthernet0/0    192.168.1.20       YES    NVRAM      up            up
    FastEthernet0/1    10.5.0.1           YES    NVRAM      up            up
    Loopback1          5.5.5.5            YES    NVRAM      up            up
    Loopback30         2.2.2.2            YES    NVRAM      up            up
    Loopback100        1.1.1.1            YES    NVRAM      up            up

    In this case, there is only a single interface configured for EIGRP.

  • The interface between the devices is up but can’t ping:

    HQ# show ip interface brief
    Interface        IP-Address           OK?    Method     Status        Protocol
    FastEthernet0/0  192.168.1.20         YES    NVRAM      up            up
    FastEthernet0/1  10.5.0.1             YES    NVRAM      up            up
    Loopback1        5.5.5.5              YES    NVRAM      up            up
    Loopback30       2.2.2.2              YES    NVRAM      up            up
    Loopback100      1.1.1.1              YES    NVRAM      up            up
    Branch# show ip interface brief
    Interface        IP-Address           OK?    Method     Status        Protocol
    FastEthernet0/0  192.168.1.25         YES    NVRAM      up            up
    FastEthernet0/1  10.20.0.1            YES    NVRAM      up            up

    In this case, a potential Layer 2 problem exists. This could be a misconfigured switch port and/or VLAN misconfiguration.

  • An interface is configured as passive:

    HQ# show running-config
    <output omitted>
    router eigrp 1
      passive-interface FastEthernet0/0
    network 192.168.1.0 255.255.255.0
    <output omitted>

    In this case, a passive-interface is configured. The show ip protocols command will also identify passive interfaces.

Aside from the issues reviewed here, there are a number of other, more advanced concerns that can prevent neighbor relationships from forming. Two examples are misconfigured EIGRP authentication or mismatched K values, depending on which EIGRP calculates its metric. The next section covers specifically neighbor adjacency.

Troubleshooting EIGRP Neighbor Issues

The previous section examined several possible reasons why EIGRP might not be working properly. This section takes a closer look at troubleshooting EIGRP neighbor relationships. As previously mentioned, a major prerequisite for the neighbor relationship to form between routers is Layer 3 connectivity. By investigating the output of show ip interface brief, you can verify that the status and protocol are both up for the interface between the routers. In Figure 3-13 and Example 3-10, the Serial0/0/0 interface that is connected to the Branch router is up. A successful ping then confirms IP connectivity between routers.

Figure 3-13

Figure 3-13 Determining If the Interface Is Operational

Example 3-10 Verifying Protocol and Status of Link Between Neighbors

Branch# show ip interface brief
Interface              IP-Address      OK?     Method      Status            Protocol
GigabitEthernet0/0     10.1.1.1        YES     NVRAM       up                up
Serial0/0/0            192.168.1.1     YES     NVRAM       up                up

Branch# ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

If the ping is not successful, as shown in Example 3-10, you should use the technologies discussed in Chapter 2, “Troubleshooting Basic Connectivity.” First, check the cabling and verify that the interfaces on connected devices are on a common subnet.

If you notice a log message such as the following that states that EIGRP neighbors are “not on common subnet,” this indicates that there is an improper IP address on one of the two EIGRP neighbor interfaces:

*Mar  28 04:04:53.778: IP-EIGRP(Default-IP-Routing-Table:100): Neighbor
192.168.100.1 not on common subnet for Serial0/0/0

If this message was received on the Branch router, you can see that the reported IP address of the neighbor does not match what you expected. However, you can still have an IP address mismatch and not see this message.

Next, check that the AS numbers are the same between neighbors. The command that starts the EIGRP process is followed by the AS number, router eigrp as_number. This AS number is significant to the entire network, as it must match between all the routers within the same routing domain. In other routing protocols, the numbering used to start the process may have only local significance (for instance, the OSPF routing protocol is started with a process-id and does not use an AS number).

In Figure 3-14 and Example 3-11, show ip protocols helps to determine if the AS numbers match.

Figure 3-14

Figure 3-14 Determining AS Numbers

Example 3-11 Using show ip protocols to Verify EIGRP AS Numbers

Branch# show ip protocols
Routing Protocol is "EIGRP 1"
<output omitted>

HQ# show ip protocols
Routing Protocol is "EIGRP 2"
<output omitted>

Also confirm that EIGRP is running on the correct interfaces. The network command configured under the EIGRP routing process indicates which router interfaces will participate in EIGRP.

The show ip eigrp interfaces interface command shows you which interfaces are enabled for EIGRP. If connected interfaces are not enabled for EIGRP, then neighbors will not form an adjacency. If an interface is not on the list, that means the router is not communicating EIGRP through that interface. Figure 3-15 shows that EIGRP is running on the Branch router. Run the same command on the HQ router and look for the same results. In this case, both routers are neighbors.

Figure 3-15

Figure 3-15 EIGRP Interface Enabled

You can also check the interface by referring to the “Routing for Networks” section of the show ip protocols command output. As shown in Example 3-12, this indicates which networks have been configured; any interfaces in those networks participate in EIGRP.

Example 3-12 Check the “Routing for Networks” Output

HQ# show ip protocols
<output omitted>
Routing Protocol is "eigrp 1"
 <output omitted>
Routing for Networks:
     172.16.0.0
     192.168.1.0
  Passive Interface(s):
      Serial0/0/0
 <output omitted>

With the show ip protocols command, you can also confirm if an interface is in passive mode only. The passive-interface command prevents both outgoing and incoming routing updates, because the effect of the command causes the router to stop sending and receiving hello packets over an interface. For this reason, routers do not become neighbors. An example where you would need to configure an interface as passive toward a specific LAN. You want to advertise LANs but don’t want to have the security risk of transmitting hello packets into the LAN. A final suggestion for checking a failed neighbor relationship is to confirm a mismatch in the authentication parameters. The key authentication configuration must match on both neighbors. The key number and key string should be checked in the running configuration.

Troubleshooting EIGRP Routing Table Issues

This section covers issues that cause missing entries in the routing table when proper connectivity and neighbor relationships exist. The exclusion of routes that should be in the routing table can be caused by routes not being advertised, by route filtering, or by network summarization. Missing routing entries due to these issues can be related to a problem either with a directly connected EIGRP neighbor or with an EIGRP router that is in another section of the network.

Issues Caused by Unadvertised Routes

Routing table issues caused by unadvertised routes are indicated by a failed ping test. Figure 3-16 illustrates the Branch/HQ example that has been implemented. It is established by checking the neighbor adjacency.

Figure 3-16

Figure 3-16 Troubleshooting EIGRP Routing Table Issues with the show ip protocols Command

In this case, checking the show ip protocols command output from the HQ router indicates the HQ router is not advertising 172.16.1.0/24. Adding the network statement to EIGRP, as demonstrated in Example 3-13, should resolve the issue.

Example 3-13 Adding the Correct Network Command

HQ(config)# router eigrp 1
HQ(config-router)# network 172.16.1.0

This should restore the routing table. If it does not, check route filtering. Route filtering can be performed by route maps or ACLs, as discussed in the next section.

Issues Caused by Route Filtering

Routing protocols can be configured to filter routes. This is a powerful tool, especially when connecting different routing domains (different AS). However, a misconfigured filter can be difficult to detect.

When investigating filtering issues, first check the show ip protocols command, as demonstrated in Example 3-14.

Example 3-14 Indentifying Incoming Filtering

Branch# show ip protocols
Routing Protocol is "eigrp 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is 1

As you can see, there is an ACL. Next, check the ACL, as shown in Example 3-15.

Example 3-15 Identifying Access List Used for Filtering

Branch# show ip access-lists
Standard IP access list 1
    10 deny   172.16.0.0, wildcard bits 0.0.255.255 (2 matches)
    20 permit any (6 matches)

The ACL matches the missing network. In this case, remove the ACL from the EIGRP configuration, as demonstrated in Example 3-16.

Example 3-16 Removing the Distribute List Used for Filtering

Branch# config t
Enter configuration commands, one per line.  End with CNTL/Z.
Branch(config)# router EIGRP 1
Branch(config-router)# no distribute-list 1 in

The console output shows the change in the adjacency after changing the configuration, as demonstrated in Example 3-17.

Example 3-17 Console Reporting Neighbor Change Due to Reconfiguration

*Mar  1 00:17:37.775: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.1 (FastEthernet0/0) is down: route configuration changed
*Mar  1 00:17:41.431: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.1 (FastEthernet0/0) is up: new adjacency

Take notice of the “in” on the distribute-list. ACLs can be placed in both inbound and outbound directions. Inbound and outbound lists are structured the same, but the transmission or reception of routes is controlled by direction.

Issues Caused by Automatic Network Summarization

EIGRP can be configured to automatically summarize routes at classful boundaries. If you have discontiguous networks, automatic summarization can cause inconsistencies in the routing tables.

In Figure 3-17, Router B is not receiving individual routes for the 172.16.1.0/24 and 172.16.2.0/24 subnets. Both Router A and Router C automatically summarized those subnets to the 172.16.0.0/16 classful boundary when sending EIGRP update packets to Router C.

Figure 3-17

Figure 3-17 Automatic Summarization Issues

Router B has two routes to 172.16.0.0/16 in the routing table, which can result in inaccurate routing and packet loss, as shown in Example 3-18.

Example 3-18 Inaccurate Routing Entries

RouterB# show ip route
<output omitted>

 Gateway of last resort is not set
     10.0.0.0/24 is subnetted, 2 subnets
C     10.1.1.0 is directly connected, Serial0/2/0
C     10.2.2.0 is directly connected, Serial0/3/0
D   172.16.0.0/16 [90/2172416] via 10.1.1.1, 00:03:51, Serial0/2/0
                                   [90/2172416] via 10.2.2.3, 00:00:14, Serial0/3/0

In Example 3-19, automatic summarization is disabled by entering the no auto-summary command in the router eigrp configuration mode:

Example 3-19 Disable Automatic Summarization

RouterB(config)# router eigrp 1
RouterB(config-if)# no auto-summary
3. Implementing EIGRP for IPv6 | Next Section Previous Section