05-10-2024 07:21 AM
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!
Solved! Go to Solution.
05-11-2024 02:05 PM
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:
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).
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.
05-10-2024 07:24 AM
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
05-10-2024 08:34 AM
Which RFC, sorry?
05-10-2024 11:03 AM
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
05-10-2024 12:26 PM
@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.
05-10-2024 10:54 AM - edited 05-10-2024 06:37 PM
05-10-2024 11:54 AM
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.
05-10-2024 06:33 PM
@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.
I would "guess" it has something to do with SD-WAN tunneling, which perhaps doesn't understand .1Q tagging.
05-10-2024 06:40 PM
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
05-11-2024 04:40 AM
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
05-11-2024 02:05 PM
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:
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).
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.
05-12-2024 03:41 AM
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.
05-12-2024 04:04 AM
So in End there is mtu 1518
Goodluck to all
MHM
05-12-2024 04:29 AM
"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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide