Contenu

Introduction

Problème

Architecture de la solution

Identification du point de terminaison du routeur PE

Identité VPLS et étiquettes MPLS

Informations d’encapsulation

Préfixe de détection automatique VPLS BGP et préfixe de signalisation VPLS BGP

Exemple de configuration du logiciel Cisco IOS

Bloc d'étiquette annoncé

Distingueur de route et cibles de route

Exemple de configuration de PE1

Vérifier la plage d'étiquettes

Vérifier les étiquettes

Vérifier le bloc d'étiquettes

Vérifier le préfixe annoncé

Afficher le préfixe en détail

Publier, recevoir et traiter les blocs d'étiquettes dans les messages de mise à jour BGP

PE2 : Recevoir la mise à jour BGP

PE2 : Rechercher une étiquette

PE2 : Envoyer le préfixe à PE1

PE1 : Rechercher une étiquette

Commandes de vérification supplémentaires

Plusieurs préfixes VPLS L2VPN annoncés par le routeur PE pour un VFI

Configuration PE1

Configuration PE2

Blocs d'étiquette initiaux

PE1 et PE2 Exchange

Analyse des échanges PE1 et PE2

Détails du préfixe

Interopérabilité

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 :

1. 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.

2. 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.

Note: Dans la mise en oeuvre du logiciel Cisco IOS et Cisco NX-OS, tous les routeurs PE doivent avoir la même RD dans le même domaine 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

Note: Le VBS par défaut (10) est petit de sorte que les étiquettes locales ne soient pas gaspillées.

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