Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Grundlegendes zum Algorithmus für den Lastenausgleich des Datenverkehrs auf Routern der MX-Serie

Wenn ein Paket auf der Eingangsschnittstelle eines Geräts empfangen wird, führt die Packet Forwarding Engine (PFE) eine Suche nach dem nächsten Hop durch, der die Weiterleitung durchführt. Wenn es mehrere ECMPs (Equal-Cost Paths) zum selben Ziel für den nächsten Hop gibt, kann die Eingangs-PFE so konfiguriert werden, dass der Datenstrom auf die nächsten Hops verteilt wird. Ebenso kann eine Verteilung des Datenverkehrs zwischen den Mitgliedsverbindungen einer aggregierten Schnittstelle, wie z. B. aggregiertem Ethernet, erforderlich sein. Die Auswahl des eigentlichen Weiterleitungs-Next-Hops basiert auf dem Ergebnis der Hash-Berechnung über ausgewählte Paket-Header-Felder und mehrere interne Felder wie z. B. den Schnittstellenindex. Sie können einige der Felder konfigurieren, die vom Hashing-Algorithmus verwendet werden.

  • Konfigurieren Sie für Router der MX-Serie mit MPCs (Modular Port Concentrators) und FPCs vom Typ 5 den Hash für die unterstützten Datenverkehrstypen auf der forwarding-options enhanced-hash-key Hierarchieebene. Details dazu, welche Felder standardmäßig für welche Verkehrsfamilie enthalten sind, finden Sie weiter unten.

    In Junos OS Version 18.3R1 wurde die Standardmethode zur Berechnung des erweiterten Hashs geändert, um eine verbesserte Entropie für IP-Tunnel, IPv6-Datenströme und PPPoE-Nutzlasten bereitzustellen, die als Familien-Multiservice übertragen werden. Diese Standardeinstellungen können deaktiviert werden, indem die entsprechenden no-Befehle gesetzt werden.

  • Konfigurieren Sie für Router der MX-Serie mit DPCs den Hash für die unterstützten Datenverkehrstypen auf Hierarchieebene forwarding-options hash-key .

Junos unterstützt verschiedene Arten des Load Balancing.

  • Load Balancing pro Präfix : Jedes Präfix wird nur einem nächsten Hop für die Weiterleitung zugeordnet.

  • Load Balancing pro Paket: Alle Next-Hop-Adressen für ein Ziel in der aktiven Route werden in der Weiterleitungstabelle installiert (der Begriff Load Balancing pro Paket in Junos entspricht dem, was andere Anbieter als Load Balancing pro Datenstrom bezeichnen). Weitere Informationen finden Sie unter Konfigurieren des Load Balancing pro Paket .

  • Zufälliges Load Balancing von Paketen: Die nächsten Hops werden nach dem Zufallsprinzip für jedes Paket ausgewählt. Diese Methode ist auf MX-Routern mit MPC-Linecards für aggregierte Ethernet-Schnittstellen und ECMP-Pfade verfügbar. Um das zufällige Spray-Load Balancing pro Paket zu konfigurieren, schließen Sie die per-packet Anweisung auf der [edit interfaces aex aggregated-ether-options load-balance] Hierarchieebene ein. Weitere Informationen finden Sie unterBeispiel: Konfigurieren des aggregierten Ethernet-Lastenausgleichs.

  • Zufälliges Spray-Load Balancing pro Paket : Wenn die adaptive Load-Balancing-Option fehlschlägt, dient das paketbasierte Random-Spray-Load Balancing als letzter Ausweg. Es stellt sicher, dass die Mitglieder des ECMP gleichmäßig belastet werden, ohne die Bandbreite zu berücksichtigen. "Pro Paket" führt zu einer Neuordnung der Pakete und wird daher nur empfohlen, wenn die Anwendungen die Neuordnung absorbieren. Das zufällige Spray pro Paket eliminiert ein Ungleichgewicht im Datenverkehr, das als Folge von Softwarefehlern auftritt, mit Ausnahme des Paket-Hashs.

    Ab Junos OS Version 20.2R1 können Sie auf MX240-, MX480- und MX960-Routern mit MPC10E-Linecard (MPC10E-15C-MRATE und MPC10E-10C-MRATE) und MX2010- und MX2020-Routern mit MX2K-MPC11E-Linecard ein zufälliges Load Balancing pro Paket konfigurieren.

  • Adaptives Load Balancing – Adaptive Load Balancing (ALB) ist eine Methode, die ein echtes Ungleichgewicht im Datenverkehr korrigiert, indem ein Feedback-Mechanismus verwendet wird, um den Datenverkehr über die Verbindungen in einem aggregierten Ethernet-Bundle und auf ECMP-Next-Hops (Equal-Cost Multipath) zu verteilen. ALB optimiert die Verteilung des Datenverkehrs, wenn die Datenverkehrsraten der Paketströme stark variieren. ALB verwendet einen Feedback-Mechanismus, um ein Ungleichgewicht der Datenverkehrslast zu korrigieren, indem die Bandbreite und die Paketströme auf Links innerhalb eines AE-Bündels angepasst werden.

    • ALB auf mehreren Packet Forwarding Engines für aggregierte Ethernet-Bundles

      Ab Junos OS Version 20.1R1 verteilt ALB auf MPCs der MX-Serie den Datenverkehr auf aggregierten Ethernet-Bundles gleichmäßig auf mehrere eingehende Packet Forwarding Engines (PFE) auf derselben Linecard. In früheren Versionen war ALB auf eine einzelne PFE beschränkt, während der Datenverkehr in einem AE-Bündel neu verteilt wurde. Dies wirkte sich auf Flexibilität und Redundanz aus. ALB ist standardmäßig deaktiviert.

      Sie können ALB konfigurieren, indem Sie die adaptive Anweisung auf Hierarchieebene [edit interfaces ae-interface aggregated-ether-options load-balance] festlegen.

      Weitere Informationen finden Sie unter Konfigurieren des adaptiven Lastenausgleichs.

    • ALB auf mehreren PFEs für ECMP Next Hops

      Ab Junos OS Version 20.1R1 können Sie ALB für ECMP-Next-Hops über mehrere Eingangs-PFEs auf derselben Linecard konfigurieren, um eine gleichmäßige Verteilung des Datenverkehrs und Redundanz zu gewährleisten. In früheren Versionen war ALB für ECMP Next Hops auf eine einzelne PFE beschränkt. Diese Einschränkung wirkte sich auf Flexibilität und Redundanz aus. ALB überwacht dynamisch die Datenverkehrslast, die von jedem Datenstrom im Verhältnis zur Gesamtbelastung der ECMP-Verbindung beigesteuert wird, und ergreift dann Korrekturmaßnahmen, wenn der Schwellenwert erreicht wird.

      Sie können ALB für ECMP-Next-Hops konfigurieren, indem Sie den ecmp-alb Befehl unter der [edit chassis] Hierarchieebene konfigurieren.

      Weitere Informationen finden Sie unter ecmp-alb .

    Anmerkung:

    ALB funktioniert für mehrere PFEs, die sich auf derselben Linecard befinden. Diese Funktion wird für PFEs, die sich auf unterschiedlichen Linecards befinden, nicht unterstützt.

    Bei PFEs, die sich auf unterschiedlichen Linecards befinden, kann eingehender Datenverkehr zu einer ungleichmäßigen Belastung der Ausgangsports führen, selbst wenn ALB aktiviert ist.

Mehrere zusätzliche Konfigurationsoptionen sind ebenfalls verfügbar:

  • Konfiguration der Hash-Funktion pro Steckplatz : Diese Methode basiert auf einem eindeutigen Load-Balance-Hashwert für jeden PIC-Steckplatz und ist nur für Router der M120-, M320- und MX-Serie mit DPCE- und MS-DPC-Linecards gültig.

  • Symmetrisches Load Balancing : Diese Methode bietet symmetrisches Load Balancing auf einer 802.3ad-LAG. Der für den symmetrischen Load Balancing verwendete Hash wird auf der interface Ebene der Hierarchie festgelegt. Es stellt sicher, dass ein bestimmter Duplex-Datenverkehrsstrom dieselben Geräte in beide Richtungen durchläuft und ist auf Routern der MX-Serie verfügbar.

    Anmerkung: Auf Geräten der MX-Serie ab Junos OS Version 25.2R1 ist der Datenverkehr in der AE, auf die von den ECMP-Links verwiesen wird, möglicherweise nicht gleichmäßig verteilt, wenn symmetrisches Load Balancing aktiviert ist und ECMP mehrstufiges Load Balancing über AE-Bundles verwendet. Das ECMP-Load Balancing der ersten Ebene wird weiterhin gleichmäßig verteilt.

MX MPC und T-Serie Typ 5 FPC – Spezifika

Der Hash-Berechnungsalgorithmus auf MPC- und Typ-5-FPCs der T-Serie liefert identische Ergebnisse für Pakete mit vertauschten Layer-3-Adressen oder Layer-4-Transportports. Beispielsweise ist das Ergebnis der Hash-Berechnung für ein Paket mit der Quelladresse 192.0.2.1 und der Zieladresse 203.0.113.1 identisch mit dem Ergebnis der Hash-Berechnung für ein Paket mit der Quelladresse 203.0.113.1 und der Zieladresse 192.0.2.1.

Um eine mögliche Neuordnung der Pakete zu vermeiden, werden Layer-4-Transportprotokollports bei der Hash-Berechnung für fragmentierte IPv4-Pakete niemals verwendet. Dies gilt für das erste Fragment des Flusses, das durch das Bit in einem Header identifiziert wird, und für alle nachfolgenden Fragmente, die durch einen more fragment Fragmentversatz ungleich Null gekennzeichnet sind. Das erste Fragment und die nachfolgenden Fragmente werden immer über denselben nächsten Hop weitergeleitet.

Hashing-Algorithmus für Junos 18.3R1 und höher

In den meisten Fällen führt die Einbeziehung von Layer-3- und Layer-4-Feldinformationen in die Hashberechnung zu Ergebnissen, die für eine gerechte Verteilung des Datenverkehrs ausreichen. In Fällen wie IP-in-IP oder GRE-Tunneling reichen die Layer-3- und Layer-4-Feldinformationen allein jedoch möglicherweise nicht aus, um einen Hash mit ausreichender Entropie für das Load Balancing zu erzeugen. In einer Bereitstellung beispielsweise, in der Router der MX-Serie GRE-Datenströme durchlaufen, werden die GRE-Kapselungstunnel in der Regel als einzelner Datenstrom mit derselben Quelle und demselben Ziel sowie demselben GRE-Schlüssel ausgeführt. Fat-Flows können auch das Ungleichgewicht bei der Auslastung der Verbindungen deutlich erhöhen, wenn das Datenverkehrsvolumen über die Tunnel zunimmt. Ein weiteres Beispiel ist, wenn MX PE-Router als VPLS PE-Geräte in einer Anwender-Edge-Bereitstellung verwendet werden, bei der die Router den Breitband-Teilnehmerdatenverkehr von den Zugriffsgeräten zu einem zentralen Breitband-Netzwerk-Gateway (BNG) zurückleiten. In einem solchen Fall stehen nur die MAC-Adressen des Teilnehmers und die MAC-Adressen des BNG-Routers für das Hashing zur Verfügung. Bei wenigen BNG-MACs und relativ wenigen Anwender-MACs reichen die typischen Layer-3- und Layer-4-Felder jedoch nicht aus, um einen Hash für ein optimales Load Balancing zu erstellen.

Daher hat sich die Standardberechnung enhanced-hash-key für Router der MX-Serie mit Trio-MPCs und Junos OS Version 18.3R1 oder höher geändert. Eine Zusammenfassung der Änderungen finden Sie hier:

  • Wenn es sich bei GRE-Paketen bei dem äußeren IP-Paket nicht um ein fragmentiertes Paket (erstes Fragment oder ein beliebiges nachfolgendes Fragment) handelt und das innere Paket IPv4 oder IPv6 ist, werden bei der Hash-Berechnung zusätzlich zu den äußeren Quell- und Zieladressen die Quell- und Zieladressen verwendet. Layer-4-Ports des inneren Pakets sind ebenfalls enthalten, wenn das Protokoll des inneren IP-Pakets TCP oder UDP ist und das innere IP-Paket kein Fragment (erstes Fragment oder ein nachfolgendes Fragment) ist. Wenn das äußere IP-Paket kein Fragmentpaket und das innere Paket MPLS ist, wird das obere innere Label in die Hash-Berechnung einbezogen.

  • Wenn es sich bei PPPoE-Paketen um IPv4 oder IPv6 handelt, werden die Quell- und Zieladressen aus dem inneren Paket eingeschlossen. Layer-4-Ports sind enthalten, wenn das Protokoll des inneren IP-Pakets TCP oder UDP ist und das innere IP-Paket kein Fragment ist. Die Aufnahme der inneren PPPoE-Paketfelder kann deaktiviert werden, indem die no-payload Option auf Hierarchieebene forwarding-options enhanced-hash-key family multiservice konfiguriert wird.

  • Bei IPv6 wird das Datenstrom-Label-Feld des IPv6-Headers in die Hash-Berechnung einbezogen. RFC 6437 beschreibt das 20-Bit-Flow-Label-Feld im IPv6-Header. Legen Sie die no-flow-label Option in der Hierarchie forwarding-options enhanced-hash-key family inet6 fest, um die neue Standardeinstellung zu deaktivieren.

Hash-Felder für GRE-Datenverkehr, der über IPv4 gesendet wird

Die Listen zeigen die Felder, die bei der Hash-Berechnung für nicht fragmentierte Pakete in Junos 18.3R1 und höher verwendet wurden. Standardmäßig wird das Feld in der Hash-Berechnung verwendet, sofern nicht anders angegeben. Außerdem sind die im Hash verwendeten IP- und Port-Felder symmetrisch, d. h., das Vertauschen der Felder ändert das Hash-Ergebnis nicht.

  • IPv4, GRE

    • GRE-Schlüssel

    • Quell- und Zieladresse; symmetrisch

    • Protokoll

    • DSCP (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv4 in IPv4, GRE

    • Nutzlast (innere IPv4: Quell- und Zielports, IP-Adressen); symmetrisch

    • GRE-Schlüssel

      GRE-Protokoll = IPv4

    • Quell- und Zieladresse; symmetrisch

    • Protokoll

    • DSCP (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv6 in IPv4, GRE

    • Nutzlast (innere IPv6: Quell- und Zielports, IP-Adressen); symmetrisch

    • GRE-Schlüssel

      GRE-Protokoll = IPv6

    • Quell- und Zieladresse; symmetrisch

    • Protokoll

    • DSCP (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • MPLS in IPv4, GRE

    • Nutzlast (inneres MPLS: Top-Label)

    • GRE-Schlüssel

      GRE-Protokoll = MPLS

    • Quell- und Zieladresse; symmetrisch

    • Protokoll

    • DSCP (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv4, L2TPv2 in Junos 17.2 und höher

    Die Einbeziehung der L2TPv2-Tunnel-ID und der Sitzungs-ID kann durch Konfigurieren der forwarding-options enhanced-hash-key family inet l2tp-tunnel-session-identifier Option aktiviert werden. Beachten Sie, dass Juniper nicht empfiehlt, diese Option standardmäßig zu aktivieren. Dies liegt daran, dass die L2TP-Sitzungsidentifizierung auf der Ziel-UDP-Portübereinstimmung (1701) basiert und dieser Port möglicherweise nicht ausschließlich für den L2TP-Transport verwendet wird, sodass die Extraktion der Tunnel- und Sitzungs-ID-Felder aus dem Paket möglicherweise nicht immer korrekt ist.

    • Sitzungs-ID

    • Tunnel-ID

    • Quell- und Zielport

    • Quell- und Zieladresse; symmetrisch

    • Protokoll (UDP)

    • DSCP (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

Hash-Felder, die für GRE-Datenverkehr verwendet werden, der über IPv6 gesendet wird

Die Liste zeigt die Felder, die bei der Hash-Berechnung für nicht fragmentierte Pakete verwendet werden. Standardmäßig wird das Feld in der Hash-Berechnung verwendet, sofern nicht anders angegeben. Außerdem sind die im Hash verwendeten IP- und Port-Felder symmetrisch, d. h., das Vertauschen der Felder ändert das Hash-Ergebnis nicht.

  • IPv6, GRE

    • GRE-Schlüssel

    • Quell- und Zieladresse; symmetrisch

    • Nächste Überschrift

    • Flow-Label (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv4 in IPv6, GRE (Junos 18.3 und höher)

    • Nutzlast (innere IPv4: Quell- und Zielports, IP-Adressen); symmetrisch

    • GRE-Schlüssel

      GRE-Protokoll = IPv4

    • Quell- und Zieladresse; symmetrisch

    • Nächste Überschrift

    • Flow-Label (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv6 in IPv6, GRE (Junos 18.3 und höher)

    • Nutzlast (innere IPv6: Quell- und Zielports, IP-Adressen); symmetrisch

    • GRE-Schlüssel

      GRE-Protokoll = IPv6

    • Quell- und Zieladresse; symmetrisch

    • Nächste Überschrift

    • Flow-Label (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • MPLS in IPv6, GRE (Junos 18.3 und höher)

    • Nutzlast (inneres MPLS: Top-Labels); symmetrisch

    • GRE-Schlüssel

      GRE-Protokoll = MPLS

    • Quell- und Zieladresse; symmetrisch

    • Nächste Überschrift

    • Flow-Label

    • Datenverkehrsklasse (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

Für IPv4 verwendete Hash-Felder

In der Liste werden die Felder angezeigt, die bei der Hash-Berechnung für nicht fragmentierte Pakete verwendet werden, sofern nicht anders angegeben. Standardmäßig wird das Feld in der Hash-Berechnung verwendet, sofern nicht anders angegeben. Außerdem ist der Hash der IP- und Port-Felder symmetrisch, d. h., das Vertauschen der Felder ändert das Hash-Ergebnis nicht.

  • IPv4, nicht TCP oder UDP oder fragmentierte Pakete

    • Quell- und Zieladresse; symmetrisch

    • Protokoll

    • DSCP (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv4, TCP und UDP, nicht fragmentierte Pakete

    • Quell- und Zielport; symmetrisch

    • Quell- und Zieladresse; symmetrisch

    • Protokoll

    • DSCP (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv4, PPTP

    • Die 16 niederwertigsten Bits des GRE-Schlüssels

    • Quell- und Zieladresse; symmetrisch

    • Protokoll

    • DSCP (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv4-, GTP-, UDP-Datenverkehr zum Zielport 2152

    Die Einbeziehung des GPRS Tunneling Protocol (GTP) Tunnel Endpoint Identifier (TEID) kann mit der forwarding-options enhanced-hash-key family inet gtp-tunnel-endpoint-identifier Option aktiviert werden. Beachten Sie, dass Juniper nicht empfiehlt, diese Option standardmäßig zu aktivieren. Dies liegt daran, dass die GTP-Sitzungsidentifizierung auf der Ziel-UDP-Port-Übereinstimmung (2152) basiert und dieser Port möglicherweise nicht ausschließlich für den GTP-Transport verwendet wird, sodass die Extraktion des TEID-Felds aus dem Paket möglicherweise nicht immer korrekt ist.

    • GTP TEID (deaktiviert)

    • Quell- und Zielport

    • Quell- und Zieladresse; symmetrisch

    • Protokoll

    • DSCP (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

Für IPv6 verwendete Hash-Felder

In der Liste werden die Felder angezeigt, die bei der Hash-Berechnung für nicht fragmentierte Pakete verwendet werden, sofern nicht anders angegeben. Standardmäßig wird das Feld in der Hash-Berechnung verwendet, sofern nicht anders angegeben. Außerdem ist der Hash der IP- und Port-Felder symmetrisch, d. h., das Vertauschen der Felder ändert das Hash-Ergebnis nicht.

  • IPv6, Nicht-TCP- und UDP-Paket oder TCP- und UDP-Paket, das vom Absender fragmentiert wurde

    • Quell- und Zieladresse; symmetrisch

    • Nächste Überschrift

    • Flow-Label (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv6, nicht fragmentiertes TCP- und UDP-Paket

    • Quell- und Zielport; symmetrisch

    • Quell- und Zieladresse; symmetrisch

    • Nächste Überschrift

    • Flow-Label (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv6, PPTP

    • Die 16 niederwertigsten Bits des GRE-Schlüssels

    • Quell- und Zieladresse; symmetrisch

    • Nächste Überschrift

    • Flow-Label (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv6, GTP

    Die Einbeziehung des GPRS Tunneling Protocol (GTP) Tunnel Endpoint Identifier (TEID) kann auf Hierarchieebene forwarding-options enhanced-hash-key family inet gtp-tunnel-endpoint-identifier aktiviert werden. Beachten Sie, dass Juniper nicht empfiehlt, diese Option standardmäßig zu aktivieren. Dies liegt daran, dass die GTP-Sitzungsidentifizierung auf der Ziel-UDP-Port-Übereinstimmung (2152) basiert und dieser Port möglicherweise nicht ausschließlich für den GTP-Transport verwendet wird, sodass die Extraktion des TEID-Felds aus dem Paket möglicherweise nicht immer korrekt ist.

    • GTP TEID (standardmäßig deaktiviert; auf Hierarchieebene forwarding-options enhanced-hash-key family inet gtp-tunnel-endpoint-identifier aktivieren.

    • Quell- und Zielport

    • Quell- und Zieladresse; symmetrisch

    • Nächste Überschrift

    • Flow-Label (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

Hashfelder, die für Multiservice verwendet werden

Die Multiservice-Hash-Konfiguration der Familie gilt für Pakete, die als family ccc, vplsoder bridgein den Router eingehen. Die Liste zeigt die Felder, die bei der Hash-Berechnung für nicht fragmentierte Pakete verwendet werden. Standardmäßig wird das Feld in der Hash-Berechnung verwendet, sofern nicht anders angegeben. Außerdem sind die im Hash verwendeten IP- und Port-Felder symmetrisch, d. h., das Vertauschen der Felder ändert das Hash-Ergebnis nicht.

  • Ethernet, Nicht-IP oder Nicht-MPLS

    Falls konfiguriert, werden Nutzlastinformationen aus nicht getaggten Paketen oder Paketen mit bis zu zwei VLAN-Tags extrahiert.

    • Äußerer 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; symmetrisch

    • Index für eingehende Schnittstelle (deaktiviert)

  • Ethernet, IPv4

    • Nutzlast (innere IPv4: Quell- und Zielports, IP-Adressen); symmetrisch

    • Äußerer 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; symmetrisch

    • Index für eingehende Schnittstelle (deaktiviert)

  • Ethernet, IPv6

    • Nutzlast (innere IPv6: Quell- und Zielports, IP-Adressen); symmetrisch

    • Äußerer 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; symmetrisch

    • Index für eingehende Schnittstelle (deaktiviert)

  • Ethernet, MPLS

    • Nutzlast (inneres MPLS: obere Labels plus innere IPv4- und IPv6-Felder); symmetrisch. Weitere Informationen finden Sie unter Hash-Felder für MPLS, Junos 18.3 und höher weiter unten.

    • Äußerer 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; symmetrisch

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv4 in PPPoE (Datenpaket)

    • Nutzlast (innere IPv4: Quell- und Zielports, IP-Adressen); symmetrisch

    • PPP-Protokoll IPv4 Version 0x1, Typ 0x1

    • Äußerer 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; symmetrisch

    • Index für eingehende Schnittstelle (deaktiviert)

  • IPv6 in PPPoE (Datenpaket)

    • Nutzlast (innere IPv6: Quell- und Zielports, IP-Adressen); symmetrisch

    • PPP-Protokoll IPv6 Version 0x1, Typ 0x1

    • Äußerer 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; symmetrisch

    • Index für eingehende Schnittstelle (deaktiviert)

Hash-Felder für MPLS, Junos 18.3 und höher

Die Liste zeigt die Felder, die bei der Hash-Berechnung für nicht fragmentierte Pakete verwendet werden. Standardmäßig wird das Feld in der Hash-Berechnung verwendet, sofern nicht anders angegeben. Außerdem sind die im Hash verwendeten IP- und Port-Felder symmetrisch, d. h., das Vertauschen der Felder ändert das Hash-Ergebnis nicht.

  • MPLS, gekapseltes IPv4 oder IPv6

    • Nutzlast (innere IPv4: Quell- und Zielports, IP-Adressen); symmetrisch

    • Nutzlast (innere IPv6: Quell- und Zielports, IP-Adressen, nächster Header); symmetrisch

    • Beschriftung 1..16 (20 Bit)

    • Äußeres Etikett EXP (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

  • MPLS, IPv4 oder IPv6 in Ethernet Pseudowire

    • Nutzlast (IPv4/IPv6 in Ethernet, Pseudowire)

    • Etikett 2..16 (20 Bit)

    • Äußeres Etikett EXP (deaktiviert)

    • Etikett 1 (20 Bit)

    • Index für eingehende Schnittstelle (deaktiviert)

  • MPLS, MPLS in Ethernet-Pseudowire

    • Nutzlast (zwei obere Labels des MPLS-Label-Stack-Eintrags in Ethernet-Pseudowire)

    • Etikett 2..16 (20 Bit)

    • Äußeres Etikett EXP (deaktiviert)

    • Etikett 1 (20 Bit)

    • Index für eingehende Schnittstelle (deaktiviert)

  • MPLS, Entropie-Label

    Wenn eine Entropiebezeichnung erkannt wird, wird das Nutzlastfeld nicht verarbeitet, und der Indikator wird nicht in die Hashberechnung einbezogen

    • Beschriftung 1..16 (20 Bit)

    • Äußeres Etikett EXP (deaktiviert)

    • Index für eingehende Schnittstelle (deaktiviert)

Hash-Felder, die für MPLS von Junos 14.1 bis Junos 18.3 verwendet werden

Die Liste zeigt die Felder, die bei der Hash-Berechnung für nicht fragmentierte Pakete verwendet werden. Standardmäßig wird das Feld in der Hash-Berechnung verwendet, sofern nicht anders angegeben. Außerdem sind die im Hash verwendeten IP- und Port-Felder symmetrisch, d. h., das Vertauschen der Felder ändert das Hash-Ergebnis nicht.

  • MPLS, gekapseltes IPv4 oder IPv6

    • Nutzlast (innere IPv4: Quell- und Zielports, IP-Adressen); symmetrisch

      Nutzlast (innere IPv6: Quell- und Zielports, IP-Adressen, nächster Header); symmetrisch

    • Etikett 2.8 (20 Bit)

      Äußeres Etikett EXP (deaktiviert)

      Etikett 1 (20 Bit)

    • Index für eingehende Schnittstelle (deaktiviert)

  • MPLS, IPv4 oder IPv6 in Ethernet Pseudowire

    • Nutzlast (IPv4/IPv6 in Ethernet, Pseudowire)

    • Etikett 2.8 (20 Bit)

      Äußeres Etikett EXP (deaktiviert)

      Etikett 1 (20 Bit)

    • Index für eingehende Schnittstelle (deaktiviert)

  • MPLS, MPLS in Ethernet-Pseudowire

    • Nutzlast (zwei obere Labels des MPLS-Label-Stack-Eintrags in Ethernet-Pseudowire)

    • Etikett 2..16 (20 Bit)

    • Äußeres Etikett EXP (deaktiviert)

    • Etikett 1 (20 Bit)

    • Index für eingehende Schnittstelle (deaktiviert)

  • MPLS, Entropie-Label

    Wenn eine Entropiebezeichnung erkannt wird, wird das Nutzlastfeld nicht verarbeitet, und der Indikator wird nicht in die Hashberechnung einbezogen

    • Etikett 2.8 (20 Bit)

      Äußeres Etikett EXP (deaktiviert)

      Etikett 1 (20 Bit)

    • Index für eingehende Schnittstelle (deaktiviert)

Liste der Junos-Updates für Hash-Berechnung und Load Balancing für Router der MX-Serie mit MPCs

Tabelle 1: Liste der Updates für Router der MX-Serie

Junos Release

Change

18.3R1

Umfasst IPv6-Datenstrombezeichnung, inneren GRE-Header und inneres PPPoE in der Standard-Hashberechnung.

Erhöht die MPLS-Etikettenstapeltiefe auf 16 Etiketten.

17.2R1

Load Balancing für L2TP-gekapselte IPv4- und IPv6-Pakete.

16.1R1

Enthält EoMPLS-Payload-Hash mit Steuerwort.

Führt quellen- und nur-zielbasiertes Hashing ein.

15.1R1

Ermöglicht die gezielte Verteilung statischer Schnittstellen über AE-Member-Links.

Schließt Quelle, Ziel und MAC der MPLS-gekapselten PPPoE-Nutzlast in die Standard-Hash-Berechnung ein.

14.2R3

Erhöht die Skalierung von LAG und MC-LAG.

14.2R2

Bietet ein aggregiertes Ethernet-Bündel mit 10G-, 40G- und 100G-Verbindungen.

14.1R1

Entkoppelt die aeX-Schnittstellenerstellung von ch agg eth dev.

Vergrößert den aggregierten Namespace der Ethernet-Schnittstelle.

Bietet adaptives Load Balancing für ECMP-Next Hops.

13.3R1

Enthält Verbesserungen für adaptives, paketbasiertes und regelmäßiges Load Balancing mit erneutem Rebalancing.

11.4R1

Bietet Lastverteilung über ECMP Next Hops hinweg.