Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Aggregierte Ethernet-Schnittstellen

In den folgenden Themen werden die Übersicht über aggregierte Ethernet-Schnittstellen, Konfigurationsdetails der Link-Aggregation und aggregierter Ethernet-Schnittstellen, Fehlerbehebung und Überprüfung von aggregierten Ethernet-Schnittstellen erläutert.

Grundlegendes zu aggregierten Ethernet-Schnittstellen und LACP für Switches

Mit IEEE 802.3ad Link Aggregation können Sie Ethernet-Schnittstellen zu einer einzigen Link-Layer-Schnittstelle gruppieren, die auch als Link Aggregation Group (LAG) oder Bundle bezeichnet wird.

Durch die Aggregation mehrerer Verbindungen zwischen physischen Schnittstellen entsteht eine einzige logische Punkt-zu-Punkt-Trunk-Verbindung oder eine LAG. Die LAG gleicht den Datenverkehr über die Mitgliedsverbindungen innerhalb eines aggregierten Ethernet-Pakets aus und erhöht effektiv die Uplink-Bandbreite. Ein weiterer Vorteil der Link-Aggregation ist die erhöhte Verfügbarkeit, da die LAG aus mehreren Mitglieds-Links besteht. Wenn eine Mitgliedsverbindung ausfällt, überträgt die LAG weiterhin Datenverkehr über die verbleibenden Verbindungen.

Hinweis:

Auf QFX5100-, QFX5120-, EX4600- QFX10002 Standalone-Switches sowie auf einem QFX5100 Virtual Chassis und EX4600 Virtual Chassis können Sie eine gemischte Rate von Verbindungsgeschwindigkeiten für das aggregierte Ethernet-Bundle konfigurieren. Verbindungsgeschwindigkeiten von 10G, 40G und 100G werden unterstützt. QFX5200- und QFX5210-Switches unterstützen Mixed-Link-Geschwindigkeiten. QFX5200- und QFX5210-Switches unterstützen mit den Mixed-Link-Geschwindigkeiten auch das Load Balancing. Der Lastenausgleich funktioniert nicht, wenn Sie Verbindungsgeschwindigkeiten konfigurieren, die nicht unterstützt werden.
Hinweis:

Sie können Port-Channel mit unterschiedlichen SFP-Modellen zwischen zwei Endpunkten konfigurieren, wobei die gleiche Bandbreite beibehalten wird.

Zum Beispiel:

switch 1 gig0/1 (SFP-10G-SR-S) --------- MX 1 gig0/1 (SFP-10G-SR-S)

switch 1 gig0/2 (SFP-10G-LR-S) --------- MX 1 gig0/2 (SFP-10G-LR-S)

Das Link Aggregation Control Protocol (LACP) ist eine Unterkomponente des IEEE 802.3ad-Standards und wird als Erkennungsprotokoll verwendet.

Hinweis:

Um den Lastenausgleich über die aggregierten Ethernet-Schnittstellen (AE) in einer redundanten Serverknotengruppe sicherzustellen, müssen die Mitglieder der AE gleichmäßig auf die redundante Serverknotengruppe verteilt werden.
Hinweis:

Während eines Netzwerkknotengruppen-Switchovers kann der Datenverkehr für einige Sekunden unterbrochen werden.

Link-Aggregationsgruppe

Sie konfigurieren eine LAG, indem Sie die Verbindungsnummer als physisches Gerät angeben und dann der Verbindung eine Reihe von Schnittstellen (Ports) zuordnen. Alle Schnittstellen müssen die gleiche Geschwindigkeit haben und sich im Vollduplex-Modus befinden. Das Betriebssystem Junos (Junos OS) von Juniper Networks für Ethernet-Switches der EX-Serie weist jeder Schnittstelle eine eindeutige ID und Portpriorität zu. Die ID und die Priorität sind nicht konfigurierbar.

Die Anzahl der Schnittstellen, die in einer LAG gruppiert werden können, und die Gesamtzahl der LAGs, die auf einem Switch unterstützt werden, variieren je nach Switch-Modell. Tabelle 1 listet die Switches der EX-Serie sowie die maximale Anzahl von Schnittstellen pro LAG und die maximale Anzahl der unterstützten LAGs auf.

LAGs mit Member-Links unterschiedlicher Schnittstellentypen, z. B. ge und mge, werden auf Multirate-Switches nicht unterstützt.

Hinweis:

Für Junos OS Evolved legt die Software keine Begrenzung für die maximale Anzahl von AE-Schnittstellen in einem AE-Paket mit gemischter Rate fest. Da alle untergeordneten logischen Schnittstellen zur gleichen physischen AE-Schnittstelle gehören und denselben Selektor verwenden und viel weniger Lastausgleichsspeicher verwenden, sollten AE-Schnittstellenkonfigurationen mit gemischter Rate auch dann durchgeführt werden, wenn sie 64 logische Schnittstellen überschreiten.

Tabelle 1: Maximale Schnittstellen pro LAG und maximale LAGs pro Switch (Switches der EX-Serie)

Wechseln

Maximale Anzahl an Schnittstellen pro LAG

Maximale LAGs

EX2200

8

32

EX2300

8

128

EX3200

8

32

EX3300 und EX3300 Virtual Chassis

8

32

EX3400

16

128

Virtuelles Chassis EX4200 und EX4200

8

111

EX4300 und EX4300 Virtual Chassis

16

128

Virtuelles Chassis EX4500, EX4500, EX4550 und EX4550

8

111
EX4400 16 128

EX4600

32

128

EX6200

8

111

EX8200

12

255

EX8200 Virtual Chassis

12

239

EX9200

64

150
Tabelle 2: Maximale Schnittstellen pro LAG und maximale LAGs pro Switch (Switches der QFX-Serie)

Wechseln

Maximale Anzahl an Schnittstellen pro LAG

Maximale LAGs

QFX3500

64

60

QFX3600

64

60

QFX5100

64

96

QFX5110

64

96

QFX5120

64

72

QFX5200

64

128

QFX5700

128

144

QFX10002

64

150

QFX10008

64

1000

QFX10016

64

1000
Hinweis:

Wenn Sie auf Switches der QFX-Serie versuchen, eine Konfiguration mit mehr als 64 Ethernet-Schnittstellen in einer LAG festzuschreiben, erhalten Sie eine Fehlermeldung, die besagt, dass das Gruppenlimit von 64 überschritten wurde und das Auschecken der Konfiguration fehlgeschlagen ist.

So erstellen Sie eine LAG:

  1. Erstellen Sie eine logische, aggregierte Ethernet-Schnittstelle.

  2. Definieren Sie die Parameter, die der logisch aggregierten Ethernet-Schnittstelle zugeordnet sind, z. B. eine logische Einheit, Schnittstelleneigenschaften und LACP (Link Aggregation Control Protocol).

  3. Definieren Sie die Mitgliedsverknüpfungen, die in der aggregierten Ethernet-Schnittstelle enthalten sein sollen, z. B. zwei 10-Gigabit-Ethernet-Schnittstellen.

  4. Konfigurieren Sie LACP für die Linkerkennung.

Beachten Sie die folgenden Hardware- und Softwarerichtlinien:

  • Wenn für Junos OS Evolved eine neue Schnittstelle als Mitglied zum aggregierten Ethernet-Bundle hinzugefügt wird, wird ein Link Flap-Ereignis generiert. Wenn Sie dem Bundle eine Schnittstelle hinzufügen, wird die physische Schnittstelle als reguläre Schnittstelle gelöscht und dann wieder als Mitglied hinzugefügt. Während dieser Zeit gehen die Details der physischen Schnittstelle verloren.

  • Bis zu 32 Ethernet-Schnittstellen können gruppiert werden, um eine LAG auf einer redundanten Server-Node-Gruppe, einer Server-Node-Gruppe und einer Netzwerk-Node-Gruppe auf einem QFabric-System zu bilden. Bis zu 48 LAGs werden auf redundanten Server-Node-Gruppen und Server-Node-Gruppen auf einem QFabric-System unterstützt, und bis zu 128 LAGs werden auf Netzwerk-Node-Gruppen auf einem QFabric-System unterstützt. Sie können LAGs für alle Node-Geräte in redundanten Server-Node-Gruppen, Server-Node-Gruppen und Netzwerk-Node-Gruppen konfigurieren.

    Hinweis:

    Wenn Sie auf einem Qfabric-System versuchen, eine Konfiguration mit mehr als 32 Ethernet-Schnittstellen in einer LAG zu bestätigen, erhalten Sie eine Fehlermeldung, die besagt, dass das Gruppenlimit von 32 überschritten wurde und das Auschecken der Konfiguration fehlgeschlagen ist.

  • Bis zu 64 Ethernet-Schnittstellen können zu einer LAG zusammengefasst werden, und in einer Junos Fusion werden bis zu 1.000 LAGs auf QFX10002 Switches unterstützt, die als Aggregationsgeräte fungieren.

  • Die LAG muss auf beiden Seiten der Verbindung konfiguriert werden.

  • Die Schnittstellen auf beiden Seiten der Verbindung müssen auf die gleiche Geschwindigkeit eingestellt sein und sich im Vollduplexmodus befinden.

    Hinweis:

    Junos OS weist jedem Port eine eindeutige ID und Portpriorität zu. Die ID und die Priorität sind nicht konfigurierbar.

  • QFabric-Systeme unterstützen eine spezielle LAG, die als FCoE-LAG bezeichnet wird und es Ihnen ermöglicht, FCoE-Datenverkehr und regulären Ethernet-Datenverkehr (Datenverkehr, der kein FCoE-Datenverkehr ist) über dasselbe Link-Aggregationspaket zu transportieren. Standard-LAGs verwenden einen Hashing-Algorithmus, um zu bestimmen, welche physische Verbindung in der LAG für eine Übertragung verwendet wird, sodass für die Kommunikation zwischen zwei Geräten möglicherweise unterschiedliche physische Verbindungen in der LAG für unterschiedliche Übertragungen verwendet werden. Eine FCoE-LAG stellt sicher, dass der FCoE-Datenverkehr für Anfragen und Antworten dieselbe physische Verbindung in der LAG verwendet, um die virtuelle Punkt-zu-Punkt-Verbindung zwischen dem konvergenten Netzwerkadapter (CNA) des FCoE-Geräts und dem FC-SAN-Switch über ein QFabric-Systemknotengerät hinweg beizubehalten. Eine FCoE-LAG bietet weder Lastausgleich noch Verbindungsredundanz für FCoE-Datenverkehr. Regulärer Ethernet-Datenverkehr verwendet jedoch den Standard-Hashing-Algorithmus und erhält die üblichen LAG-Vorteile von Load Balancing und Link-Redundanz in einer FCoE-LAG. Weitere Informationen finden Sie unter Grundlegendes zu FCoE-LAGs .

