Fehlerbehebung beim Inline-BGP VPNv4-RR mit demselben Route-Distinguisher und "cef encap-sharing disabled"

Download-Optionen

PDF (446.8 KB)
Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub (361.8 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle) (338.4 KB)
Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen

Aktualisiert:13. April 2022

Dokument-ID:217778

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Inhalt

Einleitung

Hintergrundinformationen

Problem

Szenario 1. Inline-RR und -PE mit separatem RD-Wert

Szenario 2. Inline-RR und -PE mit demselben RD-Wert

Szenario 3. In-Line-RR und PE mit demselben RD-Wert und 'cef encap sharing disable' konfiguriert

Lösung

Einleitung

Dieses Dokument beschreibt das Verhalten des Cisco Systems Network Convergence System (NCS) 540 bei Verwendung als Border Gateway Protocol (BGP) VPNv4 in-line Route Reflector (RR) und Provider Edge (PE).

Hintergrundinformationen

Im Mittelpunkt dieses Dokuments steht das Verhalten von NCS 540, das in einer Laborumgebung mit der Cisco IOS® XR Softwareversion 7.3.1 verifiziert wurde. Das in diesem Dokument beschriebene Verhalten gilt für alle auf DNX basierenden Plattformen und Softwareversionen der NCS 5500- oder NCS 500-Serie.

Problem

Beispiel: NCS540 wird mit einer VRF-Instanz (Virtual Routing and Forwarding) konfiguriert und verwendet denselben RD-Wert wie Remote-PE-RR-Client-Knoten. Bei Verwendung als Inline-RR- und -PE-Rolle und Konfiguration mit demselben RD-Wert wie Remote-PE-RR-Client-Knoten wird das oberste Label nicht vor der Weiterleitung angehalten, was zu Paketverlusten am Ausgangs-PE führt.

Szenario 1. Inline-RR und -PE mit separatem RD-Wert

Das Bild zeigt das Szenario von Device Under Test (DUT), das als Inline-RR und -PE für BGP VPNv4 mit einem eindeutigen RD-Wert für VRF VRF1 konfiguriert ist, als der von den anderen PE-Knoten verwendete.

DUT - in-line RR and PE with distinct RD value Bild 1 - DUT - Inline-RR und PE mit eigenem RD-Wert.

Die IP-Verbindung zwischen Eingangs-PE (IP 10.51.232.21) und Ausgangs-PE (10.51.232.145) innerhalb von VRF VRF1 wird hergestellt, wobei Pakete erfolgreich zwischen PE-Knoten weitergeleitet werden, wie durch Ping und Traceroute-Befehle ausgegeben:

INGRESS_PE#ping vrf vrf1 10.51.232.145 source 10.51.232.21
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.51.232.145, timeout is 2 seconds:
Packet sent with a source address of 10.51.232.21
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

INGRESS_PE#traceroute vrf vrf1 10.51.232.145 source 10.51.232.21
Type escape sequence to abort.
Tracing the route to 10.51.232.145
VRF info: (vrf in name/id, vrf out name/id)
  1 10.51.5.161 [MPLS: Label 24017 Exp 0] 4 msec 8 msec 0 msec
  2 10.9.255.207 [MPLS: Labels 23481/24008 Exp 0] 4 msec 0 msec 0 msec
  3 10.9.255.217 0 msec *  4 msec

Das DUT ist ein Inline-RR für BGP VPNv4 und ein PE mit lokal konfiguriertem VRF, der jedoch einen eigenen RD-Wert (65000:104) verwendet als der von den PE-RR-Client-Knoten verwendete Wert (65000:104830). Wie die Ausgaben zeigen, importiert das DUT alle Routen und tauscht VPNv4-Label entsprechend aus:

RP/0/RP0/CPU0:DUT-N540#show bgp vpnv4 unicast           
BGP router identifier 10.9.255.8, local AS number 65000
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65000:104 (default for vrf vrf1)
*>i0.0.0.0/0          10.48.255.30            10    100      0 ?
*>i10.51.232.20/30    10.51.5.5                0    100      0 ?
*>i10.51.232.145/32   10.48.255.30             0    100      0 ?
Route Distinguisher: 65000:104830
*>i0.0.0.0/0          10.48.255.30            10    100      0 ?
*>i10.51.232.20/30    10.51.5.5                0    100      0 ?
*>i10.51.232.145/32   10.48.255.30             0    100      0 ?
<snip>

RP/0/RP0/CPU0:DUT-N540#show bgp vpnv4 unicast rd 65000:104 labels
BGP router identifier 10.9.255.8, local AS number 65000
<snip>
   Network            Next Hop        Rcvd Label      Local Label
Route Distinguisher: 21497:104 (default for vrf vrf1)
*>i0.0.0.0/0          10.48.255.30    24008           nolabel
*>i10.51.232.20/30    10.51.5.5       17              nolabel
*>i10.51.232.145/32   10.48.255.30    24008           nolabel
<snip>

RP/0/RP0/CPU0:DUT-N540#show bgp vpnv4 unicast rd 65000:104830 labels
BGP router identifier 10.9.255.8, local AS number 65000
<snip>
   Network            Next Hop        Rcvd Label      Local Label
Route Distinguisher: 21497:104830
*>i0.0.0.0/0          10.48.255.30    24008           24018
*>i10.51.232.20/30    10.51.5.5       17              24019
*>i10.51.232.145/32   10.48.255.30    24008           24017
<snip>

Als zusätzlicher Verweis im aktuellen Szenario von Inline-RR und -PE, die einen eigenen RD-Wert verwenden, wird die vollständige Ausgabe für das Präfix 10.51.232.145/32 angezeigt, das vom Knoten EGRESSION_PE empfangen wurde:

RP/0/RP0/CPU0:DUT-N540#show bgp vpnv4 unicast rd 65000:104 10.51.232.145
BGP routing table entry for 10.51.232.145/32, Route Distinguisher: 65000:104
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                115         115
Last Modified: Feb  8 11:00:27.032 for 2w6d
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local, (received & used)
    10.48.255.30 (metric 20) from 10.48.255.30 (10.48.255.30)
      Received Label 24008 
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 1, Local Path ID 1, version 115
      Extended community: RT:65000:104830 RT:65000:105130
      Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65000:104830

RP/0/RP0/CPU0:DUT-N540#show bgp vpnv4 unicast rd 65000:104830 10.51.232.145
BGP routing table entry for 10.51.232.145/32, Route Distinguisher: 65000:104830
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                113         113
    Local Label: 24017
Last Modified: Feb  8 11:00:22.032 for 2w6d
Paths: (1 available, best #1)
  Advertised to peers (in unique update groups):
    10.51.5.5      
  Path #1: Received by speaker 0
  Advertised to peers (in unique update groups):
    10.51.5.5      
  Local, (received & used)
    10.48.255.30 (metric 20) from 10.48.255.30 (10.48.255.30)
      Received Label 24008 
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, not-in-vrf
      Received Path ID 1, Local Path ID 1, version 113
      Extended community: RT:65000:104830 RT:65000:10513

Die Pakete, die von INGRESS_PE (10.51.232.21) stammen und für den AUSGANGS-PE (10.51.232.145) bestimmt sind, sind Label-Switched und am obersten DUT-Label {24017} durch {23481 2 24000 ausgetauscht. 8} gemäß programmierten Weiterleitungsdetails:

RP/0/RP0/CPU0:DUT-N540#show cef vrf vrf1 10.51.232.145/32 detail         
10.51.232.145/32, version 96, internal 0x5000001 0x0 (ptr 0x8ce0d034) [1], 0x0 (0x8b941ee0), 0xa08 (0x8cacb5f8)
 Updated Feb 25 12:18:36.885
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
  gateway array (0x8b7b6fd0) reference count 2, flags 0x38, source rib (7), 0 backups
                [3 type 1 flags 0x8441 (0x8cb11e28) ext 0x0 (0x0)]
  LW-LDI[type=1, refc=1, ptr=0x8b941ee0, sh-ldi=0x8cb11e28]
  gateway array update type-time 1 Feb 25 12:18:36.885
 LDI Update time Feb 25 12:18:36.885
 LW-LDI-TS Feb 25 12:18:36.885
   via 10.48.255.30/32, 7 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x8d37e3b8 0x0]
    recursion-via-/32
    next hop VRF - 'default', table - 0xe0000000
    next hop 10.48.255.30/32 via 23481/0/21
     next hop 10.9.255.207/32 BE100        labels imposed {23481 24008}

    Load distribution: 0 (refcount 3)

    Hash  OK  Interface                 Address
    0     Y   recursive                 23481/0

Bei P-NODE wird bei der Konfiguration von NetFlow für die Übereinstimmung des vom INGRESS_PE-Knoten eingehenden Datenverkehrs der erwartete Label-Stack {23481 24008} beobachtet, wie in der Ausgabe der Flussüberwachung gezeigt:

RP/0/RP0/CPU0:P_NODE#show flow monitor MONITOR_MAP_MPLS cache location 0/RP0/CPU0
<snip>
LabelType Prefix/Length      Label1-EXP-S     Label2-EXP-S     Label3-EXP-S   InputInterface  OutputInterface ForwardStatus        FirstSwitched   LastSwitched    ByteCount    PacketCount  Dir SamplerID  IPV4SrcAddr      IPV4DstAddr      IPV4TOS  IPV4Prot L4SrcPort  L4DestPort L4TCPFlags   InputVRFID                        OutputVRFID                       BGPNextHopV4    
Unknown 10.48.255.30/32       23481-0-0        24008-0-1           -          
BE100           BE1             Fwd                  33 17:49:08:468 33 17:49:11:765 108000       1000         Ing 1          10.51.232.21     10.51.232.145    0        icmp     0          0          0            default                           default                           0.0.0.0          
<snip>

Szenario 2. Inline-RR und -PE mit demselben RD-Wert

Das Bild zeigt das problematische Szenario mit DUT, das als Inline-RR und -PE für BGP VPNv4 konfiguriert, aber jetzt mit demselben RD-Wert für VRF VRF VRF1 - 65000:10430 - konfiguriert ist wie die anderen PE-Knoten.

DUT - in-line RR and PE with same RD value Bild 2 - DUT - Inline-RR und -PE mit demselben RD-Wert.

In diesem Szenario schlägt die IP-Verbindung zwischen dem Eingangs-PE (IP 10.51.232.21) und dem Ausgangs-PE (10.51.232.145) in VRF VRF1 fehl, wie in der Ausgabe der Ping- und Traceroute-Befehle dargestellt:

INGRESS_PE#ping vrf vrf1 10.51.232.145 source 10.51.232.21
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.51.232.145, timeout is 2 seconds:
Packet sent with a source address of 10.51.232.21
.....
Success rate is 0 percent (0/5)

INGRESS_PE#traceroute vrf vrf1 10.51.232.145 source 10.51.232.21
Type escape sequence to abort.
Tracing the route to 10.51.232.145
VRF info: (vrf in name/id, vrf out name/id)
  1 10.51.5.161 [MPLS: Label 24013 Exp 0] 4 msec 4 msec 0 msec
  2  *  *  *
<snip>

Bei DUT wird die Problemursache weder von BGP- noch von programmierten Weiterleitungsausgängen wahrgenommen, wobei alle Ausgänge als erwartet angesehen werden:

RP/0/RP0/CPU0:DUT-N540#show bgp vpnv4 unicast
BGP router identifier 10.9.255.8, local AS number 65000
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65000:104830 (default for vrf vrf1)
*>i0.0.0.0/0          10.48.255.30            10    100      0 ?
*>i10.51.232.20/30    10.51.5.5                0    100      0 ?
*>i10.51.232.145/32   10.48.255.30             0    100      0 ?
<snip>

RP/0/RP0/CPU0:DUT-N540#show bgp vpnv4 unicast rd 65000:104830 labels     
BGP router identifier 10.9.255.8, local AS number 65000
<snip>
   Network            Next Hop        Rcvd Label      Local Label
Route Distinguisher: 21497:104830 (default for vrf vrf1)
*>i0.0.0.0/0          10.48.255.30    24008           24020
*>i10.51.232.20/30    10.51.5.5       17              24016
*>i10.51.232.145/32   10.48.255.30    24008           24013
<snip>

Ähnlich wie im vorherigen Abschnitt und als zusätzliche Referenz im aktuellen Szenario von Inline-RR und -PE unter Verwendung desselben RD-Werts wird die vollständige Ausgabe für das Präfix 10.51.232.145/32 angezeigt, das vom Knoten EGRESSION_PE empfangen wurde:

RP/0/RP0/CPU0:DUT-N540#show bgp vpnv4 unicast rd 65000:104830 10.51.232.145
BGP routing table entry for 10.51.232.145/32, Route Distinguisher: 65000:104830
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                134         134
    Local Label: 24013
Last Modified: Feb 28 18:03:20.032 for 00:04:50
Paths: (1 available, best #1)
  Advertised to peers (in unique update groups):
    10.51.5.5      
  Path #1: Received by speaker 0
  Advertised to peers (in unique update groups):
    10.51.5.5      
  Local, (received & used)
    10.48.255.30 (metric 20) from 10.48.255.30 (10.48.255.30)
      Received Label 24008 
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
      Received Path ID 1, Local Path ID 1, version 134
      Extended community: RT:65000:104830 RT:65000:105130
      Source AFI: VPNv4 Unicast, Source VRF: vrf1, Source Route Distinguisher: 65000:10483

Die Pakete, die von INGRESS_PE (10.51.232.21) stammen und für den AUSGANGS-PE (10.51.232.145) bestimmt sind, sind Label-Switched und erwarten, dass diese Pakete beim DUT das oberste Label {24013} von {2348 1 24008} gemäß programmierten Weiterleitungsdetails:

RP/0/RP0/CPU0:DUT-N540#show cef vrf vrf1 10.51.232.145/32 detail 
10.51.232.145/32, version 107, internal 0x1000001 0x0 (ptr 0x8ce0d13c) [1], 0x0 (0x8b946be8), 0xa08 (0x8cacb7d8)
 Updated Feb 28 18:03:19.778
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
  gateway array (0x8b7b71a0) reference count 6, flags 0x78, source rib (7), 0 backups
                [3 type 5 flags 0x8441 (0x8cb125d8) ext 0x0 (0x0)]
  LW-LDI[type=5, refc=3, ptr=0x8b946be8, sh-ldi=0x8cb125d8]
  gateway array update type-time 1 Feb 28 18:03:19.778
 LDI Update time Feb 28 18:03:19.778
 LW-LDI-TS Feb 28 18:03:19.778
   via 10.48.255.30/32, 7 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x8d37e3b8 0x0]
    recursion-via-/32
    next hop VRF - 'default', table - 0xe0000000
    next hop 10.48.255.30/32 via 23481/0/21
     local label 24013
     next hop 10.9.255.207/32 BE100        labels imposed {23481 24008}

    Load distribution: 0 (refcount 3)

    Hash  OK  Interface                 Address
    0     Y   recursive                 23481/0

Darüber hinaus zeigt eine Triage bei P_NODE mit Netflow, die so konfiguriert ist, dass der von INGRESS_PE stammende Eingangs-Datenverkehr mit der Weiterleitung des Pakets durch DUT übereinstimmt. Wie in der angezeigten Ausgabe hervorgehoben, wird das lokale Label 24013 vor dem Weiterleiten des Pakets nicht vom DUT angehalten. Daher erhält P_NODE einen gestapelten MPLS-Frame mit drei Labeln {23481 24008 24013} anstelle des erwarteten zweistelligen Stacks {23481 24008}. Beim obersten Label "P_NODE" wird das Label "23481" entfernt, und das Paket wird an den Label-Stack "AUSGANG_PE" weitergeleitet {24008 24013}, was zu einem Paketverlust bei "EGPRESS_PE" führt.

