Jumbo Frames - over cross-over cable, and over GigE switch


I was talking to someone yesterday about some testing that I've been doing with between a pair of computers with Intel GigE NICs. I've been doing some of my testing with a cross-over cable and some other testing going through a GigE switch.

Re. the cross-over cable connection, he said that the NICs may not be able to negotiate Jumbo Frames when they're connected with a cross-over cable, i.e., they needed to be talking to a GigE switch.

Is this true? I haven't heard this before.

Also, re. the GigE switch: In general, assuming that the GigE switch can support Jumbo Frames, do GigE switches need to be configured specifically to enable support for Jumbo Frames? Or, is this usually automatically detected/enabled by the switch(es)?

Thanks, Jim

Reply to
Loading thread data ...

It is complete news to me that the use of jumbo frames (or other frame size contraints) would be in any way negotiated between communicating Ethernet stations, with or without using a switch.


best regards Patrick

Reply to
Patrick Schaaf

I was kind of surprised to hear that myself :)...

Thanks. That might partially explain something that I'm puzzling over. I had set Jumbo Frames in the (Intel) NICs to 9014 bytes, and tried some "ping -f" tests, and am getting a "fragmented" message for anything with "-l" greater than 1472 bytes.

I've been searching through the documentation for the switch (a GigE switch that's been re-branded by IBM), but I can't find anywhere to enable/disable Jumbo Frames.

Assuming that there IS somewhere in the GigE switch configuration to enable/disable Jumbo Frames, would the Jumbo Frames being disabled in the switch cause the "ping -f" test to behave this way?


Reply to


You set the NIC to 9014, but what is the MTU that IP is using on the interface? Fragmentation is normally an IP function.

As far as I know, only a layer three switch would do IP fragmentation. Though there are stories about ethernet/FDDI bridging doing it, also. (FDDI allows frames larger than 1500, I believe somewhere around 4096.)

Where are the messages coming out?

-- glen

Reply to
glen herrmannsfeldt

On both machines:

ifconfig eth0 mtu 9014

No. Packets would appear to be sent from the local machine, but mysteriously disappear in the switch. Some counter you'll find in about five weeks while studying documentation, will have increased by one.

best regards Patrick

Reply to
Patrick Schaaf

glen and Patrick,

I'm going to respond to both of your posts in this one post. Hope that that's ok.

Sorry that I forgot to mention that both machines are running Windows


Patrick, your comment above about the packets appearing to mysteriously disappear might explain something else that I found when I did more testing yesterday.

When I did "ping -f" from machine 1 to machine 2, I got timeouts. When I did "ping -f" from machine 2 to machine 1, I got the fragmentation msg.

Now, with your post, I'm wondering if MTU is set larger than 1500 on one machine and not the other?

glen and Patrick, re. MTU, does that mean that I should have set the MTU? In my case, with Windows 2003, I think that there is an "MTU" item that I can set in the Registry, but in Windows, I think it's under the individual "Interfaces" or "Adapters".

I'll try that, but in any event, since I'm getting the timeouts when doing the "ping -f" from machine 2 to machine 1, does that seem to indicate that the GigE switch is NOT passing the Jumbo Frames?

Maybe I should go back and test with the cross-over cable again, but this time manually set the MTU? I had given up on that earlier because of the comment that I was told that the NICs might not negotiate the Jumbo Frames when going over a cross-over.


Reply to

In which case it should be called a router :)

More like nightmares - because the device wanted to be "just a little bit IP/pregnant" and didn't support all the things it must for an IP router. Should all be in the netnews archives from the mid '90's and earlier.

rick jones

Reply to
Rick Jones

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.