Zusammen gekennzeichnet und ungekennzeichnet in einem BGP-Nachbarn in IOS-XR

Dieses Dokument beschreibt das Verhalten des Empfangs und der Werbung für nicht gekennzeichnete und gekennzeichnete Pfade über eine BGP-Sitzung in Cisco IOS^® XR.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument bezieht sich nur auf Cisco IOS^® XR, ist jedoch nicht auf eine bestimmte Softwareversion oder Hardware beschränkt.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Einführung

Der Address Family Identifier (AFI) gibt die Art der BGP-Route an. Beispiele sind 1 für IPv4 und 2 für IPv6.

Die nachfolgende Adressenfamilien-Kennung (SAFI) ist ein weiterer Hinweis auf die Art der Route. Beispiel: 1 für eine nicht gekennzeichnete Route und 4 für eine bezeichnete Route.

Ungekennzeichnetes Unicast für IPv4 ist AFI 1 und SAFI 1.

Unicast mit der Bezeichnung "Unicast" für IPv4 ist AFI 1 und SAFI 4.

Ungekennzeichnetes Unicast für IPv6 ist AFI 2 und SAFI 1.

Unicast mit der Bezeichnung "Unicast" für IPv6 ist AFI 2 und SAFI 4.

Label Unicast (LU) wird häufig als RFC 3107 bezeichnet, "Carry Label Information in BGP-4".

Im Folgenden bezieht sich "U" auf Unicast, d. h. SAFI 1 und LU bezieht sich auf Unicast mit der Bezeichnung "Unicast", also SAFI 4.

Beachten Sie, dass Cisco IOS^® XR eine Routingrichtlinie ("assigned-label all| route-policy ...") benötigt, oder die Route wird nicht als SAFI 4 vom nächsten BGP-Sprecher generiert oder an diesen weitergeleitet.

IPv4/v6 Unicast und Label-Unicast in einer BGP-Sitzung wurden von Cisco IOS^® XR nicht unterstützt.

Bei Cisco IOS^® XR wurde in 6.2.1 die Unterstützung für eine BGP-Sitzung ohne Beschriftung und Beschriftung durchgeführt.

Wenn beide Sitzungen auf einer Sitzung nicht unterstützt werden, ist dies problematisch, da das letzte empfangene Update/Withdraw die vorherige Session überschreibt, auch wenn sie auf einer anderen SAFI empfangen wurden.

Wenn Sie SAFI 1 und 4 auf derselben BGP-Sitzung auf einem Router konfigurieren, auf dem IOS-XR-Code vor IOS-XR 6.2.1 ausgeführt wird, gibt der Router folgende Warnung aus:

bgp[1051]: %ROUTING-BGP-4-INCOMPATIBLE_AFI : IPv4 Unicast and IPv4 Labeled-unicast Address families together are not supported under the same neighbor.

Diese Warnmeldung wurde in IOS-XR 5.3.0 und IOS-XR 5.2.2 eingeführt.

Funktionsaustausch

Die zwischen BGP-Peers ausgetauschten Funktionen müssen übereinstimmen. Andernfalls wird die BGP-Sitzung nicht angezeigt.

Dies ist eine Wireshark-Erfassung der in der BGP Open-Nachricht für AFI 1/SAFI 1 und AFI 1/SAFI 4 ausgetauschten Funktionen:

Bild 1

Hier ein Beispiel für IOS-XR, der nur für eine IOS-Sitzung konfiguriert wurde, die nur mit U konfiguriert wurde.

IOS-XR:

RP/0/0/CPU0:R4#show bgp neighbor 10.100.1.8
 
BGP neighbor is 10.100.1.8
 Remote AS 65003, local AS 65003, internal link
 Remote router ID 0.0.0.0
  BGP state = Idle
…

  Connections established 0; dropped 0
  Local host: 10.100.1.4, Local port: 179, IF Handle: 0x00000000
  Foreign host: 10.100.1.8, Foreign port: 33396
  Last reset 00:00:14, due to BGP Notification sent: unsupported/disjoint capability
  Time since last notification sent to neighbor: 00:00:14
  Error Code: unsupported/disjoint capability
  Notification data sent:
    None

Der IOS-Router druckt eine Syslog-Meldung für diesen Konfigurationsfehler:

*Aug  8 12:40:44.719: %BGP-3-NOTIFICATION: received from neighbor 10.100.1.4 active 2/7 (unsupported/disjoint capability) 0 by

Details zur IOS-XR-Implementierung

Konfigurieren von U oder LU

Sie konfigurieren "address-family ipv4 unicast" unter dem BGP-Nachbarbefehl, um ipv4-Unicast für die BGP-Sitzung zu aktivieren.

Sie konfigurieren "address-family ipv6 unicast" unter dem BGP-Nachbarbefehl, um ipv6-Unicast für die BGP-Sitzung zu aktivieren.

Sie konfigurieren "address-family ipv4 label-unicast" unter dem Befehl "BGP neighbor", um als ipv4-Unicast gekennzeichnetes Unicast für die BGP-Sitzung zu aktivieren.

Sie konfigurieren "address-family ipv6 label-unicast" unter dem Befehl "BGP neighbor", um ipv6 als Unicast für die BGP-Sitzung zu aktivieren.

In IOS-XR wird die AFI/SAFI-Kombination pro BGP-Peer konfiguriert.

Dies ist ein Beispiel für eine BGP-Sitzung mit SAFI 1 und 4:

router bgp 65003
 address-family ipv4 unicast
  redistribute connected
  allocate-label all unlabeled-path
   …
  neighbor 10.100.1.7
   remote-as 65003
   update-source Loopback0
   address-family ipv4 unicast
    route-reflector-client
   !
   address-family ipv4 labeled-unicast
    route-reflector-client

Beachten Sie, dass unter Router BGP immer noch nur der "address family Unicast" und nicht "address-family Label-Unicast" vorhanden sind. In dieser BGP-Tabelle werden sowohl SAFI 1 als auch 4 Pfade gespeichert.

BGP-Tabelle

Unabhängig davon, ob IOS-XR älter oder jünger als 6.2.1 ist, gibt es nur eine BGP-Tabelle zum Speichern der U- und LU-Routen. Dies zeigt sich daran, dass Sie "address-family ipv4 unicast" oder "address-family ipv6 unicast" nur unter Router bgp konfigurieren (aktivieren) können. Sie können "address-family ipv4 label-unicast" oder "address-family ipv6 Label-unicast" nicht unter Router bgp konfigurieren.

Der U- und der LU-Pfad können identisch sein. Vor IOS-XR 6.2.1 würde der Empfang des gleichen Pfads, diesmal jedoch mit oder ohne Label, den zuvor empfangenen Pfad überschreiben. Nach IOS-XR 6.2.1 werden die beiden identischen Pfade als unterschiedlich angesehen, wenn sie sich nur durch das Label unterscheiden. Die Pfaderweiterungen, -löschungen oder -änderungen werden von den verschiedenen SAFIs durchgeführt.

Im Folgenden sehen Sie ein Beispiel für eine Route in der BGP-Tabelle mit AFI 1/SAFI 4. Da die Label-Zuweisung für alle Präfixe aktiviert ist, wird dieser Pfad mit einer lokalen Bezeichnung gespeichert. Da nur eine BGP-Tabelle U- und LU-Routen speichert, wird das Präfix mit den Befehlen "show bgp ipv4 unicast" und "show bgp ipv4 label-unicast" angezeigt.

RP/0/0/CPU0:R4#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  5           5
    Local Label: 24000
Last Modified: Aug  6 15:03:59.574 for 16:06:13
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.3 0.4
  Advertised to peers (in unique update groups):
    10.1.45.5
  Path #1: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.3 0.4
  Advertised to peers (in unique update groups):
    10.1.45.5
  65002 65001
    10.1.24.2 from 10.1.24.2 (10.100.1.2)
      Received Label 24003
      Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast
      Received Path ID 0, Local Path ID 0, version 5
      Origin-AS validity: not-found

Beachten Sie, dass der Pfad mit "label-unicast" gekennzeichnet ist.

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  5           5
    Local Label: 24000
Last Modified: Aug  6 15:03:59.574 for 16:08:41
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.3 0.4
  Advertised to peers (in unique update groups):
    10.1.45.5
  Path #1: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.3 0.4
  Advertised to peers (in unique update groups):
    10.1.45.5
  65002 65001
    10.1.24.2 from 10.1.24.2 (10.100.1.2)
      Received Label 24003
      Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast
      Received Path ID 0, Local Path ID 0, version 5
      Origin-AS validity: not-found

Beachten Sie, dass der Pfad mit "label-unicast" gekennzeichnet ist.

Wenn der Pfad sowohl als U als auch als LU vorhanden ist, ist die lokale Pfad-ID unterschiedlich.

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 30          30
    Local Label: 24003 (no rewrite);
    Flags: 0x00003028+0x00010000;
