Inhalt

Einleitung

Voraussetzungen

Verwendete Komponenten

Hintergrundinformationen

Lösung

Next-Hop für BGP-Route nicht erreichbar

Konfiguration

BGP ODN AS NextHop Soft Validation Knob

BGP ODN AS Next-Hop Hard Validation Knob

BGP-Auswahl für besten Pfad unter Berücksichtigung der SR-Richtlinienpfadmetrik

BGP Best Path Selection Preferred SR-Richtlinienpfade

BGP Best Path Selection Forcing SR-Richtlinienpfade

Überblick

Standardverhalten

RIB-abhängige Validierung mit SR Policy Metric

SR Policy Dependent Validation with RIB Metric

SR Policy Dependent Validation mit SR Policy Metric

SR Policy Dependent Validation with RIB Metric and SR Policy not Used for Best Path Calberechnung

SR Policy Dependent Validation with RIB Metric and SR Policy für die Berechnung des besten Pfads

Überprüfung

Überprüfen, ob eine Richtlinie aktiviert oder deaktiviert ist

Überprüfen der Verwendung der Richtlinie

BGP Nexthops-Befehl anzeigen

BGP-Trace

Administrative Distanz und Metrik

Admin-Werte

Überprüfung des Administrations- und Metriktyps im ODN

Effektive Kennzahl

Vergleich von BGP-Pfaden

BGP-Pfad mit und ohne Farbe

Szenarien im Detail mit Befehlen anzeigen

Standardverhalten

RIB-abhängige Validierung mit SR Policy Metric

SR Policy Dependent Validation with RIB Metric

SR Policy Dependent Validation mit SR Policy Metric

SR Policy Dependent Validation with RIB Metric and SR Policy Not Used for Best Path-Berechnung

SR Policy Dependent Validation with RIB Metric and SR Policy für die Berechnung des besten Pfads

Einleitung

Dieses Dokument beschreibt das Verhalten der Next-Hop-Behandlung durch Border Gateway Protocol (BGP) in Cisco IOS® XR. Für das BGP muss der Next-Hop (NH)-Pfad erreichbar sein, bevor der Pfad in der Routing Information Base (RIB) installiert wird. Diese Regel gilt für alle BGP-Lautsprecher. Dies ist die Next-Hop-Validierungsprüfung. Die BGP Soft Next-Hop-Funktion stellt sicher, dass der BGP Next-Hop in der RIB nicht mehr erreichbar sein muss.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument bezieht sich speziell auf Cisco IOS XR.

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 Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

In einem einzigen AS-Netzwerk (Autonomous System), Multi-Domain-Netzwerk oder Inter-AS-Szenario kann der NH nicht erreichbar sein, wenn er nicht zwischen den Domänen oder autonomen Systemen umverteilt wird.

Das Problem beschränkt sich nicht nur auf PE-Router (Headend Provider Edge), sondern auch auf die BGP-Zwischenlautsprecher (z. B. Route Reflector (RR) und Autonomous System Border Router (ASBR)) zwischen Ausgangs- und Eingangs-PEs. Ein Zwischen-BGP-Sprecher muss für NH erreichbar sein, bevor er eine Route installiert und propagiert.

On-Demand Next-Hop (ODN) ist eine SR-Anwendung (Segment Routing), die SR-Richtlinien auf dem Router installiert. Die mit diesen SR-Richtlinien verbundenen Service-Routen können BGP-Routen sein. Diese BGP-Routen können nur dann in der RIB- und der CEF-Tabelle (Cisco Express Forwarding) installiert werden, wenn der Next-Hop gültig ist. Es gibt Designs wie nahtloses MPLS oder Inter-AS MPLS Virtual Private Network (VPN), bei denen die Erreichbarkeit zum BGP Next-Hop in einem anderen Teil des Netzwerks, z. B. einem anderen Bereich oder einer anderen Domäne, durch eine Route in der RIB nicht garantiert wird. Dies ist kein Problem, wenn die Erreichbarkeit durch einen Controller oder ein SR Path Computation Element (SR-PCE) gewährleistet ist, das die Erreichbarkeit der Netzwerkelemente im gesamten Netzwerk ermöglicht.

Derzeit kann die BGP-Service-Route die SR-Richtlinie nur verwenden, wenn sich der Next-Hop der BGP-Route in der RIB als nicht standardmäßige Route befindet.

Wenn der BGP-Sprecher mit der SR-Richtlinie über keine Route (außer der Standardroute) in der RIB für den BGP Next-Hop verfügt, kann eine Lösung verwendet werden. Die Lösung besteht darin, eine bestimmte (nicht standardmäßige) statische Route auf null0 zu konfigurieren, die diese nicht erreichbaren NHs abdeckt, die Routen über BGP-LU einzuschleusen oder sie zwischen IGP-Domänen neu zu verteilen.

Dies ist umständlich und/oder beeinträchtigt die Skalierbarkeit.

Lösung

Der PE (Headend) empfängt farbige BGP L3VPN-Präfixe. Die SR-Richtlinie kann lokal abgerufen werden, oder es kann eine ODN SR-Richtlinie für Farbe und Next-Hop angefordert werden.

Wenn eine NH-Validierung konfiguriert ist, validiert das BGP den NH-Typ weich und wendet die NH-AD/Metrik an, wenn der Befehl aktiviert ist. Bei farbigem NH wird die AD/Metrik vom SR Controller übernommen. Die weiche Validierung des Next-Hop bedeutet, dass die Verfügbarkeit der RIB nicht überprüft wird. Die Überprüfung wird jedoch mit den SR-Richtlinieninformationen durchgeführt. Dazu gehören der Routentyp für die SR-Richtlinie, die Admin-Entfernung und der Metrikwert für diesen metrischen Typ.

Für diese Soft Next-Hop-Validierung auf dem Headend-Router oder dem RR wird ein neuer Befehl eingeführt.

Für den RR wird ein neuer Befehl eingeführt, um die Next-Hop-Erreichbarkeitsprüfung für Farb-Excomm-Pfade zu überspringen.

Für den RR wird ein neuer Befehl eingeführt, damit die SR-Richtlinie nicht für die Berechnung des besten BGP-Pfads verwendet wird.

Diese Funktion wurde in den Versionen 7.3.2 und 7.4.1 von Cisco IOS XR eingeführt.

Next-Hop für BGP-Route nicht erreichbar

Eine BGP-Route mit einem nicht zugreifbaren Next-Hop wird nicht angekündigt.

Diese Route ist eine VPNv4-Route auf einem RR. Der Next-Hop (PE-Loopback) ist nicht zugänglich, da in der Routing-Tabelle keine Route für die Next-Hop-Adresse vorhanden ist.

RP/0/RP0/CPU0:RR#show bgp vpnv4 unicast rd 65001:2 10.0.0.9/32

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65001:2

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                   0            0

Last Modified: Oct 26 10:40:12.136 for 00:03:07

Paths: (1 available, no best path)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

65002, (Received from a RR-client)

10.0.0.5 (inaccessible) from 10.0.0.5 (10.0.0.5)

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, not-in-vrf

Received Path ID 0, Local Path ID 0, version 0

Extended community: Color:101 RT:65001:101

Die BGP VPNv4-Route wird daher nicht angekündigt.

RP/0/RP0/CPU0:RR#show route 10.0.0.5

Routing entry for 0.0.0.0/0

Known via "isis 1", distance 115, metric 20, candidate default path, type level-1

Installed Oct 25 09:35:07.256 for 1d01h

Routing Descriptor Blocks

10.2.7.2, from 10.0.0.3, via GigabitEthernet0/0/0/0

Route metric is 20

No advertising protos.

Die aktuelle Problemumgehung besteht in der Konfiguration einer statischen Route, die die PE-Loopback-Adressen auf dem Headend-Router abdeckt. Dies ist ein Beispiel für eine solche statische Route zu null0.

address-family ipv4 unicast

10.0.0.0/24 Null0

!

!

Diese statische Route zu Null0 erzeugt Erreichbarkeit im RIB für alle Remote-PE-Loopback-Adressen (die BGP Next-Hop-Adressen). Diese statische Route deckt alle Adressen im Bereich 10.0.0.0 bis 10.0.0.255 ab.

Der Next-Hop wird über die statische Route aufgelöst. Sie können dies mit diesem Befehl sehen.

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast nexthops 10.0.0.5 color 101

Nexthop: 10.0.0.5 C:101

VRF: default

