Contenido

Introducción

Problema

Arquitectura de la solución

Identificación del punto final del router PE

Identidad VPLS y Etiquetas MPLS

Información de encapsulación

Prefijo de Detección Automática BGP VPLS y Prefijo de Señalización BGP VPLS

Ejemplo de configuración del software Cisco IOS

Bloque de etiquetas publicitarias

Distinguidor de Ruta y Destinos de Ruta

Ejemplo de configuración de PE1

Comprobar rango de etiquetas

Comprobar etiquetas

Comprobar bloque de etiquetas

Comprobar prefijo publicitado

Ver prefijo en detalle

Anunciar, Recibir y Procesar Bloques de Etiquetas en Mensajes de Actualización de BGP

PE2: Recibir actualización de BGP

PE2: Buscar una etiqueta

PE2: Enviar prefijo a PE1

PE1: Buscar una etiqueta

Comandos de verificación adicionales

Varios prefijos VPLS L2VPN anunciados por el router PE para un VFI

Configuración PE1

Configuración de PE2

Bloques de etiquetas iniciales

Intercambio PE1 y PE2

Análisis del intercambio PE1 y PE2

Detalles del prefijo

Interoperabilidad

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:

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

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

Nota: En la implementación del software Cisco IOS y Cisco NX-OS, todos los routers PE deben tener el mismo RD dentro del mismo dominio 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

Nota: El VBS predeterminado (10) es pequeño para que las etiquetas locales no se malgasten.

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