Inhalt

Einleitung

Problem

Architektur der Lösung

PE-Router-Endpunkterkennung

VPLS-Identität und MPLS-Labels

Kapselungsinformationen

VPLS BGP Auto Discovery Prefix und VPLS BGP Signaling Prefix

Beispielkonfiguration der Cisco IOS Software

Anzeigter Label-Block

Route Distinguisher und Route Targets

Beispielkonfiguration von PE1

Labelbereich überprüfen

Labels überprüfen

Label-Block überprüfen

Angezeigtes Präfix prüfen

Präfix im Detail anzeigen

Anzeigen, Empfangen und Verarbeiten von Label-Blöcken in BGP-Update-Nachrichten

PE2: BGP-Update empfangen

PE2: Label suchen

PE2: Präfix an PE1 senden

PE1: Label suchen

Zusätzliche Überprüfungsbefehle

Mehrere vom PE-Router für ein VFI angekündigte L2VPN-VPLS-Präfixe

PE1-Konfiguration

PE2-Konfiguration

Anfängliche Label-Blöcke

PE1 und PE2 Exchange

Analyse von PE1 und PE2 Exchange

Präfixdetails

Interoperabilität

Einleitung

Dieses Dokument beschreibt die auf Border Gateway Protocol (BGP) basierende automatische Erkennung für einen Virtual Private LAN Service (VPLS) mit BGP-Signalisierung. Die automatische Erkennung ist eine Möglichkeit, mit der ein Provider Edge (PE) ermitteln kann, welche Remote-PEs Mitglieder einer bestimmten VPLS-Domäne sind.Die Signalisierung ist ein Mittel, mit dem ein PE das Pseudowire-Label erlernen kann, das von einem bestimmten Remote-PE für eine bestimmte VPLS-Domäne erwartet wird.

Weitere Informationen finden Sie in den Dokumenten der Internet Engineering Task Force:

- RFC 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling  beschreibt die automatische BGP-Erkennung mit Label Distribution Protocol (LDP)-Signalisierung für VPLS (auch Martini genannt).

- RFC 4761 Virtual Private LAN Service (VPLS) mit BGP für die automatische Erkennung und Signalisierung  beschreibt die automatische BGP-Erkennung und BGP-Signalisierung für VPLS (auch Kompella genannt).

Dieses Dokument konzentriert sich auf RFC 4761. Bei RFC 4761 enthalten die NLRI (Network Layer Reachability Information) des BGP die Informationen für die automatische Erkennung und Signalisierung. Wenn Remote-PE-Router dieses BGP-Update erhalten, verfügen sie über alle erforderlichen Informationen, um ein vollständiges Netz an Pseudowire-Emulation für VPLS einzurichten. Die automatische BGP-Erkennung und BGP-Signalisierung verwenden dieselbe BGP-Adressfamilie.

Die Befehlszeilenschnittstelle (CLI) und die Ausgabe stammen von der Cisco IOS® Software. Konfiguration und Funktionalität sind in der Cisco IOS-XR-Software und der Cisco NX-OS-Software sehr ähnlich.

Problem

VPLS besteht aus einer Reihe von Pseudowire (PW)-Verbindungen (Point-to-Multipoint). Bisher wurde LDP verwendet, um die Pseudowire-Emulation zwischen den PE-Routern zu signalisieren. Eine zielgerichtete LDP-Sitzung signalisierte also, für welche Labels ein Pseudowire zwischen zwei PE-Routern verwendet werden sollte. Sie können den Satz von PE-Routern, die an einer VPLS-Domäne beteiligt waren, manuell konfigurieren oder die Konfiguration mithilfe des BGP automatisch ermitteln. Um diese automatische Erkennung durchzuführen, gab das BGP bekannt, zu welchem PE gehört die VPLS-Domäne gehört. Selbst bei der automatischen BGP-Erkennung wurde LDP jedoch verwendet, um die VC-Labels (Multiprotocol Label Switching) und die Pseudowire-ID zu signalisieren.

BGP kann jetzt verwendet werden, um die Pseudowire-Emulation zwischen den PE-Routern zu signalisieren.

Wenn ein Pseudowire zwischen zwei Routern eingerichtet werden soll, benötigen die anderen Router die Informationen zu diesem Pseudowire nicht. Diese Informationen sind beispielsweise das zu verwendende VC-Label.

Bei LDP, dem Signalisierungsprotokoll für die Einrichtung von Pseudowire-Emulation, werden die Informationen nur von beiden Routern empfangen, da LDP die Signalisierung Punkt-zu-Punkt-Modus durchführt.

Bei BGP als Signalisierungsprotokoll zum Einrichten von Pseudowire-Emulation werden die Informationen von allen anderen Routern empfangen, da das interne BGP (iBGP) die Signalisierung Punkt-zu-Mehrpunkt-Modus durchführt. Da iBGP eine Full-Mesh-Anforderung hat, sendet ein Router ein iBGP-Update an alle anderen iBGP-Router. Dies kann auch mit einem Routen-Reflektor erfolgen.

Bei Verwendung von iBGP als Signalisierungsprotokoll gibt es zwei Methoden zum Senden von Updates:

1. Jeder PE-Router kündigt allen iBGP-Nachbarn für jeden PW ein BGP-Update an. jedes Mal wird ein MPLS-VC-Label angehängt. Daher sendet ein PE-Router so viele BGP-Updates wie PE-Router. Das mit dem BGP-Update verbundene VC-Label konnte jedoch nur von einem der PE-Router verwendet werden - dem PE-Router am anderen Ende des PW.

2. Um dieses Problem einer hohen Anzahl an BGP-Updates zu vermeiden, wurde eine Architektur entwickelt, bei der ein lokaler PE-Router einen Satz oder einen Block lokaler VC-Labels an alle Remote-PE-Router sendet. Jeder Remote-PE-Router wählt eines der VC-Label, das als Remote-VC-Label für den PW zum lokalen PE-Router verwendet wird. Der Remote-PE-Router muss ein Remote-VC-Label eindeutig auswählen, sodass kein anderer PE-Router dasselbe VC-Label aus dem angekündigten Label-Block auswählt. Da ein Labelblock gesendet wird, müssen genügend Etiketten zur Verfügung stehen, um alle möglichen PWs zu versorgen, die eingerichtet werden könnten, aber es sollten nicht so viele Etiketten vorhanden sein, dass sie nicht verwendet und verschwendet werden.

In diesem Dokument wird beschrieben, wie BGP zum Signalisieren der Pseudowire-Emulation verwendet wird. Beachten Sie, dass BGP gleichzeitig auch für die automatische Erkennung verwendet wird.

Architektur der Lösung

Da es sich um VPLS handelt, ist im Core noch ein Hop-by-Hop-Signalisierungsprotokoll für die Übertragung der bezeichneten Pakete vom PE zum PE-Router erforderlich. Diese Transportfunktion im Core muss weiterhin von LDP- oder MPLS-Traffic Engineering erfüllt werden.

Das BGP muss die erforderlichen Informationen senden, um die Pseudowire-Emulation auf Point-to-Multipoint-Weise für VPLS einzurichten. Diese Signalisierungsinformationen umfassen:

- Endgeräteerkennung für PE-Router

- VPLS-Identität

- Block von MPLS-Labels

- Kapselungsinformationen

PE-Router-Endpunkterkennung

Die Endpunktidentifizierung des PE-Routers wird vom PE-Router bestimmt, der der BGP-Absender des Updates ist.

Das BGP-Update für Layer 2 Virtual Private Networks (L2VPN) VPLS wird von AFI/SAFI 25/65 identifiziert. Diese Adressfamilie wird ausgehandelt, wenn BGP die OPEN-Nachricht sendet.

VPLS-Identität und MPLS-Labels

Der NLRI, auch Präfix genannt, enthält Informationen zur VPLS-Identität und zum Block von MPLS-Labels. Seine Kodierung hat eine Gesamtlänge von 19 Byte:

+------------------------------------+

|  Length (2 octets)                 |

+------------------------------------+

|  Route Distinguisher  (8 octets)   |

+------------------------------------+

|  VE ID (2 octets)                  |

+------------------------------------+

|  VE Block Offset (2 octets)        |

+------------------------------------+

|  VE Block Size (2 octets)          |

+------------------------------------+

|  Label Base (3 octets)             |

+------------------------------------+

Der Route Distinguisher (RD) bezieht sich auf die Identität des VPLS.

Anmerkung: Bei der Implementierung der Cisco IOS- und Cisco NX-OS-Software müssen alle PE-Router denselben RD innerhalb derselben VPLS-Domäne haben.

Die virtuelle Erweiterungs-ID (VE), der VE-Block-Offset, die VE-Blockgröße und die Label Base (LB) beziehen sich auf den angegebenen Label-Block, wie im nächsten Abschnitt erläutert.

Kapselungsinformationen

Kapselungsinformationen werden ebenfalls an das Präfix angehängt und als erweiterte Community 'Layer2 Info Extended Community' für das BGP-Update kodiert. Der Wert ist 0x800A und wird wie folgt codiert:

+------------------------------------+

| Extended community type (2 octets) |

+------------------------------------+

|  Encaps Type (1 octet)             |

+------------------------------------+

|  Control Flags (1 octet)           |

+------------------------------------+

|  Layer-2 MTU (2 octet)             |

+------------------------------------+

|  Reserved (2 octets)               |

+------------------------------------+

Der Encaps-Typ für VPLS ist 19.

Die Control Flags (Bitvektor) werden folgendermaßen codiert:

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

|   MBZ     |C|S|      (MBZ = MUST Be Zero)

+-+-+-+-+-+-+-+-+

Name

Wert

Bedeutung

C

1

Ein Kontrollwort MUSS vorhanden sein, wenn VPLS-Pakete an diesen PE gesendet werden.

0

Ein Kontrollwort MUSS NICHT vorhanden sein, wenn VPLS-Pakete an diesen PE gesendet werden.

S

1

Die sequenzielle Zustellung von Frames MUSS verwendet werden, wenn VPLS-Pakete an diesen PE gesendet werden.

0

Die sequenzielle Zustellung von Frames DARF NICHT verwendet werden, wenn VPLS-Pakete an diesen PE gesendet werden.

Dem BGP-Update sind auch Route Targets (RTs) beigefügt. RTs steuern den Import in das L2VPN und dessen Export auf die gleiche Weise wie MPLS L3VPN.

VPLS BGP Auto Discovery Prefix und VPLS BGP Signaling Prefix

Ein VPLS-Präfix für die automatische BGP-Erkennung ist ein /96-Präfix, während ein VPLS-BGP-Signalisierungspräfix ein /136-Präfix ist. Beispiele:

PE2#show bgp l2vpn vpls all

BGP table version is 264, local router ID is 10.100.1.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>i 1:100:VEID-1001:Blk-150/136

10.100.1.1               0    100      0 ?

*>  1:100:10.100.1.2/96

0.0.0.0                            32768 ?

PE2#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 150

BGP routing table entry for 1:100:VEID-1001:Blk-150/136, version 262

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 1

Local

10.100.1.1 (metric 21) from 10.100.1.4 (10.100.1.4)

Origin incomplete, metric 0, localpref 100, valid, internal, best

AGI version(0), VE Block Size(50) Label Base(10105)

Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

Originator: 10.100.1.1, Cluster list: 10.100.1.4

rx pathid: 0, tx pathid: 0x0

PE2#show bgp l2vpn vpls rd 1:100 10.100.1.2

BGP routing table entry for 1:100:10.100.1.2/96, version 43

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 1

Local

0.0.0.0 from 0.0.0.0 (10.100.1.2)

Origin incomplete, localpref 100, weight 32768, valid, sourced, local,

best, AGI version(0)

Extended Community: RT:1:100 L2VPN AGI:1:100

rx pathid: 0, tx pathid: 0x0

Beispielkonfiguration der Cisco IOS Software

Dies ist eine Beispielkonfiguration der Cisco IOS-Software:

!

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp     <<< "signaling ldp" would be RFC 4762

ve id 1001

ve range 50

route-target export 32:64

route-target import 32:64

mpls label range 10000 20000

!

bridge-domain 1

member Ethernet0/0 service-instance 100

member vfi one

!

l2 router-id 10.100.1.1

!

interface Ethernet0/0

no ip address

service instance 100 ethernet

!

!

router bgp 1

bgp log-neighbor-changes

neighbor 10.100.1.4 remote-as 1

neighbor 10.100.1.4 update-source Loopback0

!

address-family l2vpn vpls

neighbor 10.100.1.4 activate

neighbor 10.100.1.4 send-community extended

neighbor 10.100.1.4 suppress-signaling-protocol ldp

exit-address-family

Anzeigter Label-Block

Ein PE-Router muss mindestens einen Label-Block angeben. Der Label-Block besteht aus einem kontinuierlichen Satz von MPLS-Labels und wird von den Remote-PE-Routern verwendet, um ein Remote-VC-Label auszuwählen. Das Remote-Label wird für das PW zwischen dem lokalen und dem Remote-PE-Router verwendet. (Ein PE-Router kann mehrere Label-Blöcke angeben, wie in späteren Abschnitten erläutert.)

Die VE-ID muss auf jedem PE konfiguriert werden. Identifiziert die PE-Router in der VPLS-Domäne.

Die VE-Blockgröße (VBS) ist die Größe des Label-Blocks und hat einen Standardwert von 10. Wenn 've range' konfiguriert ist, ist es dieser Wert. 've range' kann als [11-100] konfiguriert werden.

Die Label Base (LB) ist der erste Labelwert eines freien Labelsatzes, der vom PE-Router für diese VPLS-Domäne reserviert werden kann.

VE Block Offset (VBO) ist der Offset-Wert, der verwendet wird, wenn mehrere Label-Blöcke von einem PE-Router erstellt werden müssen. VBO wird mit der folgenden Gleichung berechnet: VBO = RND(VE-ID/VBS) * VBS

Dies sind Beispielberechnungen:

- Wenn VBS = 8 und VE-ID = 2, VBO = RND(2/8) * 8 = 1

- Wenn VBS = 8 und VE-ID = 20, VBO = RND (20/8) * 8 = 16

- Wenn VBS = 50 und VE-ID = 199, VBO = RND (199/50) * 50 = 150

- Wenn VBS = 50 und VE-ID = 1002, VBO = RND (1002/50) * 50 = 1000

Der den Remote-PE-Routern angekündigte Label-Block ist {LB, LB + 1, ? , LB + VBS - 1}. Der Label-Block wird durch LB und VBS definiert. Der Block beginnt bei LB und endet mit (LB + VBS - 1).

Jeder PE-Router kann bei Bedarf mehrere Label-Blöcke erstellen. Der Router muss sicherstellen, dass es sich um einen kontinuierlichen Satz freier Etiketten handelt.

Route Distinguisher und Route Targets

Beispielkonfiguration von PE1

router bgp 1

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp

ve id 1001

ve range 50

route-target export 32:64

route-target import 32:64

mpls label range 10000 20000

Dies ist eine Erklärung für die Konfigurationswerte:

- Die VPN-ID ist als 100 konfiguriert.

- Der RD stammt aus [ASN:vpn-ID], sofern kein RD ausdrücklich konfiguriert wurde. Hier ist der RD 1:100.

- Die Import-/Export-Route Targets sind 32:64.

- Die LB liegt im Bereich [10000 2000]. Der genaue LB-Wert hängt von der ersten Gruppe freier, kontinuierlicher lokaler Labels ab, die groß genug sind, um alle vom VBS festgelegten Labels zu enthalten.

- Die VE-ID ist als 1001 konfiguriert.

- Das VBS ist als 50 konfiguriert.

- Das VBO wird wie folgt berechnet: VBO = RND(VE-ID/VBS) * VBS oder RND(1001/50) * 50 = 1000.

Labelbereich überprüfen

Sie können den Bezeichnungsbereich mit dem Befehl show mpls label range überprüfen:

PE1#show mpls label range

Downstream Generic label region: Min/Max label: 10000/20000

Es gibt einen standardmäßigen Label-Bereich für jede Plattform, den Sie mit dem Befehl mpls label range ändern können.

Labels überprüfen

Mit dem Befehl show mpls forward-table können Sie die tatsächlich verwendeten Labels für einen Label-Block in der LFIB (Label Forwarding Information Base) überprüfen.

PE1#show mpls forwarding-table

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop   Label

Label      or Tunnel Id     Switched      interface

10000      No Label   lbl-blk-id(1:0)  0             drop

10001      No Label   lbl-blk-id(1:1)  0             drop

10002      No Label   lbl-blk-id(1:2)  0             drop

?

10048      No Label   lbl-blk-id(1:48) 0             drop

10049      No Label   lbl-blk-id(1:49) 0             drop

10050      Pop Label  10.100.1.4/32    0             Et1/0      10.1.1.4

In diesem Beispiel reservierte PE1, der lokale Router, 50 lokale Labels für den Label-Block. 'lbl-blk-id(1:0)' bezeichnet eine Block-ID von 1 und eine Block-Instanz von 0, die das erste Label des Blocks identifiziert. Das letzte Label dieses Blocks ist das Label 10049.

Die "Outgoing"-Schnittstelle im LFIB ist "drop", solange kein PW für dieses lokale Label eingerichtet ist. Wenn ein PW eingerichtet ist, lautet die Schnittstelle "Ausgehend" "none point2point".

Label-Block überprüfen

Der zugewiesene Label-Block kann auch mit dem Befehl show mpls infrastructure lfd block-database summary überprüft werden, wenn 'service internal' konfiguriert ist.

PE1#show mpls infrastructure lfd block-database summary

Block-DB entry for block-id : 0x1

Block-size : 50, App-Key type : AToM PWID, Labels : 10000 - 10049

LB ist 10.000. In diesem Beispiel liegt der Label-Block zwischen LB und (LB + VBS - 1) oder zwischen 10.000 und (10.000 + 50 - 1) = 10.049.

Angezeigtes Präfix prüfen

Sie können das angegebene Präfix mit dem Befehl show bgp l2vpn vpls rd 1:100 überprüfen:

PE1#show bgp l2vpn vpls rd 1:100

BGP table version is 3, local router ID is 10.100.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>  1:100:VEID-1001:Blk-1000/136

0.0.0.0                            32768 ?

Präfix im Detail anzeigen

Um dieses Präfix detailliert anzuzeigen, verwenden Sie den Befehl show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000. Beachten Sie, dass Sie die VE-ID und den Label-Block angeben, die sich im NLRI (Blk-1000) befinden.

PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000

BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 3

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Advertised to update-groups:

1

Refresh Epoch 1

Local

0.0.0.0 from 0.0.0.0 (10.100.1.1)

Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best

AGI version(0), VE Block Size(50) Label Base(10000)

Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

rx pathid: 0, tx pathid: 0x0

NLRI zeigt den RD von 1:100, die VE-ID von 1001, das VBO von 1000, die VBS von 50 und die LB von 10000.

Die erweiterte Layer2 Info-Community enthält folgende Informationen:

- Der Encap-Typ ist 19 (VPLS).

- Kontrollflags: C = 0 (ein Kontrollwort darf nicht gesetzt werden); S = 0 (keine sequenzielle Zustellung von Frames)

- MTU beträgt 1.500

Die erweiterte RT-Community enthält folgende Informationen:

- RT 1:100

- RT 32:64

Anmerkung: Der Standard-VBS (10) ist klein, sodass lokale Labels nicht verschwendet werden.

Anzeigen, Empfangen und Verarbeiten von Label-Blöcken in BGP-Update-Nachrichten

Wenn ein lokaler PE-Router einen L2VPN VPLS-Präfix-/Label-Block meldet, muss jeder Remote-PE-Router versuchen, ein Label aus diesem Bereich zu wählen, um es als Remote-VC-Label zu verwenden.

- Wenn der Remote-PE-Router erfolgreich ist, wird dieses Remote-VC-Label verwendet und in der Datenebene programmiert. Es gibt keine weitere Signalisierung durch BGP.

- Wenn der Remote-PE-Router ausfällt, muss er warten, bis vom lokalen PE-Router ein weiteres L2VPN-VPLS-Präfix angekündigt wird. Versuchen Sie dann, ein anderes Remote-VC-Label aus diesem Label-Block auszuwählen.

Angenommen, PE1 ist ein lokaler PE mit der vorherigen Konfiguration und PE2 ein Remote-PE mit dieser Konfiguration:

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp

ve id 1002

ve range 50

!

mpls label range 3000 60000

PE2: BGP-Update empfangen

PE2 erhält dieses BGP-Update von PE1:

PE2#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000

BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 5

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 2

Local

10.100.1.1 (metric 21) from 10.100.1.4 (10.100.1.4)

Origin incomplete, metric 0, localpref 100, valid, internal, best

AGI version(0), VE Block Size(50) Label Base(10000)

Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

Originator: 10.100.1.1, Cluster list: 10.100.1.4

rx pathid: 0, tx pathid: 0x0

PE2: Label suchen

PE2 muss ein Label finden, das als Remote-VC-Label für das PW zu PE1 verwendet werden kann.

PE2 muss zuerst bestimmen, ob das VBO im Bereich seiner Konfiguration liegt. PE2 prüft seine VE-ID mit dem von PE1 angegebenen Bereich und berechnet VBO <= VE-ID < VBO + VBS. In diesem Fall ist 1000 <= 1002 < 1000 + 50, sodass PE2 erfolgreich ist.

PE2 muss dann ein Remote-VC-Label auswählen. Das vom Remote-PE zu verwendende VC-Label (Demultiplexer) wird als (LB + VE-ID - VBO) berechnet.

Vom vorherigen Präfix ist LB 10.000 und VBO 1000. Die VE-ID ist die von PE2 und lautet 1002. Das PE2-Picks-Label (LB + VE-ID - VBO) = (10.000 + 1002 - 1.000) = 10.002.

Verwenden Sie den Befehl show l2vpn vfi name one, um Folgendes zu überprüfen:

PE2#show l2vpn vfi name one

Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No

VFI name: one, state: up, type: multipoint, signaling: BGP

VPN ID: 100, VE-ID: 1002, VE-SIZE: 50

RD: 1:100, RT: 1:100

Bridge-Domain 100 attachment circuits:

Pseudo-port interface: pseudowire100001

Interface          Peer Address    VE-ID  Local Label  Remote Label    S

pseudowire100002   10.100.1.1      1001   3101         10002           Y

PE2: Präfix an PE1 senden

PE2 sendet dann sein Präfix an PE1:

PE1#show bgp l2vpn vpls rd 1:100 ve-id 1002 block-offset 1000

BGP routing table entry for 1:100:VEID-1002:Blk-1000/136, version 4

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 1

Local

10.100.1.2 (metric 21) from 10.100.1.4 (10.100.1.4)

Origin incomplete, metric 0, localpref 100, valid, internal, best

AGI version(0), VE Block Size(50) Label Base(3100)

Extended Community: RT:1:100 L2VPN L2:0x0:MTU-1500

Originator: 10.100.1.2, Cluster list: 10.100.1.4

rx pathid: 0, tx pathid: 0x0

PE1: Label suchen

PE1 ist jetzt der Remote-PE und muss ein Label finden, das als Remote-VC-Label für das PW zu PE2 verwendet werden kann.

PE1 muss zuerst bestimmen, ob das VBO im Bereich seiner Konfiguration liegt. PE1 prüft seine VE-ID mit dem vom PE2 angegebenen Bereich und berechnet VBO <= VE-ID < VBO + VBS. In diesem Fall ist 1000 <= 1001 < 1000 + 50, sodass PE1 erfolgreich ist.

PE1 muss dann ein Remote-VC-Label auswählen. Das vom Remote-PE zu verwendende VC-Label (Demultiplexer) wird als (LB + VE-ID - VBO) berechnet.

Vom vorherigen Präfix ist LB 3100 und VBO 1000. Die VE-ID ist die von PE1 und lautet 1001. Das PE1-Picks-Label (LB + VE-ID - VBO) = (3100 + 1001 - 1000) = 3101.

Verwenden Sie den Befehl show l2vpn vfi name one, um Folgendes zu überprüfen:

PE1#show l2vpn vfi name one

Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No

VFI name: one, state: up, type: multipoint, signaling: BGP

VPN ID: 100, VE-ID: 1001, VE-SIZE: 50

RD: 1:100, RT: 1:100, 32:64

Bridge-Domain 1 attachment circuits:

Pseudo-port interface: pseudowire100001

Interface          Peer Address    VE-ID  Local Label  Remote Label    S

pseudowire100002   10.100.1.2      1002   10002        3101            Y

Zusätzliche Überprüfungsbefehle

PE1#show mpls l2transport vc detail

Local interface: VFI one vfi up

Interworking type is Ethernet

Destination address: 10.100.1.2, VC ID: 100, VC status: up

Output interface: Et1/0, imposed label stack {17 3101}

Preferred path: not configured

Default path: active

Next hop: 10.1.1.4

Create time: 02:06:08, last status change time: 02:06:08

Last label FSM state change time: 02:06:08

Signaling protocol: BGP

Status TLV support (local/remote)   : Not Applicable

LDP route watch                   : Not Applicable

Label/status state machine        : established, LruRru

Last local dataplane   status rcvd: No fault

Last BFD dataplane     status rcvd: Not Applicable

Last BFD peer monitor  status rcvd: Not Applicable

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: Not Applicable

Last remote LDP TLV    status rcvd: Not Applicable

Last remote LDP ADJ    status rcvd: Not Applicable

MPLS VC labels: local 10002, remote 3101

Group ID: local 0, remote 0

MTU: local 1500, remote 1500

Control Word: Off

Dataplane:

SSM segment/switch IDs: 8195/4097 (used), PWID: 3

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

PE1#show mpls infrastructure lfd block-database id 1

Block-DB entry for block-id : 0x1

Block-size : 50, App-Key type : AToM PWID

App-Key entries:

l2ckt(1)  10000

l2ckt(2)  10001

l2ckt(3)  10002

l2ckt(4)  10003

l2ckt(5)  10004

l2ckt(6)  10005

l2ckt(7)  10006

l2ckt(8)  10007

l2ckt(9)  10008

l2ckt(10)  10009

l2ckt(11)  10010

l2ckt(12)  10011

l2ckt(13)  10012

l2ckt(14)  10013

l2ckt(15)  10014

l2ckt(16)  10015

l2ckt(17)  10016

l2ckt(18)  10017

l2ckt(19)  10018

l2ckt(20)  10019

l2ckt(21)  10020

l2ckt(22)  10021

l2ckt(23)  10022

l2ckt(24)  10023

l2ckt(25)  10024

l2ckt(26)  10025

l2ckt(27)  10026

l2ckt(28)  10027

l2ckt(29)  10028

l2ckt(30)  10029

l2ckt(31)  10030

l2ckt(32)  10031

l2ckt(33)  10032

l2ckt(34)  10033

l2ckt(35)  10034

l2ckt(36)  10035

l2ckt(37)  10036

l2ckt(38)  10037

l2ckt(39)  10038

l2ckt(40)  10039

l2ckt(41)  10040

l2ckt(42)  10041

l2ckt(43)  10042

l2ckt(44)  10043

l2ckt(45)  10044

l2ckt(46)  10045

l2ckt(47)  10046

l2ckt(48)  10047

l2ckt(49)  10048

l2ckt(50)  10049

PE1#show l2vpn atom vc destination 10.100.1.2

Service

Interface Dest Address    VC ID      Type   Name                     Status

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

pw100002  10.100.1.2      100        vfi    one                      UP

PE1#show l2vpn atom vc destination 10.100.1.2 detail

pseudowire100002 is up, VC status is up PW type: Ethernet

Create time: 02:11:13, last status change time: 02:11:13

Last label FSM state change time: 02:11:13

Destination address: 10.100.1.2 VC ID: 100

Output interface: Et1/0, imposed label stack {17 3101}

Preferred path: not configured

Default path: active

Next hop: 10.1.1.4

Member of vfi service one

Bridge-Domain id: 1

Service id: 0xe7000001

Signaling protocol: BGP

Local VE ID: 1001, Remote VE ID: 1002

Status TLV support (local/remote)         : Not Applicable

LDP route watch                         : Not Applicable

Label/status state machine              : established, LruRru

Local dataplane status received         : No fault

BFD dataplane status received           : Not Applicable

BFD peer monitor status received        : Not Applicable

Status received from access circuit     : No fault

Status sent to access circuit           : No fault

Status received from pseudowire i/f     : No fault

Status sent to network peer             : Not Applicable

Status received from network peer       : Not Applicable

Adjacency status of remote peer         : Not Applicable

Bindings

Parameter    Local                          Remote

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

Label        10002                          3101

Group ID     0                              0

Interface

MTU          1500                           1500

Control word off                            off

PW type      Ethernet                       Ethernet

VCCV CV type 0x32                           0x32

LSPV [2], BFD/Raw [5]          LSPV [2], BFD/Raw [5]

BFD/Raw + sig [6]              BFD/Raw + sig [6]

VCCV CC type 0x07                           0x07

CW [1], RA [2], TTL [3]       CW [1], RA [2], TTL [3]

Status TLV   disabled                       N/A

Dataplane:

SSM segment/switch IDs: 8195/4097 (used), PWID: 3

Rx Counters

0 input transit packets, 0 bytes

0 drops, 0 seq err

Tx Counters

0 output transit packets, 0 bytes

0 drops

PE1#show l2vpn signaling rib rd 1:100

+- Origin of entry                                (i=iBGP/e=eBGP)

| +- Provisioned                                  (Yes/No)?

| | +- Stale entry                                (Yes/No)?

| | |

v v v

O P S     RD             VE-ID    VBO     VBS       LB       Next-Hop

-+-+-+-----------------+-------+-------+-------+---------+-----------------+

i Y N  1:100             1002    1000    50      3100       10.100.1.2

PE1#show l2vpn signaling rib rd 1:100 detail

Route 1:100:1002 (epoch:0) from iBGP peer 10.100.1.2

Provisioned (Y) Stale (N)

Route-Target: 1:100

NLRI [FF000001]

VE-ID:1002 VBO:1000 VBS:50 LB:3100

MTU: 1500 Control Word: off

RIB Filter [27000002]

RD: 1:100

VE-ID: 1001, VBO: 1000, VBS: 50 LB: 10000

Forwarder [58000001] VFI one

PE1#show l2vpn atom pwid

AToM Pseudowire IDs: In use: 50, In holddown: 0

Label  Peer-Address    VCID       PWID       In-Use FirstUse ResuedAt FreedAt

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

10000  0.0.0.0         0          1          Yes    00:00:15 Never    Never

10001  0.0.0.0         0          2          Yes    00:00:15 Never    Never

10002  10.100.1.2      100        3          Yes    00:00:15 Never    Never

10003  0.0.0.0         0          4          Yes    00:00:15 Never    Never

10004  0.0.0.0         0          5          Yes    00:00:15 Never    Never

PE1#show l2vpn atom summary

Destination address: 10.100.1.2, total number of vc: 1

0 unknown, 1 up, 0 down, 0 admin down, 0 recovering, 0 standby, 0 hotstandby

1 active vc on MPLS interface Et1/0

Mehrere vom PE-Router für ein VFI angekündigte L2VPN-VPLS-Präfixe

Möglicherweise muss ein PE mehrere Label-Bocks für eine virtuelle Weiterleitungsinstanz (VFI) angeben.

Wenn die VE-ID des Remote-PE nicht in den vom lokalen PE angegebenen Bereich fällt, kann der Remote-PE kein Remote-Label für den PW auswählen. Diese Berechnung, die zuvor beschrieben wurde, lautet VBO <= VE-ID < VBO + VBS.

Wenn diese Überprüfung fehlschlägt, liegt die VE-ID des Remote-PE außerhalb des zulässigen Bereichs. Der Remote-PE ignoriert das Präfix, das vom lokalen PE empfangen wurde. Der lokale PE merkt, dass der Remote-PE außerhalb der Reichweite liegt, wenn er das Präfix erhält, das der Remote-PE anzeigt. Der lokale PE muss festlegen, welches Remote-Label für diesen Remote-PE-Router verwendet werden soll. Der lokale PE sendet außerdem ein neues zweites Präfix für einen neuen Block lokaler Labels an den Remote-PE, das der Remote-PE verwenden kann, um ein Remote-Label auszuwählen.

PE1-Konfiguration

Das vorherige Beispiel wird hier fortgesetzt. PE1 verfügt noch über:

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp

ve id 1001

ve range 50

route-target export 32:64

route-target import 32:64

!

mpls label range 10000 20000

PE2-Konfiguration

PE2 hat jetzt die VE-ID 1002 und folgende Konfiguration:

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp

ve id 10002

ve range 50

!

mpls label range 3000 60000

Anfängliche Label-Blöcke

PE1 und PE2 beginnen mit diesen anfänglichen Label-Blöcken.

PE1#show bgp l2vpn vpls rd 1:100

BGP table version is 2, local router ID is 10.100.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>  1:100:VEID-1001:Blk-1000/136

0.0.0.0                            32768 ?

PE2#show bgp l2vpn vpls rd 1:100

BGP table version is 3, local router ID is 10.100.1.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>  1:100:VEID-10002:Blk-10000/136

0.0.0.0                            32768 ?

PE1 und PE2 Exchange

Verwenden Sie den Befehl debug bgp l2vpn vpls updates, um den Austausch von PE1 und PE2 zu überprüfen. Verwenden Sie dann den Befehl show bgp l2vpn vpls rd 1:100, um Details zu überprüfen.

PE1#

%BGP-5-ADJCHANGE: neighbor 10.100.1.4 Up

BGP(9): update formatted for 1:100:VEID-1001:Blk-1000:VBS-50:LB-10000/136 VE ID

1001 VE Block Offset 1000 VE Block Size 50 Label Base 10000 /136

BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-1000:VBS-50:

LB-10000/136, next 10.100.1.1, metric 0, path Local, extended community RT:1:100

RT:32:64 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?,

localpref 100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended

community RT:1:100 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136

BGP(9): bump net 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136, non bpath  added

BGP(9): nettable_walker called for 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136

BGP(9): best path[0] 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 source

10.100.1.1 nh 10.100.1.2 vpls-id: L2VPN L2:0x0:MTU-1500

BGP(9): add XC RIB route 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 masklen 136

L2VPN L2:0x0:MTU-1500 pathcount: 1 [0] LDP source:10.100.1.1 nexthop:10.100.1.2

RT:1:100

BGP(9): bump net 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136, non bpath  added

BGP(9): nlri update add VBS 50 LB 10053

BGP(9): nlri update add export extcomm count 4

BGPSSA ssacount is 0

BGP(9): update formatted for 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136 VE ID

10002 VE Block Offset 10000 VE Block Size 50 Label Base 3000 /136

BGP(9): nettable_walker called for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136

BGP(9): nettable_walker 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136 route sourced

locally

BGP(9): update formatted for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136 VE ID

1001 VE Block Offset 10000 VE Block Size 50 Label Base 10053 /136

BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-10000:VBS-50:

LB-10053/136, next 10.100.1.1, metric 0, path Local, extended community RT:1:100

RT:32:64 L2VPN L2:0x0:MTU-1500 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?, localpref 100,

metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended community

RT:1:100 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136

BGP(9): bump net 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136, non bpath  added

BGP(9): nettable_walker called for 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136

BGP(9): best path[0] 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 source 10.100.1.1

nh 10.100.1.2 vpls-id: L2VPN L2:0x0:MTU-1500

BGP(9): add XC RIB route 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 masklen 136

L2VPN L2:0x0:MTU-1500 pathcount: 1 [0] LDP source:10.100.1.1 nexthop:10.100.1.2

RT:1:100

BGP(9): update formatted for 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136 VE ID

10002 VE Block Offset 1000 VE Block Size 50 Label Base 3053 /136

BGPSSA ssacount is 0

PE1#show bgp l2vpn vpls rd 1:100

BGP table version is 5, local router ID is 10.100.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>  1:100:VEID-1001:Blk-1000/136

0.0.0.0                            32768 ?

*>  1:100:VEID-1001:Blk-10000/136

0.0.0.0                            32768 ?

*>i 1:100:VEID-10002:Blk-1000/136

10.100.1.2               0    100      0 ?

*>i 1:100:VEID-10002:Blk-10000/136

10.100.1.2               0    100      0 ?

PE2#show bgp l2vpn vpls rd 1:100

BGP table version is 6, local router ID is 10.100.1.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:100

*>i 1:100:VEID-1001:Blk-1000/136

10.100.1.1               0    100      0 ?

*>i 1:100:VEID-1001:Blk-10000/136

10.100.1.1               0    100      0 ?

*>  1:100:VEID-10002:Blk-1000/136

0.0.0.0                            32768 ?

*>  1:100:VEID-10002:Blk-10000/136

0.0.0.0                            32768 ?

Analyse von PE1 und PE2 Exchange

PE1 und PE2 haben nun zwei Label-Blöcke miteinander kommuniziert.

PE1 kündigt zunächst ein erstes BGP-Update an PE2 an:

BGP(9): update formatted for 1:100:VEID-1001:Blk-1000:VBS-50:LB-10000/136 VE ID

1001 VE Block Offset 1000 VE Block Size 50 Label Base 10000 /136

BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-1000:VBS-50:

LB-10000/136, next 10.100.1.1, metric 0, path Local, extended community

RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

Bei diesem Update ist der NLRI entsprechend der Konfiguration auf PE1 eingestellt.

Anschließend erhält PE1 das erste BGP-Update von PE2.

BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?, localpref

100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4, extended

community RT:1:100 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-10000:VBS-50:LB-3000/136

PE2 gibt das erste Präfix mit den Werten VE-ID 10002, VBO = 10000, VBS = 50, LB = 3000 an.

PE1 stellt fest, dass PE2 seit dem Start von PE1 mit dem Label Block LB to (LB + VBS - 1) oder von 10.000 bis (10.000 + 50 - 1) = 10.049 außerhalb des Bereichs liegt.

PE1 muss bestimmen, ob das VBO im Bereich seiner Konfiguration liegt. Daher muss die VE-ID von PE2 mit dem von PE1 angegebenen Bereich abgeglichen werden. Die Berechnung lautet VBO <= VE-ID < VBO + VBS. In diesem Fall 1000 <= 10002 < 1000 + 50, was nicht wahr ist. Daher muss PE1 einen neuen Label-Block senden, um die Out-of-Range-VE-ID von PE2 zu unterstützen. Als Reaktion auf das anfängliche Update von PE2 formatiert PE1 ein neues BGP-Update und sendet es an PE2. PE1 verwendet jetzt ein neues VBO von 10.000.

BGP(9): update formatted for 1:100:VEID-1001:Blk-10000:VBS-50:LB-10053/136

VE ID 1001 VE Block Offset 10000 VE Block Size 50 Label Base 10053 /136

BGP(9): (base) 10.100.1.4 send UPDATE (format) 1:100:VEID-1001:Blk-10000:

VBS-50:LB-10053/136, next 10.100.1.1, metric 0, path Local, extended

community RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500 L2VPN L2:0x0:MTU-1500

Für PE1 ist das VBO 10.000, das VBS 50, das LB 10053. Die Prüfung für PE2 lautet VBO <= VE-ID < VBO + VBS. In diesem Fall ist 10000 <= 10002 < 10000 + 50, was wahr ist. PE2 kann ein Remote-Label aus diesem neuen Label-Block [10053 - 10102] aus PE1 auswählen. Mit anderen Worten, PE1 hat einen neuen Label-Block hinzugefügt, um PE2 unterzubringen, und zwei BGP-Aktualisierungsnachrichten gesendet.

Das Gleiche geschieht in die entgegengesetzte Richtung. PE2 erhält das erste BGP-Update von PE1. Dieses Update enthält die Werte VE-ID 1001, VBO = 1000, VBS = 50, LB = 10000.

PE2 stellt fest, dass die VE-ID von PE1 bei der ursprünglichen Aktualisierung des PE2 außerhalb des zulässigen Bereichs liegt. Die Prüfung für PE1 lautet VBO <= VE-ID < VBO + VBS oder 1000 <= 1001 < 10000 + 50. Als Reaktion darauf sendet PE2 dieses zweite BGP-Update mit einem neuen Label-Block [3053 - 3102], der die VE-ID von 1001 von PE1 übernimmt, da die PE1-Prüfung VBO <= VE-ID < VBO + VBS oder 1000 <= 1001 < 10000 + 50.

BGP(9): 10.100.1.4 rcvd UPDATE w/ attr: nexthop 10.100.1.2, origin ?,

localpref 100, metric 0, originator 10.100.1.2, clusterlist 10.100.1.4,

extended community RT:1:100 L2VPN L2:0x0:MTU-1500

BGP(9): 10.100.1.4 rcvd 1:100:VEID-10002:Blk-1000:VBS-50:LB-3053/136

Präfixdetails

Dies sind die Details der beiden Präfixe von PE1:

PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000

BGP routing table entry for 1:100:VEID-1001:Blk-1000/136, version 2

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 1

Local

0.0.0.0 from 0.0.0.0 (10.100.1.1)

Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best

AGI version(0), VE Block Size(50) Label Base(10000)

Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

rx pathid: 0, tx pathid: 0x0

PE1#show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 10000

BGP routing table entry for 1:100:VEID-1001:Blk-10000/136, version 4

Paths: (1 available, best #1, table L2VPN-VPLS-BGP-Table)

Not advertised to any peer

Refresh Epoch 1

Local

0.0.0.0 from 0.0.0.0 (10.100.1.1)

Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best

AGI version(0), VE Block Size(50) Label Base(10053)

Extended Community: RT:1:100 RT:32:64 L2VPN L2:0x0:MTU-1500

L2VPN L2:0x0:MTU-1500

rx pathid: 0, tx pathid: 0x0

Hier verfügen zwei PE-Router über nicht zusammenhängende Nummernschemata, wodurch jeder PE zwei BGP-Updates sendet. Wenn es viele PE-Router mit nicht zusammenhängenden Nummernschemata gibt, nimmt die Anzahl der BGP-Updates schnell sehr stark zu.

www.cisco.com: "Beispielsweise sind VE-ID-Nummerierungssequenzen wie 1, 2, 3 oder 501, 502, 503 gut, da die VE-IDs zusammenhängend sind. Ein Nummerierungsschema wie 100, 200, 300 ist schlecht, weil es nicht zusammenhängend ist."

Die ersten Beispiele für 1, 2, 3 oder 501, 502, 503 sind zusammenhängende Zahlen, daher muss jeder PE-Router nur ein L2VPN VPLS-Präfix senden. Im dritten Beispiel (100, 200, 300) muss jeder PE viele L2VPN-VPLS-Präfixe senden. Bei nicht zusammenhängenden Zahlen würde ein großer genügend VE-Bereich die Anzahl der zu kündigenden Präfixe verringern. Die Anzahl der reservierten (verschwendeten) Etiketten ist jedoch noch größer.

Interoperabilität

Wenn der BGP Route Reflector (RR) eine Software ausführt, die RFC 4761 nicht versteht, aber RFC 4762 unterstützt, wird der spezielle Konfigurationsbefehl x.x.x.x mit Präfixlänge 2 auf dem RR benötigt, damit er die für RFC 4761 verwendeten BGP-Updates widerspiegelt.

Präfixe werden normalerweise mit einer Länge von 1 Byte gesendet. Die Cisco IOS-Software implementierte den Entwurf "Draft-ietf-l2vpn-signaling-08", der später RFC 6074 wurde. Zu diesem Zeitpunkt wurde ein Längenfeld von 1 Byte gewählt, das die Länge in Bits angibt.

RFC 6074-Bereitstellung, automatische Erkennung und Signalisierung in Layer 2 Virtual Private Networks (L2VPNs)  legt fest, dass die NLRI-Codierung für die automatische BGP-Erkennung eine Länge von 2 Byte haben soll. Die 2 Byte geben an, wie viele Byte des Präfix im Präfix mit variabler Länge folgen.

In Abschnitt 7 von RFC 6074, "BGP-AD und VPLS-BGP Interoperability", heißt es:

"Sowohl BGP-AD als auch VPLS-BGP [RFC4761] verwenden dasselbe AFI/SAFI. Damit BGP-AD und VPLS-BGP gleichzeitig vorhanden sind, muss die NLRI-Länge als Demultiplexer verwendet werden.

Der NLRI BGP-AD hat eine NLRI-Länge von 12 Byte, die nur einen 8-Byte-RD und eine 4-Byte-VSI-ID enthält. VPLS-BGP [RFC4761] verwendet eine NLRI-Länge von 17 Byte. Daher müssen bei Implementierungen von BGP-AD NLRIs ignoriert werden, die größer als 12 Byte sind."

Wenn der Befehl neighbor x.x.x.x prefix-length-size 2 auf den RRs nicht vorhanden ist, wird der BGP-Nachbar nicht angezeigt, und der RR interpretiert das Längenfeld nur als 1 Byte. Diese Benachrichtigung wird auf der RR angezeigt:

%BGP-3-NOTIFICATION: sent to neighbor 10.100.1.2 3/10 (illegal network) 1 bytes FF

%BGP-4-MSGDUMP: unsupported or mal-formatted message received from 10.100.1.2:

FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 005E 0200 0000 4780 0E1C 0019 4104 0A64

0102 0000 1100 0000 0100 0000 6427 1227 1000 3200 BB80 4001 0102 4002 0080 0404

*Feb 15 12:14:11.561: %BGP_SESSION-5-ADJCHANGE: neighbor 10.100.1.2 L2VPN Vpls

topology base removed from session  BGP Notification sent

*Feb 15 12:14:11.561: %BGP_SESSION-5-ADJCHANGE: neighbor 10.100.1.2 IPv4 Unicast

topology base removed from session  BGP Notification sent

Diese Benachrichtigung wird auf dem PE-Router angezeigt:

%BGP-3-NOTIFICATION: received from neighbor 10.100.1.4 3/10 (illegal network)

1 bytes FD

Dies liegt daran, dass bei der ursprünglichen Implementierung der automatischen BGP-Erkennung in der Cisco IOS-Software das Längenfeld 1 Byte betrug.

Wenn Sie den Befehl neighbor x.x.x.x prefix-length-size 2 auf den RR setzen, werden die Benachrichtigungen nicht angezeigt.

router bgp 1

neighbor 10.100.1.2 remote-as 1

neighbor 10.100.1.2 update-source Loopback0

!

address-family l2vpn vpls

neighbor 10.100.1.2 activate

neighbor 10.100.1.2 send-community extended

neighbor 10.100.1.2 prefix-length-size 2

neighbor 10.100.1.2 route-reflector-client