Troubleshooting EIGRP

Chapter Description

Learn how to quickly identify and fix the most common causes of EIGRP problems with these debugs, configurations, and useful show commands.

Troubleshooting EIGRP Dial Backup Problem

Dial backup is a common setup on the remote access routers. When the primary link fails, dial backup provides another means of network connection. This section discusses EIGRP dial backup issues, in which the router doesn't disconnect the dialer interface when the primary link comes back. See the flowchart in Figure 7-35 for troubleshooting EIGRP dial-backup problems.

Figure 7-35Figure 7-35 Flowchart for Troubleshooting EIGRP Dial-Backup Problems

Figure 7-36 shows the network setup for the case study on the EIGRP dial backup problem.

Figure 7-36Figure 7-36 Network Susceptible to EIGRP Dial-Backup Problems

As Figure 7-36 illustrates, Router A and Router B are connected by a T1 line as the primary link. The ISDN backup serves as the backup link if the primary link fails. Example 7-67 shows the configurations for Routers A and B.

Example 7-67 Configurations for Routers A and B in Figure 7-36

Router A# isdn switch-type basic-5ess
interface ethernet 0
  ip address 172.16.1.1 255.255.255.128
interface serial 0
  ip address 172.16.2.1 255.255.255.0
  
  
interface bri 0
  ip address 172.16.3.1 255.255.255.0
  encapsulation ppp
  dialer map ip 172.16.3.2 name Router B broadcast 1234567
  ppp authentication chap
dialer-group 1
router EIGRP 1
  network 172.16.0.0
access-list 101 deny eigrp any any
access-list 101 permit ip any any
dialer-list 1 protocol ip list 101
ip route 172.16.4.0 255.255.255.128 172.16.3.2 200
Router B# isdn switch-type basic-5ess
interface ethernet 0
  ip address 172.16.4.1 255.255.255.128
interface serial 0
  ip address 172.16.2.2 255.255.255.0
interface bri 0
  ip address 172.16.3.2 255.255.255.0
  encapsulation ppp
  dialer map IP 172.16.3.1 name Router_A broadcast 3456789
  ppp authentication chap
dialer-group 1
router eigrp 1
  network 172.16.0.0
access-list 101 deny eigrp any any
access-list 101 permit ip any any
dialer-list 1 protocol ip list 101
ip route 172.16.1.0 255.255.255.128 172.16.3.1 200

From the configuration, the backup is done through the floating static route at the end of the configuration. When the primary interface (Serial 0) is down, the primary EIGRP route goes away and the floating static route is installed in the routing table that uses the BRI port. The dialer list is tied with access-list 101, which initiates the dial with any IP packet except for EIGRP hellos. This will not cause the BRI link to continuously dial because of EIGRP hello packets.

In this scenario, when the primary link goes down, the BRI link comes up and passes traffic because of the floating static route. The network administrator is trying to fix the link problem; in doing so, the network administrator reloaded Router B. When Router B came back up, the primary link also came up. The problem is that now even when the primary link came back up, the BRI link is still up and the traffic still is passing through BRI port.

On Router A, you must verify that the routing table entry for the interesting traffic is correct. Example 7-68 shows the output of show ip route 172.16.4.0 on Router A.

Example 7-68 Routing Table for 172.16.4.0

Router A# show ip route 172.16.4.0 

Routing entry for 172.16.4.0/25
 Known via "static", distance 200, metric 0
 Routing Descriptor Blocks:
 * 172.16.3.2
  Route metric is 0, traffic share count is 1

The output in Example 7-68 shows that Router A still is installing the floating static route to Router B's Ethernet network. The next step is to make sure that EIGRP neighbors are properly established between Router A and Router B over the primary interface. You can verify this with the show ip eigrp neighbor command, as demonstrated on both Router A and Router B in Example 7-69.

Example 7-69 Verifying an EIGRP Neighbor Relationship Between Routers A and B

Router A# show ip eigrp neighbor

IP-EIGRP neighbors for process 1
H  Address  Interface  Hold  Uptime  SRTT  RTO   Q  Seq
               (sec) (ms)            Cnt  Num
0  172.16.2.2 S0     12  00:10:23   21   200   0  23
1  172.16.3.2 BRI0    12   00:10:23   40   240   0  50  
Router B# show ip eigrp neighbor

IP-EIGRP neighbors for process 1
H  Address  Interface  Hold  Uptime  SRTT  RTO   Q  Seq
              (sec)  (ms)           Cnt  Num
0  172.16.2.1 S0     12  00:10:30   21  200    0   24
1  172.16.3.1 BRI0    12  00:10:30   40  240    0   51

The neighbor relationship looks fine from both routers. Both Routers A and B show that the neighbors are established without a problem. The next step is to look at the configuration on Router B to make sure that everything is configured properly. Example 7-70 shows Router B's configuration after reload.

Example 7-70 Router B Configuration After Reload

Router B# interface ethernet 0
  ip address 172.16.4.1 255.255.255.0
interface serial 0
  ip address 172.16.2.2 255.255.255.0
interface bri 0
  ip address 172.16.3.2 255.255.255.0
  encapsulation PPP
  dialer map IP 172.16.3.1 name Router A broadcast xxx
  ppp authentication chap
dialer-group 1
router eigrp 1
  network 172.16.0.0
access-list 101 deny eigrp any any
access-list 101 permit IP any any
dialer-list 1 protocol IP list 101
ip route 172.16.1.0 255.255.255.128 172.16.3.1 200

Notice that now, in Ethernet 0's configuration in Router B, the IP address is 172.16.4.1 255.255.255.0; the mask has changed from /25 to /24. This is the cause of the problem. When Router B advertises its Ethernet 0 route to Router A, it advertises the 172.16.4.0/24 route to Router A, and Router A still installs the floating static route of 172.16.4.0/25. The routing table shows the /25 route because it has a longer subnet mask. The wrong mask appears because when the network administrator reloaded Router B, Router B used the old configuration that it had stored, and Ethernet 0's old subnet mask a /24 before the network administrator changed it to /25. When the change is made, the network administrator didn't save the configuration.

The solution to this problem is to change the IP address subnet mask in Router B to the /25 subnet mask. Example 7-71 shows the configuration for Router B's Ethernet 0 interface.

Example 7-71 Properly Configuring the Subnet Mask for Router B's Ethernet 0 Interface

Router B# interface ethernet 0
  ip address 172.16.4.1 255.255.255.128

This change now causes Router B to send an EIGRP update of 172.16.4.0/25 to Router A, which causes Router A to use the EIGRP route instead of the floating static route. Example 7-72 shows what Router A's routing table now looks like.

Example 7-72 Routing Table for 172.16.4.0 on Router A After the Configuration Change in Example 7-71

Router A# show ip route 172.16.4.0 

Routing entry for 172.16.4.0/25
Known via "EIGRP 1", distance 90, metric 2195456, type internal
 Redistributing via eigrp 1
 
Last update from 172.16.2.2 on Serial 0
, 00:10:30 ago
 Routing Descriptor Blocks:
 * 172.16.2.2, from 172.16.2.2, 00:10:30 ago, via Serial 0
  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

The traffic stops flowing to the BRI 0 interface and starts to flow to the primary link. The BRI interface then goes down and moves to backup mode again.

8. EIGRP Error Messages | Next Section Previous Section