cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
528
Views
3
Helpful
3
Replies

link flapping - eigrp

aoshea
Level 1
Level 1

Dear Network Professionals,

I have a customer who has recently implemented a new wan infrastructure (hub and spoke across mpls ISP) but when they do a large file copy between two of the spokes one of the neighbors drops off.

I got a feeling that I may need to define the bandwidth of the link and also the amount of bandwidth percentage the eigrp process should use.

This was not originally set up as the wan link is presented as an ethernet interface and the speed /duplex has been locked down at 10 Mbps / Full duplex.

Please find below extract showing the log of the two neighbours, I can provide the configs if required.

site a - log (attached)

site b - log

Your help is appreciated.

Many thanks,

Adrian.

1 Accepted Solution

Accepted Solutions

Hmmm.... EIGRP's not going to pace at 2MB/sec, so I'm not certain that setting the bandwith down is going to help. Setting the hello and hold timers out will help keep the neighbor from dropping, but it does sound like you need more of rate limiting than an rp side solution here.

I would look at CAR:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800c75ce.html

I'd make certain I have SPD configured up:

http://www.cisco.com/en/US/products/hw/routers/ps167/products_tech_note09186a008012fb87.shtml

But I'm not expert in this area, so perhaps someone who has more QOS background will chime in with more information.

:-)

Russ

View solution in original post

3 Replies 3

ruwhite
Level 7
Level 7

I would configure the bandwidth to what it really is across the link, and also set the hello timer to at least 30 seconds, with a dead interval of 90 seconds. It looks like you are having major problems getting hello's across the link, and possibly just normal multiast and unicast updates.

This:

Neighbor 172.16.31.14 (FastEthernet0/0.1103) is down: K-value mismatch

Is most likely a goodbye message, I'm guessing the router spitting this log message out is on an older IOS than the other one.

This:

Neighbor 172.16.31.14 (FastEthernet0/0.1103) is down: retry limit exceeded

Means we transmitted an update, query, or reply, and didn't get an ack, so we continued retransmitting it until the retransmit timer timed out (hold interval or 16 retries, whichever is longer).

This:

Neighbor 172.16.31.13 (FastEthernet0/0.1103) is down: holding time expired

Is just dropped hellos and other packets. EIGRP counts any packet received from a neighbor as a hello (a hello really just an empty update/reply/query, which are all the same thing with a different bit set).

Hope that helps....

:-)

Russ.W

Hi russ many thanks for your reply.

All the routers are running either 12.2 or 12.3.

I have asked the provider to check the circuit, but they don’t believe it is a fault their end.

Just one further question before I change the counters, the wan connection is presented as a 10 Mbps link, but the actual bandwidth across the ISP is only 2MB. If we set the bandwidth in eigrp to be 2MB it is only for its calculation and not to rate limit – is there a simple way to rate limit ?

Many thanks,

Adrian.

Hmmm.... EIGRP's not going to pace at 2MB/sec, so I'm not certain that setting the bandwith down is going to help. Setting the hello and hold timers out will help keep the neighbor from dropping, but it does sound like you need more of rate limiting than an rp side solution here.

I would look at CAR:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800c75ce.html

I'd make certain I have SPD configured up:

http://www.cisco.com/en/US/products/hw/routers/ps167/products_tech_note09186a008012fb87.shtml

But I'm not expert in this area, so perhaps someone who has more QOS background will chime in with more information.

:-)

Russ