Erweiterte MC-LAG-Konzepte

Vorteile der Konfigurationssynchronisierung

Die Konfigurationssynchronisierung ermöglicht es Ihnen, Konfigurationen von einem Gerät auf ein anderes zu übertragen, zu synchronisieren und zu bestätigen. Sie können sich bei jedem dieser Geräte anmelden, um alle Geräte zu verwalten, und haben so einen zentralen Verwaltungspunkt.

Funktionsweise der Konfigurationssynchronisierung

Verwenden Sie Konfigurationsgruppen, um den Konfigurationsprozess zu vereinfachen. Sie können z. B. eine Konfigurationsgruppe für das lokale Gerät, eine oder mehrere für die Remotegeräte und eine für die globale Konfiguration erstellen, bei der es sich im Wesentlichen um eine Konfiguration handelt, die für alle Geräte gilt.

Darüber hinaus können Sie bedingte Gruppen erstellen, um anzugeben, wann eine Konfiguration mit einem anderen Gerät synchronisiert wird. Sie können die Anweisung peers-synchronize in der Hierarchie [edit system commit] aktivieren, um die Konfigurationen und Commits standardmäßig geräteübergreifend zu synchronisieren. NETCONF über SSH bietet eine sichere Verbindung zwischen den Geräten, und das Secure Copy Protocol (SCP) kopiert die Konfigurationen sicher zwischen ihnen.

Aktivieren der Konfigurationssynchronisierung

Führen Sie die folgenden Schritte aus, um die Konfigurationssynchronisierung zu aktivieren:

1. Ordnen Sie das lokale Gerät statisch den Remotegeräten zu.

2. Erstellen Sie Konfigurationsgruppen für lokale, Remote- und globale Konfigurationen.

3. Erstellen Sie bedingte Gruppen.

4. Erstellen Sie Anwendungsgruppen.

5. Aktivieren Sie NETCONF über SSH.

6. Konfigurieren Sie die Gerätedetails und Benutzerauthentifizierungsdetails für die Konfigurationssynchronisierung.

7. Aktivieren Sie die Anweisung peers-synchronize oder geben Sie den commit peers-synchronize Befehl aus, um die Konfigurationen zwischen lokalen und Remote-Geräten zu synchronisieren und zu bestätigen.

Unterstützung der Konfigurationssynchronisierung

Auf Routern der MX-Serie und Junos Fusion begann die Unterstützung für die Konfigurationssynchronisierung mit Junos OS Version 14.2R6. Auf Switches der QFX-Serie begann die Unterstützung für die Konfigurationssynchronisierung mit Junos OS Version 15.1X53-D60.

Konfigurationsgruppen für lokale, Remote- und globale Konfigurationen

Sie können Konfigurationsgruppen für lokale, Remote- und globale Konfigurationen erstellen. Eine lokale Konfigurationsgruppe wird vom lokalen Gerät verwendet, eine Remotekonfigurationsgruppe wird vom Remotegerät verwendet, und eine globale Konfigurationsgruppe wird vom lokalen und dem Remotegerät gemeinsam genutzt.

Sie können z. B. eine lokale Konfigurationsgruppe mit dem Namen Gruppe A erstellen, die die vom lokalen Gerät verwendete Konfiguration (Switch A) enthält, eine Remotekonfigurationsgruppe mit dem Namen Gruppe B, die die Konfiguration enthält, die von Remotegeräten verwendet wird (Switch B, Switch C und Switch D), und eine globale Konfigurationsgruppe mit dem Namen Gruppe C, die die Konfiguration enthält, die allen Geräten gemeinsam ist.

Erstellen Sie Konfigurationsgruppen auf Hierarchieebene [edit groups] .

Erstellen bedingter Gruppen für bestimmte Geräte

Sie können bedingte Gruppen erstellen, um anzugeben, wann eine bestimmte Konfiguration auf ein Gerät angewendet werden soll. Wenn Sie die globale Konfiguration z. B. auf alle Geräte in einer Konfiguration mit vier Geräten anwenden möchten, aktivieren Sie die when peers [<name of local peer> <name of remote peer> <name of remote peer> <name of remote peer>] Anweisung auf Hierarchieebene [edit groups] . Wenn Sie z. B. die globale Konfiguration (Gruppe C) auf die lokalen und Remote-Geräte (Switch A, Switch B, Switch C und Switch D) anwenden möchten, können Sie den set groups Group C when peers [Switch A Switch B Switch C Switch D] Befehl ausgeben.

Anwenden von Konfigurationsgruppen

Um Konfigurationsgruppen anzuwenden, aktivieren Sie die apply-groups Anweisung auf Hierarchieebene [edit] . Wenn Sie z. B. die lokale Konfigurationsgruppe (z. B. Gruppe A), die Remotekonfigurationsgruppe (z. B. Gruppe B) und die globale Konfigurationsgruppe (z. B. Gruppe C) anwenden möchten, geben Sie den Befehl set apply-groups [ GroupA GroupB GroupC ] aus.

Gerätekonfigurationsdetails für die Konfigurationssynchronisierung

Um Konfigurationen zwischen Geräten zu synchronisieren, müssen Sie den Hostnamen oder die IP-Adresse, den Benutzernamen und das Kennwort für die Remote-Geräte konfigurieren. Geben Sie dazu den set peers <hostname-of-remote-peer> user <name-of-user> authentication <plain-text-password-string> Befehl in der [edit system commit] Hierarchie auf dem lokalen Gerät aus.

Um beispielsweise eine Konfiguration von Switch A zu Switch B zu synchronisieren, geben Sie den set peers SwitchB user administrator authentication test123 Befehl auf Switch A aus.

Außerdem müssen Sie das lokale Gerät den Remotegeräten statisch zuordnen. Geben Sie dazu die set system commit peers

Um beispielsweise eine Konfiguration von Switch A zu Switch B, Switch C und Switch D zu synchronisieren, konfigurieren Sie Folgendes auf Switch A:

Schalter A

Wenn Sie nur Konfigurationen von Switch A zu Switch B, Switch C und Switch D synchronisieren möchten, müssen Sie die peers Anweisung für Switch B, Switch C und Switch D nicht konfigurieren.

Die Konfigurationsdetails aus den Peers-Anweisungen werden auch verwendet, um eine NETCONF-over-SSH-Verbindung zwischen den Geräten herzustellen. Um NETCONF über SSH zu aktivieren, geben Sie den set system services netconf ssh Befehl auf allen Geräten aus.