RP/0/RP0/CPU0:P_NODE#show flow monitor MONITOR_MAP_MPLS cache location 0/RP0/CPU0
<snip>
LabelType Prefix/Length      Label1-EXP-S     Label2-EXP-S     Label3-EXP-S     InputInterface  OutputInterface ForwardStatus        FirstSwitched   LastSwitched    ByteCount    PacketCount  Dir SamplerID  IPV4SrcAddr      IPV4DstAddr      IPV4TOS  IPV4Prot L4SrcPort  L4DestPort L4TCPFlags   InputVRFID                        OutputVRFID                       BGPNextHopV4    
Unknown 10.48.255.30/32       23481-0-0        24008-0-0        24013-0-1       BE100           BE1             Fwd                  33 17:51:40:181 33 17:51:41:521 112000       1000         Ing 1          10.51.232.21     10.51.232.145    0        icmp     0          0          0            default                           default                           0.0.0.0         
<snip>

Szenario 3. In-Line-RR und PE mit demselben RD-Wert und 'cef encap sharing disable' konfiguriert

Zusätzlich zum vorherigen Szenario wird die Deaktivierung der Gruppenfreigabe für cef konfiguriert, und für jedes Präfix werden separate Hardwareressourcen zugewiesen.

RP/0/RP0/CPU0:DUT-N540(config)#cef encap-sharing disable
Warning: The command will clear the forwarding table.Traffic loss is expected during rebuilding.
RP/0/RP0/CPU0:DUT-N540(config)#commit

Das Bild zeigt das Szenario von Inline-RR und -PE, die mit demselben RD konfiguriert sind und für die Ce-Encap-Freigabe deaktiviert ist.

DUT - in-line RR and PE with same RD value and 'cef encap-sharing disable' configured Bild 3 - DUT - Inline-RR und -PE mit demselben RD-Wert und konfigurierter "cef encap-sharing disable".

Die IP-Verbindung zwischen dem Eingangs-PE (IP 10.51.232.21) und dem Ausgangs-PE (10.51.232.145) innerhalb von VRF VRF1 wird wiederhergestellt. Die Pakete werden erneut erfolgreich zwischen PE-Knoten weitergeleitet, wie in den Befehlsausgaben Ping und Traceroute gezeigt:

INGRESS_PE#ping vrf vrf1 10.51.232.145 source 10.51.232.21 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 10.51.232.145, timeout is 2 seconds:
Packet sent with a source address of 10.51.232.21
<snip>
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/3/12 ms

INGRESS_PE#traceroute vrf vrf1 10.51.232.145 source 10.51.232.21
Type escape sequence to abort.
Tracing the route to 10.51.232.145
VRF info: (vrf in name/id, vrf out name/id)
  1 10.51.5.161 [MPLS: Label 24013 Exp 0] 0 msec 0 msec 0 msec
  2 10.9.255.207 [MPLS: Labels 23481/24008 Exp 0] 4 msec 4 msec 0 msec
  3 10.9.255.217 0 msec *  0 msec

Bei P_NODE zeigt die NetFlow-Ausgabe an, dass DUT das Paket jetzt mit dem erwarteten Label-Stack {23481 24008} weiterleitet. P_NODE entfernt das oberste Label 23481 und leitet das Paket an den Knoten EGRESP_PE mit dem Label-Stack {24008} weiter, der es EGRESSION_PE ermöglicht, gekapselte Pakete in VRF1 abzugleichen und erfolgreich an das endgültige Ziel weiterzuleiten.

RP/0/RP0/CPU0:P_NODE#show flow monitor MONITOR_MAP_MPLS cache location 0/RP0/CPU0
Cache summary for Flow Monitor MONITOR_MAP_MPLS:
<snip>
LabelType Prefix/Length      Label1-EXP-S     Label2-EXP-S     Label3-EXP-S     InputInterface  OutputInterface ForwardStatus        FirstSwitched   LastSwitched    ByteCount    PacketCount  Dir SamplerID  IPV4SrcAddr      IPV4DstAddr      IPV4TOS  IPV4Prot L4SrcPort  L4DestPort L4TCPFlags   InputVRFID                        OutputVRFID                       BGPNextHopV4    
Unknown 10.48.255.30/32       23481-0-0        24008-0-1           -          BE100           BE1             Fwd                  33 18:03:14:211 33 18:03:17:505 108000       1000         Ing 1          10.51.232.21     10.51.232.145    0        icmp     0          0          0            default                           default                           0.0.0.0         
<snip>

