v7100 Опубликовано 16 декабря, 2009 Доброго всем времени суток! Собираю схему с шейпящим бриджем - 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 нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 16 декабря, 2009 (изменено) Попробуйте c protocol ip, возможно тегированный трафик ходит только по виртуальным интерфейсам. Если не поможет, то с protocol 802.1Q и смещениями 20 и 16 вместо 16 и 12. Изменено 16 декабря, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v7100 Опубликовано 16 декабря, 2009 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 ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 16 декабря, 2009 Замена protocol 802.1q на protocol ip в конфигурации с 20 и 16 что-то меняет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 16 декабря, 2009 А про 16 и 20 - действительно заработало! Спасибо!Логику этого дела оставим в стороне :-Р Логика простая: протокол 802.1Q вставляет в кадр после dst MAC свои 4 байта, поэтому и происходит смещение. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v7100 Опубликовано 16 декабря, 2009 Замена protocol 802.1q на protocol ip в конфигурации с 20 и 16 что-то меняет? Конечно меняет - пакеты не классифицируются. Ведь ip - это для IPv4, а у меня 802.1q, IPv4 там нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v7100 Опубликовано 16 декабря, 2009 А про 16 и 20 - действительно заработало! Спасибо!Логику этого дела оставим в стороне :-Р Логика простая: протокол 802.1Q вставляет в кадр после dst MAC свои 4 байта, поэтому и происходит смещение. Эта логика мне известа, я думал "protocol 802.1q" как раз эту логику и реализует. И ведь таки да - реализует и работает, но в 26 ядре, обратите внимаение.А вот для 31 ядра пришлось мало того, что указать "protocol 802.1q" так еще указывать "at 16" и "at 20" вместо "at 12" и "at 16" соответственно. Ну куда это годится? :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 16 декабря, 2009 (изменено) Тут видимо ошибка преобразования match ip dst в match A/B at C в зависимости от протокола. По идее, эту вещь должен делать tc при создании правила, а не модуль ядра. С ядром может быть такая история: у кадра перестали откусываться 4 байта от 802.1q, а tc еще не допилили под это. Лучше спросить в netdev@vger.kernel.org. Изменено 16 декабря, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 22 марта, 2010 Хочу еще раз поднять эту тему, т.к. не совсем все понятно. Как быть если через мост идет и чистый IP трафик и тегированный dot1q? Под "protocol dot1q" получается нужно строить отдельный хеш? :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 24 марта, 2010 (изменено) Да. Причина скорее не в том, что нужны правила с разными протоколами (никто не мешает указать protocol any), а в том, что смещения у IP-адресов в тегированных и нетегированных пакетах будут разные. Хэши еще можно строить с помощью фильтра flow, а также netfilter-модулей IPMARK/IPCLASSIFY. Насколько я помню, там данные берутся из sk_buff, и они не привязаны к смещениям. Изменено 24 марта, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 24 марта, 2010 Понял спс. Скорее откажусь от тегов в транзитном трафике, ядро сети все на L3, буду кидать VLAN для ближайшей L3 аггрегации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...