Last Modified: Aug 30 10:45:50.502 for 00:01:59
Paths: (2 available, best #1)
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.100.1.8      10.100.1.9
  Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
    0.8
  Path #1: Received by speaker 0
  Flags: 0x4000000009060205, import: 0x20
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.100.1.8      10.100.1.9
  Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
    0.8
  65001, (Received from a RR-client)
    10.100.1.9 (metric 2) from 10.100.1.9 (10.100.1.9)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 29
  Path #2: Received by speaker 0
  Flags: 0x4080000008020205, import: 0x20
  Not advertised to any peer
  65001, (Received from a RR-client)
    10.100.1.9 (metric 2) from 10.100.1.9 (10.100.1.9)
      Received Label 24001
      Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast
      Received Path ID 0, Local Path ID 0, version 0

Aktivieren der lokalen Label-Zuweisung

Sie müssen den Befehl "assigned-label" konfigurieren, damit die empfangenen oder Sourcing-Pfade im BGP über ein lokales MPLS-Label verfügen. Ohne diesen Befehl verfügen die Routen nicht über eine lokale Bezeichnung.

RP/0/0/CPU0:R4#conf t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label ?
  all           Allocate labels for all prefixes
  route-policy  Use a route policy to select prefixes for label allocation

Die Label-Zuweisung erfolgt für alle Routen oder gemäß der konfigurierten Routenrichtlinie.

Neue Implementierung in IOS-XR

In der alten Implementierung von IOS-XR wird eine Warnung ausgegeben, wenn sowohl die U als auch die LU für dieselbe BGP-Sitzung konfiguriert werden. Die Warnung wird in den Versionen 5.3.0 und 5.2.2 von IOS-XR eingeführt. Die Warnung wird in IOS-XR Version 6.2.1 entfernt, da die Beschriftung und die Beschriftung in derselben BGP-Sitzung unterstützt werden.

Beispiel:

RP/0/0/CPU0:ios#conf t
RP/0/0/CPU0:ios(config)#router bgp 65001
RP/0/0/CPU0:ios(config-bgp)#add ipv4 unicast
RP/0/0/CPU0:ios(config-bgp-af)#exit
RP/0/0/CPU0:ios(config-bgp)#neighbor 10.0.0.1
RP/0/0/CPU0:ios(config-bgp-nbr)#remote-as 65001
RP/0/0/CPU0:ios(config-bgp-nbr)#exit
RP/0/0/CPU0:ios(config-bgp)#neighbor 10.0.0.1
RP/0/0/CPU0:ios(config-bgp-nbr)#address-family ipv4 unicast
RP/0/0/CPU0:ios(config-bgp-nbr-af)#exit
RP/0/0/CPU0:ios(config-bgp-nbr)#address-family ipv4 labeled-unicast
RP/0/0/CPU0:ios(config-bgp-nbr-af)#commit

RP/0/0/CPU0:Aug 21 14:14:22.222 : bgp[1052]: %ROUTING-BGP-4-INCOMPATIBLE_AFI : IPv4 Unicast and IPv4 Labeled-unicast Address families together are not supported under the same neighbor. 

Die Erklärung für diese Fehlermeldung:

Diese Meldung weist darauf hin, dass der Benutzer sowohl die IPv4-Unicast- als auch die IPv4-Adressfamilien "Labeled-Unicast" oder "IPv6 Unicast" und "IPv6 Label-Unicast" unter demselben Nachbarn konfiguriert hat. Diese Konfiguration wird nicht unterstützt. 

Empfohlene Aktion: Konfigurieren Sie zwei benachbarte Sitzungen für den Router. Konfigurieren Sie die Unicast-Adressfamilie unter der ersten Nachbarsitzung, und konfigurieren Sie die als Unicast-Adressfamilie bezeichnete Adressfamilie unter der zweiten Nachbarsitzung.

Konfigurationsbeispiel für zwei BGP-Sitzungen zwischen zwei IOS-XR-Routern. Verwenden Sie für jede BGP-Sitzung eine andere (Loopback-) Adresse.

hostname R1

interface Loopback0
 ipv4 address 10.100.1.1 255.255.255.255
!
interface Loopback1
 ipv4 address 10.100.1.101 255.255.255.255
!
router bgp 65001
 address-family ipv4 unicast
 !
 neighbor 10.100.1.2
  remote-as 65001
 update-source Loopback0
  address-family ipv4 unicast
  !
 !
 neighbor 10.100.1.102
  remote-as 65001
  update-source Loopback1
  address-family ipv4 labeled-unicast
  !
 ! 
   
hostname R2

interface Loopback0
 ipv4 address 10.100.1.2 255.255.255.255
!
interface Loopback1
 ipv4 address 10.100.1.102 255.255.255.255
!
router bgp 65001
 address-family ipv4 unicast
 !
neighbor 10.100.1.1
  remote-as 65001
 update-source Loopback0
  address-family ipv4 unicast
  !
 !
 neighbor 10.100.1.101
  remote-as 65001
  update-source Loopback1
  address-family ipv4 labeled-unicast
  !
 !

In IOS-XR 6.2.1 werden sowohl U als auch LU in derselben BGP-Sitzung auf dem Standard-VRF unterstützt!

Dabei spielt es keine Rolle, ob es sich bei der BGP-Sitzung um ein internes oder ein externes BGP handelt.

U und LU in derselben Sitzung werden für BGP-Lautsprecher in einer nicht standardmäßigen VRF-Instanz nicht unterstützt.

Aktualisierungsgruppen

Vor IOS-XR 6.2.1 wurden alle BGP-Lautsprecher von U, LU und U + LU in separaten Aktualisierungsgruppen gespeichert. Nach IOS-XR Version 6.2.1 ist dies nicht mehr der Fall. Einige BGP-Lautsprecher in einer Aktualisierungsgruppe können nur U oder LU oder sowohl U als auch LU sein.

Weiterleitung

Die folgende Tabelle zeigt das Werbe- und Rücknahmeverhalten für verschiedene Szenarien. Es gibt 16 Szenarien.

Alle gelten für IOS-XR 6.2.1 und höher, sofern in der Kommentarspalte nichts anderes angegeben ist.

Fall	Bestpath/Adpath-Typ	Lokales Label vorhanden?	NHS oder NHU	SAFI der Aktualisierungsgruppe	Werbung machen oder zurückziehen?	Kommentare
1	Unbezeichneter Pfad, d. h. kein rx-Label	Ja	NHS	SAFI-1	Standardmäßige Werbung Injizieren Sie Befehl zur Deaktivierung der lokal gekennzeichneten Route (safi-Unicast) ankündigen	Nur nach 6.5.1 möglich.
2				SAFI-4	Werbung	Nur nach 6.5.1 möglich. IPv4/v6-Wahlwiederholungsrouten und 6PE: implizite NHS
1			NHU	SAFI-1	Werbung	Nur nach 6.5.1 möglich.
4				SAFI-4	Zurückziehen	Nur nach 6.5.1 möglich. IPv4/v6-Wahlwiederholungsrouten und 6PE: NHU ignoriert; implizite NHS
5		Nein	NHS	SAFI-1	Werbung
6				SAFI-4	Zurückziehen
7			NHU	SAFI-1	Werbung
8				SAFI-4	Zurückziehen
9	Bezeichneter Pfad, d. h. mit rx-Label	Ja	NHS	SAFI-1	Standardmäßige Werbung Deaktivieren des Befehls für die lokale bezeichnete Route (Safi-Unicast) zurückziehen	Vor 6.2.1: Standardverhalten ist Werbung.
10				SAFI-4	Werbung
11			NHU	SAFI-1	Zurückziehen	Vor 6.2.1:  Verhalten ist Werbung.
12				SAFI-4	Werbung
13		Nein	NHS	SAFI-1	Werbung
14				SAFI-4	Zurückziehen
15			NHU	SAFI-1	Zurückziehen	Vor 6.2.1:  Verhalten ist Werbung.
16				SAFI-4	Werbung

Tabelle 1 Anzeigeverhalten für iBGP- und eBGP-Sitzungen

NHS = Next Hop Self

NHU = Next Hop Unchanged.

Wenn NHU in Kraft ist, bedeutet dies, dass das Next-Hop-Self nicht für eine iBGP-Sitzung konfiguriert ist.

Beachten Sie, dass NHS immer dann der Fall ist, wenn der BGP-Sprecher einen eBGP-Peer sendet.

Abhängig von der Konfiguration des Next-Hop-Self-Service kann es für einen iBGP-Sprecher NHS oder NHU geben. Das Standardverhalten gegenüber iBGP-Peers ist NHU.

Zweite Spalte: Beachten Sie, dass der Pfad nur dann als nicht gekennzeichnet oder gekennzeichnet gilt, wenn der beste Pfad oder einer der mit dem Add-Pfad markierten Pfade nicht gekennzeichnet oder gekennzeichnet ist.

Für die Routenpropagierung ist es wichtig, welche Eigenschaften der beste Pfad hat. Abhängig von den Merkmalen (Spalten 2 bis 4) bestimmt es, ob der Pfad als U, LU oder beides angegeben wird.

Wenn die Funktion Zusätzliche Pfade (ADD-PATH) aktiviert ist und ein Pfad mit "Add-Path" gekennzeichnet ist, spielen die Eigenschaften dieses Pfades auch eine Rolle, wie dieser Pfad angekündigt wird.

"Lokales Label vorhanden?: Nein" bedeutet Folgendes: Es ist möglich, dass ein Label mit dem empfangenen Update empfangen wird, das Label jedoch nicht installiert ist. Die lokale Bezeichnung wird nicht installiert, wenn der Befehl "assigned-label" nicht vorhanden ist.

Sie können überprüfen, ob das lokale Label vorhanden ist, indem Sie das Präfix im Detail betrachten. Verwenden Sie "show bgp <prefix> detail" oder "show route <prefix> detail".

Im folgenden Beispiel wird das Präfix ohne Label empfangen (also über ein SAFI 1-Peering), und es wird kein lokales Label zugewiesen:

RP/0/0/CPU0:R2#show bgp ipv4 labeled-unicast 10.100.1.5/32 detail
BGP routing table entry for 10.100.1.5/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  3           3
    Flags: 0x04001001+0x00000000;
Last Modified: Sep  5 03:44:45.647 for 01:01:27
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.3
  Path #1: Received by speaker 0
  Flags: 0x4000000001040207, import: 0x00
  Advertised to update-groups (with more than one peer):
    0.3
  Local, (Received from a RR-client)
    10.100.1.1 (metric 2) from 10.100.1.1 (10.100.1.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 3

RP/0/0/CPU0:R2#show route 10.100.1.5/32 detail

Routing entry for 10.100.1.5/32
  Known via "bgp 65001", distance 200, metric 0, type internal
  Installed Sep  5 03:44:45.480 for 01:01:37
  Routing Descriptor Blocks
    10.100.1.1, from 10.100.1.1
      Route metric is 0
      Label: None
      Tunnel ID: None
      Extended communities count: 0
      NHID:0x0(Ref:0)
  Route version is 0x23 (35)
  No local label
  IP Precedence: Not Set
  QoS Group ID: Not Set
  Flow-tag: Not Set
  Route Priority: RIB_PRIORITY_RECURSIVE (12) SVD Type RIB_SVD_TYPE_LOCAL
  Download Priority 4, Download Version 52
  No advertising protos.

Zuweisen einer lokalen Bezeichnung

Label für nicht gekennzeichnete Pfade zuweisen

Standardmäßig werden nicht gekennzeichnete Pfade (SAFI 1) nie gekennzeichnet, auch wenn der Befehl "assigned-label" konfiguriert ist.

Ab IOS-XR Version 6.5.1 gibt es das Schlüsselwort "unlabeled-path" für den Befehl "assigned-label", sodass auch den nicht gekennzeichneten Pfaden ein Label zugewiesen werden kann.

RP/0/0/CPU0:R4#conf t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all ?
  unlabeled-path  Allocate label for unlabeled paths too
  <cr>
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all unlabeled-path ?
  <cr>
RP/0/0/CPU0:R4(config-bgp-af)#allocate-label all unlabeled-path
RP/0/0/CPU0:R4(config-bgp-af)#commit

Der Pfad ist ein SAFI 1-Pfad, daher gibt es kein empfangenes Label.

Aufgrund des Befehls "unlabel-path" gibt es nun eine lokale Bezeichnung.

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 16          16
    Local Label: 24003 (no rewrite);
    Flags: 0x01303028+0x00000000;
Last Modified: Aug 27 19:08:47.502 for 00:00:59
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3
  Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
    0.7
  Advertised IPv4 Labeled-unicast paths to peers (in unique update groups):
    10.1.45.5
  Path #1: Received by speaker 0
  Flags: 0x4000000009040207, import: 0x20
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3
  Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
    0.7
  Advertised IPv4 Labeled-unicast paths to peers (in unique update groups):
    10.1.45.5
  65001, (Received from a RR-client)
    10.100.1.10 (metric 2) from 10.100.1.10 (10.100.1.10)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 16

RP/0/0/CPU0:R4#show route 10.100.1.1/32 detail

Routing entry for 10.100.1.1/32
  Known via "bgp 65003", distance 200, metric 0
  …
  Route version is 0x4 (4)
  Local Label: 0x5dc3 (24003)
  IP Precedence: Not Set
  …

Dies ermöglicht die Fälle 1 bis 4 in Tabelle 1.

Um herauszufinden, warum eine lokale Bezeichnung immer noch zugewiesen wird, wenn der Befehl "assigned-label" entfernt wird, führen Sie den Debugger "debug bgp label" aus.

Hier ein Beispiel:

RP/0/0/CPU0:R4#debug bgp label

RP/0/0/CPU0:R4#show debug

####  debug flags set from tty 'con0_0_CPU0'  ####
ip-bgp default label flag is ON with value '##########'

Es ist besser, dieses Debuggen für ein bestimmtes Präfix oder eine Gruppe von Präfixen zu aktivieren. Hier ein Beispiel:

RP/0/0/CPU0:R4#sh running-config route-policy match-prefix
route-policy match-prefix
  if destination in (10.100.1.1/32) then
    pass
  else
    drop
  endif
end-policy
!

RP/0/0/CPU0:R4#debug bgp label route-policy match-prefix 

RP/0/0/CPU0:R4#show debug

####  debug flags set from tty 'con0_0_CPU0'  ####

ip-bgp default label flag is ON with value '######match-prefix####'

RP/0/0/CPU0:R4#con t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-af)#no   allocate-label all
RP/0/0/CPU0:R4(config-bgp-af)#commit

RP/0/0/CPU0:Aug 23 12:43:02.786 : bgp[1048]: [default-lbl] (ip4u): Label computation done: table=TBL:default (1/1), net=10.100.1.1/32: netfl=0x05043001, path=0x1073ed5c(10.1.24.2/32,10.1.24.2,0,0x400000000d060001), pathrcvdlabel=24002: asbr=1, rr=0/1, nhselfcount=1: result="label required"

Wie Sie sehen, hat dieser Router ein Label für das Präfix 10.100.1.1/32 erhalten, es handelt sich um einen ASBR, kein RR und hat Next-Hop-Self für mindestens eine BGP-Sitzung. Dies führt dazu, dass dieses Präfix ein lokales Label benötigt.

Das lokale Label bleibt erhalten:

RP/0/0/CPU0:R4#show bgp ipv4 unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 13          13
    Local Label: 16002 (no rewrite);
    Flags: 0x05043001+0x00000200;
Last Modified: Aug 23 12:37:11.133 for 00:05:53
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.6
  Advertised to peers (in unique update groups):
    10.1.46.6       10.100.1.8      10.100.1.7
  Path #1: Received by speaker 0
  Flags: 0x400000000d060001, import: 0x1f
  Advertised to update-groups (with more than one peer):
    0.6
  Advertised to peers (in unique update groups):
    10.1.46.6       10.100.1.8      10.100.1.7
  65002 65001
    10.1.24.2 from 10.1.24.2 (10.100.1.2)
      Received Label 24002
      Origin IGP, localpref 100, valid, external, best, group-best, import-candidate
      Received Path ID 0, Local Path ID 1, version 13
      Origin-AS validity: not-found


RP/0/0/CPU0:R4#show route 10.100.1.1/32 detail 
Routing entry for 10.100.1.1/32
  Known via "bgp 65003", distance 20, metric 0, [ei]-bgp, labeled unicast (3107)
  Tag 65002, type external
  Installed Aug 23 12:37:11.440 for 00:06:02
  Routing Descriptor Blocks
    10.1.24.2, from 10.1.24.2, BGP external
      Route metric is 0
      Label: 0x5dc2 (24002)
      Tunnel ID: None
      Extended communities count: 0
      NHID:0x0(Ref:0)
  Route version is 0x4 (4)
  Local Label: 0x3e82 (16002)
  IP Precedence: Not Set
  QoS Group ID: Not Set
  Route Priority: RIB_PRIORITY_NON_RECURSIVE_LOW (11) SVD Type RIB_SVD_TYPE_LOCAL
 Download Priority 4, Download Version 28
  No advertising protos.

Wenn keine lokale Bezeichnung erforderlich ist, wird die folgende Meldung angezeigt:

RP/0/0/CPU0:Aug 23 13:01:15.801 : bgp[1048]: [default-lbl]: Prefix 10.100.1.1/32:()doesn't require label, releasing

RP/0/0/CPU0:Aug 23 13:01:15.801 : bgp[1048]: [default-lbl]: bgp_label_release_label: perform label release onnet 10.100.1.1/32net retain 0 label_retain 0

Wenn sich das Präfix im LFIB befindet, hängt davon ab, ob das Präfix mit oder ohne Label empfangen wurde und ob das Label zugewiesen wurde.

Das empfangene Label ist 24002 für das folgende Präfix.  Sie wird nicht im LFIB installiert, da BGP nicht über den Befehl "assigned-label" verfügt.

RP/0/0/CPU0:R4#show bgp ipv4 unicast  10.100.1.1/32
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  4           4
    Local Label: 24002
Last Modified: Aug  8 13:52:57.276 for 00:00:36
Paths: (1 available, best #1)
  Advertised to update-groups (with more than one peer):
    0.6
  Advertised to peers (in unique update groups):
    10.100.1.7
  Path #1: Received by speaker 0
  Advertised to update-groups (with more than one peer):
    0.6
  Advertised to peers (in unique update groups):
    10.100.1.7
  65002 65001
    10.1.24.2 from 10.1.24.2 (10.100.1.2)
      Received Label 24002
      Origin IGP, localpref 100, valid, external, best, group-best, labeled-unicast
      Received Path ID 0, Local Path ID 0, version 4
      Origin-AS validity: not-found

router bgp 65003
 bgp unsafe-ebgp-policy
 address-family ipv4 unicast
 !

RP/0/0/CPU0:R4# show mpls forwarding
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Aggregate   10.1.24.0/24       default                      0
24001  Aggregate   10.1.45.0/24       default                      0

Wenn der Befehl assigned-label vorhanden ist, wird die lokale Bezeichnung im LFIB angezeigt:

router bgp 65003
 bgp unsafe-ebgp-policy
 address-family ipv4 unicast
  allocate-label all
 !

RP/0/0/CPU0:R4#show mpls forwarding
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Aggregate   10.1.24.0/24       default                      0
24001  Aggregate   10.1.45.0/24       default                      0
24002  24002       10.100.1.1/32                   10.1.24.2       0

Selbst wenn das BGP-Präfix über eine LU-Sitzung empfangen wird, aber kein lokales Label zugewiesen ist, wird die Route nicht über eine andere LU-Sitzung angekündigt, wenn der NHS erfolgt. Dies ist in Tabelle 1 der Fall 14. Dies ist der Fall, wenn die ausgehende BGP-Sitzung eBGP ist.

Beispiel:

RP/0/0/CPU0:R2#show bgp ipv4 unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                  3           3
    Flags: 0x00001001+0x00000000;
Last Modified: Aug 22 09:00:20.646 for 00:10:56
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Flags: 0x4080000001060001, import: 0x20
  Not advertised to any peer
  65001
    10.1.12.1 from 10.1.12.1 (10.100.1.1)
      Received Label 3
      Origin IGP, metric 0, localpref 100, valid, external, best, group-best, labeled-unicast
      Received Path ID 0, Local Path ID 0, version 3
      Origin-AS validity: not-found

RP/0/0/CPU0:R2#show route 10.100.1.1/32 detail

Routing entry for 10.100.1.1/32
  Known via "bgp 65002", distance 20, metric 0, labeled unicast (3107)
  Tag 65001, type external
  Installed Aug 22 09:00:20.416 for 00:10:59
  Routing Descriptor Blocks
    10.1.12.1, from 10.1.12.1, BGP external
      Route metric is 0
      Label: 0x100004 (1048580)
      Tunnel ID: None
      Binding Label: None
      Extended communities count: 0
      NHID:0x0(Ref:0)
  Route version is 0x1 (1)
  No local label
  IP Precedence: Not Set
  …

Dies ist wahrscheinlich darauf zurückzuführen, dass der Befehl "assigned-label" für Unicast der Adressfamilie unter Router-BGP nicht vorhanden ist.

Beim Entfernen des Befehls "assigned-label" muss der Prozess BGP neu gestartet werden, damit der Router die lokalen Labels für die BGP-Routen entfernt.

Der neue Befehl für die lokale bezeichnete Route in Tabelle 1 gibt an, dass eine Route mit lokalem Label nicht als nicht gekennzeichnete Route über SAFI-1 angekündigt werden darf.

Dieser Befehl ist der folgende:

   Ankündigung von lokal markierter Route [deaktivieren]

Dieser Befehl wird unter der Adressfamilie des Nachbarn konfiguriert. Dieser Befehl gibt an, ob eine IPv4/v6-Route mit lokalem Label dem BGP-Nachbarn über IPv4/v6-Unicast (SAFI 1) angekündigt werden soll.

Das Standardverhalten besteht darin, Routen mit einer lokalen Bezeichnung anzukündigen.

Der neue Befehl kann auch wie folgt konfiguriert werden:

   Ankündigung von lokal gekennzeichneten Routen-Safi-Unicast [deaktivieren]

Dieser Befehl wird im Abschnitt "BGP" unter der Gruppe "af" konfiguriert. Seine Funktion ist identisch mit der oben beschriebenen und gilt für alle BGP-Nachbarn.

Das Standardverhalten besteht darin, Routen mit einer lokalen Bezeichnung anzukündigen.

Die Zeile "Advertise routen with local-label via Unicast SAFI" oder "Do not notify routen with local-label via Unicast SAFI" ist im Befehl" show bgp neighbor" unter der Adressfamilie IPv4 Unicast vorhanden, um anzugeben, dass der BGP-Sprecher die Anzeige von Routen mit lokalem Label oder nicht gestattet.

Beispiel für das Standardverhalten:

RP/0/0/CPU0:R4#show bgp neighbor 10.1.45.5
…
For Address Family: IPv4 Unicast
  BGP neighbor version 5
  Update group: 0.1 Filter-group: 0.5  No Refresh request being processed
    Extended Nexthop Encoding: advertised and received
  Route refresh request: received 0, sent 0
  0 accepted prefixes, 0 are bestpaths
  Exact no. of prefixes denied : 0.
  Cumulative no. of prefixes denied: 0.
  Prefix advertised 2, suppressed 0, withdrawn 0
  Maximum prefixes allowed 1048576
  Threshold for warning message 75%, restart interval 0 min
  An EoR was not received during read-only mode
  Last ack version 5, Last synced ack version 0
  Outstanding version objects: current 0, max 1, refresh 0
  Additional-paths operation: None
  Advertise routes with local-label via Unicast SAFI
…

oder

RP/0/0/CPU0:R4# conf t
RP/0/0/CPU0:R4(config)#router bgp 65003
RP/0/0/CPU0:R4(config-bgp)# neighbor 10.1.45.5
RP/0/0/CPU0:R4(config-bgp-nbr)#  address-family ipv4 unicast
RP/0/0/CPU0:R4(config-bgp-nbr-af)#advertise local-labeled-route disable
RP/0/0/CPU0:R4(config-bgp-nbr-af)#commit


RP/0/0/CPU0:R4#show bgp neighbor 10.1.45.5

BGP neighbor is 10.1.45.5
…
For Address Family: IPv4 Unicast
  BGP neighbor version 5
  Update group: 0.1 Filter-group: 0.5 (Update-group Change
pending)
  No Refresh request being processed
    Extended Nexthop Encoding: advertised and received
  Route refresh request: received 0, sent 0
  0 accepted prefixes, 0 are bestpaths
  Exact no. of prefixes denied : 0.
  Cumulative no. of prefixes denied: 0.
  Prefix advertised 2, suppressed 0, withdrawn 0
  Maximum prefixes allowed 1048576
  Threshold for warning message 75%, restart interval 0 min
  An EoR was not received during read-only mode
  Last ack version 5, Last synced ack version 0
  Outstanding version objects: current 0, max 1, refresh 0
  Additional-paths operation: None
  Do not advertise routes with local-label via Unicast SAFI

Bestpath-Berechnung

Der Prozess für die Berechnung des besten Pfads ändert sich nicht. Wenn es sich bei einem Pfad um SAFI 1 oder SAFI 4 handelt oder wenn der Pfad ein Label hat oder nicht, macht dies im besten Pfadberechnungsprozess keinen Unterschied. Daher besteht keine Präferenz zwischen einem SAFI 1- oder SAFI 4-Pfad. Dies gilt unabhängig davon, ob SAFI 1/SAFI 4 in derselben BGP-Sitzung oder in verschiedenen Sitzungen vorhanden ist. Wenn also eine BGP-Sitzung SAFI 1 und 4 ist und ein Präfix über beide Adressfamilien empfangen wird, wird für die Berechnung des besten Pfads der beste Pfad ausgewählt, da alle Attribute gleich sind. Wenn alle BGP-Attribute zwischen dem U- und dem LU-Pfad identisch sind, wird der zuletzt erhaltene Pfad zum besten Pfad.

Wenn die Pfade SAFI 1 und SAFI 4 von unterschiedlichen BGP-Peers empfangen werden, gibt es immer einen Unterschied in den Pfaden, die zum BGP führen und immer denselben besten Pfad aus den beiden Pfaden auswählen. Auch wenn in diesem Fall alle Attribute gleich sind, ist die Nachbaradresse unterschiedlich. Betrachtet man den BGP Best Path Selection Algorithm, wird der Pfad vom Nachbarn mit der Adresse des untersten Nachbarn (letzter Schritt 13) als bestmöglicher Pfad ausgewählt.

Verwenden Sie den Befehl "show bgp <AFI> <SAFI> <präfix> bestpath-vergleichen", um zu überprüfen, warum der beste Pfad am besten ist.

Diese Präferenz kann vom Benutzer mithilfe von RPL vorgenommen werden.

Hier ein Beispiel für eine solche RPL.

RP/0/0/CPU0:R7#show bgp ipv4 un 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                682         682
    Flags: 0x00003001+0x00010000;
Last Modified: Aug 28 13:16:26.826 for 00:00:10
Paths: (2 available, best #2)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Flags: 0x4000000000020005, import: 0x20
  Not advertised to any peer
  65001
    10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
      Origin IGP, metric 0, localpref 100, valid, internal
      Received Path ID 1, Local Path ID 0, version 0
      Originator: 10.100.1.10, Cluster list: 10.100.1.4
  Path #2: Received by speaker 0
  Flags: 0x4080000001060005, import: 0x20
  Not advertised to any peer
  65001
    10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
      Received Label 24003
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast
      Received Path ID 1, Local Path ID 0, version 682
      Originator: 10.100.1.10, Cluster list: 10.100.1.4

Der LU-Pfad ist der beste.

RPL mit Gewicht wird verwendet, um den U-Pfad vorzuziehen.

route-policy weight
  if destination in (10.100.1.1/32) then
    set weight 60000
  endif
end-policy

router bgp 65003
 address-family ipv4 unicast
  additional-paths receive
  additional-paths send
 !
 neighbor 10.100.1.4
  remote-as 65003
  update-source Loopback0
  address-family ipv4 unicast
   route-policy weight in
  !
  address-family ipv4 labeled-unicast
  !
 !

RP/0/0/CPU0:R7#show bgp ipv4 un 10.100.1.1/32 bestpath-compare
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                726         726
Last Modified: Aug 28 13:39:27.826 for 00:04:54
Paths: (2 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65001
    10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
      Origin IGP, metric 0, localpref 100, weight 60000, valid, internal, best, group-best
      Received Path ID 1, Local Path ID 0, version 726
      Originator: 10.100.1.10, Cluster list: 10.100.1.4
      best of AS 65001, Overall best
  Path #2: Received by speaker 0
  Not advertised to any peer
  65001
    10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
      Received Label 24003
      Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast
      Received Path ID 1, Local Path ID 0, version 0
      Originator: 10.100.1.10, Cluster list: 10.100.1.4
      Lower weight than best path (path #1)

Der U-Pfad ist jetzt der beste.

Es gibt keinen neuen Befehl, gekennzeichnete Pfade den nicht gekennzeichneten Pfaden vorzuziehen. Sie können die RPL entweder unter "address-family unicast" oder "Label-Unicast" unter einem BGP-Nachbarn konfigurieren.

Überprüfen des Verhaltens im BGP

Um die BGP-Update-Propagation in IOS-XR zu debuggen, können Sie den folgenden Debugbefehl aktivieren: debug bgp update <BGP neighbor> in | out.

Dadurch wird das eingehende oder ausgehende BGP-Update von bzw. zu diesem BGP-Sprecher angezeigt. Die Adressfamilie wird als (ip4u) für nicht gekennzeichneten IPv4-Unicast (AFI 1/SAFI 1) oder als (ipv4lu) für mit IPv4 gekennzeichnetes Unicast (AFI 1/SAFI 4) angezeigt. Entsprechendes gilt für IPv6.

Es gibt ein neues Feld mit der Bezeichnung "Unicast", das anzeigt, dass der Pfad über SAFI 4 gelernt wird.

Beispiel:

RP/0/0/CPU0:R1#show bgp ipv4 unicast 10.100.1.7/32
BGP routing table entry for 10.100.1.7/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 26          26
Last Modified: Sep  4 10:45:44.551 for 00:29:11
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    10.100.1.4 (metric 3) from 10.100.1.102 (10.100.1.4)
      Received Label 24000
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast
      Received Path ID 0, Local Path ID 1, version 26
      Originator: 10.100.1.4, Cluster list: 10.100.1.2

Um zu überprüfen, ob das Präfix angekündigt wird, können Sie den Befehl "show bgp ... neighbors" mit dem Schlüsselwort"insersed-routen" am Ende verwenden.

Beispiel:

R4 kündigt dem Nachbar 10.100.1.7 zweimal 10.100.1.1/32 an, da Add-Path aktiviert ist (die beiden Pfade sind unterschiedlich).

RP/0/0/CPU0:R4#show bgp ipv4 labeled-unicast neighbors 10.100.1.7 advertised-routes
Network            Next Hop        From            AS Path
10.1.24.0/24       10.100.1.4      Local           ?
10.1.34.0/24       10.100.1.4      Local           ?
10.1.45.0/24       10.100.1.4      Local           ?
10.1.46.0/24       10.100.1.4      Local           ?
10.1.47.0/24       10.100.1.4      Local           ?
10.1.48.0/24       10.100.1.4      Local           ?
10.1.49.0/24       10.100.1.4      Local           ?
10.1.104.0/24      10.100.1.4      Local           ?
10.1.114.0/24      10.100.1.4      Local           ?
10.100.1.1/32      10.100.1.4      10.100.1.9      65001i
                                   10.100.1.10     65001i
10.100.1.4/32      10.100.1.4      Local           ?

Processed 11 prefixes, 12 paths

iBGP und Next-Hop-Self - Unified MPLS

Es gelten die Regeln aus Tabelle 1. Mit Unified MPLS oder Nahtlosem MPLS fungiert ein Area Border Router (ABR) als Routen-Reflektor, ist aber auch der nächste Hop für die iBGP-Routen. Die ABRs befinden sich im Weiterleitungspfad des bezeichneten Datenverkehrs. Die ABRs müssen über die explizite Konfiguration für Next-Hop-Self verfügen.

Workarounds

• Wenn U und LU über eine BGP-Sitzung nicht unterstützt werden, sind zwei BGP-Sitzungen zwischen zwei Routern möglich. Auf jedem Router müssen zwei (Loopback-)Schnittstellen verwendet werden.

Beispielkonfiguration für IOS-XR.

interface Loopback0
 ipv4 address 10.100.1.7 255.255.255.255
!
interface Loopback1
 ipv4 address 10.100.1.107 255.255.255.255
!
router bgp 65003
 address-family ipv4 unicast
!
 neighbor 10.100.1.4   -> towards loopback0 on peer
  remote-as 65003
  update-source Loopback0
  address-family ipv4 unicast
  !
 !
 neighbor 10.100.1.104  -> towards loopback1 on peer
  remote-as 65003
  update-source Loopback1
  address-family ipv4 labeled-unicast
  !

Die U- und LU-Pfade werden über zwei verschiedene BGP-Sitzungen gesendet/empfangen.

RP/0/0/CPU0:R7#show bgp ipv4 unicast 10.100.1.1/32 detail
BGP routing table entry for 10.100.1.1/32
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                753         753
    Flags: 0x00001001+0x00010000;
Last Modified: Aug 28 14:06:40.826 for 00:22:10
Paths: (2 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Flags: 0x4000000001060005, import: 0x20
  Not advertised to any peer
  65001
    10.100.1.4 (metric 2) from 10.100.1.4 (10.100.1.10)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 1, Local Path ID 0, version 753
      Originator: 10.100.1.10, Cluster list: 10.100.1.4
  Path #2: Received by speaker 0
  Flags: 0x4080000000020005, import: 0x20
  Not advertised to any peer
  65001
    10.100.1.104 (metric 2) from 10.100.1.104 (10.100.1.10)
      Received Label 24003
      Origin IGP, metric 0, localpref 100, valid, internal, labeled-unicast
      Received Path ID 1, Local Path ID 0, version 0
      Originator: 10.100.1.10, Cluster list: 10.100.1.4