Synchronisierung von Konfigurationen und Commits zwischen Geräten

Das lokale (oder anfordernde) Gerät, auf dem Sie die Anweisung peers-synchronize aktivieren oder den commit peers-synchronize Befehl ausgeben, kopiert seine Konfiguration und lädt sie auf das entfernte (oder antwortende) Gerät. Jedes Gerät führt dann eine Syntaxprüfung für die Konfigurationsdatei durch, für die ein Commit ausgeführt wird. Wenn keine Fehler gefunden werden, wird die Konfiguration aktiviert und wird zur aktuellen Betriebskonfiguration auf allen Geräten. Die Commits werden über einen Remote Procedural Call (RPC) weitergegeben.

Die folgenden Ereignisse treten während der Konfigurationssynchronisierung auf:

1. Das lokale Gerät sendet die Datei sync-peers.conf (die Konfiguration, die für die in der Bedingungsgruppe angegebenen Geräte freigegeben wird) an die Remotegeräte.

2. Die Remote-Geräte laden die Konfiguration, senden die Ergebnisse des Ladevorgangs an das lokale Gerät, exportieren ihre Konfiguration auf das lokale Gerät und antworten, dass der Commit abgeschlossen ist.

3. Das lokale Gerät liest die Antworten von den Remote-Geräten.

4. Bei Erfolg wird die Konfiguration bestätigt.

Die Konfigurationssynchronisierung ist nicht erfolgreich, wenn entweder a) das Remotegerät nicht verfügbar ist oder b) das Remotegerät erreichbar ist, es jedoch aus den folgenden Gründen zu Fehlern kommt:

• Die SSH-Verbindung schlägt aufgrund von Benutzer- und Authentifizierungsproblemen fehl.

• Junos OS RPC schlägt fehl, da keine Sperre für die entfernte Datenbank abgerufen werden kann.

• Das Laden der Konfiguration schlägt aufgrund von Syntaxproblemen fehl.

• Die Commit-Prüfung schlägt fehl.

Die peers-synchronize Anweisung verwendet den Hostnamen oder die IP-Adresse, den Benutzernamen und das Kennwort für die Geräte, die Sie in der peers Anweisung konfiguriert haben. Wenn die peers-synchronize Anweisung aktiviert ist, können Sie einfach den commit Befehl zum Synchronisieren der Konfiguration von einem Gerät zum anderen ausgeben. Wenn Sie die peers Anweisung z. B. auf dem lokalen Gerät konfiguriert haben und die Konfiguration mit dem Remotegerät synchronisieren möchten, können Sie den commit Befehl einfach auf dem lokalen Gerät ausgeben. Wenn Sie den commit Befehl jedoch auf dem lokalen Gerät ausführen und das Remote-Gerät nicht erreichbar ist, erhalten Sie eine Warnmeldung, die besagt, dass das Remote-Gerät nicht erreichbar ist und nur die Konfiguration auf dem lokalen Gerät festgeschrieben wird:

Hier ist ein Beispiel für eine Warnmeldung:

Wenn Sie die peers Anweisung nicht mit den Remote-Geräteinformationen konfiguriert haben und den commit Befehl ausgeben, wird nur die Konfiguration auf dem lokalen Gerät bestätigt. Wenn das Remotegerät nicht erreichbar ist und andere Fehler auftreten, ist der Commit sowohl auf dem lokalen als auch auf dem Remotegerät nicht erfolgreich.

Der commit peers-synchronize Befehl verwendet auch den Hostnamen oder die IP-Adresse, den Benutzernamen und das Kennwort für die in der Anweisung konfigurierten peers Geräte. Wenn Sie den commit peers-synchronize Befehl auf dem lokalen Gerät ausgeben, um die Konfiguration mit dem Remotegerät zu synchronisieren, und das Remotegerät erreichbar ist, aber andere Fehler auftreten, schlägt der Commit sowohl auf dem lokalen als auch auf dem Remotegerät fehl.

Vorteile der Verwendung der MC-LAG-Konsistenzprüfung

• Diese Funktion hilft Ihnen, Inkonsistenzen bei Konfigurationsparametern zwischen MC-LAG-Peers (Multichassis Link Aggregation Group) zu finden.

Funktionsweise von MC-LAG-Konsistenzprüfungen

Die folgenden Ereignisse finden während der Konfigurationskonsistenzprüfung statt, nachdem Sie einen Commit auf dem lokalen MC-LAG-Peer ausgestellt haben:

1. Führen Sie einen Commit für eine MC-LAG-Konfiguration auf dem lokalen MC-LAG-Peer durch.

2. ICCP analysiert die MC-LAG-Konfiguration und sendet sie dann an den Remote-MC-LAG-Peer.

3. Der Remote-MC-LAG-Peer empfängt die MC-LAG-Konfiguration vom lokalen MC-LAG-Peer und vergleicht sie mit seiner eigenen MC-LAG-Konfiguration.

   Wenn es eine schwerwiegende Inkonsistenz zwischen den beiden MC-LAG-Konfigurationen gibt, wird die MC-LAG-Schnittstelle heruntergefahren und Syslog-Meldungen ausgegeben.

   Wenn eine moderate Inkonsistenz zwischen den beiden Konfigurationen besteht, werden Syslog-Meldungen ausgegeben.

Die folgenden Ereignisse finden während der Konfigurationskonsistenzprüfung statt, nachdem Sie einen Commit auf dem Remote-MC-LAG-Peer ausgestellt haben:

• Führen Sie einen Commit für eine MC-LAG-Konfiguration auf dem Remote-MC-LAG-Peer durch.

• ICCP analysiert die MC-LAG-Konfiguration und sendet sie dann an den lokalen MC-LAG-Peer.

• Der lokale MC-LAG-Peer empfängt die Konfiguration vom Remote-MC-LAG-Peer und vergleicht sie mit seiner eigenen Konfiguration.

  Wenn es eine schwerwiegende Inkonsistenz zwischen den beiden Konfigurationen gibt, wird die MC-LAG-Schnittstelle heruntergefahren und Syslog-Meldungen ausgegeben.

  Wenn eine moderate Inkonsistenz zwischen den beiden Konfigurationen besteht, werden Syslog-Meldungen ausgegeben.

Anforderungen an die Konfigurationskonsistenz

Abhängig von den MC-LAG-Parametern gibt es unterschiedliche Anforderungen an die Konfigurationskonsistenz. Die Konsistenzanforderungen sind entweder identisch oder eindeutig, was bedeutet, dass einige Parameter identisch und einige eindeutig auf den MC-LAG-Peers konfiguriert werden müssen. Beispielsweise muss die Chassis-ID auf beiden Peers eindeutig sein, während der LACP-Modus auf beiden Peers identisch sein muss.

Die Durchsetzungsebene der Kohärenzanforderungen (identisch oder eindeutig) ist entweder obligatorisch oder erwünscht. Wenn die Erzwingungsstufe obligatorisch ist und Sie den MC-LAG-Parameter falsch konfigurieren, fährt das System die Schnittstelle herunter und gibt eine Syslog-Meldung aus.

Beispielsweise erhalten Sie eine Syslog-Meldung, die besagt: “Some of the Multichassis Link Aggregation (MC-LAG) configuration parameters between the peer devices are not consistent. The concerned MC-LAG interfaces were explictly brought down to prevent unwanted behavior.” Wenn Sie die Inkonsistenz korrigieren und einen erfolgreichen Commit ausgeben, ruft das System die Schnittstelle auf. Wenn die Erzwingung gewünscht ist und Sie den MC-LAG-Parameter falsch konfigurieren, erhalten Sie eine Syslog-Meldung, die besagt, "Some of the Multichassis Link Aggregation(MC-LAG) configuration parameters between the peer devices are not consistent. This may lead to sub-optimal performance of the feature." Wie in der Syslog-Meldung erwähnt, ist die Leistung in dieser Situation suboptimal. Sie können auch den Befehl show interfaces mc-ae ausführen, um den Status der Konfigurationskonsistenzprüfung der aggregierten Multichassis-Ethernet-Schnittstelle anzuzeigen.

Wenn es mehrere Inkonsistenzen gibt, wird nur die erste Inkonsistenz angezeigt. Wenn die Erzwingungsstufe für einen MC-LAG-Parameter obligatorisch ist und Sie diesen Parameter nicht ordnungsgemäß konfiguriert haben, zeigt der Befehl an, dass die MC-LAG-Schnittstelle ausgefallen ist.

Wenn Remote-Peers nicht erreichbar sind

Wenn Sie einen Commit für den lokalen Peer ausgeben und der Remotepeer nicht erreichbar ist, wird die Konfigurationskonsistenzprüfung bestanden, sodass der lokale Peer im Standalone-Modus gestartet werden kann. Wenn der Remote-Peer aktiviert wird, tauscht ICCP die Konfigurationen zwischen den Peers aus. Wenn die Konsistenzprüfung fehlschlägt, fällt die MC-LAG-Schnittstelle aus, und das System benachrichtigt Sie über den Parameter, der die Inkonsistenz verursacht hat. Wenn Sie die Inkonsistenz korrigieren und einen erfolgreichen Commit ausführen, ruft das System die Schnittstelle auf.

Aktivieren der Konsistenzprüfung der MC-LAG-Konfiguration

Die Konsistenzprüfung ist standardmäßig aktiviert. Tabelle 1 enthält eine Beispielliste der zugesicherten MC-LAG-Parameter, die auf Konsistenz überprüft werden, zusammen mit ihren Konsistenzanforderungen (identisch oder eindeutig), den Hierarchien, in denen die Parameter konfiguriert werden, und den Durchsetzungsebenen der Konsistenzprüfung (obligatorisch oder gewünscht).

Informationen zum Status einer Konfigurationskonsistenzprüfung

Die folgenden Befehle geben Auskunft über den Status der Konfigurationskonsistenzprüfung:

• Geben Sie den Befehl show multi-chassis mc-lag configuration-consistency list-of-parameters ein, um die Liste der zugesicherten MC-LAG-Parameter anzuzeigen, die auf Inkonsistenzen, die Konsistenzanforderung (identisch oder eindeutig) und die Erzwingungsstufe (obligatorisch oder gewünscht) überprüft werden.

• Geben Sie den Befehl show multi-chassis mc-lag configuration-consistency ein, um die Liste der zugesagten MC-LAG-Parameter anzuzeigen, die auf Inkonsistenzen, die Konsistenzanforderung (identisch oder eindeutig), die Erzwingungsstufe (obligatorisch oder gewünscht) und das Ergebnis der Konfigurationskonsistenzprüfung überprüft werden. Das Ergebnis ist entweder erfolgreich oder nicht bestanden.

• Geben Sie den Befehl show multi-chassis mc-lag configuration-consistency global-config ein, um den Status der Konfigurationskonsistenzprüfung für alle globalen Konfigurationen im Zusammenhang mit der MC-LAG-Funktionalität, die Konsistenzanforderung (identisch oder eindeutig), die Erzwingungsstufe (obligatorisch oder gewünscht) und das Ergebnis der Konfigurationskonsistenzprüfung anzuzeigen. Das Ergebnis ist entweder bestanden oder nicht bestanden.

• Setzen Sie den Befehl show multi-chassis mc-lag configuration-consistency icl-config ein, um den Status der Konfigurationskonsistenzprüfung für Parameter anzuzeigen, die sich auf die Steuerverbindung zwischen den Chassis, die Konsistenzanforderung (identisch oder eindeutig), die Erzwingungsebene (obligatorisch oder gewünscht) und das Ergebnis der Konfigurationskonsistenzprüfung beziehen. Das Ergebnis ist entweder erfolgreich oder nicht bestanden.

• Geben Sie den Befehl show multi-chassis mc-lag configuration-consistency mcae-config ein, um den Status der Konfigurationskonsistenzprüfung für Parameter im Zusammenhang mit der aggregierten Ethernet-Schnittstelle für Multichassis, die Konsistenzanforderung (identisch oder eindeutig), die Erzwingungsstufe (obligatorisch oder gewünscht) und das Ergebnis der Konfigurationskonsistenzprüfung anzuzeigen. Das Ergebnis ist entweder erfolgreich oder nicht bestanden.

• Führen Sie den Befehl show multi-chassis mc-lag configuration-consistency vlan-config ein, um den Status der Konfigurationskonsistenzprüfung für Parameter im Zusammenhang mit der VLAN-Konfiguration, die Konsistenzanforderung (identisch oder eindeutig), die Durchsetzungsstufe (obligatorisch oder gewünscht) und das Ergebnis der Konfigurationskonsistenzprüfung anzuzeigen. Das Ergebnis ist entweder bestanden oder nicht bestanden.

