cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
948
Views
0
Helpful
2
Replies

Ethernet MTU, IP MTU and fragmentation.

Don Maker
Level 1
Level 1

Hey all, have a couple of design questions. I have one group on campus asking for "jumbo frame support" for their servers. In our campus network, each building has a router and multiple switches. That building router uplinks to distribution. 

 

I asked the group to clarify if they want server to server same vlan jumbo, or servers in different vlans (on the same building router) to exchange jumbo packets. I don't have that answer yet, but I would like to clarify my limited understanding of mtu. 

 

In this case we are talking about a Cisco 3850 L2 stack that connects to a Cisco 3850 L3 for building routing. If the design goal is layer 2 same vlan only jumbo, then I would go to each interface and issue an MTU XXX command, yes? But the only command I can find on the 3850 is system mtu xxxx. This changes all L2 and L3 mtu. Does this include the ip mtu? Could this not break OSPF, etc if done on a router? 

 

The 3850 L2 stack is pre-production, so I applied the system mtu 9000 command to see what would happen. Right after I did a sh ip int | i MTU and a sh int | i MTU and in both cases the MTU had changed to 9000. I notice there is an ip mtu xxxx command under the SVI, but hasnt that already been changed with the system mtu command? 

 

This should help illustrate:

 

slc-sw-1111-b(config)#system mtu 9000
Global Ethernet MTU is set to 9000 bytes.
Note: this is the Ethernet payload size, not the total
Ethernet frame size, which includes the Ethernet
header/trailer and possibly other tags, such as ISL or
802.1q tags.
slc-sw-1111-b(config)#do sh ip int | i MTU
MTU is 9000 bytes
slc-sw-1111-b(config)#do sh ip int brief | e unass
Interface IP-Address OK? Method Status Protocol
Vlan480 172.16.9.6 YES NVRAM up up

 

 

slc-sw-1111-b(config)#int vlan480
slc-sw-1111-b(config-if)#ip mtu ?
<832-9000> MTU (bytes)

slc-sw-1111-b(config-if)#

 

As you can see there is only one ip interface on this L2 switch. If I look at the ip mtu command under that interface after the change, it says I can go up to 9000. OK, that makes sense, but it seems that the ip mtu was already changed with the system mtu command. Would this not break any OSPF on the spot? If I have to change all my ip mtu to 9000 just so that I can then selectively have some running at 9000, isn't that problematic? Maybe I am missing something. 

 

 

Also, on a related side note:

 

I am wondering if the following situation would create ip framgentation. It was suggested in a meeting recently that we should enable jumbo frames on our building to distribution uplinks, but not on building vlans unless specifically requested.  Would this not cause fragmentation? We would have a point to point with 9000 mtu on each side, but then when traffic reaches a router (L3 3850) bound for say a host in vlan 420 in that building, would the 3850 not have to then fragment since the destination vlan is not configured for the larger ip mtu?

 

 

Sorry for such a long post. I appreciate your taking the time to think about this and provide any responses.

2 Replies 2

Don Maker
Level 1
Level 1

I think I answered the second part of my question just thinking about it. Source and destination hosts will be 1500, so the routers will not increase the size for no reason, so not a fragmentation issue. I guess the point is to sort of future proof our point to points. 

 

For the first part, we have a 3850 L3 in our lab that I am going to play around with and see if I "hard code" ip mtu 1500 on point to point links, and then do the global system mtu command, and then see if the point to points stay at 1500.

 

 

Did some testing with a dev 3850 L3 connected to our distribution. I tried setting the ip mtu on the point to point vlans to 1500, saved config, then did a system mtu 9198 command. The mtu for the point to points is overwritten at this point and ospf breaks. I can still access the device remotely if I target the building side of the point to point using ipv4 address and a local user (RADIUS broken at this point as well). This then brings ospf back up on the distribution router and all is well again. 

 

It's annoying that you have to break your ospf adj just to change the ip mtu on some local vlans. 

Review Cisco Networking products for a $25 gift card