OSPF and different MTU

[Konstantin Dunaev]

Hello,

I will now try to ask here

I have some problems with stability of my OSPF session between 3 devices. the topology is simple:

cisco7200 --- catalyst3560 --- cisco2600

the cisco7200 and catalyst3560 are speaking MTU 1546 (because of QinQ and MPLS)

cisco2600 speaks only MTU 1500.

The OSPF between cisco7200 and catalyst3560 works perfect, but the OSPF betwenn catalyst3560 and cisco2600 is not stable and doesn't come correctly to Full adjacency. The reason is quite stupid - catalyst3560 doesn't support differet MTU on different Interfaceses and tries to send OSPF packets with MTU 1546 to cisco2600, which obviously drop them.

The comman "ip ospf mtu-ignore" IS CONFIGURED on the both sides  but doesn't help, and I know that MTU value should be the same alone the  whole path, but cisco2600 is just a "spoke" router and doesn't forward  any backbone traffic and cisco2600 doesn't support lager MTU anyway.

What would be the best soluition or work-around? static routing is not really an option.

[Kishore Chennupati]

Hello,

The command "ip ospf mtu-ignore" should work. havent seen this not work before. In your case, this should be enough on the 2600. No need for it to be on the 3560 as it can accomodate 1500bytes from the 2600.However no harm in having it on both

Maybe you can try using RIPv2 or BGP between the 3560 and 2600 and redis it into ospf..You have also mentioend that the 2600 is not part of your network. So maybe you can use filters etc what to accept and not etc

Regards,

[Konstantin Dunaev]

Kishore,

thanks for the suggestion.

kishore.chennupati wrote:
Hello,
The command "ip ospf mtu-ignore" should work. havent seen this not work before. In your case, this should be enough on the 2600. No need for it to be on the 3560 as it can accomodate 1500bytes from the 2600.However no harm in having it on both

I'd say the problem is not that "ip ospf mtu-ignore" doesn't work, I'd say it works exactly as it suppose to be, the problem is cisco2600 drops the  OSPF packets which are sent by catalyst3560 and which size are 1546 bytes (MTU is 1546 on catalyst3560)

Maybe you can try using RIPv2 or BGP between the 3560 and 2600 and redis it into ospf..You have also mentioend that the 2600 is not part of your network. So maybe you can use filters etc what to accept and not etc
Regards,

that's the option of cause, but I think all those routing protocols doesn't take into account the MTU size of the remote end and the will end up exactly as OSPF. One says that ISIS can work with different MTU's but I didn't try it yet.

[Sudeep Khuraijam]

OSPF ignore mtu  is specifically meant to bypass the mtu check and thus still establish neighbor relationship with a mismatched MTU. 

It is outragiously ridiculous to have to run BGP or any IGP just to achieve what you are doing.  Run debug OSPF at varying levels and open a TAC case.  If the command aint working it needs to be fixed.You might want to do a bug scrub and see if it is fixed at a certain patch level.

[Kishore Chennupati]

Hi Sudeep,

I agree with you that this should be looked into further. However, I guess we are trying to provide some workarounds here till Konstantin can log it with the TAC and investigate the root cause. If we keep going to the TAC for everything then I guess we dont need to have the forums here if you know what i mean..

Sometimes, things don't work the way you expect them to and hence all the suggestions/workarounds and it also helps you increase your knowledge as well. Even the TAC sometimes offer you workarounds till they find out the root cause...some of the engineers on this forum are equally knowledgable and experienced

HTH,

Regards,

[Konstantin Dunaev]

Hi Khuraijam,

as I said, it doesn't have  to do with "mtu-ignore" problem, my OSPF neighbours are not stuck in EXSTART/EXCHANGE  state, actually, catalyst3560 come succesfully to FULL state but cisco2600 stays in LOADING state.

Debug doesn't say anything about "MTU mistmatch", look here:

catalyst3560:

catalyst3560#sh ip os ne

cisco2600    1   FULL/DR         00:00:38    10.0.89.10      Vlan10

Feb 20 12:48:35.616: OSPF: Rcv LS REQ from cisco2600 on Vlan10 length 660 LSA count 53
Feb 20 12:48:35.616: OSPF: Send UPD to cisco2600 on Vlan10 length 1496 LSA count 53

cisco2600:

cisco2600#sh ip os ne

catalyst3560    1   LOADING/DROTHER 00:00:38    10.0.89.2       Ethernet0/0

Feb 20 12:48:30.614: OSPF: Retransmitting request to catalyst3560 on Ethernet0/0
Feb 20 12:48:30.614: OSPF: Send LS REQ to catalyst3560 length 636 LSA count 53

cisco2600#sh int e0/0 | i giants
Received 3054259 broadcasts, 0 runts, 380867 giants, 0 throttles

as you can see catalyst3560 is sending OSPF Update packet of 1496 bytes length, plus 20 byte OSPF header and 20 bytes IP header which in sum gets 1536 bytes for IP packet, plus Ethernet header and at the end we get the packet which become "giants" for cisco2600 and which is dropped. I can see that giants  counter is continuasly growing.

[hbruyere]

Hello,

You are in some kind of catch-22 situations here, since you can't increase the mtu on the 2600, and you can't decrease it on the 3560.

But if the 3560 is sending a big ospf packet to the 2600, it's because it contains a lot of summary and/or external routes, and if the 2600