Link Aggregation Control Protocol (LACP)

LACP ist eine Methode, bei der mehrere physische Schnittstellen zu einer logisch aggregierten Ethernet-Schnittstelle gebündelt werden. Standardmäßig tauschen Ethernet-Verbindungen keine LACP-Protokolldateneinheiten (PDUs) aus, die Informationen über den Status der Verbindung enthalten. Sie können Ethernet-Verbindungen so konfigurieren, dass sie LACP-PDUs aktiv übertragen, oder Sie können die Verbindungen so konfigurieren, dass sie sie passiv übertragen und LACP-PDUs nur dann senden, wenn die Ethernet-Verbindung sie vom Remote-Ende empfängt. Der LACP-Modus kann aktiv oder passiv sein. Die sendende Verbindung wird als Akteur und die empfangende Verbindung als Partner bezeichnet. Wenn sich sowohl der Akteur als auch der Partner im passiven Modus befinden, tauschen sie keine LACP-Pakete aus, und die aggregierten Ethernet-Verbindungen werden nicht hergestellt. Wenn entweder der Akteur oder der Partner aktiv ist, tauschen sie LACP-Pakete aus. Standardmäßig befindet sich LACP bei aggregierten Ethernet-Schnittstellen im passiven Modus. Um die Übertragung von LACP-Paketen und die Antwort auf LACP-Pakete zu initiieren, müssen Sie den aktiven LACP-Modus aktivieren. Sie können sowohl VLAN-getaggte als auch nicht getaggte aggregierte Ethernet-Schnittstellen konfigurieren, ohne dass LACP aktiviert ist. LACP ist in IEEE 802.3ad, definiert. Aggregation of Multiple Link Segments

LACP wurde entwickelt, um Folgendes zu erreichen:

  • Automatisches Hinzufügen und Löschen einzelner Links zur LAG ohne Benutzereingriff.

  • Link-Überwachung, um zu überprüfen, ob beide Enden des Bundles mit der richtigen Gruppe verbunden sind.

In einem Szenario, in dem ein Dual-Homed-Server mit einem Switch bereitgestellt wird, bilden die Netzwerkschnittstellenkarten zusammen mit dem Switch eine LAG. Während eines Serverupgrades kann der Server möglicherweise keine LACP-PDUs austauschen. In einer solchen Situation können Sie eine Schnittstelle so konfigurieren, dass sie up sich auch dann im Status befindet, wenn keine PDUs ausgetauscht werden. Verwenden Sie die Anweisung force-up , um eine Schnittstelle zu konfigurieren, wenn der Peer über eine eingeschränkte LACP-Funktion verfügt. Die Schnittstelle wählt standardmäßig die zugehörige LAG aus, unabhängig davon, ob sich Switch und Peer im aktiven oder passiven Modus befinden. Wenn keine PDUs empfangen werden, wird davon ausgegangen, dass der Partner im passiven Modus arbeitet. Daher werden LACP-PDU-Übertragungen über die Sendeverbindung gesteuert.

Wenn es sich bei dem Remote-Ende der LAG-Verbindung um ein Sicherheitsgerät handelt, wird LACP möglicherweise nicht unterstützt, da Sicherheitsgeräte eine deterministische Konfiguration erfordern. Konfigurieren Sie in diesem Fall LACP nicht. Alle Verbindungen in der LAG sind permanent betriebsbereit, es sei denn, der Switch erkennt einen Verbindungsausfall innerhalb der physikalischen Ethernet-Schicht oder der Datenverbindungsschicht.

Wenn LACP konfiguriert ist, erkennt es Fehlkonfigurationen am lokalen oder entfernten Ende der Verbindung. Somit kann LACP dazu beitragen, Kommunikationsfehler zu vermeiden:

  • Wenn LACP nicht aktiviert ist, versucht eine lokale LAG möglicherweise, Pakete an eine einzelne Remoteschnittstelle zu übertragen, wodurch die Kommunikation fehlschlägt.

  • Wenn LACP aktiviert ist, kann eine lokale LAG keine Pakete übertragen, es sei denn, am Remote-Ende der Verbindung ist auch eine LAG mit LACP konfiguriert.

Siehe auch

Konfigurieren einer aggregierten Ethernet-Schnittstelle

Sie können eine physische Schnittstelle mit einer aggregierten Ethernet-Schnittstelle verknüpfen.

So konfigurieren Sie eine aggregierte Ethernet-Schnittstelle:

  1. Geben Sie an, dass Sie die Link-Aggregationsgruppen-Schnittstelle konfigurieren möchten.
  2. Konfigurieren Sie die aggregierte Ethernet-Schnittstelle.

Sie geben die Nummer x der Schnittstelleninstanz an, um die Verknüpfungszuordnung abzuschließen. Sie müssen auch eine Anweisung einfügen, die auf der [edit interfaces] Hierarchieebene definiertaex. Optional können Sie weitere physikalische Eigenschaften angeben, die speziell für die aggregierten Ethernet-Schnittstellen gelten. Weitere Informationen finden Sie unter Übersicht über Ethernet-Schnittstellen.

Hinweis:

Im Allgemeinen unterstützen aggregierte Ethernet-Bundles die Funktionen, die auf allen unterstützten Schnittstellen verfügbar sind, die zu einem Member-Link innerhalb des Bundles werden können. Ausnahmsweise werden Gigabit Ethernet IQ-Funktionen und einige neuere Gigabit-Ethernet-Funktionen in aggregierten Ethernet-Paketen nicht unterstützt.

Gigabit Ethernet IQ- und SFP-Schnittstellen können Member-Links sein, aber IQ- und SFP-spezifische Features werden im aggregierten Ethernet-Bundle nicht unterstützt, selbst wenn alle Member-Links diese Features einzeln unterstützen.

Sie müssen die richtige Verbindungsgeschwindigkeit für die aggregierte Ethernet-Schnittstelle konfigurieren, um Warnmeldungen zu vermeiden.
Hinweis:

Bevor Sie eine aggregierte Ethernet-Konfiguration festschreiben, stellen Sie sicher, dass der Verbindungsmodus auf keiner Mitgliedsschnittstelle des aggregierten Ethernet-Pakets konfiguriert ist. Andernfalls schlägt die Überprüfung des Konfigurationscommits fehl.

Siehe auch

Konfigurieren von Tagged Aggregated Ethernet-Schnittstellen

Um aggregierte Ethernet-Schnittstellen anzugeben, fügen Sie die vlan-tagging Anweisung auf Hierarchieebene [edit interfaces aex] ein:

Sie müssen auch die vlan-id folgende Erklärung angeben:

Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:

  • [edit interfaces interface-name unit logical-unit-number]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]

Weitere Informationen zu den und-Anweisungen vlan-id finden Sie unter Übersicht über 802.1Q-VLANsvlan-tagging.

Siehe auch

Konfigurieren von aggregierten Ethernet-Schnittstellen ohne Tags

Wenn Sie eine nicht getaggte aggregierte Ethernet-Schnittstelle konfigurieren, gelten die vorhandenen Regeln für nicht getaggte Schnittstellen. Diese Regeln lauten wie folgt:

  • Sie können nur eine logische Schnittstelle (Einheit 0) auf dem Port konfigurieren. Die logische Einheit 0 dient zum Senden und Empfangen von LACP- oder Marker Protocol Data Units (PDUs) von und zu den einzelnen Verbindungen.

  • Sie können die vlan-id Anweisung nicht in die Konfiguration der logischen Schnittstelle einbeziehen.

Konfigurieren Sie eine aggregierte Ethernet-Schnittstelle ohne Tags, indem Sie dievlan-tagging und-Anweisungen vlan-id aus der Konfiguration weglassen:

Siehe auch

Konfigurieren der Anzahl der aggregierten Ethernet-Schnittstellen auf dem Gerät (erweiterte Layer-2-Software)

Standardmäßig werden keine aggregierten Ethernet-Schnittstellen erstellt. Sie müssen die Anzahl der aggregierten Ethernet-Schnittstellen auf dem Routinggerät festlegen, bevor Sie sie konfigurieren können.

  1. Geben Sie an, dass Sie auf die aggregierte Ethernet-Konfiguration auf dem Gerät zugreifen möchten.
  2. Legen Sie die Anzahl der aggregierten Ethernet-Schnittstellen fest.

Sie müssen auch die konstituierenden physischen Verknüpfungen angeben, indem Sie die 802.3ad Anweisung auf der [edit interfaces interface-name ether-options] Hierarchieebene einschließen.

Siehe auch

Beispiel: Konfigurieren von aggregierten Ethernet-Schnittstellen

Aggregierte Ethernet-Schnittstellen können Schnittstellen von verschiedenen FPCs, DPCs oder PICs verwenden. Die folgende Konfiguration ist ausreichend, um eine aggregierte Gigabit-Ethernet-Schnittstelle zum Laufen zu bringen.

Siehe auch

Löschen einer aggregierten Ethernet-Schnittstelle

Es gibt zwei Ansätze zum Löschen einer aggregierten Ethernet-Schnittstelle:

  • Sie können eine aggregierte Ethernet-Schnittstelle aus der Schnittstellenkonfiguration löschen. Das Junos-Betriebssystem entfernt die Konfigurationsanweisungen, die sich auf diese Schnittstelle beziehen, aex und setzt sie auf den Status "Nicht verfügbar".

  • Sie können die aggregierte Ethernet-Schnittstelle auch dauerhaft aus der Gerätekonfiguration entfernen, indem Sie sie aus der Geräteanzahl auf dem Routing-Gerät löschen.

So löschen Sie eine aggregierte Ethernet-Schnittstelle:

  1. Löschen Sie die aggregierte Ethernet-Konfiguration.

    In diesem Schritt wird der Schnittstellenstatus in "down" geändert, und die Konfigurationsanweisungen werden im Zusammenhang mit aex.

  2. Löschen Sie die Schnittstelle aus der Geräteanzahl.

Siehe auch

Fehlerbehebung bei einer aggregierten Ethernet-Schnittstelle

Fehlerbehebung bei aggregierten Ethernet-Schnittstellen:

Der Befehl "Schnittstellen anzeigen" zeigt an, dass die LAG ausgefallen ist

Problem

Beschreibung

Der show interfaces terse Befehl zeigt an, dass die LAG ausgefallen ist.

Lösung

Überprüfen Sie Folgendes:

  • Stellen Sie sicher, dass kein Konfigurationskonflikt vorliegt.

  • Stellen Sie sicher, dass alle Mitgliedsports aktiv sind.

  • Stellen Sie sicher, dass eine LAG Teil der Ethernet-Familie (Layer 2 LAG) oder der Familie inet (Layer 3 LAG) ist.

  • Stellen Sie sicher, dass das LAG-Element mit der richtigen LAG am anderen Ende verbunden ist.

  • Stellen Sie sicher, dass die LAG-Mitglieder zum selben Switch (oder zum gleichen Virtual Chassis) gehören.

Statistiken über logische Schnittstellen spiegeln nicht den gesamten Datenverkehr wider

Problem

Beschreibung

Die Datenverkehrsstatistiken für eine logische Schnittstelle enthalten nicht den gesamten Datenverkehr.

Lösung

Datenverkehrsstatistikfelder für logische Schnittstellen in show interfaces Befehlen zeigen nur Steuerungsdatenverkehr an; die Datenverkehrsstatistiken enthalten keinen Datenverkehr. Sie können die Statistiken für den gesamten Datenverkehr nur pro physischer Schnittstelle anzeigen.

IPv6-Schnittstellendatenverkehrsstatistiken werden nicht unterstützt

Problem

Beschreibung

Die IPv6 transit statistics im show interfaces Befehl zeigen alle 0 Werte an.

Lösung

Switches der EX-Serie unterstützen die Erfassung und Berichterstellung von IPv6-Transitstatistiken nicht.

SNMP-Zähler ifHCInBroadcastPkts und ifInBroadcastPkts sind immer 0

Problem

Beschreibung

Die Werte für die SNMP-Zähler ifHCInBroadcastPkts und ifInBroadcastPkts sind immer 0.

Lösung

Die SNMP-Zähler ifHCInBroadcastPkts und ifInBroadcastPkts werden für aggregierte Ethernet-Schnittstellen auf Switches der EX-Serie nicht unterstützt.

Siehe auch

Konfigurieren des periodischen Rebalancing von Teilnehmern in einer aggregierten Ethernet-Schnittstelle

Wenn sich Abonnenten häufig in Ihrem Netzwerk an- und abmelden, können Sie das System so konfigurieren, dass die Verbindungen basierend auf einer bestimmten Zeit und einem bestimmten Intervall regelmäßig neu verteilt werden.

So konfigurieren Sie ein regelmäßiges Rebalancing:

  1. Greifen Sie auf die aggregierte Ethernet-Schnittstelle zu, für die Sie ein regelmäßiges Rebalancing konfigurieren möchten.
  2. Konfigurieren Sie die Rebalancing-Parameter für die Schnittstelle, einschließlich der Zeit und des Intervalls zwischen Rebalancing-Aktionen.

Siehe auch

Konfigurieren von aggregiertem Ethernet-LACP

Für aggregierte Ethernet-Schnittstellen können Sie das Link Aggregation Control Protocol (LACP) konfigurieren. LACP ist eine Methode, um mehrere physische Schnittstellen zu einer logischen Schnittstelle zu bündeln. Sie können sowohl VLAN-Tagged als auch Untagged Aggregated Ethernet mit oder ohne aktiviertem LACP konfigurieren.

Für Multichassis Link Aggregation (MC-LAG) müssen Sie das und admin keyangeben.system-id MC-LAG-Peers verwenden dasselbe system-id beim Senden der LACP-Nachrichten. Sie system-id können auf dem MC-LAG-Netzwerkgerät konfiguriert und zur Validierung zwischen den Peers synchronisiert werden.

Im Rahmen des LACP findet ein Austausch zwischen Akteuren und Partnern statt. Ein Akteur ist die lokale Schnittstelle in einem LACP-Austausch. Ein Partner ist die Remoteschnittstelle in einem LACP-Austausch.

LACP ist in IEEE 802.3ad ( Aggregation of Multiple Link Segments) definiert.

LACP wurde entwickelt, um Folgendes zu erreichen:

  • Automatisches Hinzufügen und Löschen einzelner Links zum Aggregat-Bundle ohne Benutzereingriff

  • Linküberwachung, um zu überprüfen, ob beide Enden des Bundles mit der richtigen Gruppe verbunden sind

Die Junos OS-Implementierung von LACP bietet Verbindungsüberwachung, aber kein automatisches Hinzufügen und Löschen von Verbindungen.

Der LACP-Modus kann aktiv oder passiv sein. Wenn sich sowohl der Akteur als auch der Partner im passiven Modus befinden, tauschen sie keine LACP-Pakete aus, was dazu führt, dass die aggregierten Ethernet-Verbindungen nicht hergestellt werden. Wenn entweder der Akteur oder der Partner aktiv ist, tauschen sie LACP-Pakete aus. Standardmäßig ist LACP für aggregierte Ethernet-Schnittstellen deaktiviert. Wenn LACP konfiguriert ist, befindet es sich standardmäßig im passiven Modus. Um die Übertragung von LACP-Paketen und die Antwort auf LACP-Pakete zu initiieren, müssen Sie LACP im aktiven Modus konfigurieren.

Um den aktiven LACP-Modus zu aktivieren, fügen Sie die lacp Anweisung auf Hierarchieebene [edit interfaces interface-name aggregated-ether-options] ein, und geben Sie die active folgende Option an:

Hinweis:

Der LACP-Prozess ist im System nur vorhanden, wenn Sie das System entweder im aktiven oder passiven LACP-Modus konfigurieren.

Um das Standardverhalten wiederherzustellen, schließen Sie die lacp Anweisung auf Hierarchieebene [edit interfaces interface-name aggregated-ether-options] ein, und geben Sie die passive folgende Option an:

Ab Junos OS Version 12.2 können Sie LACP auch so konfigurieren, dass der IEEE 802.3ad-Standard außer Kraft gesetzt wird und die Standby-Verbindung immer Datenverkehr empfangen kann. Das Überschreiben des Standardverhaltens erleichtert das Failover in Sekundenbruchteilen.

Um den IEEE 802.3ad-Standard außer Kraft zu setzen und ein Failover von unter einer Sekunde zu ermöglichen, fügen Sie die fast-failover Anweisung auf Hierarchieebene [edit interfaces interface-name aggregated-ether-options lacp] ein.

Weitere Informationen finden Sie in den folgenden Abschnitten:

Konfigurieren des LACP-Intervalls

Standardmäßig senden der Akteur und der Partner jede Sekunde LACP-Pakete. Sie können das Intervall konfigurieren, in dem die Schnittstellen LACP-Pakete senden, indem Sie die periodic Anweisung auf Hierarchieebene [edit interfaces interface-name aggregated-ether-options lacp] einfügen:

Das Intervall kann schnell (jede Sekunde) oder langsam (alle 30 Sekunden) sein. Sie können unterschiedliche periodische Raten für aktive und passive Schnittstellen konfigurieren. Wenn Sie die aktiven und passiven Schnittstellen mit unterschiedlichen Raten konfigurieren, berücksichtigt der Sender die Rate des Empfängers.

Hinweis:

Das Filtern von Quelladressen funktioniert nicht, wenn LACP aktiviert ist.

Prozentuale Policer werden auf aggregierten Ethernet-Schnittstellen mit konfigurierter CCC-Protokollfamilie nicht unterstützt. Weitere Informationen zu prozentualen Policern finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Traffic Policers.

Im Allgemeinen wird LACP auf allen nicht getaggten aggregierten Ethernet-Schnittstellen unterstützt. Weitere Informationen finden Sie unter Konfigurieren von aggregierten Ethernet-Schnittstellen ohne Tags.

Konfigurieren des LACP-Verbindungsschutzes

Hinweis:

Wenn Sie den LACP-Link-Schutz verwenden, können Sie nur zwei Mitgliedsverbindungen zu einer aggregierten Ethernet-Schnittstelle konfigurieren: eine aktive und eine Standby-Schnittstelle.

Um aktive und Standby-Verbindungen innerhalb eines aggregierten Ethernets zu erzwingen, können Sie den LACP-Link-Schutz und die Systempriorität auf der Ebene der aggregierten Ethernet-Schnittstelle mithilfe der link-protection and-Anweisungen system-priority konfigurieren. Die Konfiguration von Werten auf dieser Ebene führt dazu, dass nur die konfigurierten Schnittstellen die definierte Konfiguration verwenden. Mit der LACP-Schnittstellenkonfiguration können Sie auch globale (Chassis-)LACP-Einstellungen außer Kraft setzen.

Der LACP-Verbindungsschutz verwendet ebenfalls die Portpriorität. Sie können die Portpriorität auf der Hierarchieebene der Ethernet-Schnittstelle [ether-options] konfigurieren, indem Sie die port-priority Anweisung verwenden. Wenn Sie keine Portpriorität konfigurieren möchten, verwendet der LACP-Link-Schutz den Standardwert für die Portpriorität (127).

Hinweis:

Der LACP-Link-Schutz unterstützt die Konfiguration der Planung pro Einheit auf aggregierten Ethernet-Schnittstellen.

Um den LACP-Link-Schutz für aggregierte Ethernet-Schnittstellen zu aktivieren, verwenden Sie die folgende link-protection Anweisung auf Hierarchieebene [edit interfaces aeX aggregated-ether-options lacp] :

Standardmäßig wird der LACP-Link-Schutz auf einen Link mit höherer Priorität (niedriger Nummer) zurückgesetzt, wenn dieser Link mit höherer Priorität in Betrieb genommen wird oder ein Link zum Aggregator hinzugefügt wird, der eine höhere Priorität hat. Sie können die Verknüpfungsberechnung jedoch unterdrücken, indem Sie die non-revertive Anweisung zur LACP-Verbindungsschutzkonfiguration hinzufügen. Im nicht-revertiven Modus führt das anschließende Hinzufügen einer (besseren) Verbindung mit höherer Priorität nicht zu einem Switch, sobald eine Verbindung aktiv ist und Pakete sammelt und verteilt, und die aktuelle Verbindung bleibt aktiv.

Wenn der LACP-Link-Schutz auf globaler Ebene ([edit chassis] Hierarchieebene) so konfiguriert ist, dass er nicht revertiv ist, können Sie die revertive Anweisung zur LACP-Link-Schutzkonfiguration hinzufügen, um die nicht revertive Einstellung für die Schnittstelle zu überschreiben. Im revertiven Modus führt das Hinzufügen eines Links mit höherer Priorität zum Aggregator dazu, dass LACP eine Neuberechnung der Priorität durchführt und vom aktuellen aktiven Link zum neuen aktiven Link wechselt.

VORSICHT:

Wenn an beiden Enden eines Aggregators der LACP-Link-Schutz aktiviert ist, stellen Sie sicher, dass beide Enden des Aggregators für die Verwendung desselben Modus konfiguriert sind. Nicht übereinstimmende LACP-Link-Schutzmodi können zu Datenverkehrsverlusten führen.

Es wird dringend empfohlen, LACP an beiden Enden des Aggregators zu verwenden, wenn Sie eine aggregierte Ethernet-Schnittstelle mit zwei Mitgliedsschnittstellen an ein Gerät eines anderen Herstellers anschließen. Andernfalls ist das Gerät des Herstellers (z. B. ein Layer-2-Switch oder ein Router) nicht in der Lage, den Datenverkehr zu verwalten, der vom aggregierten Ethernet-Bundle mit zwei Verbindungen kommt. Infolgedessen kann es vorkommen, dass das Gerät des Herstellers den Datenverkehr an die Backup-Member-Verbindung der aggregierten Ethernet-Schnittstelle zurücksendet.

Derzeit verwerfen MX-MPC2-3D, MX-MPC2-3D-Q, MX-MPC2-3D-EQ, MX-MPC1-3D, MX-MPC1-3D-Q und MPC-3D-16XGE-SFPP den Datenverkehr, der zur Backup-Verbindung zurückkommt, nicht, während DPCE-R-Q-20GE-2XGE, DPCE-R-Q-20GE-SFP, DPCE-R-Q-40GE-SFP, DPCE-R-Q-4XGE-XFP, DPCE-X-Q-40GE-SFP und DPCE-X-Q-4XGE-XFP den Datenverkehr verwerfen, der zur Backup-Verbindung kommt.

Konfigurieren der LACP-Systempriorität

Um die LACP-Systempriorität für aggregierte Ethernet-Schnittstellen auf der Schnittstelle zu konfigurieren, verwenden Sie die system-priority folgende Anweisung auf Hierarchieebene [edit interfaces aeX aggregated-ether-options lacp] :

Die Systempriorität ist ein 2-Oktett-Binärwert, der Teil der LACP-System-ID ist. Die LACP-System-ID besteht aus der Systempriorität als den beiden höchstwertigen Oktetten und der MAC-Adresse der Schnittstelle als den sechs niederwertigsten Oktetten. Das System mit dem numerisch niedrigeren Wert für die Systempriorität hat die höhere Priorität. Standardmäßig ist die Systempriorität 127 mit einem Bereich von 0 bis 65.535.

Konfigurieren der LACP-Systemkennung

Um die LACP-Systemkennung für aggregierte Ethernet-Schnittstellen zu konfigurieren, verwenden Sie die folgende system-id Anweisung auf Hierarchieebene [edit interfaces aeX aggregated-ether-options lacp] :

Die benutzerdefinierte Systemkennung in LACP ermöglicht es zwei Ports von zwei separaten Geräten, sich so zu verhalten, als wären sie Teil derselben Aggregatgruppe.

Der Systembezeichner ist ein 48-Bit-Feld (6 Byte) global eindeutig. Er wird in Kombination mit einem 16-Bit-Systemprioritätswert verwendet, der zu einer eindeutigen LACP-Systemkennung führt.

Konfigurieren des administrativen LACP-Schlüssels

Um einen administrativen Schlüssel für LACP zu konfigurieren, fügen Sie die admin-key number Anweisung auf Hierarchieebene edit interfaces aex aggregated-ether-options lacp] ein:

Hinweis:

Sie müssen MC-LAG konfigurieren, um die admin-key Anweisung zu konfigurieren. Weitere Informationen zu MC-LAG finden Sie unter Konfigurieren der Multichassis-Link-Aggregation auf Routern der MX-Serie .

Konfigurieren der LACP-Portpriorität

Um die LACP-Portpriorität für aggregierte Ethernet-Schnittstellen zu konfigurieren, verwenden Sie die port-priority Anweisung auf den [edit interfaces interface-name ether-options 802.3ad aeX lacp] Hierarchieebenen oder [edit interfaces interface-name ether-options 802.3ad aeX lacp] :

Die Portpriorität ist ein 2-Oktett-Feld, das Teil der LACP-Port-ID ist. Die LACP-Port-ID setzt sich aus der Portpriorität als den beiden höchstwertigen Oktetten und der Portnummer als den beiden niederwertigsten Oktetten zusammen. Das System mit dem numerisch niedrigeren Wert für die Portpriorität hat die höhere Priorität. Standardmäßig ist die Portpriorität 127 mit einem Bereich von 0 bis 65.535.

Die Auswahl der Portaggregation wird von jedem System auf der Grundlage der höchsten Portpriorität getroffen und vom System mit der höchsten Priorität zugewiesen. Ports werden ausgewählt und zugewiesen, beginnend mit dem Port mit der höchsten Priorität des Systems mit der höchsten Priorität und von dort aus mit der Priorität nach unten arbeiten.

Hinweis:

Die Auswahl der Portaggregation (siehe oben) wird für die aktive Verbindung durchgeführt, wenn der LACP-Link-Schutz aktiviert ist. Ohne LACP-Verbindungsschutz wird die Portpriorität bei der Auswahl der Portaggregation nicht verwendet.

Ablaufverfolgung von LACP-Vorgängen

Um die Vorgänge des LACP-Prozesses zu verfolgen, fügen Sie die traceoptions Anweisung auf Hierarchieebene [edit protocols lacp] ein:

Sie können die folgenden Flags in der protocols lacp traceoptions Anweisung angeben:

  • all—Alle LACP-Tracing-Vorgänge

  • configuration—Konfigurationscode

  • packet—Gesendete und empfangene Pakete

  • process—LACP-Prozessereignisse

  • protocol—LACP-Protokoll-Zustandsautomat

  • routing-socket—Routing-Socket-Ereignisse

  • startup—Verarbeiten von Startereignissen

Einschränkungen von LACP

LACP kann mehrere verschiedene physische Schnittstellen miteinander verbinden, aber nur Funktionen, die von allen verknüpften Geräten unterstützt werden, werden im resultierenden Link Aggregation Group (LAG)-Bundle unterstützt. Beispielsweise können verschiedene PICs eine unterschiedliche Anzahl von Weiterleitungsklassen unterstützen. Wenn Sie die Link-Aggregation verwenden, um die Ports eines PIC, der bis zu 16 Weiterleitungsklassen unterstützt, mit einem PIC, der bis zu 8 Weiterleitungsklassen unterstützt, miteinander zu verbinden, unterstützt das resultierende LAG-Bundle nur bis zu 8 Weiterleitungsklassen. Ebenso führt das Verknüpfen eines PIC, das WRED unterstützt, mit einem PIC, das es nicht unterstützt, zu einem LAG-Paket, das WRED nicht unterstützt.

Beispiel: Konfigurieren von aggregiertem Ethernet-LACP

Dieses Beispiel zeigt, wie eine aggregierte Ethernet-Schnittstelle mit aktivem LACP zwischen zwei EX-Switches konfiguriert wird.

Topologie

Zwei EX-Switches werden über zwei Schnittstellen in einer aggregierten Ethernet-Konfiguration miteinander verbunden.

Konfigurieren Sie aggregierten Ethernet-LACP über eine nicht getaggte Schnittstelle:

Hinweis:

In diesem Beispiel wird nur die Konfiguration für EX1 angezeigt. EX2 hat bis auf die IP-Adresse die gleiche Konfiguration.

LACP mit untagged Aggregated Ethernet

Die Gehäusekonfiguration ermöglicht 1 aggregierte Ethernet-Schnittstelle. Die 802.3ad Konfiguration ordnet sowohl Schnittstellen ge-0/0/0 ge-0/0/1 als auch Schnittstelle zu ae0. Die ae0 aggregated-ether-options Konfiguration aktiviert den aktiven Modus LACP.

Überprüfung
Verifizieren der aggregierten Ethernet-Schnittstelle
Zweck

Vergewissern Sie sich, dass die aggregierte Ethernet-Schnittstelle erstellt wurde und aktiv ist.

Aktion

Verwenden Sie den Befehl show interfaces terse | match ae aus dem Betriebsmodus.

Bedeutung

Die Ausgabe zeigt, dass ge-0/0/0 und ge-0/0/1 gebündelt sind, um die aggregierte Ethernet-Schnittstelle ae0 zu erstellen, und die Schnittstelle aktiv ist.

Überprüfen, ob LACP aktiv ist
Zweck

Überprüfen Sie, welche Schnittstellen an LACP teilnehmen und wie der aktuelle Status ist.

Aktion

Verwenden Sie den Befehl show lacp interfaces aus dem Betriebsmodus.

Bedeutung

Die Ausgabe zeigt, dass der aktive Modus LACP aktiviert ist.

Überprüfen der Erreichbarkeit
Zweck

Stellen Sie sicher, dass der Ping zwischen den beiden EX-Switches funktioniert.

Aktion

Verwenden Sie den ping 10.1.1.2 count 2 Befehl "Betriebsmodus" auf EX1.

Bedeutung

EX1 ist in der Lage, EX2 über die aggregierte Ethernet-Schnittstelle anzupingen.

Siehe auch

Überprüfen, ob LACP korrekt konfiguriert ist und Bundle-Mitglieder LACP-Protokollpakete austauschen

Stellen Sie sicher, dass LACP korrekt eingerichtet wurde und dass die Bundle-Mitglieder LACP-Protokollpakete übertragen.

Überprüfen des LACP-Setups

Zweck

Vergewissern Sie sich, dass der LACP korrekt eingerichtet wurde.

Aktion

So überprüfen Sie, ob LACP an einem Ende aktiviert wurde:

Bedeutung

Dieses Beispiel zeigt, dass LACP so konfiguriert wurde, dass eine Seite aktiv und die andere passiv ist. Wenn LACP aktiviert ist, muss eine Seite als aktiv festgelegt werden, damit die gebündelte Verbindung aktiv ist.

Überprüfen, ob LACP-Pakete ausgetauscht werden

Zweck

Stellen Sie sicher, dass LACP-Pakete zwischen Schnittstellen ausgetauscht werden.

Aktion

Verwenden Sie den Befehl, um LACP-BPDU-Austauschinformationen show lacp statistics interfaces interface-name anzuzeigen.

Bedeutung

Die Ausgabe hier zeigt, dass die Verbindung verfügbar ist und dass PDUs ausgetauscht werden.

Siehe auch

Unabhängige Micro-BFD-Sitzungen für LAG verstehen

Das BFD-Protokoll (Bidirectional Forwarding Detection) ist ein einfaches Erkennungsprotokoll, das Fehler in den Weiterleitungspfaden schnell erkennt. Um die Fehlererkennung für aggregierte Ethernet-Schnittstellen in einer LAG zu aktivieren, können Sie eine unabhängige BFD-Sitzung im asynchronen Modus für jede LAG-Mitgliedsverbindung in einem LAG-Bundle konfigurieren. Anstelle einer einzelnen BFD-Sitzung, die den Status des UDP-Ports überwacht, überwachen unabhängige Mikro-BFD-Sitzungen den Status einzelner Mitgliederverbindungen.

Wenn Sie Micro-BFD-Sitzungen für jeden Mitgliedslink in einem LAG-Bundle konfigurieren, bestimmt jede einzelne Sitzung die Layer-2- und Layer-3-Konnektivität jedes Mitgliedslinks in einer LAG.

Nachdem die einzelne Sitzung für eine bestimmte Verbindung eingerichtet wurde, werden die Mitgliedsverknüpfungen an die LAG angehängt und dann durch eine der folgenden Optionen einen Lastenausgleich durchgeführt:

  • Statische Konfiguration: Der Gerätesteuerungsprozess fungiert als Client für die Mikro-BFD-Sitzung.

  • Link Aggregation Control Protocol (LACP): LACP fungiert als Client für die Mikro-BFD-Sitzung.

Wenn die Micro-BFD-Sitzung aktiv ist, wird eine LAG-Verbindung hergestellt, und die Daten werden über diese LAG-Verbindung übertragen. Wenn die Micro-BFD-Sitzung auf einem Mitgliedslink ausfällt, wird dieser bestimmte Mitgliedslink aus dem Load Balancer entfernt, und die LAG-Manager leiten den Datenverkehr nicht mehr an diesen Link weiter. Diese Micro-BFD-Sitzungen sind unabhängig voneinander, obwohl sie über einen einzigen Client verfügen, der die LAG-Schnittstelle verwaltet.

Micro-BFD-Sitzungen werden in den folgenden Modi ausgeführt:

  • Verteilungsmodus: In diesem Modus sendet und empfängt die Packet Forwarding Engine (PFE) die Pakete auf Layer 3. Standardmäßig werden Micro-BFD-Sitzungen auf Layer 3 verteilt.

  • Nicht-Verteilungsmodus: In diesem Modus sendet und empfängt die Routing-Engine die Pakete auf Layer 2. Sie können die BFD-Sitzung so konfigurieren, dass sie in diesem Modus ausgeführt wird, indem Sie die no-delegate-processing Anweisung unter Periodic Packet Management (PPM) einfügen.

Ein Paar Routing-Geräte in einer LAG tauscht BFD-Pakete in einem festgelegten, regelmäßigen Intervall aus. Das Routinggerät erkennt einen Nachbarfehler, wenn es nach einem bestimmten Intervall keine Antwort mehr empfängt. Dies ermöglicht die schnelle Überprüfung der Member-Link-Konnektivität mit oder ohne LACP. Ein UDP-Port unterscheidet BFD-over-LAG-Pakete von BFD-over-Single-Hop-IP-Paketen. Die Internet Assigned Numbers Authority (IANA) hat 6784 als UDP-Zielport für Micro-BFD zugewiesen.

Vorteile

  • Fehlererkennung für LAG: Ermöglicht die Fehlererkennung zwischen Geräten, die sich in Punkt-zu-Punkt-Verbindungen befinden.

  • Mehrere BFD-Sitzungen: Ermöglicht die Konfiguration mehrerer Mikro-BFD-Sitzungen für jeden Mitgliederlink anstelle einer einzelnen BFD-Sitzung für das gesamte Paket.

Konfigurationsrichtlinien für Micro-BFD-Sitzungen

Beachten Sie die folgenden Richtlinien, wenn Sie einzelne Micro-BFD-Sitzungen für ein aggregiertes Ethernet-Bundle konfigurieren.

  • Diese Funktion funktioniert nur, wenn beide Geräte BFD unterstützen. Wenn BFD an einem Ende der LAG konfiguriert ist, funktioniert diese Funktion nicht.

  • Beginnend mit Junos OS Version 13.3 hat die IANA 01-00-5E-90-00-01 als dedizierte MAC-Adresse für Micro-BFD zugewiesen. Der dedizierte MAC-Modus wird standardmäßig für Micro-BFD-Sitzungen verwendet.

  • In Junos OS sind Micro-BFD-Steuerungspakete standardmäßig immer ungetaggt. Bei aggregierten Layer-2-Schnittstellen muss die Konfiguration oder-Optionen flexible-vlan-tagging enthaltenvlan-tagging, wenn Sie aggregiertes Ethernet mit BFD konfigurieren. Andernfalls gibt das System beim Ausführen der Konfiguration einen Fehler aus.

  • Wenn Sie Micro-BFD auf einer aggregierten Ethernet-Schnittstelle aktivieren, kann die aggregierte Schnittstelle Micro-BFD-Pakete empfangen. In Junos OS Version 19.3 und höher können Sie für MPC10E- und MPC11E-MPCs keine Firewall-Filter auf die Mikro-BFD-Pakete anwenden, die auf der aggregierten Ethernet-Schnittstelle empfangen werden. Für MPC1E bis MPC9E können Sie Firewall-Filter nur dann auf die Mikro-BFD-Pakete anwenden, die auf der aggregierten Ethernet-Schnittstelle empfangen werden, wenn die aggregierte Ethernet-Schnittstelle als nicht getaggte Schnittstelle konfiguriert ist.

  • Geben Sie ab Junos OS Version 14.1 den Nachbarn in einer BFD-Sitzung an. In Versionen vor Junos OS Version 16.1 müssen Sie die Loopback-Adresse des Remote-Ziels als Nachbaradresse konfigurieren. Ab Junos OS Version 16.1 können Sie diese Funktion auch auf Routern der MX-Serie konfigurieren, bei denen die aggregierte Ethernet-Schnittstellenadresse des Remote-Ziels als Nachbaradresse angegeben ist.

  • Ab Version 16.1R2 prüft und validiert Junos OS die konfigurierte Mikro-BFD local-address vor dem Konfigurations-Commit anhand der Schnittstellen- oder Loopback-IP-Adresse. Junos OS führt diese Prüfung sowohl für IPv4- als auch für IPv6-Micro-BFD-Adresskonfigurationen durch, und wenn diese nicht übereinstimmen, schlägt der Commit fehl. Die konfigurierte lokale Micro-BFD-Adresse sollte mit der Micro-BFD-Nachbaradresse übereinstimmen, die Sie auf dem Peer-Router konfiguriert haben.

  • Deaktivieren Sie für die IPv6-Adressfamilie die Erkennung doppelter Adressen, bevor Sie diese Funktion mit aggregierten Ethernet-Schnittstellenadressen konfigurieren. Um die Erkennung doppelter Adressen zu deaktivieren, fügen Sie die dad-disable Anweisung auf Hierarchieebene [edit interface aex unit y family inet6] ein.

  • Ab Junos OS 21.4R1 wird die minimale LACP-Verbindung mit Sync-Reset und microBFD-Konfiguration auf PTX10001-36MR-, PTX10003-, PTX10004-, PTX10008- und PTX10016-Routern unterstützt.

VORSICHT:

Deaktivieren bfd-liveness-detection Sie auf Hierarchieebene [edit interfaces aex aggregated-ether-options] oder deaktivieren Sie die aggregierte Ethernet-Schnittstelle, bevor Sie die Nachbaradresse von der Loopback-IP-Adresse auf die aggregierte Ethernet-Schnittstellen-IP-Adresse ändern. Das Ändern der lokalen Adresse und der Nachbaradresse, ohne die aggregierte Ethernet-Schnittstelle zu deaktivieren bfd-liveness-detection , kann zum Ausfall von Micro-BFD-Sitzungen führen.

Siehe auch

Konfigurieren von Micro-BFD-Sitzungen für LAG

Das BFD-Protokoll (Bidirectional Forwarding Detection) ist ein einfaches Erkennungsprotokoll, das Fehler in den Weiterleitungspfaden schnell erkennt. Eine Link Aggregation Group (LAG) kombiniert mehrere Verbindungen zwischen Geräten, die sich in Punkt-zu-Punkt-Verbindungen befinden, und erhöht so die Bandbreite, bietet Zuverlässigkeit und ermöglicht einen Lastausgleich. Um eine BFD-Sitzung auf LAG-Schnittstellen auszuführen, konfigurieren Sie eine unabhängige BFD-Sitzung im asynchronen Modus für jeden Link eines LAG-Mitglieds in einem LAG-Paket. Anstelle einer einzelnen BFD-Sitzung, die den Status des UDP-Ports überwacht, überwachen unabhängige Mikro-BFD-Sitzungen den Status einzelner Mitgliederverbindungen.

Hinweis:

Ab Junos OS Evolved Version 20.1R1 werden unabhängige Mikro-BFD-Sitzungen (Bidirectional Forwarding Detection) auf Linkbasis pro Mitglied eines Link Aggregation Group (LAG)-Pakets aktiviert.

