Jumbo frame on Procurve 4108GL

[BERTON_1]

Hello,

I have configured 2 Proliants DL380 to use 4k Jumbo frame, it doesn't work. When the jumbo frame is active the communication stop between these 2 servers but continue to works between these servers and other servers without jumbo frame active.
Servers are connected on a procurve 4108gl, this switch is it compatible with jumbo frame?
Is it a setup problem, a firmware version problem?

Regards

Pascal

[Matt Hobbs]

It's a hardware limitation, the 4100 series does not support Jumbo frames.

For Jumbo frame support you'd need to look at the 3400/5400/3500 series.

[BERTON_1]

Ok
Tank-you for your help

Pascal

[BERTON_1]

Hello,

I have seen on the HP web site, I can replace the 4108GL by a 5406ZL.
But, do you know if a layer 3 switch is as fast as a layer 2 switch for backups ?
I don't know how work a layer 3 switch
if it wait to have all of the IP packet to send it, it create a important latency ...


regards

Pascal

[Matt Hobbs]

The 5400 is much faster than the 4100. The ProCurve Layer 3 devices are routing-switches. That is, they are switches underneath but have layer 3 functionality.

[rick jones]

And once you upgrade to a ProCurve with JumboFrame support, you should keep in mind that when enabling Jumbo Frames (IMO the one true definition of "JumboFrame" is an MTU of at least 9000 bytes - anything less is not IMO a Jumbo Frame) you really SHOULD (virtually MUST) set the MTU on ALL devices in the broadcast domain to the same value.

(Broadcast domain here is basically the set of systems on the same side of a router - ie systems which can reach each other without having to use a router, just switching)

While TCP will continue to "work" if you don't, it is only by luck and the MSS exchange at the beginning of the connection. Any UDP traffic from a JF-enabled host to a nonJF-enabled host will fail miserably. The IP in the JF-enabled host will fragment the IP datagram containing the UDP datagram based on the JF MTU which will be too large for the nonJF-enabled receiver to accept.

[BERTON_1]

hello,

In fact, during the backup, with a 1.5k frame, the integrated NIC of a proliant generate more than 15000 interrupts/s.

I have tried to test with big frames because I have read that it can reduce of 50% the cpu load and increase of 50% the throughput on gigabit link.

I have also read that when a computer with JF enabled communicate with another with JF disable they use std frames, maybe it's false.

if a computer with JF enabled can't communicate with another without JF support (on the same network), I can't use it (laptop and printers doesn't support it).

tank-you for your help

regards

Pascal

[rick jones]

Most Gigabit NICs should have interrupt coalescing parameters one can set if you are truely worried about interrupt rates. There is of course no free lunch:

ftp://ftp.cup.hp.com/dist/networking/briefs/nic_tput_vs_latency.txt

(might need to switch tput and latency)

The warning about JF on one, JF on all is meant as much to educate as anything else, so you will know what might be happening if you start to have connectivity problems. If all your communications are over TCP you will be OK (sometimes it is ok to be lucky rather than good :) but if some of them are not over TCP then you will start to have problems.

There may be a way to setup multiple, tagged, vlans and split-off a separate backup network for the JF-capable systems. How to do so will be specific to your switches and hosts networking stacks.

[BERTON_1]

Hello,

tank-you for your help
I read the document this afternoon

Pascal