Auf dieser Seite
Load Balancing von MPLS-Datenverkehr
Konfigurieren von Load Balancing auf Basis von MPLS-Labeln
Load Balancing erfolgt paketbezogen für MPLS-Datenströme auf unterstützten Plattformen. Entropie oder zufällige Verteilung ist für die einheitliche Verteilung von Paketen an ihre nächsten Hops unerlässlich. Wenn Load Balancing zur Verteilung des Datenverkehrs verwendet wird, verwendet Junos OS standardmäßig einen Hash-Algorithmus, um eine Next-Hop-Adresse auszuwählen, die in die Weiterleitungstabelle installiert werden soll. Wenn sich der Satz der nächsten Hops für ein Ziel ändert, wird die Next-Hop-Adresse mithilfe des Hash-Algorithmus neu gewählt. Sie können konfigurieren, wie der Hash-Algorithmus zum Lastausgleich des Datenverkehrs über eine Reihe von Label Switched Paths (LSPs zu gleichen Kosten) verwendet wird.
Um die Entropie des VPLS- und VPWS-Datenverkehrs zu gewährleisten, kann Junos OS einen Hash basierend auf Daten aus dem IP-Header und bis zu drei MPLS-Labeln (den sogenannten Top-Labeln) erstellen.
In einigen Fällen kann die Anzahl der Netzwerkfunktionen, die Label verwenden (wie MPLS Fast Reroute und RFC 3107, RSVP und VPN), die Daten in den drei wichtigsten Labeln statisch und daher nicht ausreichend für Entropie werden. Das Load Balancing kann dadurch verfeinigt werden, oder die Inzidenz von ungeordneten Paketen kann steigen. Für diese Fälle können Label vom unteren Rand des Labelstacks verwendet werden (siehe Tabelle 1, unten für Qualifikationen). Obere und untere Label können nicht gleichzeitig verwendet werden.
MPC-Karten unterstützen die reguläre Hash-Schlüsselkonfiguration nicht. Damit die MPC-basierte Hash-Schlüsselkonfiguration effektiv ist, benötigen Sie eine enhanced-hash-key Konfiguration.
Load Balancing wird verwendet, um den Datenverkehr gleichmäßig zu verteilen, wenn die folgenden Bedingungen gelten:
Es gibt mehrere next Hops zu gleichen Kosten über verschiedene Schnittstellen zum selben Ziel.
Es gibt einen einzelnen nächsten Hop über eine aggregierte Schnittstelle.
Ein LSP neigt dazu, seine Platzierung zu lastausgleichen, indem er zufällig einen der zu gleichen Kosten bezogenen nächsten Hops wählt und ihn ausschließlich verwendet. Die zufällige Auswahl erfolgt unabhängig an jedem Transit-Router, der die Metriken des Interior Gateway Protocol (IGP) allein vergleicht. Bandbreiten oder Überlastungen werden nicht berücksichtigt.
Diese Funktion gilt für aggregierte Ethernet- und aggregierte SONET/SDH-Schnittstellen sowie mehrere mpls Next Hops zu gleichen Kosten. Darüber hinaus können Sie das Load Balancing für IPv4-Datenverkehr über Layer-2-Ethernet-Pseudowires nur für die T-Serie, MX-Serie, M120 und M320-Router konfigurieren. Sie können auch Load Balancing für Ethernet-Pseudowires basierend auf IP-Informationen konfigurieren. Die Option, IP-Informationen in den Hash-Schlüssel einzubeziehen, bietet Unterstützung für Ethernet Circuit Cross-Connect (CCC)-Verbindungen.
Konfigurieren Sie die Anweisung, um einen Lastausgleich basierend auf den MPLS-Labelinformationen zu erhalten family mpls :
[edit forwarding-options hash-key] family mpls { all-labels; bottom-label-1; bottom-label-2; bottom-label-3; label-1; label-2; label-3; no-labels; no-label-1-exp; payload { ether-pseudowire; ip { disable; layer-3-only; port-data { destination-lsb; destination-msb; source-lsb; source-msb; } } } }
Sie können diese Anweisung auf den folgenden Hierarchieebenen einschließen:
[edit forwarding-options hash-key]
Tabelle 1 bietet detaillierte Informationen zu allen möglichen MPLS-LSP-Load-Balancing-Optionen.
Anweisung |
Unterstützte Plattformen |
MPLS LSP Load Balancing-Optionen |
|---|---|---|
|
MX-Serie und PTX-Serie |
Vor Junos OS Version 19.1R1 waren bis zu acht MPLS-Label in den Hash-Schlüssel enthalten, um die Eindeutigkeit eines Datenstroms in der Packet Forwarding Engine zu identifizieren. Auf Routern der PTX-Serie wird dieser Wert standardmäßig festgelegt. Ab Junos OS Version 19.1R1 sind für Router der MX-Serie mit MPC- und MIC-Schnittstellen bis zu sechzehn eingehende MPLS-Label in der Hash-Taste enthalten. |
|
MX-Serie mit DPC (I-Chip). Nicht unterstützt auf M10i, M7i und M120. |
Verwendet das label bottom-most für die Berechnung der Hash-Taste, z. B. wenn die Top-Label nicht genügend Variable für die erforderliche Ebene der Entropie bereitstellen. |
|
MX-Serie mit DPC (I-Chip). Nicht unterstützt auf M10i, M7i und M120. |
Verwendet das zweite Label von unten für die Berechnung der Hash-Taste, z. B. wenn die Top-Label nicht genügend Variable für die erforderliche Ebene der Entropie bereitstellen. |
|
MX-Serie mit DPC (I-Chip). Nicht unterstützt auf M10i, M7i und M120. |
Verwendet das dritte Label von unten für die Berechnung der Hash-Taste, z. B. wenn die Top-Label nicht genügend Variable für die erforderliche Ebene der Entropie bereitstellen. |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie das erste Label in die Hash-Taste ein. Verwenden Sie diese Option für Pakete mit einzelnen Labeln. |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie das zweite Label in die Hash-Taste ein. Sie müssen die |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie das dritte Label in die Hash-Taste ein. Sie müssen auch die |
|
Alle Prüfungsgutscheine von |
Schließt MPLS-Label vom Hashschlüssel aus. |
|
M-Serie, MX-Serie, T-Serie |
Schließt das EXP-Bit des obersten Labels von der Hash-Taste aus. Sie müssen die Bei Layer-2-VPNs kann der Router auf ein Problem mit der Paketneuordnung stoßen. Wenn ein Überlastung des Datenverkehrs die Bandbreite des Kunden überschreitet, um seine Grenzen zu überschreiten, kann der Datenverkehr im mittleren Datenfluss beeinträchtigt werden. Pakete können dadurch neu sortiert werden. Indem Sie das EXP-Bit von der Hash-Taste ausschließen, können Sie dieses Problem mit der Neuordnung vermeiden. |
|
Alle Prüfungsgutscheine von |
Ermöglicht es Ihnen zu konfigurieren, welche Teile der IP-Paketnutzlast in den Hashschlüssel enthalten sein sollen. Für den Paketübertragungs-Router der PTX-Serie ist dieser Wert standardmäßig festgelegt. |
|
PTX-Serie |
Ip-Payload vom Hashschlüssel ausschließen. |
|
M120, M320, MX-Serie, T-Serie |
Lastausgleich von IPv4-Datenverkehr über Layer-2-Ethernet-Pseudowires. |
|
Alle Prüfungsgutscheine von |
Fügen Sie die IPv4- oder IPv6-Adresse in den Hashschlüssel ein. Sie müssen auch entweder |
|
Alle Prüfungsgutscheine von |
Fügen Sie nur die Layer-3-IP-Informationen in den Hashschlüssel ein. Schließt alle |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie die Feldinformationen des Quell- und Zielports ein. Standardmäßig werden im Hash-Schlüssel das bedeutendste Byte und das geringste Byte der Quell- und Zielportfelder verwendet. Um bestimmte Bytes auszuwählen, die im Hashschlüssel verwendet werden sollen, schließen Sie eine oder mehrere der Optionen , |
|
M-Serie, MX-Serie, T-Serie |
Schließen Sie das geringste Byte des Zielports in den Hash-Schlüssel ein. Kann mit jeder der anderen |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie das bedeutendste Byte des Ziel-Ports in den Hash-Schlüssel ein. Kann mit jeder der anderen |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie das geringste Byte des Quell-Ports in den Hashschlüssel ein. Kann mit jeder der anderen |
|
M-Serie, MX-Serie, T-Serie |
Nehmen Sie das bedeutendste Byte des Quell-Ports in den Hash-Schlüssel ein. Kann mit jeder der anderen |
In den folgenden Beispielen wird veranschaulicht, wie Sie MPLS LSP Load Balancing konfigurieren können:
So fügen Sie die IP-Adresse sowie das erste Label in die Hash-Taste ein:
Konfigurieren Sie für Router der M-, MX- und T-Serie die
label-1Anweisung und dieipOption für diepayloadAnweisung auf Hierarchieebene[edit forwarding-options hash-key family mpls]:[edit forwarding-options hash-key family mpls] label-1; payload { ip; }Bei Paketübertragungs-Routern der PTX-Serie sind die
all-labelsOptionen standardmäßigip payloadkonfiguriert, sodass keine Konfiguration erforderlich ist.
(nur Router der M320- und T-Serie) Um die IP-Adresse sowie die erste und zweite Bezeichnung in den Hashschlüssel einzubeziehen, konfigurieren Sie die
label-1optionen undlabel-2dieipOption für diepayloadAnweisung auf Hierarchieebene[edit forwarding-options hash-key family mpls]:[edit forwarding-options hash-key family mpls] label-1; label-2; payload { ip; }HINWEIS:Sie können diese Kombination von Aussagen nur auf Routern der M320- und T-Serie einschließen. Wenn Sie sie in einen Multiservice Edge-Router der M-Serie einbinden, werden im Hash-Schlüssel nur das erste MPLS-Label und die IP-Payload verwendet.
Stellen Sie bei Routern der T-Serie ein korrektes Load Balancing sicher, indem Sie den
label-1,label-2undlabel-3die[edit forwarding-options hash-key family mpls]Optionen auf Hierarchieebene einbesteigen:[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
(Nur Router der M-, MX- und T-Serie) Bei Layer-2-VPNs kann der Router auf ein Problem mit der Paketneuordnung stoßen. Wenn ein Überlastung des Datenverkehrs die Bandbreite des Kunden überschreitet, um seine Grenzen zu überschreiten, kann der Datenverkehr im mittleren Datenfluss beeinträchtigt werden. Pakete können dadurch neu sortiert werden. Indem Sie das EXP-Bit von der Hash-Taste ausschließen, können Sie dieses Problem mit der Neuordnung vermeiden. Um das EXP-Bit des ersten Labels aus den Hash-Berechnungen auszuschließen, fügen Sie die
no-label-1-expAnweisung auf[edit forwarding-options hash-key family mpls]Hierarchieebene ein:[edit forwarding-options hash-key family mpls] label-1; no-label-1-exp; payload { ip; }
Beispiel: Load-Balanced MPLS-Netzwerk
Wenn Sie mehrere RSVP-LSPs für denselben Ausgangsrouter konfigurieren, wird der LSP mit der niedrigsten Metrik ausgewählt und transportiert den gesamten Datenverkehr. Wenn alle LSPs dieselbe Kennzahl haben, wird eine der LSPs zufällig ausgewählt und der gesamte Datenverkehr darüber weitergeleitet. Um den Datenverkehr gleichmäßig auf alle LSPs zu verteilen, können Sie das Load Balancing auf den Eingangs- oder Transitroutern konfigurieren, je nach Art des konfigurierten Load Balancing.
Abbildung 1 veranschaulicht ein MPLS-Netzwerk mit vier LSPs, die auf demselben Ausgangsrouter konfiguriert sind (R0). Load Balancing wird auf dem Eingangsrouter R1konfiguriert. Das Beispielnetzwerk verwendet Open Shortest Path First (OSPF) als Interior Gateway Protocol (IGP) mit OSPF-Bereich 0.0.0.0. Für den CSPF-LSP (Constrained Shortest Path First), der Standard für Junos OS, ist eine IGP erforderlich. Darüber hinaus verwendet das Beispielnetzwerk eine Richtlinie, um BGP-Datenverkehr zu erstellen.
Das dargestellte Abbildung 1 Netzwerk besteht aus den folgenden Komponenten:
Eine Full-Mesh-BGP(IBGP)-Topologie mit AS 65432
MPLS und RSVP auf allen Routern aktiviert
Eine Send-Statics-Richtlinie auf Routern R1 , R0 die es ermöglicht, eine neue Route in das Netzwerk zu veröffentlichen
Vier unidirektionale LSPs zwischen R1 und und R0, und ein Umkehrrichtungs-LSP zwischen R0 und R1, die bidirektionalen Datenverkehr ermöglichen
Load Balancing auf Eingangsrouter konfiguriert R1
Das angezeigte Abbildung 1 Netzwerk ist ein BGP Full-Mesh-Netzwerk. Da Routenreflektoren und Konföderationen nicht zur Verbreitung von BGP-erlernten Routen verwendet werden, muss jeder Router eine BGP-Sitzung haben, in der jeder andere Router BGP ausführt.
Routerkonfigurationen für das lastausgleichene MPLS-Netzwerk
- Zweck
- Aktion
- Beispielausgabe 1
- Beispielausgabe 2
- Beispielausgabe 3
- Beispielausgabe 4
- Beispielausgabe 5
- Beispielausgabe 6
- Bedeutung
Zweck
Die Konfigurationen in diesem Thema gelten für die sechs lastausgleichenden Router im Beispielnetzwerk, die in Load-Balancing-Netzwerktopologie veranschaulicht werden.
Aktion
Verwenden Sie den folgenden Junos OS CLI-Betriebsmodusbefehl, um die Konfiguration eines Routers anzuzeigen:
user@host> show configuration | no-more
Beispielausgabe 1
Die folgende Konfigurationsausgabe ist für Edge-Router R6.
user@R6> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.16.14/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.10.12.1/24;
}
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.148/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.6.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.6.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
}
protocols {
rsvp {
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.6.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/2.0;
interface fe-1/3/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Beispielausgabe 2
Die folgende Konfigurationsausgabe ist für den Eingangsrouter R1.
user@R1> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.13/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-0/1/2 {
unit 0 {
family inet {
address 10.0.16.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.143/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 100.100.1.0/24 reject; #Static route for send-statics policy
}
router-id 192.168.1.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
forwarding-table {
export lbpp; #Routes exported to forwarding table
}
}
protocols {
rsvp {
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path lsp 1 { #First LSP
to 192.168.0.1; # Destination of the LSP
install 10.0.90.14/32 active; # The prefix is installed in the
primary via-r4; # inet.0 routing table
}
label-switched-path lsp2 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r2;
}
label-switched-path lsp3 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r2;
}
label-switched-path lsp4 {
to 192.168.0.1;
install 10.0.90.14/32 active;
primary via-r4;
}
path via-r2 { #Primary path to spread traffic across interfaces
10.0.29.2 loose;
}
path via-r4 {
10.0.24.2 loose;
}
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
export send-statics; #Allows advertising of a new route
group internal {
type internal;
local-address 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface fe-0/1/2.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
policy-options { #Load balancing policy
policy-statement lbpp {
then {
load-balance per-packet;
}
}
policy-statement send-statics { #Static route policy
term statics {
from {
route-filter 100.100.1.0/24 exact;
}
then accept;
}
}
}
Beispielausgabe 3
Die folgende Konfigurationsausgabe ist für Transit-Router R2.
user@R2> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.1/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.0.29.1/30;
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.12.14/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.144/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.2.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
}
protocols {
rsvp {
interface so-0/0/1.0;
interface fe-0/1/0.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface fe-0/1/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.2.1;
neighbor 192.168.1.1;
neighbor 192.168.4.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Beispielausgabe 4
Die folgende Konfigurationsausgabe ist für Transit-Router R4.
user@R4> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.0.24.2/30;
}
family mpls; # MPLS enabled on relevant interfaces
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.0.49.1/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.146/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.4.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.4.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.4.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.0.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/1.0;
interface so-0/0/3.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Beispielausgabe 5
Die folgende Konfigurationsausgabe ist für Transit-Router R9.
user@R9> show configuration | no-more
[...Output truncated...]
interfaces {
so-0/0/2 {
unit 0 {
family inet {
address 10.0.29.2/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.0.49.2/30;
}
family mpls;
}
}
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.90.13/30;
}
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.69.206/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.9.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
router-id 192.168.9. 1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface fxp0.0 {
disable;
}
}
mpls {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.9.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
neighbor 192.168.0.1;
neighbor 192.168.6.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fe-0/1/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
Beispielausgabe 6
Die folgende Konfigurationsausgabe ist für Den Ausgangsrouter R0.
user@R0> show configuration | no-more
[...Output truncated...]
interfaces {
fe-0/1/0 {
unit 0 {
family inet {
address 10.0.90.14/30;
}
family mpls; #MPLS enabled on relevant interfaces
}
}
fe-1/3/0 {
unit 0 {
family inet {
address 10.10.11.1/24;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.69.207/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.1/32;
}
}
}
}
routing-options {
static {
[...Output truncated...]
route 100.100.10.0/24 reject; #Static route for send-statics policy
}
router-id 192.168.0.1; #Manually configured RID
autonomous-system 65432; #Full mesh IBGP
}
protocols {
rsvp {
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path r0-r6 {
to 192.168.6.1;
}
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface fxp0.0 {
disable;
}
}
bgp {
group internal {
type internal;
local-address 192.168.0.1;
export send-statics; #Allows advertising of a new route
neighbor 192.168.9.1;
neighbor 192.168.6.1;
neighbor 192.168.1.1;
neighbor 192.168.2.1;
neighbor 192.168.4.1;
}
}
ospf { #IGP enabled
traffic-engineering;
area 0.0.0.0 {
interface fe-0/1/0.0;
interface fe-1/3/0.0;
interface lo0.0 {
passive; #Ensures protocols do not run over this interface
}
}
}
}
policy-options {
policy-statement send-statics {
term statics {
from {
route-filter 100.100.10.0/24 exact;
}
then accept;
}
}
}
Bedeutung
Die Beispielausgaben 1 bis 6 zeigen die Basisschnittstellen, Routing-Optionen, Protokolle und Richtlinienoptionenkonfigurationen für alle sechs Router in dem im Beispiel dargestellten Beispielnetzwerk: Load-Balanced-MPLS-Netzwerk.
Alle Router im Netzwerk haben MPLS, RSVP und BGP-aktiviert. OSPF ist als IGP konfiguriert, und die relevanten Schnittstellen verfügen über grundlegende IP-Informationen und MPLS-Unterstützung.
Darüber hinaus verfügen alle Router über die manuelle Konfiguration der Router-ID (RID) auf Hierarchieebene [edit routing-options] , um doppelte RID-Probleme zu vermeiden. Die passive Anweisung ist in der OSPF-Konfiguration enthalten, um sicherzustellen, dass Die Protokolle nicht über die Loopback () Schnittstelle ausgeführtlo0 werden und dass die Loopback (lo0) Schnittstelle im gesamten Netzwerk korrekt angekündigt wird.
Beispielausgaben 1, 3, 4 und 5 für R6, R2, , R4und R9 zeigen die Basiskonfiguration für Transit-Label-switched Router. Die Basiskonfiguration umfasst alle Schnittstellen, die für MPLS, den RID manuell konfiguriert und die relevanten Protokolle (RSVP, MPLS, BGP und OSPF) aktiviert sind.
Die Beispielausgabe 2 vom Eingangsrouter R1 zeigt die Basiskonfiguration plus vier LSPs (lsp1 durch lsp4) Konfiguration auf R0. Die vier LSPs sind mit verschiedenen primären Pfaden konfiguriert, die einen losen Hop für R4lsp1 und , und lsp4durch R2 für lsp2 und lsp3angeben.
Um Datenverkehr zu erstellen, R1 hat eine statische Route (100.100.1.0/24) konfiguriert auf [edit routing-options static route] Hierarchieebene. Das Präfix ist in der Send-Statics-Richtlinie auf Hierarchieebene [edit policy-options send statics] enthalten, sodass die Routen zu BGP-Routen werden können.
Darüber hinaus wird auf dem Eingangsrouter R1das Load Balancing mit der per-packet Option konfiguriert, und die Richtlinie wird auf Hierarchieebene [edit routing-options forwarding-table] exportiert.
Die Beispielausgabe 6 vom Ausgangsrouter R0 zeigt einen LSP (r0-r6), der zur R6 Erstellung bidirektionalen Datenverkehrs verwendet wird. OSPF erfordert bidirektionale LSP-Erreichbarkeit, bevor es den LSP in der IGP bekannt gibt. Obwohl der LSP in der IGP angekündigt wird, erfolgen keine Hallo-Nachrichten oder Routing-Updates über den LSP – nur Der Benutzerdatenverkehr wird über den LSP gesendet. Der Router verwendet seine lokale Kopie der IGP-Datenbank, um die bidirektionale Erreichbarkeit zu überprüfen.
Darüber hinaus R0 hat eine statische Route (100.100.10.0/24) konfiguriert auf [edit routing-options static route] Hierarchieebene. Das Präfix ist in der Send-Statics-Richtlinie auf Hierarchieebene [edit policy-options send statics] enthalten, sodass die Routen zu BGP-Routen werden können.
Konfigurieren von Load Balancing auf Basis von MPLS-Labeln auf Routern der ACX-Serie
Tabelle 2 bietet detaillierte Informationen zu allen möglichen MPLS-LSP-Load-Balancing-Optionen.
Router der ACX-Serie können einen Lastausgleich pro Paket in MPLS bereitstellen. Load Balancing kann sowohl auf Informationen im IP-Header als auch auf bis zu drei MPLS-Labeln durchgeführt werden, was eine einheitlichere Verteilung des MPLS-Datenverkehrs an next Hops ermöglicht. Diese Funktion ist standardmäßig auf unterstützten Plattformen aktiviert und erfordert keine Konfiguration.
Load Balancing wird verwendet, um den Datenverkehr gleichmäßig zu verteilen, wenn es einen einzelnen Nächsten Hop über eine aggregierte Schnittstelle oder ein LAG-Paket gibt. Load Balancing mit MPLS-Labeln wird nur für LAG-Schnittstellen und nicht für ECMP-Verbindungen (Equal-Cost Multipath) unterstützt.
Wenn Load Balancing zur Verteilung des Datenverkehrs verwendet wird, verwendet Junos OS standardmäßig einen Hash-Algorithmus, um eine Next-Hop-Adresse auszuwählen, die in die Weiterleitungstabelle installiert werden soll. Wenn sich die Menge der nächsten Hops für ein Ziel in irgendeiner Weise ändert, wird die Next-Hop-Adresse mithilfe des Hash-Algorithmus erneut gewählt. Sie können konfigurieren, wie der Hash-Algorithmus zum Lastausgleich des Datenverkehrs über Schnittstellen in einer aggregierten Ethernet -Schnittstelle (ae) verwendet wird.
Ein LSP neigt dazu, seine Platzierung zu lastausgleichen, indem er zufällig eine der Schnittstellen in einem ae- Schnittstellenpaket wählt und es ausschließlich verwendet. Die zufällige Auswahl erfolgt unabhängig an jedem Transit-Router, der die Metriken des Interior Gateway Protocol (IGP) allein vergleicht. Bandbreiten oder Überlastungen werden nicht berücksichtigt.
Konfigurieren Sie die Anweisung, um einen Lastausgleich basierend auf den MPLS-Labelinformationen zu erhalten family mpls :
[edit forwarding-options hash-key] family mpls { all-labels; label-1; label-2; label-3; no-labels; payload { ether-pseudowire; ip { layer-3-only; port-data { destination-lsb; destination-msb; source-lsb; source-msb; } } } }
Sie können diese Anweisung auf [edit forwarding-options hash-key] Hierarchieebene einschließen.
Wenn Sie Payload-IP (user@host# set forwarding-options hash-key family mpls payload ip) konfigurieren, ist die Konfiguration layer-3-onlyport-data erforderlich.
Load Balancing-Funktionen ohne korrekte Hash-Schlüsselkonfiguration können zu einem unvorhersehbaren Verhalten führen.
Für Layer-2-VPN/Pseudowire-Tunnel-Terminierung werden bis zu zwei Label für Hashing verwendet, und die Nutzlast mac-Ziel und Quelladressen können optional ausgewählt werden. Diese Steuerelemente können zur Unterstützung von Ether-Pseudowire-Knöpfen in der Mpls-Familie unter der oben dargestellten Hash-Key-Konfiguration verwendet werden. Da ACX2000 und ACX4000 jedoch auch TDM-Pseudowires unterstützen, dürfen die Ether-Pseudowire-Knöpfe nur verwendet werden, wenn keine TDM-Pseudowires verwendet werden.
Für Die Layer 3-VPN-Tunnel-Terminierung werden bis zu zwei Label für das Haben und die Payload-IP-Quell- und Zieladresse verwendet, und Es können optional Layer 4-Quell- und Ziel-Ports ausgewählt werden. Diese Steuerelemente können zur Unterstützung von IP-Port-Datenknöpfen in mpls der Familie unter der oben dargestellten Hash-Key-Konfiguration verwendet werden. Da jedoch Layer-4-Port-MSB und LSB nicht einzeln ausgewählt werden können, würde einer der Ziel-lsb- oder Ziel-msb-Knöpfe oder einer der Source-lsb- oder Source-msb-Knöpfe Layer 4-Ziel- bzw. Quell-Ports auswählen.
Für LSR-Fall werden bis zu drei Label für Hashing verwendet. Wenn beim Parsieren der ersten drei Label ein BOS zu sehen ist, untersucht BCM die ersten Knaben der Nutzlast. Wenn die Nibble 4 ist, wird die Payload als IPv4 behandelt und wenn die erste Knabber 6 ist, wird die Nutzdaten als IPv6 behandelt, und in solchen Fällen können die Payload-Quell- und Ziel-IP-Adressen spekulativ für das Hashing verwendet werden. Diese Steuerelemente können zur Unterstützung von IP-Port-Datenknöpfen in mpls der Familie unter Hash-Key-Konfiguration verwendet werden. Layer-4-Ports können jedoch nicht für Hashing in LSR-Fall verwendet werden, und nur Layer-3-Knopf ist anwendbar. BCM beansprucht keine Unterstützung für Hashing auf Feldern außerhalb der drei MPLS-Label. Das Load Balancing für eine einzige Pseudowire-Sitzung findet im Fall von LSR nicht statt, da der gesamte für diese Sitzung spezifische Datenverkehr den gleichen Satz von MPLS-Labeln trägt.
Load Balancing auf LSR AE-Schnittstellen kann für eine höhere Anzahl von MPLS-Sitzungen erreicht werden, d. h. mindestens 10 Sitzungen. Dies gilt für CCC/VPLS/L3VPN. Im Fall von Layer-3-VPN wird der Datenverkehr möglicherweise nicht gleich über die Member-Links verteilt, wie die Layer-3-Adressen auch (zusammen mit den Labeln) für die Hash-Eingabefunktion berücksichtigt werden.
Für LER-Szenarien ist im Fall von ACX5048 und ACX5096 ein Hashing auf Der Grundlage von Layer-3- und Layer-4-Feldern möglich, indem die Payload-Option unter der Hierarchie "Family mpls" konfiguriert wird. Hashing auf dem LER basiert nicht auf Labeln. Für Layer-3-Services ist es zwingend erforderlich, die Payload als "layer 3-only" zu bezeichnen und im Fall eines Layer-4-Services "Port-Daten" anzugeben. Sie können auch die Anzahl der Label bei der Konfiguration von Hash-Schlüsseln auf LER-Routern erwähnen.
Das Load Balancing-Verhalten von LER und LSR ist für CCC/VPLS/Layer 3 VPN und andere IP-MPLS-Szenarien anwendbar.
Diese Funktion gilt für aggregierte Ethernet- und aggregierte SONET/SDH-Schnittstellen. Darüber hinaus können Sie Load Balancing für IPv4-Datenverkehr über Layer-2-Ethernet-Pseudowires konfigurieren. Sie können auch Load Balancing für Ethernet-Pseudowires basierend auf IP-Informationen konfigurieren. Die Option, IP-Informationen in den Hash-Schlüssel einzubeziehen, bietet Unterstützung für Ethernet Circuit Cross-Connect (CCC)-Verbindungen.
Anweisung |
MPLS LSP Load Balancing-Optionen |
|---|---|
|
Fügen Sie das erste Label in die Hash-Taste ein. Verwenden Sie diese Option für Pakete mit einzelnen Labeln. |
|
Fügen Sie das zweite Label in die Hash-Taste ein. Sie müssen die |
|
Fügen Sie das dritte Label in die Hash-Taste ein. Sie müssen auch die |
|
Schließt MPLS-Label vom Hashschlüssel aus. |
|
Ermöglicht es Ihnen zu konfigurieren, welche Teile der IP-Paketnutzlast in den Hashschlüssel enthalten sein sollen. Für den Paketübertragungs-Switch der PTX-Serie ist dieser Wert standardmäßig festgelegt. |
|
Ip-Payload vom Hashschlüssel ausschließen. |
|
Lastausgleich von IPv4-Datenverkehr über Layer-2-Ethernet-Pseudowires. |
|
Fügen Sie die IPv4- oder IPv6-Adresse in den Hashschlüssel ein. Sie müssen auch entweder |
|
Fügen Sie nur die Layer-3-IP-Informationen in den Hashschlüssel ein. Schließt alle |
|
Fügen Sie die Feldinformationen des Quell- und Zielports ein. Standardmäßig werden im Hash-Schlüssel das bedeutendste Byte und das geringste Byte der Quell- und Zielportfelder verwendet. Um bestimmte Bytes auszuwählen, die im Hashschlüssel verwendet werden sollen, schließen Sie eine oder mehrere der Optionen , |
|
Schließen Sie das geringste Byte des Zielports in den Hash-Schlüssel ein. Kann mit jeder der anderen |
|
Fügen Sie das bedeutendste Byte des Ziel-Ports in den Hash-Schlüssel ein. Kann mit jeder der anderen |
|
Fügen Sie das geringste Byte des Quell-Ports in den Hashschlüssel ein. Kann mit jeder der anderen |
|
Nehmen Sie das bedeutendste Byte des Quell-Ports in den Hash-Schlüssel ein. Kann mit jeder der anderen |
Um die IP-Adresse sowie das erste Label in den Hashschlüssel einzubeziehen, konfigurieren Sie die label-1 Anweisung und die ip Option für die payload Anweisung auf Hierarchieebene [edit forwarding-options hash-key family mpls] :
[edit forwarding-options hash-key family mpls]
label-1;
payload {
ip;
}
Um die IP-Adresse sowie die erste und zweite Bezeichnung in den Hashschlüssel einzubeziehen, konfigurieren Sie die label-1 optionen und label-2 die ip Option für die payload Anweisung auf Hierarchieebene [edit forwarding-options hash-key family mpls] :
[edit forwarding-options hash-key family mpls]
label-1;
label-2;
payload {
ip;
}
Stellen Sie das richtige Load Balancing sicher, indem Sie den label-1, label-2und label-3 die [edit forwarding-options hash-key family mpls] Optionen auf Hierarchieebene angeben:
[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
MPLS Encapsulated Payload Load-Balancing – Übersicht
Router können einen Lastausgleich pro Paket in MPLS. Load Balancing kann für die Informationen sowohl im IP-Header als auch auf bis zu drei MPLS-Labeln durchgeführt werden, um eine einheitlichere Verteilung des MPLS-Datenverkehrs an next Hops zu erreichen.
Load Balancing wird verwendet, um den Datenverkehr gleichmäßig zu verteilen, wenn die folgenden Bedingungen gelten:
Es gibt mehrere next Hops zu gleichen Kosten über verschiedene Schnittstellen zum selben Ziel.
Es gibt einen einzelnen nächsten Hop über eine aggregierte Schnittstelle.
Wenn Load Balancing zur Verteilung des Datenverkehrs verwendet wird, wird standardmäßig ein Hash-Algorithmus verwendet, um eine Next-Hop-Adresse auszuwählen, die in die Weiterleitungstabelle installiert werden soll. Wenn sich die Menge der nächsten Hops für ein Ziel in irgendeiner Weise ändert, wird die Next-Hop-Adresse mithilfe des Hash-Algorithmus erneut gewählt.
Bei Netzwerken auf mehreren Transportebenen, wie Ethernet über MPLS oder Ethernet-Pseudowire, muss der Hash-Algorithmus über den äußeren Header der Nutzlast hinaus in die inneren Header schauen, um eine gleichmäßige Verteilung zu erzeugen. Um die innere Verkapselung zu bestimmen, stützt sich die PFE auf das Vorhandensein bestimmter Codes oder Nummern an festen Nutzlast-Offets; zum Beispiel das Vorhandensein von Payload-Typ 0X800 oder das Vorhandensein von Protokoll Nummer 4 für ein IPv4-Paket. In Junos OS können Sie die Option konfigurieren zero-control-word , um den Start eines Ethernet-Frames in einer MPLS Ether-Pseudowire-Payload anzugeben. Wenn er dieses Steuerwort mit vier Bytes mit einem numerischen Wert aller Nullen sieht, nimmt der Hash-Generator den Start eines Ethernet-Frames am Ende des Steuerwortes in einem MPLS-Ether-Pseudowire-Paket an.
Konfigurieren Sie die zero-control-word Option für DPC I-Chip-basierten Karten auf [edit forwarding-options hash-key family mpls ether-pseudowire] Hierarchieebene und für MPC-Karten die zero-control-word Option auf [edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] Hierarchieebene.
Konfigurieren von MPLS Encapsulated Payload for Load Balancing
Wenn Load Balancing zur Verteilung des Datenverkehrs verwendet wird, wird standardmäßig ein Hash-Algorithmus verwendet, um eine Next-Hop-Adresse auszuwählen, die in die Weiterleitungstabelle installiert werden soll. Wenn sich die Menge der nächsten Hops für ein Ziel in irgendeiner Weise ändert, wird die Next-Hop-Adresse mithilfe des Hash-Algorithmus erneut gewählt. Konfigurieren Sie die zero-control-word Option, um den Start eines Ethernet-Frames in einer MPLS-Ether-Pseudowire-Payload anzugeben. Beim Sehen dieses Steuerworts, vier Bytes mit einem numerischen Wert aller Nullen, übernimmt der Hash-Generator den Start des Ethernet-Frame am Ende des Steuerwortes in einem MPLS Ether-Pseudowire-Paket.
Bevor Sie mit der Konfiguration der MPLS-gekapselten Nutzdaten für Load Balancing beginnen, konfigurieren Sie Routing- und Signalprotokolle.
So konfigurieren Sie MPLS-gekapselte Nutzdaten für Load Balancing:
zero-control-word Option, um den Start eines Ethernet-Frames in einer MPLS-Ether-Pseudowire-Payload anzugeben. Konfigurieren Sie für DPC I-Chip-basierten Karten die
zero-control-wordOption auf[edit forwarding-options hash-key family mpls ether-pseudowire]Hierarchieebene.[edit forwarding-options hash-key family mpls ether-pseudowire] user@host# set zero-control-word
Konfigurieren Sie für MPC-Karten die
zero-control-wordOption auf[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire]Hierarchieebene.[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] user@host# set zero-control-word
Richtlinienbasierte Multipath-Routen – Übersicht
Segment-Routing-Netzwerke können mehrere Transportprotokolle im Core haben. Sie können Segment-Routing SR-TE LDP- oder RSVP-Routen mit SR-TE IP-Routen kombinieren und eine Multipath-Route in der Routing-Informationsdatenbank (auch Routing-Tabelle genannt) installieren. Sie können dann den selektiven Serviceverkehr über die Mutlipath-Route durch die Richtlinienkonfiguration steuern.
- Grundlegendes zu richtlinienbasierten Multipath-Routen
- Vorteile von richtlinienbasierten Multipath-Routen
- Richtlinienbasierte Multipath-Routen zur Routenauflösung
- Beispielroutenauflösung mithilfe von richtlinienbasierten Multipath-Routen
- Verbesserung der Class-of-Service (CoS)-Weiterleitungsrichtlinie
- Verbesserungen des Policy Match Protocol
- Auswirkungen der Konfiguration richtlinienbasierter Multipath-Route auf die Netzwerkleistung
Grundlegendes zu richtlinienbasierten Multipath-Routen
In einem Netzwerk gibt es verschiedene Transportprotokolle wie IGP, gekennzeichnete IGP-, RSVP-, LDP- und Sr-TE-Protokolle (Segment Routing Traffic-Engineering), die zur Behebung des Servicedatenverkehrs verwendet werden. Sie konnten jedoch keine Kombination der Transportprotokolle verwenden, um den Servicedatenverkehr zu lösen. Mit der Einführung der richtlinienbasierten Multipath-Funktion können Sie SR-TE-LDP- oder RSVP-Routen (Segment Routing Traffic Engineered) und SR-TE IP-Routen kombinieren, um eine in der Routing-Informationsdatenbank installierte Multipath-Route zu erstellen. Sie können BGP-Servicerouten über die Mutlipath-Route durch Richtlinienkonfiguration auflösen und den Datenverkehr für verschiedene Präfixe unterschiedlich steuern.
Eine Multipath-Route verfügt über kombinierte Next Hops von Routeneinträgen, die für das Load Balancing verwendet werden. Alle unterstützenden Routen des Multipath-Routeneintrags müssen sich in derselben Routing-Informationsbasis haben. Wenn sich die unterstützenden Routen unter einer anderen Routing-Informationsbasis befinden, können Sie die rib-group Konfigurationsaussage verwenden, um einer bestimmten Routing-Informationsdatenbank Routeneinträge hinzuzufügen.
Sie können eine Multipath-Route konfigurieren, indem Sie eine Richtlinie verwenden, um die Liste der Routen auszuwählen, deren nächste Hops kombiniert werden soll. Wenn Sie die policy-multipath Anweisung zusammen mit der policy Anweisung auf [edit routing-options rib routing-table-name] Hierarchieebene einschließen, wird eine richtlinienbasierte Multipath-Route erstellt.
Die richtlinienbasierte Multipath-Funktion wird sowohl für IP- als auch für IPv6-Protokolle unterstützt und kann unter der [edit routing-instances] Hierarchieebene konfiguriert werden.
Zum Beispiel:
[edit routing-options] user@host# set rib inet.3 policy-multipath policy example-policy [edit policy-options] user@host# set policy-statement example-policy from example-conditions user@host# set policy-options policy-statement example-policy then accept
Die konfigurierte Richtlinie wird auf jeden Routeneintrag für ein bestimmtes Präfix angewendet. Die Multipath-Route wird nur erstellt, wenn mehr als eine Route (einschließlich der aktiven Route) die Richtlinie passiert. Alle in der Richtlinie konfigurierten Aktionsbefehle, z. B. Apply, werden mithilfe der aktiven Route ausgewertet. Bei nicht aktiven Routen wird die Richtlinie angewendet, um zu prüfen, ob die Routen an der Multipath-Route teilnehmen können oder nicht. Multipath-Routen erben alle Attribute der aktiven Route. Diese Attribute können mithilfe der Multipath-Richtlinienkonfiguration geändert werden.
Vorteile von richtlinienbasierten Multipath-Routen
-
Bietet Flexibilität, Core-Netzwerkprotokolle zu kombinieren, um den selektiven Datenverkehr zu steuern.
-
Optimiert die Netzwerkleistung mit gewichteten multipath-Routen zu gleichen Kosten.
Richtlinienbasierte Multipath-Routen zur Routenauflösung
Sie können SR-TE-LDP- oder RSVP-Routen mit SR-TE-IP-Routen kombinieren und eine Multipath-Route in der Routing-Informationsdatenbank installieren. Die richtlinienbasierten Multipath-Routen sind keine aktiven Einträge in der Routing-Informationsbasis. Wenn eine Multipath-Route durch die Konfiguration der Richtlinie generiert wird, wird sie für die Auflösung des Protokolls next Hops anstelle von aktiven Routen verwendet. Eine Multipath-Route des nächsten Hops wird erstellt, indem Gateways der nächsten Hops jeder konstituierenden Route zusammengeführt werden.
Berücksichtigen Sie bei der Konfiguration richtlinienbasierter Multipath-Routen für die Routenauflösung Folgendes:
-
Wenn die Member-Route einer Multipath-Route auf einen anderen Hop als den Router next Hop oder auf einen indirekten nächsten Hop mit Weiterleitung des nächsten Hops an den Router next Hop verweist, werden solche nächsten Hops ignoriert.
-
Wenn die konstituierenden Routen auf den indirekten Next Hop zeigen, werden Gateways aus dem Weiterleitungs- und nächsten Hop zusammengeführt und der indirekte nächste Hop ignoriert.
-
Wenn die Gesamtzahl der Gateways die
maximum-ecmpauf dem Gerät unterstützte übersteigt, werden nur diemaximum-ecmpGateways beibehalten und alle anderen Gateways werden ignoriert. -
Gateways mit geringerer Gewichtung werden bevorzugt. Wenn eine Der Member-Route eine Unilist der indirekten next Hops hat und jeder nächste Hop auf einen Weiterleitungs-nächsten Hop zeigt, können Gewichtungswerte sowohl für den indirekten nächsten Hop als auch für die Weiterleitung des nächsten Hops angegeben werden. In solchen Fällen wird der Gewichtungswert von Gateways aktualisiert, um den kombinierten Effekt der Gewichtung auf beiden Ebenen widerzuspiegeln.
Beispielroutenauflösung mithilfe von richtlinienbasierten Multipath-Routen
Nehmen wir als Beispiel an, dass es Traffic-Engineering-LSPs für Segment-Routing, Label-IS-Routen und LDP-LSPs für ein Ziel 10.1.1.1/32 gibt, wie in der ausgabe unten dargestellt:
10.1.1.1/32 *[SPRING-TE/8] 00:00:58, metric 1, metric2 30
> to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:15:57, metric 10
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:09:27, metric 1
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
Hier ist Segment-Routing-LSP der aktive Routeneintrag zum 10.1.1-Ziel, und standardmäßig wird nur diese Route verwendet, um alle Services zu lösen, die über 10.1.1.1 aufgelöst werden.
Wenn mehr als ein Protokoll für die Auflösung von Servicerouten verwendet werden muss, können Sie dies erreichen, indem Sie Richtlinien-Multipath konfigurieren, um die Protokolle zu kombinieren. Wenn beispielsweise Segment-Routing und LDP-Pfade für die Serviceauflösung erforderlich sind, müssen Sie die Kombination von SegMent-Routing und LDP-Routen für das Präfix 10.1.1 konfigurierenpolicy-multipath.
Zum Beispiel:
[edit policy-options] user@host# set rib inet.3 policy-multipath policy example-policy user@host# set policy-statement abc term 1 from protocol spring-te user@host# set policy-statement abc term 1 from protocol ldp user@host# set policy-statement abc term 1 from route-filter 10.1.1.1/32 exact user@host# set policy-statement abc term 1 then accept
Mit dieser Konfiguration erstellen Sie eine richtlinienbasierte Multipath-Route für präfix 10.1.1.1/32, die konstituierende Routeneinträge von Segment-Routing und LDP-Protokollen verwendet.
Sie können die Multipath-Route mit der show route Befehlsausgabe wie folgt anzeigen:
10.1.1.1/32 *[SPRING-TE/8] 00:10:28, metric 1, metric2 30
> to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
[L-ISIS/14] 1w0d 00:25:27, metric 10
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[LDP/19] 1w0d 00:18:57, metric 1
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
[Multipath/8] 00:03:13, metric 1, metric2 30
> to 10.12.1.1 via ge-0/0/0.1
to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
Sie können über die Befehlsausgabe sehen, dass die Multipath-Route die nächsten Hops von Segment-Routing und LDP-Pfaden kombiniert. Die Multipath-Route ist nicht aktiv, und standardmäßig ist die Routenpräferenz und -metrik mit der der aktiven Route identisch.
Sie können die folgenden Kombinationen für die poilcy-basierte Multipath-Route verwenden: Wir können jedoch keinen Multipath von LDP/L-ISIS erstellen, da aktiv-route nicht Teil von Multipath ist.
-
Traffic-Engineering-LSPs und LDP-LSPs im Segment-Routing.
-
Traffic-Engineering-LSPs für Segment-Routing und labeln IS-IS-Pfade.
-
Segment-Routing-Traffic-Engineering-LSPs, LDP-LSPs und Label IS-IS-Pfade.
Sie können jedoch keine Multipath-Route für LDP und BEZEICHNUNG IS-IS erstellen, da die aktive Route nicht Teil der Multipath-Route ist.
Bei derselben Konfiguration wird diese Route unter Der Annahme, dass es eine statische Route 1.2.3.4/32 mit einem Protokoll next Hop von 10.1.1 konfiguriert ist, wird diese Route mit der Multipath-Route sowohl über LSPs des Segment-Routing-Datenverkehrs als auch über LDP-LSPs aufgelöst.
Zum Beispiel:
10.1.3.4/32 *[Static/5] 00:00:12, metric2 1
to 10.12.1.1 via ge-0/0/0.1
> to 10.22.1.1 via ge-0/0/0.2
to 10.23.1.1 via ge-0/0/0.3
to 10.24.1.1 via ge-0/0/0.4
to 10.25.1.1 via ge-0/0/0.5
to 10.13.1.2 via ge-0/0/1.1, Push 33333, Push 801005, Push 801006(top)
to 10.13.1.2 via ge-0/0/1.1, Push 801001, Push 801005(top)
Verbesserung der Class-of-Service (CoS)-Weiterleitungsrichtlinie
Für die Class-of-Service-basierte Weiterleitung müssen Sie die forwarding-policy next-hop-map Konfigurationsaussage verwenden.
Vor Junos OS-Version 19.1R1 umfassten die Übereinstimmungsbedingungen, die unter class-of-Service-basierte Weiterleitung unterstützt wurden:
-
next-hop— Passen Sie den nächsten Hop basierend auf der ausgehenden Schnittstelle oder der Adresse des nächsten Hops ab.
-
lsp-next-hop— Passen Sie benannte LSPs mit dem regulären Ausdruck des LSP-Namens ab.
-
non-lsp-next-hop– Passen Sie alle LSPs ohne LSP-Namen an.
Mit der richtlinienbasierten Multipath-Routenfunktion können Sie auch alle nächsten Hops ohne Label für bestimmte Präfixe abgleichen. Dazu müssen Sie die non-labelled-next-hop Option auf [edit class-of-service forwarding-policy next-hop-map map-name forwarding-class forwarding-class-name Hierarchieebene aktivieren.
Zum Beispiel:
[edit]
class-of-service {
forwarding-policy {
next-hop-map abc {
forwarding-class best-effort {
non-labelled-next-hop;
}
}
}
}
Verbesserungen des Policy Match Protocol
Vor Junos OS Version 19.1R1 wurden alle Protokollrouten (gekennzeichnet und nicht gekennzeichnet) abgeglichen, wenn Sie eine Richtlinie verwendet haben, um das Protokoll mit der from protocol[edit policy-options policy-statement statement-name] Anweisung auf Hierarchieebene abzugleichen. Mit der richtlinienbasierten Multipath-Routenfunktion können Sie gekennzeichnete Protokollrouten gezielt abgleichen.
Die Optionen für den Abgleich von gekennzeichneten Protokollen) sind:
-
l-isis— Übereinstimmung mit gekennzeichneten IS-IS-Routen. Die
isisOption entspricht IS-IS-Routen mit Ausnahme von Label-IS-Routen. -
l-ospf— Passen Sie laborierte OSPF-Routen ab. Die
ospfOption entspricht allen OSPF-Routen, einschließlich OSPFv2, OSPFv3 und dem Label OSPF.
Zum Beispiel:
[edit]
policy-options {
policy-statement abc {
from protocol [ l-ospf l-isis ];
}
}
Auswirkungen der Konfiguration richtlinienbasierter Multipath-Route auf die Netzwerkleistung
Wenn Sie eine richtlinienbasierte Multipath-Route konfigurieren, führt eine Änderung der Route in der Routing-Informationsdatenbank zu einer Auswertung der Richtlinie, um zu prüfen, ob eine Multipath-Route erstellt werden muss. Da diese Funktion erfordert, dass die Mitgliedsrouten in derselben Routing-Informationsbasis enthalten sein müssen, wird die rib-group Anweisung verwendet, um Routen aus einer anderen Routing-Informationsbasis zusammenzuführen. Die Konfiguration der rib-group Anweisung auf Anwendungsebene erhöht die Anzahl der Routen im System.
Wenn sich in der Routing-Informationsbasis eine Reihe von Routen befindet, führt eine ständige Änderung der Routen zu einer Neubewertung der Multipath-Richtlinie. Dies könnte sich auf die Netzwerkleistung auswirken. Es wird empfohlen, die richtlinienbasierte Multipath-Routenfunktion nur bei Bedarf zu konfigurieren.
Grundlegendes zur IP-basierten Filterung und selektiven Portspiegelung von MPLS-Datenverkehr
In einem MPLS-Paket kommt der IP-Header direkt nach dem MPLS-Header. Die IP-basierte Filterfunktion bietet einen Deep Inspection-Mechanismus, bei dem maximal bis zu acht MPLS-Label der inneren Nutzlast untersucht werden können, um die Filterung des MPLS-Datenverkehrs basierend auf IP-Parametern zu ermöglichen. Der gefilterte MPLS-Datenverkehr kann auch zu einem Überwachungsgerät gespiegelt werden, um netzwerkbasierte Services im MPLS-Core-Netzwerk anzubieten.
- IP-basierte Filterung von MPLS-Datenverkehr
- Selektives Port-Spiegelung von MPLS-Datenverkehr
- Beispielkonfigurationen
IP-basierte Filterung von MPLS-Datenverkehr
Vor Junos OS Version 18.4R1 wurde eine Filterung basierend auf IP-Parametern für filter der MPLS-Familie nicht unterstützt. Mit der Einführung der IP-basierten Filterfunktion können Sie eingehende und ausgehende Filter für MPLS-getaggte IPv4- und IPv6-Pakete basierend auf IP-Parametern wie Quell- und Zieladressen, Layer-4-Protokolltyp sowie Quell- und Ziel-Ports anwenden.
Die IP-basierte Filterfunktion ermöglicht es Ihnen, MPLS-Pakete am Eingang einer Schnittstelle zu filtern, wobei die Filterung unter Verwendung von Übereinstimmungsbedingungen auf der inneren Nutzlast des MPLS-Pakets erfolgt. Der selektive MPLS-Datenverkehr kann dann über logische Tunnel auf ein Remote-Überwachungsgerät gespiegelt werden.
Um IP-basierte Filterung zu unterstützen, werden zusätzliche Übereinstimmungsbedingungen hinzugefügt, die es ermöglichen, MPLS-Pakete tief inspiziert zu werden, um die innere Nutzlast mit Layer-3- und Layer-4-Headern zu analysieren, bevor die entsprechenden Filter angewendet werden.
Die IP-basierte Filterfunktion wird nur für MPLS-getaggte IPv4- und IPv6-Pakete unterstützt. Mit anderen Worten, die MPLS-Filter stimmen IP-Parameter nur dann ab, wenn die IP-Payload unmittelbar nach den MPLS-Labeln eingeht.
In anderen Szenarien, in denen die MPLS-Payload Pseudowires, andere Protokolle als Inet und Inet6 oder andere Kapselungen wie Layer 2 VPN oder VPLS umfasst, wird die IP-basierte Filterfunktion nicht unterstützt.
Für die IP-basierte Filterung von MPLS-Datenverkehr werden folgende Übereinstimmungsbedingungen hinzugefügt:
IPv4-Quelladresse
IPv4-Zieladresse
IPv6-Quelladresse
IPv6-Zieladresse
Protokoll
Quell-Port
Ziel-Port
Quell-IPv4-Präfixliste
Ziel-IPv4-Präfixliste
Quell-IPv6-Präfixliste
Ziel-IPv6-Präfixliste
Für die IP-basierte Filterung von MPLS-Datenverkehr werden folgende Kombinationen unterstützt:
Quell- und Zieladressen stimmen bedingungen mit IPv4- und IPv6-Präfixlisten ab.
Quell- und Ziel-Portadressen und Protokolltypen stimmen bedingungen mit IPv4- und IPv6-Präfixlisten ab.
Selektives Port-Spiegelung von MPLS-Datenverkehr
Port-Spiegelung ist die Fähigkeit, ein Paket zusätzlich zur normalen Verarbeitung und Weiterleitung der Pakete an ein konfiguriertes Ziel zu spiegeln. Die Portspiegelung wird als Aktion für einen Firewall-Filter angewendet, der am Eingang oder Ausgang einer beliebigen Schnittstelle angewendet wird. Ebenso bietet die selektive Portspiegelungsfunktion die Möglichkeit, MPLS-Datenverkehr, der anhand von IP-Parametern gefiltert wird, mithilfe logischer Tunnel zu einem gespiegelten Ziel zu spiegeln.
Um die selektive Portspiegelung zu aktivieren, werden zusätzlich zu den [edit firewall family mpls filter filter-nameterm term-name then] vorhandenen counter, acceptund discard Aktionen weitere Aktionen auf Hierarchieebene konfiguriert:
port-mirrorport-mirror-instance
Port Mirroring
Die port-mirror Aktion ermöglicht eine globale Port-Spiegelung auf dem Gerät, was für alle Packet Forwarding Engines (PFEs) und zugehörigen Schnittstellen gilt.
Für Filter der MPLS-Familie ist die Aktion für die port-mirror globale Portspiegelung aktiviert.
Port Mirroring Instance
Die port-mirror-instance Aktion ermöglicht es Ihnen, jede Instanz mit unterschiedlichen Eigenschaften für Eingabe-Sampling und Portspiegelung Ausgabeziele anzupassen, anstatt eine einzige systemweite Konfiguration für die Portspiegelung verwenden zu müssen.
Sie können nur zwei Portspiegelungsinstanzen pro Flexible PIC Concentrator (FPC) konfigurieren, indem Sie die instance port-mirror-instance-name Anweisung auf Hierarchieebene [edit forwarding-options port-mirror] hinzufügen. Sie können dann einzelne Portspiegelungsinstanzen je nach Gerätehardware einem FPC, PIC oder (Forwarding Engine Board ( FEB) zuordnen.
Für Filter der MPLS-Familie ist die port-mirror-instance Aktion nur für die Portspiegelungsinstanz aktiviert.
Für beides port-mirror und port-mirror-instance Aktionen muss die Ausgabeschnittstelle mit der Layer-2-Familie und nicht mit der MPLS-Familie (Layer 3) aktiviert sein, damit die selektive Portspiegelungsfunktion funktioniert.
Beispielkonfigurationen
- Ip-basierte Filterkonfiguration
- Konfiguration selektiver Portspiegelung
- Spiegelung der Zielkonfiguration
Ip-basierte Filterkonfiguration
[edit firewall family mpls filter mpls-filter]
term ipv4-term {
from {
ip-version {
ipv4 {
source-address {
10.10.10.10/24;
}
destination-address {
20.20.20.20/24;
}
protocol tcp {
source-port 100;
destination-port 200;
}
soure-prefix-list ipv4-source-users;
destination-prefix-list ipv4-destination-users;
}
}
exp 1;
}
then port-mirror;
then accept;
then count;
}
term ipv6-term {
from {
ip-version {
ipv6 {
source-address {
2000::1/128;
}
destination-address {
3000::1/128;
}
protocol tcp {
source-port 100;
destination-port 200;
}
source-prefix-list ipv6-source-users;
destination-prefix-list ipv6-destination-users;
}
}
exp 1;
}
then port-mirror-instance port-mirror-instance1;
then accept;
then count;
}
[edit policy-options]
prefix-list ipv4-source-users {
172.16.1.16/28;
172.16.2.16/28;
}
prefix-list ipv6-source-users {
2001::1/128;
3001::1/128;
}
[edit interfaces]
xe-0/0/1 {
unit 0 {
family inet {
address 100.100.100.1/30;
}
family mpls {
filter {
input mpls-filter;
}
}
}
}
Konfiguration selektiver Portspiegelung
[edit forwarding-options]
port-mirroring {
input {
rate 2;
run-length 4;
maximum-packet-length 500;
}
family any {
output {
interface xe-2/0/2.0;
}
}
}
[edit forwarding-options]
port-mirroring {
instance {
port-mirror-instance1 {
input {
rate 3;
run-length 5;
maximum-packet-length 500;
}
family any {
output {
interface xe-2/0/2.0;
}
}
}
}
}
Die Ausgabeschnittstelle xe-2/0/2.0 ist für die Layer-2-Familie und nicht für die MPLS-Familie konfiguriert.
Für beides port-mirror und port-mirror-instance Aktionen muss die Ausgabeschnittstelle mit der Layer-2-Familie und nicht mit der MPLS-Familie (Layer 3) aktiviert sein, damit die selektive Portspiegelungsfunktion funktioniert.
Spiegelung der Zielkonfiguration
[edit interfaces]
xe-2/0/2 {
vlan-tagging;
encapsulation extended-vlan-bridge;
unit 0 {
vlan-id 600;
}
}
[edit bridge-domains]
bd {
domain-type bridge;
interface xe-2/0/2.0;
}