Nexthop ID: 0x6000008, Version: 0x0

Nexthop Flags: 0x00480002

Nexthop Handle: 0x7fa734042e94

RIB Related Information:

Firsthop interface handle 0x0000000c

Gateway TBL Id: 0xe0000000    Gateway Flags: 0x00000080

Gateway Handle: 0x7fa7988c7ce8

Gateway: reachable, non-Connected route, prefix length 24

Resolving Route: 10.0.0.0/24 (static)

Paths: 0

RIB Nexhop ID: 0x0

Status: [Reachable][Connected][Not Local]

Metric: 0

ORR afi bits: 0x0

Registration: Synchronous, Completed: 01:22:27

Events: Critical (0)/Non-critical (0)

Last Received: 01:22:27 (Registration)

Last gw update: (Crit-sync) 01:22:27(rib)

Reference Count: 4

Prefix Related Information

Active Tables: [IPv4 Unicast][VPNv4 Unicast]

Metrices: [0x0][0x0]

Reference Counts: [0][4]

Interface Handle: 0x0

Attr ref-count: 7

SR policy color 101, State: [Up]

Not registered, bsid 24009

Skip Reg on restart [No]

First notif received [Yes]

SR Policy Flags [0x2]

BGP TE registered [No]

ODN registered [No]

IPv6 capability required/enabled: Yes/Yes

Last SR policy update: 01:22:35

Wenn eine SR-Richtlinie für die Validierung des Next-Hop verwendet wird, wird diese Ausgabe angezeigt:

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast nexthops 10.0.0.5 color 101

Nexthop: 10.0.0.5 C:101

VRF: default

Nexthop ID: 0x6000008, Version: 0x0

Nexthop Flags: 0x00480000

Nexthop Handle: 0x7fa734042e94

RIB Related Information:

Firsthop interface handle 0x00000000

Gateway TBL Id: 0xe0000000    Gateway Flags: 0x00000080

Gateway Handle: 0x7fa7988c7ce8

Gateway: unreachable, non-Connected route, prefix length 8192

Resolving Route: 10.0.0.0/24 (static)

Paths: 0

RIB Nexhop ID: 0x0

Status: [Unreachable]

Metric: 4294967295

ORR afi bits: 0x0

Registration: Synchronous, Completed: 01:25:30

Events: Critical (1)/Non-critical (0)

Last Received: 00:00:43 (Critical)

Last gw update: (Crit-notif) 00:00:43(rib)

Reference Count: 2

Prefix Related Information

Active Tables: [IPv4 Unicast][VPNv4 Unicast]

Metrices: [0xffffffff][0xffffffff]

Reference Counts: [0][2]

Interface Handle: 0x0

Attr ref-count: 5

SR policy color 101, State: [Up]

Not registered, bsid 24009

Skip Reg on restart [No]

First notif received [Yes]

SR Policy Flags [0x2]

BGP TE registered [No]

ODN registered [No]

IPv6 capability required/enabled: Yes/Yes

Last SR policy update: 01:25:38

Konfiguration

Diese Konfigurationsbefehle sind neu:

nexthop validation color-extcomm sr-policy

nexthop validation color-extcomm disable

bgp bestpath igp-metric sr-policy

bgp bestpath sr-policy prefer

bgp bestpath sr-policy force

nexthop validation color-extcomm disable

BGP ODN AS NextHop Soft Validation Knob

PE (HE):

RP/0/RP0/CPU0:PE1(config)#router bgp 65001

RP/0/RP0/CPU0:PE1(config-bgp)#nexthop ?

mpls        Configure next-hop related items for mpls

resolution  Configure next-hop related items for resolution

validation  Configure next-hop reachability validation

RP/0/RP0/CPU0:PE1(config-bgp)#nexthop validation ?

color-extcomm  Configure next-hop reachability validation for color-extcomm paths

RP/0/RP0/CPU0:PE1(config-bgp)#nexthop validation color-extcomm ?

disable    Disable next-hop reachability validation for color-extcomm paths

sr-policy  Enable BGP next-hop reachability validation by SR Policy for color-extcomm paths

RP/0/RP0/CPU0:PE1(config-bgp)#nexthop validation color-extcomm sr-policy

RP/0/RP0/CPU0:PE1(config-bgp)#commit

Dies ist der Hauptbefehl: aktiviert das BGP Soft Next-Hop-Verhalten. Die RIB-Validierung wird nicht durchgeführt, wenn eine SR-Richtlinie für den nächsten Hop und die nächste Farbe verfügbar ist.

BGP ODN AS Next-Hop Hard Validation Knob

BGP Hard Next-Hop ist das Standardverhalten.

Dieser Befehl dient dazu, auf dieses Verhalten zurückzukehren: kein Farb-Excomm für die Validierung der nächsten Hop.

BGP-Auswahl für besten Pfad unter Berücksichtigung der SR-Richtlinienpfadmetrik

Wenn für die NHs Interior Gateway Protocol (IGP)-Erreichbarkeit vorhanden ist und der Algorithmus bei der Auswahl des besten BGP-Pfads Schritt 8 erreicht, ist der bevorzugte BGP-Pfad der mit der niedrigsten (IGP) Entfernung zum nächsten Hop. Dies ist das Standardverhalten. Siehe BGP Best Path Selection Algorithm.

Dies gilt nur, wenn der Befehl bgp bestpath igp-metric ignore konfiguriert wurde. In diesem Fall werden die IGP-Kosten überhaupt nicht berücksichtigt.

Derzeit wird nur die IGP-Metrik für den BGP-NH berücksichtigt. nicht die vom SR Policy Path bereitgestellte Metrik. Dieses Verhalten bleibt das Standardverhalten, es gibt jedoch einen Befehl, der BGP anweist, die Richtlinientypmetrik anstelle der IGP-Metrik für den BGP-Algorithmus zur Auswahl des besten Pfads zu verwenden.

RP/0/RP0/CPU0:PE1(config)#router bgp 65001

RP/0/RP0/CPU0:PE1(config-bgp)#bgp bestpath igp-metric ?

ignore     Ignore IGP metric during path comparison

sr-policy  Use next-hop admin/metric from SR policy at Next Hop metric compareson stage

RP/0/RP0/CPU0:PE1(config-bgp)#bgp bestpath igp-metric sr-policy

RP/0/RP0/CPU0:PE1(config-bgp)#commit

Dieser Befehl aktiviert die Berücksichtigung der PCE/Pfad-Admin- und metrischen Werte. Diese admin-/metrischen Werte können nur an BGP übergeben werden, wenn die SR-Richtlinie aktiv ist. Mit diesem Befehl kann der BGP-Algorithmus den besten Pfad basierend auf dem Admin und der Metrik für den nächsten Hop aus der SR-Richtlinie auswählen. Ohne diesen Befehl wird standardmäßig nur die IGP-Metrik des nächsten Hop berücksichtigt. Dies wird als "RIB-Validierung des nächsten Hop" bezeichnet.

BGP Best Path Selection Preferred SR-Richtlinienpfade

Es gibt Plattformen, die die Kombination von Pfaden nicht unterstützen, die entweder über einen nativen Next-Hop oder über einen SR Policy Next-Hop verfügen. Die Plattform unterstützt diese Mischung bei der Weiterleitung über beide Pfadtypen möglicherweise nicht. Dies ist wichtig, wenn Sie Equal Cost Multi-Path (ECMP) oder Uniqual Cost Multi-Path (UCMP) oder Backup Pfade verwenden. Jeder Pfadtyp kann der beste Pfad des BGP sein. Das Standardverhalten besteht darin, nur BGP-Pfade mit demselben Next-Hop-Typ wie der beste BGP-Pfad zu berücksichtigen.

Mit diesem Befehl wird BGP angewiesen, Routen vorzuziehen, für die eine SR-Richtlinie für die Farbe/den nächsten Hop vorliegt, wenn der Router die Berechnung des besten Pfads durchführt. Dies bedeutet, dass Pfade, bei denen die SR-Richtlinie ausgefallen ist oder keine SR-Richtlinie existiert, bei der Berechnung des besten Pfads nicht berücksichtigt werden.

bgp bestpath sr-policy {force} | ziehen Sie es vor.

Eines der beiden Schlüsselwörter muss konfiguriert werden.

RP/0/RP0/CPU0:PE1(config-bgp)#bgp bestpath sr-policy ?

force   Consider only paths over SR Policy for bestpath selection, eBGP no-color ineligible