So aktivieren Sie die Fehlererkennung für aggregierte Ethernet-Schnittstellen:

  1. Nehmen Sie die folgende Anweisung in die Konfiguration auf Hierarchieebene [edit interfaces aex aggregated-ether-options] auf:
  2. Konfigurieren Sie die Authentifizierungskriterien der BFD-Sitzung für die LAG.

    Um die Authentifizierungskriterien anzugeben, fügen Sie die authentication folgende Anweisung ein:

    • Geben Sie den Algorithmus an, der zur Authentifizierung der BFD-Sitzung verwendet werden soll. Sie können einen der folgenden Algorithmen für die Authentifizierung verwenden:

      • keyed-md5

      • keyed-sha-1

      • akribisch-keyed-md5

      • akribisch-keyed-sha-1

      • einfaches-passwort

    • Um den Schlüsselbund zu konfigurieren, geben Sie den Namen an, der dem Sicherheitsschlüssel für die BFD-Sitzung zugeordnet ist. Der Name, den Sie angeben, muss mit einem der Schlüsselbund übereinstimmen, die in der authentication-key-chains key-chain Anweisung auf Hierarchieebene [edit security] konfiguriert sind.

    • Konfigurieren Sie die Überprüfung der losen Authentifizierung in der BFD-Sitzung. Nur für Übergangszeiträume verwenden, in denen die Authentifizierung möglicherweise nicht an beiden Enden der BFD-Sitzung konfiguriert ist.

  3. Konfigurieren Sie BFD-Timer für aggregierte Ethernet-Schnittstellen.

    Um die BFD-Timer anzugeben, fügen Sie die detection-time folgende Anweisung ein:

    Geben Sie den Schwellenwert an. Dies ist das maximale Zeitintervall für die Erkennung eines BFD-Nachbarn. Wenn das Sendeintervall größer als dieser Wert ist, löst das Gerät einen Trap aus.

  4. Konfigurieren Sie einen Wert für das Halteintervall, um die Mindestzeit festzulegen, die die BFD-Sitzung aktiv bleiben muss, bevor eine Statusänderungsbenachrichtigung an die anderen Mitglieder im LAG-Netzwerk gesendet wird.

    Um das Hold-Down-Intervall anzugeben, fügen Sie die holddown-interval folgende Anweisung ein:

    Sie können eine Zahl im Bereich von 0 bis 255.000 Millisekunden konfigurieren, der Standardwert ist 0. Wenn die BFD-Sitzung ausfällt und dann während des Halteintervalls wieder hochgefahren wird, wird der Timer neu gestartet.

    Dieser Wert stellt das minimale Intervall dar, in dem das lokale Routinggerät BFD-Pakete überträgt, sowie das minimale Intervall, in dem das Routinggerät erwartet, eine Antwort von einem Nachbarn zu erhalten, mit dem es eine BFD-Sitzung aufgebaut hat. Sie können eine Zahl im Bereich von 1 bis 255.000 Millisekunden konfigurieren. Sie können die minimalen Sende- und Empfangsintervalle auch separat festlegen.

  5. Konfigurieren Sie die Quelladressierung für die BFD-Sitzung.

    Um eine lokale Adresse anzugeben, fügen Sie die local-address folgende Anweisung ein:

    Die lokale BFD-Adresse ist die Loopback-Adresse der Quelle der BFD-Sitzung.

    Hinweis:

    Ab Junos OS Version 16.1 können Sie diese Funktion auch mit der AE-Schnittstellenadresse als lokale Adresse in einer Micro-BFD-Sitzung konfigurieren. Deaktivieren Sie für die IPv6-Adressfamilie die Erkennung doppelter Adressen, bevor Sie diese Funktion mit der AE-Schnittstellenadresse konfigurieren. Um die Erkennung doppelter Adressen zu deaktivieren, fügen Sie die dad-disable Anweisung auf Hierarchieebene [edit interface aex unit y family inet6] ein.

    Ab Version 16.1R2 prüft und validiert Junos OS die konfigurierte Micro-BFD vor dem Konfigurations-Commit anhand der Schnittstellen- oder Loopback-IP-Adresse local-address . Junos OS führt diese Prüfung sowohl für IPv4- als auch für IPv6-Micro-BFD-Adresskonfigurationen durch, und wenn diese nicht übereinstimmen, schlägt der Commit fehl. Der konfigurierte Mikro-BFD local-address sollte mit dem auf dem Peer-Router konfigurierten Mikro-BFD neighbour-address übereinstimmen.
  6. Geben Sie das minimale Intervall an, das das Zeitintervall für das Senden und Empfangen von Daten angibt.

    Dieser Wert stellt das minimale Intervall dar, in dem das lokale Routinggerät BFD-Pakete überträgt, sowie das minimale Intervall, in dem das Routinggerät erwartet, eine Antwort von einem Nachbarn zu erhalten, mit dem es eine BFD-Sitzung aufgebaut hat. Sie können eine Zahl im Bereich von 1 bis 255.000 Millisekunden konfigurieren. Sie können die minimalen Sende- und Empfangsintervalle auch separat festlegen.

    Um die minimalen Sende- und Empfangsintervalle für die Fehlererkennung anzugeben, fügen Sie die minimum-interval folgende Anweisung ein:

    Hinweis:

    BFD ist ein intensives Protokoll, das Systemressourcen verbraucht. Die Angabe eines Mindestintervalls für BFD von weniger als 100 ms für Routing-Engine-basierte Sitzungen und 10 ms für verteilte BFD-Sitzungen kann zu unerwünschtem BFD-Flattern führen.

    Abhängig von Ihrer Netzwerkumgebung können die folgenden zusätzlichen Empfehlungen zutreffen:

    • Geben Sie für umfangreiche Netzwerkbereitstellungen mit einer großen Anzahl von BFD-Sitzungen ein Mindestintervall von 300 ms für Routing-Engine-basierte Sitzungen und 100 ms für verteilte BFD-Sitzungen an.

    • Bei sehr großen Netzwerkbereitstellungen mit einer großen Anzahl von BFD-Sitzungen wenden Sie sich an den Kundendienst von Juniper Networks, um weitere Informationen zu erhalten.

    • Damit BFD-Sitzungen während eines Routing-Engine-Switchover-Ereignisses aktiv bleiben, wenn ununterbrochenes aktives Routing konfiguriert ist, geben Sie ein Mindestintervall von 2500 ms für Routing-Engine-basierte Sitzungen an. Für verteilte BFD-Sitzungen mit konfiguriertem Nonstop-Aktiv-Routing bleiben die Empfehlungen für das Mindestintervall unverändert und hängen nur von Ihrer Netzwerkbereitstellung ab.
  7. Geben Sie nur das minimale Empfangsintervall für die Fehlererkennung an, indem Sie die minimum-receive-interval folgende Anweisung einfügen:

    Dieser Wert stellt das minimale Intervall dar, in dem das lokale Routinggerät erwartet, eine Antwort von einem Nachbarn zu erhalten, mit dem es eine BFD-Sitzung aufgebaut hat. Sie können eine Zahl im Bereich von 1 bis 255.000 Millisekunden konfigurieren.

  8. Geben Sie die Anzahl der BFD-Pakete an, die nicht vom Nachbarn empfangen wurden, der dazu führt, dass die Ursprungsschnittstelle als inaktiv deklariert wird, indem Sie die multiplier folgende Anweisung einfügen:

    Der Standardwert ist 3. Sie können eine Zahl im Bereich von 1 bis 255 konfigurieren.

  9. Konfigurieren Sie den Nachbarn in einer BFD-Sitzung.

    Die Nachbaradresse kann entweder eine IPv4- oder eine IPv6-Adresse sein.

    Um den nächsten Hop der BFD-Sitzung anzugeben, fügen Sie die neighbor folgende Anweisung ein:

    Die BFD-Nachbaradresse ist die Loopback-Adresse des Remote-Ziels der BFD-Sitzung.

    Hinweis:

    Ab Junos OS Version 16.1 können Sie auch die AE-Schnittstellenadresse des Remote-Ziels als BFD-Nachbaradresse in einer Mikro-BFD-Sitzung konfigurieren.

  10. (Optional) Konfigurieren Sie BFD-Sitzungen so, dass sie sich nicht an sich ändernde Netzwerkbedingungen anpassen.

    Um die BFD-Anpassung zu deaktivieren, fügen Sie die no-adaptation folgende Anweisung ein:

    Hinweis:

    Es wird empfohlen, die BFD-Anpassung nicht zu deaktivieren, es sei denn, es ist vorzuziehen, keine BFD-Anpassung in Ihrem Netzwerk zu haben.
  11. Geben Sie einen Schwellenwert für die Erkennung der Anpassung der Erkennungszeit an, indem Sie die threshold folgende Anweisung einfügen:

    Wenn sich die Erkennungszeit der BFD-Sitzung an einen Wert anpasst, der gleich oder größer als der Schwellenwert ist, werden ein einzelner Trap und eine Systemprotokollmeldung gesendet. Die Erkennungszeit basiert auf dem Multiplikator des Wertes für das minimale Intervall oder das minimale Empfangsintervall. Der Schwellenwert muss ein höherer Wert als der Multiplikator für einen dieser konfigurierten Werte sein. Wenn z. B. das minimale Empfangsintervall 300 ms und der Multiplikator 3 beträgt, beträgt die gesamte Erkennungszeit 900 ms. Daher muss der Schwellenwert für die Erkennungszeit einen Wert größer als 900 aufweisen.

  12. Geben Sie nur das minimale Übertragungsintervall für die Fehlererkennung an, indem Sie die transmit-interval minimum-interval folgende Anweisung einfügen:

    Dieser Wert stellt das minimale Intervall dar, in dem das lokale Routinggerät BFD-Pakete an den Nachbarn überträgt, mit dem es eine BFD-Sitzung aufgebaut hat. Sie können einen Wert im Bereich von 1 bis 255.000 Millisekunden konfigurieren.

  13. Geben Sie den Übertragungsschwellenwert für die Erkennung der Anpassung des Übertragungsintervalls an, indem Sie die transmit-interval threshold folgende Anweisung einfügen:

    Der Schwellenwert muss größer als das Sendeintervall sein. Wenn sich die Erkennungszeit der BFD-Sitzung an einen Wert anpasst, der größer als der Schwellenwert ist, werden ein einzelner Trap und eine Systemprotokollmeldung gesendet. Die Erkennungszeit basiert auf dem Multiplikator des Wertes für das minimale Intervall oder das minimale Empfangsintervall. Der Schwellenwert muss ein höherer Wert als der Multiplikator für einen dieser konfigurierten Werte sein.

  14. Geben Sie die BFD-Version an, indem Sie die version folgende Anweisung einfügen:

    Standardmäßig wird die Version automatisch erkannt.

Hinweis:

  • Diese version Option wird von der QFX-Serie nicht unterstützt. Ab Junos OS Version 17.2R1 wird eine Warnung angezeigt, wenn Sie versuchen, diesen Befehl zu verwenden.

  • Diese Funktion funktioniert, wenn beide Geräte BFD unterstützen. Wenn BFD nur an einem Ende der LAG konfiguriert ist, funktioniert diese Funktion nicht.

Siehe auch

Verstehen des Algorithmus, der zum Hashen des LAG-Bündels und zum Ausgang von Next-Hop-ECMP-Datenverkehr verwendet wird

Die EX- und QFX-Serien von Juniper Networks verwenden einen Hashing-Algorithmus, um zu bestimmen, wie der Datenverkehr über ein LAG-Bundle (Link Aggregation Group) oder an das Next-Hop-Gerät weitergeleitet werden soll, wenn ECMP (Equal-Cost Multipath) aktiviert ist.

Der Hashing-Algorithmus trifft Hashing-Entscheidungen auf der Grundlage von Werten in verschiedenen Paketfeldern sowie auf einigen internen Werten wie der Quellport-ID und der Quellgeräte-ID. Sie können einige der Felder konfigurieren, die vom Hashalgorithmus verwendet werden.

Hinweis:

Die Plattformunterstützung hängt von der Junos OS-Version in Ihrer Installation ab.

Dieses Thema enthält die folgenden Abschnitte:

Grundlegendes zum Hashing-Algorithmus

