MTU Size for establishing EIGRP

Unanswered Question
Jul 7th, 2008
User Badges:

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


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
a.alekseev Mon, 07/07/2008 - 12:03
User Badges:
  • Gold, 750 points or more

maybe the problem is inside the configurations on both sides?

dhanasekaran.r Mon, 07/07/2008 - 12:07
User Badges:

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


dhanasekaran.r Mon, 07/07/2008 - 12:09
User Badges:

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

scottmac Mon, 07/07/2008 - 12:48
User Badges:
  • Green, 3000 points or more

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


dhanasekaran.r Mon, 07/07/2008 - 12:51
User Badges:

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

dhanasekaran.r Mon, 07/07/2008 - 14:19
User Badges:

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


bvsnarayana03 Mon, 07/07/2008 - 21:35
User Badges:
  • Silver, 250 points or more

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.

dhanasekaran.r Tue, 07/08/2008 - 10:16
User Badges:

To My knowledge also MTU never played important role in forming adjacency. Still awaiting help from experts..

burkland Fri, 07/11/2008 - 16:15
User Badges:

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.

Actions

This Discussion