03-22-2004 06:34 AM - edited 03-02-2019 02:27 PM
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.
Solved! Go to Solution.
03-22-2004 01:46 PM
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:
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
03-22-2004 07:21 AM
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
03-22-2004 09:41 AM
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 dont 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.
03-22-2004 01:46 PM
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:
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide