[tartila]

Для теста сервера шейпирования на каталисте поднял 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 адрес

[tartila]

Вопрос отменяется, это прикол драйвера 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 ;))))

Изменено 25 января, 2011 пользователем tartila

[NiTr0]

хеш-фильтры пользовать. От цепочки в 1-2к проверок любой тазик в дудку скрутится, какой проц туда не ставьте.

[tartila]

Заюзал хеш-фильтры и вроде бы было все ok, решил воткнуть в боевую конфигу, но вот интересный момент, почему то траф режется на 100 Mbit/100 Mbit. То есть цепочки фильтров работают, можно даже увидеть при нагрузке на весь канал менее 100 Mbit реальную нарезку, но вот при привышении канала в 100Mbit идет его жесткая нарезка. С чем может быть связано? Вроде бы rate/ceil покрутил.