[Sysadmins] Bridges

[Дмитрий]

Gennady Kovalev пишет:
> Добрый день,
>
> Я с бриджами, так сказать, первый раз столкнулся. Настроил как уже 
> рекомендовали в рассылке и в wiki. Все разаботало.
>
> Вопрос как с ними жить принято.
>
> 1. При перезапуске системы интерфейс vzbr0 автоматически не поднимается, хотя 
> ONBOOT=yes. Приходится его поднимать ручками. Рестарт network после загрузки 
> тоже помогает.
>   
Странно конечно это. Неплохо бы увидеть что там в /etc/net/ifaces/vzbr0 
есть? И что за система?
> 2. Бридж мне нужен для броадкастов в VE.  И вот когда VE рестартует, его 
> интерфейс, например, veth100.0 пропадает из бриджа, приходится добавлять 
> ручками. Как автоматизировать?
>
>   
Скрипты vz должны его при vzctl stop убирать его из бриджа и при vzctl 
start добавлять. veth100.0 не должен присутствовать в списке HOST = в 
файле /etc/net/ifaces/vzbr0/options. Смотрим следующий мануал: 
http://wiki.openvz.org/VEs_and_HNs_in_different_subnets

Для того чтобы broabcast у vzbr0 был не 0.0.0.0, а определялся по шлюзу 
и маске, добавляем AUTO_BROADCAST=yes.
Для того чтобы у интерфейса внутри контейнера broadcast тоже не был 
0.0.0.0, то я долго не заморачивался и модифицировал скрипт 
vznetcfg.custom, заменив строчку

$vzctl exec $VEID $ip address add $IP dev $VEIFNAME
на
$vzctl exec $VEID $ip address add $IP broadcast $VETH_BROADCAST dev $VEIFNAME

И в файле конфигураций /etc/vz/conf/100.conf добавил VETH_BROADCAST=192.168.0.255(собственно нужное значение).

Всё это я проделывал на ALS4.


Теперь мои вопросы на эту же тему:

Я их уже не раз озвучивал, но решений так не найдено.

1. Заметил тормоза при использовании бриджа. Делал терминальное решение на базе xrdp. eth0 был в бридже br0'ом. Всё работало нормально, но наблюдались тормоза. Т.е. менюшки, всплывающие окна и т.п. отрисовывались жутко медленно, но терпимо.
После того как убрал бридж тормоза пропали и всё просто залетало. Почему бридж такой не хороший? Можно ли тут что-то сделать?

2. Проблема с broadcast'ами. Тут не знаю с бриджем ли дело или с OpenVZ. Но в 64-х битной системе при пинге broadcast'а все машины отвечали, но пакеты максимум попадали на br0 и не попадали на veth100.0. Во всех остальных случаях пакеты благополучно доходили до места назначения.
Такого не наблюдается в 32-х битной системе.

3. Некоторые свичи(я работал с DLink) не сразу почему-то догоняют на каком порту находится у них контейнер. Т.е. samba из контейнера бросала на broadcast UDP пакет на который все машины благополучно пытались ответить, но... Но когда они делали arp запрос, мол кто контейнер с samba'ой, контейнер отвечает. Клиенты кидают UDP пакет уже известному IP, но этот пакет не попадает даже на физический интерфей той машины где находится контейнер. Т.е. комутатор либо этот пакет вообще ни на один порт не бросает, либо не туда.
В бридже было несколько интерфейсов, где один физический и 2 или 3 veth. Где сначала 1 из контейнеров активно используется в сети, но затем начинает использоваться только внутри физической машины. Похоже на то что после этого момента коммутатор начинает догонять где же находится другой контейнер.
Такие гадания комутатора происходят каждый раз стоит, только освободить какой-нибудь порт или наоборот, т.е. кто-то в локальной сети перезагрузил машину и начались жудкие тормоза. Клиентские машины входят в домен по 5 минут, что очень неприятно. Единственное решение этой проблемы, которое я использовал, это не ставить samba'у в контейнер и не использовать бриджы вообще.

Что такое с этими бриджами? Они такие удобные в использовании, но почему то создают кучу неприятностей.