Ich habe eine virtuelle QEMU/KVM-Maschine eingerichtet und wollte dafür Bridge-Networking verwenden. In jedem Handbuch/Tutorial, das ich gelesen habe, steht, dass DHCP auf der physischen Netzwerkkarte deaktiviert und auf der Bridge aktiviert werden soll. Was ich nicht verstehe, ist, wenn die Bridge sich genauso verhält wie eine physische Bridge/ein physischer Switch, warum muss ihr dann eine IP-Adresse zugewiesen werden, während die eigentliche physische Netzwerkkarte keine hat? Diese Frage wurde bereits ein paar Mal gestellt, aber ich habe immer noch keine Antwort gefunden, z. B.HierIn der Antwort hieß es, dass die VMs auf diese Weise mit der Bridge kommunizieren können. Aber warum müssen sie das? Bei tatsächlichen physischen Maschinen arbeitet eine Bridge transparent und leitet nur den Datenverkehr weiter. Meine Fragen sind also:
- Warum benötigt eine virtuelle Brücke eine IP-Adresse, eine physische jedoch nicht?
- Woher weiß die physische Netzwerkkarte, dass sie die IP-Adresse der virtuellen Brücke verwenden soll, wenn die Netzwerkkarte keine hat?
- Warum müssen VMs mit der Brücke kommunizieren, während physische Maschinen nicht direkt mit einer physischen Brücke kommunizieren?
Hier sind einige Abbildungen, um besser zu zeigen, was ich meine:
- So stelle ich mir die Funktionsweise eines physischen Netzwerks mit einem Netzwerk-Switch vor:
- Wie ich mir vorstelle, dass eine virtuelle Brücke funktionieren sollte
- So wie ich es verstehe, funktioniert es tatsächlich
Antwort1
- Warum benötigt eine virtuelle Brücke eine IP-Adresse, eine physische jedoch nicht?
Es ist ein Irrglaube, dass eine virtuelle Brücke eine IP-Adresse benötigt. Das ist nicht der Fall.
Du eigentlichdürfeneine virtuelle Brücke ohne IP-Adresse haben. Dann ist der Host selbst über diese physische Schnittstelle allerdings überhaupt nicht über IP erreichbar: nur die VMs.
Bei einem Enterprise-Virtualisierungshost kann dies nützlich sein: Sie haben möglicherweise ein Kundennetzwerk, das mit den VMs der Kunden verbunden werden muss. Sie möchten möglicherweise dem Virtualisierungshost selbst keinen Zugriff von einem solchen Netzwerk aus gewähren, abernurzu den jeweiligen VMs. Dann hätten Sie ein weiteres, physisch getrenntes Verwaltungsnetzwerk, das Sie zur Verwaltung Ihrer Virtualisierungshosts verwenden würden. Dieses Netzwerk wäre über eine separate Netzwerkkarte mit dem Host verbunden, dienichtSeien Sie Mitglied einer virtuellen Brücke.
- Woher weiß die physische Netzwerkkarte, dass sie die IP-Adresse der virtuellen Brücke verwenden soll, wenn die Netzwerkkarte keine hat?
Sofern die physische Netzwerkkarte nicht über spezielle IPv4-Beschleunigungsfunktionen verfügt, ist eine IP-Adresse nur Nutzdaten für die Netzwerkkarte. Eine einfache physische Netzwerkkarte funktioniert nur mit Layer 2, also mit MAC-Adressen. Das IP-Protokoll ist Layer 3 und wird normalerweise dem Netzwerktreiberstapel des Betriebssystems überlassen. Wenn Sie mit ifconfigoder „eine IP-Adresse für eine Netzwerkkarte konfigurieren“ ip addr, nehmen Sie nicht unbedingt Änderungen an der tatsächlichen physischen Hardwarekonfiguration vor, sondern an einem abstrakten Konstrukt, das sowohl die physische Netzwerkkarte als auch die mit der Netzwerkkarte verbundene IP-Protokollunterstützung auf Betriebssystemebene umfasst.
Wenn eine physische Netzwerkkarte als Mitglied einer Brücke konfiguriert ist, müssen alle Layer-3-Beschleunigungsfunktionen möglicherweise trotzdem ausgeschaltet werden: Wenn sie als Teil einer Brücke fungiert, muss die Netzwerkkarte alle eingehenden Pakete empfangen, unabhängig von der Ziel-MAC- oder -IP-Adresse, und der Brückencode entscheidet, ob das Paket weitergeleitet wird und an welches Mitglied der Brücke. Eine einfache Brücke darf sich überhaupt nicht um IP-Adressen kümmern. Jede Layer-3-Funktionalität in einer Brücke geht über die grundlegende Brückenfunktionalität hinaus und ist/sollte in einer virtuellen Brücke optional sein.
Wenn die physische Netzwerkkarte als Teil einer Bridge mit einer IP-Adresse konfiguriert ist, aktiviert sie die ARP-Funktionalität auf dieser Netzwerkkarte (+ ihrem Treiber). Ausgehende ARP-Nachrichten von dieser physischen Netzwerkkarte können die VMs jedoch nicht erreichen: Um das gesamte Segment mit seinen ARPs zu erreichen (wie es die richtige Layer-2-Funktionalität erfordert), müsste der Netzwerkkartentreiber die ARP-Nachricht gleichzeitig als ausgehende und eingehende Nachricht generieren, und der Netzwerkkartentreiber verfügt nicht über den Code dafür.
Eine virtuelle Brücke mit VMs bedeutet, dass sich einige Teile des IP-Segments der Brücke physisch außerhalb des Hosts befinden, während andere in den VMs innerhalb des Hosts enthalten sind. Würde der Host die Netzwerkkarte wie üblich verwenden, um mit einer der VMs zu kommunizieren, würden die Pakete unnötigerweise aus dem Host an den physischen Switch oder Router gesendet, mit dem der Host verbunden ist, und von dort müssten sie zum Host und über die Brücke zur Ziel-VM zurückkehren.
Dies wäre sicherlich ineffizient und würde möglicherweise überhaupt nicht funktionieren: Der physische Switch, mit dem der Host mit der virtuellen Brücke verbunden ist, hätte normalerweise keinen Grund, Pakete, die von diesem Host stammen, an den Host selbst zurückzusenden.
Stattdessen müssen die ausgehenden Pakete vom Host zum überbrückten Netzwerksegment durch den Bridge-Code geschickt werden, der zunächst nachsieht, welche Schnittstelle der Bridge (virtuell oder physisch) dem Ziel „am nächsten“ ist. Wenn das Ziel der Bridge bekannt ist, wird das ausgehende Paket direkt dorthin gesendet. Für die Kommunikation zwischen dem Host und seinen VMs bedeutet dies, dass die Kommunikation vollständig innerhalb des physischen Hosts stattfindet und die physische Netzwerkbandbreite außerhalb des Hosts überhaupt nicht nutzt.
Wenn der Bridge die Ziel-MAC-Adresse nicht bekannt ist, werden die ausgehenden Pakete zunächst über alle Schnittstellen der Bridge-Mitglieder gesendet: Sobald eine Antwort eingeht, erfährt die Bridge den Standort des Ziels des ursprünglichen Pakets und kann zur effizienteren Betriebsmethode (wie oben) zurückkehren.
Wenn ARP-Anfragen vom Host gestellt werden, der die Brücke enthält, müssen die Anfragen sowohl an die VMs gesendet werdenUnddie physische Netzwerkkarte aus, damit die Anfragen tatsächlich an dieganzNetzwerksegment: Der Bridge-Code kann das, die einzelne physische Netzwerkkarte nicht.
Ich denke, es gibt keine Anforderung, dass eine Linux-Brücke ausschließlich physisch oder virtuell sein muss: Ich sehe keinen Grund, warum eine Linux-Brücke nicht mehrere physische Schnittstellen haben könnteUndeine beliebige Anzahl von VMs, die damit verbunden sind. Aber in einer Unternehmensumgebung möchten Sie im Allgemeinen keinen Host wie diesen erstellen, der alles kann. Er könnte leicht zu einem heiklen, kritischen Teil der Infrastruktur werden, der niemals ausfallen darf; mit anderen Worten, ein Ärgernis für die Systemadministratoren.
- Warum müssen VMs mit der Brücke kommunizieren, während physische Maschinen nicht direkt mit einer physischen Brücke kommunizieren?
Wieder das Missverständnis: Die VMsnichtbenötigen eine IP-Adresse auf der Brücke, um „mit der Brücke zu kommunizieren“ als solche.
Aber wenn duwollenDamit der Host und die VMs im selben IP-Netzwerksegment miteinander kommunizieren können, erfolgt dies durch Zuweisen einer IP-Adresse zum Bridge-Gerät.
Die IP-Adresse des Bridge-Geräts dient in erster Linie den Kommunikationsanforderungen desGastgeber, nicht von derVMs- aber es kann dem Host ermöglichen, effizient über IP mit den VMs zu kommunizieren, ohne externe Geräte zu durchlaufen, wenn Sie das möchten.