Jump to content
Калькуляторы

Linux Bridge vs Cisco Port-Mirroring

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this