IPv4 Backbone Baby Jumbo MTU size - any adverse effect?

[Won Lee]

Hello.

Is there any complication or adverse effect, setting IPv4/MPLS backbone GE link MTU size bigger than the Ethernet De facto of 1500, in the ASR9000 IOX-XR 4.3.x? What would be practical size? 4470, 8192? We have customers request to set 1800 but too odd value. What is the value the ASR9K (Trident LC with RSP, not 440) and LCs supports?

Much appreciate for your support.

Thanks,

Intopian.

[xthuijs]

Hi Won,

fragmentation in general should be avoided at all cost.

XR and in particular asr9k supports ethernet frame sizes of 9200 (max ether MTU).

It is no problem setting the config to this value.

If you want to be more minimalistic, you need to set the MTU to accomodate AT MINIMUM an ether payload of 1500

plus all the tags that can be applied to the packet, this includes (several) MPLS labels, dot1q-tags etc.

I agree that a value of 1800 seems a bit arbitrary chosen, and when using either ISIS or OSPF as IGP, I would recommend the MTU to be rolled out consistently throughout the whole domain.

I think it makes sense to evaluate the option of choosing an MtU of 9000 (saving 200 for several headers as necesasry)

xander

Xander Thuijs CCIE #6775
Principal Engineer 
ASR9000, CRS, NCS6000 & IOS-XR

[Won Lee]

Hello Xander,

Thanks for reply.

Through some research, there are several advantage of bumping up the MTU size, beside than the preventing fragment, less packet to handle, less lookup table quary, less headers, ect...

But, as the 1500 was de facto for so long, with bigger size of MTU, How does the routing protocols will deal with? any known issue with specific applications? any effect on the TCP session? more delay on VoIP packet?

Any formal Cisco stance guideline link or doc available?

Thanks again!

Won

[xthuijs · Accepted solution]

That is correct Won, there are other advantages also as you noted.

For routing protocols:

OSPF uses it to fill its DBD's do both sides need to ahve the same MTU size,

same applies to ISIS.

RIP doesnt really care, although it can pack more updates in a single packet

BGP, using TCP, will use the MTU to adjust its MSS value so BGP benefits from this also big time.

As for delay on voip, yes theoretically, if the link speed is low enough, serialization delay of a large mtu packet may induce jitter on the high priority voip packet. But with 1500 bytes, the "fragment" size should be adjusted at 750k (so half T1 speed) only. With the majority circuits operating now at 1G, 10G etc, this fragment size requirement is almost no longer there as the serialization delay is so low at these speeds.

Other then very low end CPE's or very old devices that dont like larger MTU's (eg very old PA's in the 7200) there is really no worry anymore increasing the MTU size.

I dont think there is a formal doc on this, but I am sure if google it, you can find recommendations from other folks

on what they have done/seen etc.

regards

xander

Xander Thuijs CCIE #6775
Principal Engineer 
ASR9000, CRS, NCS6000 & IOS-XR