Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Fehlerbehebung bei Multichassis Link Aggregation

Verwenden Sie die folgenden Informationen, um Konfigurationsprobleme bei der Multichassis-Link-Aggregation zu beheben:

MAC-Adressen, die auf aggregierten Multichassis-Ethernet-Schnittstellen gelernt wurden, werden nicht aus der MAC-Adresstabelle entfernt

Problem

Beschreibung

Wenn beide aggregierten Multichassis-Ethernet-Schnittstellen auf beiden verbundenen MC-LAG-Peers (Multichassis Link Aggregation Group) ausgefallen sind, werden die auf den aggregierten Multichassis-Ethernet-Schnittstellen gelernten MAC-Adressen nicht aus der MAC-Adresse-Tabelle entfernt.

Wenn Sie beispielsweise die Multichassis-aggregierte Ethernet-Schnittstelle (ae0) auf beiden MC-LAG-Peers deaktivieren, indem Sie den set interfaces ae0 disable Befehl ausgeben und die Konfiguration bestätigen, zeigt die MAC-Tabelle weiterhin an, dass die MAC-Adressen auf den Multichassis-aggregierten Ethernet-Schnittstellen beider MC-LAG-Peers gelernt wurden.

Lösung

Dies ist ein erwartetes Verhalten.

MC-LAG-Peer wechselt nicht in den Standby-Modus

Problem

Beschreibung

Ein MC-LAG-Peer (Multichassis Link Aggregation Group) wechselt nicht in den Standby-Modus, wenn die in der ICCP-Konfiguration (Inter-Chassis Control Protocol) angegebene IP-Adresse des MC-LAG-Peer und die in der Konfiguration des Multichassis-Schutzes angegebene IP-Adresse unterschiedlich sind.

Lösung

Um zu verhindern, dass der Standby-Modus fehlschlägt, stellen Sie sicher, dass die Peer-IP-Adresse in den ICCP-Konfigurationen und die IP-Adresse in Multichassis-Schutzkonfigurationen identisch sind.

Sekundärer MC-LAG-Peer mit Statuskontrolle auf Standby wird inaktiv

Problem

Beschreibung

Wenn die Interchassis Control Link Link Protection Link (ICL-PL) und die aggregierten Ethernet-Schnittstellen des Multichassis auf dem primären MC-LAG-Peer (Multichassis Link Aggregation Group) ausfallen, werden die aggregierten Multichassis-Ethernet-Schnittstellen des sekundären MC-LAG-Peers mit Statuskontrolle auf Standby inaktiv statt aktiv.

Lösung

Dies ist ein erwartetes Verhalten.

Umleitungsfilter haben Vorrang vor benutzerdefinierten Filtern

Problem

Beschreibung

Implizite Failover-Umleitungsfilter (Multichassis Link Aggregation Group, MC-LAG) haben Vorrang vor vom Benutzer konfigurierten expliziten Filtern.

Lösung

Dies ist ein erwartetes Verhalten.

Die operative Befehlsausgabe ist falsch

Problem

Beschreibung

Nachdem Sie Inter-Chassis Control Protocol (ICCP) deaktiviert haben, zeigt die Ausgabe des show iccp Betriebsbefehls weiterhin registrierte Client-Daemons wie mcsnoopd, lacpd und eswd an.

Zum Beispiel:

Die show iccp Befehlsausgabe zeigt immer registrierte Module an, unabhängig davon, ob ICCP-Peers konfiguriert sind oder nicht.

Lösung

Dies ist ein erwartetes Verhalten.

Es kann bis zu 60 Sekunden dauern, bis die ICCP-Verbindung aktiv wird.

Problem

Beschreibung

Wenn die ICCP-Konfiguration (Inter-Chassis Control Protocol) und die RVI-Konfiguration (Routed VLAN Interface) zusammen festgelegt werden, kann es bis zu 60 Sekunden dauern, bis die ICCP-Verbindung aktiv wird.

Lösung

Dies ist ein erwartetes Verhalten.

Das auf einer aggregierten Multichassis-Ethernet-Schnittstelle gelernte MAC-Adressenalter wird auf Null zurückgesetzt

Problem

Beschreibung

Wenn Sie eine Interchassis-Verbindung-Schutzverbindung (ICL-PL) aktivieren und dann deaktivieren, wird das auf der Multichassis-aggregierten Ethernet-Schnittstelle erlernte Alter der MAC-Adresse auf Null zurückgesetzt. Die Änderungen an der Next-Hop-Schnittstelle lösen MAC-Adressen-Updates in der Hardware aus, die wiederum veraltete Updates in der Packet Forwarding Engine auslösen. Das Ergebnis ist, dass das Alter der MAC-Adresse auf Null aktualisiert wird.

Beispielsweise wurde die ICL-PL deaktiviert, und die show ethernet-switching table Befehlsausgabe zeigt, dass die MAC-Adressen ein Alter von 0 haben.

Lösung

