MTU multiples

_maurice

Is it recommended to have an MTU set as a multiple of 8? I can't find reasoning for this. If so, why?

Thanks

jamesp1983

i don't think I've ever heard of this. The only time I've ever changed MTU size is to accommodate the overhead that the different protocols add. The MTUs that I've set haven't always been exact multiples of 8. I've never heard of that being a best practice.

Panzer919

The only time we change MTU's is when we are doing Q in Q tunnels but its just to accommodate overhead, it's not set as a multiple of 8 though.

_maurice

Trying to make an MTU of 1454 on a SonicWALL produces the following error:

"Error: The MTU must be a value between 68-1500 in increments of 8 (e.g., 1492)."

Is this due to the fragmentation offset value in the frame header being multiplied by 8?

Cisco products let you change the MTU to ANYTHING, so this doesn't make sense to me.

billyr

_maurice wrote:

Trying to make an MTU of 1454 on a SonicWALL produces the following error:

"Error: The MTU must be a value between 68-1500 in increments of 8 (e.g., 1492)."

Is this due to the fragmentation offset value in the frame header being multiplied by 8?

Cisco products let you change the MTU to ANYTHING, so this doesn't make sense to me.

I think they mean going up by a value of 8 each time. i.e 1500 + 8.

_maurice

Thanks for the reply. No, the Maximum MTU value on SonicWALL devices is 1500. I work for SonicWALL, and can't get a straight answer from my peers.

The fragmentation offset in the frame header is multiplied by 8. I am going to run a packet capture in GNS when the MTU is like 1499 and then at 1500, and see what the difference is in the packet structure.

_maurice

I love it when I answer my own questions.

I setup a GNS lab with 2 routers. At first the two routers were connected via ethernet interfaces. Cisco barked at me that it will not change the 1500 MTU value on ethernet interfaces. So I connected them with serial interfaces. I ran an extended ping with 2000 bytes of data while listening with wireshark. With an MTU of 1500 bytes, the fragmentation offset was hex B9, which is 185 decimal. 185 * 8 is 1480. I lowered the MTU to 1499, ran the same extended ping, and opened wireshark again. The fragmentation offset was hex B8, which is 184 decimal. 184 * 8 is 1472.

The first ping with 2000 bytes of data was split up into 2 packets. The first was of size 1504 then 524. The second ping with size 2000 bytes was 1496 then 532

Lesson learned: Cisco uses the MTU specified if on a boundary of 8. If not on a boundary of 8, then it drops the MTU value lower to a boundary of 8. very cool.

redwarrior

Nicely done and interesting to know...so I guess if you're going to fat finger an MTU size, make sure it is +7 or less and Cisco will fix it for you.

_maurice

Yes, so the MTU will be on a boundary of 8, regardless of what the admin sets it to be because the fragmentation offset in the IP header is multiplied by 8, and this is the only way to reassemble the original segment.

_maurice

Can anybody comment on this/confirm my findings? The ISCW certification guide mentions an optimal PPPoE MTU of 1454. If my findings are correct, then an MTU of 1454 is not used. 1452 would actually be used.

kryolla

Did you mean optimal or what is in the book. What is in the book says 1492

_maurice

I'm referring to page 100, Chapter 4: Using DSL to Connect to a Central Site of the CCNP ISCW Official Certification Guide.

kryolla, true 1492 is the maximum MTU possible with PPPoE. But on page 100, the section titled "Optimizing PPPoE MTU" explains that bigger is not always better.

It suggests an MTU of 1454. While the cisco will accept this MTU setting, it will not actually be used, as the fragmentation offset value in the IP header needs to be a whole number that is then multiplied by 8.

For example: If the MTU is 1500, and the IP header is 20 bytes, 1480 bytes of data is sent (layer 4 and up). 1480 / 8 = 185. If the MTU is 1454, and the IP header is 20 bytes, 1434 bytes of data is sent, and this is not a whole number that can be divided by 8, so the fragmentation offset can not be placed in the IP header. The MTU must be dropped to 1452. Minus 20 bytes for the IP header, 1432 bytes of data is sent. 1432 / 8 = 179, and this CAN be used in the fragmentation offset.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

kryolla

okay but all the config in the book has 1492 from what I can remember I haven't opened the book since I past the exam. I just dont know if you are reading too much into this MTU thing

PPPOE, dot1q tunneling you have to account for the extra dot1q header and mpls vpn & traffic Engineering is all that I read where you have to take into account the MTU size and OSPF but you can just ignore the MTU size.