cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

39230
Views
13
Helpful
26
Replies
Hall of Fame Cisco Employee

Re: Can anybody finaly explain "system mtu routing" for c3560?

Konstantin,

If you are certain that the OSPF packets will never exceed the size of the smallest MTU configured on a segment, you may want to configure your OSPF to ignore the MTU size indicated by its OSPF neighbor using the interface-level command ip ospf mtu-ignore on the interface where you are suspecting MTU mismatches (the command shall be placed at least on the interface with the lower MTU but ideally on all interfaces on a common segment where you have a mismatched MTU). This will allow the routers to establish a full adjacency despite the MTU mismatch. However, this will not make the OSPF to fragment the packets - fragmenting the packets is fully in the competence of the IP protocol (as opposed to the IS-IS that handles the fragmentation itself) and is controlled by the router's own MTU.

Best regards,

Peter

Enthusiast

Re: Can anybody finaly explain "system mtu routing" for c3560?

Hi Peter,

thank you for the answer.

I've tried the command "ip ospf mtu-ignore " on both devices, but it didn't relly help.It seems that OSPF adjancy correctly ignores different MTU, but the the pckets with lager MTU were simply dropped by the c2600, which desn't support lager MTU.

Enthusiast

Re: Can anybody finaly explain "system mtu routing" for c3560?

ok, then if I can't configure MTU for SVI, how can I establish the OSPF  between devices with different MTU size?

The link between c3560 and c7200 should support MTU bigger as 1500 because of QinQ and MPLS,

the link between c3560 and c2600  supports only MTU 1500, as c2600 can't configure lager value. It means that c3560 should use different MTU on those two interfaces. on c3550 I could simply sys "ip mtu 1500" on the VLAN interfcae to c2600 and that all.

Enthusiast

Re: Can anybody finaly explain "system mtu routing" for c3560?

I'm a little bit lost, I think we all speak about different think.

first of all my cisco 3560 are  WS-C3560G-24TS, it means all ports are Gigabit and according documentation

Gigabit Ethernet ports operating at 1000 Mbps are not affected by the system mtu command, and 10/100-Mbps ports are not affected by the system mtu jumbo command.

doesn't affected by "system mtu" command, the MTU size for Gigabit ports can be cahnged  only by "system mtu jumbo" command.

BUT! the "system mtu" defines which MTU value will be used by SVI !

