Re: Loosing half the conversion when any BFP is

[Guy Harris <guy () alum mit edu>]

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.