Problem: IGRP Routes Are Flapping-Cause: Packet Drops on Sender s or Receiver s Interface

Problem: IGRP Routes Are Flapping ‚ Cause: Packet Drops on Sender's or Receiver's Interface

When IGRP is used in a large Frame Relay environment where there are several neigh-bors on one Frame Relay interface, there is a possibility of a packet loss. The packet loss in IGRP means that the whole update is lost. If a sender or receiver drops an IGRP update, it has to wait for another update because the IGRP updates are not retransmitted after it is lost.

The most common reason for packet drops on Frame Relay interfaces is a result of broad-cast drops in the broadcast queue of Frame Relay. Broadcast queues in Frame Relay are designed to carry all the broadcast traffic. If there is a lot of broadcast traffic, the broadcast queue needs to be tuned .

Figure 5-37 shows the network setup susceptible to a IGRP route-flapping problem.

Figure 5-37. Network Setup Conducive to Route Flapping

Figure 5-38 shows the flowchart to follow to solve this problem.

Figure 5-38. Problem-Resolution Flowchart

Debugs and Verification

The show ip route output in Example 5-93 shows that the routes are 3:08 old, so it has missed two updates. If IGRP does not receive a route for 270 seconds, the route will be put into holddown. This situation gets corrected by itself, but, in some cases, changes to the configuration are required. For example, consider the output in Example 5-93.

Example 5-93 show ip route igrp Command Output Indicates That IGRP Did Not Receive Updates for 3 Minutes and 8 Seconds

 Hub#  show ip route igrp  I   155.155.0.0/16 [100/8242] via 131.108.1.1,  00:03:08  , Serial0 I   166.166.0.0/16 [100/8242] via 131.108.1.1,  00:03:08  , Serial0 

The output in Example 5-93 shows that no IGRP update has been received since 3 minutes and 8 seconds. This means that two IGRP updates have been missed.

Example 5-94 shows that there are a large number of broadcast drops on the interface. The broadcast queue size also is 64, which is the default, and it must be increased.

Example 5-94 Serial Interface Shows That the Broadcast Queue Is Dropping a Large Number of Packets

 Hub#  show interface serial 0  Serial0 is up, line protocol is up Hardware is MK5025 Description: Charlotte Frame Relay Port DLCI 100 MTU 1500 bytes, BW 1024 Kbit, DLY 20000 usec, rely 255/255, load 44/255 Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec) LMI enq sent 7940, LMI stat recvd 7937, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE  Broadcast queue 64/64, broadcasts sent/dropped 1769202/1849660  , interface         broadcasts 3579215 

Solution

The output in Example 5-94 further proves that there is some problem at the interface level. Too many drops are occurring at the interface level. This is causing the route flapping. To correct this problem, you must tune the Frame Relay broadcast queue accordingly . Tuning the Frame Relay broadcast queue is beyond the scope of this book. Several papers on the Cisco web site discuss how to tune the Frame Relay broadcast queue:

www.cisco.com/warp/partner/synchronicd/cc/techno/media/wan/frame/prodlit/256_pb.htm

www.cisco.com/warp/public/125/20.html

Example 5-95 shows that after fixing the interface drop problem, route flapping disappears. The broadcast queue size is changed from 64 to 256. The correct number can be determined after reading the URL mentioned earlier for tuning the broadcast queue.

Example 5-95 Verifying That the Serial Interface Is Not Dropping Any Broadcast Traffic in the Broadcast Queue

 Hub#  show interface serial 0  Serial0 is up, line protocol is up Hardware is MK5025 Description: Charlotte Frame Relay Port DLCI 100 MTU 1500 bytes, BW 1024 Kbit, DLY 20000 usec, rely 255/255, load 44/255 Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec) LMI enq sent 7940, LMI stat recvd 7937, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE  Broadcast queue 0/256, broadcasts sent/dropped 1769202/0  , interface broadcasts         3579215 

Example 5-96 shows that the show ip routes output verifies that the routes are stable in the routing table.

Example 5-96 Verifying Stable Routes

 Hub#  show ip route igrp  I    155.155.0.0/16 [100/8242] via 131.108.1.1, 00:00:07, Serial0 I    166.166.0.0/16 [100/8242] via 131.108.1.1, 00:00:07, Serial0