OpenVZ Forum


Home » International » Russian » *SOLVED* shaping и veth
*SOLVED* shaping и veth [message #16215] Tue, 28 August 2007 12:58 Go to next message
sa10 is currently offline  sa10
Messages: 103
Registered: May 2007
Location: Minsk
Senior Member
Конфигурация несущей системы:
Portage 2.1.2.12 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.5-r4, 2.6.18-028stab039 x86_64)
System uname: 2.6.18-028stab039 x86_64 Intel(R) Xeon(TM) CPU 3.40GHz
Gentoo Base System release 1.12.9
Timestamp of tree: Mon, 27 Aug 2007 08:30:01 +0000
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.61
sys-devel/automake:  1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.21
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -O2 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
++++++++++++++++
vzctl-3.0.18-r1 
vzquota-3.0.9
++++++++++++++++


На сервере 2 интерфейса Broadcom BCM5704 Gigabit

На одном из VE создан фаервол c управлением через shorewall-4.0.2
Эта система отличается от несущей:
 профиль (hardened/amd64/multilib, 
gcc-3.4.6


Интерфейсы veth стыкуются на несущей машине через бриджи. в бриджи включены виланы созданные на bond0 из двух адаптеров.

Фаервол разруливает доступ в инет, сетевые службы здесь же на VE в dmz и внутреннюю сеть.

ВСе кроме нарезки трафика для внутренней сети нормально работает, но шейпинг творит что попало...

До других интефейсов еще не дошли, на внутреннем...
Ставишь лимит 10 мегабит, дает около 10 мегабит, ставишь 20 или 100Мбит, дает около 300Кбит и канал рвется постоянно.
Шоревол не причем, делал руками простую нарезку с тем же эффектом. На несущей машине делаю все то же самое, вроде никаких аномалий.
Без шейпинга шлюз отдает поток без замечаний на уровне 93-94 Мбит по 100Мбитной сети.
В /proc/user_beancounters тишина и спокойствие
Где поискать причину?


--------------------

[Updated on: Thu, 06 September 2007 15:22] by Moderator

Report message to a moderator

Re: shaping и veth [message #16237 is a reply to message #16215] Wed, 29 August 2007 13:40 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

1. проверьте 3 опции в конфиге ядра:
# CONFIG_NET_SCH_CLK_JIFFIES is not set
CONFIG_NET_SCH_CLK_GETTIMEOFDAY=y
# CONFIG_NET_SCH_CLK_CPU is not set

возможно вам стоит поменять на 1-ую CLK_JIFFIES.

2. я еще не понял из вашего сообщения на каком интерфейсе настроен shaping... плюс какой scheduler?


http://static.openvz.org/userbars/openvz-developer.png
Re: shaping и veth [message #16245 is a reply to message #16237] Wed, 29 August 2007 15:04 Go to previous messageGo to next message
sa10 is currently offline  sa10
Messages: 103
Registered: May 2007
Location: Minsk
Senior Member
В конфиге стоят такие опции
grep CONFIG_NET_SCH /proc/config.gz
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m

И там стоит CONFIG_NET_SCH_CLK_JIFFIES=y
Можно поставить GETTIMEOFDAY=y для эксперимента, но на несущей машине ведь все работает без замечаний, проблема с управлением потока на виртуальном интерфейсе VE.
Я уже думаю над переносом фаервола на несущую машину, но это идеологически неправильно. Делать шейпинг на несущей машине, а фильтрацию пакетов на виртуальной тоже неразумно.
> 2. я еще не понял из вашего сообщения на каком интерфейсе настроен shaping... плюс какой scheduler?
Используются интерфейсы veth и scheduler HTB

На несущей машине интерфейсы выглядят так примерно (сори за большую портянку):
2: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
4: eth0: <BROADCAST,MULTICAST,SLAVE,UP,10000> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
    link/ether 00:15:60:ab:61:b4 brd ff:ff:ff:ff:ff:ff
6: eth1: <BROADCAST,MULTICAST,SLAVE,UP,10000> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
    link/ether 00:15:60:ab:61:b4 brd ff:ff:ff:ff:ff:ff
8: bond0: <BROADCAST,MULTICAST,MASTER,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:15:60:ab:61:b4 brd ff:ff:ff:ff:ff:ff
1: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,10000> mtu 1500 qdisc noqueue
    link/void
10: vlan5@bond0: <BROADCAST,MULTICAST,PROMISC,MASTER,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:15:60:ab:61:b4 brd ff:ff:ff:ff:ff:ff
12: vlan36@bond0: <BROADCAST,MULTICAST,PROMISC,MASTER,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:15:60:ab:61:b4 brd ff:ff:ff:ff:ff:ff
14: vlan111@bond0: <BROADCAST,MULTICAST,PROMISC,MASTER,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:15:60:ab:61:b4 brd ff:ff:ff:ff:ff:ff
16: vlan222@bond0: <BROADCAST,MULTICAST,PROMISC,MASTER,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:15:60:ab:61:b4 brd ff:ff:ff:ff:ff:ff
18: brdmz: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:15:60:ab:61:b4 brd ff:ff:ff:ff:ff:ff
20: brext: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:15:60:ab:61:b4 brd ff:ff:ff:ff:ff:ff
22: brint: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:15:60:ab:61:b4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.4/24 brd 192.168.5.255 scope global brint
24: brtorg: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:15:60:ab:61:b4 brd ff:ff:ff:ff:ff:ff
5: veth777.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:18:51:fb:68:f8 brd ff:ff:ff:ff:ff:ff
7: veth777.1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:18:51:39:93:e3 brd ff:ff:ff:ff:ff:ff
9: veth777.2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:18:51:73:a8:23 brd ff:ff:ff:ff:ff:ff
11: veth777.3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:18:51:af:80:0d brd ff:ff:ff:ff:ff:ff
13: veth1001.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:18:51:dd:be:bf brd ff:ff:ff:ff:ff:ff
15: veth221.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
    link/ether 00:18:51:83:cd:79 brd ff:ff:ff:ff:ff:ff
________________________________
bridge name     bridge id               STP enabled     interfaces
brdmz           8000.001560ab61b4       no              vlan111
                                                        veth221.0
                                                        veth777.1
                                                        veth1001.0
brext           8000.001560ab61b4       no              vlan36
                                                        veth777.2
brint           8000.001560ab61b4       no              vlan5
                                                        veth777.0
brtorg          8000.001560ab61b4       no              vlan222
                                                        veth777.3



--------------------

Re: shaping и veth [message #16246 is a reply to message #16245] Wed, 29 August 2007 15:20 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

ага. т.е. shaping вы настраиваете внутри VE на veth, так?
попрошу завтра попробовать кого-нибудь воспроизвести.

обычно мы так не делаем и такую конфигурацию не проверяли даже, по следующим причинам:

1. разумнее ограничивать не виртуальные интерфейсы, а реальные куда уходит трафик вовне. т.е. какой смысл ограничивать трафик в рамках одной машины?

2. плюс мы всегда использовали CBQ... Хотя ANK говорит что HTB правильнее...

а какие правила у вас настроены tc?


http://static.openvz.org/userbars/openvz-developer.png
Re: shaping и veth [message #16270 is a reply to message #16246] Thu, 30 August 2007 10:03 Go to previous messageGo to next message
sa10 is currently offline  sa10
Messages: 103
Registered: May 2007
Location: Minsk
Senior Member
Quote:

> shaping вы настраиваете внутри VE на veth, так?

Да именно так.
Quote:

> 1. разумнее ограничивать не виртуальные интерфейсы, а реальные >куда уходит трафик вовне. т.е. какой смысл ограничивать трафик в >рамках одной машины?

То есть помесить фаервол на несущую машину (HN)?
Вероятно во многих случаях это разумно.
Наш проект - кластер из двух узлов под openvz где располагаются сетвые службы, из соображений безопасности почти каждая на отдельном VE в виртуальной DMZ и, собственно, фаервол нарезающий трафик для DMZ, для внешних и внутренних сетей.
Трафик внешней сети и сети DMZ на несущем узле не выделяется. Там есть соотвествующие этим сетям виланы без адресов и они включены в соответсвующие бриджи для подключения интерфейсов VE

Можно фаервол на HN перемесить, но тогда обнаружение уязвимости или погрешости в настройке дает возможность валить всю систему.
И я с трудом себе представляю как сможет фаервол на HN управлять пакетами между виртуальными машинами если HN этот трафик не видит.

Quote:

2. плюс мы всегда использовали CBQ... Хотя ANK говорит что HTB правильнее...

Вообще то все рекомендуют HTB. И наш shorewall использует именно его.

Quote:

а какие правила у вас настроены tc?

Воспроизводить их все (портянка на пару страниц) не требуется.
Можно проверить любой простейший вариант и попробовать ограничить на уровне близком к максимуму.
Я получаю трафик на уровне 2-4МБит при ограничении на 100Мбит с отрицательными значениями токенов, например
tokens: -16742272 ctokens: -1513472
Как я понимаю отрицательные значения говорят об отстутствии очереди.

Впрочем я могу выслать Вам почтой свои конфиги Sorewall, публиковать их в форуме будет неправильно.
Скажите куда, вероятно dev@sw.ru - общий адрес





--------------------

[Updated on: Thu, 30 August 2007 10:05]

Report message to a moderator

Re: shaping и veth [message #16281 is a reply to message #16270] Thu, 30 August 2007 11:51 Go to previous messageGo to next message
gblond is currently offline  gblond
Messages: 64
Registered: May 2007
Member
Почему в DMZ располагается firewall? Вернее, почему в DMZ используются vlan-ы?

Воспроизводится ли данная проблема в "простой" конфигурации без vlan-ов, firewall-ов и т.п. ?

Вышлите, пожалуйста, правила tc на мой e-mail.
Re: shaping и veth [message #16285 is a reply to message #16281] Thu, 30 August 2007 12:13 Go to previous messageGo to next message
sa10 is currently offline  sa10
Messages: 103
Registered: May 2007
Location: Minsk
Senior Member
> Почему в DMZ располагается firewall? Вернее, почему в DMZ используются vlan-ы?
Потому, что допускается возможность подключения в DMZ внешних устройств через vlan.
Трафик рвется не только с машинами в DMZ, прокачка с фаервола работает так же, а он имеет адрес во внутренней сети.

> Воспроизводится ли данная проблема в "простой" конфигурации без vlan-ов, firewall-ов и т.п. ?

При отключенной пакетной фильтрации те же проблемы
Без виланов проверю позже, надо свичи переконфигурить, человека на месте нет.


PS. Конфиги выслал


--------------------

[Updated on: Thu, 30 August 2007 12:28]

Report message to a moderator

Re: shaping и veth [SOLVED] [message #16441 is a reply to message #16215] Thu, 06 September 2007 15:19 Go to previous messageGo to next message
sa10 is currently offline  sa10
Messages: 103
Registered: May 2007
Location: Minsk
Senior Member
Огромное спасибо за помощь Виталию Гусеву, проблема решена.
Rolling Eyes

Причина была в недостаточно свежей версии iproute2

У нас для фаервола использовался профиль hardened/amd64 c
ACCEPT_KEYWORDS="amd64"
Считается, что это обеспечивает более высокий уровень стабильности и безопасности системы методом консервативного подхода к обновлению пакетов и наложением дополнительных патчей.
Это ограничивает систему на установку только стабильных (старых) версий для ответственных компонентов.

Причина была в версии sys-apps/iproute2-2.6.19.20061214
Меняем ACCEPT_KEYWORDS конкретно для этого пакета
flagedit sys-apps/iproute2 -- +~amd64

и обновляем его
emerge -u sys-apps/iproute2


После обновления iproute2 до версии sys-apps/iproute2-2.6.22.20070710 USE="berkdb -atm -minimal"
Все нормализовалось.

Использовались версии пакетов
sys-kernel/openvz-sources-028.039
sys-cluster/vzctl-3.0.18-r1
sys-fs/vzquota-3.0.9

net-firewall/iptables-1.3.5-r4 USE="extensions l7filter -imq -ipv6 -static"
С более свежей версией net-firewall/iptables-1.3.8-r2
были проблемы. Как будто почти все работало, но были сообщения об ошибках, сейчас не вспомню

Дополнительно ставился shorewall-perl-4.0.3
К сожалению ни в дереве портеджей ни в оверлеях пока его нет.
Но там есть net-firewall/shorewall-3.2.9, он тоже нормально работает. Основное отличие 3.2.9 - bashscripting, вероятно его можно считать более стабильным, но дальнейшее развитие будет только у перловой версии - там больше возможностей для построения сложных алгоритмов.







--------------------

Re: shaping и veth [SOLVED] [message #20146 is a reply to message #16441] Wed, 12 September 2007 13:39 Go to previous messageGo to next message
sa10 is currently offline  sa10
Messages: 103
Registered: May 2007
Location: Minsk
Senior Member
Сообщение о полном решении проблемы было преждевременным.

Хотя проблему с с исходящим траффиком на интерфейсе veth мы решили, обнаружились похожие проблемы с входящим трафиком для машин в виртуальной зоне dmz.
Например - я настраиваю shorewall на ограничение скорости выдачи трафика другим машинам в DMZ (исходящий трафик на veth), при этом я, казалось бы, нигде прямо не указываю ограничение для входящего трафика на этом интерфейсе.
Впрочем в файле /etc/shorewall/tcdevices указаны такие значения:
###############################################################################
#INTERFACE      IN-BANDWITH     OUT-BANDWIDTH
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
$DMZ_IF         500mbit         500mbit


Величина 500 мегабит выбрана "от фонаря", дескать - "а что мало?"

После этого тест - на этой же машине выполняю подключение к соседнему виртуальному хосту, взаимодействие через veth, и скачиваю большой файл. Имею около 64Кb/s.
Fetching /home/file.xyz to file.xyz <...> 1% 1120KB 64.0KB/s 25:45 ETA

Если команды для ограничения трафика выполняешь руками - поблем нет.

Причина в ограничении скорости входящего трафика которое ставит shorewall хотя его не просят.

Вот пример минимального набора команд для ловли бага:

tc qdisc add dev eth1 root handle 1: htb default 0
tc class add dev eth1 parent 1: classid 1:1 htb rate 500mbit
tc qdisc add dev eth1 handle ffff: ingress
tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 500000kbit burst 10k drop flowid :1

Я понял это таким образом: - если трафик летит в ядре между виртуальными
интерфейсам со скоростью больше указанной, ядро дропает его почти полностью.
Для нашего случая граничное значение в /etc/shorewall/tcdevices около 12Гбит. Ставишь 12Гбит все работает нормально, уменьшаешь до 11,5Гбит - не работает.
Вероятно так быть не должно.
В обычной ситуации трафик дропается, но держится на нужной величине, полностью не убивается как с openvz.

В нашем случае мы обойдемся без ограничений входящего трафика, но это может быть полезно в отдельных случаях.
Интересно как будет работать IFB....



--------------------

[Updated on: Wed, 12 September 2007 13:44]

Report message to a moderator

Re: shaping и veth [SOLVED] [message #21062 is a reply to message #20146] Mon, 01 October 2007 14:22 Go to previous messageGo to next message
sa10 is currently offline  sa10
Messages: 103
Registered: May 2007
Location: Minsk
Senior Member
Quote:

Для нашего случая граничное значение в /etc/shorewall/tcdevices около 12Гбит. Ставишь 12Гбит все работает нормально, уменьшаешь до 11,5Гбит - не работает.

На самом деле для отключения ограничений входящего трафика на интерфейсе нужно поставить значение в "0"

Тем не менее, подобное ограничение может понадобиться, например, для ликвидации очереди пакетов на модеме провайдера. На данный момент наш входящий канал меньше 10Мбит, но не намного.

Хотелось бы ответа - планируется ли устранить этот глюк?


--------------------

Re: shaping и veth [SOLVED] [message #21271 is a reply to message #21062] Thu, 04 October 2007 06:16 Go to previous messageGo to next message
gblond is currently offline  gblond
Messages: 64
Registered: May 2007
Member
Насколько я понимаю, проблема в htb, и касается она не только виртуальных интерфесов, но и реальных. Действительно при задании тех параметров, которые вы привели, трафик ограничивается несколько неправильно.
Также при выполнении конфигурирования в dmesg-е появляется сообщение:

HTB: quantum of class 10001 is big. Consider r2q change.

что говорит о плохом соотношении параметров.

Неправильное ограничегие лечилось увеличением параметра burst (также переставало печататься "HTB: quantum ..." сообщение в dmesg-e)
Re: shaping и veth [SOLVED] [message #21293 is a reply to message #21271] Thu, 04 October 2007 13:59 Go to previous messageGo to next message
sa10 is currently offline  sa10
Messages: 103
Registered: May 2007
Location: Minsk
Senior Member
Quote:

проблема в htb, и касается она не только виртуальных интерфесов, но и реальных

Я бы с этим согласился, но на несущем сервере (то же ядро и те же версии софта) этой проблемы я не наблюдаю.

Большое значение quantum - это следствие упрощенного опредления параметров и влияние значения quantum на проблему не замечено.
Вы и сами предлагаете задание нормального значения через burst, но это проблему не решает, увы...


--------------------

Re: shaping и veth [SOLVED] [message #21348 is a reply to message #21293] Fri, 05 October 2007 14:43 Go to previous message
gblond is currently offline  gblond
Messages: 64
Registered: May 2007
Member
>Я бы с этим согласился, но на несущем сервере (то же ядро и те же версии софта) этой проблемы я не наблюдаю.

htb должен работать одинаково как на виртуальном там и на реальном интерфейсе (они одинаковы с точки зрения сетевого стека, единственное различие tx_queue_len = 0 для veth-интерфейса).


Возможно такое поведение из-за того что "tc" не может в VE прочитать параметры из /proc/net/psched (в VE этого файла нет, а он нужен "tc" для конфигурирования).
Previous Topic: iptables-1.3.8-r1 Error inserting x_tables
Next Topic: *SOLVED* TCP: time wait bucket table overflow
Goto Forum:
  


Current Time: Tue Dec 10 15:15:10 GMT 2024

Total time taken to generate the page: 0.02727 seconds