Bei Deaktivierung der Konfiguration der cef-Encap-Freigabe werden für jedes Präfix zusätzliche Hardwareressourcen zugewiesen. Die erforderlichen Weiterleitungsinformationen sind beim DUT vorhanden, um Pakete in diesem speziellen Szenario von Inline-RR mit demselben RD-Wert korrekt weiterzuleiten. Um die Unterscheidung in programmierten Weiterleitungsdetails hervorzuheben, beachten Sie die beiden Ausgaben von show cef vrf vrf1 10.51.232.145/32 Hardware-Ausgangspunkt 0/RP0/CPU0 und beachten Sie die zusätzlichen Informationen, die enthalten sind, wenn cef encap-sharing disable konfiguriert wurde.

Wie im Szenario von Inline-RR und -PE mit demselben RD-Wert, jedoch ohne konfigurierte "cef encap-sharing disable" (Standard):

!
! --- without 'cef encap-sharing disable' (default)
! --- note highlighted (bold) sections
!
RP/0/RP0/CPU0:DUT-N540#show cef vrf vrf1 10.51.232.145/32 hardware egress location 0/RP0/CPU0
10.51.232.145/32, version 107, internal 0x1000001 0x0 (ptr 0x8ce0d13c) [1], 0x0 (0x8b946be8), 0xa08 (0x8cacb7d8)
 Updated Feb 28 18:03:19.778
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
  gateway array (0x8b7b71a0) reference count 6, flags 0x78, source rib (7), 0 backups
                [3 type 5 flags 0x8441 (0x8cb125d8) ext 0x0 (0x0)]
  LW-LDI[type=5, refc=3, ptr=0x8b946be8, sh-ldi=0x8cb125d8]
  gateway array update type-time 1 Feb 28 18:03:19.778
 LDI Update time Feb 28 18:03:19.778
 LW-LDI-TS Feb 28 18:03:19.778
   via 10.48.255.30/32, 7 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x8d37e3b8 0x0]
    recursion-via-/32
    next hop VRF - 'default', table - 0xe0000000
    next hop 10.48.255.30/32 via 23481/0/21
     local label 24013
     next hop 10.9.255.207/32 BE100        labels imposed {23481 24008}

 Show-data Print at RPLC

 LEAF - HAL pd context :
 sub-type : IPV4, ecd_marked:0, has_collapsed_ldi:0
 collapse_bwalk_required:0, ecdv2_marked:0,
HW Walk:
LEAF:
    PI:0x8ce0d13c PD:0x8ce0d1dc rev:892768 type: IPV4 (0)
    LEAF location: LEM
    FEC key: 0x57f40001104

    LWLDI:
        PI:0x8b946be8 PD:0x8b946c28 rev:892767 p-rev:892766  ldi type:IMP_EOS0_EOS1
        FEC key: 0x57f40001104 fec index: 0x0(0) num paths:1, bkup paths: 0

 REC-SHLDI HAL PD context :
ecd_marked:0, collapse_bwalk_required:0, load_shared_lb:0

    RSHLDI:
        PI:0x8cb125d8 PD:0x8cb126a8 rev:892766 dpa-rev:41494702 flag:0x1
        FEC key: 0x57f40001104 fec index: 0x2000ffcc(65484) num paths: 1
        p-rev:854950
        Path:0 fec index: 0x2000ffcc(65484) DSP fec index: 0x2000ffca(65482)
                MPLS EEI push label: 24008

 LEAF - HAL pd context :
 sub-type : MPLS, ecd_marked:0, has_collapsed_ldi:0
 collapse_bwalk_required:0, ecdv2_marked:0,
