Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Kumuliertes Interior Gateway Protocol-Attribut

Anwendungsbeispiele

1. Multi-ASN-Netzwerk

Konfiguration

Verifizierung

2. Nahtloses MPLS (Single ASN)

Beobachtungen

Geräteprotokolle - anfänglich

AIGP-Lösung

Konfiguration

Konfigurationsbeispiel

Geräteprotokolle - nach der AIGP-Implementierung

Wichtige Überlegungen

AIGP ignorieren

Schlussfolgerung

Zugehörige Informationen

Einleitung

In diesem Dokument werden die AIGP-Metrik (Accumulated Interior Gateway Protocol) im Border Gateway Protocol (BGP) sowie deren Anwendungsfälle beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

- BGP

- Nahtloses MPLS-Netzwerk (Multiprotocol Label Switching)

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn unser Netzwerk aktiv ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen aller Befehle verstehen.

Hintergrundinformationen

Dieser Abschnitt bietet einen Überblick über die AIGP-Metrik und einige wichtige Überlegungen zu ihrer Verwendung.

Wie Sie wissen, steht IGP für Interior Gateway Protocol und steht für eine Gruppe von Routing-Protokollen, die innerhalb einer einzelnen administrativen Domäne ausgeführt werden. Das IGP trifft eine Pfadauswahl auf Grundlage des metrischen Werts.

BGP wurde entwickelt, um das Routing über eine große Anzahl unabhängiger autonomer Systeme (AS) mit eingeschränkter oder fehlender Koordination zwischen den jeweiligen Verwaltungen zu ermöglichen. Es trifft keine Pfadauswahl durch die Verwendung einer Metrik. Es gibt jedoch Bereitstellungen, in denen ein einzelner Administrator mehrere zusammenhängende BGP-Netzwerke ausführt. In solchen Fällen kann es sich als wünschenswert erweisen, dass das BGP Pfade auf Basis einer Metrik auswählt, genau wie es ein IGP tun würde.

Kumuliertes Interior Gateway Protocol-Attribut

Die AIGP-Metrik (definiert über RFC 7311) ist ein optionales, nicht transitives BGP-Pfadattribut. Das Wertefeld des AIGP-Attributs wird als ein Satz von Type/Length/Value-Elementen (TLVs) definiert. Die BGP-AIGP-TLV enthält die kumulierte IGP-Metrik.

Hinweis: BGP-Router, die die optionalen nicht transitiven Attribute (z. B. AIGP) nicht unterstützen, müssen diese Attribute löschen und dürfen sie nicht an andere BGP-Peers weitergeben. Die AIGP-Metrik ist nicht als transitiv zwischen völlig unterschiedlichen autonomen Systemen (nur über interne AS-Grenzen hinweg) konzipiert.

Anwendungsbeispiele

1. Multi-ASN-Netzwerk

Heute gibt es viele Netzwerke in einer einzigen administrativen Domäne, die aus verschiedenen Gründen in mehrere ASNs unterteilt sind. Dafür gibt es viele mögliche Gründe:

- IGP-Skalierung

- Ein Anbieternetzwerk wurde von einem anderen Netzwerkanbieter erworben, die BGP-ASNs wurden jedoch noch nicht intern zusammengeführt.

- Verschiedene Geschäftsbereiche verfügen intern über separate Netzwerke

- BGP-Verbünde mit Sub-AS

- Nahtloses MPLS usw.

In Netzwerken wie diesen kann es nützlich sein, dem BGP zu gestatten, seine Entscheidungen auf Grundlage der IGP-Metrik zu treffen, sodass das BGP den kürzesten End-to-End-Pfad zwischen zwei Knoten auswählt, selbst wenn sich die Knoten in zwei verschiedenen ASNs befinden.

Beispiel: ABC-Netzwerk, das in zwei BGP-ASNs, ASN 1 und ASN 2, unterteilt ist. Sie verwenden Peering für ASBR, und die IGP-Kosten für die Verbindung stellen die Bandbreite dar. Ziel hierbei ist ein optimaler End-to-End-Pfad zwischen PE11 und PE21.

Multi-ASN-Netzwerk ohne AIGP

Anmerkung:

1. Vorausgesetzt, dass auf RR1/2 Add-path aktiviert ist, um beide NHs für PEx anzukündigen.

2. Die im vorherigen Szenario verwendeten Geräte werden alle mit Cisco IOS-XE ausgeführt.

PE11#sh bgp ipv4 unicast 10.0.21.21/32

BGP routing table entry for 10.0.21.21/32, version 20

Paths: (2 available, best #2, table default)

Not advertised to any peer

Refresh Epoch 3

2

192.168.0.12 (metric 211) from 192.168.11.11 (192.168.11.11)

Origin IGP, metric 0, localpref 100, valid, internal

Originator: 192.168.0.12, Cluster list: 192.168.11.11

rx pathid: 0x1, tx pathid: 0

Refresh Epoch 3

2

192.168.0.11 (metric 201) from 192.168.11.11 (192.168.11.11)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 192.168.0.11, Cluster list: 192.168.11.11

rx pathid: 0x0, tx pathid: 0x0

Wenn AiGP in der Topologie aktiviert ist (auf PE11, PE32, ASBR1x, ASBR2x, RR1, RR2), wählt PE11 jetzt den Pfad mit den niedrigsten End-to-End-IGP-Kosten.

Multi-ASN-Netzwerk mit AIGP

Konfiguration

PEx, ASBRx, RN:

Konfiguration der AIGP-Funktion:

router bgp ASN

neighbor <NBR_IP> aigp

!

Hinweis: Das BGP-Peering wird beendet und wiederhergestellt, um diese neue Funktion auszuhandeln. Es wird daher empfohlen, dies in einem Wartungsfenster durchzuführen.

AIGP-Metrik für ein Präfix ankündigen

PE 21:

route-map SET_AIGP permit 10

set aigp-metric igp-metric

!

router bgp 2

address-family {ipv4|ipv6} unicast

network 10.0.21.21 mask 255.255.255.255 route-map SET_AIGP

!

Verifizierung

PE11#sh bgp ipv4 unicast 10.0.21.21/32

BGP routing table entry for 10.0.21.21/32, version 21

Paths: (2 available, best #2, table default)

Not advertised to any peer

Refresh Epoch 3

2

192.168.0.11 (metric 201) from 192.168.11.11 (192.168.11.11)

Origin IGP, aigp-metric 501, metric 0, localpref 100, valid, internal

Originator: 192.168.0.11, Cluster list: 192.168.11.11

rx pathid: 0x1, tx pathid: 0

Refresh Epoch 3

2

192.168.0.12 (metric 211) from 192.168.11.11 (192.168.11.11)

Origin IGP, aigp-metric 201, metric 0, localpref 100, valid, internal, best

Originator: 192.168.0.12, Cluster list: 192.168.11.11

rx pathid: 0x0, tx pathid: 0x0

2. Nahtloses MPLS (Single ASN)

In einem großen Core-Netzwerk eines Service Providers ist das Transportnetzwerk in der Regel in verschiedene IGP-Domänen unterteilt, die unter Verwendung von BGP mit der Bezeichnung Unicast zusammengeführt werden, um einen End-to-End Labeled Switched Path (LSP) bereitzustellen. Border Router führen Next Hop Self (NHS) in BGP LU AF aus.

IGP/LDP überträgt die Präfix-/Label-Informationen nur in der lokalen Region/Domäne. Anschließend überträgt das BGP das Präfix/Label an alle Remote-Bereiche/Domänen, indem es die Routen an den Bereichsgrenzen in das BGP umverteilt. Die Routen/Labels werden dann mithilfe von LSPs angekündigt. Der nächste Hop für die Route wird an jedem ABR zum lokalen Router geändert, sodass keine IGP-Routen über Gebiets-/Domänengrenzen hinweg ausgelaufen sind.

In diesem Topologiediagramm ist eine einzelne BGP-Domäne in zwei IGP-Domänen (CORE und Access-1) unterteilt. Die Zahl neben jeder Verbindung stellt die IGP-Kosten/Kennzahlen dieser Verbindung dar.

Nahtloses MPLS-Netzwerk ohne AIGP

Herausforderung: Abwärtiger Datenverkehr vom PS-Core zum eNB/gNB (mit CSR15 verbunden) nimmt einen asymmetrischen und suboptimalen Pfad im Vergleich zum aufsteigenden Datenverkehr vom eNB/gNB (mit CSR15 verbunden) zum PS-Core, was zu Latenzproblemen im Mobilitätsdatenverkehr führt.

Beobachtungen

1. Hauptsächlich beobachtet bei Szenarien mit geografischen Grenzen, bei denen derselbe Aggregation Router als gemeinsamer Border Router für mehrere Access-Domänen fungiert (z. B. AGG102 im oben erwähnten Image).

2. Für steigenden Datenverkehr wählt der Cell-Site Router (CSR) den nächstgelegenen Grenzrouter aus. Beispielsweise wählt CSR15 AGG102 als NextHop aus.

3. Für Downward-Datenverkehr wählt der Service Aggregation Router (SAR) auch den nächstgelegenen Grenzrouter aus. SAR150 wählt beispielsweise AGG101 (Kosten 180 < 200).

Geräteprotokolle - anfänglich

Upstream-Datenverkehr - CSR15 bis SAR150

RP/0/0/CPU0:CSR15#traceroute mpls ipv4 10.0.2.150/32 so 10.0.2.15

Tracing MPLS Label Switched Path to 10.0.2.150/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.15.102.15 MRU 1500 [Labels: explicit-null/16150 Exp: 0/0]

L 1 10.15.102.102 MRU 1500 [Labels: 16150 Exp: 0] 0 ms                !!!! AGG102

. 2 *                                                                 !!!! P112 does not have a route to CSR15

! 3 10.112.150.150 20 ms                                              !!!! SAR150

Downstream-Datenverkehr - SAR150 bis CSR15

RP/0/0/CPU0:SAR150#traceroute mpls ipv4 10.0.2.15/32 source 10.0.2.150

Tracing MPLS Label Switched Path to 10.0.2.15/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.101.150.150 MRU 1500 [Labels: explicit-null/16015 Exp: 0/0]

L 1 10.101.150.101 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                 !!! AGG101

L 2 10.11.101.11 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                   !!! CSR11

L 3 10.11.12.12 MRU 1500 [Labels: 16015 Exp: 0] 10 ms                    !!! CSR12

L 4 10.12.13.13 MRU 1500 [Labels: 16015 Exp: 0] 20 ms                    !!! CSR13

L 5 10.13.14.14 MRU 1500 [Labels: explicit-null Exp: 0] 30 ms            !!! CSR14

! 6 10.14.15.15 30 ms                                                    !!! CSR15

AIGP-Lösung

Ziel hierbei ist ein optimaler End-to-End-Pfad zwischen SAR- und CSR-Routern. Zur Berechnung der Entfernung zwischen SAR- und CSR-Routern wird BGP Labeled Unicast (RFC 3107) verwendet. Die für die einzelnen Core-Verbindungen verfügbare Bandbreite wird den IGP-Kosten zugeordnet, daher muss das BGP diese Kosten zwischen den einzelnen PEs korrekt tragen. Diese Funktionalität wird mit dem AiGP erreicht.

Nahtloses MPLS-Netzwerk mit

AIGPSnahtloses MPLS-Netzwerk mit AIGP

Anmerkung:

1. Unter der Annahme, dass auf RR1/2-, AGG-, CSR- und SAR-Geräten Add-Path aktiviert ist, um beide NH anzukündigen.

2. Alle im oben genannten Szenario verwendeten Geräte basieren auf Cisco IOS-XR.

Konfiguration

Die Funktion des AiGP-Pfadattributs muss zwischen den BGP-Peers vereinbart werden. AiGP-Metriken sind nur in Präfix-Advertisements zwischen AiGP-fähigen Peers enthalten. Die AIGP-Funktion wird für einen einzelnen BGP-Peer und eine bestimmte BGP-Adressfamilie konfiguriert.

router bgp ASN

neighbor <NBR_IP>

address-family ipv4 unicast

aigp [disable]

Die AIGP-Metrik ist ein 32-Bit-Wert (0 bis 4.294.967.295). Sie kann während der Neuverteilung, der Routengenerierung über eine Netzwerkanweisung oder beim Empfang eines Präfix mit einer Routenzuordnung/Routenrichtlinie festgelegt werden.

route-policy AIGP_POLICY

set aigp-metric igp-cost

end-policy

!

router bgp ASN

address-family {ipv4|ipv6} unicast

network <NETWORK/MASK> route-policy AIGP_POLICY

or

redistribute {ospf|isis} {process-id} route-policy AIGP_POLICY metric VALUE

!

Anmerkung:

1. Bei neu verteilten Routen ist der dem AiGP-Attribut zugewiesene Wert der Wert von iGP next hop to the route oder wie durch eine Routenrichtlinie festgelegt.

2. Bei statischen Routen, die in das BGP umverteilt werden, ist der zugewiesene Wert der Wert des nächsten Hop zur Route oder wie durch eine Routenrichtlinie festgelegt.

3. Die Route wird über eine Netzwerkanweisung in das BGP importiert. Der zugewiesene Wert ist der Wert des nächsten Hop für die Route oder gemäß einer Routenrichtlinie.

Konfigurationsbeispiel

CSR15:

! Additional config lines related to AIGP are marked in RED color

route-policy SID($SID)

set label-index $SID

set aigp-metric igp-cost

end-policy

!

router bgp 1

address-family ipv4 unicast

network 10.0.2.15/32 route-policy SID(15)

neighbor-group RR

address-family ipv4 labeled-unicast

aigp

!

!

!

Hinweis: Eine ähnliche Konfiguration wurde für alle entsprechenden BGP-Peering-Geräte durchgeführt.

Geräteprotokolle - nach der AIGP-Implementierung

Downstream-Datenverkehr - SAR150 bis CSR15

RP/0/0/CPU0:SAR150#sh bgp ipv4 labeled-unicast 10.0.2.15/32

BGP routing table entry for 10.0.2.15/32

Versions:

Process bRIB/RIB SendTblVer

Speaker 411 411

Local Label: 16015

Last Modified: Oct 24 11:05:26.796 for 00:00:04

Paths: (2 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

Local

10.0.2.102 (metric 200) from 10.0.2.100 (10.0.2.15)

Received Label 16015

Origin IGP, metric 0, localpref 100, aigp metric 20, valid, internal, best, group-best, labeled-unicast

Received Path ID 1, Local Path ID 1, version 410

Originator: 10.0.2.15, Cluster list: 10.0.2.100, 10.0.2.102

Total AIGP metric 220

Label-Index: 15

Path #2: Received by speaker 0

Not advertised to any peer

Local

10.0.2.101 (metric 180) from 10.0.2.100 (10.0.2.15)

Received Label 16015

Origin IGP, metric 0, localpref 100, aigp metric 60, valid, internal, backup, add-path, labeled-unicast

Received Path ID 8, Local Path ID 7, version 411

Originator: 10.0.2.15, Cluster list: 10.0.2.100, 10.0.2.101

Total AIGP metric 240

Label-Index: 15

RP/0/0/CPU0:SAR150#traceroute mpls ipv4 10.0.2.15/32 so 10.0.2.150

Tracing MPLS Label Switched Path to 10.0.2.15/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.112.150.150 MRU 1500 [Labels: 16102/16015 Exp: 0/0]

L 1 10.112.150.112 MRU 1500 [Labels: explicit-null/16015 Exp: 0/0] 10 ms          !!! P112

L 2 10.102.112.102 MRU 1500 [Labels: explicit-null Exp: 0] 10 ms                  !!! AGG102

! 3 10.15.102.15 20 ms                                                            !!! CSR15

Upstream-Datenverkehr - CSR15 bis SAR150

RP/0/0/CPU0:CSR15#traceroute mpls ipv4 10.0.2.150/32 source 10.0.2.15

Tracing MPLS Label Switched Path to 10.0.2.150/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 10.15.102.15 MRU 1500 [Labels: explicit-null/16150 Exp: 0/0]

L 1 10.15.102.102 MRU 1500 [Labels: 16150 Exp: 0] 10 ms                 !!! AGG102

. 2 *                                                                   !!! P112 does not have a route to CSR15

! 3 10.112.150.150 30 ms                                                !!! SAR150

Wichtige Überlegungen

- Änderungen der IGP-Kosten (z. B. Änderungen der physischen Topologie aufgrund von Verbindungsausfällen und mehr) haben auch Auswirkungen auf das BGP. Dies kann zu einer Abwanderung der BGP-Routen führen. Diese Konvergenz hängt auch vom Wert der BGP Next Hop Trigger-Verzögerung ab, der für nicht kritische Ereignisse konfiguriert wurde.

- Mit Einführung von AiGP wird die Auswahl des besten Pfades geändert. Dabei wird BGP AIGP nach den lokalen BGP-Einstellungen und vor das AS_PATH-Attribut gesetzt. Wenn es also Richtlinien über AS_PATH gibt, die bereits vorhanden sind, müssen diese möglicherweise erneut überprüft werden.

- Wenn es zwei Pfade gibt, einen mit der AIGP-Metrik und einen anderen ohne, bevorzugt BGP immer einen Pfad mit der AIGP-Metrik.

AIGP ignorieren

Ein Gerät, auf dem das Border Gateway Protocol (BGP) ausgeführt wird, kann auch so konfiguriert werden, dass die AIGP-Metrik beim Auswahlprozess für den besten Pfad zwischen zwei Pfaden ignoriert wird, wenn ein Pfad nicht über die AIGP-Metrik verfügt. Verwenden des bgp bestpath aigp ignore Befehls im Router-Konfigurationsmodus Um den Standardbetrieb des Geräts wiederherzustellen, verwenden Sie die negative Form dieses Befehls.

[no] bgp bestpath aigp ignore

Standardmäßig bevorzugt BGP immer einen Pfad mit der AIGP-Metrik. Wenn zwei Pfade vorhanden sind, der eine mit der AIGP-Metrik und der andere ohne, führt die Ausführung desbgp bestpath aigp ignore Befehls dazu, dass das BGP den besten Pfad berechnet, als ob keiner der Pfade über die AIGP-Metrik verfügt.

Schlussfolgerung

BGP AIGP Attribut ist sicherlich entwickelt, um bestimmte Nischen Anwendungsfälle zu lösen, aber es muss vorsichtig verwendet werden.

Zugehörige Informationen

- Konfigurieren des AIGP-Metrikattributs für BGP

- Technischer Support und Downloads von Cisco