Problem with shaping vlan-tagged traffic on linux bridge

Posted on
Update: there are no any problem with vlans in classifiers, that was my fault.

Have been playing with shapers and run into such a problem: u32 classifier does not work (?) for tagged traffic on «non-tagged» linux bridge.

In more details:

Test bed:

Let’s take three linux boxes. One will be two-ports switch (SW), on two another (BoxA and BoxB) we will configure IP addresses and, for example.

So.. For the beginning BoxA should ping BoxB on crossover cable.

Building bridge:

brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ip link set up dev br0

Now BoxA should successfully ping BoxB through this switch.

Configuring shaper:

# QDisc:
tc qdisc add dev $DEV root handle 1: htb default 200
# root class:
tc class add dev $DEV classid 1:10 parent 1:0 htb rate 100Mbit
# default class:
tc class add dev $DEV classid 1:200 parent 1:10 htb rate 1Mbit
# клас для тестового трафіка:
tc class add dev $DEV classid 1:100 parent 1:10 htb rate 10Mbit
# фільтр для тестового трафіка:
tc filter add dev $DEV protocol ip parent 1:0 prio 100 u32 match ip dst flowid 1:100

Check — BoxA should ping BoxB, and this traffic should be in class 1:100, this can be verified by tc -s class show dev $DEV.

Configuring vlan subinterfaces:

Now on boxes A and B we remove addresses from interfaces and put them on sub-interfaces:

ip addr del brd dev eth0
vconfig add eth0.100
ip link set up dev eth.100
# на іншому "боксі" буде .11/24, відповідно:
ip addr add brd dev eth0.100

Switch’s configuration remains unchanged.

Now BoxA still can ping BoxB, but this traffic is in the default class, 1:10, instead of 1:100.

The value of REORDER_HDR does not matter.

This is the problem.

What is wrong?

Some considerations:

  1. u32 classifier takes «offset» counting from the beginning of IP packet.
  2. vlan tag should not mess IP related code…

Is any of these wrong?

I’ve mentioned, i’m not a programmer :-)

4 Replies to “Problem with shaping vlan-tagged traffic on linux bridge”

  1. Not sure, I’ve just recently been researching tc/bridges/VLANs, but maybe on your bridge, eth0 is for untagged packets, yet the traffic you’re sending is now tagged. So it doesn’t match your tc rules.

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.