second, there is command "system mtu routing" which seems to be applyed only on L3 phisycal ports (no switchport) and not on the SVI. (but I can't find any 100% clear statement about it),. in my Lab "no switchports" L3 ports has taken over the "system mtu jumbo" settings, in my case MTU 9000


My problem is, on my c3560G on one SVI I need a "normal2 MTU 1500 but on the other SVI I need lager MTU 9000 or 1546 (MTU 1546 is good to be comüatible with my c3550's )

Cisco Employee

Re: Can anybody finaly explain "system mtu routing" for c3560?

since you have gig ports on the switch you will not be able to apply the "system mtu" to change the MTU on the gig ports...

----- "My problem is, on my c3560G on one SVI I need a "normal2 MTU 1500 but on the other SVI I need lager MTU 9000 or 1546 (MTU 1546 is good to be comüatible with my c3550's )"

and for this unfortunatly i think we cannot configure MTUs per-interface basis according to he above document.. you would either have MTU of 1500 on both SVIs or 1546 or 9000

Cisco Employee

Re: Can anybody finaly explain "system mtu routing" for c3560?

Hi Konstantin,

My problem is, on my c3560G on one SVI I need a "normal2 MTU 1500 but on the other SVI I need lager MTU 9000 or 1546 (MTU 1546 is good to be comüatible with my c3550's )

Per interface MTU configuration is impossible on this platform. In other words, two SVIs cannot have different MTU values.

Regards,

Shashank

Enthusiast

Re: Can anybody finaly explain "system mtu routing" for c3560?

hmm, so far it's more clear, two people has confirmed that c3560G can use only a single MTU value for all SVI.

But it should be some way to get OSPF working for my case, I can't believe that Cisco will fail on such quite usuall scenario!

Of course I can use static routing, but I wanted to avoid it as much as possible!

Beginner

Re: Can anybody finaly explain "system mtu routing" for c3560?

Hi,

maybe I'm a bit late to the party, but when searching  the interwebs for "system mtu routing" this thread is what pops up, so I  wanted to add a little more information:

Konstantin Dunaev wrote:

second, there is command "system mtu routing" which seems to be applyed  only

on L3 phisycal ports (no switchport) and not on the SVI. (but I  can't find any 100% clear

statement about it),. in my Lab "no  switchports" L3 ports has taken over the

"system mtu jumbo" settings, in  my case MTU 9000

The limitations of the platform in question would make no sense if system mtu routing would apply to routed ports, but at the same time would not apply to SVIs. The point here seems to be that the model line cannot fragment in hardware.  So to avoid that, it just makes sure every L3 interface (routed port  and SVI alike) has the same IP MTU, so there is never any need to  fragment a packet.

I've tested this in the lab using two 3560E chassis, trivially set up with the default VLAN, connected through Gigabit (so system mtu jumbo will apply) and then pinging each other's SVIs. Now let's configure the  following (using the maximum frame size the platform supports, there's  not much sense in limiting it here):

system mtu jumbo 9198

After rebooting, all physical ports running 1000Base or better will allow payloads of up to 9198 bytes to be encapsulated. The routing mtu will still be 1500 at this point. Try to ping one switch from the other like

ping 10.1.1.2 size 1500 df-bit

and it will succeed, but increasing size to 1501 will fail.

Now let's add:

system mtu routing 9000

to both switches and try again (no reboots needed). You will see that

ping 10.1.1.2 size 6000 df-bit

will suddenly work now, and the interface counters  will make clear that no fragmentation happens - it's really a single  6000 byte IP packet bouncing forth and back between the switches. That  works up to 9000, and starts failing at 9001, exactly as you would  expect.

Why is there a rumour that system mtu routing doesn't apply to SVIs? Probably because show interface of an SVI will show you an MTU of 1500 (or whatever your system mtu is), while the same command applied to a routed port will show 9000.  This seems to be a glitch, as so often with interface MTU in show  commands. More specifically, the show interface MTU is  supposed to be the potential payload MTU of the underlying physical  interface of that routed interface, and there are other cases where it  displays rubbish. One should always compare to the IP MTU as given by show ip interface. Et voila: The IP MTU of our SVI (as given through show ip int vl1) displays as 9000. So the succeeding ping is not a mystery and system mtu routing does exactly what it intuitively states: Change the IP MTU of every L3 interface of the platform.

I know this won't help in cases like the one discussed  here, where supposedly two L3 interfaces running at different MTUs are  needed. In such cases, one should first reassure that what's needed is  really that and there's no way to redesign the setup to avoid that (by  placing L3 and L2 boundaries appropriately). If there is no way around  that, the 3560 will likely have to go for something that has  per-interface IP MTU, like the 49xx or 4500X platforms.

Discussions about MTU often mix up different problems  and lead to chaos. IMO this is because two things are often not regarded  to the necessary extent by the participants:

  1. There is not one MTU. When talking about MTU, always define  the layer you consider. That's often hard because you actually have to  think about a layer boundary, so two layers are involved. The mythical  1500 for instance is the L3 MTU on top of a classic L2 of the Ethernet  family. Things fundamentally change when you discuss L2 MTUs with regard  to some underlying L1 (but things are easier here, as L1+L2 are often  developed together as one technology, while the boundary between  technology layers and the network layer has more degees of freedom).
  2. MTU  doesn't exist as such, but is an emerging concept. In other words, MTU  is what everybody in a system of communicating nodes (typically a  broadcast domain) thinks it is, with the emphasis on everybody.  In that sense it's like the IP network that lives on top of a broadcast  domain - it doesn't exist per se, but by convention of everybody using  that broadcast domain as a bearer for IP packets sourced from  non-colliding adresses from the same visibility range (aka prefix, aka  network and netmask, in ancient times aka subnet/subnetmask). MTU is a  convention as well, a single node just changing its MTU (up or down from  the convention, that is, what everybody else uses) is a recipe for  disaster. That's why you don't do it except you know exactly what you  are doing, and have the might to change it everywhere in a broadcast  domain (every involved intermediate network device and every end node).  It's viral. Luckily it's not as widespread as the viral issue of people  configuring ports full duplex because that's what they always did,  introducing duplex mismatches up and down and then telling you that as  obviously auto negotiation doesn't work, they will continue this  practice. You see the common scheme: Breaking a convention is a bad  idea, unless you are the sole dictator.

HTH,

Andre.

Message was edited by: Me Tried to remove the worst formatting issues introduced by this forum software. Can't fix the random position my answer was inserted into, instead of under the posting I replied to. Why everybody is trying to replace Usenet with something that isn't half as decent is beyond me (ranting mostly because I was logged out in the middle of writing that post and almost lost it).

Highlighted
Enthusiast

Re: Can anybody finaly explain "system mtu routing" for c3560?

Hi Andre,

thanks for the feedback!

I'm not 100% sure right now why in my case Layer3 ports (no switch) and SVI had different MTUs (or probably it seemed to be different), I couldn't explain it also, but it seems I didn't thoroughly tested it. Anyway thanks for the testing it.

So, I'm agree with your first statement about MTU layers, but the second statement doesn't seem to be fully correct to me.

The MTU is not only the "convention, in most cases, especially back to the "good old days", it's a physical attribute of a network segment. Which means you can use only the MTU which your hardware is supported, e.g. if you're connected to a device which supports 9000 and your device supports only 1508, this is not a "convention violation" anymore, this will result in more or less technical incompability.

P.S. lost of the mesage, because you was not "really logged in" is the most annoying "feature" of this particular forum SW, I agree This is why I got a habbit the use "Ctrl-A, Ctrl-C" before posting.

Beginner

Re: Can anybody finaly explain "system mtu routing" for c3560?

Hi Konstantin,

Konstantin Dunaev wrote:

So, I'm agree with your first statement about MTU layers, but the second statement doesn't seem to be fully correct to me.

The MTU is not only the "convention, in most cases, especially back to the "good old days", it's a physical attribute of a network segment. Which means you can use only the MTU which your hardware is supported, e.g. if you're connected to a device which supports 9000 and your device supports only 1508, this is not a "convention violation" anymore, this will result in more or less technical incompability.

Yep, but from another point of view, those technical limitations are the reason for conventions being there in the first place. In other words, they are voters in finding the convention that works for everyone, and they have a very strong vote. If you now raise the physical limit somewhere (by replacing a switch, or a NIC in some host), that doesn't mean the system which has raised the limit can suddenly make use of the raised limit. For that to be allowable, every other system has to be compatible with raising the limit, which may be impossible if it is still limited physically, or close to impossible for a lot of other reasons (bitrot of the ancient software, adverse configuration settings mandated by insane policies in place etc). Maybe convention is the wrong word because it has the undertone of something that is not a hard boundary and easy to change if only some participants push it enough (like a number of social conventions). The stuff we are talking about here is different, it is typically extremely entrenched and fortified and withstands change thoroughly for a long time. The 1500 IP MTU is one such thing, and it's only partly an issue of physical limits.

I just wanted to voice the thought that this is often overlooked when people play around with MTU values (both smaller and larger than 1500). There should be awareness that it's a Pandora's box you're about to open, because of the involved micromanagement of every participating system. It requires a systemic view. For instance, I found that this discussion focused too much on working around OSPF hitting an MTU mismatch, but nobody warned you that getting OSPF to underfly it will not help your actual payload traffic hitting that same MTU mismatch from potentially getting dropped (depends on whether sufficiently large packets can enter the routing instance on the larger sized end, but even if not now, that may change later when nobody remembers the other hack).

HTH & Thanks,

Andre.

PS: I had copied the message away, knowing other web fora with similar issues. It just broke some of the formatting, so it wasn't a simple paste again. But I realize I should not spin this further, my logout timer is ticking...

Hall of Fame Guru

Can anybody finaly explain "system mtu routing" for c3560?

Andre

Really good answer, leant a lot.

Hopefully you will be sticking aroud in these forums

Jon

Enthusiast

Re: Can anybody finaly explain "system mtu routing" for c3560?

Hi,

regarding OSPF between C3560 and c2600 I think I found a solution, see:

https://supportforums.cisco.com/message/3398176#3398176

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards