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 von Link-Aggregation und aggregierten Ethernet-Schnittstellen sowie 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 gruppieren, um eine Single Link Layer-Schnittstelle zu bilden, 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 Linkaggregation ist die erhöhte Verfügbarkeit, da sich die LAG aus mehreren Mitgliederlinks zusammensetzt. Wenn eine Mitgliedsverbindung ausfällt, leitet die LAG weiterhin Datenverkehr über die verbleibenden Verbindungen.

Anmerkung:

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

Sie können den Portkanal mit verschiedenen SFP-Modellen zwischen zwei Endgeräten 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)

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

Anmerkung:

Um einen Load Balancing für die aggregierten Ethernet-Schnittstellen (AE) in einer redundanten Serverknotengruppe sicherzustellen, müssen die Mitglieder der AE gleichmäßig auf die redundante Serverknotengruppe verteilt sein.
Anmerkung:

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 eine Reihe von Schnittstellen (Ports) mit der Verbindung verknüpfen. Alle Schnittstellen müssen die gleiche Geschwindigkeit haben und sich im Vollduplex-Modus befinden. Juniper Networks Betriebssystem Junos (Junos OS) 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 von einem Switch unterstützten LAGs 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 von ihnen unterstützten LAGs auf.

LAGs mit Mitgliedslinks unterschiedlicher Schnittstellentypen, z. B. GE und MGE, werden auf Multirate-Switches nicht unterstützt.

Anmerkung:

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

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

Schalter

Maximale Anzahl an Schnittstellen pro LAG

Maximale Anzahl an LAGs

EX2200-KARTON

8

32

EX2300-KARTON

8

128

EX3200-KARTON

8

32

EX3300 und EX3300 Virtual Chassis

8

32

EX3400-KARTON

16

128
EX4100-F Virtual Chassis 8 128

EX4200 und EX4200 Virtual Chassis

8

111

EX4300 und EX4300 Virtual Chassis

16

128

EX4500, EX4500 Virtual Chassis, EX4550 und EX4550 Virtual Chassis

8

111
EX4400-KARTON 16 128

EX4600-KARTON

32

128
EX4650 Virtual Chassis 64 72

EX6200-KARTON

8

111

EX8200-KARTON

12

255

EX8200 Virtual Chassis

12

239

EX9200-KARTON

64

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

Schalter

Maximale Anzahl an Schnittstellen pro LAG

Maximale Anzahl an LAGs

QFX5100

64

96

QFX5110

64

96

QFX5120

64

72
QFX5130 64 128

QFX5200

64

128

QFX5700

128

144

QFX10002

64

150

QFX10008

64

1000

QFX10016

64

1000
Anmerkung:

Wenn Sie auf Switches der QFX-Serie versuchen, eine Konfiguration mit mehr als 64 Ethernet-Schnittstellen in einer LAG zu bestätigen, 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 logisch aggregierte Ethernet-Schnittstelle.

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

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

  4. Konfigurieren Sie LACP für die Verbindungserkennung.

Beachten Sie die folgenden Hardware- und Softwarerichtlinien:

  • Für Junos OS Evolved wird ein Link-Flap-Ereignis generiert, wenn dem aggregierten Ethernet-Bundle eine neue Schnittstelle als Mitglied hinzugefügt wird. Wenn Sie dem Paket 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-Knotengruppe, einer Server-Knotengruppe und einer Netzwerk-Knotengruppe auf einem QFabric-System zu bilden. Bis zu 48 LAGs werden auf redundanten Server-Knotengruppen und Server-Knotengruppen auf einem QFabric-System und bis zu 128 LAGs auf Netzwerk-Knotengruppen auf einem QFabric-System unterstützt. Sie können LAGs für Node-Geräte in redundanten Serverknotengruppen, Serverknotengruppen und Netzwerkknotengruppen konfigurieren.

    Anmerkung:

    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 gruppiert werden. In einem 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.

    Anmerkung:

    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. Daher kann die Kommunikation zwischen zwei Geräten für verschiedene Übertragungen unterschiedliche physische Verbindungen in der LAG verwenden. Eine FCoE-LAG stellt sicher, dass der FCoE-Datenverkehr dieselbe physische Verbindung in der LAG für Anfragen und Antworten 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 aufrechtzuerhalten. Eine FCoE-LAG bietet kein Load Balancing oder Verbindungsredundanz für FCoE-Datenverkehr. Der reguläre 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 zur Bündelung mehrerer physikalischer Schnittstellen zu einer logisch aggregierten Ethernet-Schnittstelle. Standardmäßig tauschen Ethernet-Verbindungen keine LACP-Protokolldateneinheiten (PDUs) aus, die Informationen über den Zustand der Verbindung enthalten. Sie können Ethernet-Verbindungen so konfigurieren, dass LACP-PDUs aktiv übertragen werden, oder Sie können die Links so konfigurieren, dass sie passiv übertragen werden und LACP-PDUs nur dann senden, wenn die Ethernet-Verbindung sie vom entfernten 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 der Akteur und der Partner beide im passiven Modus befinden, tauschen sie keine LACP-Pakete aus, und die aggregierten Ethernet-Verbindungen werden nicht angezeigt. Wenn entweder der Akteur oder der Partner aktiv ist, tauschen sie LACP-Pakete aus. Standardmäßig befindet sich LACP auf aggregierten Ethernet-Schnittstellen im passiven Modus. Um die Übertragung von LACP-Paketen und die Reaktion 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 Bündels mit der richtigen Gruppe verbunden sind.

In einem Szenario, in dem ein Dual-Homed-Server mit einem Switch bereitgestellt wird, bilden die Netzwerkschnittstellenkarten eine LAG mit dem Switch. Während eines Serverupgrades ist der Server möglicherweise nicht in der Lage, LACP-PDUs auszutauschen. In einer solchen Situation können Sie eine Schnittstelle so konfigurieren, dass sie sich auch dann im up 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 zugeordnete 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 durch die Sendestrecke 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 keine LACP. Alle Verbindungen in der LAG sind dauerhaft betriebsbereit, es sei denn, der Switch erkennt einen Verbindungsausfall innerhalb der physischen Ethernet-Schicht oder der Datenverbindungsschichten.

Wenn LACP konfiguriert ist, erkennt es Fehlkonfigurationen auf dem lokalen oder dem Remote-Ende der Verbindung. So 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, was dazu führt, dass 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

Konfiguration 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-Aggregationsgruppenschnittstelle konfigurieren möchten.
  2. Konfigurieren Sie die aggregierte Ethernet-Schnittstelle.

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

Anmerkung:

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. Ausnahmen 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 Mitgliederlinks sein, aber IQ- und SFP-spezifische Funktionen werden im aggregierten Ethernet-Paket nicht unterstützt, selbst wenn alle Mitgliedslinks diese Funktionen einzeln unterstützen.

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

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

Siehe auch

Konfiguration von getaggten aggregierten Ethernet-Schnittstellen

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

Sie müssen auch die vlan-id folgende Anweisung angeben:

Sie können diese Anweisung auf folgenden Hierarchieebenen einfÃ1/4hren:

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

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

Weitere Hinweise zu den und-Anweisungen finden Sie unter Übersicht über 802.1Q-VLANsvlan-taggingvlan-id.

Siehe auch

Konfiguration von nicht getaggten aggregierten Ethernet-Schnittstellen

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) zu und von den einzelnen Verbindungen.

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

Konfigurieren Sie eine nicht getaggte aggregierte Ethernet-Schnittstelle, indem Sie dievlan-tagging and-Anweisungen vlan-id in 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 Routing-Gerä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 physischen Verknüpfungen angeben, indem Sie die 802.3ad Anweisung auf der [edit interfaces interface-name ether-options] Hierarchieebene einschließen.

Siehe auch

Beispiel: Konfiguration 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 OS entfernt die zugehörigen aex Konfigurationsanweisungen und setzt diese Schnittstelle in den inaktiven Zustand.

  • 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 im Zusammenhang mit aexentfernt.

  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 "show interfaces" 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 keine Konfigurationsdiskrepanz vorliegt.

  • Vergewissern Sie sich, dass alle Mitgliedsports aktiv sind.

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

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

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

Logische Schnittstellenstatistiken spiegeln nicht den gesamten Datenverkehr wider

Problem

Beschreibung

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

Lösung

Datenverkehrsstatistikfelder für logische Schnittstellen in show interfaces Befehlen zeigen nur den Steuerverkehr an; die Datenverkehrsstatistik enthält keinen Datenverkehr. Sie können die Statistiken für den gesamten Datenverkehr nur pro physischer Schnittstelle anzeigen.

IPv6-Schnittstellen-Datenverkehrsstatistiken werden nicht unterstützt

Problem

Beschreibung

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

Lösung

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

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

Konfiguration der regelmäßigen Neuverteilung von Teilnehmern in einer aggregierten Ethernet-Schnittstelle

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

So konfigurieren Sie die regelmäßige Neuverteilung:

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

Siehe auch

Konfiguration des aggregierten Ethernet-LACP

Für aggregierte Ethernet-Schnittstellen können Sie das Link Aggregation Control Protocol (LACP) konfigurieren. LACP ist eine Methode, bei der mehrere physische Schnittstellen zu einer logischen Schnittstelle gebündelt werden. Sie können sowohl VLAN-getaggtes als auch nicht getaggtes aggregiertes Ethernet mit oder ohne aktiviertem LACP konfigurieren.

Für Multichassis Link Aggregation (MC-LAG) müssen Sie die system-id und admin keyangeben. 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 Peers synchronisiert werden.

Der LACP-Austausch findet zwischen Akteuren und Partnern statt. Ein Akteur ist die lokale Schnittstelle in einem LACP-Austausch. Ein Partner ist die Remote-Schnittstelle in einer LACP-Börse.

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 Bündels mit der richtigen Gruppe verbunden sind

Die Junos OS-Implementierung von LACP bietet eine Linküberwachung, jedoch kein automatisches Hinzufügen und Löschen von Links.

Der LACP-Modus kann aktiv oder passiv sein. Wenn sich der Akteur und der Partner beide im passiven Modus befinden, tauschen sie keine LACP-Pakete aus, was dazu führt, dass die aggregierten Ethernet-Verbindungen nicht aktiviert werden. Wenn entweder der Akteur oder der Partner aktiv ist, tauschen sie LACP-Pakete aus. Standardmäßig ist LACP auf aggregierten Ethernet-Schnittstellen deaktiviert. Wenn LACP konfiguriert ist, befindet es sich standardmäßig im passiven Modus. Um die Übertragung von LACP-Paketen und die Reaktion 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 der [edit interfaces interface-name aggregated-ether-options] Hierarchieebene ein, und geben Sie die active Option an:

Anmerkung:

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

Um das Standardverhalten wiederherzustellen, fügen Sie die lacp Anweisung auf Hierarchieebene [edit interfaces interface-name aggregated-ether-options] ein, und geben Sie die passive 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 der Standby-Link immer Datenverkehr empfangen kann. Das Überschreiben des Standardverhaltens erleichtert das Failover innerhalb einer Sekunde.

Um den IEEE 802.3ad-Standard außer Kraft zu setzen und das Failover innerhalb einer Sekunde zu erleichtern, schließen Sie die fast-failover Anweisung auf der [edit interfaces interface-name aggregated-ether-options lacp] Hierarchieebene 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 der [edit interfaces interface-name aggregated-ether-options lacp] Hierarchieebene 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.

Anmerkung:

Die Filterung der Quelladresse 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 Datenverkehrs-Policers.

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

Konfigurieren des LACP-Linkschutzes

Anmerkung:

Wenn Sie den LACP-Verbindungsschutz verwenden, können Sie nur zwei Mitgliedsverbindungen zu einer aggregierten Ethernetschnittstelle konfigurieren: einen aktiven und einen Standby-Schnittstelle.

Um aktive und Standby-Links 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 system-priority and-Anweisungen konfigurieren. Die Konfiguration von Werten auf dieser Ebene führt dazu, dass nur die konfigurierten Schnittstellen die definierte Konfiguration verwenden. Die LACP-Schnittstellenkonfiguration ermöglicht es Ihnen auch, globale (Chassis-)LACP-Einstellungen zu überschreiben.

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

Anmerkung:

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

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

Standardmäßig wird der LACP-Linkschutz auf einen Link mit höherer Priorität (niedriger Nummer) zurückgesetzt, wenn dieser Link mit höherer Priorität betriebsbereit wird oder dem Aggregator ein Link hinzugefügt wird, der als höher eingestuft wird. Sie können die Verbindungsberechnung jedoch unterdrücken, indem Sie die non-revertive Anweisung der LACP-Linkschutzkonfiguration hinzufügen. Sobald eine Verbindung aktiv ist und Pakete sammelt und verteilt, führt im nicht-revertiven Modus das nachfolgende Hinzufügen einer (besseren) Verbindung mit höherer Priorität nicht zu einem Switch, und die aktuelle Verbindung bleibt aktiv.

Wenn der LACP-Verknüpfungsschutz auf globaler Ebene ([edit chassis] Hierarchie) so konfiguriert ist, dass er nicht rückgängig gemacht werden kann, können Sie die revertive Anweisung der LACP-Verknüpfungsschutzkonfiguration hinzufügen, um die nicht wiederherstellbare Einstellung für die Schnittstelle zu überschreiben. Im umgekehrten Modus führt das Hinzufügen eines Links mit höherer Priorität zum Aggregator dazu, dass LACP eine Prioritätsneuberechnung durchführt und vom derzeit aktiven Link zum neuen aktiven Link wechselt.

VORSICHT:

Wenn an beiden Enden eines Aggregators der LACP-Verbindungsschutz 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 von dem aggregierten Ethernet-Bündel mit zwei Verbindungen kommt. Infolgedessen können Sie beobachten, dass das Gerät des Herstellers den Datenverkehr an die Backup-Mitgliedsverbindung 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 keinen Datenverkehr, der zur Backup-Verbindung zurückkehrt, während DPCE-R-Q-20GE-2XGE, DPCE-R-Q-20GE-SFP, DPCE-R-Q-40GE-SFP, DPCE-R-Q-Q-4XGE-XFP, DPCE-X-Q-40GE-SFP und DPCE-X-Q-4XGE-XFP den Datenverkehr löschen, der zum Backup-Link kommt.

Konfigurieren der LACP-Systempriorität

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

Die Systempriorität ist ein Binärwert mit 2 Oktetten, der Teil der LACP-System-ID ist. Die LACP-System-ID setzt sich aus der Systempriorität als den beiden höchstwertigen Oktetten und der Schnittstellen-MAC-Adresse als den sechs niederwertigsten Oktetten zusammen. 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 Anweisung system-id auf der [edit interfaces aeX aggregated-ether-options lacp] Hierarchieebene:

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

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

Konfigurieren des LACP-Administratorschlüssels

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

Anmerkung:

Sie müssen MC-LAG konfigurieren, um die Anweisung admin-key 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 Anweisung port-priority auf der [edit interfaces interface-name ether-options 802.3ad aeX lacp] Hierarchieebene oder [edit interfaces interface-name ether-options 802.3ad aeX lacp] :

Die Portpriorität ist ein Feld mit 2 Oktetten, das Teil der LACP-Port-ID ist. Die LACP-Port-ID setzt sich aus der Portpriorität als die beiden wichtigsten Oktette und der Portnummer als die beiden niederwertigsten Oktette 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 Portaggregation wird von jedem System auf der Grundlage der höchsten Portpriorität ausgewählt 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 in der Priorität nach unten gearbeitet.

Anmerkung:

Die Portaggregationsauswahl (siehe oben) wird für die aktive Verbindung durchgeführt, wenn der LACP-Verbindungsschutz 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 der [edit protocols lacp] Hierarchieebene ein:

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

  • all—Alle LACP-Rückverfolgungsvorgänge

  • configuration—Konfigurationscode

  • packet—Gesendete und empfangene Pakete

  • process—LACP-Prozessereignisse

  • protocol– LACP-Protokoll-Zustandsautomat

  • routing-socket– Routing-Socket-Ereignisse

  • startup– Verarbeiten von Startereignissen

LACP-Einschränkungen

LACP kann mehrere verschiedene physische Schnittstellen miteinander verknüpfen, 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 Linkaggregation verwenden, um die Ports eines PIC, das bis zu 16 Weiterleitungsklassen unterstützt, mit einem PIC zu verbinden, der bis zu 8 Weiterleitungsklassen unterstützt, unterstützt das resultierende LAG-Paket nur bis zu 8 Weiterleitungsklassen. Ebenso führt die Verknüpfung eines PIC, das WRED unterstützt, mit einem PIC, der es nicht unterstützt, zu einem LAG-Bundle, das WRED nicht unterstützt.

Beispiel: Aggregatiertes Ethernet-LACP konfigurieren

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.

Konfiguration aggregierter Ethernet-LACP über eine nicht getaggte Schnittstelle:

Anmerkung:

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

LACP mit nicht getaggtem aggregiertem Ethernet

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

Verifizierung
Verifizierung 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 funktioniert ist.

Überprüfen, ob LACP aktiv ist
Zweck

Überprüfen Sie, welche Schnittstellen am 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

Vergewissern Sie sich, dass der Ping zwischen den beiden EX-Switches funktioniert.

Aktion

Verwenden Sie den Befehl für den ping 10.1.1.2 count 2 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

Vergewissern Sie sich, dass LACP ordnungsgemäß eingerichtet wurde und dass die Bundle-Mitglieder LACP-Protokollpakete übertragen.

Überprüfen des LACP-Setups

Zweck

Vergewissern Sie sich, dass das LACP ordnungsgemäß eingerichtet wurde.

Aktion

So überprüfen Sie, ob LACP an einem Ende als aktiv 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 der gebündelte Link verfügbar ist.

Überprüfen, ob LACP-Pakete ausgetauscht werden

Zweck

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

Aktion

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

Bedeutung

Die Ausgabe hier zeigt, dass die Verbindung besteht und PDUs ausgetauscht werden.

Siehe auch

Grundlegendes zu unabhängigen Micro-BFD-Sitzungen für LAG

Das BFD-Protokoll (Bidirectional Forwarding Detection) ist ein einfaches Erkennungsprotokoll, mit dem Fehler in den Weiterleitungspfaden schnell erkannt werden können. 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 jeden LAG-Mitgliedslink 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 Mitgliedsverbindungen.

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 auf einer bestimmten Verbindung eingerichtet wurde, werden die Mitgliederlinks an die LAG angehängt und dann durch eine der folgenden Optionen ausgeglichen:

  • 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 ausgefallen ist, wird dieser bestimmte Mitgliedslink aus dem Load Balancer entfernt, und die LAG-Manager leiten den Datenverkehr nicht mehr an diesen Link weiter. Diese Mikro-BFD-Sitzungen sind unabhängig voneinander, obwohl sie einen einzigen Client haben, 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 von Routing-Geräten 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 erhält. Dies ermöglicht die schnelle Überprüfung der Member-Link-Konnektivität mit oder ohne LACP. Ein UDP-Port unterscheidet BFD über LAG-Pakete von BFD über Single-Hop-IP-Pakete. Die Internet Assigned Numbers Authority (IANA) hat 6784 als UDP-Zielport für Micro-BFD zugewiesen.

Nützt

  • 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 Mitgliedslink 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 auf einem aggregierten 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 Mikro-BFD-Sitzungen verwendet.

  • In Junos OS sind Mikro-BFD-Steuerpakete standardmäßig immer nicht markiert. Bei aggregierten Layer-2-Schnittstellen muss die Konfiguration bei der Konfiguration von aggregiertem Ethernet mit BFD Optionen flexible-vlan-tagging enthaltenvlan-tagging. Andernfalls löst 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 über die aggregierte 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 markierte 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. Beginnend mit Junos OS Version 16.1 können Sie diese Funktion auch auf Routern der MX-Serie mit aggregierter Ethernet-Schnittstellenadresse des Remote-Ziels als Nachbaradresse konfigurieren.

  • Beginnend mit Version 16.1R2 prüft und validiert Junos OS die konfigurierte Mikro-BFD local-address anhand der Schnittstelle oder Loopback-IP-Adresse, bevor die Konfiguration bestätigt wird. Junos OS führt diese Prüfung sowohl für IPv4- als auch für IPv6-Mikro-BFD-Adresskonfigurationen durch, und wenn sie nicht übereinstimmen, schlägt die Übertragung 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 LACP-Mindestverbindung 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 in die aggregierte Ethernet-Schnittstellen-IP-Adresse ändern. Das Ändern der lokalen und benachbarten Adresse, ohne vorher die aggregierte Ethernet-Schnittstelle zu deaktivieren bfd-liveness-detection , kann zu einem Fehler bei Mikro-BFD-Sitzungen führen.

Siehe auch

Konfigurieren von Micro-BFD-Sitzungen für LAG

Das BFD-Protokoll (Bidirectional Forwarding Detection) ist ein einfaches Erkennungsprotokoll, mit dem Fehler in den Weiterleitungspfaden schnell erkannt werden können. Eine Link Aggregation Group (LAG) kombiniert mehrere Verbindungen zwischen Geräten, die sich in Punkt-zu-Punkt-Verbindungen befinden, und erhöht dadurch die Bandbreite, sorgt für Zuverlässigkeit und ermöglicht Load Balancing. Um eine BFD-Sitzung auf LAG-Schnittstellen auszuführen, konfigurieren Sie eine unabhängige, asynchrone BFD-Sitzung auf jedem LAG-Mitgliedslink 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 Mitgliedsverbindungen.

Anmerkung:

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

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

  1. Fügen Sie die folgende Anweisung in die Konfiguration auf Hierarchieebene [edit interfaces aex aggregated-ether-options] ein:
  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

      • MD5 mit akribischen Tasten

      • SHA-1 mit akribischen Schlüsseln

      • simple-password

    • Um den Schlüsselbund zu konfigurieren, geben Sie den Namen an, der dem Sicherheitsschlüssel für die BFD-Sitzung zugeordnet ist. Der von Ihnen angegebene Name muss mit einem der Schlüsselbunde ü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. Verwenden Sie diese Option nur für Übergangszeiträume, 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 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 eine Trap aus.

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

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

    Sie können eine Zahl im Bereich von 0 bis 255.000 Millisekunden konfigurieren, und 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 Routing-Gerät BFD-Pakete überträgt, sowie das minimale Intervall, in dem das Routing-Gerät eine Antwort von einem Nachbarn erwartet, 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 auch die minimalen Sende- und Empfangsintervalle separat angeben.

  5. Konfigurieren Sie die Quelladresse 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.

    Anmerkung:

    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.

    Beginnend mit Version 16.1R2 prüft und validiert Junos OS den konfigurierten Micro-BFD local-address anhand der Schnittstelle oder Loopback-IP-Adresse, bevor die Konfiguration bestätigt wird. Junos OS führt diese Prüfung sowohl für IPv4- als auch für IPv6-Micro-BFD-Adresskonfigurationen durch, und wenn sie nicht übereinstimmen, schlägt die Übertragung fehl. Das konfigurierte Mikro-BFD local-address sollte mit dem auf dem Peer-Router konfigurierten Mikro-BFD neighbour-address übereinstimmen.
  6. Geben Sie das Mindestintervall an, das das Zeitintervall für das Senden und Empfangen von Daten angibt.

    Dieser Wert stellt das minimale Intervall dar, in dem das lokale Routing-Gerät BFD-Pakete überträgt, sowie das minimale Intervall, in dem das Routing-Gerät eine Antwort von einem Nachbarn erwartet, 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 auch die minimalen Sende- und Empfangsintervalle separat angeben.

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

    Anmerkung:

    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-Flapping führen.

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

    • Geben Sie für groß angelegte 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 Kundensupport von Juniper Networks, um weitere Informationen zu erhalten.

    • Damit BFD-Sitzungen während eines Routing-Engine-Switchover-Ereignisses aktiv bleiben, wenn aktives Nonstop-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-Routing sind die Empfehlungen für minimale Intervalle 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 Routing-Gerät eine Antwort von einem Nachbarn erwartet, 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 von dem Nachbarn empfangen wurden, der dazu führt, dass die ursprüngliche Schnittstelle 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 Anweisung ein:

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

    Anmerkung:

    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 Anweisung ein:

    Anmerkung:

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

    Wenn sich die BFD-Sitzungserkennungszeit 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 Minimum-Intervalls bzw. des Minimum-Empfangsintervall-Wertes. Der Schwellenwert muss ein höherer Wert als der Multiplikator für einen dieser konfigurierten Werte sein. Wenn das minimale Empfangsintervall beispielsweise 300 ms und der Multiplikator 3 beträgt, beträgt die Gesamterkennungszeit 900 ms. Daher muss der Schwellenwert für die Erkennungszeit einen Wert größer als 900 haben.

  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 Routing-Gerä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 die Sendeschwelle für die Erkennung der Anpassung des Sendeintervalls an, indem Sie die transmit-interval threshold folgende Anweisung einfügen:

    Der Schwellwert 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 Minimum-Intervalls bzw. des Minimum-Empfangsintervall-Wertes. 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.

Anmerkung:

  • Die 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

Grundlegendes zum Hashen des LAG-Bündels und zum ausgehenden Next-Hop-ECMP-Datenverkehr

Die EX-Serie und QFX-Serie von Juniper Networks verwenden einen Hashing-Algorithmus, um zu bestimmen, wie der Datenverkehr über ein Link Aggregation Group (LAG)-Paket 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 sowie einiger interner Werte wie der Quellport-ID und der Quellgeräte-ID. Sie können einige der Felder konfigurieren, die vom Hashing-Algorithmus verwendet werden.

Anmerkung:

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 zu treffen, der in ein LAG-Bündel eintritt, oder für den Datenverkehr, der einen Switch verlässt, wenn ECMP aktiviert ist.

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

