Интерфейс на основе Macvlan проверяет связь с хоста, но не из пространства имен

10

[РЕДАКТИРОВАТЬ]

Производственная система в настоящее время представляет собой смесь физических и ESXi систем. Очевидно, мы бы никогда не использовали virtualbox даже для предсерийной среды! Он использовался здесь только для того, чтобы быстро сузить проблему прямо на моем рабочем столе.

Спасибо за объяснение "в ожидании" на мета!

[/РЕДАКТИРОВАТЬ]

Моя настройка:

  1. Частная сеть vboxnet110.0.7.0/24
  2. 1 Host, рабочий стол Ubuntu
  3. 1 ВМ, сервер Ubuntu (VirtualBox)

Адресная раскладка:

  1. ВЕДУЩИЙ: 10.0.7.1
  2. VM: 10.0.7.101
  3. VM MAC NAMESPACE: 10.0.7.102

На этом VMя запустил следующие команды:

ip netns add mac                        # create a new nmespace
ip link add link eth0 mac0 type macvlan # create a new macvlan interface
ip link set mac0 netns mac

В macпространстве имен внутри виртуальной машины:

ip link set lo up
ip link set mac up
ip addr add 10.0.7.102/24 dev mac0

Так что мы в конечном итоге с: (Как начало?)

+------------------------+
| Host: 10.0.7.1         |
|                        |
| +--------------------+ |
| | VM: 10.0.7.101     | |
| |                    | |
| | +----------------+ | |
| | | NS: 10.0.7.102 | | |
| | |                | | |
| | +----------------+ | |
| +--------------------+ |
+------------------------+

Что работает:

  • Пинг между HostиVM
  • Пинг между NSиNS
  • клиент из NS

Что не работает:

  • пинг между NSиVM
  • пинг между NSиHost

Где я начал сходить с ума

  • tcpdump on host(реальная машина) фактически показывает ARP-запрос и ответы
  • tcpdump on NSпоказывает запросы ARP, отправленные на хост
  • tcpdump on VMзаставляет весь беспорядок работать (!) -> ping начинает получать ответы при запуске tcpdump на виртуальной машине?!?

Итак, держу пари, что вы к этому стремились, мой вопрос: как мне заставить это работать? Я подозреваю, что что-то не так с ARP на macvlan внутри NS, но не могу понять, что именно ...

Кстати, я сделал те же эксперименты с mac0интерфейсом непосредственно на виртуальной машине (без пространства имен), и он работал безупречно.

linux networking iproute2 namespaces yadutaf
источник
4
Я не понимаю, почему этот вопрос был помечен как не по теме. Это определенно вопрос sysadmin / netadmin, относящийся к нескольким средам виртуализации, и он не является тривиальным (или, если это так, 90% вопросов по StackOverflow также не по теме). Я был бы рад, если бы люди, которые пометили его как «не по теме», удосужились объяснить почему, а не копировать правило, которое здесь явно не применимо. Спасибо!
jpetazzo
@jpetazzo Это не не по теме, и я могу только предположить, что люди, закрывающие его, сделали это, основываясь на плохой организации / представлении вопроса (вероятно, из-за того, что OP не был администратором sys / net). Кроме того, область действия Server Fault (а не только тема) отличается от переполнения стека - ваш аргумент заставляет меня думать, что вы не посещали наш справочный центр, поскольку это не имеет смысла.
Крис С

Ответы:

13

Итак, для потомков, тот факт, что tcpdump делает все неожиданно, должен был поставить меня на правильный путь. Внутри он переключается eth0в беспорядочный режим. То есть, eth0будет выдавать весь сетевой трафик, а не только тот, который с основным серверомMAC

Однако именно так и macvlanработает: он добавляет новый вторичный виртуальный MAC-адрес, который «физический» (это виртуальная машина) сетевой адаптер не знает.

Таким образом, простой обходной путь заключается в том, чтобы вручную: ifconfig eth0 promisc

Я надеюсь, что это помогает !

yadutaf
источник
Значит, вам также пришлось снять флажок «без режима запрета» на этой виртуальной машине?
Нильс
Действительно, это не проверено.
yadutaf