LINUX.ORG.RU
ФорумAdmin

CentOS, veth и ifcfg

 , , , , veth


1

1

Столкнулся с вот такой презамечательной фичей реализации L2-мостов в Линуксе.

Вкратце: при добавлении нового интерфейса в бридж MAC бриджа может пересчитаться, что приведёт к недоступности хоста, если он должен быть досягаем через IP, назначенный бриджу. Конкретно в моём случае происходит затирание ARP-таблицы, и хост не видится из сети, пока из хоста что-либо не пропинговать, чтобы получить MAC шлюза.

Как наиболее разумный вариант решения проблемы предлагают такое:

We could go back to using a VETH device for the host, and using the bond MAC address, and stop putting an IP address on the bridge. We then would need to assign a random MAC to the bond itself (which now seems to work).

Я правильно понимаю, что предлагают на хосте создать pair из двух veth'ов, один воткнуть в мост (повесив на другой IP бриджа, а самому бриджу IP не назначать)? Не хочется костылять самопальным скриптом такое, а ifcfg-*, похоже, не поддерживает создание пары veth. Писать самому?

И вообще, как тогда правильно организовывать бриджи на гипервизорах?

смену мака в arp-таблицах соседей можно форсировать через «arping -U»

А openvswitch c fake bridge не пробовал?

Можно в бридж пихнуть dummy интерфейс с максимальным MAC-ом

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)

Там еще рецепт был «ip link set br-if address macaddr»

vel ★★★★★
()
Ответ на: комментарий от vel

смену мака в arp-таблицах соседей можно форсировать через «arping -U»

Лучше уж я пинг в фоне пускать буду =).

А openvswitch c fake bridge не пробовал?

Не. libvirt, по идее, его не поддерживает. Или я чего-то не знаю?

Можно в бридж пихнуть dummy интерфейс с максимальным MAC-ом

Костыль? Лучше тогда и вправду два veth на хосте.

Там еще рецепт был «ip link set br-if address macaddr»

ifcfg для бриджа умеет принимать HWADDR? Гуглил, но в примерах такого нигде нет.

post-factum ★★★★★
() автор топика
Ответ на: комментарий от post-factum

если ifcfg сам не может, то в каком-нибудь пре/пост-скрипте можно задать.

Вроде libvirt должен знать openvswich. Вторая ссылка в гугле «libvirt opebvswitch» рассказывает про

[...]
    <interface type='bridge'>
      <mac address='52:54:00:fb:00:01'/>
      <source bridge='ovsbr0'/>
      <virtualport type='openvswitch'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
[...]
Да и на vlan ovs libvirt есть интересные примеры

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от post-factum

Ну это решение «рандомности» veth. У veth 2 конца и 2 адреса. в VETH_MAC ты задаешь только локальный адрес, а тот, что уходит гостю будет рандомный?

Чтоб не съезжал мак на IP бриджа самый надежный способ - указать MAC интерфейсу бриджа, а не играть с МАС-ами интерфейсов входящих в бридж.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 2)
Ответ на: комментарий от vel

Оба peer'а veth — на одном хосте (на гипервизоре). Один peer с рандомным MAC'ом входит в бридж. Другой peer имеет нужный мне MAC, на него же навешивается нужный IP.

По сути, MAC что бриджа, что peer'а в бридже мне до лампочки.

post-factum ★★★★★
() автор топика
Последнее исправление: post-factum (всего исправлений: 1)

а бриджами из шапкиных руководств по серверу и по виртуализации нельзя пользоваться?

anonymous
()
Ответ на: комментарий от anonymous

Например? Они же стандартные.

Ну и виртуализация тут как бы ни при чём, получается. Виртуалки, подключенные к бриджу, остаются доступные. Становится недоступным только сам гипервизор, потому что на сам бридж повешен его IP.

post-factum ★★★★★
() автор топика
Ответ на: комментарий от post-factum

нафига этот огород с veth, если можно задать ip бриджу, а чтоб mac не съежал задать mac бриджу. Задать mac можно только после подъема самого бриджа.

vel ★★★★★
()
Ответ на: комментарий от vel

нафига этот огород с veth

Не знаю, мне кажется, что это красиво и симметрично — гипервизор подключен к сети так же, как и гостевые системы.

post-factum ★★★★★
() автор топика

Столкнулся с вот такой презамечательной фичей реализации L2-мостов в Линуксе

проблема известна много лет, решена простым ограничением mac-ов которые выдает либвирт, до начинающихся с FE. таким образом поднимающиеся виртуалки не могут получить мак ниже того на котором сидит мост. все уже сделано и решено

dyasny ★★★★★
()
Ответ на: комментарий от post-factum

этот костыль работает с 2010го, я сам баг открывал. с тех пор ни одной проблемы в тысячах установок kvm

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

Да я ж не спорю, но, как по мне, это некрасиво.

post-factum ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.