tcpdump mailing list archives
Re: Loosing half the conversion when any BFP is
From: Guy Harris <guy () alum mit edu>
Date: Thu, 20 Dec 2007 11:02:03 -0800
Bill Richardson wrote:
From BigIPtcpdump -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.
Current thread:
- Loosing half the conversion when any BFP is used Bill Richardson (Dec 19)
- Re: Loosing half the conversion when any BFP is used Bill Richardson (Dec 19)
- Re: Loosing half the conversion when any BFP is used Guy Harris (Dec 19)
- Re: Loosing half the conversion when any BFP is used Bill Richardson (Dec 20)
- Re: Loosing half the conversion when any BFP is Guy Harris (Dec 20)
- Re: Loosing half the conversion when any BFP is Bill Richardson (Dec 20)
- Re: Loosing half the conversion when any BFP is Guy Harris (Dec 20)
- Re: Loosing half the conversion when any BFP is Bill Richardson (Dec 21)
- Re: Loosing half the conversion when any BFP is used Guy Harris (Dec 19)
- Re: Loosing half the conversion when any BFP is used Bill Richardson (Dec 19)