Dies ist ein erwartetes Verhalten.

MAC-Adresse wird in einem Standard-VLAN nicht remote gelernt

Problem

Beschreibung

Lösung

Dies ist ein erwartetes Verhalten.

Snooping-Einträge, die auf aggregierten Multichassis-Ethernet-Schnittstellen erlernt wurden, werden nicht entfernt

Problem

Beschreibung

Wenn Multichassis-aggregierte Ethernet-Schnittstellen in einem VLAN konfiguriert sind, das für Multicast-Snooping aktiviert ist, werden die Mitgliedschaftseinträge, die auf den Multichassis-aggregierten Ethernet-Schnittstellen im VLAN gelernt wurden, nicht gelöscht, wenn die aggregierten Multichassis-Ethernet-Schnittstellen ausfallen. Dies geschieht, um die Konvergenzzeit zu beschleunigen, wenn Schnittstellen hoch- oder hoch- und abgeschaltet werden.

Lösung

Dies ist ein erwartetes Verhalten.

ICCP wird nicht angezeigt, nachdem Sie einen Authentifizierungsschlüssel hinzugefügt oder gelöscht haben

Problem

Beschreibung

Die ICCP-Verbindung (Inter-Chassis Control Protocol) wird nicht hergestellt, wenn Sie einen Authentifizierungsschlüssel hinzufügen und ihn dann nur auf globaler ICCP-Ebene löschen. Die Authentifizierung funktioniert jedoch auf ICCP-Peer-Ebene ordnungsgemäß.

Lösung

Löschen Sie die ICCP-Konfiguration, und fügen Sie dann die ICCP-Konfiguration hinzu.

Der lokale Status ist Standby, wenn er aktiv sein sollte

Problem

Beschreibung

Wenn die Multichassis-aggregierte Ethernet-Schnittstelle ausgefallen ist, während sich der Zustandsautomat in einem synchronisierten Zustand befindet, ist die Multichassis-Link-Aggregationsgruppe (MC-LAG) Peer lokalen Status Standby. Wenn die aggregierte Multichassis-Ethernet-Schnittstelle ausfällt, nachdem sich der Zustandscomputer in einem aktiven Zustand befindet, bleibt der lokale Status aktiv, und der lokale Status zeigt an, dass die Schnittstelle ausgefallen ist.

Lösung

Dies ist ein erwartetes Verhalten.

Paketschleife auf dem Server, wenn ICCP fehlschlägt

Problem

Beschreibung

Wenn Sie die Backup-Liveness-Erkennung für eine Multichassis-Link-Aggregationsgruppe (MC-LAG) aktivieren und die Backup-Liveness-Detection-Pakete aufgrund eines vorübergehenden Fehlers in der MC-LAG verloren gehen, bleiben beide Peers in der MC-LAG aktiv. In diesem Fall senden beide MC-LAG-Peers Pakete an den verbundenen Server.

Lösung

Dies ist ein erwartetes Verhalten.

Beide MC-LAG-Peers verwenden nach einem Neustart oder einer ICCP-Konfigurationsänderung die Standardsystem-ID

Problem

Beschreibung

Nach einem Neustart oder nachdem eine neue ICCP-Konfiguration (Inter-Chassis Control Protocol) festgelegt wurde und die ICCP-Verbindung nicht aktiv wird, verwenden die LACP-Nachrichten (Link Aggregation Control Protocol), die über die aggregierten Multichassis-Ethernet-Schnittstellen übertragen werden, die Standardsystem-ID. Die konfigurierte System-ID wird anstelle der Standard-System-ID erst verwendet, nachdem die MC-LAG-Peers miteinander synchronisiert wurden.

Lösung

Dies ist ein erwartetes Verhalten.

Für ICL-PL-Schnittstellen werden keine Commit-Prüfungen durchgeführt

Problem

Beschreibung

Es gibt keine Commit-Prüfungen für die Schnittstelle, die als Interchassis Link Protection Link (ICL-PL) konfiguriert wird, daher müssen Sie einen gültigen Schnittstellennamen für ICL-PL angeben.

Lösung

Dies ist ein erwartetes Verhalten.

Szenario für doppeltes Failover

Problem

Beschreibung

Wenn die folgenden Ereignisse in genau dieser Reihenfolge eintreten – Inter-Chassis Control Protocol (ICCP) fällt aus und die aggregierte Multichassis-Ethernet-Schnittstelle auf dem MC-LAG-Peer (Multichassis Link Aggregation Group) im aktiven Modus fällt aus – erfolgt ein doppeltes Failover. In diesem Szenario erkennt der MC-LAG-Peer im Standby-Modus nicht, was auf dem aktiven MC-LAG-Peer passiert. Der MC-LAG-Peer im Standby-Modus arbeitet so, als ob die aggregierte Multichassis-Ethernet-Schnittstelle auf der MC-LAG im aktiven Modus aktiv wäre, und blockiert den ICL-PL-Datenverkehr (Interchassis Link Protection). Der ICL-PL-Datenverkehr wird nicht weitergeleitet.