• Geben Sie den Befehl show multi-chassis mc-lag configuration-consistency vrrp-config ein, um den Status der Konfigurationskonsistenzprüfung für Parameter im Zusammenhang mit der VRRP-Konfiguration, die Konsistenzanforderung (identisch oder eindeutig), die Erzwingungsstufe (obligatorisch oder gewünscht) und das Ergebnis der Konfigurationskonsistenzprüfung anzuzeigen. Das Ergebnis ist entweder erfolgreich oder nicht bestanden.

• Geben Sie den Befehl show interfaces mc-ae ein, um den Status der Konfigurationskonsistenzprüfung der aggregierten Multichassis-Ethernet-Schnittstelle anzuzeigen. Wenn es mehrere Inkonsistenzen gibt, wird nur die erste Inkonsistenz angezeigt. Wenn die Erzwingungsstufe für den MC-LAG-Parameter obligatorisch ist und Sie diesen Parameter nicht ordnungsgemäß konfiguriert haben, zeigt der Befehl an, dass die MC-LAG-Schnittstelle ausgefallen ist.

Unterstützung für die Konsistenzprüfung der MC-LAG-Konfiguration

Sowohl die Switches der EX-Serie als auch die Switches der QFX-Serie unterstützen die Konsistenzprüfung der MC-LAG-Konfiguration.

Beginnend mit Junos OS Version 15.1X53-D60 auf QFX10000-Switches verwendet die Konfigurationskonsistenzprüfung das Inter-Chassis Control Protocol (ICCP), um MC-LAG-Konfigurationsparameter (Chassis-ID, Service-ID usw.) auszutauschen und nach Konfigurationsinkonsistenzen zwischen MC-LAG-Peers zu suchen.

PIM-Betrieb mit Auswahl des normalen Modus für designierte Router

Im normalen Modus mit Auswahl des designierten Routers sind die IRB - oder RVI-Schnittstellen auf beiden MC-LAG-Peers mit aktiviertem PIM konfiguriert. In diesem Modus wird einer der MC-LAG-Peers über den Auswahlmechanismus des designierten PIM-Routers zum designierten Router. Der gewählte designierte Router verwaltet den Rendezvouspunktbaum (RPT) und den Kurzestpfadbaum (SPT), damit er Daten vom Quellgerät empfangen kann. Der gewählte designierte Router nimmt an regelmäßigen PIM-Join- und Prune-Aktivitäten in Richtung des Rendezvouspunkts oder der Quelle teil.

Der Auslöser für die Initiierung dieser Join- und Prune-Aktivitäten sind die IGMP-Mitgliedschaftsberichte, die von interessierten Empfängern empfangen werden. IGMP-Berichte, die über aggregierte Multichassis-Ethernet-Schnittstellen (möglicherweise Hashing auf einem der MC-LAG-Peers) und Single-Homed-Links empfangen werden, werden über ICCP mit dem MC-LAG-Peer synchronisiert.

Beide MC-LAG-Peers empfangen Datenverkehr über ihre eingehende Schnittstelle (IIF). Der nicht designierte Router empfängt Datenverkehr über die ICL-Schnittstelle, die als Multicast-Router-Schnittstelle (mrouter) fungiert.

Wenn der designierte Router ausfällt, muss der nicht designierte Router die gesamte Weiterleitungsstruktur (RPT und SPT) aufbauen, was zu Multicast-Datenverkehrsverlusten führen kann.

PIM-Betrieb mit Dual Designated Router-Modus

Im Dual-Designedating-Router-Modus fungieren beide MC-LAG-Peers als designierte Router (aktiv und Standby) und senden regelmäßig Join- und Prune-Nachrichten stromaufwärts in Richtung Rendezvouspunkt oder Quelle und treten schließlich dem RPT oder SPT bei.

Der primäre MC-LAG-Peer leitet den Multicast-Datenverkehr an die Empfängergeräte weiter, auch wenn der Standby-MC-LAG-Peer eine kleinere Präferenzmetrik aufweist.

Der MC-LAG-Standbypeer tritt ebenfalls der Weiterleitungsstruktur bei und empfängt die Multicastdaten. Der Standby-MC-LAG-Peer löscht die Daten, da er über eine leere ausgehende Schnittstellenliste (OIL) verfügt. Wenn der Standby-MC-LAG-Peer den Ausfall des primären MC-LAG-Peers erkennt, fügt er das Empfänger-VLAN zur OIL hinzu und beginnt mit der Weiterleitung des Multicast-Datenverkehrs.

Um einen designierten Multicast-Dual-Router zu aktivieren, geben Sie den set protocols pim interface interface-name dual-dr Befehl auf den VLAN-Schnittstellen jedes MC-LAG-Peers aus.

Fehlerbehandlung

Um eine schnellere Konvergenz bei Ausfällen zu gewährleisten, konfigurieren Sie die IP-Adresse auf dem primären MC-LAG-Peer mit einer höheren IP-Adresse oder mit einer höheren designierten Routerpriorität. Auf diese Weise wird sichergestellt, dass der primäre MC-LAG-Peer die vorgesehene Routermitgliedschaft beibehält, wenn das PIM-Peering ausfällt.

Um sicherzustellen, dass der Datenverkehr konvergiert, wenn eine MC-AE-Schnittstelle ausfällt, wird die ICL-PL-Schnittstelle immer als mrouter-Port hinzugefügt. Layer-3-Datenverkehr wird durch den Standardeintrag oder den Snooping-Eintrag über die ICL-PL-Schnittstelle geflutet, und der Datenverkehr wird über die MC-AE-Schnittstelle auf dem MC-LAG-Peer weitergeleitet. Wenn die ICL-PL-Schnittstelle ausfällt, fällt auch die PIM-Nachbarschaft aus. In diesem Fall werden beide MC-LAG-Peers zum designierten Router. Der Backup-MC-LAG-Peer stürzt seine Verbindungen, und das Routing-Peering geht verloren. Wenn die ICCP-Verbindung ausfällt, ändert der Backup-MC-LAG-Peer die LACP-System-ID und beendet die MC-AE-Schnittstellen. Der Status der PIM-Nachbarn bleibt betriebsbereit.

IGMP-Snooping im MC-LAG Aktiv-Aktiv-Modus

Multichassis Link Aggregation Group (MC-LAG) Aktiv-Aktiv-Modus und IGMP-Snooping im Aktiv-Standby-Modus werden unterstützt. Mit MC-LAG kann ein Gerät eine logische LAG-Schnittstelle mit zwei oder mehr Netzwerkgeräten bilden. MC-LAG bietet zusätzliche Vorteile wie Redundanz auf Knotenebene, Multihoming und ein schleifenfreies Layer-2-Netzwerk ohne das Spanning Tree Protocol (STP). Die folgenden Funktionen werden unterstützt:

