07-07-2008 11:43 AM - edited 03-03-2019 10:37 PM
Hi All,
I require a help to understand this.
We have Cisco 3845 with IOS c3845-spservicesk9-mz.124-17.bin.
We have at this end ATM interface and the other frame relay link.
While comisioning we got the folllowing error message
Jul 3 13:49:34.265: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor xxx.xx.xx.xxx (ATM4/0.52) is down: retry limit exceeded
Jul 3 13:49:36.717: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor XX.XX.XX.XX (ATM4/0.52) is up: new adjacency
Cisco recomended to use MTU size of 1500 and it resolved the problem.
Can somebody help me to understand what really made the eigrp to establish again with MTU size
07-07-2008 12:03 PM
maybe the problem is inside the configurations on both sides?
07-07-2008 12:07 PM
Thanks for your reply. The below is the new config
sh run int AT4/0.52
Building configuration...
Current configuration : 373 bytes
!
interface ATM4/0.52 point-to-point
description - Serial0.52
bandwidth 512
ip address XX.XX.XX.XXX 255.255.255.252
ip mtu 1420
ip pim sparse-mode
ip multicast ttl-threshold 16
ip multicast boundary MC_Low
pvc 1/52
vbr-nrt 636 318
oam-pvc manage
max-reserved-bandwidth 100
service-policy output Q-ATMsi
!
end
07-07-2008 12:09 PM
The other end config
interface Serial0.52 point-to-point
description 3845 ATM4/0.52
bandwidth 512
ip address XX.XX.XX.XX 255.255.255.252
ip accounting output-packets
ip pim sparse-mode
ip multicast ttl-threshold 16
ip multicast boundary MC_Med
frame-relay interface-dlci 52 IETF
class QPM_Q-FRsi-512-256
07-07-2008 12:48 PM
Most, if not all, routing protocols will not tolerate fragmentation ("Do not fragment" bit is set).
If fragmentation is required, the packet will be dropped.
What size MTU were you trying to use? I used to use this as a practical scenario for some of my students (crank down the MTU until the routing protocol breaks).
Good Luck
Scott
07-07-2008 12:51 PM
In the begining I did not use any MTU size in the interface. The EIGRP came up at MTU size 1500.
I would like to understand the Logic more
07-07-2008 02:19 PM
I was wondering this may be the answer
The Default MTU size in ATM interface is 4470 and in the serial interface is 1500.
This would be the cause for puting the MTU size 1500 in ATM interface at A end for EIGRP to establish
07-07-2008 09:35 PM
Thats strange. I have seen OSPF routers not forming adjacencies due to mtu mismatch. But mtu was never a criteria for neighbor forming in EIGRP. I'm also interested in knowing the role mtu plays here.
07-08-2008 10:16 AM
To My knowledge also MTU never played important role in forming adjacency. Still awaiting help from experts..
07-11-2008 04:15 PM
I did run into the same issue running a DS3 connection (2851 router) into a frame cloud with a circuit shaped back to 512Kbps....
I received the same error message and changing the MTU on the frame-relay sub-interface to 1500 fixed the issue.
I think it has something to do with the timers in EIGRP. One end is sending 4470byte packets which somehow ends up timing out before a acknowledgement is received.
I searched through the documentation on EIGRP, but I couldn't find an exact reason why this would occur mathematically.
Interestingly enough I had a DS3 (3845 router) connected to the same frame cloud and did not have this issue for 3 years....
Sorry to not offer a solution, but at least you know someone else sympathizes with your pain.
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