tartila Posted January 25, 2011 · Report post Для теста сервера шейпирования на каталисте поднял port-mirroring === monitor session 1 source interface Gi0/7 rx monitor session 1 destination interface Gi0/23 monitor session 2 source interface Gi0/7 tx monitor session 2 destination interface Gi0/1 === где Gi0/7 исходящий порт на BGP. Тестировал сначала FreeBSD 8.2RC и все было ok, то есть родной бридж FreeBSD гонял трафик через интерфейсы, но не устроила FreeBSD своими возможно кривыми драйверами для igb. Начал тестирование Linux, собрал шейпер на ядре 2.6.32, если быть более точным, то RHEL 6 2.6.32-71.el6.x86_64 . Поднял бридж, поднял шейпинг, проверил, что работает, поставив в разрез между другим сервером и проверив шейпирование. Однако, когда воткнулся в кольцо port-mirroring - обнаружил, что нифига не работает. Трафик на сетевухи приходит, cacti его рисует, tcpdump его видно, однако в бридж он не попадает из кольца исходя из отсутствия трафика на самом интерфейсе bridge по cacti. Однако появилась забавность буквально только что натравил tcpdump и трафик якобы прошел, однако не могу четко сказать, попадает ли он в шейпер, Шейп на Linux организовал так === tc filter add dev $LAN_PORT protocol ip parent 1:0 prio 100 u32 match ip dst $IP flowid 1:$FLOWID tc filter add dev $BGP_PORT protocol ip parent 1:0 prio 100 u32 match ip src $IP flowid 1:$FLOWID === где FLOWID - номер правила, IP - ip адрес Share this post Link to post Share on other sites
tartila Posted January 25, 2011 (edited) · Report post Вопрос отменяется, это прикол драйвера igb. Он, когда траф не требуется - заворачивает его сразу между портами на сетевухе, при этом не загружая ядро. Как только правильно включил tc - сразу траф потек. Вопрос следующий, с tc давно имел дело, хотелось бы оптимизировать подход. shaper навалял по старым своим примерам, может кто подскажет более правильный подход. Трафа уже ~ 800 MBit/s в симметрии и ~ 100 kPPS. Сейчас шейп делаю так: === tc qdisc add dev $LAN_PORT root handle 1: htb default 200 tc class add dev $LAN_PORT classid 1:10 parent 1:0 htb rate 2000Mbit tc qdisc add dev $BGP_PORT root handle 1: htb default 200 tc class add dev $BGP_PORT classid 1:10 parent 1:0 htb rate 2000Mbit tc class add dev $LAN_PORT classid 1:100 parent 1:10 htb rate 1500Kbit tc class add dev $BGP_PORT classid 1:100 parent 1:10 htb rate 1500Kbit tc class add dev $LAN_PORT classid 1:101 parent 1:10 htb rate 1500Kbit tc class add dev $BGP_PORT classid 1:101 parent 1:10 htb rate 1500Kbit tc filter add dev $LAN_PORT protocol ip parent 1:0 prio 100 u32 match ip dst 1.1.1.1 flowid 1:100 tc filter add dev $BGP_PORT protocol ip parent 1:0 prio 100 u32 match ip src 1.1.1.1 flowid 1:100 tc filter add dev $LAN_PORT protocol ip parent 1:0 prio 100 u32 match ip dst 2.2.2.2 flowid 1:101 tc filter add dev $BGP_PORT protocol ip parent 1:0 prio 100 u32 match ip src 2.2.2.2 flowid 1:101 и т.д. === просьба не пинать ногами за кривоту, только что вернулся от dummynet + ipfw ;)))) Edited January 25, 2011 by tartila Share this post Link to post Share on other sites
NiTr0 Posted January 25, 2011 · Report post хеш-фильтры пользовать. От цепочки в 1-2к проверок любой тазик в дудку скрутится, какой проц туда не ставьте. Share this post Link to post Share on other sites
tartila Posted January 27, 2011 · Report post Заюзал хеш-фильтры и вроде бы было все ok, решил воткнуть в боевую конфигу, но вот интересный момент, почему то траф режется на 100 Mbit/100 Mbit. То есть цепочки фильтров работают, можно даже увидеть при нагрузке на весь канал менее 100 Mbit реальную нарезку, но вот при привышении канала в 100Mbit идет его жесткая нарезка. С чем может быть связано? Вроде бы rate/ceil покрутил. Share this post Link to post Share on other sites