Bei ECMP bestimmt der Hashing-Algorithmus, 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 einiger interner Werte wie der Quellport-ID und der Quellgeräte-ID. Die vom Hashing-Algorithmus verwendeten Paketfelder variieren je nach EtherType des Pakets und in einigen Fällen auch nach der 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 werden ebenfalls 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 Hashingalgorithmus verwendet werden, um Entscheidungen über die Weiterleitung des Datenverkehrs zu treffen. Sie können jedoch nicht konfigurieren, wie bestimmte Werte innerhalb eines Headers vom Hashing-Algorithmus 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 auf keinen anderen Parametern, einschließlich der Weiterleitungsentscheidung (Bridged oder Routing) oder der ausgehenden LAG-Bundle-Konfiguration (Layer 2 oder Layer 3).

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

  • Der Hashing-Algorithmus verwendet dieselben Felder zum Hashen von ECMP- und LAG-Datenverkehr, der Hashing-Algorithmus hasht jedoch ECMP- und LAG-Datenverkehr unterschiedlich. Für den LAG-Datenverkehr wird ein Trunk-Hash verwendet, während für ECMP ECMP-Hashing verwendet wird. Sowohl LAG als auch ECMP verwenden denselben RTAG7-Ausgangswert, verwenden jedoch unterschiedliche Offsets dieses 128B-Ausgangswerts, um Polarisation zu vermeiden. Die anfängliche Konfiguration der HASH-Funktion für die Verwendung des Trunk- und ECMP-Offsets wird zur PFE-Init-Zeit festgelegt. Das unterschiedliche Hashing stellt sicher, dass der Datenverkehr nicht polarisiert wird, wenn ein LAG-Paket 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 einer Virtual Chassis-Fabric (VCF) beteiligt ist oder nicht.

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

IP (IPv4 und IPv6)

Nutzlastfelder in IPv4- und IPv6-Paketen werden vom Hashing-Algorithmus verwendet, wenn IPv4- oder IPv6-Pakete auf einem Mitgliedslink 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 das Layer-2-Nutzlastfeld festgelegt. IPv4- und IPv6-Nutzlastfelder werden für das Hashing verwendet, wenn der Hash-Modus auf Layer-2-Nutzlast eingestellt ist.

Wenn der Hash-Modus auf 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 durch die Felder Quell-MAC-Adresse, Ziel-MAC-Adresse oder EtherType gehasht werden, müssen Sie den Hash-Modus auf Layer-2-Header festlegen.

In Tabelle 5 werden die IPv4- und IPv6-Nutzlastfelder angezeigt, die standardmäßig vom Hashing-Algorithmus verwendet werden.

  • ✓ – Das Feld wird standardmäßig vom Hashing-Algorithmus verwendet.

  • Χ – Das Feld wird standardmäßig nicht vom Hashing-Algorithmus 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 einem Mitgliedslink 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, Eingangs-Mod-ID und Eingangsport-ID

  • Für Broadcast, unbekannten Unicast und unbekannten Multicast-Datenverkehr auf LAG: Quell-MAC, Ziel-MAC, Eingangs-Mod-ID und Eingangsport-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

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

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-Datenstrom-Label (nur IPv6)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Eingangs-Mod-ID

✓

(konfigurierbar)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Eingangsport-ID

✓

(konfigurierbar)

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

Χ

MPLS

Der Hashing-Algorithmus hasht MPLS-Pakete mithilfe der Felder Quell-IP, Ziel-IP, MPLS-Label 0, MPLS-Label 1, MPLS-Label 2 und MPLS 3. Auf den QFX5110-, QFX5120- und QFX5200-Switches unterstützen LSR-Router auch ECMP. ECMP verwendet die folgenden 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 (die obersten 3 Labels) und Eingangsport-ID

In Tabelle 6 werden die MPLS-Nutzlastfelder angezeigt, die standardmäßig vom Hashing-Algorithmus verwendet werden:

  • ✓ – Das Feld wird standardmäßig vom Hashing-Algorithmus verwendet.

  • Χ – Das Feld wird standardmäßig nicht vom Hashing-Algorithmus verwendet.

Die Felder, die vom Hashing-Algorithmus für das MPLS-Pakethashing 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-Labels für das Hashing verwendet. Wenn das BoS-Flag im Paket nicht angezeigt wird, 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

Χ

Χ

Χ

Χ

Χ

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-Flow-Labor

Χ

Χ

Χ

Χ

Χ

MPLS-Label 0

Χ

✓

✓

✓

✓

MPLS-Label 1

✓

✓

✓

✓

✓

MPLS-Label 2

✓

✓

✓

✓

✓

MPLS-Label 3

✓

X

X

X

X

Eingangsport-ID

