[v7100]

Доброго всем времени суток!

 

Собираю схему с шейпящим бриджем - Linux, HTB, u32. Особенность такова - через него проходит тегированный трафик.

Соответственно фильтр выглядит так:

для даунстрима tc filter add dev $DEV protocol 802.1q parent 1:0 prio 1 u32 match ip dst 10.44.0.4/32 flowid 1:10

для апстрима tc filter add dev $VED protocol 802.1q parent 1:0 prio 1 u32 match ip src 10.44.0.4/32 flowid 1:10

 

bridge:~# tc -V

tc utility, iproute2-ss090324

 

 

проверяю c клиента

# ping -c1 10.44.0.3

PING 10.44.0.3 (10.44.0.3) 56(84) bytes of data.

64 bytes from 10.44.0.3: icmp_seq=1 ttl=64 time=68.4 ms

 

--- 10.44.0.3 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 68.456/68.456/68.456/0.000 ms

в итоге получаю

bridge:~# tc -s filter show dev eth1 | grep -A 1 1:10

filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 1 success 1)

match 0a2c0004/ffffffff at 16 (success 1 )

bridge:~# tc -s filter show dev eth2 | grep -A 1 1:10

filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 1 success 1)

match 0a2c0004/ffffffff at 12 (success 1 )

То есть и ушедший ping и вернувшийся pong отфильтровались верно.

Это при

bridge:~# uname -r

2.6.26-2-686

 

Если же загружаюсь с

bridge:~# uname -r

2.6.31-1-686

 

то при тех же фильтрах

bridge:~# tc -s filter show dev eth1 | grep -A 1 1:10

filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 1 success 0)

match 0a2c0004/ffffffff at 16 (success 0 )

bridge:~# tc -s filter show dev eth2 | grep -A 1 1:10

filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 1 success 0)

match 0a2c0004/ffffffff at 12 (success 0 )

 

Соотвественно и вопрос - почему в 26 фильтруется, а в 31 нет.

[photon]

Попробуйте c protocol ip, возможно тегированный трафик ходит только по виртуальным интерфейсам. Если не поможет, то с protocol 802.1Q и смещениями 20 и 16 вместо 16 и 12.

Edited December 16, 2009 by photon

[v7100]

bridge:~# tcpdump -i eth2

tcpdump: WARNING: eth2: no IPv4 address assigned

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes

15:28:15.058476 vlan 444, p 0, IP 10.44.0.4 > 10.44.0.3: ICMP echo request, id 63292, seq 1, length 64

15:28:15.060651 vlan 444, p 0, IP 10.44.0.3 > 10.44.0.4: ICMP echo reply, id 63292, seq 1, length 64

^C

 

А про 16 и 20 - действительно заработало! Спасибо!

Логику этого дела оставим в стороне :-Р

 

bridge:~# tc -s filter show dev eth1 | grep -A 1 1:10

filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 3 success 1)

match 0a2c0004/ffffffff at 20 (success 1 )

bridge:~# tc -s filter show dev eth2 | grep -A 1 1:10

filter parent 1: protocol 802.1Q pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 (rule hit 3 success 1)

match 0a2c0004/ffffffff at 16 (success 1 )

 

[voron]

Замена protocol 802.1q на protocol ip в конфигурации с 20 и 16 что-то меняет?

[photon]

А про 16 и 20 - действительно заработало! Спасибо!

Логику этого дела оставим в стороне :-Р

Логика простая: протокол 802.1Q вставляет в кадр после dst MAC свои 4 байта, поэтому и происходит смещение.

[v7100]

Замена protocol 802.1q на protocol ip в конфигурации с 20 и 16 что-то меняет?

Конечно меняет - пакеты не классифицируются. Ведь ip - это для IPv4, а у меня 802.1q, IPv4 там нет

[v7100]

А про 16 и 20 - действительно заработало! Спасибо!

Логику этого дела оставим в стороне :-Р

Логика простая: протокол 802.1Q вставляет в кадр после dst MAC свои 4 байта, поэтому и происходит смещение.

Эта логика мне известа, я думал "protocol 802.1q" как раз эту логику и реализует. И ведь таки да - реализует и работает, но в 26 ядре, обратите внимаение.

А вот для 31 ядра пришлось мало того, что указать "protocol 802.1q" так еще указывать "at 16" и "at 20" вместо "at 12" и "at 16" соответственно.

Ну куда это годится? :-)

[photon]

Тут видимо ошибка преобразования match ip dst в match A/B at C в зависимости от протокола. По идее, эту вещь должен делать tc при создании правила, а не модуль ядра. С ядром может быть такая история: у кадра перестали откусываться 4 байта от 802.1q, а tc еще не допилили под это. Лучше спросить в netdev@vger.kernel.org.

Edited December 16, 2009 by photon

[SokolovS]

Хочу еще раз поднять эту тему, т.к. не совсем все понятно. Как быть если через мост идет и чистый IP трафик и тегированный dot1q? Под "protocol dot1q" получается нужно строить отдельный хеш? :(

[photon]

Да. Причина скорее не в том, что нужны правила с разными протоколами (никто не мешает указать protocol any), а в том, что смещения у IP-адресов в тегированных и нетегированных пакетах будут разные. Хэши еще можно строить с помощью фильтра flow, а также netfilter-модулей IPMARK/IPCLASSIFY. Насколько я помню, там данные берутся из sk_buff, и они не привязаны к смещениям.

Edited March 24, 2010 by photon

[SokolovS]

Понял спс. Скорее откажусь от тегов в транзитном трафике, ядро сети все на L3, буду кидать VLAN для ближайшей L3 аггрегации.