is just a stub router, he does not really need to get all this, a default route would be enough.

So why not putting the 3560-2600 link in a totally stubby area? In that way the 3560 would only generate a default route towards the 2600.

It might well avoid the problem.

Hope it helps.

Herve

[Konstantin Dunaev]

Hi Herve,

thank you for the answer.

I was thinking about "totally stub" or "stub" area for cisco2600, and you're right - OSPF database is quite big, but not so extreme, may be 100-200 routes in there.

The problem is, catalyst3560 is sitting not in Area "0" and then I need on cisco2600 some kind of OSPF virtual-link, it's of course possible, but it'll inrease compexity, and secondly I'll need to do it on all other location in order to have simular topology and configuration (not all location have such a problem, only with catalyst3560, orther with catalyst3550 runs perfectly). But after all, it seems to be the best solution.

What I really want know what was the reason to disable a setting of MTU value on interfce level. Or it's just my cisco2600's too old for the modern network world ?

[hbruyere]

location have such a problem, only with catalyst3560, orther with catalyst3550 runs perfectly). But after all, it seems to be the best solution.
What I really want know what was the reason to disable a setting of MTU value on interfce level. Or it's just my cisco2600's too old for the modern network world  ?

Hi Konstantin,

Indeed the 2600 is a bit oldish. The ethernet interface controller is limited to 1500 bytes and we cannot change that.

The fact that the same works where you use cat3550 is a bit weird. I am not expert of these small switches, but the cat3550

has also a physical mtu only globally configurable. So if it works, that must be because you have been able to configure an 'ip mtu'

on the SVI's. But on these switches (3560/3550/3750) the 'ip mtu' command is not supported, and should be removed from most

of the more recent software releases.

Regards,

Herve

[Konstantin Dunaev]

Hi Herve,

thank you for the answer. Yu're right - on my c3550 I'm using "ip mtu" on the interface level and don't have any problems.

on the SVI's. But on these switches (3560/3550/3750) the 'ip mtu' command is not supported, and should be removed from most
of the more recent software releases.

you said "from most of the more recent software releases" could it be that in some old release "ip mtu" still avaiable?

[hbruyere]

on the SVI's. But on these switches (3560/3550/3750) the 'ip mtu' command is not supported, and should be removed from most
of the more recent software releases.
you said "from most of the more recent software releases" could it be that in some old release "ip mtu" still avaiable?

On the 3560 it seems the command was never allowed. I tried 122-35.SE, and 'ip mtu' does not exist. Then with 122-44.SE and newer releases it says:

c3560(config-if)#int vlan 1

c3560(config-if)#ip mtu 1500
% ip mtu is not supported on this interface

But anyway, even if the ip mtu command was allowed in some old 3560 release, downgrading to use an unsupported command would not be a great move.

Regards,

Herve

[Konstantin Dunaev]

Hello,

thank you all again for the good advices, unfortunatly this network topology works only with some kind of workaround - cisco2600 in separate "stub no-summary" area and virtual-links between catalyst3560 and cisco7200. cisco2600 gets then only a couple of prefixes and OSPF packet doesn't exceed the MTU value. It makes the topology more complex (unnecessary) of course, but at leaset I don't have any problem with OSPF adjacency anymore.

but it's a little bit confusing, of course one can always do such a changes in a network, but e.g. we're using a lot of cisco7200 with NPE400 which forwards backbone traffic (they are forwarding  traffic from Spokes sites into backbone ) and  NPE-400 doesn't support lager MTU on its FE's.  In this case it would be not possible just to place a NPE400 in a separate Area and advetise only default-routing information. I don't get the idea to take off the command "ip mtu" from the Layer3 interface, it was always possible to set IP MTU separatly on the links, it's just not fair .

[hbruyere]

I don't get the idea to take off the command "ip mtu" from the Layer3 interface, it was always possible to set IP MTU separatly on the links, it's just not fair .

I agree that this is an annoyance. The removal of 'ip mtu' from the CLI was justified by the fact that it is not supported in hardware on those small switches.

The command had no effect on packets hardware-forwaded accross the switch, but only on packets processed in software (so mainly the packets originated by the switch itself). This is not solving your problem, but at least you know the story behind

Regards,

Herve

[Konstantin Dunaev]

Hi Herve,

thank you a lot for the explanation!  I expected something like this and from one side it's may be not so bad idea to limit all non-hardware supported operations to a very minimum.

As you now said about it I can  imagine a very simple DoS attack on out catalyst3550 - just send big ping packets to the managemnet IP and catalyst3550 will die very fast as it should not only answer on those packets but to do the fragmentation as well. It makes sence.

[lephuc007]

Hi Gents,

Sorry for my ignorance as a late comer into this issue. Assuming the Catalyst is a layer 3 switch, then why can't it be turned into a routed interface, where the ip mtu command and other mtu associated commands should be supported, whereas the svi doesnot.

[Konstantin Dunaev]

Hi Le,

no probs.

there are 2 things which make your suggestion not really applicable:

1. It's not possible to change the mode of an interface to "routed" because this is a trunk.

2. routed ports don't have "ip mtu" command either, the command "system-mtu routed" manages the size of MTU on them, but this give  us again  the same  problem - one can't use different MTU's on different routed ports.