Megas Опубликовано 28 апреля, 2012 (изменено) · Жалоба Пока еще трафик режится через --set-mark в FORWARD и дальше уже обрабатывает tc перейти на хэш таблицы не получается из-за vlan интерфейсов на сервере, пробовал различные варианты но трафик из vlan не попадает в filter, только когда указываешь eth1.2020 и т.д. Решил попробовать через CLASSIFY в iptables отправлять сразу в нужный класс. Смотрю пример: http://shearer.org/Linux_Shaping_Template И не пойму, кто-то делает -j CLASSIFY в таблице mangle forward, кто-то в mangle postrouting но чем заинтересовал этот пример, они вешают tos в forward и дальше класс в postrouting Собственно вопросов несколько, есть ли разница где указывать class в forward или postrouting ведь согласно все находится в одной цепочке перед выходом пакета. Изменено 28 апреля, 2012 пользователем Megas Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 28 апреля, 2012 · Жалоба пробовал различные варианты но трафик из vlan не попадает в filter, только когда указываешь eth1.2020 и т.д. мб использовать дополнительный уровень абстракции в виде ifb ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 28 апреля, 2012 (изменено) · Жалоба FORWARD - до SNAT, POSTROUTING - после SNAT Юзайте IFB Изменено 28 апреля, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 29 апреля, 2012 (изменено) · Жалоба Пока еще трафик режится через --set-mark в FORWARD и дальше уже обрабатывает tc перейти на хэш таблицы не получается из-за vlan интерфейсов на сервере, пробовал различные варианты но трафик из vlan не попадает в filter, только когда указываешь eth1.2020 и т.д. Можно классифицировать и на физическом интерфейсе. 802.1Q добавляет к фрейму дополнительный заголовок размером в 4 байта, т.е. значения смещений для destination и source IP (12 и 16, соответственно) нужно увеличить на 4. Изменено 29 апреля, 2012 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Megas Опубликовано 1 мая, 2012 · Жалоба photon, в упор не могу понять почему не попадает никакой трафик. root@gateway:/shaper_htb_hash# tc -s -d -p filter show dev eth0 filter parent 1: protocol ip pref 100 u32 filter parent 1: protocol ip pref 100 u32 fh 804: ht divisor 1 filter parent 1: protocol ip pref 49149 u32 filter parent 1: protocol ip pref 49149 u32 fh 131: ht divisor 256 filter parent 1: protocol ip pref 49149 u32 fh 803: ht divisor 1 filter parent 1: protocol ip pref 49150 u32 filter parent 1: protocol ip pref 49150 u32 fh 121: ht divisor 256 filter parent 1: protocol ip pref 49150 u32 fh 802: ht divisor 1 filter parent 1: protocol ip pref 49151 u32 filter parent 1: protocol ip pref 49151 u32 fh 111: ht divisor 256 filter parent 1: protocol ip pref 49151 u32 fh 801: ht divisor 1 filter parent 1: protocol ip pref 49152 u32 filter parent 1: protocol ip pref 49152 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 49152 u32 fh 800::800 order 2048 key ht 800 bkt 0 link 111: (rule hit 0 success 0) match IP src 0.0.0.0/0 (success 0 ) hash mask ff000000 at 20 root@gateway:/shaper_htb_hash# Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 1 мая, 2012 · Жалоба Поскольку через физический интерфейс идет уже тегированный трафик, то IP-адреса должны быть смещены на 4 байта. Нужно использовать правила вида match u32 0xc0a000001 0xffffffff at 16 вместо match ip dst 10.0.0.1. Для проверки смотрите трафик с помощью tcpdump. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...