HW Walk:
LEAF:
    PI:0x8d37e3b8 PD:0x8d37e458 rev:854953 type: MPLS (2)
    LEAF location: LEM
    FEC key: 0

    LWLDI:
        PI:0x8b945288 PD:0x8b9452c8 rev:854950 p-rev:854949  ldi type:IMP_EOS0_EOS1
        FEC key: 0x51140001104 fec index: 0x0(0) num paths:1, bkup paths: 0
        IMP LDI:
        IMP pattern:3
        PI:0x8b945288 PD:0x8b9452c8 rev:854950 p-rev:854949
        FEC key: 0x51240001104 fec index: 0x2000ffca(65482) num paths:1
        Path:0  fec index: 0x2000ffca(65482) DSP:0xc000001
                MPLS encap key: 0xf1b0000040014822 MPLS encap id: 0x40014822 Remote: 0

        SHLDI:
            PI:0x8cb10718 PD:0x8cb107e8 rev:854949 dpa-rev:39755988 flag:0x0
            FEC key: 0x51140001104 fec index: 0x2000ffcb(65483) num paths: 1 bkup paths: 0
            p-rev:72522
            Path:0 fec index: 0x2000ffcb(65483) DSP:0xc000001 Dest fec index: 0x0(0)

            TX-NHINFO:
                PI: 0x8d11fad0 PD: 0x8d11fb50 rev:72522 dpa-rev:3303803 Encap hdl: 0x8cd16098
                Encap id: 0x40010003 Remote: 0 L3 int: 1579 flags: 0x407
                npu_mask: 0x1 DMAC: 5c:5a:c7:ff:78:84

    Load distribution: 0 (refcount 3)

    Hash  OK  Interface                 Address
    0     Y   recursive                 23481/0

Wie im Szenario von Inline-RR und -PE mit demselben RD-Wert und cef-Encap-Freigabe deaktiviert konfiguriert:

!
! --- with 'cef encap-sharing disable'
! --- note highlighted (bold) sections for the extra and additional forwarding information included
!
RP/0/RP0/CPU0:DUT-N540#show cef vrf vrf1 10.51.232.145/32 hardware egress location 0/RP0/CPU0
10.51.232.145/32, version 127, internal 0x1000001 0x0 (ptr 0x8ce0ffa4) [1], 0x0 (0x8b948630), 0xa08 (0x8cacb5f8)
 Updated Feb 28 18:26:25.775
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
  gateway array (0x8b7b5f80) reference count 3, flags 0x78, source rib (7), 0 backups
                [2 type 5 flags 0x8441 (0x8cb14c48) ext 0x0 (0x0)]
  LW-LDI[type=5, refc=3, ptr=0x8b948630, sh-ldi=0x8cb14c48]
  gateway array update type-time 1 Feb 28 18:26:25.775
 LDI Update time Feb 28 18:26:25.775
 LW-LDI-TS Feb 28 18:26:25.779
   via 10.48.255.30/32, 11 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x8d37e3b8 0x0]
    recursion-via-/32
    next hop VRF - 'default', table - 0xe0000000
    next hop 10.48.255.30/32 via 23481/0/21
     local label 24013
     next hop 10.9.255.207/32 BE100        labels imposed {23481 24008}

 Show-data Print at RPLC

 LEAF - HAL pd context :
 sub-type : IPV4, ecd_marked:0, has_collapsed_ldi:0
 collapse_bwalk_required:0, ecdv2_marked:0,
HW Walk:
LEAF:
    PI:0x8ce0ffa4 PD:0x8ce10044 rev:893768 type: IPV4 (0)
    LEAF location: LEM
    FEC key: 0x5ae40001104

    LWLDI:

        LSP pattern:3
        PI:0x8b948630 PD:0x8b948670 rev:893767 p-rev:893766  ldi type:IMP_EOS0_EOS1
        FEC key: 0x5af40001104 fec index: 0x2000ffbf(65471) num paths:1, bkup paths: 0
        Path:0  fec index: 0x2000ffbf(65471) DSP fec index:0x20000001(1)
                MPLS encap key: 0xf1b000004001482f MPLS encap id: 0x4001482f Remote: 0
        IMP LDI:
        IMP pattern:3
        PI:0x8b948630 PD:0x8b948670 rev:893767 p-rev:893766
        FEC key: 0x5ae40001104 fec index: 0x2000ffc0(65472) num paths:1
        Path:0  fec index: 0x2000ffc0(65472) DSP fec index: 0x20000001(1)
                MPLS encap key: 0xf1b000004001482e MPLS encap id: 0x4001482e Remote: 0

 REC-SHLDI HAL PD context :
