Inhalt

Voraussetzungen

Anforderungen

Verwendete Komponenten

Einführung

Funktionsaustausch

Details zur IOS-XR-Implementierung

Konfigurieren von U oder LU

BGP-Tabelle

Aktivieren der lokalen Label-Zuweisung

Neue Implementierung in IOS-XR

Aktualisierungsgruppen

Weiterleitung

Zuweisen einer lokalen Bezeichnung

Label für nicht gekennzeichnete Pfade zuweisen

Bestpath-Berechnung

Überprüfen des Verhaltens im BGP

iBGP und Next-Hop-Self - Unified MPLS

Workarounds

Beispielkonfiguration für 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