• Zustandssynchronisierung zwischen Peers für IGMP-Snooping in einer Bridge-Domäne mit nur Layer-2-Schnittstellen

• Qualifiziertes Lernen

• Routerseitige Multichassis-Verbindungen

Die folgenden Verbesserungen für Aktiv-Aktiv-Bridging und Virtual Router Redundancy Protocol (VRRP) über integriertes Routing und Bridging (IRB) werden unterstützt:

• MC-LAG-Unterstützung für IGMP-Snooping in einem reinen Layer-2-Switch

• MC-LAG-Unterstützung für IGMP-Snooping in Bridge-Domänen qualifiziertes Lernen

• Unterstützung für MC-Links als Schnittstellen für Router

Folgende Funktionen werden not unterstützt:

• MC-LAG für VPLS-Instanzen

• MC-Links Trunk-Ports

• Proxy-Modus für Aktiv-Aktiv

• Hinzufügen von Interchassis-Links zu ausgehenden Schnittstellen nach Bedarf

  Interchassis-Verbindungen können der Liste der ausgehenden Schnittstellen als routerseitige Schnittstellen hinzugefügt werden.

Typischerweise unterstützte Netzwerktopologie für IGMP-Snooping mit MC-LAG Aktiv-Aktiv-Bridging

Abbildung 1 zeigt eine typische Netzwerktopologie, über die IGMP-Snooping mit MC-LAG Aktiv-Aktiv-Bridging unterstützt wird.

Abbildung 1: Typisches Netzwerk, in dem Aktiv/Aktiv-Modus unterstützt wird

Bei den Schnittstellen I3 und I4 handelt es sich um Single-Homed-Schnittstellen. Die Multichassis-Links ae0.0 und ae0.1 gehören in beiden Chassis zur gleichen Bridge-Domäne. Die Schnittstellen I3, ae0.0 und ae0.1 befinden sich in derselben Bridge-Domäne im sekundären aktiven Router (S-A). Die Schnittstellen I4, ae0.0 und ae0.1 befinden sich in derselben Bridge-Domäne im primären aktiven Router (P-A). Die Schnittstellen I3, I4, ae0.0 und ae0.1 befinden sich in derselben Lerndomäne wie der Interchassis-Link (ICL), der die beiden Chassis verbindet.

Der primäre aktive Router ist das Gehäuse, in dem integriertes Routing und Bridging zu PIM-DR geworden ist. Der sekundäre aktive Router ist das Gehäuse, in dem integriertes Routing und Bridging nicht PIM-DR entspricht. Router P-A ist das Chassis, das für das Abrufen des Datenverkehrs vom IP-Core verantwortlich ist. Daher wird die PIM-DR-Wahl verwendet, um Doppelarbeit im Datenverkehr zu vermeiden.

Die Lernbereiche werden unter Qualifiziertes Lernen beschrieben.

Für die IGMP-Lautsprecher (Hosts und Router) in der Lerndomäne sollten P-A und S-A zusammen als ein Gerät mit den Schnittstellen I4, I3, ae0.0 und ae0.1 angezeigt werden.

Auf Multichassis-Links sollten keine doppelten Steuerpakete gesendet werden, d. h. das Steuerpaket sollte nur über eine Verbindung gesendet werden.

Statusaktualisierungen der Steuerungsebene, die durch auf einem Remote-Chassis empfangene Pakete ausgelöst werden

Im Folgenden sind die Statusaktualisierungen der Steuerungsebene aufgeführt, die durch die auf dem Remote-Chassis empfangenen Pakete ausgelöst werden:

• Der Mitgliedschaftsstatus im Layer 3-Multicast-Routing wird als Ergebnis von Berichten aktualisiert, die über Remote-Legs von Multichassis-Verbindungen und S-Links gelernt wurden, die an das Remote-Chassis angeschlossen sind.

• Der Mitgliedschaftsstatus und der Routingeintrag beim Snooping werden aktualisiert, wenn Berichte über die Remote-Legs einer Multichassis-Verbindung empfangen werden.

Weiterleitung von Daten

In dieser Diskussion wird davon ausgegangen, dass integriertes Routing und Bridging auf Router P-A der PIM-DR ist. Er bezieht den Datenverkehr von den Quellen im Core. Der Datenverkehr kann auch über Layer-2-Schnittstellen in der Bridge-Domäne erfolgen. Für Hosts, die direkt mit dem P-A-Chassis verbunden sind, ändert sich nichts an der Art und Weise, wie Daten bereitgestellt werden.

Für die Übertragung von Datenverkehr an Hosts, die mit S-A (dem Nicht-DR) auf der Single-Homed-Verbindung wie I3 verbunden sind, verlassen wir uns auf die Interchassis-Verbindung. Der Datenverkehr, der P-A erreicht, wird über ICL an S-A gesendet, um an die Links weitergeleitet zu werden, die Interesse an s,g gemeldet haben, und an die Links, die auf den Router ausgerichtet sind.

Wenn der ae0-Zweig in P-A ausfällt, empfangen die Hosts, die mit der Multichassis-Verbindung verbunden sind, Datenverkehr über ICL. In S-A wird der über ICL empfangene Datenverkehr an Multichassis-Verbindungen in der ausgehenden Schnittstellenliste gesendet, für die das ae-Gegenstück in P-A ausgefallen ist.

Reine Layer-2-Topologie ohne integriertes Routing und Bridging

Abbildung 2 zeigt, dass das Gehäuse, das mit dem PIM-DR verbunden ist, der primäre aktive (P-A) Router und das andere der sekundäre aktive (S-A) Router ist.

Abbildung 2: Layer-2-Konfiguration ohne integriertes Routing und Bridging

Qualifiziertes Lernen

In dieser Topologie sind die Schnittstellen I1, I2, I3, I4, I5, I6, I7, I8, I9 und I10 Single-Homed-Schnittstellen. Die Multichassis-Links ae0.0 und ae0.1 gehören in beiden Chassis zur gleichen Bridge-Domäne. Die Schnittstellen I10, I1,I7,I3,I5, ae0.0 und ae0.1 befinden sich in der gleichen Bridge-Domäne, bd1 in P-A. Die Schnittstellen I9, I2, I8, I4, I6, ae0.0 und ae0.1 befinden sich in derselben Bridge-Domäne, bd1 in S-A.

In dieser Diskussion wird von der folgenden Konfiguration ausgegangen:

• In P-A und S-A ist qualifiziertes Lernen in bd1 aktiviert.

• Die Schnittstellen I1, I2, I3, ae0.0 und I4 gehören zu VLAN1, Lerndomäne LD1.

• Die Schnittstellen I7, I8, I5, ae0.1 und I6 gehören zu VLAN2, Lerndomäne LD2.

• Die Schnittstellen I9 und I10 gehören zu VLAN3, Lerndomäne LD3.

Für die IGMP-Sprecher (Hosts und Router) in derselben Lerndomäne sollten ld1, p-A und S-A verbunden wie ein Switch erscheinen.

Für die IGMP-Lautsprecher (Hosts und Router) in derselben Lerndomäne sollten ld2, P-A und S-A als ein Switch verbunden erscheinen.

Da es in der Lerndomäne ld3 keine Multichassis-Verbindungen gibt, erscheinen P-A und S-A für die IGMP-Lautsprecher (Hosts und Router) in der Lerndomäne ld3 nicht als ein Switch.

In dieser Diskussion wird davon ausgegangen, dass die Interchassis-Verbindung ICL1 der Lerndomäne ld1 und die Interchassis-Verbindung ICL2 der Lerndomäne ld2 entspricht.

Die Steuerung des Paketflusses wird unterstützt, mit Ausnahme der Übergabe von Informationen an IRB.

Datenweiterleitung mit qualifiziertem Lernen

In dieser Diskussion wird von einer Lerndomäne (LD), ld1, ausgegangen, und ferner wird davon ausgegangen, dass die Schnittstelle I1 auf Router P-A mit dem PIM-DR in der Lerndomäne verbunden ist und den Datenverkehr von Quellen im Core bezieht.

Für die Lieferung von Datenverkehr an Hosts, die mit Router S-A (der Nicht-DR) auf der Single-Homed-Verbindung wie I2, I4 (die zu ld1 gehören) verbunden sind, verlassen wir uns auf ICL1. Der Datenverkehr, der auf Router P-A an der Schnittstelle I1 trifft, wird über die Interchassis-Verbindung ICL1 an Router S-A gesendet, um an die Verbindungen weitergeleitet zu werden, die Interesse an s,g gemeldet haben, oder an die Links, die in der Lerndomäne ld1 auf den Router ausgerichtet sind.

Wenn die Schnittstelle ae0 leg in Router P-A ausfällt, empfangen die Hosts, die mit der Multichassis-Verbindung verbunden sind, Datenverkehr von Schnittstelle I1 über die Interchassis-Verbindung ICL1. In Router S-A wird der über die Interchassis-Verbindung ICL1 empfangene Datenverkehr an Multichassis-Verbindungen in der ausgehenden Schnittstellenliste gesendet, für die das aggregierte Ethernet-Gegenstück in Router P-A ausgefallen ist.

Es wird ferner angenommen, dass die Schnittstelle I9 im Router S-A zur Lerndomäne ld3 mit Interesse an s,g gehört, und dass die Schnittstelle I10 in der Lerndomäne ld3 im Router P-A Datenverkehr für s,g empfängt. Die Schnittstelle I9 empfängt in dieser Topologie keine Daten, da es keine Multichassis-Verbindungen (im a-a-Modus) und daher keine Interchassis-Verbindung in der Lerndomäne ld3 gibt.

Statische Gruppen auf Single-Homed-Schnittstellen

Bei Multichassis-Verbindungen sollte die statische Gruppenkonfiguration auf beiden Strecken vorhanden sein, und eine Synchronisierung mit dem anderen Chassis ist nicht erforderlich.

Die Synchronisierung der statischen Gruppen auf Single-Homed-Schnittstellen zwischen den Chassis wird nicht unterstützt. Das Hinzufügen logischer Schnittstellen zur Liste der ausgehenden Standardschnittstellen unterstützt jedoch die Übermittlung von Datenverkehr an die Schnittstelle innerhalb einer statischen Konfiguration.

Router-orientierte Schnittstellen als Multichassis-Links

IGMP-Abfragen können auf beiden Zweigen der Multichassis-Verbindungen eintreffen, aber bei beiden Peers sollte die Multichassis-Verbindung als routerorientiert betrachtet werden.

Berichte sollten nur einmal von der Multichassis-Verbindung verlassen werden, d. h. nur von einem Abschnitt.

Die folgende MC-LAG-Unterstützung für IGMP-Snooping in IRB wird bereitgestellt:

• Nicht-Proxy-Snooping

• Bei logischen Schnittstellen muss es sich um ausgehende Schnittstellen für alle Routen handeln, einschließlich der Standardroute

• IGMP-Snooping in einem reinen Layer-2-Switch

• IGMP-Snooping in Bridge-Domänen, qualifiziertes Lernen

• Schnittstelle für Router MC-Links

Die folgenden Funktionen werden not unterstützt:

• Proxy-Modus für Aktiv-Aktiv

• MC-LAG-Unterstützung für VPLS-Instanzen

• Trunk-Ports als Multichassis-Links

• Hinzufügen von logischen Schnittstellen zu ausgehenden Schnittstellen nach Bedarf.

  Logische Schnittstellen werden jedoch immer als Schnittstelle für den Router zur Liste der ausgehenden Schnittstellen hinzugefügt.

Unterstützte MC-LAG-Topologie

Um den verlustfreien Transport von FCoE-Datenverkehr über eine MC-LAG zu unterstützen, müssen Sie die entsprechende CoS-Klasse (Class of Service ) auf beiden Switches mit MC-LAG-Portmitgliedern konfigurieren. Die CoS-Konfiguration muss auf beiden MC-LAG-Switches identisch sein, da MC-LAGs keine Weiterleitungsklassen- und IEEE 802.1p-Prioritätsinformationen übertragen.

Switches, die nicht direkt mit FCoE-Hosts verbunden sind und als Pass-Through-Transit-Switches fungieren, unterstützen MC-LAGs für FCoE-Datenverkehr in einer invertierten U-Netzwerktopologie . Abbildung 3 zeigt eine invertierte U-Topologie mit QFX3500 Switches.

Abbildung 3: Unterstützte Topologie für eine MC-LAG auf einem FCoE-Transit-Switch

