HTB/8021q: That was my fault

Posted on

Regarding the problem with shaping vlan-tagged traffic on linux bridge — it was my fault :-)

I asked, and Sergey Vlasov answered me with some info and hint — thanks a lot!-)

As Sergey told, «a packet is being passed to bridge module before 8021q can process it». That’s why the classifier decides that a packet does not match a filter rule — because filter contains «protocol ip» condition, however a packet contains «protocol 802.1q» actually. It look like it’s enough to use «protocol 802.1q» in filter condition — after that ip addresses (offsets from IP packet’s start) will be counted correctly.

This offers a possibility to build «aggregating shapers» on linux bridges, which will be able to shaper clients” traffic regardless of «traffic direction» (regardless of a particular vlan membership). And it will be very easy to migrate from an «usual» shaper on linux bridge — we will have to replace «protocol ip» with «protocol 802.1q» in a filter template (or we can add one more filter — if it is really necessary).

2 Replies to “HTB/8021q: That was my fault”

  1. So, is this working or not? I personally failed to “capture” 802.1q tagged traffic using this type of filter. After googling around I started to come to realization that it might work but not for everyone (I don’t know the reasons).

    Could you please elaborate on the idea described in this post?

    1. Yes! It works.

      Now my shaper has a lot of lines like this:

      /sbin/tc filter add dev clients0 protocol 802.1q parent 1:0 prio 100 u32 ht 133:54 match ip dst XX.YY.133.84 flowid 1:2e2

      It shapes tagged traffic on “untagged” (physical) interfaces (“clients0” is a renamed physical ethX — can’t remember which one).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.