ospf on SVI

Hit a problem today connecting a 2600 to a 3550.
The adj wouldn't form due to a mismatch of the mtu.
The SVI has an mtu 1546 which cannot be modified, the 2620 has a fastethernet int with mtu 1500 which cant be modified.So what can i do? i modified under the interface "ip ospf mtu-ignore" on both sides, hey presto my database synchronised.2 minutes later the adj bums out and i get loads of lsa errors being received on the switch, obviously the pkts is getting segmented or something.So now stuck again.
Decided to load a 2620xm 12.4 image now everything works dandy without any ignore mtu.
So i wonder whats happened regarding the mtu on the new code,maybe its not being check anymore. I really don't want to waste time checking so i thought i'd post and see if someone knows anything about this.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

APA

what's the mtu on the interface connecting to the 2600??

I know it's an logical vPtP via SVI but there still must be a physical interface....

I had this issue the other day when hooking up a 7201 to a 3550 as the 3550 has a default mtu of 1550 on all of it's switchports.... The adjacency would not form due to MTU mismatch

What I did was change the physical interface of the 7201 via 'mtu 1550' not 'ip mtu' as 'ip mtu' only allows up to 1500. This has everything working fine... I don't like using ip ospf mtu-ignore.

That's interesting that you have the adjacency up with mismatching mtu's on 12.4 -matching mtu is a standard for OSPF adjacency so I doubt cisco would have disabled it........ I'll have to lab this up....

Can you post your show interfaces???? FastEthernet[2600], SVI and Physical uplink to 2600[3550]

EdTheLad

The 3550 doesn't care about the mtu size, i noticed the 2600 still had the ignore mtu, once i removed from the 2600 the adj dropped.I've just seen alot of strange behavior regarding the mtu on the 3550 and i was wondering what gives.I found the command "system mtu" which allows me to set everything at 1500 so its all good, solves all my issues.

kryolla

Usually MTU comes into play when doing QinQ tunneling with system mtu command you have to increase due to another dot1q header. I Just turned up an SVI and looked at the MTU and it is 1500 bytes and system mtu is also 1500. As far as the new code fixing your problem I dont know about that.

APA

EdTheLad wrote: »

The 3550 doesn't care about the mtu size, i noticed the 2600 still had the ignore mtu, once i removed from the 2600 the adj dropped.I've just seen alot of strange behavior regarding the mtu on the 3550 and i was wondering what gives.I found the command "system mtu" which allows me to set everything at 1500 so its all good, solves all my issues.

I put it down to the 3550 having a standard mtu of 1550 for all it's switchports hence the strange behaviour....

I'm still at a loss as to why they did it.......but as you say system mtu is an easy enough fix....

APA

kryolla wrote: »

Usually MTU comes into play when doing QinQ tunneling with system mtu command you have to increase due to another dot1q header. I Just turned up an SVI and looked at the MTU and it is 1500 bytes and system mtu is also 1500. As far as the new code fixing your problem I dont know about that.

was this on a 3550 or other switch series??? I've only noticed the MTU difference with the 3550 range of switches... I've got two in my lab and used plenty at work for lab purposes as well...

MTU comes in to play with MPLS,QinQ etc....many reasons....

kryolla

A.P.A wrote: »

was this on a 3550 or other switch series??? I've only noticed the MTU difference with the 3550 range of switches... I've got two in my lab and used plenty at work for lab purposes as well...

MTU comes in to play with MPLS,QinQ etc....many reasons....

yes this is a 3550 I have here at work.