VPLS con Nota Técnica de Señalización BGP
Contenido
Introducción
Este documento describe la detección automática basada en el protocolo de gateway fronterizo (BGP) para un servicio de LAN privada virtual (VPLS) con señalización BGP. La detección automática es un medio para que un borde del proveedor (PE) aprenda qué PE remotos son miembros de un dominio VPLS dado. La señalización es un medio para que un PE aprenda la etiqueta pseudowire esperada por un PE remoto dado para un dominio VPLS determinado.
Consulte estos documentos del Grupo de Trabajo de Ingeniería de Internet:
- RFC 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling describe la detección automática de BGP con señalización de protocolo de distribución de etiquetas (LDP) para VPLS (también conocido como Martini).
- RFC 4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling describe el descubrimiento automático BGP y la señalización BGP para VPLS (también conocido como Kompella).
Este documento se centra en RFC 4761. Con RFC 4761, la información de disponibilidad de capa de red (NLRI) de BGP de las actualizaciones de BGP contiene la información tanto para la detección automática como para la señalización. Cuando los routers PE remotos reciben esta actualización BGP, tienen toda la información necesaria para configurar una malla completa de pseudowires para VPLS. El descubrimiento automático BGP y la señalización BGP utilizan la misma familia de direcciones BGP.
La interfaz de línea de comandos (CLI) y la salida provienen del software Cisco IOS®. La configuración y la funcionalidad son muy similares en el software Cisco IOS-XR y en el software Cisco NX-OS.
Problema
VPLS consta de un conjunto de pseudowires (PW) de forma punto a multipunto. Hasta ahora, el LDP se utilizó para señalizar los pseudowires entre los routers PE. Por lo tanto, una sesión LDP dirigida señaló qué etiquetas usar para qué pseudowire entre un par de routers PE. Puede configurar manualmente el conjunto de routers PE que participaron en un dominio VPLS o puede utilizar BGP para detectar la configuración automáticamente. Para realizar este descubrimiento automático, BGP anunció qué PE era un miembro del cual el dominio VPLS. Sin embargo, incluso con la detección automática de BGP, se utilizó LDP para indicar las etiquetas del circuito virtual (VC) de switching de etiquetas multiprotocolo (MPLS) y la ID de pseudowire.
Ahora es posible utilizar BGP para señalar los pseudowires entre los routers PE.
Cuando se debe configurar un pseudowire entre un par de routers, los otros routers no necesitan la información relacionada con este pseudowire. Por ejemplo, dicha información es la etiqueta VC que se utilizará.
Con LDP como protocolo de señalización para configurar pseudowires, la información sólo es recibida por el par de routers, porque LDP hace la señalización de una manera punto a punto.
Con BGP como protocolo de señalización para configurar pseudowires, todos los demás routers reciben la información porque el BGP interno (iBGP) hace la señalización de una manera punto a multipunto. iBGP tiene un requisito de malla completa, por lo que un router envía una actualización iBGP a todos los demás routers iBGP. Esto también podría hacerse con un reflector de ruta.
Con iBGP como protocolo de señalización, habría dos métodos para enviar actualizaciones:
- Cada router PE anuncia una actualización de BGP a todos los vecinos iBGP para cada PW; cada vez, se adjunta una etiqueta de VC MPLS. Por lo tanto, un router PE enviaría tantas actualizaciones BGP como routers PE. Sin embargo, la etiqueta VC conectada a la actualización de BGP podría ser utilizada solamente por uno de los routers PE - el router PE en el otro extremo del PW.
- Para evitar este problema de un alto número de actualizaciones BGP, se diseñó una arquitectura por la cual un router PE local envía un conjunto o un bloque de etiquetas VC locales a todos los routers PE remotos. Cada router PE remoto selecciona una de las etiquetas VC para usarla como etiqueta VC remota para el PW hacia el router PE local. El router PE remoto debe elegir una etiqueta VC remota de una manera única para que ningún otro router PE elija la misma etiqueta VC del bloque de etiquetas anunciado. Dado que se envía un bloque de etiquetas, debe haber suficientes etiquetas disponibles para servir a todos los PW posibles que se puedan configurar, pero no debe haber tantas etiquetas reservadas que no se utilicen ni desperdicien.
Este documento describe cómo se utiliza BGP para señalar los pseudowires; observe que BGP también se utiliza para la detección automática al mismo tiempo.
Arquitectura de la solución
Debido a que se trata de VPLS, todavía hay un protocolo de señalización salto a salto necesario en el núcleo para transportar los paquetes etiquetados del PE al router PE. Esta función de transporte en el núcleo todavía debe ser cumplimentada por la ingeniería de tráfico MPLS o LDP.
BGP necesita enviar la información necesaria para configurar los pseudowires de una manera punto a multipunto que necesita VPLS. Esta información de señalización incluye:
- Identificación del punto final del router PE
- identidad VPLS
- Bloque de etiquetas MPLS
- Información de encapsulación
Identificación del punto final del router PE
La identificación del punto final del router PE se determina desde el router PE que es el remitente BGP de la actualización.
AFI/SAFI 25/65 identifica la actualización de BGP correspondiente a VPLS de redes privadas virtuales (L2VPN) de capa 2. Esta familia de direcciones se negocia cuando BGP envía el mensaje OPEN.
Identidad VPLS y Etiquetas MPLS
El NLRI, también conocido como prefijo, contiene la información sobre la identidad VPLS y el bloque de etiquetas MPLS. Su codificación tiene una longitud total de 19 bytes:
+------------------------------------+
| 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) |
+------------------------------------+
El Distinguidor de Ruta (RD) se relaciona con la identidad de VPLS.
La ID de expansión virtual (VE), el desplazamiento de bloques VE, el tamaño de bloque VE y la base de etiquetas (LB) se relacionan con el bloque de etiquetas anunciado, como se explica en la siguiente sección.
Información de encapsulación
La información de encapsulación también se adjunta al prefijo y se codifica como una comunidad extendida 'Layer2 Info Extended Community' a la actualización de BGP. El valor es 0x800A y está codificado como:
+------------------------------------+
| Extended community type (2 octets) |
+------------------------------------+
| Encaps Type (1 octet) |
+------------------------------------+
| Control Flags (1 octet) |
+------------------------------------+
| Layer-2 MTU (2 octet) |
+------------------------------------+
| Reserved (2 octets) |
+------------------------------------+
El Tipo de Encaps para VPLS es 19.
Los indicadores de control (vector de bits) se codifican de esta manera:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |C|S| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
| Nombre | Valor | Significado |
| C | 1 | Debe estar presente una palabra de control cuando se envían paquetes VPLS a este PE. |
| 0 | NO DEBE estar presente una palabra de control cuando se envían paquetes VPLS a este PE. | |
| S | 1 | La entrega secuenciada de tramas DEBE utilizarse cuando se envían paquetes VPLS a este PE. |
| 0 | La entrega secuenciada de tramas NO SE DEBE utilizar cuando se envían paquetes VPLS a este PE. |
También hay destinos de ruta (RT) asociados a la actualización de BGP. Los RT controlan la importación y exportación desde L2VPN, de la misma manera que MPLS L3VPN.
Prefijo de Detección Automática BGP VPLS y Prefijo de Señalización BGP VPLS
Un prefijo de detección automática BGP VPLS es un prefijo /96, mientras que un prefijo de señalización BGP VPLS es un prefijo /136. Estos son ejemplos de cada uno:
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
Ejemplo de configuración del software Cisco IOS
Esta es una configuración de ejemplo de Cisco IOS Software:
!
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp <<< "signaling ldp" would be RFC 4762
ve id 1001
ve range 50
route-target export 32:64
route-target import 32:64
mpls label range 10000 20000
!
bridge-domain 1
member Ethernet0/0 service-instance 100
member vfi one
!
l2 router-id 10.100.1.1
!
interface Ethernet0/0
no ip address
service instance 100 ethernet
!
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.100.1.4 remote-as 1
neighbor 10.100.1.4 update-source Loopback0
!
address-family l2vpn vpls
neighbor 10.100.1.4 activate
neighbor 10.100.1.4 send-community extended
neighbor 10.100.1.4 suppress-signaling-protocol ldp
exit-address-family
Bloque de etiquetas publicitarias
Un router PE debe anunciar al menos un bloque de etiquetas. El bloque de etiquetas es un conjunto continuo de etiquetas MPLS y es utilizado por los routers PE remotos para seleccionar una etiqueta VC remota. La etiqueta remota se utiliza para el PW entre el router PE local y el router PE remoto. (Un router PE puede anunciar varios bloques de etiquetas, como se explica en secciones posteriores.)
El VE-ID se debe configurar en cada PE. Identifica los routers PE dentro del dominio VPLS.
El tamaño del bloque VE (VBS) es el tamaño del bloque de etiquetas y tiene un valor predeterminado de 10. Si se configura 've range', se trata de ese valor. 've range' se puede configurar para que sea [11-100].
La base de etiquetas (LB) es el primer valor de etiqueta de un conjunto libre de etiquetas que el router PE puede reservar para este dominio VPLS.
VE Block Offset (VBO) es el valor de desplazamiento que se utiliza cuando un router PE debe crear varios bloques de etiquetas. La VBO se calcula con esta ecuación: VBO = RND(VE-ID/VBS) * VBS
Estos son cálculos de ejemplo:
- Si VBS = 8 y VE-ID = 2, VBO = RND(2/8) * 8 = 1
- Si VBS = 8 y VE-ID = 20, VBO = RND (20/8) * 8 = 16
- Si VBS = 50 y VE-ID = 199, VBO = RND (199/50) * 50 = 150
- Si VBS = 50 y VE-ID = 1002, VBO = RND (1002/50) * 50 = 1000
El bloque de etiquetas anunciado a los routers PE remotos es {LB, LB + 1, ? , LB + VBS - 1}. El bloque de etiquetas lo definen el LB y el VBS; el bloque comienza en LB y termina con (LB + VBS - 1).
Cada router PE puede crear varios bloques de etiquetas cuando sea necesario. El router debe asegurarse de que es un conjunto continuo de etiquetas libres.
Distinguidor de Ruta y Destinos de Ruta
Ejemplo de configuración 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
Esta es una explicación de los valores de configuración:
- El ID de VPN se configura como 100.
- El RD se toma de [ASN:vpn id], a menos que se configure explícitamente un RD. Aquí, la RD es la 1:100.
- Los destinos de ruta de importación/exportación son 32:64.
- El LB pertenece al intervalo [10000 2000]. El valor exacto de LB depende del primer conjunto de etiquetas locales continuas libres lo suficientemente grandes como para contener todas las etiquetas determinadas por el VBS.
- El VE-ID se configura como 1001.
- El VBS está configurado como 50.
- La VBO se calcula como: VBO = RND(VE-ID/VBS) * VBS o RND(1001/50) * 50 = 1000.
Comprobar rango de etiquetas
Puede verificar el rango de etiquetas con el comando show mpls label range:
PE1#show mpls label range
Downstream Generic label region: Min/Max label: 10000/20000
Hay un rango de etiquetas predeterminado por plataforma, que puede cambiar con el comando mpls label range.
Comprobar etiquetas
Puede verificar las etiquetas usadas reales para un bloque de etiquetas en la base de información de reenvío de etiquetas (LFIB) con el 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
En este ejemplo, PE1, el router local, reservó 50 etiquetas locales para el bloque de etiquetas. 'lbl-blk-id(1:0)' significa una ID de bloque de 1 y una instancia de bloque de 0, que identifica la primera etiqueta del bloque. La última etiqueta de este bloque es la etiqueta 10049.
La interfaz 'Saliente' en el LFIB es 'descartar' siempre y cuando no haya PW configurado para esa etiqueta local. Si se configura un PW, la interfaz 'Saliente' es 'none point2point'.
Comprobar bloque de etiquetas
El bloque de etiquetas asignado también se puede verificar con el comando show mpls infrastructure lfd block-database summary cuando se configura '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 es 10000. En este ejemplo, el bloque de etiquetas es de LB a (LB + VBS - 1) o de 10000 a (10000 + 50 - 1) = 10049.
Comprobar prefijo publicitado
Puede verificar el prefijo anunciado con el 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 ?
Ver prefijo en detalle
Para ver este prefijo en detalle, utilice el comando show bgp l2vpn vpls rd 1:100 ve-id 1001 block-offset 1000. Tenga en cuenta que especifica el VE-ID y el bloque de etiquetas, que se pueden encontrar en el 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 muestra el RD de 1:100, el VE-ID de 1001, el VBO de 1000, el VBS de 50 y el LB de 10000.
La comunidad extendida de información de capa 2 contiene esta información:
- El tipo Encap es 19 (VPLS)
- Indicadores de control: C = 0 (no se debe establecer una palabra de control); S = 0 (sin entrega secuenciada de tramas)
- MTU es 1500
La comunidad extendida RT contiene esta información:
- RT 1:100
- RT 32:64
Anunciar, Recibir y Procesar Bloques de Etiquetas en Mensajes de Actualización de BGP
Cuando un router PE local anuncia un bloque de prefijo/etiqueta VPLS L2VPN, cada router PE remoto debe intentar elegir una etiqueta de ese rango para usarla como etiqueta VC remota.
- Si el router PE remoto tiene éxito, utiliza esa etiqueta VC remota y la programa en el plano de datos. BGP no proporciona más señalización.
- Si el router PE remoto falla, debe esperar a que el router PE local anuncie otro prefijo VPLS L2VPN y luego intentar elegir otra etiqueta VC remota de ese bloque de etiquetas.
Suponga que PE1 es un PE local con la configuración anterior y que PE2 es un PE remoto con esta configuración:
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 1002
ve range 50
!
mpls label range 3000 60000
PE2: Recibir actualización de BGP
PE2 recibe esta actualización 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: Buscar una etiqueta
PE2 necesita encontrar una etiqueta que pueda utilizar como etiqueta VC remota para el PW hacia PE1.
PE2 primero debe determinar si la VBO está dentro del rango de su configuración. PE2 verifica su VE-ID con el rango anunciado por PE1 con el cálculo VBO <= VE-ID < VBO + VBS. En este caso, 1000 <= 1002 < 1000 + 50, por lo que PE2 tiene éxito.
Luego, PE2 necesita elegir una etiqueta VC remota. La etiqueta del demultiplexor (VC) que utilizará el PE remoto se calcula como (LB + VE-ID - VBO).
Desde el prefijo anterior, LB es 10000 y VBO es 1000. El VE-ID es el de PE2 y es 1002. Por lo tanto, PE2 elige la etiqueta (LB + VE-ID - VBO) = (10000 + 1002 - 1000) = 10002.
Utilice el comando show l2vpn vfi name one para verificar esto:
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: Enviar prefijo a PE1
PE2 luego envía su prefijo 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: Buscar una etiqueta
PE1 es ahora el PE remoto y necesita encontrar una etiqueta que pueda utilizar como etiqueta VC remota para el PW hacia PE2.
PE1 primero debe determinar si la VBO está dentro del rango de su configuración. PE1 verifica su VE-ID con el rango anunciado por PE2 con el cálculo VBO <= VE-ID < VBO + VBS. En este caso, 1000 <= 1001 < 1000 + 50, por lo que PE1 tiene éxito.
Luego, PE1 necesita elegir una etiqueta VC remota. La etiqueta del demultiplexor (VC) que utilizará el PE remoto se calcula como (LB + VE-ID - VBO).
Desde el prefijo anterior, LB es 3100 y VBO es 1000. El VE-ID es el de PE1 y es 1001. Por lo tanto, PE1 selecciona la etiqueta (LB + VE-ID - VBO) = (3100 + 1001 - 1000) = 3101.
Utilice el comando show l2vpn vfi name one para verificar esto:
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
Comandos de verificación adicionales
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
Varios prefijos VPLS L2VPN anunciados por el router PE para un VFI
Es posible que un PE deba anunciar varios bloques de etiquetas para una instancia de reenvío virtual (VFI).
Si el VE-ID del PE remoto no cae en el rango anunciado por el PE local, el PE remoto no puede elegir una etiqueta remota para el PW. Este cálculo, descrito anteriormente, es VBO <= VE-ID < VBO + VBS.
Si esta verificación falla, el VE-ID del PE remoto está fuera del intervalo. El PE remoto ignora el prefijo recibido del PE local. El PE local aprende que el PE remoto está fuera de intervalo cuando recibe el prefijo que el PE remoto anuncia. El PE local necesita determinar qué etiqueta remota utilizar para ese router PE remoto. El PE local también envía un nuevo segundo prefijo para un nuevo bloque de etiquetas locales al PE remoto, que el PE remoto debería poder utilizar para seleccionar una etiqueta remota.
Configuración PE1
El ejemplo anterior se continúa aquí; PE1 todavía tiene:
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
Configuración de PE2
PE2 ahora tiene un VE-ID de 1002 y esta configuración:
l2vpn vfi context one
vpn id 100
autodiscovery bgp signaling bgp
ve id 10002
ve range 50
!
mpls label range 3000 60000
Bloques de etiquetas iniciales
Tanto PE1 como PE2 comienzan con estos bloques de etiquetas iniciales.
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 ?
Intercambio PE1 y PE2
Utilice el comando debug bgp l2vpn vpls updates para revisar el intercambio PE1 y PE2, luego utilice el comando show bgp l2vpn vpls rd 1:100 para revisar los detalles.
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 ?
Análisis del intercambio PE1 y PE2
PE1 y PE2 ahora han anunciado dos bloques de etiquetas entre sí.
PE1 anuncia primero una actualización BGP inicial 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
Esta actualización tiene el NLRI establecido según la configuración en PE1.
Luego, PE1 recibe la actualización BGP inicial 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 anuncia el prefijo inicial con los valores VE-ID 10002, VBO = 10000, VBS = 50, LB = 3000.
PE1 observa que el PE2 está fuera del intervalo desde que PE1 comenzó con el bloque de etiquetas LB a (LB + VBS - 1) o de 10000 a (10000 + 50 - 1) = 10049.
PE1 debe determinar si la VBO está dentro del rango de su configuración. Por lo tanto, el VE-ID de PE2 debe verificarse con el rango anunciado por PE1. El cálculo es VBO <= VE-ID < VBO + VBS. En este caso, 1000 <= 10002 < 1000 + 50, lo que no es cierto. Por lo tanto, PE1 necesita enviar un nuevo bloque de etiquetas para acomodar el VE-ID fuera de rango de PE2. En reacción a la actualización inicial de PE2, PE1 formatea y envía una actualización BGP adicional nueva a PE2. PE1 ahora utiliza una nueva 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
Para PE1, la VBO es 10000, la VBS es 50, la LB es 10053. La comprobación de PE2 es VBO <= VE-ID < VBO + VBS. En este caso, 10000 <= 10002 < 10000 + 50, lo que es cierto. PE2 puede elegir una etiqueta remota de este nuevo bloque de etiquetas [10053 - 10102] de PE1. En otras palabras, PE1 agregó un nuevo bloque de etiquetas para acomodar el PE2 y envió dos mensajes de actualización BGP.
Lo mismo ocurre en la dirección opuesta. PE2 recibe la actualización BGP inicial de PE1. Esta actualización tiene estos valores VE-ID 1001, VBO = 1000, VBS = 50, LB = 10000.
PE2 observa que el VE-ID de PE1 está fuera del rango con la actualización inicial de PE2. La comprobación de PE1 es VBO <= VE-ID < VBO + VBS o 10000 <= 1001 < 10000 + 50. En respuesta, PE2 envía esta segunda actualización de BGP, con un nuevo bloque de etiquetas [3053 - 3102] que acomoda el VE-ID de 1001 de PE1 porque la verificación de PE1 es VBO <= VE-ID < VBO + VBS o 1000 <= 1001 < 1000 + 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
Detalles del prefijo
Estos son los detalles de los dos prefijos originados por 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
Aquí, dos routers PE tienen esquemas de número no contiguos, lo que hace que cada PE envíe dos actualizaciones de BGP. Si hay muchos routers PE con esquemas de número no contiguos, el número de actualizaciones BGP crece rápidamente.
www.cisco.com dice: "Por ejemplo, las secuencias de numeración VE-ID como 1, 2, 3 o 501, 502, 503 son buenas porque los VE-ID son contiguos. Un esquema de numeración como 100, 200, 300 es malo porque no es contiguo".
Los primeros ejemplos de 1, 2, 3 o 501, 502, 503 son números contiguos, por lo que cada router PE necesita enviar solamente un prefijo VPLS L2VPN. Con el tercer ejemplo (100, 200, 300), cada PE debe enviar muchos prefijos VPLS L2VPN. Para los números no contiguos, un rango de VE lo suficientemente grande mantendría el número de prefijos que se anunciarán más bajo. Sin embargo, la cantidad de etiquetas reservadas (desperdiciadas) es aún mayor.
Interoperabilidad
Si el BGP Route Reflector (RR) ejecuta un software que no comprende RFC 4761, pero que sí admite RFC 4762, el comando de configuración neighbor BGP especiales x.x.x prefix-length-size 2 se necesita en el RR para que refleje las actualizaciones de BGP utilizadas para RFC 4761.
Los prefijos se envían normalmente con una longitud de 1 byte. El software Cisco IOS implementó el borrador 'draft-ietf-l2vpn-signaling-08', que posteriormente se convirtió en RFC 6074. Se eligió un campo de longitud de 1 byte en el momento, indicando la longitud en bits.
RFC 6074 Provisioning, Auto-Discovery y Signaling in Layer 2 Virtual Private Networks (L2VPNs) especifica que la codificación NLRI para la detección automática de BGP debe tener una longitud de 2 bytes. Los 2 bytes indican cuántos bytes de prefijo siguen en el prefijo de longitud variable.
La sección 7 de RFC 6074, "Interoperabilidad BGP-AD y VPLS-BGP", establece:
"Tanto BGP-AD como VPLS-BGP [RFC4761] utilizan el mismo AFI/SAFI. Para que tanto BGP-AD como VPLS-BGP coexistan, la longitud de NLRI se debe utilizar como demultiplexor.
El BGP-AD NLRI tiene una longitud NLRI de 12 bytes, que contiene solamente un RD de 8 bytes y un VSI-ID de 4 bytes. VPLS-BGP [RFC4761] utiliza una longitud NLRI de 17 bytes. Por lo tanto, las implementaciones de BGP-AD deben ignorar el NLRI que son mayores de 12 bytes."
Si el comando neighbor x.x.x.x prefix-length-size 2 no está presente en los RRs, el vecino BGP no aparece y el RR interpreta el campo length como 1 byte solamente. Esta notificación aparece en el 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
Esta notificación aparece en el router PE:
%BGP-3-NOTIFICATION: received from neighbor 10.100.1.4 3/10 (illegal network)
1 bytes FD
Esto ocurre porque, en la implementación original de la detección automática de BGP en el Cisco IOS Software, el campo de longitud era de 1 byte.
Si coloca el comando neighbor x.x.x.x prefix-length-size 2 en el RR, las notificaciones no aparecen.
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
Comentarios