In a previous thread I was asking about network monitoring tools and got
several recommendations. I have tested a few of them and found that they
cannot handle 802.1Q VLAN tagged ethernet frames and are therefore
unusable for my current project without changes. A way around this has
been implemented. See below.
For those unfamiliar with 802.1Q VLAN (Virtual Local Area Network), it
is a means of "tagging" ethernet frames so that they can be logically
grouped together as if they are all in the same LAN. The tagging works
by injecting 4 bytes into a regular ethernet frame to provide the
additional data. A basic explanation is here
<http://www.javvin.com/protocolVLAN.html> Most applications will never
see these types of packets because they are mostly exchanged between
switches.
In my application I was having a switch forward all of its traffic from
a certain port to a monitoring port. These switches are fairly
sophisticated and run everything in a VLAN. All ports by default are on
VLAN 1. It turns out that the switch sends the monitoring port the
actual internal ethernet frame INCLUDING the VLAN bytes. Normal switch
ports don't include them because the switch hides the VLAN info from the
end device. Unfortunately, there is no way to reprogram the switch to
deliver stripped frames.
It turns out that the tools I tested, bandwidthd and iptraf, both fail
to recognize the fact that the ethernet frames are "tagged" and either
think they are malformed or oversize and drop them. Looking at the
source of bandwidthd shows that it is hard-coded to assume that IP data
starts at 14 bytes offset (destination address: 6 source address: 6
type/length: 2 ). However, the VLAN tags inject an extra four bytes into
the frame just after the source address, causing an off-by-four error.
My temporary fix is to not use the monitoring port but instead put a
100mps hub (NOT switch) in between the devices I want to monitor. I'll
then plug my monitoring station into the hub and sniff the packets from
there. I'm not worried about a possible loss of bandwidth because one of
the end points is limited to 6Mbps max. This may become my permanent fix.
The complete fix would be to make these applications 802.1Q aware.
This was driving me insane because it worked fine in my home setup but
not at the customer site. It wasn't until later after I had a few beers
and then looked at the Wireshark packet capture that the 802.1Q stuff
jumped out out me.
Gus
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
