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...