Interfejs oparty na Macvlan pinguje z hosta, ale nie z przestrzeni nazw

[EDYTOWAĆ]

System produkcyjny jest obecnie mieszanym systemem fizycznym i opartym na ESXi. Oczywiście nigdy nie używalibyśmy virtualboksa nawet w środowisku przedprodukcyjnym! Został użyty tutaj tylko do szybkiego zawężenia problemu bezpośrednio na moim pulpicie.

Dziękujemy za wyjaśnienie „wstrzymania” na meta!

[/EDYTOWAĆ]

Moja konfiguracja:

1. Sieć prywatna vboxnet110.0.7.0/24
2. 1 Host, pulpit Ubuntu
3. 1 VM, serwer Ubuntu (VirtualBox)

Układ adresowania:

1. HOST: 10.0.7.1
2. VM: 10.0.7.101
3. VM NAMESPACE : 10.0.7.102

Na VMpobiegłem następujące polecenia:

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

W macprzestrzeni nazw wewnątrz maszyny wirtualnej:

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

Więc w zasadzie kończymy na: (jak Inception?)

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

Co działa:

• Ping pomiędzy HostiVM
• Ping pomiędzy NSiNS
• dhclient z NS

Co nie działa:

• ping pomiędzy NSiVM
• ping pomiędzy NSiHost

Gdzie zacząłem wariować:

• tcpdump on host(prawdziwa maszyna) faktycznie pokazuje żądanie ARP ORAZ odpowiedzi
• tcpdump on NSpokazuje żądania ARP wysłane do hosta
• tcpdump on VMsprawia, że ​​cały bałagan działa (!) -> ping zaczyna otrzymywać odpowiedzi, gdy tcpdump jest uruchamiany na maszynie wirtualnej?!?

Więc założę się, że byłeś chętny, moje pytanie brzmi: jak sprawić, by działało? Podejrzewam, że coś jest nie tak z ARP na macvlan w NS, ale nie mogę zrozumieć, co dokładnie ...

Przy okazji zrobiłem te same eksperymenty z mac0interfejsem bezpośrednio na maszynie wirtualnej (bez przestrzeni nazw) i działało bezbłędnie.

OK, więc dla potomności fakt, że tcpdump sprawia, że ​​nagle wszystko działa, powinien był mnie nakłonić. To, co robi wewnętrznie, to przejście eth0do trybu rozwiązłego. Oznacza to, eth0że da cały ruch sieciowy, nie tylko ten z głównym serweremMAC

Jednak właśnie tak macvlandziała: dodaje nowy dodatkowy wirtualny adres MAC, którego karta sieciowa „fizyczna” (czyli VM) nie zna.

Zatem łatwym obejściem jest ręczne: ifconfig eth0 promisc

Mam nadzieję, że to pomoże !