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 Paketweiterleitungs-Engine (Packet Forwarding Engine, PFE) eine Suche durch, um den nächsten Hop der Weiterleitung zu identifizieren. Wenn es mehrere Equal-Cost-Pfade (ECMPs) zum gleichen Ziel des nächsten Hops 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, z. B. aggregiertem Ethernet, erforderlich sein. Die Auswahl des tatsächlichen Weiterleitungs-Next-Hops basiert auf dem Ergebnis der Hash-Berechnung über ausgewählte Paket-Header-Felder und mehrere interne Felder wie den Schnittstellenindex. Sie können einige der Felder konfigurieren, die vom Hashalgorithmus verwendet werden.

  • Konfigurieren Sie bei Routern der MX-Serie mit MPCs (Modular Port Concentrators) und FPCs vom Typ 5 den Hash für die unterstützten Datenverkehrstypen auf Hierarchieebene forwarding-options enhanced-hash-key . Details dazu, welche Felder für welche Verkehrsdatenfamilie standardmäßig 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 durch Setzen der entsprechenden no- Befehle deaktiviert werden.

  • Konfigurieren Sie bei Routern 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.

  • Lastenausgleich pro Präfix : Jedes Präfix wird nur einem Weiterleitungs-Next-Hop 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 Datenfluss bezeichnen). Weitere Informationen finden Sie unter Konfigurieren des Load Balancing pro Paket .

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

  • Per-Packet Random Spray Load Balancing – Wenn die adaptive Load-Balancing-Option fehlschlägt, dient der Random Spray Load Balancing pro Paket als letzter Ausweg. Es stellt sicher, dass die Mitglieder von ECMP gleichmäßig belastet werden, ohne die Bandbreite zu berücksichtigen. Pro Paket bewirkt eine Neuanordnung von Paketen und wird daher nur empfohlen, wenn die Anwendungen die Neuanordnung übernehmen. Das zufällige Sprühen pro Paket eliminiert ein Ungleichgewicht im Datenverkehr, das aufgrund von Softwarefehlern auftritt, mit Ausnahme von Paket-Hash.

    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 den zufälligen Lastausgleich pro Paket konfigurieren.

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

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

      Ab Junos OS Version 20.1R1 verteilt ALB den Datenverkehr auf MPCs der MX-Serie auf aggregierten Ethernet-Bundles gleichmäßig auf mehrere eingehende Packet Forwarding Engines (PFE) auf derselben Linecard. In früheren Versionen war ALB auf eine einzige PFE beschränkt, während der Datenverkehr in einem AE-Bundle 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 zum Gesamtlastniveau der ECMP-Verbindung beigetragen wird, und ergreift dann Korrekturmaßnahmen, wenn der Schwellenwert erreicht ist.

      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 .

    Hinweis:

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

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

Darüber hinaus stehen mehrere zusätzliche Konfigurationsoptionen zur Verfügung:

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

  • Symmetrischer Lastenausgleich: Diese Methode bietet symmetrischen Lastenausgleich für eine 802.3ad-LAG. Der für den symmetrischen Lastenausgleich verwendete Hash wird auf der interface Ebene der Hierarchie festgelegt. Es stellt sicher, dass ein bestimmter Fluss des Duplexdatenverkehrs dieselben Geräte in beide Richtungen durchläuft, und ist auf Routern der MX-Serie verfügbar.

MX MPC und T-Serie Typ 5 FPC-Besonderheiten

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

Um eine mögliche Neuanordnung von Paketen zu vermeiden, werden Layer-4-Transportprotokollports niemals bei der Hashberechnung für fragmentierte IPv4-Pakete verwendet. Dies gilt für das erste Fragment des Datenflusses, das durch das more fragment Bit in einem Header identifiziert wird, und alle nachfolgenden Fragmente, die durch einen Fragmentoffset ungleich Null identifiziert werden. Das erste Fragment und die nachfolgenden Fragmente werden immer über denselben Next-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 Hash-Berechnung zu Ergebnissen, die gut genug für eine gerechte Verteilung des Datenverkehrs sind. In Fällen wie IP-in-IP- oder GRE-Tunneling reichen die Feldinformationen der Schichten 3 und 4 allein jedoch möglicherweise nicht aus, um einen Hash mit ausreichender Entropie für den Lastenausgleich zu erzeugen. In einer Bereitstellung, in der Router der MX-Serie beispielsweise GRE-Flows übertragen, treten die GRE-Kapselungstunnel in der Regel als einzelner Flow mit derselben Quelle und demselben Ziel und demselben GRE-Schlüssel auf. Fette Ströme können auch das Ungleichgewicht bei der Verbindungsauslastung deutlich erhöhen, da das Verkehrsaufkommen über die Tunnel zunimmt. Ein weiteres Beispiel ist die Verwendung von MX PE-Routern als VPLS PE-Geräte in einer Teilnehmer-Edge-Bereitstellung, bei der die Router den Breitbandteilnehmerdatenverkehr von den Zugangsgeräten zu einem zentralen Breitbandnetzwerk-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 Teilnehmer-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 dem äußeren IP-Paket nicht um ein fragmentiertes Paket (erstes Fragment oder ein nachfolgendes Fragment) handelt und das innere Paket IPv4 oder IPv6 ist, werden bei GRE-Paketen zusätzlich zu den äußeren Quell- und Zieladressen die Quell- und Zieladressen aus dem inneren Paket in der Hashberechnung 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 ist (erstes Fragment oder ein beliebiges nachfolgendes Fragment). Wenn das äußere IP-Paket kein Fragmentpaket ist und das innere Paket MPLS ist, wird das obere innere Label in die Hashberechnung einbezogen.

  • Wenn bei PPPoE-Paketen das innere Paket IPv4 oder IPv6 ist, werden die Quell- und Zieladressen des inneren Pakets 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. Das Einschließen 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 Flussbezeichnungsfeld des IPv6-Headers in die Hashberechnung einbezogen. RFC 6437 beschreibt das 20-Bit-Flussbezeichnungsfeld im IPv6-Header. Legen Sie die no-flow-label Option in der forwarding-options enhanced-hash-key family inet6 Hierarchie fest, um den neuen Standardwert zu deaktivieren.

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

Die Listen zeigen die Felder, die bei der Hashberechnung für nicht fragmentierte Pakete in Junos 18.3R1 und höher 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.

  • IPv4, GRE

    • GRE-Schlüssel

    • Quell- und Zieladresse; Symmetrischen

    • Protokoll

    • DSCP (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • IPv4 in IPv4, GRE

    • Nutzdaten (inneres IPv4: Quell- und Zielports, IP-Adressen); Symmetrischen

    • GRE-Schlüssel

      GRE-Protokoll = IPv4

    • Quell- und Zieladresse; Symmetrischen

    • Protokoll

    • DSCP (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • IPv6 in IPv4, GRE

    • Nutzlast (inneres IPv6: Quell- und Zielports, IP-Adressen); Symmetrischen

    • GRE-Schlüssel

      GRE-Protokoll = IPv6

    • Quell- und Zieladresse; Symmetrischen

    • Protokoll

    • DSCP (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • MPLS in IPv4, GRE

    • Nutzlast (inneres MPLS: Top-Label)

    • GRE-Schlüssel

      GRE-Protokoll = MPLS

    • Quell- und Zieladresse; Symmetrischen

    • Protokoll

    • DSCP (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • IPv4, L2TPv2 für 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 davon abrät, diese Option standardmäßig zu aktivieren. Dies liegt daran, dass die L2TP-Sitzungsidentifikation auf der Übereinstimmung des Ziel-UDP-Ports (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 genau ist.

    • Sitzungs-ID

    • Tunnel-ID

    • Quell- und Zielport

    • Quell- und Zieladresse; Symmetrischen

    • Protokoll (UDP)

    • DSCP (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

Hash-Felder für GRE-Datenverkehr, 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; Symmetrischen

    • Nächster Header

    • Flussbezeichnung (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

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

    • Nutzdaten (inneres IPv4: Quell- und Zielports, IP-Adressen); Symmetrischen

    • GRE-Schlüssel

      GRE-Protokoll = IPv4

    • Quell- und Zieladresse; Symmetrischen

    • Nächster Header

    • Flussbezeichnung (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

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

    • Nutzlast (inneres IPv6: Quell- und Zielports, IP-Adressen); Symmetrischen

    • GRE-Schlüssel

      GRE-Protokoll = IPv6

    • Quell- und Zieladresse; Symmetrischen

    • Nächster Header

    • Flussbezeichnung (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

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

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

    • GRE-Schlüssel

      GRE-Protokoll = MPLS

    • Quell- und Zieladresse; Symmetrischen

    • Nächster Header

    • Flow-Etikett

    • Datenverkehrsklasse (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

Für IPv4 verwendete Hash-Felder

Die Liste zeigt die Felder, 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; Symmetrischen

    • Protokoll

    • DSCP (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • IPv4, TCP und UDP, nicht fragmentierte Pakete

    • Quell- und Zielport; Symmetrischen

    • Quell- und Zieladresse; Symmetrischen

    • Protokoll

    • DSCP (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • IPv4, PPTP

    • 16 niederwertigste Bits des GRE-Schlüssels

    • Quell- und Zieladresse; Symmetrischen

    • Protokoll

    • DSCP (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

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

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

    • GTP TEID (deaktiviert)

    • Quell- und Zielport

    • Quell- und Zieladresse; Symmetrischen

    • Protokoll

    • DSCP (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

Für IPv6 verwendete Hash-Felder

Die Liste zeigt die Felder, 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; Symmetrischen

    • Nächster Header

    • Flussbezeichnung (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • IPv6, nicht fragmentiertes TCP- und UDP-Paket

    • Quell- und Zielport; Symmetrischen

    • Quell- und Zieladresse; Symmetrischen

    • Nächster Header

    • Flussbezeichnung (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • IPv6, PPTP

    • 16 niederwertigste Bits des GRE-Schlüssels

    • Quell- und Zieladresse; Symmetrischen

    • Nächster Header

    • Flussbezeichnung (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index der eingehenden 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 davon abrät, diese Option standardmäßig zu aktivieren. Dies liegt daran, dass die GTP-Sitzungsidentifikation auf der Übereinstimmung des Ziel-UDP-Ports (2152) basiert und dieser Port möglicherweise nicht ausschließlich für den GTP-Transport verwendet wird, sodass die Extraktion des TEID-Feldes aus dem Paket möglicherweise nicht immer genau ist.

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

    • Quell- und Zielport

    • Quell- und Zieladresse; Symmetrischen

    • Nächster Header

    • Flussbezeichnung (Junos 18.3 und höher)

    • Datenverkehrsklasse (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

Hash-Felder, die für Multiservice verwendet werden

Die Multiservice-Hash-Konfiguration der Familie gilt für Pakete, die als family ccc, vplsoder bridge. 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ßeres 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; Symmetrischen

    • Index der eingehenden Schnittstelle (deaktiviert)

  • Ethernet, IPv4

    • Nutzdaten (inneres IPv4: Quell- und Zielports, IP-Adressen); Symmetrischen

    • Äußeres 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; Symmetrischen

    • Index der eingehenden Schnittstelle (deaktiviert)

  • Ethernet, IPv6

    • Nutzlast (inneres IPv6: Quell- und Zielports, IP-Adressen); Symmetrischen

    • Äußeres 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; Symmetrischen

    • Index der eingehenden Schnittstelle (deaktiviert)

  • Ethernet, MPLS

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

    • Äußeres 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; Symmetrischen

    • Index der eingehenden Schnittstelle (deaktiviert)

  • IPv4 in PPPoE (Datenpaket)

    • Nutzdaten (inneres IPv4: Quell- und Zielports, IP-Adressen); Symmetrischen

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

    • Äußeres 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; Symmetrischen

    • Index der eingehenden Schnittstelle (deaktiviert)

  • IPv6 in PPPoE (Datenpaket)

    • Nutzlast (inneres IPv6: Quell- und Zielports, IP-Adressen); Symmetrischen

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

    • Äußeres 802.1p (deaktiviert)

    • Quell- und Ziel-MAC; Symmetrischen

    • Index der eingehenden Schnittstelle (deaktiviert)

Hash-Felder, die für MPLS, Junos 18.3 und höher 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

    • Nutzdaten (inneres IPv4: Quell- und Zielports, IP-Adressen); Symmetrischen

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

    • Label 1..16 (20 Bit)

    • Äußeres Label EXP (deaktiviert)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • MPLS, IPv4 oder IPv6 in Ethernet-Pseudodraht

    • Nutzlast (IPv4/IPv6 in Ethernet-Pseudo-Wire)

    • Label 2..16 (20 Bit)

    • Äußeres Label EXP (deaktiviert)

    • Label 1 (20 Bit)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • MPLS, MPLS in Ethernet-Pseudodraht

    • Nutzlast (zwei Top-Labels des MPLS-Label-Stack-Eintrags in Ethernet-Pseudo-Wire)

    • Label 2..16 (20 Bit)

    • Äußeres Label EXP (deaktiviert)

    • Label 1 (20 Bit)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • MPLS, Entropie-Label

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

    • Label 1..16 (20 Bit)

    • Äußeres Label EXP (deaktiviert)

    • Index der eingehenden 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

    • Nutzdaten (inneres IPv4: Quell- und Zielports, IP-Adressen); Symmetrischen

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

    • Label 2.8 (20 Bit)

      Äußeres Label EXP (deaktiviert)

      Label 1 (20 Bit)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • MPLS, IPv4 oder IPv6 in Ethernet-Pseudodraht

    • Nutzlast (IPv4/IPv6 in Ethernet-Pseudo-Wire)

    • Label 2.8 (20 Bit)

      Äußeres Label EXP (deaktiviert)

      Label 1 (20 Bit)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • MPLS, MPLS in Ethernet-Pseudodraht

    • Nutzlast (zwei Top-Labels des MPLS-Label-Stack-Eintrags in Ethernet-Pseudo-Wire)

    • Label 2..16 (20 Bit)

    • Äußeres Label EXP (deaktiviert)

    • Label 1 (20 Bit)

    • Index der eingehenden Schnittstelle (deaktiviert)

  • MPLS, Entropie-Label

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

    • Label 2.8 (20 Bit)

      Äußeres Label EXP (deaktiviert)

      Label 1 (20 Bit)

    • Index der eingehenden 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

Enthält IPv6-Flow-Label, inneren GRE-Header und inneren PPPoE in der Standard-Hash-Berechnung.

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-Nutzlast-Hash mit Steuerwort.

Führt quellen- und zielbasiertes Hashing ein.

15.1R1

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

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

14.2R3

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

14.2R2

Bietet ein aggregiertes Ethernet-Paket mit 10G-, 40G- und 100G-Verbindungen.

14.1R1

Entkoppelt die Erstellung von aeX-Schnittstellen von ch agg eth dev.

Vergrößert den aggregierten Namensraum für Ethernet-Schnittstellen.

Bietet adaptiven Lastenausgleich für ECMP Next Hops.

13.3R1

Enthält Verbesserungen für adaptives, paketzufälliges und periodisches Rebalancing.

11.4R1

bietet Lastverteilung über ECMP Next Hops.