Warum MAC- und IP-Adressen auf der Bridge-Schnittstelle zugewiesen werden

Warum MAC- und IP-Adressen auf der Bridge-Schnittstelle zugewiesen werden

Angenommen, ich erstelle eine Bridge-Schnittstelle unter Linux ( br0) und füge ihr einige Schnittstellen hinzu ( eth0, tap0, usw.). Nach meinem Verständnis verhält sich diese Schnittstelle mit allen Schnittstellen/Ports, die ich hinzufüge, wie ein virtueller Switch.

Was bedeutet es, dieser Schnittstelle eine MAC- und eine IP-Adresse zuzuweisen? Fungiert die Schnittstelle als zusätzlicher Port auf dem Switch/der Bridge, der anderen Ports den Zugriff auf den Hostcomputer ermöglicht?

Ich habe auf einigen Seiten gelesen, dass einer Bridge eine IP-Adresse zugewiesen werden soll. Ist die MAC-Zuweisung implizit (oder automatisch)?

Antwort1

Da eine Bridge ein Ethernet-Gerät ist, benötigt sie eine MAC-Adresse. Eine Linux-Bridge kann Dinge wie Spanning-Tree-Protokoll-Frames erstellen, und für diesen Datenverkehr ist eine Ursprungs-MAC-Adresse erforderlich.

Eine Brückeerforderneine IP-Adresse. Es gibt viele Situationen, in denen Sie keine haben. In vielen Fällen jedochMaihaben Sie eines, wie zum Beispiel:

  • Wenn die Bridge als Standard-Gateway für eine Gruppe von Containern oder virtuellen Maschinen (oder sogar physischen Schnittstellen) fungiert. In diesem Fall benötigt sie eine IP-Adresse (da das Routing auf der IP-Ebene erfolgt).

  • Wenn Ihre „primäre“ Netzwerkkarte Mitglied der Brücke ist, sodass die Brücke Ihre Verbindung zur Außenwelt darstellt. In diesem Fall eth0würden Sie eine IP-Adresse nicht (zum Beispiel) zuweisen, sondern stattdessen dem Brückengerät.

Wenn die Brückenichtfür IP-Routing erforderlich ist, dann wird keine IP-Adresse benötigt. Beispiele für diese Situation sind:

  • Wenn die Bridge verwendet wird, um ein privates Gerätenetzwerk ohne externe Konnektivität oder mit externer Konnektivität zu erstellen, die über ein anderes Gerät als die Bridge bereitgestellt wird.

Antwort2

Das mit Ihren anderen Netzwerkgeräten aufgelistete Bridge-Gerät stellt nicht die virtuelle Bridge dar, sondern eine virtuelle Netzwerkkarte, die mit der Bridge verbunden ist. Wenn Sie eine physische Bridge mit physischen Netzwerkgeräten verbunden hätten, würden Sie die physische Bridge auch nicht in Ihren Netzwerkgeräten aufgelistet sehen – aber Sie würden Ihre Netzwerkkarte sehen, die mit der Bridge verbunden ist und die natürlich wie jedes andere Netzwerkgerät eine eigene MAC-Adresse hat.

Durch die Zuweisung einer IP-Adresse zum Bridge-Gerät (bei dem es sich wiederum um eine virtuelle Netzwerkkarte handelt, die mit der virtuellen Bridge verbunden ist) kann Ihr Host-Gerät Pakete an das von der Bridge erstellte Subnetz und alle daran angeschlossenen Geräte weiterleiten. Klasse!

Während Netzwerkgerätetools wie iproute2(mit den Befehlen ip linkund ip addr) Ihnen ermöglichen, die an die Bridge angeschlossene virtuelle Netzwerkkarte anzuzeigen, ist es mit dem brctlProgramm auch möglich, die virtuelle Bridge selbst anzuzeigen. Der brctl showBefehl listet alle Bridges und ihre angeschlossenen Schnittstellen auf. Hier ist ein Beispiel mit iprouteund brctlmit Linux-Bridges und Tuntaps:

# ip link add br0 type bridge
# ip tuntap add dev tap0 mode tap
# ip tuntap add dev tap1 mode tap
# ip addr add 10.0.0.1/24 broadcast 10.0.0.255 dev br0
# ip addr add 10.0.0.2/24 broadcast 10.0.0.255 dev tap0
# ip addr add 10.0.0.3/24 broadcast 10.0.0.255 dev tap1
# brctl addif br0 tap0
# brctl addif br0 tap1
# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.2e22e593fe8c       no              tap0
                                                        tap1
# ip addr show to 10.0.0.0/24
11: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    inet 10.0.0.1/24 brd 10.0.0.255 scope global br0
       valid_lft forever preferred_lft forever
12: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    inet 10.0.0.2/24 brd 10.0.0.255 scope global tap0
       valid_lft forever preferred_lft forever
13: tap1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    inet 10.0.0.3/24 brd 10.0.0.255 scope global tap1
       valid_lft forever preferred_lft forever

Beachten Sie, dass in der Ausgabe von unter "Schnittstellen" brctl showfolgendeandereSchnittstellen, die an die Bridge angeschlossen sind, zusätzlich zu der br0Schnittstelle, die automatisch hinzugefügt wurde, als die Bridge erstellt wurde. (Ich vermute, Linux erlaubt nicht die Erstellung einer virtuellen Bridge ohne angeschlossene Geräte, und Bridges ohne Geräte werden automatisch zerstört.) Der Vollständigkeit halber sei erwähnt, dass ich dies im Kernel nicht recherchiert habe und auch kein Netzwerkexperte bin. Ich habe dies gepostet, weil es die ziemlich verwirrende Implementierung virtueller Bridges in Linux überzeugend zu erklären scheint. Ich glaube nicht, dass die virtuellen Bridges selbst überhaupt MAC-Adressen haben.

Antwort3

Ja, die Bridge-Schnittstelle fungiert als zusätzlicher Port.

Nach man 5 systemd.netdev:

Ein Bridge-Gerät ist ein Software-Switch und jedes seiner Slave-Geräte und die Bridge selbst sind Ports des Switches.

Antwort4

Die von br0und virbr0aufgelisteten Schnittstellen sind Tap-Schnittstellen ip addr, ip linkdie den Host mit der br0Bridge bzw. virbr0Bridge verbinden. Diese Überladung mit Namen kann durchaus verwirrend sein.

Also was ist virbr0-nic?

Dies war nicht Teil der ursprünglichen Frage, aber ich gebe hier meinen Senf dazu, da mich das in der Vergangenheit verwirrt hat. virbr0-nicist eine Dummy-Schnittstelle, deren MAC-Adresse von der Bridge als ihre eigene MAC-Adresse verwendet wird virbr0. Diese immer vorhandene Schnittstelle soll verhindern, virbr0dass sich die MAC-Adresse ändert, wenn Ports dynamisch zur Bridge hinzugefügt oder von ihr entfernt werden. Der Host sendet keinen Datenverkehr über die virbr0-nicSchnittstelle.

Sehenhttps://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-portsUndhttps://www.redhat.com/archives/libvirt-users/2012-September/msg00038.htmlfür eine Erklärung.

verwandte Informationen