prefer  Consider only paths over SR Policy for bestpath selection, eBGP no-color eligible

Wenn Sie die bevorzugte Option konfigurieren, sind die eBGP-Pfade ohne Farbe als qualifiziert gekennzeichnet (so kann Teil des besten Pfades sein). Wenn dieses Verhalten nicht erwünscht ist, können Sie den eBGP-Pfaden eine Dummy-SR-Richtlinie hinzufügen. Andernfalls können Sie die Force-Option für diesen Befehl so konfigurieren, dass die eBGP-Routen ohne Farbe nicht qualifiziert sind.

Siehe Netzwerk, wie im Bild gezeigt.

Es gibt drei mögliche Pfade für das Netzwerk 10.99.99.99/32 vom Router PE1. Das Präfix 10.99.99.99/32 wird von R8 und dem CE-Router angekündigt.

BGP hat drei Pfade für die Route 10.99.99.99/32: 2 iBGP (PE2 und PE3 sind die BGP Next-Hop-Router) und 1 eBGP-Pfade (von R8).

Die iBGP-Pfade haben Next-Hop 10.0.0.5 und 10.0.0.6. Der eBGP-Pfad hat Next-Hop 10.1.8.8.

Der Befehl bgp bestpath sr-policy ist in der Konfiguration nicht enthalten.

RP/0/RP0/CPU0:PE1#show bgp vrf one 10.9.9.9/32

BGP routing table entry for 10.9.9.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 474          474

Local Label: 24005

Last Modified: Nov 29 09:04:07.948 for 00:00:49

Paths: (3 available, best #3)

Advertised to PE peers (in unique update groups):

10.0.0.4        10.0.0.3

Path #1: Received by speaker 0

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24007) (admin 20) (metric 23) from 10.0.0.3 (10.0.0.5)

Received Label 24018

Origin IGP, metric 0, localpref 100, valid, internal, group-best, imported

Received Path ID 0, Local Path ID 0, version 0

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.3

SR policy color 101, up, not-registered, bsid 24007

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

Path #2: Received by speaker 0

Not advertised to any peer

65002

10.0.0.6 from 10.0.0.4 (10.0.0.6)

Received Label 24004

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

Received Path ID 0, Local Path ID 0, version 0

Extended community: RT:65001:101

Originator: 10.0.0.6, Cluster list: 10.0.0.4

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:3

Path #3: Received by speaker 0

Advertised to PE peers (in unique update groups):

10.0.0.4        10.0.0.3

65003

10.1.8.8 from 10.1.8.8 (10.0.0.8)

Origin IGP, metric 0, localpref 100, valid, external, best, group-best, import-candidate

Received Path ID 0, Local Path ID 1, version 474

Extended community: RT:65001:101

Origin-AS validity: (disabled)

Der eBGP-Pfad weist keine Farbe oder keine SR-Richtlinie auf. Es ist der beste Weg.

Wenn die eBGP-Route farbig ist, aber keine SR-Richtlinie, wird sie dennoch als der beste Pfad ausgewählt.

Wenn die eBGP-Route eine Farbe und eine SR-Richtlinie hat, wird sie als der beste Pfad ausgewählt.

Hier ist ein weiteres Beispiel. Die eBGP-Route hat keine Farbe, und es wird keine SR-Richtlinie und der Befehl bgp bestpath sr-policy prefer konfiguriert.

Anmerkung: Der eBGP-Nachbar befindet sich innerhalb der VRF-Instanz. Dies bedeutet, dass Sie den Befehl bgp bestpath sr-policy prefer unter der VRF-Instanz konfigurieren müssen.

router bgp 65001

nexthop validation color-extcomm sr-policy

bgp unsafe-ebgp-policy

bgp bestpath igp-metric sr-policy

address-family vpnv4 unicast

!

neighbor 10.0.0.3

remote-as 65001

update-source Loopback0

address-family vpnv4 unicast

!

!

neighbor 10.0.0.4

remote-as 65001

update-source Loopback0

address-family vpnv4 unicast

!

!

neighbor 10.0.0.7

remote-as 65001

shutdown

update-source Loopback0

address-family vpnv4 unicast

!

!

vrf one

rd 65000:1

bgp unsafe-ebgp-policy

bgp bestpath sr-policy prefer

address-family ipv4 unicast

redistribute connected

!

neighbor 10.1.8.8

remote-as 65003

address-family ipv4 unicast

!

!

!

!

RP/0/RP0/CPU0:PE1#show bgp vrf one 10.9.9.9/32 bestpath-compare

BGP routing table entry for 10.9.9.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 579          579

Local Label: 24004 (no rewrite);

Flags: 0x01343001+0x00020000;

Last Modified: Nov 30 07:36:55.948 for 00:03:05

Paths: (3 available, best #3)

Advertised to PE peers (in unique update groups):

10.0.0.4        10.0.0.3

Path #1: Received by speaker 0

Flags: 0x2000000001020005, import: 0x080

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24007) (admin 20) (metric 23) from 10.0.0.3 (10.0.0.5), if-handle 0x00000000

Received Label 24018

Origin IGP, metric 0, localpref 100, valid, internal, group-best, imported

Received Path ID 0, Local Path ID 0, version 0

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.3

SR policy color 101, up, not-registered, bsid 24007

best of AS 65002

An iBGP path, whereas best path (path #3) is an eBGP path

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

Path #2: Received by speaker 0

Flags: 0x2000000000020005, import: 0x0a0

Not advertised to any peer

65002

10.0.0.6 from 10.0.0.4 (10.0.0.6), if-handle 0x00000000

Received Label 24004

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

Received Path ID 0, Local Path ID 0, version 0

Extended community: RT:65001:101

Originator: 10.0.0.6, Cluster list: 10.0.0.4

Non SR-policy path is ignored due to config knob

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:3

Path #3: Received by speaker 0

Flags: 0x300000000d040003, import: 0x31f

Advertised to PE peers (in unique update groups):

10.0.0.4        10.0.0.3

65003

10.1.8.8 from 10.1.8.8 (10.0.0.8), if-handle 0x00000000

Origin IGP, metric 0, localpref 100, valid, external, best, group-best, import-candidate

Received Path ID 0, Local Path ID 1, version 579

Extended community: RT:65001:101

Origin-AS validity: (disabled)

best of AS 65003, Overall best

Der eBGP-Pfad ist der beste, auch wenn er keine Farbe hat. Wenn Sie die eBGP-Route nicht farblos als besten Pfad verwenden möchten, konfigurieren Sie den Befehl bgp bestpath sr-policy mit der force-Option.

Anmerkung: Die lokalen und neu verteilten Pfade sind immer für die Berechnung des besten Pfades qualifiziert.

Mit diesem Befehl können Sie überprüfen, ob die Plattform die Kombination aus Weiterleitung über die SR-Richtlinie und nativem Next-Hop unterstützt.

RP/0/RP0/CPU0:R1#show bgp process detail | include native

Platform support mix of sr-policy and native nexthop: No

Anmerkung: Die Router NCS55xx und NCS560/NCS540 zeigen "Nein", der ASR9000 "Ja".

BGP Best Path Selection Forcing SR-Richtlinienpfade

Der Befehl weist BGP an, bei der Berechnung des besten Pfads Routen mit dem nächsten Hop der SR-Richtlinie zu bevorzugen. eBGP-Pfade ohne Farbe werden jedoch ausgeschlossen.

RP/0/RP0/CPU0:PE1(config-bgp)#bgp bestpath sr-policy ?

force   Consider only paths over SR Policy for bestpath selection, eBGP no-color ineligible

RP/0/RP0/CPU0:PE1(config-bgp)#bgp bestpath sr-policy force ?

Next-Hop Reachability Validation für Color-Excomm-Pfade ist deaktiviert

Dies wird in der Regel für Routen-Reflektoren (RRs) verwendet.

RR:

RP/0/RP0/CPU0:RR1(config-bgp)#nexthop validation color-extcomm disable

RP/0/RP0/CPU0:RR1(config-bgp)#commit

Die Next-Hop-Erreichbarkeitsprüfung für Farbverlustpfade ist deaktiviert. Dies ist für den Zustand oder das Vorhandensein einer SR-Richtlinie irrelevant.

Überblick

Das Verhalten auf Headend und RR wird durch die Konfiguration des Next-Hop-Validierungsbefehls und des Befehls bgp best path igp-metric sr-policy bestimmt. Es gibt 4 Szenarien. Jedes Szenario verfügt über eine Kombination aus zwei Konfigurationsbefehlen.

Standardverhalten

Gilt für Headend-Router und RR.

Konfiguration:

no nexthop validation color-extcomm sr-policy

no bgp bestpath igp-metric sr-policy

Funktion:

Perform RIB validation (hard next-hop).

Do not use admin/metric from the sr-policy.

RIB-abhängige Validierung mit SR Policy Metric

Gilt für Headend-Router und RR.

Konfiguration:

no nexthop validation color-extcomm sr-policy

bgp bestpath igp-metric sr-policy

Funktion:

Perform RIB validation (hard next-hop).

If NH is reachable in RIB:

If policy is up:

Use policy metric

If policy is down:

Use RIB metric

SR Policy Dependent Validation with RIB Metric

Dies ist das Standardverhalten.

Gilt für Headend-Router.

Konfiguration:

nexthop validation color-extcomm sr-policy

no bgp bestpath igp-metric sr-policy

Funktion:

Do not perform RIB validation (soft next-hop).

Do not use admin/metric from the SR policy.

The RIB metric might not be available.

SR Policy Dependent Validation mit SR Policy Metric

Gilt für Headend-Router.

Konfiguration:

nexthop validation color-extcomm sr-policy

bgp bestpath igp-metric sr-policy

Funktion:

Do not perform RIB validation (soft next-hop).  RIB reachability is not needed.

If policy is up:

Use policy metric and validation, even if RIB reachability is present

If policy is down:

Use RIB validation and metric if available. If not available, the route is not installed.

SR Policy Dependent Validation with RIB Metric and SR Policy not Used for Best Path Calberechnung

Gilt für RR-Router.

Konfiguration:

nexthop validation color-extcomm disable

no bgp bestpath igp-metric sr-policy

Funktion:

Use RIB metric if the next-hop is in the RIB. Else, use the gateway metric (the next-hop IGP metric) 0.

Do not use SR policy for bestpath calculation. Do not use admin/metric from the SR policy.

SR Policy Dependent Validation with RIB Metric and SR Policy für die Berechnung des besten Pfads

Gilt für RR-Router.

Konfiguration:

nexthop validation color-extcomm disable

bgp bestpath igp-metric sr-policy

Funktion:

Use RIB metric if the next-hop is in the RIB. Else, use the gateway metric 0.

Use sr-policy for bestpath calculation.

If policy is up:

Use policy metric and validation, even if RIB reachability is present

If policy is down

Use RIB validation and metric if available

If RIB validation and metric is not available:

use the gateway metric 0

Überprüfung

So überprüfen Sie, welche Next-Hop-Validierung aktiv ist und ob die Admin-Distanz/Metrik der SR-Richtlinie bei der Berechnung des besten Pfads verwendet wird.

RP/0/RP0/CPU0:PE1#show bgp process detail | i Nexthop

Use SR-Policy admin/metric of color-extcomm Nexthop during path comparison: enabled

ExtComm Color Nexthop validation: SR-Policy then RIB

Dies ist die Standardeinstellung.

Dies ist ein Beispiel für eine SR Policy Dependent Validation mit RIB Metric und SR Policy, die nicht für die Berechnung des besten Pfads verwendet werden.

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast process detail | in Nexthop

Use SR-Policy admin/metric of color-extcomm Nexthop during path comparison: disabled

ExtComm Color Nexthop validation: RIBExtComm Color Nexthop validation: RIB

Dies ist ein Beispiel für eine Admin-Distanz/Metrik, die mit der BGP-Route verbunden ist.

RP/0/RP0/CPU0:PE1#show bgp vrf VRF1002 ipv4 unicast 10.77.2.0

BGP routing table entry for 10.77.2.0/24, Route Distinguisher: 18522:1002

Versions:

Process           bRIB/RIB  SendTblVer

Speaker            5232243     5232243

Paths: (1 available, best #1)

Advertised to CE peers (in unique update groups):

10.11.2.11      10.15.2.2

Path #1: Received by speaker 0

Advertised to CE peers (in unique update groups):

10.11.2.11      10.15.2.2

16611 770

10.1.1.33 C:1129 (bsid:27163) (admin 20) (metric 25) from 10.1.1.100 (10.1.1.33)

Received Label 24007

Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 1, Local Path ID 1, version 5232243

Extended community: Color:1129 RT:17933:1002 RT:18522:1002

Originator: 10.1.1.33, Cluster list: 10.1.1.100

SR policy color 1129, up, registered, bsid 27163, if-handle 0x200053dc

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 18522:3002

Überprüfen, ob eine Richtlinie aktiviert oder deaktiviert ist

So überprüfen Sie, ob die SR-Richtlinie aktiviert oder deaktiviert ist.

RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng pcc lsp

PCC's SR policy database:

-------------------------

Symbolic Name: cfg_ODN-policy-1_discr_100

LSP[0]:

Source 10.0.0.1, Destination 10.0.0.5, Tunnel ID 3, LSP ID 8

State: Admin up, Operation up

Setup type: SR

Binding SID: 24005

Überprüfen der Verwendung der Richtlinie

Verwenden Sie den Befehl BGP show, um die Route anzuzeigen.

Wenn ein Binding Segment IDentifier (BSID) vorhanden ist, verwendet diese Route eine SR-Richtlinie.

RP/0/RP0/CPU0:PE1#show bgp vrf one 10.0.0.9/32

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  89           89

Last Modified: Oct 28 13:21:57.714 for 00:00:30

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24004) from 10.0.0.3 (10.0.0.5)

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 87

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.3

SR policy color 101, up, not-registered, bsid 24004

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

Die Bindungs-SID ist hier ein MPLS-Label. Dieses Label ist mit einer SR Policy verknüpft.

RP/0/RP0/CPU0:PE1#show mpls forwarding labels 24004

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

24004  Pop         No ID              srte_c_101_e point2point     0

BGP Nexthops-Befehl anzeigen

Mit dem Befehl show bgp nexthops können Sie Farbe, Admin und Metrik für den Endpunkt anzeigen.

RP/0/RP0/CPU0:RR#show bgp nexthops wide

Total Nexthop Processing

Time Spent: 0.000 secs

Maximum Nexthop Processing

Received: 00:21:57

Bestpaths Deleted: 0

Bestpaths Changed: 31

Time Spent: 0.000 secs

Last Notification Processing

Received: 00:01:22

Time Spent: 0.000 secs

Gateway Address Family: IPv4 Unicast

Table ID: 0xe0000000

Gateway Reference Count: 8

Gateway AF Bits : 0x8011

Nexthop Count: 6

Critical Trigger Delay: 3000msec

Non-critical Trigger Delay: 10000msec

Nexthop Version: 1, RIB version: 1

EPE Table Version: 1, EPE Label version: 1

EPE Downloaded Version: 1, EPE Standby Version: 0

Status codes: R/UR Reachable/Unreachable

C/NC Connected/Not-connected

L/NL Local/Non-local

PR   Pending Registration

I    Invalid (Policy drop)

Next Hop                                Status          Metric           Tbl-ID                  Notf      LastRIBEvent             RefCount

10.0.0.1                                [R][NC][NL]         30         e0000000                   6/0    00:01:22 (Cri)                  0/5

10.0.0.3                                [R][NC][NL]         20         e0000000                   6/0    00:01:22 (Cri)                 0/34

10.0.0.4                                [R][NC][NL]         30         e0000000                   6/0    00:01:22 (Cri)                 0/34

10.0.0.5                                [UR]        4294967295         e0000000                   2/0    00:01:22 (Cri)                  0/4

10.0.0.5 T:101                          [UR]        4294967295         e0000000                   2/0    00:01:22 (Cri)                  0/3

10.0.0.6                                [UR]        4294967295         e0000000                   2/0    00:01:22 (Cri)                  0/3

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast nexthops 10.0.0.5 color 101

Nexthop: 10.0.0.5 C:101

VRF: default

Nexthop ID: 0x6000006, Version: 0x0

Nexthop Flags: 0x00480002

Nexthop Handle: 0x7efc84043624

RIB Related Information:

Firsthop interface handle 0x0000000c

Gateway TBL Id: 0xe0000000    Gateway Flags: 0x00000080

Gateway Handle: 0x7efcadee6e98

Gateway: reachable, non-Connected route, prefix length 8

Resolving Route: 10.0.0.0/8 (static)

Paths: 0

RIB Nexhop ID: 0x0

Status: Reachable via SR-TE

Status: [Reachable][Connected][Not Local]

Metric: 0 (SR-TE metric 333)

ORR afi bits: 0x0

Registration: Asynchronous, Completed: 2d05h

Events: Critical (14)/Non-critical (0)

Last Received: 02:15:15 (Critical)

Last gw update: (Crit-notif) 02:15:15(rib)

Reference Count: 2

Prefix Related Information

Active Tables: [IPv4 Unicast][VPNv4 Unicast]

Metrices: [0x0][0x0]

Reference Counts: [0][2]

Interface Handle: 0x0

Attr ref-count: 5

SR policy color 101, State: [Up]

Not registered, bsid 24004

Skip Reg on restart [No]

First notif received [Yes]

SR Policy Flags [0x2]

BGP TE registered [No]

ODN registered [No]

End-point admin/metric: 30/333

IPv6 capability required/enabled: Yes/Yes

Last SR policy update: 00:55:07

BGP-Trace

Einige Einträge in der Ausgabe von show bgp trace beziehen sich auf die SR-Richtlinie. Beachten Sie das Vorhandensein von admin/metric.

default-bgp/spkr-tr2-sr 0/RP0/CPU0 t8885 [SR]:1323: SR-policy hdlr for reg nh with XTC af 0, reg/unreg flag 1

default-bgp/spkr-tr2-sr 0/RP0/CPU0 t8885 [SR]:3394: SR-policy XTC nexthop 10.0.0.5/32 T:, color 101, register 1 with XTC done, v6-cap 1, rc 'Success', flags 0x480000

default-bgp/spkr-tr2-sr 0/RP0/CPU0 t8885 [SR]:3394: SR-policy XTC nexthop 10.0.0.6/32 T:, color 101, register 1 with XTC done, v6-cap 0, rc 'Success', flags 0x480000

default-bgp/spkr-tr2-sr 0/RP0/CPU0 t8885 [SR]:2424: SR-policy XTC notif NH end-point color,gw_afi 0, [C:101][10.0.0.5] admin/metric 100/2147483647

default-bgp/spkr-tr2-sr 0/RP0/CPU0 t8885 [SR]:2424: SR-policy XTC notif NH end-point color,gw_afi 0, [C:101][10.0.0.5] admin/metric 100/2147483647

default-bgp/spkr-tr2-sr 0/RP0/CPU0 t8885 [SR]:2424: SR-policy XTC notif NH end-point color,gw_afi 0, [C:101][10.0.0.5] admin/metric 20/30

default-bgp/spkr-tr2-sr 0/RP0/CPU0 t8881 [SR]:1379: SR-policy trigger XTC for nh reg af 0, reg/unreg flag 1

default-bgp/spkr-tr2-nh 0/RP0/CPU0 t8885 [NH]:7370: nexthop walk for AFI:'VPNv4 Unicast' start

default-bgp/spkr-tr2-nh 0/RP0/CPU0 t8885 [NH]:7425: nexthop walk for AFI:'VPNv4 Unicast', paths deleted: 0, recalculated bestpaths: 2, color nh trigger for 2 nets, 0 msec

Anmerkung: Der Cisco IOS XR Traffic Controller (XTC) bezieht sich auf den SR Controller.

Einige Einträge im BGP-Trace beziehen sich auf die Konfigurationsänderung für die Next-Hop-Verarbeitung.

default-bgp/spkr-tr2-prog 0/RP0/CPU0 t9036 [PROG]:724: 'Done VRF cfg notif init', name default iid 0

default-bgp/spkr-tr2-prog 0/RP0/CPU0 t9036 [PROG]:792: 'Done cfg init', name default iid 0

default-bgp/spkr-tr2-gen 0/RP0/CPU0 t9048 [GEN]:17871: nh cfg change 2 sense 1

default-bgp/spkr-tr2-gen 0/RP0/CPU0 t9048 [GEN]:17920: nh cfg change 1 sense 1

Administrative Distanz und Metrik

Die administrative Distanz (admin) wird durch den metrischen Typ in der SR-Richtlinie bestimmt. Der metrische Typ kann auf dem Headend-Router festgelegt werden.

RP/0/RP0/CPU0:PE1#conf t

RP/0/RP0/CPU0:PE1(config)#segment-routing

RP/0/RP0/CPU0:PE1(config-sr)#traffic-eng

RP/0/RP0/CPU0:PE1(config-sr-te)#policy ODN-policy-1

RP/0/RP0/CPU0:PE1(config-sr-te-policy)#color 101 end-point ipv4 10.0.0.5

RP/0/RP0/CPU0:PE1(config-sr-te-policy)#candidate-paths

RP/0/RP0/CPU0:PE1(config-sr-te-policy-path)#preference 100

RP/0/RP0/CPU0:PE1(config-sr-te-policy-path-pref)#dynamic

RP/0/RP0/CPU0:PE1(config-sr-te-pp-info)#metric ?

margin     Metric margin

sid-limit  SID limit

type       Metric type configuration

<cr>

RP/0/RP0/CPU0:PE1(config-sr-te-pp-info)#metric type ?

hopcount  Hopcount metric type

igp       IGP metric type

latency   Latency metric type

te        TE metric type

Admin-Werte

Dies sind die standardmäßigen Administrationswerte für die SR-Richtlinie.

- Latenz 10

- TE 20

- IGP (Standard) 30

- Hopcount 40

- KEINER/UNKNOWN-Metrischer Typ (für explizite Segmentlistenrichtlinien) 100

Wenn der metrische Typ keine ist, ist der metrische Wert 1.

Je niedriger der Admin-Wert, desto besser ist der Pfad zum BGP.

Je niedriger die Metrik, desto besser ist der Pfad zum BGP, wenn der Administrator denselben Wert hat.

Überprüfung des Administrations- und Metriktyps im ODN

RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy color 101 endpoint ipv4 10.0.0.5

SR-TE policy database

---------------------

Color: 101, End-point: 10.0.0.5

Name: srte_c_101_ep_10.0.0.5

Status:

Admin: up  Operational: up for 01:01:00 (since Oct 28 15:22:36.012)

Candidate-paths:

Preference: 100 (configuration) (active)

Name: ODN-policy-1

Requested BSID: dynamic

PCC info:

Symbolic name: cfg_ODN-policy-1_discr_100

PLSP-ID: 4

Protection Type: protected-preferred

Maximum SID Depth: 10

Dynamic (pce 10.0.0.7) (valid)

Metric Type: IGP,   Path Accumulated Metric: 30

16002 [Prefix-SID, 10.0.0.2]

24009 [Adjacency-SID, 10.2.3.2 - 10.2.3.3]

16005 [Prefix-SID, 10.0.0.5]

Attributes:

Binding SID: 24004

Forward Class: Not Configured

Steering labeled-services disabled: no

Steering BGP disabled: no

IPv6 caps enable: yes

Invalidation drop enabled: no

Effektive Kennzahl

Die effektive Metrik erzwingt den Typ und die Metrik der Richtlinie, unter der dieser Befehl konfiguriert wird.

RP/0/RP0/CPU0:PE1#conf t

RP/0/RP0/CPU0:PE1(config)#segment-routing

RP/0/RP0/CPU0:PE1(config-sr)#traffic-eng

RP/0/RP0/CPU0:PE1(config-sr-te)#policy ODN-policy-1

RP/0/RP0/CPU0:PE1(config-sr-te-policy)#candidate-paths

RP/0/RP0/CPU0:PE1(config-sr-te-policy-path)#preference 100

RP/0/RP0/CPU0:PE1(config-sr-te-policy-path-pref)#effective-metric ?

value  Metric value, advertised to other protocols

<cr>

RP/0/RP0/CPU0:PE1(config-sr-te-policy-path-pref)#effective-metric value 333 ?

type  Metric type, advertised to other protocols

<cr>

RP/0/RP0/CPU0:PE1(config-sr-te-policy-path-pref)#effective-metric value 333 type ?

hopcount  HOPCOUNT metric type

igp       IGP metric type

latency   LATENCY metric type

te        TE metric type

RP/0/RP0/CPU0:PE1(config-sr-te-policy-path-pref)#effective-metric value 333 type igp ?

<cr>

RP/0/RP0/CPU0:PE1(config-sr-te-policy-path-pref)#effective-metric value 333 type igp

RP/0/RP0/CPU0:PE1(config-sr-te-policy-path-pref)#commit

RP/0/RP0/CPU0:PE1#show run segment-routing traffic-eng policy ODN-policy-1

segment-routing

traffic-eng

policy ODN-policy-1

color 101 end-point ipv4 10.0.0.5

candidate-paths

preference 100

dynamic

pcep

!

metric

type igp

!

!

effective-metric

value 333 type igp

Auf diese Weise können Sie den angewendeten effektiven Metriktyp (Admin-Distanz) und den Metrik-Wert überprüfen.

RP/0/RP0/CPU0:PE1#show bgp vrf one 10.0.0.9/32

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 131          131

Last Modified: Oct 28 15:22:35.714 for 00:03:42

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24004) (admin 30) (metric 333) from 10.0.0.7 (10.0.0.5)

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 130

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.7, 10.0.0.3

