RIP updates not received > 5 minutes sometimes?

[cwschultz]

2611 at remote site is connected via T1 frame-relay to DS3's. One PVC to my DS3/core and two PVC's to parent company DS3/core. The RIP updates from parent company always arrive within 30 second interval but RIP updates from my core are intermittent. Sometimes they arrive within 30 seconds however the majority of the time they can take up to 7 minutes.

Ping from core to remote never drops a packet and average RTT for 1000 1400 byte packets is 98ms.

As detailed below if RIP timer in sh ip prot is over 30 seconds issuing a clear ip rou will set the timer to 00 and the route will show up in the RIP database and route table.

There are several other remotes not exhibiting this behavior.

sho ip prot

Routing Protocol is "rip"

Sending updates every 30 seconds, next due in 8 seconds

Invalid after 180 seconds, hold down 180, flushed after 240

Outgoing update filter list for all interfaces is 3

Incoming update filter list for all interfaces is not set

Redistributing: rip

Default version control: send version 2, receive version 2

Interface Send Recv Triggered RIP Key-chain

Serial0/0.553 2 2

Serial0/0.753 2 2

Serial0/0.853 2 2

Automatic network summarization is not in effect

Maximum path: 4

Routing for Networks:

172.18.0.0

172.21.0.0

172.22.0.0

Passive Interface(s):

FastEthernet0/0

Routing Information Sources:

Gateway Distance Last Update

172.22.250.217 120 00:00:23

172.18.142.169 120 00:03:08

172.21.250.217 120 00:00:05

Distance: (default is 120)

clear ip rou *

sho ip prot

Routing Protocol is "rip"

Sending updates every 30 seconds, next due in 4 seconds

Invalid after 180 seconds, hold down 180, flushed after 240

Outgoing update filter list for all interfaces is 3

Incoming update filter list for all interfaces is not set

Redistributing: rip

Default version control: send version 2, receive version 2

Interface Send Recv Triggered RIP Key-chain

Serial0/0.553 2 2

Serial0/0.753 2 2

Serial0/0.853 2 2

Automatic network summarization is not in effect

Maximum path: 4

Routing for Networks:

172.18.0.0

172.21.0.0

172.22.0.0

Passive Interface(s):

FastEthernet0/0

Routing Information Sources:

Gateway Distance Last Update

172.22.250.217 120 00:00:01

172.18.142.169 120 00:00:00

172.21.250.217 120 00:00:01

Distance: (default is 120)

[steve.barlow]

I would try and "debug ip rip" on both ends to make sure both are indeed sending and that the packets are being received. Hopefully will help you eliminate one end as the problem.

Hope it helps.

Steve

[cwschultz]

The remote sees nothing consistiently on my PVC and the 7206 crashed last Friday when logging the debug output (145 RIP interfaces on this DS3). Can't see into the DS3 with Sniffer so at the present I can't verify production of updates on the 7206.

When I clear ip rou * Rip requests updates from all three PVC's and receives relpies from all three, even ours. It also sends flash updates into the core when the routes are cleared.

Am I into a buffer utilization issue?

cliff

[steve.barlow]

How many sites are affected? What is your system resources looking like (cpu, mem, input queue, buffers)? Is CEF enabled?

Packets destined to or originated from the router itself may experience higher than expected latency since they are often given a low priority access to the processor and need to wait a longer time to access the CPU. An example of this is icmp, but this doesn't apply to routing protocols.

Steve

[Erick Bergquist]

Do a show interface for the main/physical frame relay interfaces. On this show output will be a line that saids broadcast queue, etc with # of broadcasts, drops, etc.

This broadcast queue is shared between all the PVCs on this interface. Perhaps there is alot of broadcast traffic occuring and alot of the broadcasts are getting dropped and this remote site happens to see a RIP update every few minutes. You can increase the broadcast queue size if needed.

If there is alot of broadcast drops, perhaps consider changing to a different routing protocol that doesn't send broadcasts as often as RIP.

Erick