Nota tecnica su VPLS con segnalazione BGP
Sommario
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:
- 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.
- 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.
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
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
Feedback