03-06-2013 06:23:17 PM
My office macs and NAS can all use gigabit ethernet on the LAN, so I've got 'em connected up with gigabit switches and using Jumbo frames (MTU=9000) to allow them to talk to each other at max speed. But the 2-wire Gateway (36000HGV) is hard-strapped at fast ethernet and Standard frames (MTU=1500) (or so say other people in various ATT forums I've looked at). I wonder if this configuration leads to non-optimal internet throughput rates.
Here's my office topology:
machine group > gigaswitch > long cable ....> gigaswitch > 2-wire gateway >VDSL
⇑
machine group(NAS is in this group) -----+
The througput among machines is quite satisfactory ... especially when doing full machine backups to the NAS.
I know the switch feeding the gateway can tone down it's bit rate to talk to the gateway ... but I was wondering if the machines .... all set to send Jumbo frames .... could be choking the gateway when the machines use it for internet traffic.
My network savvy is limited, so I don't know if the gateway is capable of moderating LAN traffic with the machines so that the LAN doesn't suffer thrashing that would result in lower internet throughput than a similar setup where all the machines use a standard frame size.
03-06-2013 08:13:10 PM - edited 03-06-2013 08:17:29 PM
The rule is that for Jumbo Frames to work properly, all components in the path (NIC, switch, router, transport, etc.) must all support Jumbo Frames. The U-Verse RG and the rest of the Internet do not, so you shouldn't have Jumbo Frames enabled on your network at all if it's connected to the RG.
The only reason it happens to work is that your OS uses path MTU discovery (PMTUD) to determine the largest IP packet that can be transmitted without fragmentation. This happens to be 1476 bytes (1476 of payload, 24 of IP header, total 1500), which enables your machines to talk to the RG and the Internet despite the fact that they want to use 9000 byte frames on the Ethernet.
The proper and RFC-conforming thing for you to do is to either turn off Jumbo Frames on all of your equipment, or place a router that does have Jumbo Frame capability between your network and the RG. This router would then fragment the IP traffic itself, or PMTUD on the workstations would reduce the frame size to 1500 anyway.
By the way, as the level of sophistication in network cards has increased, many network cards now support Large Send Offload and Large Receive Offload (LSO/LRO), which bring the CPU load to a constant value that is not dependent on the frame size. This eliminates the per-packet overhead that Jumbo Frames was designed to reduce. Thus, the effectiveness and usefulness of Jumbo Frames is mostly obviated by modern network equipment. Furthermore, there is a greater possibility of an undetected frame error with Jumbo Frames, requiring a more complex CRC algorithm to detect those errors. The increased CPU load from the CRC algorithm offsets the CPU load saved by the lower frame count.
In short, while Jumbo Frames was a good idea when Gigabit Ethernet was first released, the problem it was designed to solve largely doesn't exist anymore. Plus, given that no RFC or IEEE standard was ever completed for Jumbo Frames, manufacturer interoperability is limited. The bottom line is that Jumbo Frames should probably be retired to a footnote, similar to Token Ring. Modern computers have outgrown the need for it.
Here is an informative article that discusses this in more detail:
Also see the Wikipedia entry on Jumbo Frames:
https://en.wikipedia.org/wiki/Jumbo_frames
