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.
