Regarding the problem with shaping vlan-tagged traffic on linux bridge — it was my fault :-)
I asked community@lists.altlinux.org, 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).
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?
Yes! It works.
Now my shaper has a lot of lines like this:
It shapes tagged traffic on “untagged” (physical) interfaces (“clients0” is a renamed physical ethX — can’t remember which one).