cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3247
Views
0
Helpful
9
Replies

MTU Size for establishing EIGRP

dhanasekaran.r
Level 1
Level 1

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

9 Replies 9

a.alekseev
Level 7
Level 7

maybe the problem is inside the configurations on both sides?

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

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
Level 10
Level 10

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

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

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

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.

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

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: