La página MPLSVPLS cubre la introducción general al servicio VPLS y la configuración de túneles VPLS basados en LDP. Debido a su naturaleza estática, los túneles VPLS basados en LDP tienen problemas de escalabilidad que surgen cuando aumenta la cantidad de VPLS y sitios que participan en VPLS. Uno de los problemas es el requisito de mantener una malla completa de túneles LDP entre sitios que forman VPLS. En caso de que la cantidad de sitios en VPLS sea alta, agregar un nuevo sitio a VPLS existente puede volverse una carga para el administrador de la red.
El descubrimiento automático basado en BGP y la señalización de túneles VPLS pueden ayudar a evitar la complejidad de la configuración a expensas de ejecutar el protocolo BGP entre enrutadores VPLS. En general, el VPLS basado en BGP tiene dos propósitos:
-
detección automática: no es necesario configurar cada enrutador VPLS con todos los puntos finales remotos de los túneles VPLS, siempre que haya medios para entregar NLRI multiprotocolo BGP entre ellos: los enrutadores descubren los puntos finales remotos de los túneles a partir de las actualizaciones BGP recibidas;
-
Señalización: las etiquetas utilizadas para los túneles VPLS por puntos finales remotos se distribuyen en las mismas actualizaciones de BGP, lo que significa que no hay necesidad de sesiones LDP dirigidas entre puntos finales del túnel como en el caso de VPLS señalados por LDP.
Por ejemplo, si se usa VPLS señalado por LDP, agregar un nuevo sitio a VPLS existente significaría configurar un enrutador que conecte un nuevo sitio para establecer túneles con el resto de los sitios y también configurar todos los demás enrutadores para establecer túneles con el enrutador que conecta este nuevo sitio. VPLS basado en BGP, si se configura correctamente, elimina la necesidad de ajustar la configuración en todos los enrutadores que forman VPLS.
El requisito de intercambiar BGP NLRI entre enrutadores VPLS significa que se debe establecer una malla completa de sesiones BGP entre enrutadores que forman VPLS o se debe usar un reflector de ruta. En caso de que se establezca una malla completa de sesiones BGP entre enrutadores VPLS, los beneficios de VPLS basado en BGP sobre VPLS señalados por LDP son cuestionables: cuando se agrega un nuevo sitio a VPLS, aún se debe ingresar la configuración de pares BGP en cada enrutador que forma VPLS dado. Cuando se usa el reflector de ruta BGP, agregar un nuevo sitio a VPLS se vuelve más simple: el enrutador que conecta el nuevo sitio solo debe emparejarse con el reflector de ruta y no se requiere configuración adicional en otros enrutadores. Teniendo en cuenta que el reflector de ruta también puede ser uno de los enrutadores que forman VPLS, no hay necesidad de equipos separados adicionales. Por supuesto,
El inconveniente de ejecutar VPLS basado en BGP es el requisito de configurar BGP, lo que requiere que el administrador de red tenga al menos un conocimiento básico de BGP, sus capacidades multiprotocolo y reflectores de ruta. Por lo tanto, se recomienda implementar VPLS con señal LDP si la cantidad de sitios y redes VPLS es pequeña, la topología es más estática, es decir, los beneficios de usar BGP no son obvios.
Tenga en cuenta que VPLS basado en BGP es un método solo para el intercambio de etiquetas de túnel VPLS, no se ocupa de la entrega de tráfico entre los extremos del túnel VPLS, por lo que se debe garantizar la entrega general de tramas MPLS entre los extremos del túnel, como se describe en MPLSVPLS.
Material de lectura sugerido:
-
RFC 4761, servicio de LAN privada virtual (VPLS) mediante BGP para detección automática y señalización
-
RFC 4456, Reflexión de ruta BGP: una alternativa al BGP interno de malla completa (IBGP)
Ejemplo de red:
Considere la misma red que se usa para el ejemplo de VPLS señalado por LDP en MPLSVPLS:
Los requisitos de los clientes A y B son los mismos: los segmentos de Ethernet deben estar conectados de forma transparente. Teniendo en cuenta la simplicidad de la topología de red dada, el proveedor de servicios ha decidido utilizar R5 como reflector de ruta y no tener un reflector de ruta de respaldo. Considere que la conmutación de MPLS está configurada y en ejecución, como se explica en MPLSVPLS, pero aún no se ha aplicado ninguna configuración de VPLS. el resto de este documento se ocupa de los detalles que se introducen mediante el uso de BGP para la señalización VPLS.
Configuración de sesión IBGP para señalización VPLS
Al principio, se debe configurar la instancia BGP, también se puede usar la instancia predeterminada:
[admin@R1] /routing bgp instance> print
Flags: X - disabled
0 name="default" as=65530 router-id=0.0.0.0 redistribute-connected=no redistribute-static=no
redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no out-filter=""
client-to-client-reflection=yes ignore-as-path-len=no
Para habilitar la entrega de VPLS NLRI a través de BGP, se debe utilizar la capacidad multiprotocolo de BGP. Esto se habilita especificando l2vpn en la configuración de familias de direcciones del par BGP .
Por ejemplo, para configurar la conexión BGP entre R1 y R5, se deben emitir los siguientes comandos.
En R1:
[admin@R1] /routing bgp peer> add remote-address=9.9.9.5 remote-as=65530 address-families=l2vpn \
update-source=lobridge
y en R5:
[admin@R5] /routing bgp peer> add remote-address=9.9.9.1 remote-as=65530 address-families=l2vpn \
update-source=lobridge
La conexión BGP debe establecerse entre R1 y R5. Esto puede ser confirmado por:
[admin@R1] /routing bgp peer> print status
Flags: X - disabled
0 name="peer1" instance=default remote-address=9.9.9.5 remote-as=65530 tcp-md5-key=""
nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter=""
out-filter="" address-families=l2vpn update-source=lobridge remote-id=4.4.4.5
local-address=9.9.9.1 uptime=3s prefix-count=0 updates-sent=0 updates-received=0
withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m used-hold-time=3m
used-keepalive-time=1m refresh-capability=yes state=established
Hay varias cosas a tener en cuenta sobre la configuración de pares BGP:
-
No es necesario distribuir ninguna ruta IP o IPv6 e incluso no es necesario tener soporte IP o IP6 a través de una conexión BGP para poder intercambiar VPLS NLRI, es suficiente especificar address-families=l2vpn.
-
Las direcciones de "bucle invertido" de los enrutadores se utilizan como direcciones de pares BGP (la dirección local se configura mediante la configuración de la fuente de actualización). El par BGP, cuando origina VPLS NLRI, especifica su dirección local como BGP NextHop (por ejemplo, en la configuración dada R1 que origina BGP NLRI usará la dirección 9.9.9.1 como dirección BGP NextHop), el enrutador VPLS receptor usa la dirección BGP NextHop recibida como dirección de punto final del túnel y por lo tanto utiliza una etiqueta de transporte que asegura la entrega a BGP NextHop. Para que la aparición del penúltimo salto funcione correctamente, se recomienda utilizar la dirección IP de loopback para esto. Consulte la discusión relacionada con el penúltimo salto en MPLSVPLS.
Configuración del reflector de ruta
En su sentido más simple, BGP Route Reflector vuelve a anunciar las rutas IBGP recibidas sin cambiar BGP NextHop por ruta. Esta función se puede utilizar para evitar configurar una malla completa de conexiones BGP. Tenga en cuenta que para que el enrutador pueda operar como reflector de ruta para VPLS NLRI, no es necesario que participe en ningún VPLS, incluso no es necesario que tenga soporte MPLS. Aún así, es obligatorio que los enrutadores VPLS puedan establecer sesiones BGP con reflector de ruta, por lo que la conectividad IP es imprescindible.
La instancia BGP de Route Reflector debe configurarse con la configuración client-to-client-reflection=yes:
admin@R5] /routing bgp instance> print
Flags: X - disabled
0 name="default" as=65530 router-id=0.0.0.0 redistribute-connected=no redistribute-static=no
redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no out-filter=""
client-to-client-reflection=yes ignore-as-path-len=no
Además, los pares en el reflector de ruta deben configurarse con la configuración route-reflect=yes:
[admin@R5] /routing bgp peer> print
Flags: X - disabled
0 name="peer1" instance=default remote-address=9.9.9.1 remote-as=65530 tcp-md5-key=""
nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter=""
out-filter="" address-families=l2vpn update-source=lobridge
[admin@R5] /routing bgp peer> set 0 route-reflect=yes
[admin@R5] /routing bgp peer> print
Flags: X - disabled
0 name="peer1" instance=default remote-address=9.9.9.1 remote-as=65530 tcp-md5-key=""
nexthop-choice=default multihop=no route-reflect=yes hold-time=3m ttl=255 in-filter=""
out-filter="" address-families=l2vpn update-source=lobridge
Para permitir que R5 opere como reflector de ruta, todos sus pares deben agregarse con la configuración route-reflect=yes. Entonces, para habilitar la distribución adecuada de VPLS NLRI, R5 debe configurarse con 2 pares BGP: R1 y R4:
[admin@R5] /routing bgp peer> print status
Flags: X - disabled
0 name="peer1" instance=default remote-address=9.9.9.1 remote-as=65530 tcp-md5-key=""
nexthop-choice=default multihop=no route-reflect=yes hold-time=3m ttl=255 in-filter=""
out-filter="" address-families=l2vpn update-source=lobridge remote-id=1.1.1.1
local-address=9.9.9.5 uptime=5m55s prefix-count=0 updates-sent=0 updates-received=0
withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m used-hold-time=3m
used-keepalive-time=1m refresh-capability=yes state=established
1 name="peer2" instance=default remote-address=9.9.9.4 remote-as=65530 tcp-md5-key=""
nexthop-choice=default multihop=no route-reflect=yes hold-time=3m ttl=255 in-filter=""
out-filter="" address-families=l2vpn update-source=lobridge remote-id=3.3.3.4
local-address=9.9.9.5 uptime=23s prefix-count=0 updates-sent=0 updates-received=0
withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m used-hold-time=3m
used-keepalive-time=1m refresh-capability=yes state=established
Pero R1 y R4 solo deben emparejarse con R5. En R1:
[admin@R1] /routing bgp peer> print status
Flags: X - disabled
0 name="peer1" instance=default remote-address=9.9.9.5 remote-as=65530 tcp-md5-key=""
nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter=""
out-filter="" address-families=l2vpn update-source=lobridge remote-id=4.4.4.5
local-address=9.9.9.1 uptime=6m33s prefix-count=0 updates-sent=0 updates-received=0
withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m used-hold-time=3m
used-keepalive-time=1m refresh-capability=yes state=established
Y en R4:
[admin@R4] /routing bgp peer> print status
Flags: X - disabled
0 name="peer1" instance=default remote-address=9.9.9.5 remote-as=65530 tcp-md5-key=""
nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter=""
out-filter="" address-families=l2vpn update-source=lobridge remote-id=4.4.4.5
local-address=9.9.9.4 uptime=3s prefix-count=0 updates-sent=0 updates-received=0
withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m used-hold-time=3m
used-keepalive-time=1m refresh-capability=yes state=established
El uso de reflector de ruta significa que para agregar un nuevo sitio a algunos VPLS, por ejemplo, conectado por el enrutador Ry, significaría agregar Ry como par BGP a R5 (con la configuración route-reflect=yes) y agregar R5 como par BGP a Ry.
Configuración de VPLS señalados por BGP
Configuración de puentes de ethernet
Los túneles VPLS señalados por BGP se crean dinámicamente cuando se reciben los NLRI de BGP adecuados. Por lo tanto, no es necesario configurar ninguna interfaz VPLS. Aún así, para entregar paquetes de manera transparente desde el segmento de Ethernet a través de VPLS, se debe configurar el puente. Por ejemplo, en el R1 se crean dos puentes, denominados "A" y "B", con las interfaces de ethernet orientadas al cliente adecuadas que se les agregan:
[admin@R1] /interface bridge> print
Flags: X - disabled, R - running
0 R name="lobridge" mtu=1500 arp=enabled mac-address=00:00:00:00:00:00 protocol-mode=none
priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s
forward-delay=15s transmit-hold-count=6 ageing-time=5m
1 R name="A" mtu=1500 arp=enabled mac-address=00:01:50:E7:00:09 protocol-mode=none
auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s
priority=0x8000 transmit-hold-count=6 ageing-time=5m
2 R name="B" mtu=1500 arp=enabled mac-address=00:01:50:E7:00:08 protocol-mode=none
auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s
priority=0x8000 transmit-hold-count=6 ageing-time=5m
[admin@R1] /interface bridge> port print
Flags: X - disabled, I - inactive, D - dynamic
# INTERFACE BRIDGE PRIORITY PATH-COST HORIZON
0 ether2 A 0x80 10 none
1 ether1 B 0x80 10 none
Configuración de instancias VPLS señaladas por BGP
La configuración de la instancia VPLS señalada por BGP hace que el enrutador anuncie VPLS BGP NLRI que anuncia que ese enrutador en particular pertenece a algún VPLS. Al recibir dicho anuncio, otros miembros del mismo VPLS saben que deben establecer un túnel VPLS con este enrutador.
Para configurar VPLS para los clientes A y B, en el R1 se deben emitir los siguientes comandos:
[admin@R1] /interface vpls bgp-vpls> add bridge=A bridge-horizon=1 route-distinguisher=1:1 \
site-id=1 import-route-targets=1:1 export-route-targets=1:1
[admin@R1] /interface vpls bgp-vpls> add bridge=B bridge-horizon=1 route-distinguisher=2:2 \
site-id=1 import-route-targets=2:2 export-route-targets=2:2
Nota: Dado que v3.20, vpls-id se reemplazó con objetivos de ruta de importación/exportación separados para brindar más flexibilidad.
La configuración del distintivo de ruta especifica el valor que se adjunta a VPLS NLRI para que los enrutadores receptores puedan distinguir anuncios que de otro modo podrían tener el mismo aspecto. Esto implica que se debe utilizar un distintivo de ruta único para cada VPLS. No es necesario usar el mismo distintivo de ruta para algunos VPLS en todos los enrutadores que forman ese VPLS como distintivo no se usa para determinar si algún BGP NLRI está relacionado con un VPLS en particular (para esto se usa el atributo Route Target), pero es obligatorio tienen diferentes distintivos para diferentes VPLSes.
La configuración export-route-targets se usa para etiquetar BGP NLRI.
La configuración import-route-targets se usa para determinar si BGP NLRI está relacionado con un VPLS particular.
La configuración del ID del sitio debe ser única entre los miembros de un VPLS particular. Es aconsejable, aunque no obligatorio, asignar valores de identificación del sitio en el rango más estrecho posible, ya que aumenta la eficiencia de BGP (para obtener detalles, consulte RFC 4761).
La configuración del puente especifica el puente al que se deben agregar los túneles VPLS creados dinámicamente.
Bridge-horizon especifica el valor de horizonte que se usará para los puertos agregados al puente (consulte la discusión sobre puentes de horizonte dividido en MPLSVPLS).
Después de configurar R4 como miembro de VPLS 1:1 (utilizado para el cliente A) con el comando:
[admin@R4] /interface vpls bgp-vpls> add bridge=A bridge-horizon=1 route-distinguisher=1:1 \
site-id=4 import-route-targets=1:1 export-route-targets=1:1
El túnel VPLS dinámico se crea en R1 y R4. En R1 esto se puede confirmar:
[admin@R1] > /interface vpls print
Flags: X - disabled, D - dynamic, R - running, B - bgp-signaled
0 RDB name="vpls1" mtu=1500 mac-address=02:FA:33:C4:7A:A9 arp=enabled
disable-running-check=no remote-peer=9.9.9.4 cisco-style=no
cisco-style-id=0 vpls=bgp-vpls1
[admin@R1] > /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic
# INTERFACE BRIDGE PRIORITY PATH-COST HORIZON
0 ether2 A 0x80 10 none
1 ether1 B 0x80 10 none
2 D vpls1 A 0x80 50 1
Aquí también hemos confirmado que la reflexión de ruta configurada en R5 funciona como se esperaba, ya que no existe una relación de pares BGP entre R1 y R4.
Adicionalmente debemos configurar R5 para participar en VPLS para el cliente A:
[admin@R5] /interface vpls bgp-vpls> add bridge=A bridge-horizon=1 route-distinguisher=1:1 \
site-id=5 import-route-targets=1:1 export-route-targets=1:1
Esto hace que R1 y R4 establezcan un túnel VPLS adicional con R5. Por ejemplo en R1:
[admin@R1] > /interface vpls print
Flags: X - disabled, D - dynamic, R - running, B - bgp-signaled
0 RDB name="vpls1" mtu=1500 mac-address=02:FA:33:C4:7A:A9 arp=enabled
disable-running-check=no remote-peer=9.9.9.4 cisco-style=no
cisco-style-id=0 vpls=bgp-vpls1
1 RDB name="vpls2" mtu=1500 mac-address=02:FF:B7:0E:4B:97 arp=enabled
disable-running-check=no remote-peer=9.9.9.5 cisco-style=no
cisco-style-id=0 vpls=bgp-vpls1
Y puerto de puente para agregar con el valor de horizonte adecuado:
[admin@R1] > /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic
# INTERFACE BRIDGE PRIORITY PATH-COST HORIZON
0 ether2 A 0x80 10 none
1 ether1 B 0x80 10 none
2 D vpls1 A 0x80 50 1
3 D vpls2 A 0x80 50 1
Para completar la configuración, se debe aplicar la configuración necesaria para el cliente B VPLS a R5:
[admin@R5] /interface vpls bgp-vpls> add site-id=5 route-distinguisher=2:2 bridge=B \
bridge-horizon=1 import-route-targets=2:2 export-route-targets=2:2
Como resultado, se establece una malla completa de túneles VPLS, por ejemplo, en R5:
[admin@R5] /interface vpls> print
Flags: X - disabled, D - dynamic, R - running, B - bgp-signaled
0 RDB name="vpls1" mtu=1500 mac-address=02:FA:5C:28:29:D3 arp=enabled
disable-running-check=no remote-peer=9.9.9.1 cisco-style=no
cisco-style-id=0 vpls=bgp-vpls1
1 RDB name="vpls2" mtu=1500 mac-address=02:EA:51:31:3E:2B arp=enabled
disable-running-check=no remote-peer=9.9.9.4 cisco-style=no
cisco-style-id=0 vpls=bgp-vpls1
2 RDB name="vpls3" mtu=1500 mac-address=02:F6:CF:06:1E:CB arp=enabled
disable-running-check=no remote-peer=9.9.9.1 cisco-style=no
cisco-style-id=0 vpls=bgp-vpls2
Tenga en cuenta que el par remoto para los túneles VPLS es la dirección BGP NextHop tal como se recibió en BGP Update. Por ejemplo, BGP inicia sesión en R5 cuando recibe la actualización para VPLS 2:2 (cliente B), diga:
11:24:06 route,bgp,debug,packet UPDATE Message
11:24:06 route,bgp,debug,packet RemoteAddress=9.9.9.1
11:24:06 route,bgp,debug,packet MessageLength=79
11:24:06 route,bgp,debug,packet
11:24:06 route,bgp,debug,packet PathAttributes
11:24:06 route,bgp,debug,packet bgp-origin=INCOMPLETE
11:24:06 route,bgp,debug,packet bgp-nexthop=9.9.9.1
11:24:06 route,bgp,debug,packet bgp-localpref=100
11:24:06 route,bgp,debug,packet bgp-extended-communities=RT:2:2
11:24:06 route,bgp,debug,packet
11:24:06 route,bgp,debug,packet NLRI= rd
11:24:06 route,bgp,debug,packet type=0
11:24:06 route,bgp,debug,packet administrator=2
11:24:06 route,bgp,debug,packet assigned-number=2 veId=1 veBlockOffset=0 veBlockSize=16
labelBase=40
Esto se refleja en el túnel de VPLS dinámico, donde el par remoto para el túnel con export-route-targer 2:2 es 9.9.9.1. Esto implica que R5 usa la ruta IGP que conduce a 9.9.9.1 para decidir qué etiqueta de transporte usar. En dado caso existen rutas /32 IGP distribuidas en la red mediante OSPF, por lo tanto:
[admin@R5] /interface vpls> monitor 2 once
remote-label: 45
local-label: 40
remote-status:
igp-prefix: 9.9.9.1/32
igp-nexthop: 4.4.4.3
imposed-labels: 17,45
Muestra que se usa la ruta 9.9.9.1/32 y que el siguiente salto inmediato es 4.4.4.3. Las etiquetas adjuntas a los paquetes VPLS son 17 y 45, donde 45 es el mapeo de etiquetas recibido con BGP Update y 17 es la etiqueta asignada por R3 para el prefijo 9.9.9.1/32:
[admin@R5] > /mpls remote-bindings print
Flags: X - disabled, A - active, D - dynamic
# DST-ADDRESS NEXTHOP LABEL PEER
...
14 AD 9.9.9.1/32 4.4.4.3 17 9.9.9.3:0
...