cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1112
Views
0
Helpful
5
Replies

OSPF, mismatched MTU, 3550 vs. 2500

Kevin Dorrell
Level 10
Level 10

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

Luxembourg

1 Accepted Solution

Accepted Solutions

Hi,

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

Regards,

Dandy

View solution in original post

5 Replies 5

Danilo Dy
VIP Alumni
VIP Alumni

Hi,

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?

Regards,

Dandy

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

Luxembourg

Hi,

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

Regards,

Dandy

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

Luxembourg

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

Luxembourg

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:

Review Cisco Networking products for a $25 gift card