Re: Loosing half the conversion when any BFP is

["Bill Richardson" <wrichardson () llbean com>]

 This traffic was gathered using a port mirror on a Nortel 5510 switch.
The port that I'm mirroring is where the 172.21.89.70 address is. You
would think that the Nortel switch would present the traffic as untagged
but this may be a bug in the way Nortel does port mirroring.

Thanks

-----Original Message-----
From: tcpdump-workers-owner () lists tcpdump org
[mailto:tcpdump-workers-owner () lists tcpdump org] On Behalf Of Guy Harris
Sent: Thursday, December 20, 2007 2:02 PM
To: tcpdump-workers () lists tcpdump org
Subject: Re: [tcpdump-workers] Loosing half the conversion when any BFP
is

Bill Richardson wrote:
> From BigIP
>   
> tcpdump -r test.pcap -nn host 172.21.89.75 -d

        ...

As I suspected, they appear to interpret "host XXX" as "host XXX or
(vlan and host XXX)".

That has the advantage that it works with both untagged and VLAN-tagged
packets.

It has the disadvantage that the filtering code is more complicated than
it needs to be on networks that don't have any VLANs, so there's a bit
more filtering overhead.  It may be that most of their customers use
VLANs, so that's the appropriate choice for them; it might or might not
be appropriate for all applications using libpcap on all sites.

It also doesn't handle multiple levels of VLAN encapsulation.

Whether they *literally* interpret "host XXX" as "host XXX or (vlan and
host XXX)" is another matter.  As the tcpdump man page says:

       vlan [vlan_id]
              True if the packet is an IEEE  802.1Q  VLAN  packet.   If
              [vlan_id]  is  specified, only true if the packet has the
              specified vlan_id.  Note  that  the  first  vlan  keyword
              encountered  in  expression  changes the decoding offsets
              for the remainder of expression on  the  assumption  that
              the  packet is a VLAN packet.

so once you use "vlan", *everything* after it is interpreted as acting
on tagged packets.  Thus, for example, if they interpret each occurrence
of a filter expression XXX as "XXX or (vlan and XXX)", so that

        host XXX or host YYY

is interpreted as

        (host XXX or (vlan and host XXX)) or (host YYY or (vlan and host
YYY))

that wouldn't do what you'd expect, as the first "vlan" affects all the
stuff that checks YYY.  If, however, they interpret it as

        (host XXX or host YYY) or (vlan and (host XXX or host YYY))

that would work correctly.

It appears that only half of the packets in your capture are
VLAN-tagged.  The older tcpdump on the F5 BigIP prints, by default, an
indication of whether the packet is tagged:

> 08:05:28.729250 802.1Q vlan#88 P0 172.21.89.75.4000 > 
> 172.21.89.70.45647: . 1555:1569(14) ack 3496 win 202
> 08:05:28.729258 172.21.89.70.45647 > 172.21.89.75.4000: . ack 1569 win

> 5840 (DF)
> 08:05:28.739994 802.1Q vlan#88 P0 172.21.89.75.4000 > 
> 172.21.89.70.45647: . 1569:1583(14) ack 3496 win 202
> 08:05:28.740003 172.21.89.70.45647 > 172.21.89.75.4000: . ack 1583 win

> 5840 (DF)

i.e., the traffic from 172.21.89.75 port 4000 to 172.21.89.70 port 45647
is tagged, but the traffic in the other direction isn't.

Newer tcpdumps don't print that by default, but if you run them with the
"-e" flag, they will.

Thus, to filter that traffic, you'd need to check with an filter that
works on both untagged packets and tagged packets.  That's what you get
by default with the F5 BigIP's libpcap, but you have to do "XXX or (vlan
and XXX)" on standard libpcap.

Now, *why* the traffic is like that is another matter.  If 172.21.89.70
is the IP address of the machine on which you captured the traffic,
traffic from that address isn't captured from the wire, it's wrapped
around inside the networking stack to the PF_PACKET socket (or whatever
the capture mechanism uses - it's a Centos box, hence Linux, so it's a
PF_PACKET socket in that case), and that happens before any VLAN tagging
is done.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.