Macvlan-basierte Schnittstellen-Pings vom Host, jedoch nicht vom Namespace

[BEARBEITEN]

Das Produktionssystem ist derzeit ein gemischtes physisches und ESXi-basiertes System. Wir würden virtualbox natürlich niemals verwenden, auch nicht für eine Vorproduktionsumgebung! Es wurde hier nur verwendet, um das Problem schnell direkt auf meinem Desktop einzugrenzen.

Vielen Dank für die Erklärung für das "on hold" auf Meta!

[/BEARBEITEN]

Mein Setup:

Privates Netzwerk vboxnet110.0.7.0/24
1 Host, Ubuntu-Desktop
1 VM, Ubuntu-Server (VirtualBox)

Adressierungslayout:

Host: 10.0.7.1
VM: 10.0.7.101
VM MAC NAMESPACE : 10.0.7.102

Auf dem habe VMich die folgenden Befehle ausgeführt:

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

Im macNamespace innerhalb der VM:

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

Damit wir im Grunde genommen am Ende Folgendes haben: (Like Inception?)

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

Was funktioniert:

Ping zwischen HostundVM
Ping zwischen NSundNS
dhclient von NS

Was funktioniert nicht:

Ping zwischen NSundVM
Ping zwischen NSundHost

Wo ich anfing verrückt zu werden:

tcpdump on host(die reale Maschine) zeigt tatsächlich ARP-Anfrage UND Antworten an
tcpdump on NSzeigt ARP-Anforderungen an, die an den Host gesendet wurden
Mit tcpdump on VMfunktioniert das ganze Durcheinander (!) -> ping erhält Antworten, wenn tcpdump auf der VM gestartet wird?!?

Ich wette, Sie waren gespannt darauf. Meine Frage lautet: Wie kann ich dafür sorgen, dass es funktioniert? Ich vermute, dass etwas mit ARP auf dem Macvlan in der NS nicht stimmt, kann aber nicht herausfinden, was genau ...

Übrigens habe ich die gleichen Experimente mit der mac0Schnittstelle direkt auf der VM durchgeführt (kein Namespace) und es hat einwandfrei funktioniert.

— Yadutaf
quelle

Ich verstehe nicht, warum diese Frage als nicht zum Thema gehörend gekennzeichnet wurde. Es handelt sich definitiv um eine Sysadmin / Netadmin-Frage, die für mehrere Virtualisierungsumgebungen relevant ist, und es handelt sich nicht um eine triviale Frage (oder, falls dies der Fall ist, sind 90% der Fragen zu StackOverflow ebenfalls nicht zum Thema gehörend). Ich würde es lieben, wenn die Leute, die es als "Off-Topic" gekennzeichnet haben, sich die Mühe machen würden, zu erklären, warum, anstatt eine Regel zu kopieren, die hier offensichtlich nicht gilt. Vielen Dank!

— Jpetazzo

@jpetazzo Dies ist kein Off-Topic, und ich kann nur davon ausgehen, dass die schließenden Personen dies aufgrund der schlechten Organisation / Präsentation der Frage getan haben (wahrscheinlich, weil das OP kein sys / net-Administrator ist). Außerdem unterscheidet sich der Bereich von Server Fault (nicht nur das Thema) vom Stapelüberlauf. Ihr Argument lässt mich glauben, dass Sie unser Hilfezentrum nicht besucht haben , da dies keinen Sinn ergibt .

— Chris S

OK, für die Nachwelt hätte mich die Tatsache, dass tcpdump plötzlich funktioniert, auf den richtigen Weg bringen sollen. Intern wird eth0in den Promiscuous-Modus gewechselt. Das heißt, es eth0wird der gesamte Netzwerkverkehr ausgegeben, nicht nur der mit dem Hauptverkehr des ServersMAC

Genau so macvlanfunktioniert es jedoch: Es wird eine neue sekundäre virtuelle MAC-Adresse hinzugefügt, die der "physische" (das ist eine VM) Netzwerkadapter nicht kennt.

Die einfache Problemumgehung besteht also darin, manuell: ifconfig eth0 promisc

Ich hoffe, es hilft !

— Yadutaf
quelle

Sie mussten also auch auf dieser VM das Kontrollkästchen "Kein Promisc-Modus" deaktivieren, nehme ich an?

— Nils

In der Tat ist es nicht markiert.

— Yadutaf