✓

(LSR und L2Circuit)

X

X

X

✓

(LSR und L2Circuit)

✓

(LSR und L2Circuit)

MAC-in-MAC-Pakethashing

Pakete, die den MAC-in-MAC-EtherTyp verwenden, werden vom Hashing-Algorithmus unter Verwendung der Felder Layer-2-Nutzlastquellen-MAC, Layer-2-Nutzlast-Ziel-MAC und Layer-2-Nutzlast-EtherTyp 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 des MAC-in-MAC-EtherType wird in früheren Versionen nicht unterstützt.

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

  • ✓ – Das Feld wird standardmäßig vom Hashing-Algorithmus verwendet.

  • Χ – Das Feld wird standardmäßig nicht vom Hashing-Algorithmus verwendet.

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

Field

EX3400

EX4300

QFX5100

QFX5110 and QFX5120

QFX5200

Layer-2-Nutzlastquelle MAC

✓

✓

✓

✓

✓

Layer 2-Nutzlast-Ziel-MAC

✓

✓

✓

✓

✓

Layer-2-Nutzlast-Ethertyp

✓

✓

✓

✓

✓

Layer 2-Nutzlast: Äußeres 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 Hashing-Algorithmus verwendet.

  • Χ – Das Feld wird standardmäßig nicht vom Hashing-Algorithmus 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)

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 Zeile von Switches die Hashing-Parameter für die vorhandenen implementierten Algorithmen ändern. Sie können den Schwellenwert für freigegebene 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 für das Hashen von LAG-Bundle- und ECMP-Datenverkehr (CLI-Verfahren)

Switches der EX-Serie 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 Hashing-Algorithmus verwendet werden.

Die Konfiguration der vom Hashing-Algorithmus verwendeten Felder ist nützlich in Szenarien, in denen der größte Teil des Datenverkehrs, der in das Paket eingeht, ä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 Hashingalgorithmus optimieren, um Hashing-Entscheidungen effizienter zu treffen, indem Sie den Algorithmus so konfigurieren, dass Hashing-Entscheidungen nur anhand dieser Felder getroffen werden.

Anmerkung:

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 so, dass Felder im Layer-2-Header für das Hashing verwendet werden:

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

    Der Standard-Hash-Modus ist Layer-2-Nutzlast. Daher muss dieser Schritt ausgefü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 Hashing-Algorithmus die Werte in den Feldern "Ziel-MAC-Adresse", "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 Sie no-destination-mac-address, no-ether-typeoder no-source-mac-addresskonfigurieren.

    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 Hashing-Algorithmus das Feld "Ethertype" nicht für das Hashing verwendet, gehen Sie wie folgt vor:

Konfigurieren des Hashalgorithmus 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 Layer 2-Nutzlast:

    Die IP-Nutzlast wird vom Hashing-Algorithmus nur überprüft, wenn der Hash-Modus auf Layer-2-Nutzlast festgelegt ist. Der Standard-Hash-Modus ist Layer-2-Nutzlast.

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

    Wenn Sie beispielsweise möchten, dass der Hashing-Algorithmus die Felder "Layer-4-Zielport", "Layer-4-Quellport" und "Protokoll" ignoriert und stattdessen Datenverkehr basierend auf den IPv4-Quell- und -Zieladressen hasht:

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

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

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

    Die IPv6-Nutzlast wird vom Hashing-Algorithmus nur überprüft, wenn der Hash-Modus auf Layer-2-Nutzlast eingestellt ist. Der Standard-Hash-Modus ist Layer-2-Nutzlast.

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

    Wenn Sie beispielsweise möchten, dass der Hashing-Algorithmus die Felder "Layer 4-Zielport", "Layer-4-Quellport" und "Nächster Header" ignoriert und stattdessen Datenverkehr nur basierend auf den Feldern "IPv6-Quelle" und "IPv6-Zieladresse" hasht:

Konfigurieren anderer Hashing-Parameter

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

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

Siehe auch

Tabellarischer Änderungsverlauf

Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Funktionen entdecken , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.

Loslassen
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 über die aggregierte 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
In der QFX5000 Zeile von 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 fungiert.
16.1
Beginnend mit Version 16.1R2 prüft und validiert Junos OS den konfigurierten Micro-BFD local-address anhand der Schnittstelle oder Loopback-IP-Adresse, bevor die Konfiguration bestätigt wird.
14,1 X 53-D25
Ab Junos OS Version 14.1X53-D25 kann der 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.