tc u32 --- как соответствовать протоколам L2 в последних ядрах?

У меня есть хороший формирователь с хэшированной фильтрацией, построенный на Linux-мосте. Короче, br0 подключает external а также internal физические интерфейсы, пакеты с тегами VLAN соединяются "прозрачно" (я имею в виду, интерфейсы VLAN отсутствуют).

Теперь разные ядра делают это по-разному. Я могу ошибаться с точными диапазонами версий ядра, пожалуйста, прости меня. Благодарю.

2.6.26

Итак, в Debian, 2.6.26 и выше (я думаю, до 2.6.32) --- это работает:

tc filter add dev internal protocol 802.1q parent 1:0 prio 100 \
    u32 ht 1:64 match ip dst 192.168.1.100 flowid 1:200

Здесь "kernel" сопоставляет два байта в поле "protocol" с 0x8100, но считает начало пакета ip "нулевой позицией" (извините за мой английский, если я немного неясен).

2.6.32

Опять же, в Debian (я не собирал ванильное ядро), 2.6.32-5 --- это работает:

tc filter add dev internal protocol 802.1q parent 1:0 prio 100 \
    u32 ht 1:64 match ip dst 192.168.1.100 at 20 flowid 1:200

Здесь "ядро" совпадает с протоколом, но считает смещение от начала заголовка этого протокола - мне нужно добавить 4 байта к смещению (20, а не 16 для адреса dst). Это нормально, кажется более логичным, как для меня.

3.2.11, последняя стабильная версия

Это работает --- как если бы вообще не было тега 802.1q:

tc filter add dev internal protocol ip parent 1:0 prio 100 \
    u32 ht 1:64 match ip dst 192.168.1.100 flowid 1:200

Проблема в том, что я пока не смог найти способ сопоставить тег 802.1q.

Соответствующий тег 802.1q в прошлом

Я мог бы сделать это раньше следующим образом:

tc filter add dev internal protocol 802.1q parent 1:0 prio 100 \
    u32 match u16 0x0ed8 0x0fff at -4 flowid 1:300

Теперь я не могу сопоставить тег 802.1q с at 0, at -2, at -4, at -6 или как то Основная проблема в том, что у меня ноль отсчетов - этот фильтр вообще не проверяется, "неправильный протокол", другими словами.

Пожалуйста, кто-нибудь, помогите мне:-)

Спасибо!

Источник

5 ответов

Тег VLAN убран из skb в последних ядрах. Попробуйте что-то вроде этого, чтобы выполнить мета-соответствие в skb:

tc filter add dev internal protocol all parent 1:0 prio 100 basic match 'meta(vlan mask 0xfff eq 0x0ed8)' flowid 1:300
Источник

Я должен был сделать именно это. Я обнаружил, что ответ, предложенный @Thusitha, был правильным способом сделать это для новых ядер.

Протестировано с ядром Debian wheezy 3.2.0-4 и iproute (откуда берется команда tc) версии 20120521-3+b3

Вот полный сценарий, tc filter линии почти точно такие, как указано @Thusitha

function qos() {
    if="$1"
    vlan1="$2"
    vlan2="$3"

    # delete previous
    tc qdisc del dev $if root >/dev/null 2>&1
    tc qdisc del dev $if ingress >/dev/null 2>&1

    # Root HTB for $if
    tc qdisc add dev $if root handle 1: htb r2q 1 default 1

    # Root class to borrow from
    tc class add dev $if parent 1: classid 1:1 htb quantum 1000000 rate 500mbit ceil 500mbit burst 64k prio 2
    tc qdisc add dev $if parent 1:1 handle 101 sfq perturb 10

    # class for vlan1
    tc class add dev $if parent 1:1 classid 1:106 htb quantum 1000000 rate 1.00mbit ceil 1.00mbit burst 6k
    tc qdisc add dev $if parent 1:106 handle 107 sfq perturb 10
    tc filter add dev $if protocol all parent 1: prio 100 basic match "meta(vlan mask 0xfff eq ${vlan1})" flowid 1:106

    # class for vlan2
    tc class add dev $if parent 1:1 classid 1:108 htb quantum 1000000 rate 1.00mbit ceil 10.00mbit burst 6k
    tc qdisc add dev $if parent 1:108 handle 108 sfq perturb 10
    tc filter add dev $if protocol all parent 1: prio 100 basic match "meta(vlan mask 0xfff eq ${vlan2})" flowid 1:108

}

qos eth1 1234 1235
qos eth2 2345 2346
Источник

Вы можете пометить пакеты vlan ebtables.

# mark packets according to the vlan id
ebtables -i br0 -A PREROUTING -p 802_1Q --vlan-id 1 -j mark --mark-set 1
ebtables -i br0 -A PREROUTING -p 802_1Q --vlan-id 5 -j mark --mark-set 2

Тогда примените формирование, основанное на маркировке. ebtables и iptables имеют одинаковую маркировку.

Сам еще не сделал этого. Так что это скорее догадка.

Источник

Я бы порекомендовал использовать wireshark для захвата того, что происходит через интерфейс, как видимое в пользовательском пространстве, и использовать его для написания фильтра. Мне интересно, может быть, интерфейс по какой-то причине удаляет теги VLAN (несмотря на то, что он настроен для прозрачного моста). Возможно, это добавление дополнительных тегов или что-то?

Источник

Попробуй выключить reorder_hdr опция на интерфейсе vlan. Если опция переупорядочивания заголовка включена, то теги из фреймов удаляются. Проверьте это командой ip -d link list dev vlan_iface,

Источник
Другие вопросы по тегам