NCL 2.0 beta and Xen

| 1 Comment
I found a good candidate for why the Novell Client for Linux 2.0-beta is so crappy in a Xen kernel. Take a look at this:

Frame 6 (4434 bytes on wire, 4434 bytes captured)

What the heck? What it should look like is this:

Frame 6 (1514 bytes on wire, 1514 bytes captured)

So I go to our network guys and ask, "Have we turned on jumbo frames anywhere?" No, we haven't. Anywhere. Which I pretty much knew, since we're not doing any iSCSI. So where the heck is that jumbo coming from? The only thing I can think of is that the sniffing layer I'm getting this at is above the layer that'd grab what actually hits the wire, and something between the sniffer and the wire is converting these jumbos to the normal 1514B ethernet MTU, and that's where my lag is coming from.

This is a case where I'd like to span a port and get a sniff of what actually hits the wire so I can compare.

1 Comment

Im no how about:1. the pktscan nlm running on a server to look at it from the recieving end, or2. plugging a HUB into your workstation port and plugging a laptop running wireshark on a nic in promiscuous mode to get all the traffic, or3. asking your nice data network folks to set up a monitor port on the switch your workstation connects to so you can attach a laptop running wireshark (etc).As a thought that sounds alot like the default frame size in the NCW (47xx) which is some sort of stupid nod to IBM's token-ring network. I usually set the value to 2048 in the Windows client, but I haven't even looked to see if this value is configurable in the Linux client...Cheers,Ron NeillyUBC Okanagan