0

I have a functioning traffic classifier that uses raw packet offsets to match on the source and/or destination MAC addresses of the packet. The filter uses negative offsets as the default appears to be offset=0 is the beginning of the IP packet. The means the contents of the Ethernet header are just prior to that.

Example, for MAC 12:34:56:78:90:ab :

tc filter add dev <iface> protocol ip parent 1:0 prio 1 u32 \
    match u16 0x0800 0xffff at -2 \
    match u32 0x90ab 0xffff at -12 \
    match u16 0x12345678 0xffffffff at -14 \
    flowid 1:10

The network link is now going to be carrying 802.1Q VLAN traffic alongside the non-VLAN stuff. protocol ip prevents this traffic from matching. The question is, how do I construct a similar rule for VLAN traffic? I am trying to do a negative offset again to search for the "Ethertype" value of 0x8100 for DotQ traffic, just to confirm that my assumptions about offset, but can't seem to find it or at least can't seem to match on it. The example below does not successfully match DotQ traffic:

tc filter add dev <iface> parent 1:0 prio 1 u32 \
    match u16 0x8100 0xffff at -6 flowid 1:10

I have been unable to find any documentation on the tc system that specifies what offset=0 represents. Is it unconditionally the IP header start, or does protocol ip affect this?

Improve this question

1 Answer 1

Reset to default
0

My guess is that protocol IP uses EtherType field to determine what is the Layer 3 protocol. Since VLAN tag is inserted before EtherType field as indicated in https://en.wikipedia.org/wiki/IEEE_802.1Q, it doesn't match as an IP packet.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .