Home » International » Russian » *SOLVED* shaping и veth
| *SOLVED* shaping и veth [message #16215] |
Tue, 28 August 2007 12:58  |
 |
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 #16245 is a reply to message #16237] |
Wed, 29 August 2007 15:04  |
|
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 #16270 is a reply to message #16246] |
Thu, 30 August 2007 10:03 |
|
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 #16285 is a reply to message #16281] |
Thu, 30 August 2007 12:13 |
|
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 #20146 is a reply to message #16441] |
Wed, 12 September 2007 13:39 |
|
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 #21271 is a reply to message #21062] |
Thu, 04 October 2007 06:16 |
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 #21348 is a reply to message #21293] |
Fri, 05 October 2007 14:43 |
gblond
Messages: 64
Registered: May 2007
|
Member |
|
|
>Я бы с этим согласился, но на несущем сервере (то же ядро и те же версии софта) этой проблемы я не наблюдаю.
htb должен работать одинаково как на виртуальном там и на реальном интерфейсе (они одинаковы с точки зрения сетевого стека, единственное различие tx_queue_len = 0 для veth-интерфейса).
Возможно такое поведение из-за того что "tc" не может в VE прочитать параметры из /proc/net/psched (в VE этого файла нет, а он нужен "tc" для конфигурирования).
|
|
|
|
Goto Forum:
Current Time: Thu Dec 26 09:52:19 GMT 2024
Total time taken to generate the page: 0.01511 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