Eigenständige Switches unterstützen MC-LAGs. QFabric-System Node-Geräte unterstützen keine MC-LAGs. Virtual Chassis- und Mixed-Mode Virtual Chassis-Fabric (VCF)-Konfigurationen unterstützen FCoE nicht. Nur reine QFX5100 VCFs (bestehend aus nur QFX5100 Switches) unterstützen FCoE.

Ports, die Teil einer FCoE-FC-Gateway-Konfiguration (einer virtuellen FCoE-FC-Gateway-Fabric) sind, unterstützen keine MC-LAGs. Ports, die Mitglieder einer MC-LAG sind, fungieren als Pass-Through-Transit-Switch-Ports.

Die folgenden Regeln und Richtlinien gelten für MC-LAGs, wenn sie für FCoE-Datenverkehr verwendet werden. Die Regeln und Richtlinien tragen dazu bei, die ordnungsgemäße Handhabung und verlustfreie Transporteigenschaften zu gewährleisten, die für den FCoE-Verkehr erforderlich sind.

• Die beiden Switches, die die MC-LAG bilden (Switches S1 und S2), können keine Ports verwenden, die Teil einer FCoE-FC-Gateway-Fabric sind. Bei den MC-LAG-Switch-Ports muss es sich um Pass-Through-Transit-Switch-Ports handeln (die als Teil eines Zwischen-Transit-Switches verwendet werden, der nicht direkt mit FCoE-Hosts verbunden ist).

• Die MC-LAG Switches S1 und S2 können nicht direkt mit den FCoE-Hosts verbunden werden.

• Die beiden Switches, die als Zugriffsgeräte für FCoE-Hosts dienen (FCoE-Transit-Switches TS1 und TS2), verwenden Standard-LAGs zur Verbindung mit den MC-LAG-Switches S1 und S2. FCoE-Transit-Switches TS1 und TS2 können eigenständige Switches sein oder sie können Node-Geräte in einem QFabric-System sein.

• Die Transit-Switches TS1 und TS2 müssen Transit-Switch-Ports für die FCoE-Hosts und für die Standard-LAGs für die MC-LAG-Switches S1 und S2 verwenden.

• Aktivieren Sie FIP-Snooping im FCoE-VLAN auf den Transit-Switches TS1 und TS2. Sie können entweder VN_Port für VF_Port (VN2VF_Port) FIP-Snooping oder VN_Port für VN_Port (VN2VN_Port) FIP-Snooping konfigurieren, je nachdem, ob die FCoE-Hosts auf Ziele im FC-SAN (VN2VF_Port FIP-Snooping) oder Ziele im Ethernet-Netzwerk (VN2VN_Port FIP-Snooping) zugreifen müssen.

  FIP-Snooping sollte am Zugriffs-Edge durchgeführt werden und wird auf MC-LAG-Switches nicht unterstützt. Aktivieren Sie FIP-Snooping nicht auf den MC-LAG-Switches S1 und S2. (Aktivieren Sie FIP-Snooping nicht auf den MC-LAG-Ports, die die Switches S1 und S2 mit den Switches TS1 und TS2 verbinden, oder auf den LAG-Ports, die Switch S1 mit S2 verbinden.)

  Anmerkung:

  Juniper Networks QFX10000 Aggregation-Switches unterstützen FIP-Snooping nicht, sodass sie in dieser Topologie nicht als FIP-Snooping-Zugangs-Switches (Transit Switches TS1 und TS2) verwendet werden können.

• Die CoS-Konfiguration muss auf den MC-LAG-Switches konsistent sein. Da MC-LAGs keine Weiterleitungsklassen- oder Prioritätsinformationen enthalten, muss jeder MC-LAG-Switch dieselbe CoS-Konfiguration haben, um einen verlustfreien Transport zu unterstützen. (Auf jedem MC-LAG-Switch müssen der Name, die Ausgangswarteschlange und die CoS-Bereitstellung jeder Weiterleitungsklasse identisch sein, und die Konfiguration der prioritätsbasierten Datenstromsteuerung (PFC) muss identisch sein.)

• Transit-Switches (Serverzugriff)
• MC-LAG-Switches (FCoE-Aggregation)

FIP-Snooping und vertrauenswürdige FCoE-Ports

Um einen sicheren Zugriff aufrechtzuerhalten, aktivieren Sie VN2VF_Port FIP-Snooping oder VN2VN_Port FIP-Snooping an den Transit-Switch-Zugriffsports, die direkt mit den FCoE-Hosts verbunden sind. FIP-Snooping sollte am Zugriffsrand des Netzwerks durchgeführt werden, um unbefugten Zugriff zu verhindern. In Abbildung 3 aktivieren Sie beispielsweise FIP-Snooping für die FCoE-VLANs auf den Transit-Switches TS1 und TS2, die die Zugriffsports enthalten, die mit den FCoE-Hosts verbunden sind.

Aktivieren Sie FIP-Snooping nicht auf den Switches, die zum Erstellen der MC-LAG verwendet werden. In Abbildung 3 würden Sie beispielsweise FIP-Snooping für die FCoE-VLANs auf den Switches S1 und S2 nicht aktivieren.

Konfigurieren Sie Links zwischen Switches als FCoE-vertrauenswürdige Ports, um den FIP-Snooping-Overhead zu reduzieren und sicherzustellen, dass das System FIP-Snooping nur am Zugriffs-Edge durchführt. Konfigurieren Sie in der Beispieltopologie die LAG-Ports der Transit-Switches TS1 und TS2, die mit den MC-LAG-Switches verbunden sind, als vertrauenswürdige FCoE-Ports, konfigurieren Sie die MC-LAG-Ports der Switches S1 und S2, die mit den Switches TS1 und TS2 verbunden sind, als vertrauenswürdige FCoE-Ports und konfigurieren Sie die Ports in der LAG, die die Switches S1 bis S2 verbindet, als vertrauenswürdige FCoE-Ports.

CoS und Data Center Bridging (DCB)

Die MC-LAG-Links enthalten keine Informationen zu Weiterleitungsklassen oder -prioritäten. Die folgenden CoS-Eigenschaften müssen auf jedem MC-LAG-Switch oder auf jeder MC-LAG-Schnittstelle dieselbe Konfiguration aufweisen, um einen verlustfreien Transport zu unterstützen:

• Name der FCoE-Weiterleitungsklasse: Beispielsweise könnte die Weiterleitungsklasse für FCoE-Datenverkehr die Standardweiterleitungsklasse fcoe auf beiden MC-LAG-Switches verwenden.

