Optimierung des BGP-Pfads mit AIGP

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.

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

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
!

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

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
!

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
  !
 !
!

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