Der Hashing-Algorithmus wird verwendet, um Entscheidungen über die Weiterleitung des Datenverkehrs für Datenverkehr zu treffen, der in ein LAG-Paket eintritt, oder für Datenverkehr, der einen Switch verlässt, wenn ECMP aktiviert ist.

Bei LAG-Bundles bestimmt der Hashing-Algorithmus, wie der in ein LAG-Bundle eingehende Datenverkehr auf die Mitgliedslinks des Bundles platziert wird. Der Hashing-Algorithmus versucht, die Bandbreite zu verwalten, indem er den gesamten eingehenden Datenverkehr gleichmäßig auf die Mitgliedslinks im Bundle verteilt.

Bei ECMP bestimmt der Hashalgorithmus, wie eingehender Datenverkehr an das Next-Hop-Gerät weitergeleitet wird.

Der Hashing-Algorithmus trifft Hashing-Entscheidungen auf der Grundlage von Werten in verschiedenen Paketfeldern sowie auf einigen internen Werten wie der Quellport-ID und der Quellgeräte-ID. Die Paketfelder, die vom Hashing-Algorithmus verwendet werden, variieren je nach EtherType des Pakets und in einigen Fällen durch die Konfiguration auf dem Switch. Der Hashing-Algorithmus erkennt die folgenden EtherTypes:

  • IP (IPv4 und IPv6)

  • MPLS

  • MAC-in-MAC

Datenverkehr, der nicht als zu einem dieser EtherTypes gehörend erkannt wird, wird basierend auf dem Layer-2-Header gehasht. IP- und MPLS-Datenverkehr wird auch basierend auf dem Layer-2-Header gehasht, wenn ein Benutzer den Hash-Modus als Layer-2-Header konfiguriert.

Sie können einige Felder konfigurieren, die vom Hashalgorithmus verwendet werden, um Entscheidungen über die Weiterleitung des Datenverkehrs zu treffen. Sie können jedoch nicht konfigurieren, wie bestimmte Werte innerhalb eines Headers vom Hashalgorithmus verwendet werden.

Beachten Sie die folgenden Punkte in Bezug auf den Hashing-Algorithmus:

  • Die für das Hashing ausgewählten Felder basieren nur auf dem Pakettyp. Die Felder basieren nicht auf anderen Parametern, einschließlich der Weiterleitungsentscheidung (überbrückt oder geroutet) oder der Ausgangs-LAG-Bundle-Konfiguration (Layer 2 oder Layer 3).

  • Die gleichen Felder werden für das Hashing von Unicast- und Multicast-Paketen verwendet. Unicast- und Multicast-Pakete werden jedoch unterschiedlich gehasht.

  • Der Hashalgorithmus verwendet dieselben Felder zum Hashen von ECMP- und LAG-Datenverkehr, aber der Hashalgorithmus hasht ECMP- und LAG-Datenverkehr unterschiedlich. LAG-Datenverkehr verwendet einen Trunk-Hash, während ECMP ECMP-Hashing verwendet. Sowohl LAG als auch ECMP verwenden denselben RTAG7-Seed, verwenden jedoch unterschiedliche Offsets dieses 128B-Seed, um Polarisation zu vermeiden. Die anfängliche Konfiguration der HASH-Funktion zur Verwendung des Trunk- und ECMP-Offsets wird zur PFE-Init-Zeit festgelegt. Durch das unterschiedliche Hashing wird sichergestellt, dass der Datenverkehr nicht polarisiert wird, wenn ein LAG-Bundle Teil des ECMP-Next-Hop-Pfads ist.

  • Für das Hashing werden dieselben Felder verwendet, unabhängig davon, ob der Switch an einem gemischten oder nicht gemischten Virtual Chassis oder Virtual Chassis Fabric (VCF) beteiligt ist oder nicht.

In den folgenden Abschnitten werden die Felder erläutert, die von den einzelnen EtherType für das Hashing verwendet werden, sowie die Felder, die vom Layer-2-Header verwendet werden.

IP (IPv4 und IPv6)

Nutzlastfelder in IPv4- und IPv6-Paketen werden vom Hashing-Algorithmus verwendet, wenn IPv4- oder IPv6-Pakete auf einer Mitgliedsverbindung in einem LAG-Bundle platziert oder an das Next-Hop-Gerät gesendet werden müssen, wenn ECMP aktiviert ist.

Der Hash-Modus ist standardmäßig auf Layer-2-Nutzlastfeld eingestellt. IPv4- und IPv6-Nutzlastfelder werden für das Hashing verwendet, wenn der Hash-Modus auf Layer-2-Nutzlast festgelegt ist.

Wenn der Hash-Modus für Layer-2-Header konfiguriert ist, werden IPv4-, IPv6- und MPLS-Pakete mithilfe der Layer-2-Header-Felder gehasht. Wenn Sie möchten, dass eingehende IPv4-, IPv6- und MPLS-Pakete von den Feldern Quell-MAC-Adresse, Ziel-MAC-Adresse oder EtherType gehasht werden, müssen Sie den Hash-Modus auf Layer-2-Header festlegen.

Tabelle 5 zeigt die IPv4- und IPv6-Nutzlastfelder, die standardmäßig vom Hashalgorithmus verwendet werden.

  • ✓ – Das Feld wird standardmäßig vom Hashalgorithmus verwendet.

  • Χ: Das Feld wird standardmäßig nicht vom Hashalgorithmus verwendet.

  • (konfigurierbar): Das Feld kann so konfiguriert werden, dass es vom Hashing-Algorithmus verwendet oder nicht verwendet wird.

Auf EX2300-Switches werden die folgenden Nutzlastfelder in IPv4- und IPv6-Paketen vom Hashing-Algorithmus verwendet, wenn IPv4- oder IPv6-Pakete auf einer Mitgliedsverbindung in einem LAG-Bundle platziert oder an das Next-Hop-Gerät gesendet werden müssen, wenn ECMP aktiviert ist:

  • Für Unicast-Datenverkehr auf LAG – SIP, DIP, L4SP, L4DP

  • Für bekannten Multicast-Datenverkehr auf LAG: Quell-IP, Ziel-IP, Ingress-Mod-ID und Ingress-Port-ID

  • Für Broadcast-, unbekannten Unicast- und unbekannten Multicast-Datenverkehr auf LAG – Quell-MAC, Ziel-MAC, Ingress-Mod-ID und Ingress-Port-ID

  • ECMP-Load-Balancing: Ziel-IP, Layer-4-Quellport und Layer-4-Zielport

Tabelle 5: IPv4- und IPv6-Hashing-Felder

Fields

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

 

LAG

ECMP

LAG

ECMP

LAG

ECMP

LAG

ECMP

LAG

ECMP

Quell-MAC

X

Χ

X

Χ

Χ

Χ

Χ

Χ

Χ

X

Ziel-MAC

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

EtherType (EtherTyp)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

VLAN-ID

Χ

(konfigurierbar)

Χ

(konfigurierbar)

Χ

(konfigurierbar)

Χ

(konfigurierbar)

Χ

(konfigurierbar)

Χ

(konfigurierbar)

Χ

(konfigurierbar)

Χ

(konfigurierbar)

Χ

(konfigurierbar)

Χ

(konfigurierbar)

Quell-IP oder IPv6

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

Ziel-IP oder IPv6

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

Protokoll (nur IPv4)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

Nächster Header (nur IPv6)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

Layer-4-Quellport

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

Layer-4-Zielport

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

IPv6-Flow-Label (nur IPv6)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Ingress-Mod-ID

✓

(konfigurierbar)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Eingangsport-ID

✓

(konfigurierbar)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

MPLS

Der Hashing-Algorithmus hasht MPLS-Pakete anhand der Felder Quell-IP, Ziel-IP, MPLS-Label 0, MPLS-Label 1, MPLS-Label 2 und MPLS 3. Auf den Switches QFX5110, QFX5120 und QFX5200 unterstützen LSR-Router auch ECMP. ECMP verwendet diese Felder für das Hashing auf einem LSR-Router:

  • Layer-3-VPN: MPLS-Labels (die drei wichtigsten Labels), Quell-IP, Ziel-IP und Eingangsport-ID

  • Layer-2-Schaltung: MPLS-Labels (Top-3-Labels) und Ingress-Port-ID

Tabelle 6 zeigt die MPLS-Nutzlastfelder, die standardmäßig vom Hashalgorithmus verwendet werden:

  • ✓ – Das Feld wird standardmäßig vom Hashalgorithmus verwendet.

  • Χ: Das Feld wird standardmäßig nicht vom Hashalgorithmus verwendet.

Die Felder, die vom Hashing-Algorithmus für das MPLS-Paket-Hashing verwendet werden, können nicht vom Benutzer konfiguriert werden.

Die Felder Quell-IP und Ziel-IP werden nicht immer für das Hashing verwendet. Bei nicht terminierten MPLS-Paketen wird die Nutzlast überprüft, wenn das BoS-Flag (Bottom of Stack) im Paket zu sehen ist. Wenn es sich bei der Nutzlast um IPv4 oder IPv6 handelt, werden die Felder IP-Quelladresse und IP-Zieladresse zusammen mit den MPLS-Bezeichnungen für das Hashing verwendet. Wenn das BoS-Flag im Paket nicht zu sehen ist, werden nur die MPLS-Labels für das Hashing verwendet.

Tabelle 6: MPLS-Hashing-Felder

Field

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

Quell-MAC

Χ

Χ

Χ

Χ

Χ

Ziel-MAC

Χ

Χ

Χ

Χ

Χ

EtherType (EtherTyp)

Χ

Χ

Χ

Χ

Χ

VLAN-ID

Χ

Χ

Χ

Χ

Χ

Quell-IP

✓

✓

✓

✓

✓

Ziel-IP

✓

✓

✓

✓

✓

Protokoll (für IPv4-Pakete)

Χ

Χ

Χ

Χ

Χ

Nächster Header (für IPv6-Pakete)

Χ

Χ

Χ

Χ

Χ

Layer-4-Quellport

Χ

Χ

Χ

Χ

Χ

Layer-4-Zielport

Χ

Χ

Χ

Χ

Χ

IPv6-Flusslabor

Χ

Χ

Χ

Χ

Χ

MPLS-Etikett 0

Χ

✓

✓

✓

✓

MPLS-Etikett 1

✓

✓

✓

✓

✓

MPLS-Etikett 2

✓

✓

✓

✓

✓

MPLS-Etikett 3

✓

X

X

X

X

Eingangsport-ID

✓

(LSR und L2Circuit)

X

X

X

✓

(LSR und L2Circuit)

✓

(LSR und L2Circuit)

MAC-in-MAC-Paket-Hashing

