cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
398
Views
1
Helpful
13
Replies

MTU on subinterfaces

ChrisNewnham_
Level 1
Level 1

So normally a standard interface has an MTU of 1500.

When creating a sub-interface on a router (or using an SVI on switch), should the MTU be manually lowered to 1496 to account for the extra 4 bytes?

Everything just seems to work without this, so I am wondering how that is the case.

Thanks!

1 Accepted Solution

Accepted Solutions

Joseph W. Doherty
Hall of Fame
Hall of Fame

In your OP, you didn't mention SD-WAN.  As noted in my original reply, normally you don't need to make any adjustments to MTU when using VLAN tagging.  I revised my original reply to provide a Wiki reference, but since then I found an older Cisco Technote (since we're discussing Cisco equipment) that might be helpful as it explicitly has:

Routed L3 Sub-Interfaces

These characteristics apply to routed L3 sub-interfaces.

A routed sub-interface MTU inherits the MTU of its parent main interface; add 4 bytes for each VLAN tag configured on the sub-interface. Thus, there are 4 bytes for a dot1q sub-interface and 8 bytes for a IEEE 802.1Q tunneling (QinQ) sub-interface.

As a result, L3 packets of the same size can be forwarded both on the main interface and the sub-interface.

The mtu command can be configured under the sub-interface, but it is applied only if it is lower or equal to the MTU that is inherited from the main interface.

From: MTU Behavior on Cisco IOS XR and Cisco IOS Routers

Noted in the above, adjusting MTU is optional on the subinterfaces, but by default, the L2 MTU is increased (L3 MTU remains constant - which would not be the case if you decrease the L2 MTU).

BTW, MTU is often not clearly specified as to which OSI level it refers.  For example, a standard (L2) Ethernet frame MTU of 1518 supports a (L3) IPv4 MTU of 1500 which (by default) supports a (L4) TCP MTU of 1460 (unless fragmentation is being used).

Wiki article on MTU.

So, again, to your OP, the generally answer is no, you shouldn't need to be making MTU adjustments to support VLAN tagging on Ethernet, assuming such equipment is using 802.3ac standard (which Cisco does, as far as I know).

In one of your follow up replies, you reference Cisco documentation that does reduce MTU for operation with SD-WAN.

As I earlier replied, likely that's has something to do with SD-WAN, and its tunneling.

I dug into that a bit deeper, and that does seem to be a SD-WAN cEdge requirement, although unclear it's still necessary, as Cisco working on "improving" SD-WAN.

Although a cEdge device is, as you note, an IOS-XE (hardware) device, to me it seems quite a bit has been "added" to IOS-XE to support SD-WAN.  Basically, it appears, the cEdge is a vEdge like software running on/under IOS-XE.  When using SD-WAN, I suspect you cannot go to far assuming its behaviors would be like IOS.

In other words, again, this MTU reduction is likely something, for whatever reason, SD-WAN "needs".

However, if you've noticed SD-WAN appears to work fine without it, possibly that might be software version dependent, as I've read some other strict configuration requirements have been eliminated in later software releases.

If "why" the MTU subinterface reduction is necessary or if you wonder is it still necessary, those questions are probably better posted in the dedicated Software-Defined Access (SD-Access) forum rather than this generic Routing forum.

View solution in original post

13 Replies 13

If you check you will see the rfc using 1518 not 1500 so there is 18 bytes or less than a little is keep not count and it sure cover extra 4 bytes of vlan ID 

MHM

ChrisNewnham_
Level 1
Level 1

Which RFC, sorry?  

https://www.google.com/amp/s/www.networkworld.com/article/745164/mtu-size-issues.html/amp/

No need to decrease mtu to 1496 to cover 4 bytes there are already 14-18 bytes can use for l2 header and vlan -id 

MHM

@MHM Cisco World skimmed your reference.  Way back, we had a discussion where I mentioned using jumbo Ethernet to avoid fragmentation of 1500 byte packet that were going to be tunnelled.  Recall you didn't understand the advantage.  Interestingly, this is mentioned in your reference.

Second, article states MSS must fit within packet.  Believe that's incorrect, although commonly done to avoid splitting TCP segment across multiple packets.

Joseph W. Doherty
Hall of Fame
Hall of Fame

ChrisNewnham_
Level 1
Level 1

I am wondering why in this document Cisco reduces the MTU by 4 for the sub-interfaces of the cEdges, even though it works just fine if you don't do it. They are just IOS-XE devices ultimately.

https://www.cisco.com/c/en/us/support/docs/routers/xe-sd-wan-routers/218137-configure-basic-parameters-to-form-contr.html


@ChrisNewnham_ wrote:

I am wondering why in this document Cisco reduces the MTU by 4 for the sub-interfaces of the cEdges, even though it works just fine if you don't do it. They are just IOS-XE devices ultimately.

https://www.cisco.com/c/en/us/support/docs/routers/xe-sd-wan-routers/218137-configure-basic-parameters-to-form-contr.html


I would "guess" it has something to do with SD-WAN tunneling, which perhaps doesn't understand .1Q tagging.

end

 

Note: To accommodate the 32-bit field added to packets by the 802.1Q protocol, the MTU for subinterfaces must be at least 4 bytes smaller than the MTU of the physical interface. This is configured with the mtu<value> command. The default MTU on a physical interface is 1500 bytes, hence the MTU of the subinterface must not be larger than 1496 bytes. Also, if the subinterface requires an MTU of 1500 bytes, the physical interface MTU can be adjusted to 1504 bytes.

1504

As I mentioned the Ethernet II (see link I share) is cover up to 1518.

MHM

Hello
please be aware when changing the interface mtu on a routed interface(s) make sure the value you set is consistent through your routed network as you could incur unexpected fragmentation and issues arising from these changes especially on igp adjacency’s (ospf) as mtu is a factor in establishing those peerings and changing them will drop such adjacency’s if they are inconsistent 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Joseph W. Doherty
Hall of Fame
Hall of Fame

In your OP, you didn't mention SD-WAN.  As noted in my original reply, normally you don't need to make any adjustments to MTU when using VLAN tagging.  I revised my original reply to provide a Wiki reference, but since then I found an older Cisco Technote (since we're discussing Cisco equipment) that might be helpful as it explicitly has:

Routed L3 Sub-Interfaces

These characteristics apply to routed L3 sub-interfaces.

A routed sub-interface MTU inherits the MTU of its parent main interface; add 4 bytes for each VLAN tag configured on the sub-interface. Thus, there are 4 bytes for a dot1q sub-interface and 8 bytes for a IEEE 802.1Q tunneling (QinQ) sub-interface.

As a result, L3 packets of the same size can be forwarded both on the main interface and the sub-interface.

The mtu command can be configured under the sub-interface, but it is applied only if it is lower or equal to the MTU that is inherited from the main interface.

From: MTU Behavior on Cisco IOS XR and Cisco IOS Routers

Noted in the above, adjusting MTU is optional on the subinterfaces, but by default, the L2 MTU is increased (L3 MTU remains constant - which would not be the case if you decrease the L2 MTU).

BTW, MTU is often not clearly specified as to which OSI level it refers.  For example, a standard (L2) Ethernet frame MTU of 1518 supports a (L3) IPv4 MTU of 1500 which (by default) supports a (L4) TCP MTU of 1460 (unless fragmentation is being used).

Wiki article on MTU.

So, again, to your OP, the generally answer is no, you shouldn't need to be making MTU adjustments to support VLAN tagging on Ethernet, assuming such equipment is using 802.3ac standard (which Cisco does, as far as I know).

In one of your follow up replies, you reference Cisco documentation that does reduce MTU for operation with SD-WAN.

As I earlier replied, likely that's has something to do with SD-WAN, and its tunneling.

I dug into that a bit deeper, and that does seem to be a SD-WAN cEdge requirement, although unclear it's still necessary, as Cisco working on "improving" SD-WAN.

Although a cEdge device is, as you note, an IOS-XE (hardware) device, to me it seems quite a bit has been "added" to IOS-XE to support SD-WAN.  Basically, it appears, the cEdge is a vEdge like software running on/under IOS-XE.  When using SD-WAN, I suspect you cannot go to far assuming its behaviors would be like IOS.

In other words, again, this MTU reduction is likely something, for whatever reason, SD-WAN "needs".

However, if you've noticed SD-WAN appears to work fine without it, possibly that might be software version dependent, as I've read some other strict configuration requirements have been eliminated in later software releases.

If "why" the MTU subinterface reduction is necessary or if you wonder is it still necessary, those questions are probably better posted in the dedicated Software-Defined Access (SD-Access) forum rather than this generic Routing forum.

Thanks Joseph, that's helpful. Yes I didn't mention SD-WAN originally as I wanted to be sure I understood how it worked on a "conventional" device.

So in End there is mtu 1518

Goodluck to all

MHM

"So in End there is mtu 1518"

That depends whether you've reduced MTU, and by how much.  Normally a standard maximum Ethernet VLAN tagged frame would be 1522.

BTW in my research, I came across mention of reducing MTU to support MPLS labels, which also normally extends frame's size.

Basically, Ethernet interfaces designed to support VLAN tags, MPLS labels and/or jumbo Ethernet can send/receive the larger frames those features need.

Conversely though, protocols like PPPoE, GRE and/or IPSec do not extend the frame for their overhead.  Believe this because these protocols are not limited to just Ethernet.

Review Cisco Networking for a $25 gift card