root@mpls2:~# tcpdump -i enp1s0 "mpls 17004 && mpls 17003" -env tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), capture size 262144 bytes 14:11:01.812328 52:54:00:d9:52:82 > 52:54:00:73:55:cd, ethertype MPLS unicast (0x8847), length 106: MPLS (label 17004, exp 0, ttl 64) (label 17003, exp 0, [S], ttl 64) (tos 0x0, ttl 64, id 38111, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > 192.168.0.3: ICMP echo request, id 16099, seq 865, length 64 14:11:02.836320 52:54:00:d9:52:82 > 52:54:00:73:55:cd, ethertype MPLS unicast (0x8847), length 106: MPLS (label 17004, exp 0, ttl 64) (label 17003, exp 0, [S], ttl 64) (tos 0x0, ttl 64, id 38308, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > 192.168.0.3: ICMP echo request, id 16099, seq 866, length 64 14:11:03.860330 52:54:00:d9:52:82 > 52:54:00:73:55:cd, ethertype MPLS unicast (0x8847), length 106: MPLS (label 17004, exp 0, ttl 64) (label 17003, exp 0, [S], ttl 64) (tos 0x0, ttl 64, id 38422, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > 192.168.0.3: ICMP echo request, id 16099, seq 867, length 64 14:11:04.884324 52:54:00:d9:52:82 > 52:54:00:73:55:cd, ethertype MPLS unicast (0x8847), length 106: MPLS (label 17004, exp 0, ttl 64) (label 17003, exp 0, [S], ttl 64) (tos 0x0, ttl 64, id 38556, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > 192.168.0.3: ICMP echo request, id 16099, seq 868, length 64 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel
To quote the pcap-filter man page: mpls [label_num] True if the packet is an MPLS packet. If [label_num] is speci- fied, only true is the packet has the specified label_num. Note that the first mpls keyword encountered in expression changes the decoding offsets for the remainder of expression on the assumption that the packet is a MPLS-encapsulated IP packet. The mpls [label_num] expression may be used more than once, to filter on MPLS hierarchies. Each use of that expression incre- ments the filter offsets by 4. For example: mpls 100000 && mpls 1024 filters packets with an outer label of 100000 and an inner label of 1024, and mpls && mpls 1024 && host 192.9.200.1 filters packets to or from 192.9.200.1 with an inner label of 1024 and any outer label. "Each use of that expression increments the filter offsets by 4." means "once you use it in a filter expression, all filters after it in the filter expression string will check MPLS labels past that label. This means that in (mpls && mpls && port 161) or (mpls && port 161) the first two mpls will cause all subsequent checks to look at the third level of label, so (mpls && port 161) will check for three levels of MPLS filter. The same applies to vlan. Arguably, vlan/mpls items should only affect stuff directly ANDed to them; that can probably be implemented, but isn't necessarily simple to implement - it might be easier if, for example, the parser were to build a parse tree and the code generator were to walk the parse tree. I don't know whether those changes would affect any filters that depend on the current behavior in a useful fashion; I suspect not, as I can't imagine why vlan and mpls should affect stuff ORed with them.