Perfil 0
Perfil 1
Perfil 3
En esta parte del artículo, veremos la opción de reemplazar la señalización dentro de la red superpuesta de PIM a BGP.
Como se discutió anteriormente (ver el artículo sobre BGP Auto-Discovery), para transmitir análogos de mensajes PIM, se inventaron varios tipos de rutas en BGP, cada una de las cuales tiene cierta funcionalidad. Además, hay más tipos de rutas que tipos de mensajes en PIM.
"¿Por qué poner una lechuza en un globo terráqueo?" - puede preguntar, porque todo funciona muy bien con PIM también. Y, en general, tendrás razón. La razón principal de este movimiento de caballero es la escalabilidad. PIM, al ser en esencia un protocolo Soft Driven, requiere el envío constante de mensajes de servicio para su trabajo, lo que a un cierto tamaño de implementación (si el número de nodos comienza a exceder un par de cientos o miles) introduce limitaciones debido a la carga inevitable en la CPU. BGP es un protocolo duro, es decir, si algo se dijo una vez, no se repite; cualquier actualización de BGP se debe únicamente a cambios en la red.
Hoy consideraremos dos escenarios: usar PIM SSM y PIM ASM dentro de C-VRF.
C-PIM SSM
Para una comprensión más simple de la señalización BGP para la construcción de árboles de multidifusión, comencemos nuestra conversación con un PIM SSM más simple.
En primer lugar, eliminemos la configuración actual del punto de encuentro y desactivemos los destinatarios del tráfico:
CE4(config)#interface Loopback0
CE4(config-if)#no ip igmp join-group 231.1.1.2
CE4(config-if)#
CE15(config)#no ip pim bsr-candidate Loopback0 0
CE15(config)#no ip pim rp-candidate Loopback0 group-list 1
En todos los PE, indicaremos que BGP funcionará para señalización en lugar de PIM. Esto se hace con el siguiente comando:
ip vrf C-ONE
mdt overlay use-bgp
El punto de partida para la observación será la situación sin la presencia de fuentes y receptores de tráfico multidifusión. Solo las rutas de tipo 1 deben estar presentes en la tabla BGP:
PE1#show bgp ipv4 mvpn all
BGP table version is 406, local router ID is 1.1.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,
t secondary path,
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.1.1.1:1 (default for vrf C-ONE)
*> [1][1.1.1.1:1][1.1.1.1]/12
0.0.0.0 32768 ?
*>i [1][1.1.1.1:1][2.2.2.2]/12
2.2.2.2 0 100 0 ?
*>i [1][1.1.1.1:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
*>i [1][1.1.1.1:1][4.4.4.4]/12
4.4.4.4 0 100 0 ?
Route Distinguisher: 2.2.2.2:1
*>i [1][2.2.2.2:1][2.2.2.2]/12
2.2.2.2 0 100 0 ?
Route Distinguisher: 3.3.3.3:1
Network Next Hop Metric LocPrf Weight Path
*>i [1][3.3.3.3:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
Route Distinguisher: 4.4.4.4:1
*>i [1][4.4.4.4:1][4.4.4.4]/12
4.4.4.4 0 100 0 ?
Conectemos al destinatario:
CE4(config-if)#ip igmp join 230.1.1.1 source 11.11.11.11
En el PE más cercano, se crea una ruta BGP del séptimo tipo; este es el equivalente al mensaje de unión PIM (S, G):
PE4#show bgp ipv4 mvpn all
Route Distinguisher: 1.1.1.1:1
*> [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22
0.0.0.0 32768 ?
Lógicamente, esta ruta debe estar presente solo en PE4 y PE1 (porque es por ellas por donde debe pasar el tráfico) y ausente en PE2 y PE3. Vamos a revisar:
PE1#show bgp ipv4 mvpn all | b \[7\]
*>i [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22
4.4.4.4 0 100 0 ?
PE2#show bgp ipv4 mvpn all | b \[7\]
PE2#
PE3#show bgp ipv4 mvpn all | b \[7\]
PE3#
¿Cómo es que la ruta generada originalmente en PE4 solo se importa en PE1?
Veamos la entrada en la tabla BGP con más detalle:
PE4#show bgp ipv4 mvpn all route-type 7 1.1.1.1:1 65001 11.11.11.11 230.1.1.1
BGP routing table entry for [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22, version 533
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
7
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (4.4.4.4)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:1.1.1.1:1
rx pathid: 1, tx pathid: 0x0
La entrada de prefijo contiene la comunidad extendida Route-target = 1.1.1.1:1, que fue agregado al prefijo vpnv4 por el enrutador, que es un vecino RPF desde el punto de PE4:
PE1#show bgp vpnv4 unicast rd 1.1.1.1:1 11.11.11.11/32
BGP routing table entry for 1.1.1.1:1:11.11.11.11/32, version 670
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1 17
Refresh Epoch 4
65011
172.1.11.11 (via vrf C-ONE) from 172.1.11.11 (11.11.11.11)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
mpls labels in/out 10018/nolabel
rx pathid: 0, tx pathid: 0x0
PE1#
PE2#show bgp vpnv4 unicast rd 2.2.2.2:1 11.11.11.11/32
BGP routing table entry for 2.2.2.2:1:11.11.11.11/32, version 762
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 152
65011, imported path from 1.1.1.1:1:11.11.11.11/32 (global)
1.1.1.1 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
Originator: 1.1.1.1, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 1.1.1.1:1:1.1.1.1
mpls labels in/out nolabel/10018
rx pathid: 0, tx pathid: 0x0
Comprobemos la conectividad:
CE1#ping 230.1.1.1 so 11.11.11.11 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
Reply to request 0 from 14.14.14.14, 7 ms
Reply to request 0 from 14.14.14.14, 8 ms
Reply to request 1 from 14.14.14.14, 7 ms
Reply to request 1 from 14.14.14.14, 9 ms
Reply to request 2 from 14.14.14.14, 7 ms
Reply to request 2 from 14.14.14.14, 7 ms
ASM C-PIM
En el caso de C-PIM en modo SSM, todo es bastante sencillo. Para que mVPN funcione correctamente, es suficiente crear dos (tipos) rutas BGP adicionales.
Pero, ¿qué pasa si se usa un PIM ASM más complejo dentro del C-VRF?
En primer lugar, vemos que todos los CE conocen información sobre el punto de encuentro:
CE2#show ip pim rp mapp
CE2#show ip pim rp mapping
Auto-RP is not enabled
PIM Group-to-RP Mappings
Group(s) 231.1.1.0/24
RP 15.15.15.15 (?), v2
Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150
Uptime: 1d04h, expires: 00:02:09
CE2#
¿Cómo? Si miramos la tabla BGP, no encontraremos ningún indicio de este punto allí:
PE1#show bgp ipv4 mvpn all
BGP table version is 682, local router ID is 1.1.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,
t secondary path,
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.1.1.1:1 (default for vrf C-ONE)
*> [1][1.1.1.1:1][1.1.1.1]/12
0.0.0.0 32768 ?
*>i [1][1.1.1.1:1][2.2.2.2]/12
2.2.2.2 0 100 0 ?
*>i [1][1.1.1.1:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
*>i [1][1.1.1.1:1][4.4.4.4]/12
4.4.4.4 0 100 0 ?
Route Distinguisher: 2.2.2.2:1
*>i [1][2.2.2.2:1][2.2.2.2]/12
2.2.2.2 0 100 0 ?
Route Distinguisher: 3.3.3.3:1
Network Next Hop Metric LocPrf Weight Path
*>i [1][3.3.3.3:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
Route Distinguisher: 4.4.4.4:1
*>i [1][4.4.4.4:1][4.4.4.4]/12
4.4.4.4 0 100 0 ?
No olvides que tenemos un PMSTI con PIM activado:
PE1#show ip pim vrf C-ONE interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
172.1.11.1 GigabitEthernet2.111 v2/S 1 30 1 172.1.11.11
172.1.15.1 GigabitEthernet2.115 v2/S 1 30 1 172.1.15.15
1.1.1.1 Tunnel2 v2/S 0 30 1 1.1.1.1
A partir de esto, se puede extraer una conclusión importante: algunos mensajes PIM (incluso con señalización BGP) se transmiten a través de la red troncal dentro del marco del MDT predeterminado .
Imagine que aparece una fuente en la red (detrás del enrutador CE2). Dado que actualmente no hay entradas mRIB en CE2, el enrutador designado PIM (en nuestro caso, es el propio CE2) envía un mensaje de registro al punto de encuentro, lo que indica la presencia de una fuente activa en la red.
Se crea un árbol en el punto de encuentro (12.12.12.12, 231.1.1.1):
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:00:19/stopped, RP 15.15.15.15, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(12.12.12.12, 231.1.1.1), 00:00:19/00:02:40, flags: P
Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1
Outgoing interface list: Null
Y, dado que no hay destinatarios de tráfico activos en la red (no hay árbol (*, 231.1.1.1)), se genera un mensaje Register-Stop desde el lado CE5
En respuesta a recibir un Register-Stop, CE2 suspende la transmisión de datos (sin interfaces en OIL):
CE2#show ip mroute 231.1.1.1
(12.12.12.12, 231.1.1.1), 00:00:07/00:02:54, flags: PFT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list: Null
Ahora, imagine que hay un destinatario en la red interesado en el tráfico del grupo 231.1.1.1. En PE4, aparece una ruta dentro del C-VRF:
PE4#show ip mroute vrf C-ONE 231.1.1.1 | b \(
(*, 231.1.1.1), 00:00:44/00:02:45, RP 15.15.15.15, flags: Sg
Incoming interface: Tunnel0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:00:44/00:02:45
Y se crea una ruta BGP del sexto tipo, que es el equivalente a PIM Join (*, 231.1.1.1):
PE4#show bgp ipv4 mvpn all
Route Distinguisher: 1.1.1.1:1
*> [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22
0.0.0.0 32768 ?
PE4#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 808
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
8
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (4.4.4.4)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:1.1.1.1:1
rx pathid: 1, tx pathid: 0x0
En el resultado anterior, debe tener en cuenta la comunidad extendida Route-target = 1.1.1.1:1. ¿Qué es y de dónde viene?
Comprobemos la presencia de este prefijo en otros PE:
PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
% Network not in table
PE3#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
% Network not in table
PE1#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 698
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Not advertised to any peer
Refresh Epoch 2
Local
4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1.1.1.1:1
Originator: 4.4.4.4, Cluster list: 8.8.8.8
rx pathid: 0, tx pathid: 0x0
Aquellos. el prefijo existe solo en PE1. Lo interesante es el hecho de que el punto de encuentro (15.15.15.15) se encuentra exactamente en el sitio detrás de PE1.
Conociendo el propósito de la ruta-objetivo (importación de rutas en un VRF específico), la conclusión sugiere por sí misma: RT = 1.1.1.1:1 es conocido para PE1 y desconocido para PE2 / PE3. Es decir, el hecho es obvio que PE4 generó una ruta BGP que describe el PIM Shared Tree Join de tal manera que se procesó solo en el PE detrás del cual se encuentra realmente el punto de encuentro (de hecho, este es un análogo de la transmisión PIM Join a través de la interfaz RPF). Pero, ¿cómo concilian PE1 y PE4 los valores de ruta-destino?
PE4 realiza RPF para la dirección del punto de encuentro:
PE4#show ip rpf vrf C-ONE 15.15.15.15
RPF information for ? (15.15.15.15)
RPF interface: Tunnel0
RPF neighbor: ? (1.1.1.1)
RPF route/mask: 15.15.15.15/32
RPF type: unicast (bgp 65001)
Doing distance-preferred lookups across tables
BGP originator: 1.1.1.1
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
PE1 se ve como vecino RPF. Esto significa que PE4 debe colocar un destino de ruta dentro de una ruta de tipo 6 que solo PE1 importará. Para responder a la pregunta "¿cómo lo sabe PE4?" - veamos, para empezar, la ruta vpn:
PE4#show bgp vpnv4 unicast vrf C-ONE 15.15.15.15/32
BGP routing table entry for 4.4.4.4:1:15.15.15.15/32, version 859
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 1
65015, imported path from 1.1.1.1:1:15.15.15.15/32 (global)
1.1.1.1 (metric 3) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
Originator: 1.1.1.1, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 1.1.1.1:1:1.1.1.1
mpls labels in/out nolabel/10013
rx pathid: 0, tx pathid: 0x0
Tenga en cuenta la comunidad MVPN VRF adicional: 1.1.1.1: 1. Esto no es más que la comunidad de importación de rutas generada por PE1. Es este valor el que se copia como destino de ruta dentro de la ruta de multidifusión, lo que permite a PE1 importar la actualización recibida desde PE4.
El resultado de procesar el tipo de ruta BGP 6 en PE4 es la creación de una entrada en la tabla de enrutamiento de multidifusión:
PE4#show ip mroute vrf C-ONE
(*, 231.1.1.1), 00:23:31/00:02:33, RP 15.15.15.15, flags: Sg
Incoming interface: Tunnel0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:23:31/00:02:33
Nota - Tenga en cuenta que Tunnel0 (PMSTI) se especifica como la interfaz de entrada.
En el punto de encuentro, se completa la creación de un árbol común:
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:25:42/00:03:22, RP 15.15.15.15, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2.115, Forward/Sparse, 00:25:42/00:03:22
Ahora, si una fuente de tráfico activa vuelve a aparecer en la red, el punto de encuentro sabrá cómo "combinar" (*, 231.1.1.1) y (12.12.12.12, 231.1.1.1) árboles.
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:47:12/stopped, RP 15.15.15.15, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2.115, Forward/Sparse, 00:47:12/00:02:31
(12.12.12.12, 231.1.1.1), 00:00:23/00:02:43, flags: PT
Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1
Outgoing interface list: Null
El punto de encuentro crea un PIM Join (12.12.12.12, 231.1.1.1), enviándolo hacia CE2. PE1 recibe la unión PIM especificada y crea una ruta BGP del séptimo tipo:
PE1#show bgp ipv4 mvpn all
Route Distinguisher: 2.2.2.2:1
*> [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22
0.0.0.0 32768 ?
PE1#show bgp ipv4 mvpn all route-type 7 2.2.2.2:1 65001 12.12.12.12 231.1.1.1
BGP routing table entry for [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22, version 726
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
8
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (1.1.1.1)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:2.2.2.2:1
rx pathid: 1, tx pathid: 0x0
Tenga en cuenta que el valor RD de VPN remota se establece en 2.2.2.2:1, ya que es a través de PE2 que se completa la verificación RPF de la ruta:
PE1#show ip rpf vrf C-ONE 12.12.12.12
RPF information for ? (12.12.12.12)
RPF interface: Tunnel2
RPF neighbor: ? (2.2.2.2)
RPF route/mask: 12.12.12.12/32
RPF type: unicast (bgp 65001)
Doing distance-preferred lookups across tables
BGP originator: 2.2.2.2
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
Y RT 2.2.2.2:1 se ha agregado a VPNv4 un prefijo del lado PE2:
PE1#show bgp vpnv4 unicast vrf C-ONE 12.12.12.12
BGP routing table entry for 1.1.1.1:1:12.12.12.12/32, version 706
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 2
65012, imported path from 2.2.2.2:1:12.12.12.12/32 (global)
2.2.2.2 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:2.2.2.2:1
Originator: 2.2.2.2, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 2.2.2.2:1:2.2.2.2
mpls labels in/out nolabel/31
rx pathid: 0, tx pathid: 0x0
Este paso, de hecho, completa la construcción del árbol (12.12.12.12, 231.1.1.1) en la sección entre la fuente y el punto de encuentro:
Después de recibir una ruta del séptimo tipo, PE2 genera una ruta del quinto tipo, señalando la presencia de una fuente de tráfico activa en la red. La ruta es importada por todos los dispositivos PE.
PE2#show bgp ipv4 mvpn all
Route Distinguisher: 2.2.2.2:1 (default for vrf C-ONE)
*> [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18
0.0.0.0 32768 ?
PE2#show bgp ipv4 mvpn all route-type 5 12.12.12.12 231.1.1.1
BGP routing table entry for [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18, version 838
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
Advertised to update-groups:
8
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (2.2.2.2)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Community: no-export
Extended Community: RT:65001:1
rx pathid: 0, tx pathid: 0x0
Cuando se recibe un tipo de ruta 5, la creación de un árbol de multidifusión se completa en PE4 (donde se encuentra el receptor):
PE4#show ip mroute vrf C-ONE
(12.12.12.12, 231.1.1.1), 00:22:24/00:02:51, flags: TnQ
Incoming interface: Tunnel0, RPF nbr 2.2.2.2
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:22:24/00:03:19
Nota : preste atención a la bandera Q, que indica que la entrada se creó gracias al mensaje BGP Source-Active
La variante considerada de la organización mVPN tiene el nombre en código "Perfil 11". Sus principales caracteristicas:
- para transmitir tráfico de multidifusión a la red superpuesta, se utiliza MDT predeterminado
- el protocolo mGRE se utiliza como método de organización del transporte
- El protocolo BGP se utiliza para señalar el árbol de multidifusión dentro de la red impuesta.