SR policy color 101, up, not-registered, bsid 24004

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

Vergleich von BGP-Pfaden

Der Vergleich von BGP-Pfaden wird standardmäßig nicht geändert.

Wenn der Befehl bgp bestpath igp-metric sr-policy konfiguriert ist, werden die Admin-Distanz und die Metrik der SR-Richtlinie im BGP Best-Path-Auswahlalgorithmus verwendet.

Die Admin-Entfernung und die Metriken der SR-Richtlinie sind an die SR-Richtlinie gebunden. Diese wird lokal konfiguriert oder über PCEP (Path Computation Element Protocol) vom SR-PCE empfangen. Dies bedeutet, dass ein RR beim Vergleich von Pfaden die Admin-Distanz und -Metrik nicht erkennt, da er über keine Headend-Funktionalität für ODN verfügt. Daher ist keine PCEP-Sitzung für das SR-PCE vorhanden.

Dieses Beispiel zeigt ein Präfix, das von einem Remote-PE-Router angekündigt wird. Dies ist die Konfiguration.

segment-routing

global-block 16000 23999

traffic-eng

logging

policy status

!

policy ODN-policy-1

color 101 end-point ipv4 10.0.0.5

candidate-paths

preference 100

dynamic

pcep

!

metric

type te

!

!

