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:

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

Układ adresowania:

HOST: 10.0.7.1
VM: 10.0.7.101
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.

— Yadutaf
źródło

Nie rozumiem, dlaczego to pytanie zostało oznaczone jako nie na temat. Jest to z pewnością pytanie sysadmin / netadmin, istotne dla wielu środowisk wirtualizacji i nie jest trywialne (a jeśli tak, to 90% pytań na StackOverflow również jest nie na temat). Bardzo bym chciał, gdyby ludzie, którzy oznaczyli go jako „nie na temat”, próbowali wyjaśnić dlaczego, zamiast kopiować i wklejać regułę, która oczywiście tutaj nie ma zastosowania. Dziękuję Ci!

— jpetazzo

@jpetazzo To nie jest nie-temat, i mogę tylko założyć, że osoby zamykające to zrobiły w oparciu o słabą organizację / prezentację pytania (prawdopodobnie z powodu tego, że OP nie jest administratorem sys / net). Ponadto zakres błędu serwera (nie tylko temat) różni się od przepełnienia stosu - twój argument sprawia, że myślę, że nie odwiedziłeś naszego centrum pomocy, ponieważ nie ma to sensu.

— Chris S

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 !

— Yadutaf
źródło

Więc musiałeś odznaczyć „no promisc mode” również na tej maszynie wirtualnej, tak sądzę?

— Nils

Rzeczywiście, nie jest zaznaczone.

— yadutaf