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 172.17.2.10/24 and 172.17.2.11/24, 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:
DEV=eth0 # # 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 172.17.2.10 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 172.17.2.10/24 brd 172.17.2.255 dev eth0 # vconfig add eth0.100 ip link set up dev eth.100 # # на іншому "боксі" буде .11/24, відповідно: ip addr add 172.17.2.10/24 brd 172.17.2.255 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:
- u32 classifier takes «offset» counting from the beginning of IP packet.
- vlan tag should not mess IP related code…
Is any of these wrong?
I’ve mentioned, i’m not a programmer :-)
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.
Thank you, Garry, for your feedback.
Yes, i should use “tc filter add … protocol 802.1q”, i’ve stated this here: http://brownian.org.ua/?p=208
That was my fault, definitely.
Good article – plenty of food for thought.