Jump to content
Калькуляторы

Linux u32 filter 802.1q

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

 

Собираю схему с шейпящим бриджем - 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 нет.

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

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 )

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
А про 16 и 20 - действительно заработало! Спасибо!

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
А про 16 и 20 - действительно заработало! Спасибо!

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this