OSPF, mismatched MTU, 3550 vs. 2500

Answered Question
Oct 9th, 2007

I had an OSPF issue in a lab exercise yesterday concerning OSPF and MTU. One of my routers was not forming an adjacency on the Ethernet. On debugging, I found that it was due to an MTU mismatch.

Here is the situation. I had three devices on an OSPF broadcast network:

1. Router R1, a 2620, running a dot1q trunk into the switch. The trunk was carrying two VLANs, 20 and 30, and the router was bridging them with with IRB. The MTU on the BVI interface was 1500. This router was the OSPF DR.

2. Router R7, a 2520, connected to an access port on VLAN 30. This had an MTU of 1500 on its E0 interface.

3. Switch CAT1, a 3550, running an SVI on VLAN 20. This had an MTU of 1504 on the VLAN 20 interface.

I found that CAT1 would not exchange databases with R1 or R7 because of the mismatch in MTU.

I tried changing the MTU on R1 BVI 1, to 1504. This was successful in that R1 could now exchange databasees with CAT1, but now R7 could not talk to either of the others.

I tried changing the MTU on R7, but you cannot do that on a 2500.

I changed R1 back to MTU 1500, and tried changing CAT1, but I could not. Whatever I did, the MTU stayed stubbornly at 1504. I rebooted. I set the MTU of the underlying layer 2 VLAN to 1500, but the SVI stayed at 1504.

In the end, I set ip ospf mtu-ignore on the interfaces in R1 and R7, and that worked. But I have two questions:

1. What do I have to do to change the MTU on the 3550 SVI? The answer key from my training provider shows the MTU as 1500, apparently by default. I must be doing something different.

2. If I solve this problem with ip ospf mtu-ignore, is there not a danger that the exchange of databases will still not work because CAT1 will generate LSA packets that are too large for R1 and R7?

Kevin Dorrell


Correct Answer by Danilo Dy about 9 years 4 months ago


Surprisingly, this seems to happen in 3550 only (not sure if anyone experience this in other model). At first I thought it's a bug, but here's some light to it http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.1_13_ea1/configuration/guide/swtunnel.html#wp1010370



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Danilo Dy Tue, 10/09/2007 - 23:31


I encountered this before, can't find the solution. However, 802.1Q in my WS-3550-24 increase the MTU to 1504 (this does not happen in my other switches). Maybe use ISL?



Kevin Dorrell Tue, 10/09/2007 - 23:46

Hi Dandy,

That is a useful thing to know. Does that mean that if any of the trunks carrying the VLAN are dot1q then the MTU on the VLAN interface will be 1504? That is, to make the MTU 1500, I have to make them all ISL.

Certainly in my case I am constrained to use dot1q because my other switch is a 2950 (with a router on a stick behind it to make it layer-3). However in the answer key, their 3550 was running dot1q as well.

If the extra 4 bytes are only for the dot1q header, then the MTU should not cause any problem to the OSPF. But is it correct to include the dot1q header in the MTU? I think not.

I had a thought that maybe this extra 4 octets is something to do with support for private VLANs or maybe Q-in-Q. Anyone care to comment?

Kevin Dorrell


Kevin Dorrell Wed, 10/10/2007 - 05:25

Thanks. So it does have something to do with [Q-in-Q] tunnelling. I'll have a look when I get home to see if there is a system mtu set on my 3550. I cannot remember which version I have, but the document I read said the default was 1500. It also said explicitly that you cannot change the MTU on a per-interface basis, which agress with what I observed.

I'll let you know what I find.

Kevin Dorrell


Kevin Dorrell Wed, 10/10/2007 - 12:09

Well, thank you. Problem solved. show system mtu showed it had been set to 1504. Strangely, this parameter does not show up in the config, and you have to reload to get it to take effect. Even stranger that it is global, and not per interface.

Setting it to 1500 and reloading, CAT1 can now form adjacencies OK with R1 and R7 even without ip ospf mtu-ignore

Thanks again.

Kevin Dorrell



This Discussion