Auf dieser Seite
Routerkonfigurationen für das MPLS-Netzwerk mit Lastenausgleich
Konfigurieren des Lastausgleichs basierend auf MPLS-Labels auf Routern der ACX-Serie
Konfigurieren der MPLS-gekapselten Nutzlast für den Lastenausgleich
Grundlegendes zur IP-basierten Filterung und selektiven Portspiegelung des MPLS-Datenverkehrs
Load Balancing von MPLS-Datenverkehr
Konfigurieren des Load Balancing basierend auf MPLS-Labels
Der Lastenausgleich erfolgt pro Paket für MPLS-Datenströme auf unterstützten Plattformen. Entropie oder Zufallsverteilung ist für die gleichmäßige Verteilung von Paketen auf 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 der Weiterleitungstabelle installiert werden soll. Wenn sich die Menge der nächsten Hops für ein Ziel ändert, wird die Adresse des nächsten Hops mithilfe des Hash-Algorithmus neu ausgewählt. Sie können konfigurieren, wie der Hashalgorithmus verwendet wird, um den Datenverkehr über eine Reihe von Equal-Cost-Label-Switched-Pfaden (LSPs) auszugleichen.
Um die Entropie für VPLS- und VPWS-Datenverkehr sicherzustellen, kann Junos OS einen Hash erstellen, der auf Daten aus dem IP-Header und bis zu drei MPLS-Labels (den sogenannten Top-Labels) basiert.
In einigen Fällen, wenn die Anzahl der Netzwerk-Features, die Labels verwenden (z. B. MPLS Fast Reroute und RFC 3107, RSVP und VPN), zunimmt, können die Daten in den ersten drei Labels statisch werden und sind daher keine ausreichende Quelle für Entropie. Infolgedessen kann das Load Balancing verzerrt werden, oder die Häufigkeit von Out-of-Order-Paketzustellungen kann zunehmen. In diesen Fällen können Etiketten vom unteren Rand des Etikettenstapels verwendet werden (Qualifizierungen finden Sie in Tabelle 1 unten). Obere und untere Etiketten können nicht gleichzeitig verwendet werden.
MPC-Karten unterstützen die reguläre Hash-Schlüsselkonfiguration nicht. Damit die MPC-basierte Hash-Schlüsselkonfiguration wirksam ist, benötigen Sie eine enhanced-hash-key Konfiguration.
Load Balancing wird verwendet, um den Datenverkehr gleichmäßig zu verteilen, wenn die folgenden Bedingungen zutreffen:
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 auszugleichen, indem er nach dem Zufallsprinzip einen der kostengünstigen nächsten Hops auswählt und ausschließlich verwendet. Die Zufallsauswahl erfolgt unabhängig von jedem Transit-Router, wobei nur die IGP-Metriken (Interior Gateway Protocol) verglichen werden. Bandbreite oder Überlastungsgrad werden nicht berücksichtigt.
Diese Funktion gilt für aggregierte Ethernet- und aggregierte SONET/SDH-Schnittstellen sowie für mehrere MPLS-Next-Hops zu gleichen Kosten. Darüber hinaus können Sie nur auf den Routern der T-Serie, MX-Serie, M120 und M320 den Lastausgleich für IPv4-Datenverkehr über Layer-2-Ethernet-Pseudoleitungen konfigurieren. Sie können auch den Lastenausgleich für Ethernet-Pseudowires basierend auf IP-Informationen konfigurieren. Die Option, IP-Informationen in den Hash-Schlüssel aufzunehmen, bietet Unterstützung für CCC-Verbindungen (Ethernet Circuit Cross Connect).
Um einen Lastenausgleich basierend auf den MPLS-Bezeichnungsinformationen durchzuführen, konfigurieren Sie die family mpls folgende Anweisung:
[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 einbinden:
[edit forwarding-options hash-key]
Tabelle 1 bietet detaillierte Informationen zu allen möglichen MPLS-LSP-Lastausgleichsoptionen.
Aussage |
Unterstützte Plattformen |
MPLS-LSP-Load-Balancing-Optionen |
|---|---|---|
|
MX- und PTX-Serie |
Vor Junos OS Version 19.1R1 waren bis zu acht MPLS-Labels im Hash-Schlüssel enthalten, um die Eindeutigkeit eines Datenstroms in der Paketweiterleitungs-Engine zu identifizieren. Bei Routern der PTX-Serie ist dieser Wert standardmäßig festgelegt. Ab Junos OS Version 19.1R1 sind bei Routern der MX-Serie mit MPC- und MIC-Schnittstellen bis zu sechzehn eingehende MPLS-Labels im Hash-Schlüssel enthalten. |
|
MX-Serie mit DPC (I-Chip). Wird auf M10i, M7i und M120 nicht unterstützt. |
Verwendet die unterste Beschriftung zum Berechnen des Hashschlüssels, z. B. wenn die obersten Beschriftungen keine ausreichende Variable für die erforderliche Entropiestufe bereitstellen. |
|
MX-Serie mit DPC (I-Chip). Wird auf M10i, M7i und M120 nicht unterstützt. |
Verwendet die zweite Beschriftung von unten zum Berechnen des Hash-Schlüssels, z. B. wenn die obersten Beschriftungen keine ausreichende Variable für die erforderliche Entropiestufe bereitstellen. |
|
MX-Serie mit DPC (I-Chip). Wird auf M10i, M7i und M120 nicht unterstützt. |
Verwendet die dritte Beschriftung von unten zum Berechnen des Hashschlüssels, z. B. wenn die oberen Beschriftungen keine ausreichende Variable für die erforderliche Entropiestufe bereitstellen. |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie die erste Bezeichnung in den Hash-Schlüssel ein. Verwenden Sie diese Option für Pakete mit einem einzelnen Label. |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie die zweite Bezeichnung in den Hash-Schlüssel ein. Sie müssen die |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie die dritte Bezeichnung in den Hash-Schlüssel ein. Sie müssen auch die |
|
Alle Prüfungsgutscheine von |
Schließt MPLS-Bezeichnungen aus dem Hash-Schlüssel aus. |
|
M-Serie, MX-Serie, T-Serie |
Schließt das EXP-Bit des obersten Labels aus dem Hash-Schlüssel aus. Sie müssen die Bei Layer-2-VPNs könnte der Router ein Problem mit der Neuanordnung von Paketen haben. Wenn ein Burst des Datenverkehrs dazu führt, dass die Bandbreite des Kundendatenverkehrs ihre Grenzen überschreitet, kann der Datenverkehr während des Datenflusses beeinträchtigt werden. Pakete können dadurch neu angeordnet werden. Indem Sie das EXP-Bit aus dem Hash-Schlüssel ausschließen, können Sie dieses Problem der Neuanordnung vermeiden. |
|
Alle Prüfungsgutscheine von |
Hier können Sie konfigurieren, welche Teile der IP-Paketnutzlast in den Hash-Schlüssel aufgenommen werden sollen. Für den Paketübertragungsrouter der PTX-Serie ist dieser Wert standardmäßig festgelegt. |
|
PTX-Serie |
Schließen Sie die IP-Nutzlast aus dem Hash-Schlüssel aus. |
|
M120, M320, MX-Serie, T-Serie |
Lastausgleich für IPv4-Datenverkehr über Layer-2-Ethernet-Pseudowires. |
|
Alle Prüfungsgutscheine von |
Fügen Sie die IPv4- oder IPv6-Adresse in den Hash-Schlüssel ein. Sie müssen außerdem entweder |
|
Alle Prüfungsgutscheine von |
Fügen Sie nur die Layer-3-IP-Informationen in den Hash-Schlüssel ein. Schließt alle |
|
M-Serie, MX-Serie, T-Serie |
Geben Sie die Feldinformationen für den Quell- und Zielport an. Standardmäßig werden das höchstwertige Byte und das niederwertigste Byte der Quell- und Zielportfelder im Hash-Schlüssel verwendet. Um bestimmte Bytes auszuwählen, die im Hashschlüssel verwendet werden sollen, schließen Sie eine oder mehrere der |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie das niederwertigste Byte des Zielports in den Hash-Schlüssel ein. Kombinierbar mit allen anderen |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie das höchstwertige Byte des Zielports in den Hash-Schlüssel ein. Kombinierbar mit allen anderen |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie das niederwertigste Byte des Quellports in den Hash-Schlüssel ein. Kombinierbar mit allen anderen |
|
M-Serie, MX-Serie, T-Serie |
Fügen Sie das höchstwertige Byte des Quellports in den Hash-Schlüssel ein. Kombinierbar mit allen anderen |
In den folgenden Beispielen wird veranschaulicht, wie Sie den MPLS-LSP-Lastenausgleich konfigurieren können:
So fügen Sie die IP-Adresse sowie das erste Label in den Hash-Schlüssel ein:
Konfigurieren Sie für Router der M - Serie, MX- Serie 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 undip payloadstandardmäßig konfiguriert, sodass keine Konfiguration erforderlich ist.
(Nur Router der M320- und T-Serie) Um die IP-Adresse sowie das erste und zweite Label in den Hash-Schlüssel aufzunehmen, konfigurieren Sie die
label-1Optionen andlabel-2und dieipOption 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 Anweisungen nur auf Routern der M320- und T-Serie einschließen. Wenn Sie sie in einen Multiservice-Edge-Router der M-Serie einbinden, werden nur die erste MPLS-Bezeichnung und die IP-Nutzlast im Hash-Schlüssel verwendet.
Stellen Sie bei Routern der T-Serie einen ordnungsgemäßen Lastausgleich sicher, indem Sie die
label-1Optionen ,label-2undlabel-3auf Hierarchieebene[edit forwarding-options hash-key family mpls]einschließen:[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
(Nur Router der M-Serie, MX-Serie und T-Serie) Bei Layer-2-VPNs könnte der Router ein Problem mit der Neuanordnung von Paketen haben. Wenn ein Burst des Datenverkehrs dazu führt, dass die Bandbreite des Kundendatenverkehrs ihre Grenzen überschreitet, kann der Datenverkehr während des Datenflusses beeinträchtigt werden. Pakete können dadurch neu angeordnet werden. Indem Sie das EXP-Bit aus dem Hash-Schlüssel ausschließen, können Sie dieses Problem der Neuanordnung vermeiden. Um das EXP-Bit des ersten Labels von den Hashberechnungen auszuschließen, schließen Sie die
no-label-1-expAnweisung auf Hierarchieebene[edit forwarding-options hash-key family mpls]ein:[edit forwarding-options hash-key family mpls] label-1; no-label-1-exp; payload { ip; }
Beispiel: MPLS-Netzwerk mit Lastenausgleich
Wenn Sie mehrere RSVP-LSPs für denselben Ausgangsrouter konfigurieren, wird der LSP mit der niedrigsten Metrik ausgewählt und überträgt den gesamten Datenverkehr. Wenn alle Sprachdienstleister dieselbe Metrik aufweisen, wird einer der Sprachdienstleister nach dem Zufallsprinzip ausgewählt, und der gesamte Datenverkehr wird über ihn weitergeleitet. Um den Datenverkehr gleichmäßig auf alle Sprachdienstleister zu verteilen, können Sie je nach konfiguriertem Load-Balancing-Typ den Lastenausgleich auf den Eingangs- oder Transit-Routern konfigurieren.
Abbildung 1 veranschaulicht ein MPLS-Netzwerk mit vier LSPs, die für denselben Ausgangsrouter konfiguriert sind (R0). Der Lastenausgleich wird auf dem Eingangsrouter R1konfiguriert. Im Beispielnetzwerk wird Open Shortest Path First (OSPF) als Interior Gateway Protocol (IGP) mit OSPF-Bereich 0.0.0.0verwendet. Für den CSPF-LSP (Constrained Shortest Path First) ist ein IGP erforderlich, der Standardeinstellung für das Junos-Betriebssystem. Darüber hinaus verwendet das Beispielnetzwerk eine Richtlinie zum Erstellen von BGP-Datenverkehr.
Das in Abbildung 1 dargestellte Netzwerk besteht aus folgenden Komponenten:
Eine interne BGP-Topologie (Full-Mesh-BGP) unter Verwendung von AS 65432
MPLS und RSVP auf allen Routern aktiviert
Eine Sende-Statik-Richtlinie auf Routern R1 , R0 die es ermöglicht, eine neue Route im Netzwerk anzukündigen
Vier unidirektionale LSPs zwischen R1 und R0und und ein LSP in umgekehrter Richtung zwischen R0 und R1, was bidirektionalen Datenverkehr ermöglicht
Auf dem Eingangsrouter konfiguriertes Load Balancing R1
Bei dem gezeigten Abbildung 1 Netzwerk handelt es sich um ein BGP-Full-Mesh-Netzwerk. Da Routenreflektoren und Konföderationen nicht zur Weitergabe von BGP-gelernten Routen verwendet werden, muss jeder Router über eine BGP-Sitzung mit jedem anderen Router verfügen, auf dem BGP ausgeführt wird.
Routerkonfigurationen für das MPLS-Netzwerk mit Lastenausgleich
- Zweck
- Action!
- Beispielausgabe 1
- Beispielausgabe 2
- Beispielausgabe 3
- Beispielausgabe 4
- Beispielausgabe 5
- Beispielausgabe 6
- Bedeutung
Zweck
Die Konfigurationen in diesem Thema beziehen sich auf die sechs Router mit Lastenausgleich im Beispielnetzwerk, das unter Netzwerktopologie mit Lastenausgleichdargestellt wird.
Action!
Um die Konfiguration eines Routers anzuzeigen, verwenden Sie den folgenden Junos OS CLI-Betriebsmodusbefehl:
user@host> show configuration | no-more
Beispielausgabe 1
Die folgende Konfigurationsausgabe gilt für den 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 gilt 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 gilt für den Transitrouter 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 gilt für den Transitrouter 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 gilt für den Transitrouter 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 gilt 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 Richtlinienoptionskonfigurationen für alle sechs Router in dem unter Beispiel dargestellten Beispielnetzwerk: MPLS-Netzwerkmit Lastenausgleich.
Auf allen Routern im Netzwerk sind 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 wird bei allen Routern die Router-ID (RID) manuell auf Hierarchieebene [edit routing-options] konfiguriert, um doppelte RID-Probleme zu vermeiden. Die passive Anweisung ist in der OSPF-Konfiguration enthalten, um sicherzustellen, dass Protokolle nicht über die Loopback-Schnittstelle (lo0) ausgeführt werden und dass die Loopback-Schnittstelle (lo0) im gesamten Netzwerk korrekt angekündigt wird.
Beispielausgänge 1, 3, 4 und 5 für R6, R2, R4und R9 zeigen die Basiskonfiguration für Transit-Label-Switched-Router. Die Basiskonfiguration umfasst alle für MPLS aktivierten Schnittstellen, das manuell konfigurierte RID und die relevanten Protokolle (RSVP, MPLS, BGP und OSPF).
Beispielausgabe 2 des Eingangsrouters R1 zeigt die Basiskonfiguration plus vier LSPs (lsp1lsp4) bis konfiguriert zu R0. Die vier LSPs sind mit unterschiedlichen primären Pfaden konfiguriert, die einen losen Hop durch R4 für lsp1 und lsp4, und durch R2 für lsp2 und lsp3angeben.
Zum Erstellen von Datenverkehr R1 eine statische Route (100.100.1.0/24) auf Hierarchieebene [edit routing-options static route] konfiguriert). 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 R1der Lastenausgleich mit der per-packet Option konfiguriert, und die Richtlinie wird auf Hierarchieebene [edit routing-options forwarding-table] exportiert.
Beispielausgabe 6 des Ausgangsrouters R0 zeigt einen LSP (r0-r6), der zum Erstellen von bidirektionalem Datenverkehr verwendet werden soll R6 . OSPF erfordert bidirektionale LSP-Erreichbarkeit, bevor der LSP im IGP angekündigt wird. Obwohl der LSP in der IGP angekündigt wird, finden keine Hello-Nachrichten oder Routing-Updates über den LSP statt – 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 verfügt es über eine statische Route (100.100.10.0/24) die auf der Hierarchieebene [edit routing-options static route] konfiguriert ist. 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 des Lastausgleichs basierend auf MPLS-Labels auf Routern der ACX-Serie
Tabelle 2 bietet detaillierte Informationen zu allen möglichen MPLS-LSP-Lastausgleichsoptionen.
Router der ACX-Serie können einen Lastenausgleich pro Paket in MPLS durchführen. Der Lastenausgleich kann sowohl für Informationen im IP-Header als auch für bis zu drei MPLS-Labels durchgeführt werden, wodurch eine gleichmäßigere Verteilung des MPLS-Datenverkehrs auf die nächsten Hops gewährleistet wird. Diese Funktion ist auf unterstützten Plattformen standardmäßig aktiviert und erfordert keine Konfiguration.
Load Balancing wird verwendet, um den Datenverkehr gleichmäßig zu verteilen, wenn ein einzelner nächster Hop über eine aggregierte Schnittstelle oder ein LAG-Bundle erfolgt. Load Balancing mit MPLS-Labels wird nur für LAG-Schnittstellen und nicht für Equal-Cost-Multipath-Verbindungen (ECMP) 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 der Weiterleitungstabelle installiert werden soll. Wenn sich die Menge der nächsten Hops für ein Ziel in irgendeiner Weise ändert, wird die Adresse des nächsten Hops mithilfe des Hash-Algorithmus neu ausgewählt. Sie können konfigurieren, wie der Hash-Algorithmus verwendet wird, um den Datenverkehr über Schnittstellen in einer aggregierten Ethernet-Schnittstelle (ae) auszugleichen.
Ein LSP neigt dazu, seine Platzierung auszugleichen, indem er eine der Schnittstellen in einem ae- Schnittstellenpaket nach dem Zufallsprinzip auswählt und exklusiv verwendet. Die Zufallsauswahl erfolgt unabhängig von jedem Transit-Router, wobei nur die IGP-Metriken (Interior Gateway Protocol) verglichen werden. Bandbreite oder Überlastungsgrad werden nicht berücksichtigt.
Auf Routern der ACX-Serie wird das Load Balancing auf gekennzeichneten Switched-Pfaden (LSPs) für Virtual Private LAN Service (VPLS), L2-Circuit und Layer2 Virtual Private Network (L2VPN) nicht unterstützt.
Um einen Lastenausgleich basierend auf den MPLS-Bezeichnungsinformationen durchzuführen, konfigurieren Sie die family mpls folgende Anweisung:
[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 Hierarchieebene [edit forwarding-options hash-key] einbinden.
Wenn Sie die Nutzlast ip (user@host# set forwarding-options hash-key family mpls payload ip) konfigurieren, ist die Konfiguration layer-3-only von und port-data obligatorisch.
Die Load-Balancing-Funktionalität kann ohne ordnungsgemäße Konfiguration der Hash-Schlüssel zu einem unvorhersehbaren Verhalten führen.
Für die Layer-2-VPN-/Pseudowire-Tunnelterminierung werden bis zu zwei Labels für das Hashing verwendet, und die MAC-Ziel- und Quelladressen der Nutzlast können optional ausgewählt werden. Diese Steuerelemente können verwendet werden, um den Ether-Pseudowire-Knopf in der MPLS-Familie unter der oben gezeigten Hash-Key-Konfiguration zu unterstützen. Da ACX2000 und ACX4000 jedoch auch TDM-Pseudodrähte unterstützen, müssen die Ether-Pseudowire-Knöpfe nur verwendet werden, wenn keine TDM-Pseudodrähte verwendet werden.
Für die Layer-3-VPN-Tunnelterminierung werden bis zu zwei Labels für die Phasen- und Nutzlast-IP-Quell- und Zieladressen verwendet, und optional können Layer-4-Quell- und Zielports ausgewählt werden. Diese Steuerelemente können zur Unterstützung von IP-Port-Datenknöpfen in MPLS der Familie unter der oben gezeigten Hash-Key-Konfiguration verwendet werden. Da Layer-4-Port MSB und LSB jedoch nicht einzeln ausgewählt werden können, wählt einer der Drehregler destination-lsb oder destination-msb oder einer der Drehregler source-lsb oder source-msb die Ziel- bzw. Quellports von Layer 4 aus.
Für LSR-Fälle werden bis zu drei Labels für das Hashing verwendet. Wenn beim Parsen der ersten drei Labels ein BOS angezeigt wird, untersucht BCM das erste Nibble der Nutzlast - wenn das Nibble 4 ist, wird die Nutzlast als IPv4 behandelt, und wenn das erste Nibble 6 ist, wird die Nutzlast als IPv6 behandelt, und in solchen Fällen können die Quell- und Ziel-IP-Adressen der Nutzlast 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 im LSR-Fall verwendet werden, und es ist nur ein Nur-Layer-3-Knopf anwendbar. BCM beansprucht keine Unterstützung für das Hashing in Feldern, die über die drei MPLS-Bezeichnungen hinausgehen. Load Balancing für eine einzelne Pseudowire-Sitzung findet im Falle von LSR nicht statt, da der gesamte für diese Sitzung spezifische Datenverkehr denselben Satz von MPLS-Labels trägt.
Load Balancing auf LSR AE-Schnittstellen kann für eine höhere Anzahl von MPLS-Sitzungen erreicht werden, d. h. für mindestens 10 Sitzungen. Dies gilt für CCC/VPLS/L3VPN. Im Falle eines Layer-3-VPN wird der Datenverkehr möglicherweise nicht gleichmäßig auf die Mitgliederlinks verteilt, da die Layer-3-Adressen (zusammen mit den Labels) auch für die Hash-Eingabefunktion berücksichtigt werden.
Bei LER-Szenarien ist bei ACX5048 und ACX5096 ein Hashing basierend auf Layer-3- und Layer-4-Feldern möglich, indem die Payload-Option in der Hierarchie "Family MPLS" konfiguriert wird. Das Hashing auf der LER basiert nicht auf Labels. Für den Layer-3-Service ist es zwingend erforderlich, die Nutzlast als "Layer-3-only" zu erwähnen und im Falle des Layer-4-Service "port-data" anzugeben. Sie können die Anzahl der Bezeichnungen auch bei der Konfiguration von Hash-Schlüsseln auf LER-Routern angeben.
Das LER- und LSR-Load-Balancing-Verhalten gilt für CCC/VPLS/Layer 3-VPN und andere IP-MPLS-Szenarien.
Diese Funktion gilt für aggregierte Ethernet- und aggregierte SONET/SDH-Schnittstellen. Darüber hinaus können Sie den Lastenausgleich für IPv4-Datenverkehr über Layer-2-Ethernet-Pseudoleitungen konfigurieren. Sie können auch den Lastenausgleich für Ethernet-Pseudowires basierend auf IP-Informationen konfigurieren. Die Option, IP-Informationen in den Hash-Schlüssel aufzunehmen, bietet Unterstützung für CCC-Verbindungen (Ethernet Circuit Cross Connect).
|
Aussage |
MPLS-LSP-Load-Balancing-Optionen |
|---|---|
|
|
Fügen Sie die erste Bezeichnung in den Hash-Schlüssel ein. Verwenden Sie diese Option für Pakete mit einem einzelnen Label. |
|
|
Fügen Sie die zweite Bezeichnung in den Hash-Schlüssel ein. Sie müssen die |
|
|
Fügen Sie die dritte Bezeichnung in den Hash-Schlüssel ein. Sie müssen auch die |
|
|
Schließt MPLS-Bezeichnungen aus dem Hash-Schlüssel aus. |
|
|
Hier können Sie konfigurieren, welche Teile der IP-Paketnutzlast in den Hash-Schlüssel aufgenommen werden sollen. Für den Paket-Transport-Switch der PTX-Serie ist dieser Wert standardmäßig festgelegt. |
|
|
Schließen Sie die IP-Nutzlast aus dem Hash-Schlüssel aus. |
|
|
Lastausgleich für IPv4-Datenverkehr über Layer-2-Ethernet-Pseudowires. |
|
|
Fügen Sie die IPv4- oder IPv6-Adresse in den Hash-Schlüssel ein. Sie müssen außerdem entweder |
|
|
Fügen Sie nur die Layer-3-IP-Informationen in den Hash-Schlüssel ein. Schließt alle |
|
|
Geben Sie die Feldinformationen für den Quell- und Zielport an. Standardmäßig werden das höchstwertige Byte und das niederwertigste Byte der Quell- und Zielportfelder im Hash-Schlüssel verwendet. Um bestimmte Bytes auszuwählen, die im Hashschlüssel verwendet werden sollen, schließen Sie eine oder mehrere der |
|
|
Fügen Sie das niederwertigste Byte des Zielports in den Hash-Schlüssel ein. Kombinierbar mit allen anderen |
|
|
Fügen Sie das höchstwertige Byte des Zielports in den Hash-Schlüssel ein. Kombinierbar mit allen anderen |
|
|
Fügen Sie das niederwertigste Byte des Quellports in den Hash-Schlüssel ein. Kombinierbar mit allen anderen |
|
|
Fügen Sie das höchstwertige Byte des Quellports in den Hash-Schlüssel ein. Kombinierbar mit allen anderen |
Um sowohl die IP-Adresse als auch die erste Bezeichnung in den Hash-Schlüssel aufzunehmen, 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 das erste und zweite Label in den Hash-Schlüssel aufzunehmen, konfigurieren Sie die label-1 Optionen and label-2 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;
label-2;
payload {
ip;
}
Stellen Sie einen ordnungsgemäßen Lastenausgleich sicher, indem Sie die label-1Optionen , label-2und label-3 auf Hierarchieebene [edit forwarding-options hash-key family mpls] einschließen:
[edit forwarding-options hash-key family mpls] label-1; label-2; label-3;
MPLS-gekapselte Nutzlast Load-Balancing – Übersicht
Router können einen Lastenausgleich pro Paket in MPLS durchführen. Der Lastenausgleich kann sowohl für die Informationen im IP-Header als auch für bis zu drei MPLS-Labels durchgeführt werden, wodurch eine gleichmäßigere Verteilung des MPLS-Datenverkehrs auf die nächsten Hops gewährleistet wird.
Load Balancing wird verwendet, um den Datenverkehr gleichmäßig zu verteilen, wenn die folgenden Bedingungen zutreffen:
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 der Lastenausgleich zur Verteilung des Datenverkehrs verwendet wird, wird standardmäßig ein Hashalgorithmus verwendet, um eine Next-Hop-Adresse auszuwählen, die in der Weiterleitungstabelle installiert werden soll. Wenn sich die Menge der nächsten Hops für ein Ziel in irgendeiner Weise ändert, wird die Adresse des nächsten Hops mithilfe des Hash-Algorithmus neu ausgewählt.
Bei Netzwerken mit mehreren Transportschichten, wie z. B. 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 Kapselung zu bestimmen, stützt sich die PFE auf das Vorhandensein bestimmter Codes oder Nummern an festen Nutzlasten. z. B. das Vorhandensein von Nutzlasttyp 0X800 oder das Vorhandensein von Protokollnummer 4 für ein IPv4-Paket. In Junos OS können Sie eine Option konfigurieren zero-control-word , um den Start eines Ethernet-Frames in einer MPLS-Ether-Pseudowire-Nutzlast anzuzeigen. Wenn der Hash-Generator dieses Steuerwort sieht, das aus vier Bytes mit einem numerischen Wert von Nullen besteht, geht er davon aus, dass am Ende des Steuerworts in einem MPLS-Ether-Pseudowire-Paket ein Ethernet-Frame beginnt.
Konfigurieren Sie bei DPC-I-Chip-basierten Karten die zero-control-word Option auf Hierarchieebene [edit forwarding-options hash-key family mpls ether-pseudowire] , und bei MPC-Karten konfigurieren Sie die zero-control-word Option auf Hierarchieebene [edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] .
Konfigurieren der MPLS-gekapselten Nutzlast für den Lastenausgleich
Wenn der Lastenausgleich zur Verteilung des Datenverkehrs verwendet wird, wird standardmäßig ein Hashalgorithmus verwendet, um eine Next-Hop-Adresse auszuwählen, die in der Weiterleitungstabelle installiert werden soll. Wenn sich die Menge der nächsten Hops für ein Ziel in irgendeiner Weise ändert, wird die Adresse des nächsten Hops mithilfe des Hash-Algorithmus neu ausgewählt. Konfigurieren Sie die zero-control-word Option so, dass der Beginn eines Ethernet-Frames in einer MPLS-Ether-Pseudowire-Nutzlast angezeigt wird. Wenn der Hash-Generator dieses Steuerwort sieht, vier Bytes mit einem Zahlenwert von Nullen, geht er davon aus, dass der Ethernet-Frame am Ende des Steuerworts in einem MPLS-Ether-Pseudowire-Paket beginnt.
Bevor Sie mit der Konfiguration der MPLS-gekapselten Nutzlast für den Lastenausgleich beginnen, konfigurieren Sie Routing- und Signalisierungsprotokolle.
So konfigurieren Sie die MPLS-gekapselte Nutzlast für den Lastenausgleich:
zero-control-word Option so, dass der Beginn eines Ethernet-Frames in einer MPLS-Ether-Pseudowire-Nutzlast angezeigt wird. Konfigurieren Sie die
zero-control-wordOption für DPC-I-Chip-basierte Karten auf Hierarchieebene[edit forwarding-options hash-key family mpls ether-pseudowire].[edit forwarding-options hash-key family mpls ether-pseudowire] user@host# set zero-control-word
Konfigurieren Sie die
zero-control-wordOption für MPC-Karten auf Hierarchieebene[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire].[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 und SR-TE IP-Routen kombinieren und eine Multipath-Route in der Routing-Informationsdatenbank (auch als Routing-Tabelle bezeichnet) installieren. Anschließend können Sie selektiven Dienstdatenverkehr mithilfe der Multipath-Route über die Richtlinienkonfiguration steuern.
- Grundlegendes zu richtlinienbasierten Multipath-Routen
- Vorteile von richtlinienbasierten Multipath-Routen
- Richtlinienbasierte Multipath-Routen für die Routenauflösung
- Beispiel für die Routenauflösung mit richtlinienbasierten Multipath-Routen
- Erweiterung der Class-of-Service (CoS) Weiterleitungsrichtlinie
- Verbesserungen am Policy Match Protocol
- Auswirkungen der Konfiguration der richtlinienbasierten Multipath-Route auf die Netzwerkleistung
Grundlegendes zu richtlinienbasierten Multipath-Routen
Es gibt verschiedene Transportprotokolle in einem Netzwerk, z. B. IGP, die als IGP, RSVP, LDP bezeichnet werden, und Segment-Routing-Traffic-Engineering-Protokolle (SR-TE), die zur Auflösung des Dienstdatenverkehrs verwendet werden. Sie konnten jedoch keine Kombination der Transportprotokolle verwenden, um den Dienstdatenverkehr aufzulösen. Mit der Einführung der richtlinienbasierten Multipath-Funktion können Sie Segment-Routing-SR-TE-LDP- oder RSVP-Routen mit SR-TE IP-Routen kombinieren, um eine Multipath-Route zu erstellen, die in der Routing-Informationsdatenbank installiert wird. Sie können BGP-Service-Routen über die Multipath-Route über die 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 den Lastenausgleich verwendet werden. Alle unterstützenden Routen des Multipath-Routeneintrags müssen sich in derselben Routing-Informationsdatenbank befinden. Wenn sich die unterstützenden Routen in einer anderen Routing-Informationsbasis befinden, können Sie die rib-group Konfigurationsanweisung verwenden, um Routeneinträge zu einer bestimmten Routing-Informationsbasis hinzuzufügen.
Sie können eine Multipath-Route mithilfe einer Richtlinie konfigurieren, um die Liste der Routen auszuwählen, deren nächste Hops miteinander kombiniert werden sollen. Wenn Sie die policy-multipath Anweisung zusammen mit der policy Anweisung auf Hierarchieebene [edit routing-options rib routing-table-name] 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 auf Hierarchieebene [edit routing-instances] 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 anhand 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 die Flexibilität, Core-Netzwerkprotokolle zu kombinieren, um selektiven Datenverkehr zu steuern.
-
Optimiert die Netzwerkleistung mit gewichtetem Mehrwege-Mehrpfad zu gleichen Kosten unter Verwendung von Multipath-Routen.
Richtlinienbasierte Multipath-Routen für die Routenauflösung
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 installieren. Die richtlinienbasierten Multipath-Routen sind keine aktiven Einträge in der Routing-Informationsdatenbank. Wenn eine Multipath-Route durch Konfiguration der Richtlinie generiert wird, wird sie zum Auflösen der nächsten Hops des Protokolls anstelle von aktiven Routen verwendet. Ein nächster Hop für eine Multipath-Route wird erstellt, indem Gateways der nächsten Hops jeder einzelnen Route zusammengeführt werden.
Beachten Sie Folgendes, wenn Sie richtlinienbasierte Multipath-Routen für die Routenauflösung konfigurieren:
-
Wenn die Mitgliedsroute einer Multipath-Route auf einen anderen Hop als den nächsten Hop des Routers oder einen indirekten nächsten Hop mit Weiterleitung des nächsten Hops an den nächsten Hop des Routers verweist, werden solche nächsten Hops ignoriert.
-
Wenn die konstituierenden Routen auf den indirekten nächsten Hop verweisen, werden Gateways aus dem Weiterleitungs-nächsten Hop zusammengeführt, und der indirekte nächste Hop wird ignoriert.
-
Wenn die Gesamtzahl der Gateways die
maximum-ecmpauf dem Gerät unterstützte Anzahl überschreitet, werden nur diemaximum-ecmpGateways beibehalten und alle anderen Gateways ignoriert. -
Gateways mit geringerem Gewicht werden bevorzugt. Wenn eine der Mitgliedsrouten eine Uniliste von indirekten nächsten Hops aufweist und jeder der nächsten Hops auf einen weiterleitenden nächsten Hop verweist, kann es sowohl beim indirekten nächsten Hop als auch beim Weiterleitungs-nächsten Hop Gewichtungswerte geben. In solchen Fällen wird der Gewichtungswert der Gateways aktualisiert, um den kombinierten Effekt der Gewichtungen auf beiden Ebenen widerzuspiegeln.
Beispiel für die Routenauflösung mit richtlinienbasierten Multipath-Routen
Nehmen wir als Beispiel an, dass es Segment-Routing-LSPs, Traffic-Engineering-LSPs, Label-IS-IS-Routen und LDP-LSPs für ein Ziel 10.1.1.1/32 gibt, wie in der folgenden Ausgabe 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 der Segmentrouting-LSP der aktive Routeneintrag zum Ziel 10.1.1.1, und standardmäßig wird nur diese Route verwendet, um alle Services aufzulösen, die über 10.1.1.1aufgelöst werden.
Wenn es erforderlich ist, mehr als ein Protokoll zum Auflösen von Dienstrouten zu verwenden, können Sie dies erreichen, indem Sie policy-multipath so konfigurieren, dass die Protokolle kombiniert werden. Wenn z. B. Segment-Routing und LDP-Pfade für die Service-Auflösung erforderlich sind, müssen Sie die Kombination des Trennungs-Routings und der LDP-Routen für das Präfix10.1.1.1konfigurierenpolicy-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 das Präfix 10.1.1.1/32, die die zugehörigen Routing-Einträge des Segment-Routings und der LDP-Protokolle 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 der Befehlsausgabe entnehmen, dass die Multipath-Route die nächsten Hops des Segment-Routings und LDP-Pfade kombiniert. Die Multipath-Route ist nicht aktiv, und standardmäßig sind die Routenpräferenz und die Metrik mit denen 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 active-route nicht Teil von Multipath ist.
-
Segmentieren Sie Routing-LSPs und LDP-LSPs.
-
Segmentieren Sie Routing, Traffic-Engineering-LSPs und kennzeichnen Sie IS-IS-Pfade.
-
Segmentieren Sie Routing-LSPs, LDP-LSPs und beschriften Sie IS-IS-Pfade.
Sie können jedoch keine Multipath-Route von LDP erstellen und IS-IS beschriften, da die aktive Route nicht Teil der Multipath-Route ist.
Bei derselben Konfiguration wird diese Route unter der Annahme, dass eine statische Route 1.2.3.4/32 mit dem nächsten Hop des Protokolls 10.1.1.1konfiguriert ist, mithilfe der Multipath-Route sowohl über Segment-Routing-LSPs als auch 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)
Erweiterung der Class-of-Service (CoS) Weiterleitungsrichtlinie
Für Class-of-Service-basierte Weiterleitung müssen Sie die forwarding-policy next-hop-map configuration-Anweisung verwenden.
Vor Junos OS Version 19.1R1 umfassten die Übereinstimmungsbedingungen, die unter Class-of-Service-basierter Weiterleitung unterstützt wurden:
-
next-hop– Nächster Hop basierend auf der ausgehenden Schnittstelle oder der Adresse des nächsten Hops abgleichen.
-
lsp-next-hop– Benannte LSPs mit dem regulären Ausdruck des LSP-Namens abgleichen.
-
non-lsp-next-hop– Stimmt mit allen Sprachdienstleistern ohne LSP-Namen überein.
Mit der richtlinienbasierten Multipath-Routenfunktion können Sie auch alle nächsten Hops ohne Bezeichnung für bestimmte Präfixe abgleichen. Dazu müssen Sie die non-labelled-next-hop Option auf Hierarchieebene [edit class-of-service forwarding-policy next-hop-map map-name forwarding-class forwarding-class-name aktivieren.
Zum Beispiel:
[edit]
class-of-service {
forwarding-policy {
next-hop-map abc {
forwarding-class best-effort {
non-labelled-next-hop;
}
}
}
}
Verbesserungen am Policy Match Protocol
Wenn Sie vor Junos OS Version 19.1R1 eine Richtlinie zum Abgleich des Protokolls mithilfe der from protocol Anweisung auf Hierarchieebene [edit policy-options policy-statement statement-name] verwendet haben, wurden alle Protokollrouten (mit und ohne Bezeichnung) abgeglichen. Mit der richtlinienbasierten Multipath-Routenfunktion können Sie gekennzeichnete Protokollrouten spezifisch abgleichen.
Folgende Optionen stehen zum Abgleich von gekennzeichneten Protokollen zur Verfügung:
-
l-isis– Übereinstimmung mit beschrifteten IS-IS-Routen. Die
isisOption stimmt mit IS-IS-Routen überein, mit Ausnahme von IS-IS-Routen mit Beschriftung. -
l-ospf– Übereinstimmung mit beschrifteten OSPF-Routen. Die
ospfOption stimmt mit allen OSPF-Routen überein, einschließlich OSPFv2, OSPFv3 und Label-OSPF.
Zum Beispiel:
[edit]
policy-options {
policy-statement abc {
from protocol [ l-ospf l-isis ];
}
}
Auswirkungen der Konfiguration der richtlinienbasierten Multipath-Route auf die Netzwerkleistung
Wenn Sie die richtlinienbasierte Multipath-Route konfigurieren, führt eine Änderung der Route in der Routing-Informationsdatenbank dazu, dass die Richtlinie ausgewertet wird, um zu prüfen, ob eine Multipath-Route erstellt werden muss. Da für diese Funktion erforderlich ist, dass sich Mitgliedsrouten in derselben Routing-Informationsdatenbank befinden müssen, wird die rib-group Anweisung verwendet, um Routen aus verschiedenen Routing-Informationsdatenbanken zusammenzuführen. Wenn Sie die rib-group Anweisung auf Anwendungsebene konfigurieren, erhöht sich die Anzahl der Routen im System.
Wenn es eine Reihe von Routen in der Routing-Informationsdatenbank gibt, führt eine ständige Änderung der Routen zu einer Neubewertung der Multipath-Richtlinie. Dies kann 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 des MPLS-Datenverkehrs
In einem MPLS-Paket kommt der IP-Header unmittelbar nach dem MPLS-Header. Die IP-basierte Filterfunktion bietet einen tiefgreifenden Inspektionsmechanismus, bei dem maximal acht MPLS-Labels der inneren Nutzlast inspiziert werden können, um die Filterung des MPLS-Datenverkehrs auf der Grundlage von IP-Parametern zu ermöglichen. Der gefilterte MPLS-Datenverkehr kann auch an ein Überwachungsgerät gespiegelt werden, um netzwerkbasierte Dienste im MPLS-Kernnetzwerk anzubieten.
- IP-basierte Filterung des MPLS-Datenverkehrs
- Selektive Port-Spiegelung des MPLS-Datenverkehrs
- Beispielkonfigurationen
IP-basierte Filterung des MPLS-Datenverkehrs
Vor Junos OS Version 18.4R1 wurde die 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 IPv4- und IPv6-Pakete mit MPLS-Tags basierend auf IP-Parametern wie Quell- und Zieladressen, Layer-4-Protokolltyp sowie Quell- und Zielports anwenden.
Mit der IP-basierten Filterfunktion können Sie MPLS-Pakete am Eingang einer Schnittstelle filtern, wobei die Filterung mithilfe von Übereinstimmungsbedingungen für die innere Nutzlast des MPLS-Pakets erfolgt. Der selektive MPLS-Datenverkehr kann dann mithilfe logischer Tunnel an ein Fernüberwachungsgerät gespiegelt werden.
Zur Unterstützung der IP-basierten Filterung wurden zusätzliche Übereinstimmungsbedingungen hinzugefügt, die es ermöglichen, MPLS-Pakete gründlich zu untersuchen, 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 IPv4- und IPv6-Pakete mit MPLS-Tags unterstützt. Mit anderen Worten, die MPLS-Filter stimmen nur dann mit IP-Parametern überein, wenn die IP-Nutzlast unmittelbar nach den MPLS-Bezeichnungen erfolgt.
In anderen Szenarien, in denen die MPLS-Nutzlast 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.
Die folgenden Übereinstimmungsbedingungen wurden für die IP-basierte Filterung von MPLS-Datenverkehr hinzugefügt:
IPv4-Quelladresse
IPv4-Zieladresse
IPv6-Quelladresse
IPv6-Zieladresse
Protokoll
Quell-Port
Zielhafen
Liste der Quell-IPv4-Präfixe
IPv4-Präfixliste des Ziels
Liste der IPv6-Präfixe (Quell-IPv6)
Liste der IPv6-Zielpräfixe
Die folgenden Übereinstimmungskombinationen werden für die IP-basierte Filterung von MPLS-Datenverkehr unterstützt:
Quell- und Zieladressen stimmen mit IPv4- und IPv6-Präfixlisten überein.
Quell- und Zielportadressen und Protokolltypen stimmen mit den Bedingungen mit IPv4- und IPv6-Präfixlisten überein.
Selektive Port-Spiegelung des MPLS-Datenverkehrs
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 Firewallfilter angewendet, der beim Ein- oder Ausgang einer beliebigen Schnittstelle angewendet wird. In ähnlicher Weise bietet die selektive Port-Spiegelungsfunktion die Möglichkeit, MPLS-Datenverkehr, der basierend auf IP-Parametern gefiltert wird, mithilfe logischer Tunnel auf ein gespiegeltes Ziel zu spiegeln.
Um die selektive Portspiegelung zu aktivieren, werden zusätzlich zu den vorhandenen counter, acceptund discard und -Aktionen zusätzliche Aktionen auf Hierarchieebene [edit firewall family mpls filter filter-nameterm term-name then]konfiguriert:
port-mirrorport-mirror-instance
Port Mirroring
Die port-mirror Aktion aktiviert die globale Portspiegelung auf dem Gerät, was für alle Packet Forwarding Engines (PFEs) und zugehörige Schnittstellen gilt.
Für den MPLS-Familienfilter 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 Port-Spiegelung von Ausgabezielen anzupassen, anstatt eine einzige systemweite Konfiguration für die Port-Spiegelung 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] einschließen. Anschließend können Sie einzelne Port-Spiegelungsinstanzen je nach Gerätehardware mit einem FPC, PIC oder (Forwarding Engine Board (FEB) verknüpfen.
Für MPLS-Familienfilter ist die port-mirror-instance Aktion nur für die Portspiegelungsinstanz aktiviert.
Für beide port-mirrorport-mirror-instance Aktionen muss die Ausgabeschnittstelle mit der Layer-2-Familie und nicht mit der MPLS-Familie (Layer-3) aktiviert sein, damit die selektive Port-Spiegelungsfunktion funktioniert.
Beispielkonfigurationen
- Konfiguration der IP-basierten Filterung
- Konfiguration der selektiven Portspiegelung
- Konfiguration des gespiegelten Ziels
Konfiguration der IP-basierten Filterung
[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 der selektiven 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 beide port-mirrorport-mirror-instance Aktionen muss die Ausgabeschnittstelle mit der Layer-2-Familie und nicht mit der MPLS-Familie (Layer-3) aktiviert sein, damit die selektive Port-Spiegelungsfunktion funktioniert.
Konfiguration des gespiegelten Ziels
[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;
}
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Feature Explorer, um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.