3

Ok, this sound might stupid - but is there any negative on just enabling jumbo frames in practice?

From what I understand:

  • Any switch or ethernet adapter that sees a jumbo frame it can not handle will just drop it.
  • TCP is not a problem as max frame size is negotiated in the setinuo phase.
  • UCP is a theoretical problem as a server may just send a LARGE UDP packet that gets dropped on the way.

Practically though, as UDP is packet based, I do not really think any software WOULD send a UDP packet larger than 1500 bytes net without app level configuration changes - at least this is how I do my programming, as it is quite hard to get a decent MTU size for that without testing yourself, so you fall back in programming to max 1500 packets.

The network in question is a standard small business network - we upgraded now from a non managed 24 port switch to a 52 port switch with 4 10g ports (netgear - quite cheap) and will mov a file server to 10g for also ISCSI serving. All my equipment on the Ethernet level can handle minimum 9000 bytes and due to local firewalls I really want to get packets larger (less firewall processing), but the network is also NAT'ed to the internet. On top, different machines move around (download) large files (multi gigabyte area) quite often for processing.

The question is - can I expect problems when I just enable jumbo frames?

Again, this is not totally ignorance - I just don't see programs sending more than 1500 byte UDP packets (if that is a practical problem please tell me) and for TCP the MTU is negotiated anyway.

if there is a problem I can move to a dedicated VLAN, but this has it's own shares of problems as basically most workstations must then be on both VLAN's.

Improve this question

2 Answers 2

Reset to default
2

is there any negative on just enabling jumbo frames in practice?

No, so long as when switching JF's on you immediately confirm that the server can use the appropriate NIC/s then no, no real downside at all.

Improve this answer
2
  • You may run into some fun if the target and initiator are not running jumbo frames
    – SpacemanSpiff
    Oct 6, 2012 at 13:55
  • Well, I would set every nic to the smallest common jumbo frame. My main problem is really that I can not have all machines using jumbo frames - there are some "appliances" (printers) and there is the internet side of the router that just can not handle jumbo frames. ISCSI would even work fine in a mixed environment, or - Jumbo or not, is ISCSI not using TCP, which negotiates max segment size? (Assuming you mean this with initiator and target).
    – TomTom
    Oct 6, 2012 at 16:00
1

The one gotcha would be the extra 14 bytes added to a tagged frame. For some hardware that's enough to trigger the 'drop on the floor' action. I ran into that one myself, but it was fixed by setting the MTU on the switch in question to 9014, and everything else to 9000.

Improve this answer
1
  • Well, my limits on the swith start above 9200 and go to 65000 on the router, so I am safe here with limits. My main concern is systems going to the internet suddenly sending UDP packets tat are too large and get dropped in the router (as obviously the MTU on the outbound interface would still be 1500).
    – TomTom
    Oct 6, 2012 at 13:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .