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 einzigen Verwaltungspunkt.

So funktioniert die 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 allen Geräten gemeinsam ist.

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 peers-synchronize Anweisung in der [edit system commit] Hierarchie 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 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. Statische Zuordnung des lokalen Geräts zu den Remotegeräten.

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

3. Erstellen bedingter Gruppen.

4. Erstellen Sie Anwendungsgruppen.

5. Aktivieren Sie NETCONF über SSH.

6. Konfigurieren Sie die Gerätedetails und die Details zur Benutzer-Authentifizierung für die Konfigurationssynchronisierung.

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

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 Remote-Gerät verwendet, und eine globale Konfigurationsgruppe wird von den lokalen und Remote-Geräten gemeinsam genutzt.

Sie können z. B. eine lokale Konfigurationsgruppe namens Gruppe A erstellen, die die vom lokalen Gerät verwendete Konfiguration (Switch A) enthält, eine Remotekonfigurationsgruppe namens Gruppe B, die die von Remotegeräten (Switch B, Switch C und Switch D) verwendete Konfiguration enthält, und eine globale Konfigurationsgruppe namens 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 ausführen.

Anwenden von Konfigurationsgruppen

Um Konfigurationsgruppen anzuwenden, aktivieren Sie die apply-groups Anweisung auf Hierarchieebene [edit] . Geben Sie beispielsweise den set apply-groups [ GroupA GroupB GroupC ] Befehl ein, um die lokale Konfigurationsgruppe (z. B. Gruppe A), die Remotekonfigurationsgruppe (z. B. Gruppe B) und die globale Konfigurationsgruppe (z. B. Gruppe C) anzuwenden.

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 ein.

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

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

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

Schalter A

Wenn Sie nur Konfigurationen von Switch A mit Switch B, Switch C und Switch D synchronisieren möchten, müssen Sie die peers Anweisung auf 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 ein.

Synchronisierung von Konfigurationen und Commits zwischen Geräten

Das lokale (oder anfordernde) Gerät, auf dem Sie die peers-synchronize Anweisung aktivieren oder den commit peers-synchronize Befehl ausgeben, kopiert und lädt seine Konfiguration 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 mithilfe eines 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 Remote-Geräte.

2. Die Remotegeräte laden die Konfiguration, senden die Ergebnisse des Ladens 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 erfolgreicher Konfiguration wird ein Commit ausgeführt.

Die Konfigurationssynchronisierung ist nicht erfolgreich, wenn entweder a) das Remote-Gerät nicht verfügbar ist oder b) das Remote-Gerät erreichbar ist, aber aus den folgenden Gründen Fehler auftreten:

• 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 zur Synchronisierung der Konfiguration von einem Gerät auf ein anderes eingeben. Wenn Sie beispielsweise die peers Anweisung auf dem lokalen Gerät konfiguriert haben und die Konfiguration mit dem entfernten Gerät synchronisieren möchten, können Sie den commit Befehl einfach auf dem lokalen Gerät ausgeben. Wenn Sie jedoch den commit Befehl auf dem lokalen Gerät ausgeben 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 Remotegeräteinformationen konfiguriert haben und den commit Befehl ausgeben, wird nur die Konfiguration auf dem lokalen Gerät festgeschrieben. 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 Passwort für die in der peers Anweisung konfigurierten 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 MC-LAG-Konsistenzprüfung

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

Wie MC-LAG-Konsistenzprüfungen funktionieren

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

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

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

3. Der entfernte 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.

   Bei mäßiger Inkonsistenz zwischen den beiden Konfigurationen werden Syslog-Meldungen ausgegeben.

Die folgenden Ereignisse treten während der Konfigurationskonsistenzprüfung auf, nachdem Sie einen Commit auf dem entfernten MC-LAG-Peer ausgegeben haben:

• Führen Sie eine MC-LAG-Konfiguration auf dem entfernten MC-LAG-Peer durch.

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

• Der lokale MC-LAG-Peer empfängt die Konfiguration vom entfernten 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 es werden Syslog-Meldungen ausgegeben.

  Bei mäßiger Inkonsistenz zwischen den beiden Konfigurationen 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 andere auf den MC-LAG-Peers eindeutig 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.

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

Sie erhalten beispielsweise 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 mehrere Inkonsistenzen vorliegen, wird nur die erste Inkonsistenz angezeigt. Wenn die Erzwingungsebene für einen MC-LAG-Parameter obligatorisch ist und Sie diesen Parameter nicht korrekt konfiguriert haben, zeigt der Befehl an, dass die MC-LAG-Schnittstelle ausgefallen ist.

Wenn Remote-Peers nicht erreichbar sind

Wenn Sie einen Commit auf dem lokalen Peer ausgeben und der Remote-Peer 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 ausgeben, 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 geprüft werden, zusammen mit ihren Konsistenzanforderungen (identisch oder eindeutig), den Hierarchien, in denen die Parameter konfiguriert sind, und den Durchsetzungsebenen der Konsistenzprüfung (obligatorisch oder erwünscht).

Ermitteln des Status einer Konfigurationskonsistenzprüfung

Die folgenden Befehle enthalten Informationen zum Status der Konfigurationskonsistenzprüfung:

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

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

• 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 Durchsetzungsebene (obligatorisch oder erwünscht) und das Ergebnis der Konfigurationskonsistenzprüfung anzuzeigen. Die Ergebnisse sind entweder bestanden oder nicht.

• Geben 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 Interchassis-Steuerverbindung, die Konsistenzanforderung (identisch oder eindeutig), die Erzwingungsebene (obligatorisch oder erwünscht) und das Ergebnis der Konfigurationskonsistenzprüfung beziehen. Das Ergebnis ist entweder bestanden oder nicht.

• Geben Sie den Befehl show multi-chassis mc-lag configuration-consistency mcae-config ein, um den Status der Konfigurationskonsistenzprüfung für Parameter anzuzeigen, die sich auf die Multichassis-aggregierte Ethernet-Schnittstelle, die Konsistenzanforderung (identisch oder eindeutig), die Erzwingungsebene (obligatorisch oder erwünscht) und das Ergebnis der Konfigurationskonsistenzprüfung beziehen. Das Ergebnis ist entweder bestanden oder nicht.

• Geben 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, der Konsistenzanforderung (identisch oder eindeutig), der Durchsetzungsebene (obligatorisch oder erwünscht) und dem Ergebnis der Konfigurationskonsistenzprüfung anzuzeigen. Die Ergebnisse sind entweder bestanden oder nicht.

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

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

PIM-Betrieb mit normaler Routerauswahl

Im normalen Modus mit festgelegter Router-Auswahl werden die IRB - oder RVI-Schnittstellen auf beiden MC-LAG-Peers mit aktiviertem PIM konfiguriert. In diesem Modus wird einer der MC-LAG-Peers durch den PIM Designated Router Select-Mechanismus zum designierten Router. Der ausgewählte designierte Router verwaltet den Rendezvouspunktbaum (RPT) und den Baum des kürzesten Pfads (SPT), damit er Daten vom Quellgerät empfangen kann. Der gewählte designierte Router nimmt an regelmäßigen PIM-Join- und Bereinigungsaktivitä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 Multichassis-aggregierte Ethernet-Schnittstellen (möglicherweise Hashing auf einem der MC-LAG-Peers) und Single-Homed-Verbindungen 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 den Datenverkehr über die ICL-Schnittstelle, die als Multicast-Router-Schnittstelle (mrouter) fungiert.

Wenn der designierte Router ausfällt, muss der nicht designierte Router den gesamten Weiterleitungsbaum (RPT und SPT) erstellen, was zu einem Verlust des Multicast-Datenverkehrs führen kann.

PIM-Betrieb mit Dual Designated Router-Modus

Im Dual-Designated Router-Modus fungieren beide MC-LAG-Peers als designierte Router (aktiv und Standby) und senden periodische Join- und Prune-Nachrichten stromaufwärts zum Rendezvouspunkt oder zur Quelle und schließen sich schließlich dem RPT oder SPT an.

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 hat.

Der Standby-MC-LAG-Peer tritt ebenfalls dem Weiterleitungsbaum bei und empfängt die Multicast-Daten. Der Standby-MC-LAG-Peer verwirft die Daten, da er eine leere Liste ausgehender Schnittstellen (OIL) hat. Wenn der Standby-MC-LAG-Peer den primären MC-LAG-Peer-Ausfall erkennt, fügt er das Empfänger-VLAN zum OIL hinzu und beginnt, den Multicast-Datenverkehr weiterzuleiten.

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

Behandlung von Fehlern

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 Router-Priorität. Dadurch wird sichergestellt, dass der primäre MC-LAG-Peer die vorgesehene Router-Mitgliedschaft 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 über den Standardeintrag oder den Snooping-Eintrag über die ICL-PL-Schnittstelle geflutet und über die MC-AE-Schnittstelle auf dem MC-LAG-Peer weitergeleitet. Wenn die ICL-PL-Schnittstelle ausfällt, sinkt die PIM-Nachbarschaft. In diesem Fall werden beide MC-LAG-Peers zum designierten Router. Der Backup-MC-LAG-Peer schaltet seine Verbindungen aus, und das Routing-Peering geht verloren. Wenn die ICCP-Verbindung ausfällt, ändert der Backup-MC-LAG-Peer die LACP-System-ID und schaltet die MC-AE-Schnittstellen aus. Der Zustand der PIM-Nachbarn bleibt funktionsfähig.

IGMP-Snooping im MC-LAG Active-Active-Mode-Funktionalität

Der Aktiv-Aktiv-Modus der Multichassis Link Aggregation Group (MC-LAG) und IGMP-Snooping im Aktiv-Standby-Modus werden unterstützt. MC-LAG ermöglicht es einem Gerät, eine logische LAG-Schnittstelle mit zwei oder mehr Netzwerkgeräten zu bilden. MC-LAG bietet zusätzliche Vorteile wie Redundanz auf Knotenebene, Multihoming und ein schleifenfreies Layer-2-Netzwerk ohne Verwendung des 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

• Router-seitige Multichassis-Verbindungen

Die folgenden Verbesserungen des Aktiv-Aktiv-Bridging und des 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, die qualifiziertes Lernen durchführen

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

Folgende Funktionen werden not unterstützt:

• MC-LAG für VPLS-Instanzen

• MC-Links Trunk-Ports

• Proxy-Modus für Aktiv-Aktiv-Modus

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

  Interchassis-Links können der Liste der ausgehenden Schnittstellen als Router-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 Active-Active-Bridging unterstützt wird.

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

Die Schnittstellen I3 und I4 sind Single-Homed-Schnittstellen. Die Multichassis-Verbindungen 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är aktiven (S-A) Router. Die Schnittstellen I4, ae0.0 und ae0.1 befinden sich in derselben Bridge-Domäne im primär aktiven (P-A) Router. Die Schnittstellen I3, I4, ae0.0 und ae0.1 befinden sich in derselben Lerndomäne wie der Interchassis Link (ICL), der die beiden Gehäuse 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 ist. Router P-A ist das Gehäuse, das für das Abrufen des Datenverkehrs vom IP-Core verantwortlich ist. Daher wird die PIM-DR-Wahl verwendet, um eine Duplizierung des Datenverkehrs zu vermeiden.

Lerndomänen 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.

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

Statusaktualisierungen der Steuerungsebene, die durch auf dem Remote-Gehäuse empfangene Pakete ausgelöst werden

Im Folgenden finden Sie die Statusaktualisierungen der Steuerungsebene, die durch die auf dem Remote-Gehäuse empfangenen Pakete ausgelöst werden:

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

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

Datenweiterleitung

In dieser Diskussion wird davon ausgegangen, dass integriertes Routing und Bridging auf Router P-A das PIM-DR ist. Er zieht den Datenverkehr von Quellen im Kern. Der Datenverkehr kann auch über Layer-2-Schnittstellen in der Bridge-Domäne kommen. Bei Hosts, die direkt mit dem P-A-Chassis verbunden sind, ändert sich die Art und Weise, wie Daten übermittelt werden, nicht.

Für die Bereitstellung von Datenverkehr zu Hosts, die mit S-A (d. h. der Nicht-DR) über die Single-Homed-Verbindung wie I3 verbunden sind, verlassen wir uns auf die Interchassis-Verbindung. Der Datenverkehr, der auf P-A trifft, 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 dem Router zugewandt sind.

Wenn die AE0-Strecke in P-A ausfällt, empfangen die mit der Multichassis-Verbindung verbundenen Hosts Datenverkehr über ICL. Bei S-A wird der auf ICL empfangene Datenverkehr an Multichassis-Links in der Liste der ausgehenden Schnittstellen gesendet, für die das AE-Pendant in P-A ausgefallen ist.

Reine Layer 2-Topologie ohne integriertes Routing und Bridging

Abbildung 2 zeigt, dass das mit dem PIM-DR verbundene Gehäuse der primär aktive (P-A) Router und das andere der sekundär aktive (SA) 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-Verbindungen 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 derselben 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, der Lerndomäne ld1.

• Die Schnittstellen I7, I8, I5, ae0.1 und I6 gehören zu vlan2, der Lerndomäne ld2.