ecd_marked:0, collapse_bwalk_required:0, load_shared_lb:0

    RSHLDI:
        PI:0x8cb14c48 PD:0x8cb14d18 rev:893766 dpa-rev:41503635 flag:0x1
        FEC key: 0x5ac40001104 fec index: 0x2000ffe0(65504) num paths: 1
        p-rev:893704
        Indirection ECMP FEC key: 0x5ad20001104 fec index: 0x20000001(1)
        Path:0 fec index: 0x2000ffe0(65504) DSP fec index: 0x2000ffca(65482)

 LEAF - HAL pd context :
 sub-type : MPLS, ecd_marked:0, has_collapsed_ldi:0
 collapse_bwalk_required:0, ecdv2_marked:0,
HW Walk:
LEAF:
    PI:0x8d37e3b8 PD:0x8d37e458 rev:893707 type: MPLS (2)
    LEAF location: LEM
    FEC key: 0

    LWLDI:
        PI:0x8b9451a0 PD:0x8b9451e0 rev:893704 p-rev:893703  ldi type:IMP_EOS0_EOS1
        FEC key: 0x59f40001104 fec index: 0x0(0) num paths:1, bkup paths: 0
        IMP LDI:
        IMP pattern:3
        PI:0x8b9451a0 PD:0x8b9451e0 rev:893704 p-rev:893703
        FEC key: 0x5a040001104 fec index: 0x2000ffca(65482) num paths:1
        Path:0  fec index: 0x2000ffca(65482) DSP:0xc000001
                MPLS encap key: 0xf1b0000040014822 MPLS encap id: 0x40014822 Remote: 0

        SHLDI:
            PI:0x8cb112a0 PD:0x8cb11370 rev:893703 dpa-rev:41503599 flag:0x0
            FEC key: 0x59f40001104 fec index: 0x2000ffcb(65483) num paths: 1 bkup paths: 0
            p-rev:72522
            Path:0 fec index: 0x2000ffcb(65483) DSP:0xc000001 Dest fec index: 0x0(0)

            TX-NHINFO:
                PI: 0x8d11fad0 PD: 0x8d11fb50 rev:72522 dpa-rev:3303803 Encap hdl: 0x8cd16098
                Encap id: 0x40010003 Remote: 0 L3 int: 1579 flags: 0x407
                npu_mask: 0x1 DMAC: 5c:5a:c7:ff:78:84

    Load distribution: 0 (refcount 2)

    Hash  OK  Interface                 Address
    0     Y   recursive                 23481/0

Lösung

Wie in diesem Dokument beschrieben, besteht die Lösung für eine unsachgemäße Label-Aktion des obersten Labels, das nicht von einem Inline-RR mit demselben RD-Wert überlagert wird, darin, die Deaktivierung der cef-Encap-Freigabe zu konfigurieren. Diese Konfiguration ist in diesem speziellen Szenario obligatorisch und erzwingt, dass für jedes Präfix separate Hardwareressourcen zugewiesen werden, wodurch eine ordnungsgemäße Label-Aktion und Weiterleitung am Inline-RR-Knoten gewährleistet wird.

Vor dem Commit der Konfiguration muss die Nutzung der verfügbaren Ressourcen bewertet werden, um den Ressourcenzustand nach dem Commit des Befehls vorherzusehen. Um die tatsächliche Verwendung der Ressourcen zu überprüfen und zu bestätigen, können Sie folgende Befehle verwenden:

show controllers npu resources all location all
show controllers fia diagshell 0 "diag alloc all" location all

Anmerkung: Mit der Cisco Bug-ID CSCvw20873 - L3VPN LSP-Pfad (Label-Swap)-Optimierung - wird eine Optimierung der Ressourcen eingeführt, die mit konfigurierter Deaktivierung der cef-Encap-Nutzung belegt und zugewiesen werden.

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	13-Apr-2022	Erstveröffentlichung

Beiträge von Cisco Ingenieuren

Ricardo Lourenco
Technischer Leiter von Cisco

War dieses Dokument hilfreich?

Feedback

Cisco kontaktieren

Eine Supportanfrage öffnen
(Erfordert einen Cisco Servicevertrag)