!

preference 200

dynamic

pcep

!

metric

type te

!

Der metrische Typ ist TE.

Dieser Headend-Router sieht ein Präfix mit einer Farbe zweimal und derselben TE-Metrik, da es für beide Pfade den gleichen BGP Next-Hop darstellt.

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast rd 65001:2 10.0.0.9/32 bestpath-compare

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65001:2

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                   8            8

Flags: 0x00040001+0x00010000;

Last Modified: Nov  2 09:21:55.948 for 00:00:32

Paths: (2 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Flags: 0xa000000025060005, import: 0x31f

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24018) (admin 20) (metric 23) from 10.0.0.3 (10.0.0.5), if-handle 0x00000000

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, not-in-vrf

Received Path ID 0, Local Path ID 1, version 8

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.3

SR policy color 101, up, not-registered, bsid 24018

best of AS 65002, Overall best

Path #2: Received by speaker 0

Flags: 0x2000000024020005, import: 0x000

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24018) (admin 20) (metric 23) from 10.0.0.4 (10.0.0.5), if-handle 0x00000000

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, import-candidate, not-in-vrf

Received Path ID 0, Local Path ID 0, version 0

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.4, 10.0.0.7, 10.0.0.3

SR policy color 101, up, not-registered, bsid 24018

Longer cluster length than best path (path #1)

Da Admin-Distanz und Metrik für beide Pfade identisch sind, wird die Entscheidung für den besten Pfad im BGP-Algorithmus zur Auswahl des besten Pfades weiter unten getroffen.

Dieses Beispiel zeigt ein Präfix, das von zwei Remote-PE-Routern angekündigt wird. Ein Pfad hat Next-Hop 10.0.0.5, der andere Next-Hop 10.0.0.6. Das Präfix hat die Farbe 101 von beiden Remote-PE-Routern. Der Headend-Router PE1 verfügt über zwei ODN-Richtlinien für diese Farbe.

segment-routing

global-block 16000 23999

traffic-eng

logging

policy status

!

policy ODN-policy-1

color 101 end-point ipv4 10.0.0.5

candidate-paths

preference 100

dynamic

pcep

!

metric

type igp

!

!

!

preference 200

dynamic

pcep

!

metric

type te

!

!

!

!

!

policy ODN-policy-2

color 101 end-point ipv4 10.0.0.6

candidate-paths

preference 100

dynamic

pcep

!

metric

type igp

!

Die Richtlinie für den Endpunkt 10.0.0.5 verwendet den metrischen Typ TE und die Richtlinie für den Endpunkt 10.0.0.6 verwendet den metrischen IGP-Typ.

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf one 10.0.0.9/32 bestpath-compare

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  25           25

Flags: 0x00043001+0x00000000;

Last Modified: Nov  1 11:42:28.948 for 00:43:41

Paths: (2 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Flags: 0xa000000005060005, import: 0x080

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24007) (admin 20) (metric 30) from 10.0.0.4 (10.0.0.5), if-handle 0x00000000

Received Label 24002

Origin IGP, metric 0, localpref 100, weight 65000, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 25

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.4, 10.0.0.7, 10.0.0.3

SR policy color 101, up, not-registered, bsid 24007

best of AS 65002, Overall best

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

Path #2: Received by speaker 0

Flags: 0x2000000000020005, import: 0x0a0

Not advertised to any peer

65002

10.0.0.6 C:101 (bsid:24012) (admin 30) (metric 30) from 10.0.0.4 (10.0.0.6), if-handle 0x00000000

Received Label 24002

Origin IGP, metric 0, localpref 100, weight 65000, valid, internal, imported

Received Path ID 0, Local Path ID 0, version 0

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.6, Cluster list: 10.0.0.4

SR policy color 101, up, not-registered, bsid 24012

Higher nexthop admin distance than best path (path #1)

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:3

Der beste Pfad ist der erste, da er eine geringere Admin-Entfernung als der zweite Pfad hat. Der Admin-Abstand des metrischen Typs TE ist niedriger als der des metrischen IGP-Typs.

Die SR-Richtlinie für ODN-policy-1 hat die Priorität 200, und die SR-Richtlinie für ODN-policy-2 hat die Priorität 100.

RP/0/RP0/CPU0:PE1#show segment-routing traffic-eng pcc lsp detail

PCC's SR policy database:

-------------------------

Symbolic Name: cfg_ODN-policy-1_discr_100

LSP[0]:

Source 10.0.0.1, Destination 10.0.0.5, Tunnel ID 1, LSP ID 0

State: Admin up, Operation down

Setup type: SR

Bandwidth: requested 0, used 0

LSP object:

PLSP-ID 0x1, flags: D:0 S:0 R:0 A:1 O:0 C:0

Metric type: IGP, Accumulated Metric 30

ERO:

SID[0]: Node, Label 16004, NAI: 10.0.0.4

SID[1]: Node, Label 16005, NAI: 10.0.0.5

Symbolic Name: cfg_ODN-policy-1_discr_200

LSP[0]:

Source 10.0.0.1, Destination 10.0.0.5, Tunnel ID 1, LSP ID 4

State: Admin up, Operation up

Binding SID: 24007

Setup type: SR

Bandwidth: requested 0, used 0

LSP object:

PLSP-ID 0x2, flags: D:0 S:0 R:0 A:1 O:1 C:0

Metric type: TE, Accumulated Metric 30

ERO:

SID[0]: Adj, Label 24001, NAI: local 10.1.2.1 remote 10.1.2.2

SID[1]: Adj, Label 24003, NAI: local 10.2.3.2 remote 10.2.3.3

SID[2]: Node, Label 16005, NAI: 10.0.0.5

Symbolic Name: cfg_ODN-policy-2_discr_100

LSP[0]:

Source 10.0.0.1, Destination 10.0.0.6, Tunnel ID 2, LSP ID 2

State: Admin up, Operation up

Binding SID: 24012

Setup type: SR

Bandwidth: requested 0, used 0

LSP object:

PLSP-ID 0x3, flags: D:0 S:0 R:0 A:1 O:1 C:0

Metric type: IGP, Accumulated Metric 30

ERO:

SID[0]: Node, Label 16004, NAI: 10.0.0.4

SID[1]: Node, Label 16006, NAI: 10.0.0.6

Im folgenden Beispiel ist die Admin-Distanz identisch, die Metrik ist jedoch anders.

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf one 10.0.0.9/32 bestpath-compare

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  57           57

Flags: 0x00043001+0x00010000;

Last Modified: Nov  2 07:54:20.948 for 00:00:04

Paths: (2 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Flags: 0xa000000005060005, import: 0x080

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24007) (admin 30) (metric 23) from 10.0.0.4 (10.0.0.5), if-handle 0x00000000

Received Label 24002

Origin IGP, metric 0, localpref 100, weight 65000, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 39

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.4, 10.0.0.7, 10.0.0.3

SR policy color 101, up, not-registered, bsid 24007

best of AS 65002, Overall best

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

Path #2: Received by speaker 0

Flags: 0x2000000004020005, import: 0x080

Not advertised to any peer

65002

10.0.0.6 C:101 (bsid:24012) (admin 30) (metric 30) from 10.0.0.4 (10.0.0.6), if-handle 0x00000000

Received Label 24002

Origin IGP, metric 0, localpref 100, weight 65000, valid, internal, import-candidate, imported

Received Path ID 0, Local Path ID 0, version 0

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.6, Cluster list: 10.0.0.4

SR policy color 101, up, not-registered, bsid 24012

Higher IGP metric than best path (path #1)

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:3

Dies ist ein Beispiel mit einem metrischen Hashzähler.

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast vrf one 10.0.0.9/32 bestpath-compare

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  99           99

Flags: 0x00043001+0x00010000;

Last Modified: Nov  2 08:21:19.948 for 00:00:41

Paths: (2 available, best #2)

Not advertised to any peer

Path #1: Received by speaker 0

Flags: 0x2000000004020005, import: 0x080

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24007) (admin 40) (metric 4) from 10.0.0.4 (10.0.0.5), if-handle 0x00000000

Received Label 24002

Origin IGP, metric 0, localpref 100, weight 65000, valid, internal, import-candidate, imported

Received Path ID 0, Local Path ID 0, version 0

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.4, 10.0.0.7, 10.0.0.3

SR policy color 101, up, not-registered, bsid 24007

Higher IGP metric than best path (path #2)

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

Path #2: Received by speaker 0

Flags: 0xa000000005060005, import: 0x080

Not advertised to any peer

65002

10.0.0.6 C:101 (bsid:24010) (admin 40) (metric 3) from 10.0.0.4 (10.0.0.6), if-handle 0x00000000

Received Label 24002

Origin IGP, metric 0, localpref 100, weight 65000, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 95

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.6, Cluster list: 10.0.0.4

SR policy color 101, up, not-registered, bsid 24010

best of AS 65002, Overall best

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:3

Es gibt zwei konkurrierende BGP-Pfade für zwei verschiedene Endpunkte. Das BGP entscheidet, welcher Pfad gewinnt und in der Routing-Tabelle installiert wird. Dies wiederum entscheidet anhand der Farbe und des Endpunkts, welche SR-Richtlinie installiert wird, um den Datenverkehr an das BGP VPNv4-Präfix weiterzuleiten.

BGP-Pfad mit und ohne Farbe

In Szenario vier ist die Soft Next-Hop-Validierung auf dem Head-End-Router aktiviert, und es erhält zwei BGP-Pfade für ein Präfix, einen mit und einen ohne Farbe. Wenn keine Route für den Next-Hop vorhanden ist, ist der Pfad ohne Farbe nicht zugänglich und gilt nicht für die Rate.

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast | include 10.0.0.9/32

*>i10.0.0.9/32        10.0.0.5 C:101           0    100      0 65002 i

*>i10.0.0.9/32        10.0.0.5 C:101           0    100      0 65002 i

* i10.0.0.9/32        10.0.0.6                 0    100      0 65002 i

Der letzte BGP-Pfad hat kein >, daher ist der Next-Hop nicht zugänglich.

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast rd 65001:3 10.0.0.9/32

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65001:3

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  31           31

Last Modified: Nov  2 10:08:44.948 for 00:08:11

Paths: (2 available, no best path)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

65002

10.0.0.6 (inaccessible) from 10.0.0.3 (10.0.0.6)

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, not-in-vrf

Received Path ID 0, Local Path ID 0, version 0

Extended community: RT:65001:101

Originator: 10.0.0.6, Cluster list: 10.0.0.3, 10.0.0.7, 10.0.0.4

Path #2: Received by speaker 0

Not advertised to any peer

65002

10.0.0.6 (inaccessible) from 10.0.0.4 (10.0.0.6)

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, not-in-vrf

Received Path ID 0, Local Path ID 0, version 0

Extended community: RT:65001:101

Originator: 10.0.0.6, Cluster list: 10.0.0.4

Es wird der BGP-Pfad mit der SR-Richtlinie verwendet.

Wenn jedoch der Next-Hop 10.0.0.6 aufgrund einer Route in der RIB aufgelöst wird, kann dieser Pfad als der beste Pfad abgerufen werden. Wenn keine Farbe angezeigt wird, kann die Option nicht für ODN verwendet werden, und die SR-Richtlinie ist deaktiviert. Die Admin-Distanz dieser Route beträgt jedoch 100, daher ist sie viel höher als der Pfad mit Farbe.

RP/0/RP0/CPU0:PE1#show bgp vrf one 10.0.0.9/32 bestpath-compare

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  47           47

Flags: 0x00043001+0x00000000;

Last Modified: Nov  2 10:30:55.948 for 00:00:21

Paths: (2 available, best #1)

Advertised to CE peers (in unique update groups):

10.1.8.8

Path #1: Received by speaker 0

Flags: 0xa000000005060005, import: 0x080

Advertised to CE peers (in unique update groups):

10.1.8.8

65002

10.0.0.5 C:101 (bsid:24021) (admin 20) (metric 23) from 10.0.0.3 (10.0.0.5), if-handle 0x00000000

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 40

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.3

SR policy color 101, up, not-registered, bsid 24021

best of AS 65002, Overall best

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

Path #2: Received by speaker 0

Flags: 0x2000000000020005, import: 0x0a0

Not advertised to any peer

65002

10.0.0.6 from 10.0.0.4 (10.0.0.6), if-handle 0x00000000

Received Label 24002

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

Received Path ID 0, Local Path ID 0, version 0

Extended community: RT:65001:101

Originator: 10.0.0.6, Cluster list: 10.0.0.4

Higher nexthop admin distance than best path (path #1)

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:3

Szenarien im Detail mit Befehlen anzeigen

Standardverhalten

Gilt für Headend-Router und RR.

Konfiguration:

no nexthop validation color-extcomm sr-policy

no bgp bestpath igp-metric sr-policy

Funktion:

RIB-Validierung (Hard Next-Hop)

BGP verwendet keine Admin-/Metrik aus der SR-Richtlinie.

Die RIB-Validierung wird für den nächsten Hop der Dienstroute durchgeführt.

Wenn es für den Next-Hop keine spezifischere Route als die Standardroute gibt, verfügt die Dienstroute über einen nicht zugreifbaren Next-Hop.

If the RIB metric is available:

RIB metric is used. Route is installed.

If policy is up:

Policy is used.

If policy is not up:

Policy is not used.

If the RIB metric is not available:

Route is not installed.

RP/0/RP0/CPU0:PE1#show bgp vpnv4 unicast rd 65001:2 10.0.0.9/32

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65001:2

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  31           31

Last Modified: Oct 26 14:21:56.714 for 00:01:32

Paths: (1 available, no best path)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24005) (inaccessible) from 10.0.0.3 (10.0.0.5)

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, not-in-vrf

Received Path ID 0, Local Path ID 0, version 0

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.3

SR policy color 101, up, not-registered, bsid 24005

Dies führt auch dazu, dass die Service-Route nicht in die VRF-Instanz importiert wird.

RP/0/RP0/CPU0:PE1#show bgp vrf one 10.0.0.9/32

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  37           37

Last Modified: Oct 26 14:24:36.714 for 00:00:03

Paths: (0 available, no best path)

Not advertised to any peer

Wenn Sie dem Headend-Router eine nicht standardmäßige statische Route hinzufügen, die den Next-Hop der Dienstroute abdeckt, wird dieses Problem behoben. Dies wird häufig in ODN-Netzwerken verwendet.

Diese statische Route deckt den Next-Hop 10.0.0.5 ab und ist keine Standardroute.

router static

address-family ipv4 unicast

10.0.0.0/24 Null0

!

!

Es löst den Next-Hop, der für ODN nicht zugänglich ist.

RP/0/RP0/CPU0:PE1#show bgp vrf one 10.0.0.9/32

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  27           27

Last Modified: Oct 26 14:19:06.714 for 00:00:26

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24005) from 10.0.0.3 (10.0.0.5)

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 22

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.3

SR policy color 101, up, not-registered, bsid 24005

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

Dasselbe gilt für RR: Wenn auf den Next-Hop der Service-Route nicht zugegriffen werden kann, wird die Route nicht in anderen iBGP-Routern wiedergegeben. Die gleiche Problemumgehung einer nicht standardmäßigen statischen Route kann auf einem RR verwendet werden.

RIB-abhängige Validierung mit SR Policy Metric

Gilt für Headend-Router und RR.

Konfiguration:

no nexthop validation color-extcomm sr-policy

bgp bestpath igp-metric sr-policy

Funktion:

Die PCE/Pfad-Admin- und metrischen Werte werden an BGP übergeben und für die Berechnung des besten Pfads verwendet.

Perform RIB validation (hard next-hop).

If NH is reachable in RIB:

If policy is up:

Use policy metric.

If policy is down:

Use RIB metric.

Headend-Router

Wenn der Next-Hop in der RIB nicht erreichbar ist, ist der Next-Hop für die Service-Route nicht erreichbar, und sie wird nicht installiert.

Wenn der Next-Hop erreichbar ist (über eine statische Route möglich), wird die Service-Route installiert, jetzt mit den Werten Admin und Metric.

RP/0/RP0/CPU0:PE1#show bgp vrf one 10.0.0.9/32

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  43           43

Last Modified: Oct 26 14:42:54.714 for 00:00:03

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24005) (admin 20) (metric 30) from 10.0.0.3 (10.0.0.5)

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 43

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.3

SR policy color 101, up, not-registered, bsid 24005

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

Die Richtlinie ist gültig.

Wenn die Richtlinie ausfällt, während die RIB eine Route für den Next-Hop hat, wird die Service-Route installiert. Die Service-Route wird jedoch nicht in der CEF-Tabelle aufgelöst. Die SR-Richtlinie stellt nicht mehr die Konnektivität (den MPLS-Label-Stack) zum Erreichen des Endpunkts bereit.

RP/0/RP0/CPU0:PE1#show bgp vrf one 10.0.0.9/32

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                  57           57

Last Modified: Oct 26 15:13:46.714 for 00:01:39

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

65002

10.0.0.5 from 10.0.0.3 (10.0.0.5)

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 48

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.3

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

Die Route ist installiert, CEF für diese Service-Route wird jedoch ohne die SR-Richtlinie nicht aufgelöst.

RP/0/RP0/CPU0:PE1#show cef vrf one 10.0.0.9/32

10.0.0.9/32, version 36, drop adjacency, internal 0x5000001 0x30 (ptr 0xe3abf78) [1], 0x600 (0xe54a068), 0xa08 (0xec42558)

Updated Oct 26 15:13:47.003

Prefix Len 32, traffic index 0, precedence n/a, priority 3

gateway array (0xe3b26b8) reference count 2, flags 0x3a, source rib (7), 0 backups

[3 type 1 flags 0x88401 (0xec85888) ext 0x0 (0x0)]

LW-LDI[type=1, refc=1, ptr=0xe54a068, sh-ldi=0xec85888]

gateway array update type-time 3 Oct 26 15:16:24.524

LDI Update time Oct 26 14:42:54.404

LW-LDI-TS Oct 26 15:13:47.003

via 10.0.0.5/32, 0 dependencies, recursive [flags 0x6000]

path-idx 0 NHID 0x0 [0xd649400 0x0]

recursion-via-/32

next hop VRF - 'default', table - 0xe0000000

unresolved

labels imposed {24002}

Load distribution: 0 (refcount 3)

Hash  OK  Interface                 Address

0     Y   recursive                 drop

RR-Router:

Wenn die SR-Richtlinie aktiv ist oder nicht, und wenn die Erreichbarkeit der RIB vorhanden ist, kündigt der RR die Service-Route an.

SR Policy Dependent Validation with RIB Metric

Gilt für Headend-Router.

Konfiguration:

nexthop validation color-extcomm sr-policy

no bgp bestpath igp-metric sr-policy

Funktion:

Die PCE/Pfad-Admin- und Metrik-Werte werden nicht an BGP übergeben.

If the RIB metric is available:

RIB metric is used. Route is installed.

If policy is up:

Policy is used.

If policy is not up:

Policy is not used.

If the RIB metric is not available:

Route is not installed.

SR Policy Dependent Validation mit SR Policy Metric

Gilt für Headend-Router.

Konfiguration:

nexthop validation color-extcomm sr-policy

bgp bestpath igp-metric sr-policy

Funktion:

Do not perform RIB validation (soft next-hop).  RIB reachability is not needed.

If policy is up:

Use policy metric and validation, even if RIB reachability is present.

If policy is down:

Use RIB validation and metric if available. If not available, the route is not installed.

Wenn die SR-Richtlinie verfügbar ist:

RP/0/RP0/CPU0:PE1#show bgp vrf one 10.0.0.9/32

BGP routing table entry for 10.0.0.9/32, Route Distinguisher: 65000:1

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 101          101

Last Modified: Oct 28 13:32:24.714 for 00:25:39

Paths: (1 available, best #1)

Not advertised to any peer

Path #1: Received by speaker 0

Not advertised to any peer

65002

10.0.0.5 C:101 (bsid:24008) (admin 30) (metric 30) from 10.0.0.3 (10.0.0.5)

Received Label 24002

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported

Received Path ID 0, Local Path ID 1, version 99

Extended community: Color:101 RT:65001:101

Originator: 10.0.0.5, Cluster list: 10.0.0.3

SR policy color 101, up, not-registered, bsid 24008

Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65001:2

SR Policy Dependent Validation with RIB Metric and SR Policy Not Used for Best Path-Berechnung

Gilt für RR-Router.

Konfiguration:

nexthop validation color-extcomm disable

no bgp bestpath igp-metric sr-policy

Funktion:

Der erste Befehl bedeutet, dass die Next-Hop-Erreichbarkeitsprüfung für Farb-Excomm-Pfade deaktiviert ist. Die Erreichbarkeit des nächsten Hop wird streng überprüft. Die Validierungsprüfung für die Soft Next-Hop-Erreichbarkeit kann deaktiviert werden, da es sich bei diesem Router um einen RR handelt und nur die BGP-Service-Routen abbildet. Der RR installiert für diese keine SR-Richtlinie. Ohne diesen Befehl wird eine Soft Check durchgeführt. Wenn in der Routing-Tabelle keine andere Route für den Next-Hop als die Standardroute vorhanden ist, ist der Next-Hop nicht zugänglich. Die Route wird dann nicht wiedergegeben.

Der zweite Befehl bedeutet, dass die SR-Richtlinie nicht für die Berechnung des besten BGP-Pfads verwendet wird. Daher wird die Admin-/Metrik der SR-Richtlinie nicht verwendet. Die RIB-Metrik wird verwendet, wenn sich der Next-Hop in der RIB befindet. Andernfalls wird die Gateway-Metrik 0 (die Next-Hop-IGP-Metrik) verwendet.

SR Policy Dependent Validation with RIB Metric and SR Policy für die Berechnung des besten Pfads

Gilt für RR-Router.

Konfiguration:

nexthop validation color-extcomm disable

bgp bestpath igp-metric sr-policy

Funktion:

Der erste Befehl bedeutet, dass die Next-Hop-Erreichbarkeitsprüfung für Farb-Excomm-Pfade deaktiviert ist. Die Erreichbarkeit des nächsten Hop wird streng überprüft. Die Validierungsprüfung für die Soft Next-Hop-Erreichbarkeit kann deaktiviert werden, da es sich um einen RR handelt, der nur die BGP-Service-Routen widerspiegelt. Der RR installiert für diese keine SR-Richtlinie. Ohne diesen Befehl wird eine Soft Check durchgeführt. Wenn in der Routing-Tabelle keine andere Route für den Next-Hop als die Standardroute vorhanden ist, ist der Next-Hop nicht zugänglich. Die Route wird dann nicht wiedergegeben.

Der zweite Befehl bedeutet, dass die SR-Richtlinie für die Berechnung des besten BGP-Pfads verwendet wird.

If policy is up:

Use policy metric and validation, even if RIB reachability is present

If policy is down

Use RIB validation and metric if available

If RIB validation and metric is not available:

use the gateway metric 0