Pakete, die den MAC-in-MAC-EtherType verwenden, werden vom Hashing-Algorithmus unter Verwendung der Felder Layer-2-Nutzlast-Quell-MAC, Layer-2-Nutzlast-Ziel-MAC und Layer-2-Nutzlast EtherType gehasht. Siehe Tabelle 7.

Das Hashing mit den Feldern im MAC-in-MAC-EtherType-Paket wird erstmals auf EX4300-Switches in Version 13.2X51-D20 unterstützt. Das Hashing mit den Feldern im MAC-in-MAC-EtherType wird in früheren Versionen nicht unterstützt.

Die Felder, die vom Hashalgorithmus für MAC-in-MAC-Hashing verwendet werden, können nicht vom Benutzer konfiguriert werden.

  • ✓ – Das Feld wird standardmäßig vom Hashalgorithmus verwendet.

  • Χ: Das Feld wird standardmäßig nicht vom Hashalgorithmus verwendet.

Tabelle 7: MAC-in-MAC-Hashing-Felder

Field

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

MAC der Layer-2-Nutzlastquelle

✓

✓

✓

✓

✓

Layer-2-Nutzlast-Ziel-MAC

✓

✓

✓

✓

✓

Layer-2-Nutzlast EtherType

✓

✓

✓

✓

✓

Äußeres Layer-2-Nutzlast-VLAN

✓

Χ

Χ

Χ

Χ

Layer-2-Header-Hashing

Layer-2-Header-Felder werden vom Hashing-Algorithmus verwendet, wenn der EtherType eines Pakets nicht als IP (IPv4 oder IPv6), MPLS oder MAC-in-MAC erkannt wird. Die Layer-2-Header-Felder werden auch für das Hashing von IPv4-, IPv6- und MPLS-Datenverkehr anstelle der Nutzlastfelder verwendet, wenn der Hash-Modus auf Layer-2-Header eingestellt ist.

  • ✓ – Das Feld wird standardmäßig vom Hashalgorithmus verwendet.

  • Χ: Das Feld wird standardmäßig nicht vom Hashalgorithmus verwendet.

  • (konfigurierbar): Das Feld kann so konfiguriert werden, dass es vom Hashing-Algorithmus verwendet oder nicht verwendet wird.

Tabelle 8: Layer-2-Header-Hashing-Felder

Field

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

Quell-MAC

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

Ziel-MAC

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

EtherType (EtherTyp)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

VLAN-ID

Χ

(konfigurierbar)

Χ

(konfigurierbar)

Χ

(konfigurierbar)

✓

(konfigurierbar)

✓

(konfigurierbar)

Hashing-Parameter

Ab Junos OS Version 19.1R1 können Sie in der QFX5000 Reihe von Switches die Hashing-Parameter für die vorhandenen implementierten Algorithmen ändern. Sie können den Schwellenwert für gemeinsam genutzte Pufferpools sowohl für Eingangs- als auch für Ausgangspufferpartitionen ändern und Änderungen an der Auswahl der Hashfunktion, dem Hashalgorithmus und anderen zusätzlichen Parametern vornehmen. Weitere Informationen finden Sie unter Konfigurieren anderer Hashing-Parameter weiter unten in diesem Dokument.

Konfigurieren der Felder im Algorithmus, der zum Hashen des LAG-Pakets und des ECMP-Datenverkehrs verwendet wird (CLI-Verfahren)

Die Switches der EX- und QFX-Serie von Juniper Networks verwenden einen Hashing-Algorithmus, um zu bestimmen, wie der Datenverkehr über ein Link Aggregation Group (LAG)-Bundle oder an das Next-Hop-Gerät weitergeleitet werden soll, wenn Equal-Cost Multipath (ECMP) aktiviert ist.

Der Hashing-Algorithmus trifft Hashing-Entscheidungen auf der Grundlage von Werten in verschiedenen Paketfeldern. Sie können einige der Felder konfigurieren, die vom Hashalgorithmus verwendet werden.

Die Konfiguration der Felder, die vom Hashalgorithmus verwendet werden, ist in Szenarien nützlich, in denen der größte Teil des Datenverkehrs, der in das Paket gelangt, ähnlich ist und der Datenverkehr im LAG-Paket verwaltet werden muss. Wenn z. B. der einzige Unterschied in den IP-Paketen für den gesamten eingehenden Datenverkehr die Quell- und Ziel-IP-Adresse ist, können Sie den Hashing-Algorithmus optimieren, um Hashing-Entscheidungen effizienter zu treffen, indem Sie den Algorithmus so konfigurieren, dass Hashing-Entscheidungen nur anhand dieser Felder getroffen werden.

Hinweis:

Die Konfiguration des Hash-Modus wird auf QFX10002- und QFX10008-Switches nicht unterstützt.

Konfigurieren des Hashalgorithmus für die Verwendung von Feldern im Layer-2-Header für das Hashing

So konfigurieren Sie den Hashing-Algorithmus für die Verwendung von Feldern im Layer-2-Header für das Hashing:

  1. Konfigurieren Sie den Hash-Modus für den Layer-2-Header:

    Der Standard-Hash-Modus ist die Layer-2-Nutzlast. Daher muss dieser Schritt durchgeführt werden, wenn Sie den Hash-Modus noch nicht konfiguriert haben.

  2. Konfigurieren Sie die Felder im Layer-2-Header, die der Hashing-Algorithmus für das Hashing verwendet:

    Standardmäßig verwendet der Hashalgorithmus die Werte in den Feldern "MAC-Zieladresse", "Ethertype" und "Quell-MAC-Adresse" im Header, um den Datenverkehr auf der LAG zu hashen. Sie können den Hashalgorithmus so konfigurieren, dass die Werte in diesen Feldern nicht verwendet werden, indem no-destination-mac-addressSie , no-ether-typeoder no-source-mac-address.

    Sie können den Hashing-Algorithmus auch so konfigurieren, dass das VLAN-ID-Feld in den Header aufgenommen wird, indem Sie die vlan-id Option konfigurieren.

    Wenn Sie möchten, dass der Hashalgorithmus das Ethertype-Feld nicht für das Hashing verwendet, gehen Sie wie folgt vor:

Konfigurieren des Hashing-Algorithmus für die Verwendung von Feldern in der IP-Nutzlast für das Hashing

So konfigurieren Sie den Hashing-Algorithmus so, dass Felder in der IP-Nutzlast für das Hashing verwendet werden:

  1. Konfigurieren Sie den Hash-Modus für die Layer-2-Nutzlast:

    Die IP-Nutzlast wird vom Hashing-Algorithmus nicht überprüft, es sei denn, der Hash-Modus ist auf Layer-2-Nutzlast festgelegt. Der Standard-Hash-Modus ist die Layer-2-Nutzlast.

  2. Konfigurieren Sie die Felder in der IP-Nutzlast, die der Hashalgorithmus für das Hashing verwendet:

    Wenn Sie beispielsweise möchten, dass der Hashalgorithmus die Felder Layer-4-Zielport, Layer-4-Quellport und Protokoll ignoriert und stattdessen Datenverkehr nur auf der Grundlage der IPv4-Quell- und Zieladressen hasht:

Konfigurieren des Hashing-Algorithmus für die Verwendung von Feldern in der IPv6-Nutzlast für das Hashing

So konfigurieren Sie den Hashing-Algorithmus für die Verwendung von Feldern in der IPv6-Nutzlast für das Hashing:

  1. Konfigurieren Sie den Hash-Modus für die Layer-2-Nutzlast:

    Die IPv6-Nutzlast wird vom Hashing-Algorithmus nicht überprüft, es sei denn, der Hash-Modus ist auf Layer-2-Nutzlast festgelegt. Der Standard-Hash-Modus ist die Layer-2-Nutzlast.

  2. Konfigurieren Sie die Felder in der IPv6-Nutzlast, die der Hashalgorithmus für das Hashing verwendet:

    Wenn Sie beispielsweise möchten, dass der Hashalgorithmus den Layer-4-Zielport, den Layer-4-Quellport und die Felder Next Header ignoriert und stattdessen Datenverkehr nur auf der Grundlage der IPv6-Quell- und IPv6-Zieladressfelder hasht:

Konfigurieren anderer Hashing-Parameter

So konfigurieren Sie Hashing-Parameter für ECMP- oder LAG-Datenverkehr:

  1. Konfigurieren Sie den Parameter preprocess:
  2. Konfigurieren Sie den Funktionsparameter:
  3. Konfigurieren Sie den Offset-Wert:

Siehe auch

Tabelle "Änderungshistorie"

Die Funktionsunterstützung hängt von der Plattform und der Version ab, die Sie verwenden. Verwenden Sie den Feature-Explorer , um festzustellen, ob ein Feature auf Ihrer Plattform unterstützt wird.

Release
Beschreibung
19.3
Ab Junos OS Version 19.3 und höher können Sie für MPC10E- und MPC11E-MPCs keine Firewall-Filter auf die MicroBFD-Pakete anwenden, die auf der aggregierten Ethernet-Schnittstelle empfangen werden. Für MPC1E bis MPC9E können Sie Firewall-Filter nur dann auf die MicroBFD-Pakete anwenden, die auf der aggregierten Ethernet-Schnittstelle empfangen werden, wenn die aggregierte Ethernet-Schnittstelle als nicht getaggte Schnittstelle konfiguriert ist.
19.1R1
Bei den QFX5000 Switches können Sie die Hashing-Parameter für die vorhandenen implementierten Algorithmen ändern.
16.1
Ab Junos OS Version 16.1 können Sie diese Funktion auch auf Routern der MX-Serie konfigurieren, bei denen die aggregierte Ethernet-Schnittstellenadresse des Remote-Ziels als Nachbaradresse angegeben ist.
16.1
Ab Version 16.1R2 prüft und validiert Junos OS die konfigurierte Micro-BFD vor dem Konfigurations-Commit anhand der Schnittstellen- oder Loopback-IP-Adresse local-address .
14.1X53-D25
Ab Junos OS Version 14.1X53-D25 kann Local Link Bias global für alle LAG-Bundles in einem Virtual Chassis oder VCF oder einzeln pro LAG-Bundle in einem Virtual Chassis aktiviert werden.
14.1
Geben Sie ab Junos OS Version 14.1 den Nachbarn in einer BFD-Sitzung an. In Versionen vor Junos OS Version 16.1 müssen Sie die Loopback-Adresse des Remote-Ziels als Nachbaradresse konfigurieren.
13.3
Beginnend mit Junos OS Version 13.3 hat die IANA 01-00-5E-90-00-01 als dedizierte MAC-Adresse für Micro-BFD zugewiesen.