Jumbo Frames

[lcaruso]

Hi,

I'm working at a client site that serves video in unicast sessions across the internet. They have a lot of internal traffic on their Cisco switch that remains internal to in order serve up archived video to the streaming media servers before it goes out.

I'd like to recommend they turn on jumbo frames but have some concerns about user sessions across the internet. Some issues with jumbo frames across the internet include

For a large frame to be transmitted intact from end to end, every component on the path must support that frame size.

Switches that don't support jumbo frames will drop jumbo frames.

For a jumbo packet to pass through a router, both the ingress and egress interfaces must support the larger packet size. Otherwise, the packets will be dropped or fragmented.

I know path mtu discovery should take care of advertised MSS from the client connection requests, so if a device inbetween client and server cannot handle jumbo frames, the negoitated size will work fine. In other words, routers won't be required to fragment jumbo frames because the MSS size will be negotiated down to whatever the intermediate devices can handle. Is that a correct statement?

If anyone could lend their perspective/experience on this, I would really appreciate hearing from you. Thanks.

[Eugene Lau · Accepted solution]

G'day,

The thing to remember is that

a. Jumbo MTU -> is an interface level MTU to allow larger frames at the ethernet layer. Configuring Jumbo MTU's normally doesn't change IP MTU

b. Path MTU Discovery, MSS etc are related to IP MTU - At the IP LAYER

c. The typical Path MTU Discovery implementation requires an ICMP Type 3 message to be seen by the sending host when a device in the path is unable to forward the larger MTU packet. For an ICMP "fragment needed" to be generated, it has to be a Layer3 interface

To confirm your understanding (I'm not going to reword it just to avoid confusion)

1. For a large frame to be transmitted intact from end to end, every component on the path must support that frame size

CORRECT -> try to think about it at L2 and L3

2. Switches that don't support jumbo frames will drop jumbo frames.

CORRECT -> if this interface that drops the frame is Layer2 (eg. trunk link) -> NO ICMP type 3 is generated.

3. For a jumbo packet to pass through a router, both the ingress and egress interfaces must support the larger packet size. Otherwise, the packets will be dropped or fragmented.

CORRECT -> Architecturally, products can differ in behaviour eg. Switches can check on ingress but not on egress. It's better to think the whole path should be able to accept the required MTU size.

HTH

Eugene

[lcaruso]

Thanks Eugene. In this discussion, I had missed the distinction between layer 2 and layer 3 somehow, so that really was a great answer and help to me.

[lcaruso]

I think this Cisco discussion says what I was trying to say

Cisco Recommendations

If properly implemented, jumbo frames can provide a potential six-fold improvement in the TCP throughput of an Ethernet connection, with reduced fragmentation overhead (plus lower CPU overhead on end devices).

You must make sure that there is no device in between that is unable to handle the specified MTU size. If this device fragments and forwards the packets, it nullifies the entire process. This can result in added overhead on this device for fragmentation and reassembling of packets.

In such cases, the IP path MTU discovery helps senders to find the minimum common packet length that is suitable to transmit traffic along each path. Alternatively, you can configure jumbo frame-aware host devices with an MTU size that is the minimum of all the ones that are supported in the network.

http://www.cisco.com/en/US/customer/products/hw/switches/ps700/products_white_paper09186a00801b49a4.shtml#cg8