Интерфейс на основе Macvlan проверяет связь с хоста, но не из пространства имен
[РЕДАКТИРОВАТЬ]
Производственная система в настоящее время представляет собой смесь физических и ESXi систем. Очевидно, мы бы никогда не использовали virtualbox даже для предсерийной среды! Он был использован здесь только для того, чтобы быстро сузить проблему прямо на моем рабочем столе.
Спасибо за объяснение для "в ожидании" на мета!
[/РЕДАКТИРОВАТЬ]
Моя настройка:
- Частная сеть
vboxnet110.0.7.0/24 - 1 Host, рабочий стол Ubuntu
- 1 ВМ, сервер Ubuntu (VirtualBox)
Адресная раскладка:
- ВЕДУЩИЙ: 10.0.7.1
- VM: 10.0.7.101
- 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 Интерфейс напрямую на ВМ (без пространства имен) и все работало без нареканий.
1 ответ
Итак, для потомков, тот факт, что tcpdump делает все неожиданно, должен был поставить меня на правильный путь. То, что он делает внутри, это переключатель eth0 в беспорядочный режим. То есть eth0 будет выдавать весь сетевой трафик, а не только тот, который имеет основной сервер MAC
Тем не менее, это именно то, как macvlan работает: он добавляет новый вторичный виртуальный MAC-адрес, который "физический" (это виртуальная машина) сетевой адаптер не знает.
Таким образом, простой обходной путь заключается в том, чтобы вручную: ifconfig eth0 promisc
Я надеюсь, что это помогает!