VPLS mit BGP-Signalisierung - Technische Anmerkung
Inhalt
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:
- 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.
- 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.
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
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
Feedback