Увага: жодних проблем з vlan у класифікатора немає, то була моя помилка.
Експериментував і на трапив на таку проблему: не спрацьовує u32 classifier для «міченого» трафіка на лінукс-комутаторі.
Детальніше:
Полігон для тестування:
Маємо три лінукси. На одному з них (SW) робимо двопортовий комутатор, на інших (BoxA та BoxB) чіпляємо адреси 172.17.2.10/24 та 172.17.2.11/24, наприклад.
Спершу перевіряємо, що на кросовому шнурку BoxA може пінгати BoxB і навпаки.
Будуємо міст:
brctl addbr br0 brctl addif br0 eth0 brctl addif br0 eth1 ip link set up dev br0 |
Тепер перевіряємо, що BoxA може пінгати BoxB через цей комутатор.
Конфігуруємо шейпер:
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 |
Перевіряємо — пінгаємо щось крізь цей комутатор і дивимося tc -s class show dev $DEV
— все працює чудово. Тобто, BoxA може пінгати BoxB, і цей трафік потрапляє у клас 1:100.
Піднімаємо інтерфейси 802.1Q:
Тепер на BoxA та BoxB прибираємо IP адреси з інтерфейсів та чіпляємо їх на під-інтерфейси:
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 |
На комутаторі при цьому нічого не міняємо.
При цьому BoxA продовжує успішно пінгати BoxB, але цей трафік потрапляє не у клас 1:100, а у default class (1:10).
При цьому значення REORDER_HDR
ролі не грає.
Це і є проблема.
Що не так?
Деякі міркування:
- класифікатор u32 відлічує «offset» від початку пакету IP.
- мітки vlan не повинні впливати на код, що стосується IP…
Щось із цього неправильно?
Я ж казав, я не програміст :-)
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.