VPLS avec note technique de signalisation BGP
Contenu
Introduction
Ce document décrit la détection automatique basée sur le protocole BGP (Border Gateway Protocol) pour un service VPLS (Virtual Private LAN Service) avec signalisation BGP. La détection automatique est un moyen pour un périphérique fournisseur (PE) d’apprendre quels périphériques distants sont membres d’un domaine VPLS donné.La signalisation est un moyen pour un périphérique d’apprendre le pseudo-libellé attendu par un périphérique distant donné pour un domaine VPLS donné.
Reportez-vous aux documents suivants du Groupe de travail sur l'ingénierie Internet :
- RFC 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling décrit la détection automatique BGP avec signalisation LDP (Label Distribution Protocol) pour VPLS (également appelé Martini).
- RFC 4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling décrit la détection automatique BGP et la signalisation BGP pour VPLS (également appelée Kompella).
Ce document porte sur la RFC 4761. Avec la RFC 4761, les informations d'accessibilité de la couche réseau BGP (NLRI) des mises à jour BGP contiennent les informations pour la détection automatique et la signalisation. Lorsque les routeurs PE distants reçoivent cette mise à jour BGP, ils disposent de toutes les informations nécessaires pour configurer un maillage complet de pseudocâbles pour VPLS. La détection automatique BGP et la signalisation BGP utilisent la même famille d'adresses BGP.
L'interface de ligne de commande (CLI) et le résultat proviennent du logiciel Cisco IOS®. La configuration et les fonctionnalités sont très similaires dans les logiciels Cisco IOS-XR et Cisco NX-OS.
Problème
Le VPLS consiste en un ensemble de pseudocâbles (PW) de manière point à multipoint. Jusqu’à présent, le protocole LDP était utilisé pour signaler les pseudocâbles entre les routeurs PE. Ainsi, une session LDP ciblée a signalé quelles étiquettes utiliser pour quel pseudocâble entre une paire de routeurs PE. Vous pouvez configurer manuellement l'ensemble de routeurs PE qui ont participé à un domaine VPLS, ou utiliser BGP pour découvrir automatiquement la configuration. Afin d'effectuer cette détection automatique, BGP a annoncé quel PE était membre du domaine VPLS. Cependant, même avec la détection automatique BGP, le protocole LDP a été utilisé pour signaler les étiquettes de circuit virtuel (VC) MPLS (Multiprotocol Label Switching) et l'ID de pseudocâble.
Il est maintenant possible d'utiliser BGP pour signaler les pseudocâbles entre les routeurs PE.
Lorsqu’un pseudocâble doit être configuré entre deux routeurs, les autres routeurs n’ont pas besoin des informations associées à ce pseudocâble. Par exemple, ces informations sont l'étiquette de circuit virtuel à utiliser.
Avec le protocole LDP comme protocole de signalisation pour configurer des pseudo-câbles, les informations sont uniquement reçues par la paire de routeurs, car le protocole LDP effectue la signalisation point à point.
Avec BGP comme protocole de signalisation pour configurer des pseudo-câbles, les informations sont reçues par tous les autres routeurs car le protocole BGP interne (iBGP) effectue la signalisation de manière point à multipoint. iBGP a une exigence de maillage global, de sorte qu'un routeur envoie une mise à jour iBGP à tous les autres routeurs iBGP. Cela peut également être fait avec un réflecteur de route.
Avec iBGP comme protocole de signalisation, il y aurait deux méthodes pour envoyer des mises à jour :
- Chaque routeur PE annonce une mise à jour BGP à tous les voisins iBGP pour chaque PW ; à chaque fois, une étiquette VC MPLS est jointe. Ainsi, un routeur PE enverrait autant de mises à jour BGP qu'il y a de routeurs PE. Cependant, l'étiquette VC associée à la mise à jour BGP ne peut être utilisée que par l'un des routeurs PE - le routeur PE à l'autre extrémité du PW.
- Pour éviter ce problème de nombre élevé de mises à jour BGP, une architecture a été conçue par laquelle un routeur PE local envoie un ensemble ou un bloc d'étiquettes VC locales à tous les routeurs PE distants. Chaque routeur PE distant sélectionne une des étiquettes VC à utiliser comme étiquette VC distante pour le PW vers le routeur PE local. Le routeur PE distant doit sélectionner une étiquette VC distante de manière unique afin qu'aucun autre routeur PE ne sélectionne la même étiquette VC dans le bloc d'étiquettes annoncé. Comme un bloc d'étiquettes est envoyé, il doit y avoir suffisamment d'étiquettes disponibles pour desservir tous les PW possibles qui pourraient être configurés, mais il ne devrait pas y avoir autant d'étiquettes réservées qu'elles ne sont pas utilisées et gaspillées.
Ce document décrit comment BGP est utilisé pour signaler les pseudocâbles ; Notez que BGP est également utilisé pour la détection automatique en même temps.
Architecture de la solution
Puisqu’il s’agit d’un VPLS, un protocole de signalisation saut par saut est toujours nécessaire dans le coeur afin de transporter les paquets étiquetés du PE au routeur PE. Cette fonction de transport dans le coeur doit toujours être exécutée par l'ingénierie de trafic LDP ou MPLS.
BGP doit envoyer les informations nécessaires afin de configurer les pseudo-câbles de manière point à multipoint nécessaire à VPLS. Ces informations de signalisation incluent :
- Identification du point d’extrémité du routeur PE
- Identité VPLS
- Bloc d'étiquettes MPLS
- Informations d’encapsulation
Identification du point de terminaison du routeur PE
L'identification du point de terminaison du routeur PE est déterminée à partir du routeur PE qui est l'expéditeur BGP de la mise à jour.
La mise à jour BGP relative au VPLS des réseaux privés virtuels de couche 2 (L2VPN) est identifiée par AFI/SAFI 25/65. Cette famille d'adresses est négociée lorsque BGP envoie le message OPEN.
Identité VPLS et étiquettes MPLS
L’INLR, également appelé préfixe, contient les informations sur l’identité VPLS et le bloc d’étiquettes MPLS. Son codage a une longueur totale de 19 octets :
+------------------------------------+
| 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) |
+------------------------------------+
Le séparateur de route (RD) se rapporte à l’identité du VPLS.
L'ID d'extension virtuelle (VE), le décalage de bloc VE, la taille de bloc VE et la base d'étiquettes (LB) se rapportent au bloc d'étiquettes annoncé, comme expliqué dans la section suivante.
Informations d’encapsulation
Les informations d'encapsulation sont également attachées au préfixe et sont codées en tant que communauté étendue 'Layer2 Info Extended Community' à la mise à jour BGP. La valeur est 0x800A et est codée comme suit :
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octet) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
Le type Encaps pour VPLS est 19.
Les indicateurs de contrôle (vecteur de bits) sont codés de cette manière :
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
| Name (nom) | Valeur | Signification |
| C | 1 | Un mot de contrôle DOIT être présent lorsque des paquets VPLS sont envoyés à ce PE. |
| 0 | Un mot de contrôle NE DOIT PAS être présent lorsque des paquets VPLS sont envoyés à ce PE. | |
| S | 1 | La livraison séquentielle des trames DOIT être utilisée lorsque des paquets VPLS sont envoyés à ce PE. |
| 0 | La livraison séquentielle des trames NE DOIT PAS être utilisée lorsque des paquets VPLS sont envoyés à ce PE. |
Il existe également des cibles de route (RT) associées à la mise à jour BGP. Les RT contrôlent l'importation et l'exportation depuis L2VPN, de la même manière que MPLS L3VPN.
Préfixe de détection automatique VPLS BGP et préfixe de signalisation VPLS BGP
Un préfixe de détection automatique BGP VPLS est un préfixe /96, alors qu'un préfixe de signalisation BGP VPLS est un préfixe /136. Voici des exemples de chacun :
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
Exemple de configuration du logiciel Cisco IOS
Voici un exemple de configuration du logiciel Cisco IOS :
!
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
Bloc d'étiquette annoncé
Un routeur PE doit annoncer au moins un bloc d’étiquette. Le bloc d'étiquette est un ensemble continu d'étiquettes MPLS et est utilisé par les routeurs PE distants afin de sélectionner une étiquette VC distante. L'étiquette distante est utilisée pour le PW entre le routeur PE local et le routeur PE distant. (Un routeur PE peut annoncer plusieurs blocs d'étiquettes, comme expliqué dans les sections suivantes.)
L'ID de VE doit être configuré sur chaque PE. Il identifie les routeurs PE dans le domaine VPLS.
La taille du bloc VE (VBS) est la taille du bloc d'étiquette et a une valeur par défaut de 10. Si 've range' est configuré, c'est cette valeur. 've range' peut être configuré pour être [11 -100].
La base d'étiquettes (LB) est la première valeur d'étiquette d'un ensemble libre d'étiquettes pouvant être réservées par le routeur PE pour être utilisées pour ce domaine VPLS.
VBO (VE Block Offset) est la valeur de décalage à utiliser lorsque plusieurs blocs d'étiquette doivent être créés par un routeur PE. VBO est calculé avec cette équation : VBO = RND(ID-VE/VBS) * VBS
Voici des exemples de calculs :
- Si VBS = 8 et VE-ID = 2, VBO = RND(2/8) * 8 = 1
- Si VBS = 8 et VE-ID = 20, VBO = RND (20/8) * 8 = 16
- Si VBS = 50 et VE-ID = 199, VBO = RND (199/50) * 50 = 150
- Si VBS = 50 et VE-ID = 1002, VBO = RND (1002/50) * 50 = 1000
Le bloc d'étiquette annoncé aux routeurs PE distants est {LB, LB + 1, ? , LB + VBS - 1}. Le bloc d'étiquette est défini par l'LB et le VBS ; le bloc commence à LB et se termine par (LB + VBS - 1).
Chaque routeur PE peut créer plusieurs blocs d’étiquettes, si nécessaire. Le routeur doit s’assurer qu’il s’agit d’un ensemble continu d’étiquettes libres.
Distingueur de route et cibles de route
Exemple de configuration de 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
Voici une explication des valeurs de configuration :
- L'ID VPN est configuré sur 100.
- Le RD provient de [ASN : vpn id], sauf si un RD est explicitement configuré. Ici, la RD est 1:100.
- Les cibles de route d'importation/exportation sont 32:64.
- L'équilibrage de charge se situe dans la plage [10000 20000]. La valeur exacte de LB dépend du premier ensemble d'étiquettes locales continues libres, suffisamment grandes pour contenir toutes les étiquettes déterminées par le VBS.
- Le VE-ID est configuré en tant que 1001.
- Le VBS est configuré sur 50.
- Le VBO est calculé comme suit : VBO = RND(VE-ID/VBS) * VBS ou RND(1001/50) * 50 = 1000.
Vérifier la plage d'étiquettes
Vous pouvez vérifier la plage d'étiquettes à l'aide de la commande show mpls label range :
PE1#show mpls label range
Downstream Generic label region: Min/Max label: 10000/20000
Il existe une plage d'étiquettes par plate-forme par défaut, que vous pouvez modifier à l'aide de la commande mpls label range.
Vérifier les étiquettes
Vous pouvez vérifier les étiquettes réelles utilisées pour un bloc d'étiquettes dans la base d'informations de transfert d'étiquettes (LFIB) à l'aide de la commande show mpls forwarding-table.
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
Dans cet exemple, PE1, le routeur local, a réservé 50 étiquettes locales pour le bloc d'étiquettes. 'lbl-blk-id(1:0)' signifie un ID de bloc de 1 et une instance de bloc de 0, qui identifie la première étiquette du bloc. La dernière étiquette de ce bloc est 10049.
L'interface sortante de la LFIB est 'drop' tant qu'aucun PW n'est configuré pour cette étiquette locale. Si un PW est configuré, l'interface 'Sortant' est 'aucun point2point'.
Vérifier le bloc d'étiquettes
Le bloc d'étiquette affecté peut également être vérifié à l'aide de la commande show mpls infrastructure lfd block-database summary lorsque 'service internal' est configuré.
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 est de 10 000. Dans cet exemple, le bloc d'étiquette est de LB à (LB + VBS - 1) ou de 10000 à (10000 + 50 - 1) = 10049.
Vérifier le préfixe annoncé
Vous pouvez vérifier le préfixe annoncé à l'aide de la commande show bgp l2vpn vpls rd 1:100 :
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 ?
Afficher le préfixe en détail
Pour afficher ce préfixe en détail, utilisez la commande show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000. Notez que vous spécifiez le VE-ID et le bloc d'étiquette, qui se trouvent dans l'INLRI (Blk-1000).
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 affiche la distance annoncée de 1:100, l'ID de VE de 1001, le VBO de 1000, le VBS de 50 et l'LB de 10000.
La communauté étendue des informations de couche 2 contient ces informations :
- Le type de capuchon est 19 (VPLS)
- Indicateurs de contrôle : C = 0 (un mot de contrôle ne doit pas être défini); S = 0 (aucune livraison séquentielle de trames)
- MTU est 1500
La communauté étendue RT détient cette information :
- RT 1:100
- RT 32:64
Publier, recevoir et traiter les blocs d'étiquettes dans les messages de mise à jour BGP
Lorsqu'un routeur PE local annonce un préfixe/bloc d'étiquette VPLS L2VPN, chaque routeur PE distant doit essayer de choisir une étiquette de cette plage afin de l'utiliser comme étiquette VC distante.
- Si le routeur PE distant réussit, il utilise cette étiquette de circuit virtuel distant et le programme dans le plan de données. Il n'y a pas d'autre signalisation par BGP.
- Si le routeur PE distant échoue, il doit attendre qu'un autre préfixe VPLS L2VPN soit annoncé par le routeur PE local, puis essayer de choisir une autre étiquette VC distante à partir de ce bloc d'étiquette.
Supposez que PE1 est un PE local avec la configuration précédente et que PE2 est un PE distant avec cette configuration :
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 1002
ve range 50
!
mpls label range 3000 60000
PE2 : Recevoir la mise à jour BGP
PE2 reçoit cette mise à jour BGP de 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 : Rechercher une étiquette
PE2 doit trouver une étiquette qu'il peut utiliser comme étiquette VC distante pour le PW vers PE1.
PE2 doit d’abord déterminer si le VBO se trouve dans la plage de sa configuration. PE2 vérifie son ID VE par rapport à la plage annoncée par PE1 avec le calcul VBO <= ID VE < VBO + VBS. Dans ce cas, 1000 <= 1002 < 1000 + 50, donc PE2 réussit.
PE2 doit ensuite sélectionner une étiquette de circuit virtuel distant. L'étiquette du démultiplexeur (VC) à utiliser par le PE distant est calculée en tant que (LB + VE-ID - VBO).
À partir du préfixe précédent, LB est 10000 et VBO est 1000. L'ID VE est celui de PE2 et est 1002. Par conséquent, PE2 choisit l'étiquette (LB + VE-ID - VBO) = (10000 + 1002 - 1000) = 10002.
Utilisez la commande show l2vpn vfi name one afin de vérifier ceci :
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 : Envoyer le préfixe à PE1
PE2 envoie ensuite son préfixe à 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 : Rechercher une étiquette
PE1 est maintenant le PE distant et doit trouver une étiquette qu'il peut utiliser comme étiquette VC distante pour le PW vers PE2.
PE1 doit d’abord déterminer si le VBO se trouve dans la plage de sa configuration. PE1 vérifie son ID VE par rapport à la plage annoncée par PE2 avec le calcul VBO <= ID VE < VBO + VBS. Dans ce cas, 1 000 <= 1 001 < 1 000 + 50, donc PE1 réussit.
PE1 doit ensuite sélectionner une étiquette de circuit virtuel distant. L'étiquette du démultiplexeur (VC) à utiliser par le PE distant est calculée en tant que (LB + VE-ID - VBO).
À partir du préfixe précédent, LB est 3100 et VBO est 1000. L'ID de VE est celui de PE1 et est 1001. Par conséquent, PE1 choisit l'étiquette (LB + VE-ID - VBO) = (3100 + 1001 - 1000) = 3101.
Utilisez la commande show l2vpn vfi name one afin de vérifier ceci :
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
Commandes de vérification supplémentaires
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
Plusieurs préfixes VPLS L2VPN annoncés par le routeur PE pour un VFI
Il est possible qu'un PE doive annoncer plusieurs blocs d'étiquettes pour une instance de transfert virtuel (VFI).
Si l'ID de VE du PE distant ne se trouve pas dans la plage annoncée par le PE local, le PE distant ne peut pas choisir une étiquette distante pour le PW. Ce calcul, décrit précédemment, est VBO <= VE-ID < VBO + VBS.
Si cette vérification échoue, l'ID VE du périphérique PE distant est hors limites. Le PE distant ignore le préfixe reçu du PE local. Le PE local apprend que le PE distant est hors limites lorsqu’il reçoit le préfixe que le PE distant annonce. Le périphérique PE local doit déterminer l’étiquette distante à utiliser pour ce routeur PE distant. Le PE local envoie également un nouveau deuxième préfixe pour un nouveau bloc d'étiquettes locales au PE distant, que le PE distant doit pouvoir utiliser pour sélectionner une étiquette distante.
Configuration PE1
L'exemple précédent est repris ici ; PE1 dispose encore :
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
Configuration PE2
PE2 dispose désormais d'un ID VE de 1002 et de cette configuration :
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 10002
ve range 50
!
mpls label range 3000 60000
Blocs d'étiquette initiaux
PE1 et PE2 commencent par ces blocs d'étiquettes initiaux.
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 et PE2 Exchange
Utilisez la commande debug bgp l2vpn vpls update afin de passer en revue l'échange PE1 et PE2, puis utilisez la commande show bgp l2vpn vpls rd 1:100 afin d'examiner les détails.
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 des échanges PE1 et PE2
PE1 et PE2 ont maintenant annoncé deux blocs d'étiquettes l'un à l'autre.
PE1 annonce d'abord une mise à jour BGP initiale à PE2 :
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
Cette mise à jour est définie par NLRI en fonction de la configuration sur PE1.
PE1 reçoit ensuite la mise à jour BGP initiale de 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 annonce le préfixe initial avec les valeurs VE-ID 10002, VBO = 10000, VBS = 50, LB = 3000.
PE1 constate que PE2 est hors limites depuis que PE1 a démarré avec le bloc d'étiquette LB à (LB + VBS - 1) ou de 10000 à (10000 + 50 - 1) = 10049.
PE1 doit déterminer si le VBO se trouve dans la plage de sa configuration. Par conséquent, l'ID de VE de PE2 doit être vérifié par rapport à la plage annoncée par PE1. Le calcul est VBO <= VE-ID < VBO + VBS. Dans ce cas, 1000 <= 10002 < 1000 + 50, ce qui n'est pas vrai. Par conséquent, PE1 doit envoyer un nouveau bloc d'étiquette afin de prendre en charge l'ID VE hors gamme de PE2. En réaction à la mise à jour initiale de PE2, PE1 se formate et envoie une nouvelle mise à jour BGP supplémentaire à PE2. PE1 utilise désormais un nouveau VBO de 10000.
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
Pour PE1, le VBO est 1000, le VBS est 50 et le LB est 10053. La vérification pour PE2 est VBO <= VE-ID < VBO + VBS. Dans ce cas, 10000 <= 10002 < 10000 + 50, ce qui est vrai. PE2 peut choisir une étiquette distante à partir de ce nouveau bloc d'étiquette [10053 - 10102] à partir de PE1. En d'autres termes, PE1 a ajouté un nouveau bloc d'étiquette afin de prendre en charge PE2 et a envoyé deux messages de mise à jour BGP.
La même chose se produit dans la direction opposée. PE2 reçoit la mise à jour BGP initiale de PE1. Cette mise à jour a ces valeurs VE-ID 1001, VBO = 1000, VBS = 50, LB = 10000.
PE2 remarque que l'ID VE de PE1 est hors limites avec la mise à jour initiale de PE2. Le contrôle de PE1 est VBO <= VE-ID < VBO + VBS ou 10000 <= 1001 < 10000 + 50. En réponse, PE2 envoie cette deuxième mise à jour BGP, avec un nouveau bloc d'étiquette [3053 - 3102] qui prend en charge l'ID VE 1001 de PE1, car le contrôle de PE1 est VBO <= ID VE < VBO + VBS ou 1000 <= 1001 < 10000000000000000 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
Détails du préfixe
Voici les détails des deux préfixes créés par 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
Ici, deux routeurs PE ont des schémas de nombre discontinus, ce qui fait que chaque PE envoie deux mises à jour BGP. Si de nombreux routeurs PE ont des schémas de nombre discontinus, le nombre de mises à jour BGP augmente rapidement.
www.cisco.com dit : « Par exemple, les séquences de numérotation VE-ID telles que 1, 2, 3 ou 501, 502, 503 sont correctes car les VE-ID sont contigus. Un schéma de numérotation tel que 100, 200, 300 est incorrect car il n'est pas contigu. »
Les premiers exemples de 1, 2, 3 ou 501, 502, 503 sont des numéros contigus. Par conséquent, chaque routeur PE doit envoyer un préfixe VPLS L2VPN. Avec le troisième exemple (100, 200, 300), chaque PE doit envoyer de nombreux préfixes VPLS L2VPN. Pour les nombres non contigus, une plage VE suffisante permettrait de maintenir le nombre de préfixes à annoncer plus bas. Cependant, la quantité d'étiquettes réservées (gaspillées) est encore plus importante.
Interopérabilité
Si le réflecteur de route BGP (RR) exécute un logiciel qui ne comprend pas RFC 4761, mais qui prend en charge RFC 4762, la commande de configuration spéciale BGP neighbor x.x.x.x prefix-length-size 2 est nécessaire sur le RR afin qu'il puisse refléter les mises à jour BGP utilisées pour RFC 4776661.
Les préfixes sont généralement envoyés avec une longueur de 1 octet. La plate-forme logicielle Cisco IOS a mis en oeuvre le brouillon 'draft-ietf-l2vpn-signing-08', qui est devenu plus tard RFC 6074. Un champ de longueur de 1 octet a été choisi à l'époque, indiquant la longueur en bits.
RFC 6074 Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPN) (Provisioning, Découverte automatique et signalisation dans les réseaux privés virtuels de couche 2) spécifie que le codage NLRI pour la détection automatique BGP doit avoir une longueur de 2 octets. Les 2 octets indiquent le nombre d'octets du préfixe qui suivent dans le préfixe de longueur variable.
La section 7 de la RFC 6074, « BGP-AD et VPLS-BGP Interoperability », indique :
« BGP-AD et VPLS-BGP [RFC4761] utilisent tous deux la même AFI/SAFI. Pour que BGP-AD et VPLS-BGP coexistent, la longueur NLRI doit être utilisée comme démultiplexeur.
La NLRI BGP-AD a une longueur NLRI de 12 octets, contenant uniquement une RD de 8 octets et un ID VSI de 4 octets. VPLS-BGP [RFC4761] utilise une longueur NLRI de 17 octets. Par conséquent, les implémentations de BGP-AD doivent ignorer NLRI qui sont supérieures à 12 octets. »
Si la commande neighbor x.x.x.x prefix-length-size 2 n'est pas présente sur les RR, le voisin BGP ne s'affiche pas et le RR interprète le champ de longueur comme un octet seulement. Cette notification apparaît sur le RR :
%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
Cette notification apparaît sur le routeur PE :
%BGP-3-NOTIFICATION: received from neighbor 10.100.1.4 3/10 (illegal network)
1 bytes FD
Cela se produit parce que, dans l'implémentation initiale de la détection automatique BGP dans le logiciel Cisco IOS, le champ de longueur était de 1 octet.
Si vous mettez la commande neighbor x.x.x.x prefix-length-size 2 sur le RR, les notifications n'apparaissent pas.
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
Commentaires