Is there a command to test whether jumbo frames are actually working? i.e. some sort of "ping" that reports whether or not the packet was broken up along the way.
I've an ESXi host with an Ubuntu VM which mounts a Dell MD3000i via iSCSI. I suspect jumbo frames are not enabled on the switch, and can't easily get admin access to it. I have the option to connect the disk array directly to the ESXi host, but would like some way of confirming that jumbo frames are a problem first.
I've got an application that would benefit from larger Ethernet frames. (In theory, we could reduce the number of outbound packets by > 50%, maybe even 66%.)
I'm also in the process of specifying networking requirements with candidate hosting companies for a new installation of my application servers. It would be nice to, at a minimum, not restrict client connections from benefiting from Jumbo Frames.
But how realistic is this? Some general questions, assuming the segment of the network we can control is Jumbo Frame-friendly (switches are large MTUs capable, ICMP MTU path discovery allowed, etc.):
I am often told by Sales Engineers and Product managers that a Layer 2 Ethernet service is not fit for purpose if the maximum supported frame size is in the 1518-1522 range (enough to support standard Ethernet frames or VLAN tagged frames).
Or in other words: an MTU of 1500 is not enough (see this blog post for my definition of MTU and a short rant on how the term is often misused)
I am never able to get any details from them on:
a) What proportion of customers (Enterprise / SMB) require Jumbo frames
b) What are typical expectations on frame size for Jumbos on WAN links? 1600, 2000, 9k, etc...
I know that in Telco and Data Centre environments Jumbos are pretty common, but I am after some insight as to how common this is within Enterprise and SMB networks.
We have a dataload job that moves a relatively large amount of data across the network between two sql servers. the servers are on the same subnet and there is only a switch between them. the data consists of several large varchar fields plus an xml field.
In order to increase throughput. I have tried changing the network packet size from the default 4096 to 32627 on the connection string; However it doesn't seem to be helping performance. I suspect the issue is that although we a running gig ethernet, "jumbo frames" are not enabled.
To confirm this, I tried two ping tests:
ping -l 1400 -f pdbsql01dul
Works
ping -l 4096 -f pdbsql01dul
Packet needs to be fragmented but DF set.
as you can see the largest packet size appears to be around 1400
My question is, if Jumbo frames are ~8096, is there any benefit of setting the network packet size larger than that?
Does this change if the connection is local to the server in question?
I would like to begin to upgrade my SOHO network to gigabit (from 10/100) and have heard a bit on Jumbo Frames.
What would be the best way to implement Jumbo Frames on a network? From what I can tell in order for it to work properly all network gear on the network must support Jumbo Frames. Is this true?
If I have specific gear (e.g. network printer) that cannot be updated to GB ethernet will this prevent me from enabling Jumbo Frames?
What are some of the gotcha's of enabling Jumbo Frames?