Sommario

Introduzione

Problema

Architettura della soluzione

Identificazione endpoint router PE

Identità VPLS ed etichette MPLS

Informazioni sull'incapsulamento

Prefisso VPLS BGP Auto-Discovery e prefisso di segnalazione VPLS BGP

Esempio di configurazione software di Cisco IOS

Blocco etichetta annunciata

Distintore e destinazioni route

Configurazione di esempio di PE1

Controlla intervallo etichette

Etichette assegni

Controlla blocco etichetta

Verifica prefisso annunciato

Visualizza prefisso in dettaglio

Annuncia, riceve ed elabora blocchi di etichette nei messaggi di aggiornamento BGP

PE2: Ricevi aggiornamento BGP

PE2: Trova etichetta

PE2: Invia prefisso a PE1

PE1: Trova etichetta

Comandi di verifica aggiuntivi

Più prefissi VPLS L2VPN annunciati dal router PE per una VFI

Configurazione PE1

Configurazione PE2

Blocchi iniziali di etichette

PE1 e PE2 Exchange

Analisi di PE1 e PE2 Exchange

Dettagli prefisso

Interoperabilità

Introduzione

In questo documento viene descritto il rilevamento automatico basato su Border Gateway Protocol (BGP) per un servizio VPLS (Virtual Private LAN Service) con segnalazione BGP. L'individuazione automatica è uno strumento che consente al perimetro del provider (PE, Provider Edge) di individuare i PE remoti membri di un determinato dominio VPLS.La segnalazione è uno strumento che consente a un PE di conoscere l'etichetta dello pseudofilo previsto da un determinato PE remoto per un determinato dominio VPLS.

Fare riferimento ai seguenti documenti della Internet Engineering Task Force:

- La RFC 4762 - Servizio VPLS (Virtual Private LAN Service) che utilizza la segnalazione LDP (Label Distribution Protocol)  descrive il rilevamento automatico BGP con la segnalazione LDP (Label Distribution Protocol) per VPLS (noto anche come Martini).

- La RFC 4761 - Servizio VPLS (Virtual Private LAN Service) che utilizza BGP per l'individuazione e la segnalazione automatica  descrive il rilevamento automatico BGP e la segnalazione BGP per VPLS (nota anche come Kompella).

Nel documento si fa riferimento alla RFC 4761. Con la RFC 4761, le informazioni NLRI (Network Layer Reachability Information) BGP degli aggiornamenti BGP contengono le informazioni sia per il rilevamento automatico che per la segnalazione. Quando i router PE remoti ricevono questo aggiornamento BGP, dispongono di tutte le informazioni necessarie per configurare una rete completa di pseudofili per VPLS. Il rilevamento automatico BGP e la segnalazione BGP utilizzano la stessa famiglia di indirizzi BGP.

L'interfaccia della riga di comando (CLI) e l'output provengono dal software Cisco IOS®. La configurazione e la funzionalità sono molto simili nel software Cisco IOS-XR e nel software Cisco NX-OS.

Problema

VPLS è costituito da un insieme di pseudofili (PW) in modalità point-to-multipoint. Finora, il protocollo LDP veniva utilizzato per segnalare gli pseudofili tra i router PE. Pertanto, una sessione LDP mirata ha segnalato quali etichette utilizzare per quale pseudofilo tra una coppia di router PE. È possibile configurare manualmente il set di router PE che hanno partecipato a un dominio VPLS oppure utilizzare BGP per individuare automaticamente la configurazione. Per eseguire questo rilevamento automatico, BGP ha annunciato quale sistema PE era membro di quale dominio VPLS. Tuttavia, anche con il rilevamento automatico BGP, LDP è stato utilizzato per segnalare le etichette MPLS (Multiprotocol Label Switching) e l'ID dello pseudofilo.

È ora possibile utilizzare BGP per segnalare gli pseudofili tra i router PE.

Quando si deve configurare uno pseudowire tra una coppia di router, gli altri router non hanno bisogno delle informazioni relative a questo pseudowire. Tali informazioni, ad esempio, rappresentano l'etichetta VC da utilizzare.

Se il protocollo di segnalazione per configurare gli pseudofili è LDP, le informazioni vengono ricevute solo dalla coppia di router, in quanto LDP effettua la segnalazione in modo point-to-point.

Con BGP come protocollo di segnalazione per configurare gli pseudofili, le informazioni vengono ricevute da tutti gli altri router perché il protocollo BGP (iBGP) interno effettua la segnalazione in modalità point-to-multipoint. iBGP ha un requisito mesh completo, quindi un router invia un aggiornamento iBGP a tutti gli altri router iBGP. Ciò può essere fatto anche con un riflettore di percorso.

Se il protocollo di segnalazione è iBGP, gli aggiornamenti possono essere inviati in due modi:

1. Ogni router PE annuncia un aggiornamento BGP a tutti i router adiacenti iBGP per ogni PW; ogni volta viene allegata un'etichetta MPLS VC. Pertanto, un router PE invia tutti gli aggiornamenti BGP che sono i router PE. Tuttavia, l'etichetta VC collegata all'aggiornamento BGP può essere utilizzata solo da uno dei router PE, ovvero il router PE all'altra estremità del PW.

2. Per evitare il problema di un numero elevato di aggiornamenti BGP, è stata progettata un'architettura in base alla quale un router PE locale invia un set o un blocco di etichette VC locali a tutti i router PE remoti. Ogni router PE remoto sceglie una delle etichette VC da utilizzare come etichetta di VC remota per il PW verso il router PE locale. Il router PE remoto deve selezionare un'etichetta di VC remota in modo univoco in modo che nessun altro router PE possa selezionare la stessa etichetta di VC dal blocco di etichette annunciato. Poiché viene inviato un blocco di etichette, è necessario disporre di un numero sufficiente di etichette per poter servire tutti i PW possibili che potrebbero essere impostati, ma non dovrebbero esserci così tante etichette riservate da essere inutilizzate e sprecate.

Questo documento descrive come viene usato BGP per segnalare gli pseudofili; si noti che allo stesso tempo il protocollo BGP viene utilizzato anche per il rilevamento automatico.

Architettura della soluzione

Poiché questo è VPLS, è ancora necessario un protocollo di segnalazione hop-by-hop nel core per trasportare i pacchetti etichettati da PE a router PE. Questa funzione di trasporto nel core deve essere ancora eseguita dal servizio di progettazione del traffico LDP o MPLS.

BGP deve inviare le informazioni necessarie per impostare gli pseudofili in modo point-to-multipoint necessario per VPLS. Queste informazioni di segnalazione includono:

- Identificazione endpoint router PE

- Identità VPLS

- Blocco di etichette MPLS

- Informazioni sull'incapsulamento

Identificazione endpoint router PE

L'identificazione dell'endpoint del router PE viene determinata dal router PE che è il mittente BGP dell'aggiornamento.

L'aggiornamento BGP relativo al VPLS L2VPN (Virtual Private Network) di layer 2 è identificato da AFI/SAFI 25/65. Questa famiglia di indirizzi viene negoziata quando BGP invia il messaggio OPEN.

Identità VPLS ed etichette MPLS

L'NLRI, noto anche come prefisso, contiene le informazioni sull'identità VPLS e sul blocco di etichette MPLS. La codifica ha una lunghezza totale di 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)             |

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

Il descrittore di route (RD) è correlato all'identità del VPLS.

Nota: Nell'implementazione del software Cisco IOS e Cisco NX-OS, tutti i router PE devono avere lo stesso RD nello stesso dominio VPLS.

L'ID di espansione virtuale (VE), l'offset del blocco VE, la dimensione del blocco VE e la base dell'etichetta (LB) si riferiscono al blocco di etichette pubblicizzato, come illustrato nella sezione successiva.

Informazioni sull'incapsulamento

Le informazioni sull'incapsulamento sono anche associate al prefisso e codificate come una community estesa 'Layer2 Info Extended Community' all'aggiornamento BGP. Il valore è 0x800A ed è codificato come:

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

| Extended community type (2 octets) |

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

|  Encaps Type (1 octet)             |

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

|  Control Flags (1 octet)           |

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

|  Layer-2 MTU (2 octet)             |

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

|  Reserved (2 octets)               |

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

Il tipo di incapsulamento per VPLS è 19.

I flag di controllo (vettore bit) sono codificati nel modo seguente:

0 1 2 3 4 5 6 7

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

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

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

Nome

Valore

Significato

C

1

Quando i pacchetti VPLS vengono inviati a questo PE DEVE essere presente una parola di controllo.

0

Una parola di controllo NON DEVE essere presente quando i pacchetti VPLS vengono inviati a questo PE.

S

1

È NECESSARIO utilizzare il recapito in sequenza dei frame quando i pacchetti VPLS vengono inviati a questo PE.

0

IL recapito in sequenza dei frame NON DEVE essere utilizzato quando i pacchetti VPLS vengono inviati a questo PE.

Ci sono anche route target (RT) collegate all'aggiornamento BGP. Le RT controllano l'importazione e l'esportazione da L2VPN, come MPLS L3VPN.

Prefisso VPLS BGP Auto-Discovery e prefisso di segnalazione VPLS BGP

Un prefisso di rilevamento automatico VPLS BGP è /96, mentre un prefisso di segnalazione VPLS BGP è /136. Di seguito sono riportati alcuni esempi di ciascun tipo:

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

Esempio di configurazione software di Cisco IOS

Di seguito è riportato un esempio di configurazione del software 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

Blocco etichetta annunciata

Un router PE deve annunciare almeno un blocco di etichette. Il blocco etichetta è un insieme continuo di etichette MPLS e viene utilizzato dai router PE remoti per selezionare un'etichetta VC remota. L'etichetta remota viene utilizzata per il PW tra il router PE locale e quello remoto. Un router PE può annunciare più blocchi di etichette, come illustrato nelle sezioni successive.

L'VE-ID deve essere configurato su ogni PE. Identifica i router PE all'interno del dominio VPLS.

La dimensione del blocco VE (VBS) è la dimensione del blocco di etichette e ha un valore predefinito di 10. Se è configurato 've range', questo è il valore. 've range' può essere configurato su [11 -100].

La base etichette (LB) è il primo valore di etichetta di un insieme di etichette libere che possono essere riservate dal router PE da utilizzare per questo dominio VPLS.

VBO (VE Block Offset) è il valore di offset da utilizzare quando un router PE deve creare più blocchi di etichette. VBO viene calcolato con questa equazione: VBO = RND(VE-ID/VBS) * VBS

Questi sono esempi di calcoli:

- Se VBS = 8 e VE-ID = 2, VBO = RND(2/8) * 8 = 1

- Se VBS = 8 e VE-ID = 20, VBO = RND (20/8) * 8 = 16

- Se VBS = 50 e VE-ID = 199, VBO = RND (199/50) * 50 = 150

- Se VBS = 50 e VE-ID = 1002, VBO = RND (1002/50) * 50 = 1000

Il blocco etichetta annunciato ai router PE remoti è {LB, LB + 1, ? , LB + VBS - 1}. Il blocco etichetta è definito dalla LB e dal VBS; il blocco inizia in corrispondenza di LB e termina con (LB + VBS - 1).

Ogni router PE può creare più blocchi di etichette, se necessario. Il router deve garantire che si tratti di una serie continua di etichette libere.

Distintore e destinazioni route

Configurazione di esempio di 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

Questa è una spiegazione dei valori di configurazione:

- L'ID VPN è configurato come 100.

- Il RD viene acquisito da [ASN:vpn id], a meno che non sia configurato in modo esplicito. Qui, il RD è 1:100.

- Gli obiettivi per le route di importazione/esportazione sono 32:64.

- La LB è compresa nell’intervallo [10000 20000]. Il valore esatto di LB dipende dal primo insieme di etichette locali continue libere di dimensioni tali da contenere tutte le etichette determinate dal VBS.

- Il VE-ID è configurato come 1001.

- Il VBS è configurato come 50.

- Il valore VBO è calcolato come segue: VBO = RND(VE-ID/VBS) * VBS o RND(1001/50) * 50 = 1000.

Controlla intervallo etichette

È possibile controllare l'intervallo di etichette con il comando show mpls label range:

PE1#show mpls label range

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

Per impostazione predefinita, l'intervallo di etichette per piattaforma può essere modificato con il comando mpls label range.

Etichette assegni

È possibile controllare le etichette effettivamente utilizzate per un blocco di etichette nel database LFIB (Label Forwarding Information Base) con il comando 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

In questo esempio, PE1, il router locale, ha riservato 50 etichette locali per il blocco etichetta. 'lbl-blank-id(1:0)' indica un block-id di 1 e un block-instance di 0, che identifica la prima etichetta del blocco. L'ultima etichetta di questo blocco è l'etichetta 10049.

L'interfaccia 'In uscita' in LFIB è 'drop', a condizione che non sia stata configurata alcuna PW per l'etichetta locale. Se è impostata una PW, l'interfaccia 'In uscita' sarà 'none point2point'.

Controlla blocco etichetta

Il blocco label assegnato può essere controllato anche con il comando show mpls infrastructure lfd block-database summary quando è configurato 'service internal'.

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 è 10000. In questo esempio, il blocco di etichette è compreso tra LB e (LB + VBS - 1) o tra 10000 e (10000 + 50 - 1) = 10049.

Verifica prefisso annunciato

È possibile controllare il prefisso annunciato con il comando 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 ?

Visualizza prefisso in dettaglio

Per visualizzare questo prefisso in dettaglio, usare il comando show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000. Si noti che si specificano l'VE-ID e il blocco etichetta, che si trova nell'NLRI (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 mostra il RD di 1:100, il VE-ID di 1001, il VBO di 1000, il VBS di 50 e il LB di 10000.

La community estesa di informazioni sul layer 2 contiene le seguenti informazioni:

- Il tipo di incapsulamento è 19 (VPLS)

- Flag di controllo: C = 0 (una parola di controllo non deve essere impostata); S = 0 (nessuna consegna in sequenza di frame)

- L'MTU è 1500

La comunità estesa RT contiene queste informazioni:

- RT 1.100

- RT 32.64

Nota: Il VBS predefinito (10) è di piccole dimensioni, per evitare di sprecare le etichette locali.

Annuncia, riceve ed elabora blocchi di etichette nei messaggi di aggiornamento BGP

Quando un router PE locale annuncia un prefisso/blocco di etichette VPLS L2VPN, ogni router PE remoto deve tentare di selezionare un'etichetta da tale intervallo per utilizzarla come etichetta di VC remota.

- Se il router PE remoto ha esito positivo, utilizza l'etichetta di VC remota e la programma nel piano dati. BGP non invia ulteriori segnali.

- Se il router PE remoto ha esito negativo, è necessario attendere che un altro prefisso VPLS L2VPN venga annunciato dal router PE locale, quindi provare a scegliere un'altra etichetta di VC remota dal blocco di etichette.

Si supponga che PE1 sia un PE locale con la configurazione precedente e che PE2 sia un PE remoto con la configurazione seguente:

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp

ve id 1002

ve range 50

!

mpls label range 3000 60000

PE2: Ricevi aggiornamento BGP

PE2 riceve questo aggiornamento BGP da 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: Trova etichetta

PE2 deve trovare un'etichetta utilizzabile come etichetta di VC remota per la PW verso PE1.

PE2 deve prima determinare se il VBO rientra nell'intervallo della relativa configurazione. PE2 verifica il proprio VE-ID rispetto all'intervallo pubblicizzato da PE1 con il calcolo VBO <= VE-ID < VBO + VBS. In questo caso, 1000 <= 1002 < 1000 + 50, pertanto PE2 avrà esito positivo.

PE2 deve quindi selezionare un'etichetta di VC remota. L'etichetta del demultiplatore (VC) che deve essere utilizzata dal PE remoto viene calcolata come (LB + VE-ID - VBO).

Dal prefisso precedente, LB è 10000 e VBO è 1000. Il valore VE-ID è quello di PE2 ed è 1002. In questo modo, PE2 seleziona l'etichetta (LB + VE-ID - VBO) = (10000 + 1002 - 1000) = 10002.

Per verificare questa condizione, usare il comando show l2vpn vfi name one:

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: Invia prefisso a PE1

PE2 invia quindi il prefisso a 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: Trova etichetta

PE1 è ora il PE remoto e deve trovare un'etichetta utilizzabile come etichetta di VC remota per il PW verso PE2.

PE1 deve prima determinare se il VBO rientra nell'intervallo della relativa configurazione. PE1 controlla il proprio VE-ID rispetto all'intervallo pubblicizzato da PE2 con il calcolo VBO <= VE-ID < VBO + VBS. In questo caso, 1000 <= 1001 < 1000 + 50, pertanto PE1 avrà esito positivo.

PE1 deve quindi selezionare un'etichetta di VC remota. L'etichetta del demultiplatore (VC) che deve essere utilizzata dal PE remoto viene calcolata come (LB + VE-ID - VBO).

Dal prefisso precedente, LB è 3100 e VBO è 1000. L'ID-VE è quello di PE1 ed è 1001. In questo modo PE1 seleziona l'etichetta (LB + VE-ID - VBO) = (3100 + 1001 - 1000) = 3101.

Per verificare questa condizione, usare il comando show l2vpn vfi name one:

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

Comandi di verifica aggiuntivi

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

Più prefissi VPLS L2VPN annunciati dal router PE per una VFI

È possibile che un PE debba annunciare più blocchi di etichette per un'istanza di inoltro virtuale (VFI).

Se l'VE-ID del file PE remoto non rientra nell'intervallo annunciato dal file PE locale, il file PE remoto non potrà scegliere un'etichetta remota per il file PW. Questo calcolo, descritto in precedenza, è VBO <= VE-ID < VBO + VBS.

Se il controllo ha esito negativo, l'VE-ID del PE remoto non è compreso nell'intervallo. Il PE remoto ignora il prefisso ricevuto dal PE locale. Il PE locale apprende che il PE remoto è fuori intervallo quando riceve il prefisso che il PE remoto sta pubblicizzando. Il sistema PE locale deve determinare l'etichetta remota da utilizzare per il router PE remoto. Il file PE locale invia inoltre un nuovo secondo prefisso per un nuovo blocco di etichette locali al file PE remoto, che il file PE remoto deve essere in grado di utilizzare per selezionare un'etichetta remota.

Configurazione PE1

L'esempio precedente continua qui; PE1 presenta ancora:

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

Configurazione PE2

In PE2 è ora disponibile un VE-ID di 1002 con la seguente configurazione:

l2vpn vfi context one

vpn id 100

autodiscovery bgp signaling bgp

ve id 10002

ve range 50

!

mpls label range 3000 60000

Blocchi iniziali di etichette

Sia PE1 che PE2 iniziano con questi blocchi di etichette iniziali.

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 e PE2 Exchange

Usare il comando debug bgp l2vpn vpls updates per esaminare lo scambio di PE1 e PE2, quindi usare il comando show bgp l2vpn vpls rd 1:100 per esaminare i dettagli.

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 ?

Analisi di PE1 e PE2 Exchange

PE1 e PE2 hanno annunciato due blocchi di etichette l'uno all'altro.

PE1 annuncia innanzitutto un aggiornamento BGP iniziale a 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

L'NLRI di questo aggiornamento è impostato in base alla configurazione in PE1.

PE1 riceve quindi l'aggiornamento BGP iniziale da 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 annuncia il prefisso iniziale con i valori VE-ID 10002, VBO = 10000, VBS = 50, LB = 3000.

PE1 rileva che PE2 è fuori intervallo poiché PE1 è stato avviato con il blocco di etichette LB a (LB + VBS - 1) o da 10000 a (10000 + 50 - 1) = 10049.

PE1 deve determinare se il VBO rientra nell'intervallo della relativa configurazione. Pertanto, l'VE-ID di PE2 deve essere confrontato con l'intervallo pubblicizzato da PE1. Il calcolo è VBO <= VE-ID < VBO + VBS. In questo caso, 1000 <= 10002 < 1000 + 50, il che non è vero. Pertanto, PE1 deve inviare un nuovo blocco di etichette in modo da contenere l'ID VE di PE2 non compreso nell'intervallo. In risposta all'aggiornamento iniziale da PE2, PE1 formatta e invia un nuovo aggiornamento BGP aggiuntivo a PE2. PE1 ora utilizza un nuovo VBO di 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

Per PE1, VBO è 10000, VBS è 50, LB è 10053. Il controllo per PE2 è VBO <= VE-ID < VBO + VBS. In questo caso, 10000 <= 10002 < 10000 + 50, che è vero. PE2 è in grado di selezionare un'etichetta remota da questo nuovo blocco di etichette [10053 - 10102] da PE1. In altre parole, PE1 ha aggiunto un nuovo blocco di etichette per contenere PE2 e ha inviato due messaggi di aggiornamento BGP.

Lo stesso accade nella direzione opposta. PE2 riceve l'aggiornamento BGP iniziale da PE1. Questo aggiornamento ha i seguenti valori: VE-ID 1001, VBO = 1000, VBS = 50, LB = 10000.

PE2 rileva che VE-ID di PE1 è fuori intervallo con l'aggiornamento iniziale di PE2. Il controllo di PE1 è VBO <= VE-ID < VBO + VBS o 10000 <= 1001 <= 10000 + 50. In risposta, PE2 invia questo secondo aggiornamento BGP, con un nuovo blocco etichetta [3053 - 3102] che supporta l'VE-ID di 1001 di PE1, in quanto il controllo di PE1 è VBO <= VE-ID < VBO + VBS o 1000 <= 1001 < 0 + 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

Dettagli prefisso

Questi sono i dettagli dei due prefissi creati da 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

In questo caso, due router PE dispongono di schemi numerici non contigui, che determinano l'invio di due aggiornamenti BGP da parte di ogni router PE. Se sono presenti molti router PE con schemi numerici non contigui, il numero di aggiornamenti BGP aumenta rapidamente.

www.cisco.com dice: "Ad esempio, le sequenze di numerazione VE-ID come 1, 2, 3 o 501, 502, 503 sono valide perché gli VE-ID sono contigui. Uno schema di numerazione come 100, 200, 300 non è valido perché non è contiguo."

I primi esempi di 1, 2, 3 o 501, 502, 503 sono numeri contigui, quindi ogni router PE deve inviare solo un prefisso VPLS L2VPN. Con il terzo esempio (100, 200, 300), ogni PE deve inviare molti prefissi VPLS L2VPN. Per i numeri non contigui, un intervallo VE sufficientemente ampio da mantenere il numero di prefissi da annunciare più basso. Tuttavia, la quantità di etichette riservate (sprecate) è ancora maggiore.

Interoperabilità

Se il router BGP Route Reflector (RR) esegue un software che non supporta la RFC 4761, ma supporta la RFC 4762, è necessario lo speciale comando di configurazione x.x.x.x prefix-length-size 2 per il router BGP, in modo che rifletta gli aggiornamenti BGP utilizzati per la RFC 4761.

I prefissi vengono in genere inviati con una lunghezza di 1 byte. Il software Cisco IOS ha implementato la bozza 'draft-ietf-l2vpn-signaling-08', che in seguito è diventata RFC 6074. È stato scelto un campo di lunghezza pari a 1 byte, che indica la lunghezza in bit.

La RFC 6074 - Provisioning, rilevamento automatico e segnalazione in reti VPN di livello 2  specifica che la codifica NLRI per il rilevamento automatico BGP deve essere lunga 2 byte. I 2 byte indicano quanti byte di prefisso seguono nel prefisso di lunghezza variabile.

La sezione 7 della RFC 6074, "BGP-AD and VPLS-BGP Interoperability", afferma:

"Sia BGP-AD che VPLS-BGP [RFC4761] utilizzano lo stesso AFI/SAFI. Affinché BGP-AD e VPLS-BGP possano coesistere, la lunghezza NLRI deve essere utilizzata come demultiplatore.

Il protocollo NLRI del BGP-AD ha una lunghezza NLRI di 12 byte, contenente solo un RD di 8 byte e un VSI-ID di 4 byte. VPLS-BGP [RFC4761] utilizza una lunghezza NLRI di 17 byte. Pertanto, le implementazioni di BGP-AD devono ignorare l'NLRI maggiore di 12 byte."

Se il comando neighbors x.x.x.x prefix-length-size 2 non è presente nei record RR, il router BGP adiacente non viene visualizzato e il record RR interpreta il campo della lunghezza come solo 1 byte. Questa notifica viene visualizzata nella scheda 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

Questa notifica viene visualizzata sul router PE:

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

1 bytes FD

Questo si verifica perché, nell'implementazione originale del rilevamento automatico BGP nel software Cisco IOS, il campo della lunghezza era di 1 byte.

Se si inserisce il comando neighbors x.x.x.x prefix-length-size 2 su RR, le notifiche non vengono visualizzate.

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