Lösung

Dies ist ein erwartetes Verhalten.

Multicast-Datenverkehr überflutet das VLAN, wenn die ICL-PL-Schnittstelle ab- und ansteigt

Problem

Beschreibung

Wenn der Interchassis Link Protection Link (ICL-PL) ausfällt und hochgefahren wird, wird der Multicast-Datenverkehr an alle Schnittstellen im VLAN geflutet. Das Packet Forwarding Engine-Flag Ip4McastFloodMode für das VLAN wird in MCAST_FLOOD_ALL geändert. Dieses Problem tritt nur auf, wenn eine Multichassis Link Aggregation Group (MC-LAG) für Layer 2 konfiguriert ist.

Lösung

Dies ist ein erwartetes Verhalten.

Layer-3-Datenverkehr, der an den Standby-MC-LAG-Peer gesendet wird, wird nicht an den aktiven MC-LAG-Peer umgeleitet

Problem

Beschreibung

Wenn das Inter-chassis Control Protocol (ICCP) ausgefallen ist, ist der Status eines entfernten MC-LAG-Peers unbekannt. Selbst wenn der MC-LAG-Peer als Standby konfiguriert ist, wird der Datenverkehr nicht zu diesem Peer umgeleitet, da davon ausgegangen wird, dass dieser Peer ausgefallen ist.

Lösung

Dies ist ein erwartetes Verhalten.

Aggregierte Ethernet-Schnittstellen fallen aus

Problem

Beschreibung

Wenn eine aggregierte Multichassis-Ethernet-Schnittstelle in eine aggregierte Ethernet-Schnittstelle konvertiert wird, behält sie einige Eigenschaften der aggregierten Multichassis-Ethernet-Schnittstelle bei. Beispielsweise kann die aggregierte Ethernet-Schnittstelle den administrativen Schlüssel der aggregierten Multichassis-Ethernet-Schnittstelle beibehalten. In diesem Fall fällt die aggregierte Ethernet-Schnittstelle aus.

Lösung

Starten Sie das Link Aggregation Control Protocol (LACP) auf dem MC-LAG-Peer (Multichassis Link Aggregation Group) neu, der die aggregierte Ethernet-Schnittstelle hostet, um die aggregierte Ethernet-Schnittstelle aufzurufen. Durch einen Neustart von LACP werden die aggregierten Multichassis-Ethernet-Eigenschaften der aggregierten Ethernet-Schnittstelle entfernt.

Überflutung von Upstream-Datenverkehr

Problem

Beschreibung

Wenn die MAC-Synchronisierung aktiviert ist, kann der MC-LAG-Peer (Multichassis Link Aggregation Group) ARP-Einträge (Address Resolution Protocol) für die MC-LAG-Routed VLAN Interface (RVI) mit einer der MC-LAG-Peer-MAC-Adressen auflösen. Wenn der Downstream-Datenverkehr mit einer MAC-Adresse (MAC1) gesendet wird, der Peer die MAC-Adresse jedoch mit einer anderen MAC-Adresse (MAC2) aufgelöst hat, wird die MAC2-Adresse möglicherweise von keinem der Switches der Zugriffsebene gelernt. Daraufhin kann es zu einer Überflutung des Upstreamdatenverkehrs für die MAC2-Adresse kommen.

Lösung

Stellen Sie sicher, dass der Downstream-Datenverkehr regelmäßig von den MC-LAG-Peers gesendet wird, um zu verhindern, dass die MAC-Adressen veraltet sind.

ARP- und MAC-Tabelleneinträge sind in einer MC-LAG-Konfiguration nicht mehr synchron

Problem

Beschreibung

Die ARP- und MAC-Adressen-Tabellen in einer MC-LAG-Konfiguration bleiben normalerweise synchronisiert, aber Aktualisierungen können in extremen Situationen verloren gehen, wenn Tabellenaktualisierungen sehr häufig erfolgen, z. B. wenn Link-Flapping in einer MC-LAG-Gruppe auftritt.

Lösung

Um zu vermeiden, dass ARP- und MAC-Einträge in einer MC-LAG-Konfiguration nicht mehr synchron sind, können Sie die Option arp-l2-validate auf der IRB-Schnittstelle des Switches wie folgt konfigurieren:

Diese arp-l2-validate Option ist nur für Switches der QFX-Serie verfügbar.

Diese Option aktiviert die Validierung von ARP- und MAC-Tabelleneinträgen und wendet automatisch Aktualisierungen an, wenn sie nicht mehr synchron sind. Sie können diese Option als Problemumgehung aktivieren, wenn im Netzwerk andere Probleme auftreten, die ebenfalls zum Verlust der ARP- und MAC-Synchronisierung führen, aber sie während des normalen Betriebs deaktivieren, da diese Option die Leistung in skalierten Konfigurationen beeinträchtigen kann.