• Die Schnittstellen I9 und I10 gehören zu vlan3, Lerndomäne ld3.

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

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

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

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.

Der kontrollierte Paketfluss 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 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 Bereitstellung von Datenverkehr an Hosts, die mit Router S-A (dem Nicht-DR) über die Single-Homed-Verbindung wie I2, I4 (zu ld1 gehörend) verbunden sind, verlassen wir uns auf ICL1. Der Datenverkehr, der Router P-A an der Schnittstelle I1 erreicht, wird über die Interchassis-Verbindung ICL1 an Router S-A gesendet, um an die Links weitergeleitet zu werden, die Interesse an s,g gemeldet haben, oder an die Links, die dem Router in der Lerndomäne ld1 zugewandt sind.

Wenn die Schnittstelle ae0 in Router P-A ausfällt, empfangen die mit der Multichassis-Verbindung verbundenen Hosts Datenverkehr von der Schnittstelle I1 über die Interchassis-Verbindung ICL1. In Router S-A wird der auf der Interchassis-Verbindung ICL1 empfangene Datenverkehr an Multichassis-Links in der Liste der ausgehenden Schnittstellen gesendet, für die das aggregierte Ethernet-Pendant in Router P-A ausgefallen ist.

Es wird weiterhin angenommen, dass die Schnittstelle I9 in Router S-A zur Lerndomäne ld3 mit Interessen in s,g gehört und dass die Schnittstelle I10 in der Lerndomäne ld3 in Router P-A Datenverkehr für s,g empfängt. Schnittstelle I9 empfängt keine Daten in dieser Topologie, 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-Links sollte die statische Gruppenkonfiguration auf beiden Legs vorhanden sein, und eine Synchronisierung mit den 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 standardmäßigen Liste der ausgehenden Schnittstellen unterstützt jedoch die Datenverkehrsbereitstellung an die Schnittstelle innerhalb einer statischen Konfiguration.

Router-seitige Schnittstellen als Multichassis-Verbindungen

IGMP-Abfragen können auf beiden Zweigen der Multichassis-Verbindungen eintreffen, aber in beiden Peers sollte die Multichassis-Verbindung als dem Router zugewandt betrachtet werden.

Berichte sollten nur einmal von der Multichassis-Verbindung beendet werden, d. h. nur von einem Leg.

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

• Nicht-Proxy-Snooping

• Logische Schnittstellen müssen ausgehende Schnittstellen für alle Routen sein, einschließlich der Standardroute

• IGMP-Snooping in einem reinen Layer 2-Switch

• IGMP-Snooping in Bridge-Domänen mit qualifiziertem Lernen

• Router-orientierte Schnittstelle MC-Links

Die folgenden Funktionen werden not unterstützt:

• Proxy-Modus für Aktiv-Aktiv-Modus

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

• Trunk-Ports als Multichassis-Verbindungen

• Hinzufügen logischer Schnittstellen zu ausgehenden Schnittstellen nach Bedarf.

  Logische Schnittstellen werden jedoch immer als dem Router zugewandte Schnittstelle 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 Class of Service (CoS) 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 unter Verwendung von QFX3500-Switches.

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

Eigenständige Switches unterstützen MC-LAGs. Virtual Chassis- und gemischte 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 für den FCoE-Datenverkehr erforderliche ordnungsgemäße Handhabung und verlustfreie Transporteigenschaften zu gewährleisten.

• 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 für die Verbindung zu den MC-LAG-Switches S1 und S2. Die FCoE Transit Switches TS1 und TS2 können eigenständige Switches sein.

• Die Transit-Switches TS1 und TS2 müssen Transit-Switch-Ports für die FCoE-Hosts und für die Standard-LAGs zu den 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 auf 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.)

  Hinweis:

  QFX10000-Switches unterstützen kein FIP-Snooping. Daher können sie in dieser Topologie nicht als FIP-Snooping-Zugriffs-Switches (Transit Switches TS1 und TS2) verwendet werden.

• Die CoS-Konfiguration muss auf den MC-LAG-Switches konsistent sein. Da MC-LAGs keine Weiterleitungsklassen- oder Prioritätsinformationen übertragen, muss jeder MC-LAG-Switch über dieselbe CoS-Konfiguration verfügen, um 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 Flusssteuerung (PFC) muss identisch sein.)

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

FIP Snooping und FCoE Trusted Ports

Um den sicheren Zugriff aufrechtzuerhalten, aktivieren Sie VN2VF_Port FIP-Snooping oder VN2VN_Port FIP-Snooping an den Zugriffsports des Transit-Switches, 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 auf den FCoE-VLANs auf den Transit-Switches TS1 und TS2, die die mit den FCoE-Hosts verbundenen Zugriffsports enthalten.

Aktivieren Sie kein FIP-Snooping auf den Switches, die zur Erstellung 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 Verbindungen zwischen Switches als vertrauenswürdige FCoE-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 mit den MC-LAG-Switches verbundenen LAG-Ports TS1 und TS2 des Transit-Switches als vertrauenswürdige FCoE-Ports, konfigurieren Sie die mit den Switches TS1 und TS2 verbundenen MC-LAG-Ports Switches S1 und S2 als vertrauenswürdige FCoE-Ports und konfigurieren Sie die Ports in der LAG, die die Switches S1 mit S2 verbindet, als vertrauenswürdige FCoE-Ports.

CoS und Data Center Bridging (DCB)

Die MC-LAG-Links übertragen keine Weiterleitungsklassen- oder Prioritätsinformationen. Die folgenden CoS-Eigenschaften müssen auf jedem MC-LAG-Switch oder auf jeder MC-LAG-Schnittstelle dieselbe Konfiguration aufweisen, um 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 kann 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 demselben IEEE 802.1p-Codepunkt auf jeder Mitgliedsschnittstelle der MC-LAG auf beiden MC-LAG-Switches 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 am FCoE-Codepunkt auf jedem MC-LAG-Switch aktiviert und über ein Überlastungsbenachrichtigungsprofil auf jede MC-LAG-Schnittstelle angewendet werden.

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

Das Link Layer Discovery Protocol (LLDP) und das 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

Nutzen Sie EVPN-MPLS mit Junos Fusion Enterprise und MC-LAG, um verteilte Campus- und Datencenterstandorte miteinander zu verbinden und eine einzige virtuelle Layer 2-Brücke zu bilden.

BUM-Datenverkehrsabwicklung

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

Geteilter Horizont

In den in Abbildung 4 und Abbildung 5 dargestellten Anwendungsfällen verhindert Split Horizon, 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 einem Problem führt. Tabelle 3 erläutert das Problem und wie Juniper Networks es bei der Implementierung der EVPN-MPLS-Interworking-Funktion löst.

MAC-Lernen

EVPN und MC-LAG verwenden dieselbe 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 erläutert, wie die Implementierung der EVPN-MPLS-Interworking-Lösung das Problem verhindert. Die in Abbildung 4 und Abbildung 5 dargestellten Anwendungsszenarien veranschaulichen das Problem. In beiden Anwendungsfällen sind PE1, PE2 und PE3 EVPN-Peers und PE2 und PE3 MC-LAG-Peers.

Handhabung von Downlink-Verbindungen zwischen Cascade- und Uplink-Ports in Junos Fusion Enterprise

Gehen Sie im in Abbildung 4 gezeigten Junos Fusion Enterprise davon aus, dass das Aggregationsgerät PE2 ein BUM-Paket von PE1 empfängt und dass die Verbindung zwischen dem kaskadierten Port auf PE2 und dem entsprechenden Uplink-Port auf dem Satellitengerät SD1 ausgefallen ist. Unabhängig davon, ob das BUM-Paket von MC-LAG oder EVPN-Multihoming Aktiv-Aktiv-Datenverkehr verarbeitet wird, ist das Ergebnis dasselbe: Das Paket wird über die ICL-Schnittstelle an PE3 weitergeleitet, das es an Dual-Homed SD1 weiterleitet.

Um weiter zu veranschaulichen, wie EVPN mit Multihoming Aktiv-Aktiv diese Situation mit Dual-Homed SD1 handhabt, nehmen wir an, dass sich die DF-Schnittstelle auf PE2 befindet und mit der Down-Verbindung verbunden ist und dass sich die Nicht-DF-Schnittstelle auf PE3 befindet. In der Regel verwirft die Nicht-DF-Schnittstelle das Paket pro EVPN mit Multihoming Aktiv-Aktiv-Weiterleitungslogik. Aufgrund der mit der DF-Schnittstelle verbundenen Down-Verbindung leitet PE2 das BUM-Paket jedoch über die ICL an PE3 weiter, und die Nicht-DF-Schnittstelle an PE3 leitet das Paket an SD1 weiter.

Unterstützung von Layer 3-Gateways

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 zur Weiterleitung des Datenverkehrs von einem physischen (Bare-Metal-)Server 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 VLAN.

Plattformspezifisches MC-LAG-Verhalten