Bonjour mon amis.
This post is going to be about L2 MTU! Wait. What? Wondering how this can be a whole topic? Me too atm, so let’s dive in and see how warm the water is.
I have never really in all my time as a network engineer really ever needed to mess with the MTU on anything, other than an old broadband modem as suggested by an ISP engineer about a decade ago. There might be some people reading this that can’t believe that as they live and breathe the MTU life on a daily basis. If so, fair play. Maybe that makes me a massive noob, but hopefully I wont be by the end of this post. This is what its all about AMIRITE?! Knowledge gets you power. Power gets you women. Or was that money gets you power? I’m paraphrasing (Scarface gag, if you know, you know.)
So what is MTU? MTU stands for Maximum Transmission Unit and the name itself is actually quite explanatory. It’s the maximum size that a protocol data unit (PDU) can be sent in a single network ‘transaction’. SIMPLES. Hold on. Whats a protocol data unit? Yeah I don’t really know either. Let’s dive deeper. It’s also important to note here that the syllabus refers to L2 MTU specifically. So is that a different MTU as each layer of the OSI?
The answer to that is, sort of. The L2 MTU contains parts that aren’t required in the L3 MTU and so on. It’s important at this point to discuss the structure of a data packet and break it down into its super fun constituent parts. It’s also important to discuss the difference between the PDU and the MTU. Its going to take a while so strap yourself in…
The MTU is the PDU minus the header.
Oh. Thats it? Sorry I hadn’t even got my seatbelt into the clippy thing (what is that part of the seatbelt called? Question for another day. Maybe another post!? Nah probably not.) We should probably note at this point that the PDU is also called different things at different layers. So at L1 its the BIT, at L2 its the FRAME, at L3 its the PACKET (how many times have you said packet and not known that it actually refers to the L3 PDU?) and L4 its the SEGMENT for TCP or DATAGRAM for UDP. Lets drill down into that L2 ethernet frame:
So we see the MAC header split of 14 bytes split into 3 sections: a destination MAC address which is 6 bytes, a source MAC address with is 6 bytes (as we already learned in a previous post that MAC addresses are 6 bytes or 48 bits), and a type field, which is 2 bytes, adding up to the total 14 bytes. The following section represents what is known as the PAYLOAD and this is all the data to be transmitted. It’s also important to note that the payload will include any other headers required for higher layers eg: the IP headers for L3. This can (in ethernet) go up to a maximum of 1500 bytes per frame. The remaining 4 bytes at the end which is here described as the CRC checksum but may also be referred to as the frame check sequence, or L2 footer. So we’ve got a 14 byte header, a 1500 byte payload, and a 4 byte checksum. TOTAL of 1518 bytes per ethernet frame.
When we’re referring to the actual MTU of the L2 frame, really we’re just looking at the PAYLOAD (however I think Cisco may be being a tad blasé here and they’re referring to the whole frame as the MTU). Anyhow, there is one thing missing when looking at the L2 frame above that I bet you’re all ITCHING to find out. What if the packet being sent is part of a VLAN and needs a Dot1Q tag? Well spotted, Sherlock. I applaud your inquisitive-ness. Well the short answer is that in between the destination MAC address and type sections, A VLAN section is added as shown below:
There it is! 4 delicious bites of FLAN. I mean bytes of VLAN. This is even further broken up into sections, the TPID (tag protocol identifier, a value of 0x8100 indicates a dot1Q frame), the PRI (this called the PCP (priority code point) in Cisco literature and represents the priority, indicating a 802.1p class of service for QoS at L2), the CFI (canonical format indicator) although Cisco document this as the DEI (drop eligible indicator) used to determine whether it can be dropped if there is bandwidth contention) and the VID (VLAN identifier, which will be a value between 1-4094). So let’s add another 4 bytes to our existing 1518 byte frame, we’ve now got a frame size of 1522 bytes. Can’t be more surely? Well. Yes. But I’ll make it quick.
Any additional 4 byte section can be added before the VLAN tag section, which is there for any service provider VLAN tags (S tags) that are required for other services such as PPPoE, MPLS etc. It’s called the QinQ tag, or 802.1ad tag. Where as 802.1Q tagged frame is represented by the 0x8100 value in the TPID, the QinQ tag or service tag is represented by 0x88a8. So the additional 4 bytes takes us up to a grand total of 1526 bytes. That’ll do for that…
***At this point I just want to make sure that you’re aware of FRAGMENTATION. You might be thinking (but I hope you’re not) if there is only 1500 bytes in the payload of a packet, then how they hell do I send anything larger than 1.5Mb? Well, obviously the data is fragmented. It’s broken down into lots of small sections, then reorganised at the receiving end. Thats why, having a larger MTU means fewer fragments, fewer overheads, more efficiency. BACK OF THE NET.***
Ok, so we’ve identified what the L2 frame is made up of and how cool it is (what at first I thought to be quite a boring topic has actually peaked my interest now), let’s take a look at its relevance in real world scenarios and configuration examples. Maybe even a bit of wireshark?! Who knows? Let’s see where this goes, it could get crazy.
So firstly, if there is a maximum size why would you ever want to configure it below that? Well you wouldn’t really, unless you were sending traffic to a medium only capable of lower MTUs. For example, the maximum MTU size for a PPPoE frame is 1492. Anything with an MTU higher than that will be dropped. The higher the MTU, the more efficient the transaction as fewer frames need to be sent in total, along with fewer overheads (eg fewer headers and CRCs). How do we check the MTU of a switch port? (I’ll show you) Can it be configured on port by port basis? (No)
The MTU shown here only refers to the payload, it does not include the L2 headers. This MTU can be increased with system wide commands that will affect all ports of a certain speed. The command ‘system mtu’ can be used to increase the MTU size for all ports operating at 10-100Mb, and the command ‘system mtu jumbo’ for all ports operating at 1Gb-10Gb. These 2 commands will not interfere with one another (ie the system MTU command will not change the MTU on the gigabit interfaces). So just as a test, leaving the MTU default on a couple of routers, let’s see what happens when we craft a few packets using ping, set the DF (do not fragment bit) and set the value of the MTU higher than 1500 (by default anything higher than 1500 will be fragmented as discussed earlier and sent as multiple packets). So in the below, I have 2 routers connected to each other via the Fa0/0 ports, and have configured R1 as 192.168.0.1 and R2 as 192.168.0.2.
As we can see from the above clip, once the size of the IP packet goes above the MTU size (and we’ve told the router not to fragment the packets) the destination router drops the packets and we get no replies. CRAZY stuff. Well I definitely feel like I know a lot more about MTU now, I hope you do too!
(ok there was no wireshark, but who knows, if I’m in the mood for some MTU fun in the future, I may return)