Fehlerbehebung für den Layer 2 VPN Virtual Private LAN Service unter IOS XE

Download-Optionen

  • PDF     (357.1 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
Aktualisiert:7. Juli 2026
Dokument-ID:226121

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.

Einleitung


In diesem Dokument wird die Fehlerbehebung für den Layer 2 VPN Virtual Private LAN Service (VPLS) auf Technologien für Cisco IOS® XE beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

  • Einfaches IP-Routing
  • Virtueller privater Layer-2-LAN-Service

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf der Cisco IOS XE Software.

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 möglichen Auswirkungen aller Befehle kennen.

Netzwerkdiagramm


VPLS TopologyVPLS-Topologie

VPLS Cross-Connect ist nicht betriebsbereit

Schritte zur Fehlerbehebung

Die VPLS-Querverbindung befindet sich nach dem unerwarteten Beenden der Sitzung im Ruhezustand.

PE2#show xconnect all 
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware

XC ST  Segment 1                         S1 Segment 2                         S2
------+---------------------------------+--+---------------------------------+--
DN pri vfi 100                           UP mpls 203.0.113.10:100             DN
UP pri ac Vl100:100(Eth VLAN)            UP vfi 100                           UP
UP pri bd 100                            UP vfi 100                           UP


Schritt 1: Bestätigen Sie den genauen VC/VPLS-Status.

PE2#show mpls l2transport vc 100 detail 
Local interface: VFI 100 vfi up
   Interworking type is Ethernet
   Destination address: 203.0.113.10, VC ID: 100, VC status: down
     Last error: Local access circuit is not ready for label advertise << The local device is unable to advertise labels because the access circuit (AC) is not in a ready state.
     Output interface: none, imposed label stack {} << no MPLS labels are being imposed because no path exists.
     Preferred path: not configured << No explicit traffic engineering path is configured for this pseudowire.
     Default path: no route << No route to the remote PE (203.0.113.10) exists in the routing table.
     No adjacency
Create time: 10:50:35, last status change time: 00:17:39
  Last label FSM state change time: 00:17:33
Signaling protocol: LDP, peer x.x.x.x:0 up
  Targeted Hello: 203.0.113.20(LDP Id) -> 203.0.113.10, LDP is DOWN, no binding
  Graceful restart: not configured and not enabled
  Non stop routing: not configured and not enabled
  Status TLV support (local/remote) : enabled/None (no remote binding
    LDP route watch : enabled
    Label/status state machine : local ready, LruRnd
    Last local dataplane status rcvd: No fault
    Last BFD dataplane status rcvd: Not sent
    Last BFD peer monitor status rcvd: No fault
    Last local AC circuit status rcvd: No fault
    Last local AC circuit status sent: DOWN(hard-down) << The local device is advertising the access circuit as hard-down to the remote PE. 
    Last local PW i/f circ status rcvd: No fault
    Last local LDP TLV status sent: No fault
    Last remote LDP TLV status rcvd: None (no remote binding) << No status has been received from the remote PE.
    Last remote LDP ADJ status rcvd: None (no remote binding) << No adjacency status received from the remote peer.
  MPLS VC labels: local 16, remote unassigned 
  Group ID: local n/a, remote unknown
  MTU: local 1500, remote unknown
  Remote interface description: 
Sequencing: receive disabled, send disabled
Control Word: On (configured: autosense)
SSO Descriptor: 203.0.113.10/100, local label: 16
Dataplane:
  SSM segment/switch IDs: 0/8194 (used), PWID: 1
VC statistics:
  transit packet totals: receive 0, send 0
  transit byte totals: receive 0, send 0
  transit packet drops: receive 0, seq error 0, send 0

Der VPLS-Cross-Connect-Modus (VC-ID 100) wurde in den inaktiven Zustand versetzt. Die Ursache wird auf die beschriebenen Bedingungen zurückgeführt:

1. Keine Route zum Remote-PE - Der Router hat in der Routing-Tabelle keine Route zu 203.0.113.10 (Standardpfad: keine Route). Ohne gültige Route kann kein MPLS Label Switched Path (LSP) eingerichtet werden.
2. Gezielte LDP-Sitzung ist unterbrochen - Die angepeilte LDP-Sitzung von 203.0.113.20 bis 203.0.113.10 ist nicht hergestellt. Dadurch wird der Austausch von Pseudowire-Labels zwischen den PE-Routern verhindert.
3. Keine Remote-Label-Bindung - Da die Ziel-LDP-Sitzung unterbrochen ist, wurde kein Remote-Label für VC 100 zugewiesen. Der Pseudowire kann den Datenverkehr nicht ohne lokale und Remote-Label weiterleiten.
4. Keine Adjacency: Ohne gültige Route und LDP-Sitzung besteht keine MPLS-Adjacency zum Remote-PE.

Schritt 2: Überprüfen Sie den lokalen Anschlusskreis.

Für PE bei VC-Ausfall:

PE2#show interfaces vlan 100 | include up|errors
Vlan100 is up, line protocol is up , Autostate Disabled
Keepalive not supported 
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 output errors, 1 interface resets

PE2#show running-config interface vlan 100
Building configuration...

Current configuration : 72 bytes
!
interface Vlan100
no ip address
no autostate
xconnect vfi 100
end

Schritt 3: Überprüfen der VFI-Konfiguration

PE2#show running-config | section l2 vfi
l2 vfi 100 manual 
vpn id 100
neighbor 203.0.113.10 pw-class VPLS_100

PE2#show l2vpn vfi
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No

VFI name: 100, state: up, type: multipoint, signaling: LDP
  VPN ID: 100
  Bridge-Domain 100 attachment circuits:
    Vlan100 
  Pseudo-port interface: pseudowire100001
  Interface Peer Address VC ID S
  pseudowire100002 203.0.113.10 100 Y

Wichtigste Beobachtungen


1. VFI ist betriebsbereit - Die lokale VFI-Instanz ist aktiv und bereit für die Weiterleitung von Datenverkehr.
2. Der Anbindungsschaltkreis ist gebunden: Vlan100 ist der Bridge-Domain 100 und dem VFI richtig zugeordnet.
3. Pseudowire ist konfiguriert: Unter 203.0.113.10 mit der VC-ID 100 wird ein Pseudowire (pseudowire100002) zum Remote-PE definiert.
4. Split-horizon ist aktiviert - Dies ist ein erwartetes Verhalten in einer VPLS-Multipoint-Umgebung, um Layer-2-Schleifen zu verhindern.


Schritt 4: Überprüfung der PE-Loopback-Erreichbarkeit:

PE2#ping 203.0.113.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

PE2#show ip route 203.0.113.10
Routing entry for 203.0.113.10/32
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 192.0.2.9 on TwentyFiveGigE1/0/3, 00:01:30 ago
Routing Descriptor Blocks:
* 192.0.2.9, from 198.51.100.2, 00:01:30 ago, via TwentyFiveGigE1/0/3
Route metric is 2, traffic share count is 1

PE2#ping mpls ipv4 203.0.113.10/32 source 203.0.113.20
Sending 5, 72-byte MPLS Echos to 203.0.113.10/32, 
timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Total Time Elapsed 8 ms

Standard-Ping und MPLS LSP-Ping: Wichtigste Unterscheidungen

Ein Standard-Ping kann selbst dann erfolgreich sein, wenn der MPLS LSP unterbrochen ist:
・ Das ICMP-Paket kann IP-geroutet (nicht Label-Switched) werden, wenn das Ziel direkt über IP erreichbar ist.
・ Transit-Router können das ICMP-Paket mithilfe der IP-Suche weiterleiten, wenn kein Label festgelegt wird.


Umgekehrt validiert ping mpls ipv4 die tatsächliche MPLS-Datenebene, indem das Paket über den Label-Switched-Pfad geleitet wird. Dadurch wird sichergestellt, dass

・ Etiketten werden korrekt zugewiesen und verteilt.
・ Die LFIB-Einträge sind an jedem Hop konsistent.
・ Der End-to-End-Pfad des LSP funktioniert.

Schritt 5: Überprüfen von MPLS und LDP im Kern:

PE2#show mpls ldp neighbor 
    Peer LDP Ident: 203.0.113.10:0; Local LDP Ident 203.0.113.20:0
        TCP connection: 203.0.113.10.646 - 203.0.113.20.39001
        State: Oper; Msgs sent/rcvd: 16/15; Downstream
        Up time: 00:02:15
        LDP discovery sources:
          TwentyFiveGigE1/0/3, Src IP addr: 192.0.2.9
          Targeted Hello 203.0.113.20 -> 203.0.113.10, active, passive
        Addresses bound to peer LDP Ident:
          203.0.113.10 192.0.2.6 192.0.2.9

Mit diesem Befehl werden die LDP-Sitzungsinformationen für Nachbarn zwischen dem lokalen Router (PE2) und dem Remote-Peer angezeigt. Jedes Feld in der Ausgabe wird detailliert beschrieben.

  • Peer-Identifizierung:
    Peer-LDP-Indent | 203.0.113.10:0 | Die LDP-Router-ID des Remote-Peers. Das :0 gibt den standardmäßigen plattformweiten Labelraum an. Dies ist in der Regel die Loopback-Adresse des Remote-Routers. 
    Lokale LDP-Kennung | 203.0.113.20:0 | Die LDP-Router-ID des lokalen Routers (PE2). Dies ist in der Regel die Loopback-Adresse von PE2. 
  • TCP-Sitzungsinformationen:
    TCP-Verbindung | 203 0 113 10 646 - 203 0 113 20 39001 | Die für die LDP-Kommunikation verwendete TCP-Sitzung. Der Remote-Peer (203.0.113.10) verwendet den bekannten LDP-Port 646, und der lokale Router (203.0.113.20) verwendet den ephemeren Port 39001. LDP verwendet TCP für eine zuverlässige Label-Verteilung.
  • Sitzungsstatus:
    Status | Oper | Die LDP-Sitzung ist in einem betriebsbereiten Zustand, d. h. sie ist vollständig eingerichtet und funktionsfähig.
    Nachrichten gesendet/empfangen | 16/15 | Die Anzahl der seit Einrichtung der Sitzung gesendeten (16) und empfangenen (15) LDP-Nachrichten Dazu gehören Keepalives, Label-Zuordnungen und andere LDP-Nachrichten.
    Downstream |- | Gibt den Label-Verteilungsmodus an. Downstream Unsolicited (Unerwünscht) bedeutet, dass der Peer Labels an PE2 verteilt, ohne dass PE2 diese explizit anfordert. Dies ist der Standardmodus für LDP.
    Betriebszeit | 00:02:15 | Die Sitzung ist seit 2 Minuten und 15 Sekunden aktiv.

  • LDP-Erkennungsquellen:
    25 GigE1/0/3 | Quelladresse: 192.0.2.9 | Vom Peer an der Schnittstelle TwentyFiveGigE1/0/3 mit der Quell-IP-Adresse 192.0.2.9 wird ein "Basic Discovery" (auf Verbindungsebene) Hello empfangen. Dies bedeutet, dass die beiden Router direkt an dieser Schnittstelle angeschlossen sind.
    Zielgerichtete Begeisterung | 203.0.113.20 → 203.0.113.10, aktiv, passiv | Zwischen dem lokalen Router (203.0.113.20) und dem Remote-Peer (203.0.113.10) ist ein gezielter Ermittlungs- (erweiterter) Hello vorhanden.

  • An Peer-LDP-Ident gebundene Adressen:
    An Peer gebundene Adressen | 203.0.113.10, 192.0.2.6, 192.0.2.9 | Die Liste der IP-Adressen, die der Remote-Peer über LDP-Adressnachrichten angekündigt hat. Diese stellen die Schnittstellen auf dem Remote-Router dar.

Schritt 5.1 Überprüfen des mit einem MPLS-Label Switched Path to the Remote VPLS Peer

PE2#show mpls forwarding-table 203.0.113.10 
Local        Outgoing         Prefix               Bytes Label     Outgoing          Next Hop 
Label        Label            or Tunnel Id         Switched        interface 
25           Pop Label        203.0.113.10/32      0                Twe1/0/3         192.0.2.9 

PE2#show mpls ldp bindings 203.0.113.10 32
  lib entry: 203.0.113.10/32, rev 69
        local binding: label: 25
        remote binding: lsr: 203.0.113.10:0, label: imp-null

PE2 empfängt "imp-null" direkt von PE1 und umgeht den erwarteten Label-Pfad durch P2 und P1. Dies weist auf ein fehlendes LDP-Sitzungs- oder MPLS-Konfigurationsproblem zwischen PE2 und P2 hin.

Schritt 5.2 Validieren Sie die Next-Hop-Informationen, indem Sie die folgenden Befehle ausführen:

  • show mpls ldp neighbor
  • MPLS-Weiterleitungstabelle anzeigen

P2#show mpls forwarding-table 203.0.113.10
Local        Outgoing          Prefix Bytes          Label           Outgoing       Next Hop 
Label        Label             or Tunnel Id          Switched        interface 
None         No Label          203.0.113.10/32       0

Wichtigste Beobachtung

  • Lokale Bezeichnung: None | P2 hat diesem Präfix kein lokales Label zugewiesen.
  • Ausgehendes Label: Kein Label | Es wird kein Label-Vorgang ausgeführt.
  • Keine ausgehende Schnittstelle oder kein nächster Hop | Das Präfix wird als lokal verwaltet behandelt - keine Weiterleitung an PE1 erfolgt.

P2#show mpls ldp neighbor 
    Peer LDP Ident: 203.0.113.20:0; Local LDP Ident 198.51.100.2:0
        TCP connection: 203.0.113.20.17326 - 198.51.100.2.646
        State: Oper; Msgs sent/rcvd: 30/29; Downstream
        Up time: 00:13:57
        LDP discovery sources:
           GigabitEthernet0/0/1, Src IP addr: 192.0.2.10
        Addresses bound to peer LDP Ident:
          203.0.113.20 192.0.2.10 
Peer LDP Ident: 198.51.100.1:0; Local LDP Ident 198.51.100.2:0
    TCP connection: 198.51.100.1.646 - 198.51.100.2.12799
    State: Oper; Msgs sent/rcvd: 30/28; Downstream
    Up time: 00:13:56
    LDP discovery sources:
      GigabitEthernet0/0/0, Src IP addr: 192.0.2.5
    Addresses bound to peer LDP Ident:
      192.0.2.2 192.0.2.5 198.51.100.1 

P2#show ip ospf neighbor

Neighbor ID       Pri   State           Dead Time    Address           Interface
198.51.100.3        0   FULL/ -         00:00:34     192.0.2.10        GigabitEthernet0/0/1
198.51.100.1        0   FULL/ -         00:00:34     192.0.2.5         GigabitEthernet0/0/0

Wichtigste Beobachtung

  • P2 verfügt über keine direkte LDP-Adjacency mit PE1 (203.0.113.10). Dies ist zu erwarten, da sich P1 in der Topologie zwischen P2 und PE1 befindet. P2 ist für den Label-Switching-Datenverkehr an P1 zuständig, der ihn dann an PE1 weiterleitet.
  • Der LDP-Indent von P2 ist 198.51.100.2:0. | P2 verwendet 198.51.100.2 als LDP-Router-ID und nicht 203.0.113.10. 203.0.113.10 ist jedoch weiterhin für Loopback10 konfiguriert und verursacht einen Routing-Konflikt. 

Schritt 6: Überprüfen Sie die Route zur Remote-PE-Loopback-Adresse:

P2#show ip route 203.0.113.10
Routing entry for 203.0.113.10/32
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Loopback10
      Route metric is 0, traffic share count is 1

Schlussfolgerung

  1. Doppelte IP-Adresse - Die IP-Adresse 203.0.113.10 wird auf P2 (Loopback10) und PE1 (Loopback0) konfiguriert, wodurch ein Konflikt in der MPLS-Domäne entsteht.
  2. Routing-Konflikt - P2 installiert 203.0.113.10/32 als verbundene Route (administrative Distanz 0), die Vorrang vor jeder vom IGP bezogenen Route hat, die von PE1 generiert wurde.
  3. LSP-Fehler - Da P2 das Präfix als lokal verwaltet ansieht, wird PE2 kein Transportlabel für 203.0.113.10/32 zugewiesen oder angekündigt.
  4. VPLS-Auswirkung - Das Fehlen eines gültigen Transportetiketts von P2 verhindert, dass PE2 einen LSP für PE1 erstellt. Daher kann der VPLS-Pseudowire-Transportpfad nicht gebildet werden.

VPLS-Querverbindung hergestellt, aber kein Datenverkehr über die Pseudowire-Emulation

VPLS - Betriebsverifizierung der Catalyst Serie 9000

Schritte zur Fehlerbehebung

Schritt 1: Bestätigen Sie, dass sich der Pseudowire in einem Betriebszustand befindet.
Stellen Sie sicher, dass die Parameter korrekt sind:

  • VFI-Status ist aktiv
  • Die Pseudowire-Schnittstelle wird aufgelistet.
  • Die richtige Peer-Adresse und VC-ID werden angezeigt.
PE2#show mpls l2transport vc

Local intf    Local circuit              Dest address    VC ID      Status
------------- -------------------------- --------------- ---------- ----------
VFI 100        vfi                       203.0.113.10    100        UP
PE2#show mpls l2transport vc 100 detail 
Local interface: VFI 100 vfi up
  Interworking type is Ethernet
  Destination address: 203.0.113.10, VC ID: 100, VC status: up
    Output interface: Twe1/0/3, imposed label stack {17 16}
    Preferred path: not configured 
    Default path: active
    Next hop: 192.0.2.9
Create time: 1d11h, last status change time: 00:30:50
  Last label FSM state change time: 00:30:26
Signaling protocol: LDP, peer 203.0.113.10:0 up
  Targeted Hello: 203.0.113.20(LDP Id) -> 203.0.113.10, LDP is UP
  Graceful restart: not configured and not enabled
  Non stop routing: not configured and not enabled
  Status TLV support (local/remote) : enabled/supported
    LDP route watch : enabled
    Label/status state machine : established, LruRru
    Last local dataplane status rcvd: No fault
    Last BFD dataplane status rcvd: Not sent
    Last BFD peer monitor status rcvd: No fault
    Last local AC circuit status rcvd: No fault
    Last local AC circuit status sent: No fault
    Last local PW i/f circ status rcvd: No fault
    Last local LDP TLV status sent: No fault
    Last remote LDP TLV status rcvd: No fault
    Last remote LDP ADJ status rcvd: No fault
  MPLS VC labels: local 16, remote 16
  Group ID: local n/a, remote 0
  MTU: local 1500, remote 1500
  Remote interface description: 
  MAC Withdraw: sent:1, received:0
Sequencing: receive disabled, send disabled
Control Word: On (configured: autosense)
SSO Descriptor: 203.0.113.10/100, local label: 16
Dataplane:
  SSM segment/switch IDs: 16395/8194 (used), PWID: 1
VC statistics:
transit packet totals: receive 0, send 0
transit byte totals: receive 0, send 0
transit packet drops: receive 0, seq error 0, send 0
  • VFI-Status | nach oben | Die VFI ist auf dem lokalen Gerät betriebsbereit.
  • Zieladresse | 203.0.113.10 | Die ID des Remote-PE-Routers (PE1-Loopback-Adresse).
  • VC-ID | 100 | Die virtuelle Leitungskennung für diesen Pseudowire. Muss auf beiden PE-Routern übereinstimmen.
  • VC-Status | nach oben | Der Pseudowire ist betriebsbereit. Sowohl die lokale als auch die Remote-Signalisierung weisen auf keine Fehler hin.
  • Etikettenstapel "{17 16}" wurde eingefügt | Der MPLS-Stack mit zwei Labels für Pakete, die in die Pseudowire-Emulation eintreten. Label 17 ist das Transportlabel (außen), das verwendet wird, um den Remote-PE über den MPLS-Core zu erreichen. Label 16 ist das VC-Label (innen) zur Identifizierung des Pseudodrahts am Remote-PE.
  • Zielgerichtete Begeisterung | 203.0.113.20 → 203.0.113.10, LDP ist aktiv | Die geplante LDP-Sitzung zwischen PE2 (lokal) und PE1 (remote) ist eingerichtet und betriebsbereit.
  • Lokales Label | 16 | Das von PE2 diesem Pseudowire zugeordnete VC-Label. Der Remote-PE (PE1) verwendet dieses Label, wenn Datenverkehr an PE2 gesendet wird. Remote-Label | 16 | Das von PE1 für diesen Pseudowire angekündigte VC-Label. PE2 weist dieses Label (inneres Label) auf, wenn Datenverkehr an PE1 gesendet wird.
  • MAC-Zurückziehen gesendet | 1 | PE2 hat eine MAC-Abbruchmeldung an den Remote-PE gesendet. Damit werden MAC-Adresstabellen nach einer Topologieänderung geleert.
  • MAC-Entzug erhalten | 0 | Vom Remote-PE wurden keine MAC-Ausstiegsmeldungen empfangen.
  • VC-Statistik | Es wird kein Datenverkehr in beide Richtungen weitergeleitet (Senden: 0, empfangen: 0).

Schritt 2: Überprüfen des Status der Anschlussschaltung (Trunk-Schnittstelle)

Vergewissern Sie sich, dass die Trunk-Schnittstelle betriebsbereit ist und mit dem richtigen VLAN verknüpft ist.

Überprüfung:

  • Die Schnittstelle befindet sich in einem aktiven Zustand.
  • Das der VPLS-Bridge-Domäne zugeordnete VLAN ist für den Trunk zulässig und aktiv.
  • Das VLAN wird von STP weder abgeschnitten noch blockiert.
PE2#show interfaces twentyFiveGigE 1/0/2 status
Port       Name        Status        Vlan          Duplex       Speed  Type
Twe1/0/2               connected     trunk           full         10G  SFP-10GBase-SR

PE2#show interfaces trunk
Port         Mode        Encapsulation   Status       Native vlan 
Twe1/0/2     on          802.1q          trunking     1

Port         Vlans allowed on trunk
Twe1/0/2     100

Port         Vlans allowed and active in management domain
Twe1/0/2     100

Port         Vlans in spanning tree forwarding state and not pruned
Twe1/0/2     100

Schritt 3: Überprüfen der VLAN-Zuordnung zur Bridge-Domäne
Auf dem Catalyst 9000 mit Trunk-Konfiguration (ohne EVC) muss das VLAN der Bridge-Domäne zugeordnet werden.

Bestätigen:

  • Das VLAN wird der Bridge-Domäne über die Mitglied-VFI oder die Mitgliedkonfiguration zugeordnet.
  • Die Bridge-Domain-Konfiguration referenziert die richtige VFI.
PE2#show running-config interface vlan100
Building configuration...

Current configuration : 72 bytes
!
interface Vlan100
no ip address
xconnect vfi 100

Schritt 4: Überprüfen der MAC-Adresse

Bestätigen Sie, dass MAC-Adressen sowohl von der lokalen Anbindungsschaltung als auch vom Remote-Pseudowire abgerufen werden.

Überprüfung:

  • Die lokale CE1-MAC-Adresse wird über die Trunk-Schnittstelle abgefragt.
  • Die Remote-CE2-MAC-Adresse wird über die Pseudowire-Schnittstelle abgefragt.

Wenn keine MAC-Adressen über den Pseudowire abgefragt werden:

  • Der Datenverkehr wird vom Remote-PE nicht empfangen.
  • Der Remote-PE hat ein Konfigurationsproblem, das verhindert, dass Datenverkehr in die Pseudowire-Emulation gelangt.
  • Die Bridge-Domäne ist nicht korrekt mit der Pseudowire-Schnittstelle verknüpft.

Wenn keine MAC-Adressen vom lokalen Trunk erfasst werden:

  • Das CE-Gerät überträgt keinen Datenverkehr über das erwartete VLAN.
  • Das VLAN befindet sich in einem blockierten oder inaktiven Zustand der Trunk-Schnittstelle.
PE2#show mac address-table vlan 100 
          Mac Address Table
-------------------------------------------

Vlan Mac Address Type     Ports
---- ----------- -------- -----
100 cc7f.76b7.525f STATIC Vl100 
100 e462.c4bb.17f1 DYNAMIC Twe1/0/2  >> CE2 Mac address learned over Twe1/0/2 interface.

Schritt 5: Überprüfen des STP-Status (Spanning Tree Protocol)

STP kann das VLAN an der Trunk-Schnittstelle blockieren, wodurch verhindert wird, dass Datenverkehr in die Bridge-Domäne gelangt.

Überprüfung:

・ Der Trunk-Port befindet sich in einem Weiterleitungsstatus für das mit der VPLS-Bridge-Domäne verknüpfte VLAN.
・ Der Port befindet sich nicht in einem blockierenden, überwachenden oder lernenden Zustand.


Wenn STP den Port blockiert:

・ STP-Priorität oder Port-Kosten anpassen
・ Ziehen Sie in Betracht, den Trunk-Port als STP Edge-Port zu konfigurieren (falls dies für die Topologie angemessen ist)

PE2#show spanning-tree vlan 100

VLAN0100
  Spanning tree enabled protocol rstp
  Root ID    Priority 32868
           Address cc7f.76b7.51c0
           This bridge is the root
           Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID  Priority  32868 (priority 32768 sys-id-ext 100)
           Address   cc7f.76b7.51c0
           Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
           Aging Time 300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Twe1/0/2            Desg FWD 2000      128.2    P2p

Schritt 6: Überprüfen des MPLS-Label-Stacks und des Weiterleitungspfads
Vergewissern Sie sich, dass die richtigen Bezeichnungen verwendet werden und der Weiterleitungspfad gültig ist.

Überprüfung:

  • Ein gültiges ausgehendes Label ist vorhanden (kein Label oder kein)
  • Die Ausgangsschnittstelle und der nächste Hop sind richtig.


Pfad von PE2 zu P2 LSP:

PE2#show mpls forwarding-table 203.0.113.10 32
Local     Outgoing     Prefix            Bytes Label     Outgoing      Next Hop 
Label     Label        or Tunnel Id      Switched        interface 
22        17           203.0.113.10/32   810             Twe1/0/3      192.0.2.9 << For the transport path to the remote PE1 loopback, the imposed outgoing label is 17. The router at 192.0.2.9 assigned this value as its local label binding for the destination prefix.


Pfad von P2 zu P1:

P2#show mpls forwarding-table 203.0.113.10 32
Local     Outgoing    Prefix            Bytes Label     Outgoing       Next Hop 
Label     Label       or Tunnel Id      Switched        interface 
17        16          203.0.113.10/32   79290           Gi0/0/0        192.0.2.5 << Local label as 17 and the imposed outgoing label is 16. The router at 192.0.2.5 assigned this value as its local label binding for the destination prefix.


Pfad von P1 zu PE1 LSP: 

P1#show mpls forwarding-table 203.0.113.10 32
Local     Outgoing    Prefix            Bytes Label     Outgoing       Next Hop 
Label     Label       or Tunnel Id      Switched        interface 
16        Pop Label   203.0.113.10/32   76184           Gi0/0/0        192.0.2.1 << Pop Label is performed before forwarding the packet to the next hop. This confirms that the next hop (PE1) advertised implicit null to P1.


Pfad von P1 zu PE1 LSP: 

PE1#show mpls forwarding-table 203.0.113.10 32
Local      Outgoing   Prefix           Bytes Label         Outgoing       Next Hop 
Label      Label      or Tunnel Id     Switched            interface 
None       No Label   203.0.113.10/32  0

Bestätigung des Labelpfads:

Basierend auf dieser Ausgabe und den vorherigen Ausgaben von PE2 und P2 ist der komplette Label-Switched-Pfad von PE2 zu PE1:

[PE2] Packet leaves with label stack: | 17 | (transport label)
        ↓
[P2]  Receives label 17, swaps to 16: | 16 | (transport label)
        ↓
[P1]  Receives label 16, pops label:  | IP | (pure IP packet)
        ↓
[PE1] Receives pure IP packet - local delivery


Wenn der VPLS-Datenverkehr diesen LSP durchläuft, wird ein Stack mit zwei Labels (Transport: VC-Label)

[PE2] Packet leaves with label stack: | 17 | 16 | (transport + VC label)
       ↓
[P2] Receives label 17, swaps to 16:  | 16 | 16 | (transport + VC label)
       ↓
[P1] Receives label 16, pops label:   | 16 | (VC label only)
       ↓
[PE1] Receives VC label 16 - pseudowire disposition into bridge domain

Schlussfolgerung


Der MPLS-Transport-LSP von PE2 zu PE1 ist vollständig betriebsbereit und auf allen Routern im Pfad richtig programmiert. Die VPLS-Pseudowire-Signalisierung ist abgeschlossen, lokale und Remote-Labels wurden ausgetauscht, und es wurden keine Fehler gemeldet.

Über den Pseudowire wird jedoch kein Benutzerdatenverkehr weitergeleitet, obwohl die Kontrollebene vollständig eingerichtet ist. Dadurch wird bestätigt, dass sich das Problem außerhalb des MPLS-Core und der Pseudowire-Signalisierung befindet - insbesondere auf der Ebene der Anbindungsschaltung auf einem oder beiden PE-Routern

VPLS-Betriebsverifizierung für Router 

Schritte zur Fehlerbehebung


Schritt 1: Bestätigen Sie den genauen VC/VPLS-Status.
Stellen Sie sicher, dass die Parameter korrekt sind:

PE1#show mpls l2transport vc

Local intf    Local circuit              Dest address     VC ID     Status
------------- -------------------------- --------------- ---------- ----------
VFI 100        vfi                       203.0.113.20    100         UP
PE1#show mpls l2transport vc 100 detail
Local interface: VFI 100 vfi up
  Interworking type is Ethernet
  Destination address: 203.0.113.20, VC ID: 100, VC status: up
    Output interface: Te0/0/4, imposed label stack {19 16}
    Preferred path: not configured 
    Default path: active
    Next hop: 192.0.2.2
  Create time: 1d09h, last status change time: 08:38:02
    Last label FSM state change time: 08:38:25
  Signaling protocol: LDP, peer 203.0.113.20:0 up
    Targeted Hello: 203.0.113.10(LDP Id) -> 203.0.113.20, LDP is UP
    Graceful restart: not configured and not enabled
    Non stop routing: not configured and not enabled
    Status TLV support (local/remote) : enabled/supported
      LDP route watch : enabled
      Label/status state machine : established, LruRru
      Last local dataplane status rcvd: No fault
      Last BFD dataplane status rcvd: Not sent
      Last BFD peer monitor status rcvd: No fault
      Last local AC circuit status rcvd: No fault
      Last local AC circuit status sent: No fault
      Last local PW i/f circ status rcvd: No fault
      Last local LDP TLV status sent: No fault
      Last remote LDP TLV status rcvd: No fault
      Last remote LDP ADJ status rcvd: No fault
    MPLS VC labels: local 16, remote 16 
    Group ID: local n/a, remote 0
    MTU: local 1500, remote 1500
    Remote interface description: 
    MAC Withdraw: sent:0, received:1
  Sequencing: receive disabled, send disabled
  Control Word: On (configured: autosense)
  SSO Descriptor: 203.0.113.20/100, local label: 20
  Dataplane:
    SSM segment/switch IDs: 8199/4097 (used), PWID: 1
  VC statistics:
    transit packet totals: receive 336, send 0
    transit byte totals:   receive 27552, send 0
    transit packet drops: receive 0, seq error 0, send 0
  • VFI-Status | nach oben | Die VFI ist auf PE1 betriebsbereit.
  • Zieladresse | 203.0.113.20 | Die ID des Remote-PE-Routers (PE2-Loopback-Adresse).
  • VC-ID | 100 | Die virtuelle Leitungskennung für diesen Pseudowire. Dieser Wert entspricht auf beiden PE-Routern.
  • VC-Status | nach oben | Der Pseudowire ist betriebsbereit. Sowohl die lokale als auch die Remote-Signalisierung weisen auf keine Fehler hin.
  • Lokale Schnittstelle | VFI 100 | Die diesem Pseudowire zugeordnete lokale Virtual Forwarding-Instanz.
  • Aufgesetzter Etikettenstapel | {19 16} | Der MPLS-Stack mit zwei Labels für Pakete, die in die Pseudowire-Emulation eintreten. Label 19 ist das Transportlabel (außen), das verwendet wird, um PE2 über den MPLS-Core zu erreichen. Label 16 ist das VC-Label (innen) zur Identifizierung des Pseudodrahts an PE2.
  • Zielgerichtete Begeisterung | 203.0.113.10 → 203.0.113.20, LDP ist aktiv | Die angepeilte LDP-Sitzung von PE1 (lokal) zu PE2 (remote) ist eingerichtet und betriebsbereit.
  • Lokales Label | 16 | Das von PE1 diesem Pseudowire zugewiesene VC-Label. PE2 verwendet dieses Label (als inneres Label), wenn Datenverkehr an PE1 gesendet wird.
  • MAC-Zurückziehen gesendet | 0 | PE1 hat keine MAC-Nachricht zum Zurückziehen an PE2 gesendet.
  • MAC-Entzug erhalten | 1 | PE1 hat eine MAC-Nachricht von PE2 empfangen. Dies zeigt an, dass PE2 eine Topologieänderung erfahren hat und PE1 aufgefordert hat, seine MAC-Adresstabelle für diese VFI zu leeren.
  • VC-Statistik | Empfangene Transitpakete | 336 | 336 Pakete wurden von PE2 über diesen Pseudowire empfangen.

                          Empfangene Transit-Bytes | 27.552 | 27.552 Byte wurden von PE2 empfangen.

                          Versendete Pakete übertragen | 0 | Es wurden keine Pakete von PE1 an den Pseudowire zu PE2 gesendet.
                          Transit-Bytes gesendet | 0 | Es wurden keine Bytes an PE2 gesendet.


Schritt 2: Überprüfen der Bridge-Domain-Konfiguration und -Mitgliedschaft

Vergewissern Sie sich, dass die Bridge-Domäne über die richtigen Mitglieder verfügt (Service Instance-Schnittstelle und Pseudowire).

PE1#show running-config interface TenGigabitEthernet0/0/5
Building configuration...

Current configuration : 174 bytes
!
interface TenGigabitEthernet0/0/5
no ip address
service instance 100 ethernet
encapsulation dot1q 100
rewrite ingress tag pop 1 symmetric
bridge-domain 100
!
end

PE1#show interfaces tenGigabitEthernet 0/0/5 | include up|errors 
TenGigabitEthernet0/0/5 is up, line protocol is up 
  Keepalive not supported 
  Full Duplex, 10000Mbps, link type is force-up, media type is H10GB-CU1M
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 output errors, 0 collisions, 1 interface resets


Schritt 3: Überprüfen der MAC-Adresse
Bestätigen Sie, dass MAC-Adressen sowohl von der lokalen Anbindungsschaltung als auch vom Remote-Pseudowire abgerufen werden.

PE1#show bridge-domain 
Bridge-domain 100 (2 ports in all)
State: UP                 Mac learning: Enabled
Aging-Timer: 300 second(s)
Unknown Unicast Flooding Suppression: Disabled
Maximum address limit: 65536
    TenGigabitEthernet0/0/5 service instance 100
    vfi 100 neighbor 203.0.113.20 100
   AED MAC address Policy Tag Age Pseudoport
-----------------------------------------------------------------------------

Die Bridge-Domäne selbst ist aktiv, aber die wichtigsten Details sind das Fehlen abgefragter MAC-Adressen. Dies deutet in der Regel darauf hin, dass noch kein Datenverkehr erfasst wurde oder irgendwo zwischen der lokalen Schnittstelle, der Bridge-Domäne und der Remote-VFI ein Problem mit der Service-Zuordnung bzw. der Weiterleitung aufgetreten ist.

Schritt 4: Überprüfen der VFI-Konfiguration:

PE1#show running-config | section vfi
l2 vfi 100 manual 
 vpn id 100
 bridge-domain 100
neighbor 203.0.113.20 encapsulation mpls


Schritt 5: Überprüfen des MPLS-Transportpfads
Schnelle Validierung durch Senden einer MPLS-Traceroute an die Remote-Loopback-Adresse

PE1#traceroute mpls ipv4 203.0.113.20 255.255.255.255 source 203.0.113.10 
Tracing MPLS Label Switched Path to 203.0.113.20/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
0 192.0.2.1 MRU 1500 [Labels: 17 Exp: 0]
L 1 192.0.2.2 MRU 1500 [Labels: 16 Exp: 0] 96 ms
L 2 192.0.2.6 MRU 1500 [Labels: implicit-null Exp: 0] 12 ms
! 3 192.0.2.10 2 ms

Die MPLS-Traceroute-Ausgabe bestätigt die erfolgreiche Einrichtung eines Label Switched Path (LSP) zwischen dem Quell-PE-Router (203.0.113.10) und dem Ziel-PE-Router (203.0.113.20).

Die Ablaufverfolgung zeigt die Label-Auslagerung am Eingangs-PE, Label-Swapping-Vorgänge über Label Switch Router (LSRs) und Penultimate Hop Popping (PHP) hinweg, bevor der Ausgangs-PE erreicht wird.

Konkret:

  • Hop 0 gibt an, dass das Label 17 für Datenverkehr bestimmt ist, der für den Ziel-FEC bestimmt ist.
  • Hop 1 zeigt einen Label-Swap-Vorgang von 17 auf 16, der die MPLS-Weiterleitung über den Core bestätigt.
  • Hop 2 meldet implicit-null, was darauf hinweist, dass PHP vom vorletzten Router ausgeführt wird.
  • Hop 3 erreicht erfolgreich das Ziel, angezeigt durch "!" Rückgabecode.

Die Traceroute meldet keine MPLS-Weiterleitungsanomalien wie fehlende Label-Bindings, FEC-Diskrepanzen, vorzeitige LSP-Terminierung oder nicht unterstützte Label-Vorgänge.

PE1
Push 17
  ↓
P1
Swap 17 → 16
  ↓
P2
Pop label
  ↓
PE2 receives pure IP packet


Schritt 6: Überprüfen des Pseudowire-Datenflugs

PE1#ping mpls pseudowire 203.0.113.20 100 source 203.0.113.10
Sending 5, 72-byte MPLS Echos to 203.0.113.20, 
timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Total Time Elapsed 6 ms
PE2#ping mpls pseudowire 203.0.113.10 100 source 203.0.113.20 
Sending 5, 72-byte MPLS Echos to 203.0.113.10, 
timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface, 
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry, 
'P' - no rx intf label prot, 'p' - premature termination of LSP, 
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Total Time Elapsed 9 ms

Die MPLS-Pseudowire-Datenebene wird durch den Ping-MPLS-Pseudowire-Test erfolgreich validiert. Da der Pseudowire-Ping erfolgreich ist und die Bridge-Domäne eine Remote-MAC über VPLS erlernt, ist das Problem wahrscheinlicher auf dem lokalen Anbindungsschaltkreis oder VLAN-Weiterleitungspfad, wenn die erwartete lokale MAC-Adresse nicht erfasst wird.


Schlussfolgerung

Der erfolgreiche MPLS-Pseudowire-Ping bestätigt, dass die MPLS-Transport-LSP- und Pseudowire-Label-Bindungen zwischen dem lokalen und dem Remote-PE-Router funktionsfähig sind. Das Ergebnis zeigt, dass die MPLS-Weiterleitung, die Label-Verteilung und die Pseudowire-Signalisierung ordnungsgemäß funktionieren und dass der Remote-PE-Router Pseudowire-OAM-Pakete für die angegebene VC verarbeiten kann.

Auf Grundlage dieses Ergebnisses scheinen der MPLS-Core und die Pseudowire-Infrastruktur betriebsbereit zu sein. Wenn weiterhin Probleme mit dem Datenverkehr auftreten, können weitere Untersuchungen auf die Verbindungsschaltungen, das VPLS-Weiterleitungsverhalten, MAC-Lernen, MTU-Konsistenz und CE-orientierte Verbindungen konzentriert werden und nicht auf den zugrunde liegenden MPLS-Transportpfad.


Weitere Informationen zu diesen Themen finden Sie unter:



Revisionsverlauf

Überarbeitung Veröffentlichungsdatum Kommentare
1.0
07-Jul-2026
Erstveröffentlichung
TAC Authored

Beiträge von Cisco Ingenieuren

  • Adriana Pacheco
    Technischer Berater

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren

Dieses Dokument gilt für folgende Produkte.