• FCoE-Ausgabewarteschlange: Beispielsweise könnte die fcoe Weiterleitungsklasse Warteschlange 3 auf beiden MC-LAG-Switches zugeordnet werden (Warteschlange 3 ist die Standardzuordnung für die fcoe Weiterleitungsklasse).

• Klassifizierer: Die Weiterleitungsklasse für FCoE-Datenverkehr muss auf jeder Mitgliedsschnittstelle der MC-LAG auf beiden MC-LAG-Switches demselben IEEE 802.1p-Codepunkt zugeordnet werden. Beispielsweise könnte die FCoE-Weiterleitungsklasse fcoe dem IEEE 802.1p-Codepunkt 011 zugeordnet werden (Codepunkt 011 ist die Standardzuordnung für die fcoe Weiterleitungsklasse).

• Prioritätsbasierte Datenstromsteuerung (PFC): PFC muss für den FCoE-Codepunkt auf jedem MC-LAG-Switch aktiviert und mithilfe eines Überlastungsbenachrichtigungsprofils auf jede MC-LAG-Schnittstelle angewendet werden.

Sie müssen außerdem die erweiterte Übertragungsauswahl (Enhanced Transmission Selection, ETS) auf den MC-LAG-Schnittstellen konfigurieren, um ausreichende Planungsressourcen (Bandbreite, Priorität) für den verlustfreien Transport bereitzustellen. Die ETS-Konfiguration kann auf jedem MC-LAG-Switch unterschiedlich sein, solange genügend Ressourcen eingeplant sind, um den verlustfreien Transport für den erwarteten FCoE-Datenverkehr zu unterstützen.

Link Layer Discovery Protocol (LLDP) und Data Center Bridging Capability Exchange Protocol (DCBX) müssen auf jeder MC-LAG-Mitgliedsschnittstelle aktiviert sein (LLDP und DCBX sind standardmäßig auf allen Schnittstellen aktiviert).

Vorteile der Verwendung von EVPN-MPLS mit Junos Fusion Enterprise und MC-LAG

Verwenden Sie EVPN-MPLS mit Junos Fusion Enterprise und MC-LAG, um verteilte Campus- und Datencenter-Standorte zu einer einzigen virtuellen Layer-2-Bridge zu verbinden.

BUM-Datenverkehrsverarbeitung

In den in Abbildung 4 und Abbildung 5 gezeigten Anwendungsfällen sind PE1, PE2 und PE3 EVPN-Peers und PE2 und PE3 MC-LAG-Peers. Beide Gruppen von Peers tauschen Steuerungsinformationen aus und leiten Datenverkehr aneinander weiter, was zu Problemen führt. Tabelle 2 gibt einen Überblick über die auftretenden Probleme und wie Juniper Networks die Probleme bei der Implementierung der EVPN-MPLS-Interworking-Funktion behebt.

Geteilte Horizonte

In den in Abbildung 4 und Abbildung 5 gezeigten Anwendungsfällen verhindert der geteilte Horizont, dass mehrere Kopien eines BUM-Pakets an ein CE-Gerät (Satellitengerät) weitergeleitet werden. Die Implementierungen von EVPN-MPLS und MC-LAG mit geteiltem Horizont widersprechen sich jedoch, was zu Problemen führt. In Tabelle 3 wird das Problem erläutert und erläutert, wie Juniper Networks es bei der Implementierung der EVPN-MPLS-Interworking-Funktion löst.

MAC-Lernen

EVPN und MC-LAG verwenden die gleiche Methode zum Erlernen von MAC-Adressen: Ein PE-Gerät lernt MAC-Adressen von seinen lokalen Schnittstellen und synchronisiert die Adressen mit seinen Peers. Da jedoch sowohl EVPN als auch MC-LAG die Adressen synchronisieren, tritt ein Problem auf.

In Tabelle 4 wird das Problem beschrieben und wie es durch die Interworking-Implementierung von EVPN-MPLS verhindert wird. Die in Abbildung 4 und Abbildung 5 dargestellten Anwendungsfälle veranschaulichen das Problem. In beiden Anwendungsfällen sind PE1, PE2 und PE3 EVPN-Peers und PE2 und PE3 MC-LAG-Peers.

Behandeln von Downlink zwischen kaskadierten und Uplink-Ports in Junos Fusion Enterprise

In der in Abbildung 4 dargestellten Junos Fusion Enterprise wird davon ausgegangen, dass das Aggregationsgerät PE2 ein BUM-Paket von PE1 empfängt und dass die Verbindung zwischen dem kaskadierten Port von PE2 und dem entsprechenden Uplink-Port des Satellitengeräts SD1 unterbrochen ist. Unabhängig davon, ob das BUM-Paket von MC-LAG oder EVPN Multihoming aktiv-aktiv verarbeitet wird, ist das Ergebnis dasselbe: Das Paket wird über die ICL-Schnittstelle an PE3 weitergeleitet, das es an Dual-Homed SD1 weiterleitet.

Zur weiteren Veranschaulichung, wie EVPN mit Multihoming Aktiv/Aktiv-Modus diese Situation mit dual-homed-SD1 handhabt, nehmen wir an, dass sich die DF-Schnittstelle auf PE2 befindet und dem Downlink zugeordnet ist, und dass sich die Nicht-DF-Schnittstelle auf PE3 befindet. In der Regel verwirft die Nicht-DF-Schnittstelle pro EVPN mit Multihoming Aktiv-Aktiv-Weiterleitungslogik das Paket. Aufgrund des Downlinks, der der DF-Schnittstelle zugeordnet ist, leitet PE2 das BUM-Paket jedoch über die ICL an PE3 weiter, und die Nicht-DF-Schnittstelle auf PE3 leitet das Paket an SD1 weiter.

Layer-3-Gateway-Unterstützung

Die EVPN-MPLS-Interworking-Funktion unterstützt die folgenden Layer-3-Gateway-Funktionen für erweiterte Bridge-Domänen und VLANs:

• Integrierte Routing- und Bridging-Schnittstellen (IRB) zur Weiterleitung des Datenverkehrs zwischen den erweiterten Bridge-Domänen oder VLANs.

• Standardmäßige Layer 3-Gateways leiten Datenverkehr von einem physischen Server (Bare-Metal) in einer erweiterten Bridge-Domäne oder einem VLAN an einen physischen Server oder eine virtuelle Maschine in einer anderen erweiterten Bridge-Domäne oder einem anderen VLAN weiter.