Perfil 0
Perfil 1
Perfil 3
Perfil 11
Como aprendimos de entradas anteriores, en la red troncal al implementar mVPN, siempre hay una construcción MDT predeterminada, a la que están conectados todos los enrutadores PE. Este MDT transporta mensajes generales de PIM (por ejemplo, Bootstrap, Auto-RP) así como tráfico de multidifusión personalizado. Como resultado, resulta que algunos dispositivos PE reciben incluso el tráfico al que no se suscribieron.
Si quieres saber cómo lidiar con eso, ¡bienvenido bajo el corte!
Para aumentar la eficiencia de la transmisión de datos, se utiliza una construcción adicional, que se denomina "Data MDT". La idea detrás de esto es la siguiente:
- Dentro del árbol, solo se distribuye el tráfico C- (S, G)
- Solo aquellos PE de salida que tienen destinatarios interesados se convierten en miembros del árbol
- El dispositivo root Data MDT es el Ingress PE (el enrutador detrás del cual se encuentra la fuente)
Visualmente, se ve así:
Si imaginamos una situación en la que la fuente comienza a transmitir al segundo grupo de multidifusión (230.1.1.2), para el cual los receptores están ubicados solo detrás de PE2 y PE3, entonces se crea un MDT de datos adicional y la imagen general toma la forma (se omite el MDT predeterminado):
La señalización para cambiar el tráfico de Default MDT a Data MDT se lleva a cabo exclusivamente bajo demanda cuando el Ingress PE supera un umbral predeterminado, ya sea mediante PIM o mediante BGP.
MDT de datos usando PIM
Si se utiliza PIM para la señalización, el PE de entrada genera un mensaje TLV de MDT de datos de PIM especial y lo envía como parte del MDT predeterminado para garantizar que todos los PE puedan recibir el mensaje. Simultáneamente con el envío del TLV Data MDT, Ingress PE inicia un temporizador igual a tres segundos. Una vez que expire el temporizador, todos los paquetes se transmitirán dentro de Data MDT.
También debe tenerse en cuenta que la información contenida en el TLV Data-MDT se almacena en caché en todos los PE. La razón de esto es bastante trivial: incluso si no hay receptores de tráfico interesados en un PE en particular en este momento, pueden aparecer allí después de un tiempo. En consecuencia, al recibir una PIM Join (dentro del C-VRF), el PE puede conectarse instantáneamente al Data MDT que ya existe en la red.
Aprox. Los TLV de Data-MDT se transmiten una vez por minuto.
Cada Data MDT está configurado para una ruta (S, G) separada dentro de la VPN / VRF. El administrador debe especificar explícitamente el número máximo de MDT de datos que se pueden generar en el dispositivo. Si en algún momento el número de árboles recién instalados alcanza el límite especificado, los siguientes árboles reutilizarán los ya instalados.
Aprox. En el momento de escribir este artículo, Cisco IOS no admite la señalización PIM sobre Data MDT. Todos los perfiles con esta alarma están disponibles solo en el sistema operativo IOS XR.
MDT de datos con BGP
Cuando se utiliza BGP en una red superpuesta para la señalización Data MDT, los principios básicos siguen siendo los mismos (en comparación con PIM):
- Ingresar señales de PE a todos los PE que el tráfico para C- (S, G) se transmitirá dentro de Data MDT
- egress PE, al recibir una actualización de BGP, se une al árbol especificado
- la familia de direccionamiento mVPN (sAFI 129) se utiliza para la señalización.
Resulta que el Ingress PE debe formar un mensaje de actualización de BGP especial y enviarlo a todos los PE dentro del mVPN. Para ello, se utiliza una ruta del tercer tipo.
Perfil 14
Consideremos la transición descrita usando el ejemplo de nuestro laboratorio. En particular, es aplicable la configuración conocida como "Perfil 14". Este perfil se caracteriza por el uso de BGP mVPN AD para construir P2MP MLDP LSP.
En PE usaremos la siguiente plantilla de configuración:
ip vrf C-ONE mdt auto-discovery mldp mdt partitioned mldp p2mp mdt overlay use-bgp mdt strict-rpf interface ! router bgp 1 address-family ipv4 mvpn neighbor 8.8.8.8 activate neighbor 8.8.8.8 send-community extended exit-address-family
Aprox.
mdt strict-rpf
hablaremos sobre el propósito del comando de interfaz en el próximo número.
Descubrimiento automático
Veamos qué sucede en PE1:
En cada PE, se crea una interfaz Lspvif0, en la que se activa C-PIM.
*Dec 3 10:04:54.450: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up
No hay vecinos por el momento:
PE1#show ip pim vrf C-ONE int 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 Lspvif0 v2/S 0 30 1 1.1.1.1
Veamos la tabla BGP:
PE1#show bgp ipv4 mvpn all BGP table version is 39, 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 ? Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE) *> [3][1.1.1.1:1][*][*][1.1.1.1]/14 0.0.0.0 32768 ? *>i [3][1.1.1.1:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? *>i [3][1.1.1.1:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? *>i [3][1.1.1.1:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ? *> [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18 0.0.0.0 32768 ? Route Distinguisher: 2.2.2.2:1 *>i [3][2.2.2.2:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? Route Distinguisher: 3.3.3.3:1 *>i [3][3.3.3.3:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 4.4.4.4:1 *>i [3][4.4.4.4:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ?
Como puede ver, además de las rutas del primer tipo ya consideradas anteriormente, se agregan las rutas del tercer tipo S-PMSI AD, que se utilizan para anunciar PE como un enrutador Ingress para un grupo C- (S, G) específico. Por el momento, el grupo es (*, *). Esto indica el deseo de PE de participar en la construcción de MDT particionado.
Obviamente, para que la transferencia de datos funcione, la información del punto de encuentro debe conocerse dentro del VRF. En nuestro caso, CE15 actúa como RP y BSR.
C-RP#sh run | i pim ip pim bsr-candidate Loopback0 0 ip pim rp-candidate Loopback0
Dado que el C-RP ha construido un vecindario PIM con PE1, la información sobre RP también se conoce en este PE1:
PE1#show ip pim vrf C-ONE rp mapping Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:25:50, expires: 00:01:26
Es necesario entregar esta información a todos los demás PE / CE. ¿Cómo hacerlo? Para comprender mejor el principio, propongo ir desde lo contrario y comenzar a ver la información ya conocida sobre CE2:
CE2#show ip pim rp mapping Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:27:54, expires: 00:02:26
Como puede ver, los mensajes PIM BSR se han extendido por la infraestructura mVPN. Veamos el volcado de tráfico en PE1:
Como puede ver, PE1 encapsula el mensaje PIM BSR dentro de MPLS y lo etiqueta con 28. ¿De dónde viene? Podemos suponer que dado que este paquete ha alcanzado CE2 (y por lo tanto PE2), es decir, algún LSP antes de PE2.
PE2#show mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 1 Type: P2MP Uptime : 04:17:40 FEC Root : 2.2.2.2 (we are the root) Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : None Expires : N/A Path Set ID : 1 Replication client(s): > MDT (VRF C-ONE) Uptime : 04:17:40 Path Set ID : None Interface : Lspvif0 RPF-ID : * LSM ID : 3 Type: P2MP Uptime : 01:30:06 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 3 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 34 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 01:30:06 Path Set ID : None Interface : Lspvif0 RPF-ID : *
Del análisis de la base de datos mLDP se puede observar que en PE2 existe un determinado árbol (LSM ID: 3), cuya raíz es PE1 (IP = 1.1.1.1), Opaco = 01 0004 0001FFFF y para este árbol se generó una etiqueta local 34, la cual fue enviada al vecino R6 ( P2).
¿Cómo supo PE2 sobre el árbol, cuya raíz es PE1, e incluso obtuvo un Opaco para él? La respuesta es simple: usar la ruta BGP tipo 3.
Cuando PE1 recibió el PIM BSR, generó una ruta BGP adicional que describe el grupo (*, 224.0.0.13) (recuerde que esta es una dirección reservada para enviar todos los mensajes del servicio PIM). Esta ruta sirve para anunciar un nuevo árbol de multidifusión mLDP. Dentro de la PTA está el valor de Opaco que se utilizará para la señalización mediante mLDP.
PE1#show bgp ipv4 mvpn all route-type 3 * 224.0.0.13 1.1.1.1 BGP routing table entry for [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18, version 116 Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer) Advertised to update-groups: 1 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 Community: no-export Extended Community: RT:65001:1 PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 17, label: exp-null, tunnel parameters: 0600 0104 0101 0101 0007 0100 0400 01FF FF rx pathid: 0, tx pathid: 0x0
Por lo tanto, al importar esta ruta, PE2 puede iniciar la señalización mLDP hacia PE1 para el árbol (*, 224.0.0.13). Para la etiqueta recibida de PE2, P2 (R6) genera su propia etiqueta local (29) y la envía hacia P1 (R5):
P2#show mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 2 Type: P2MP Uptime : 01:40:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 5.5.5.5:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.56* Local Label (D): 29 Next Hop : 10.5.6.5 Replication client(s): 2.2.2.2:0 Uptime : 01:40:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.26* Local label (U): None Next Hop : 10.2.6.2
P1 (R5) hace lo mismo, generando su etiqueta local para el árbol y enviándola a PE1:
P1#show mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 2 Type: P2MP Uptime : 01:41:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 1.1.1.1:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.15* Local Label (D): 28 Next Hop : 10.1.5.1 Replication client(s): 4.4.4.4:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.45* Local label (U): None Next Hop : 10.4.5.4 7.7.7.7:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 30 Interface : GigabitEthernet2.57* Local label (U): None Next Hop : 10.5.7.7 6.6.6.6:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 29 Interface : GigabitEthernet2.56* Local label (U): None Next Hop : 10.5.6.6
Visualmente, todo el proceso se muestra en la siguiente figura:
Unirse a un árbol compartido y construir un árbol P2MP raíz (ROOT = RP-PE)
Paso 2. Aparece un receptor de tráfico en la red. Después de que Egress PE (PE2) recibe una PIM Join de CE para C - (*, G), PE2 realiza una verificación RPF para encontrar BGP Next-Hop hacia C-RP. El siguiente salto encontrado (1.1.1.1) se utilizará como RAÍZ MDT particionada para mLDP.
Además, PE2 crea una interfaz Lspvif dentro del C-VRF:
PE2# *Dec 3 14:46:21.606: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to up PE2# *Dec 3 14:46:22.310: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1
Paso 3. Egress PE (PE2) genera un mensaje de mapeo mLDP hacia RP-PE (ROOT P2MP MDT) usando el valor opaco de la actualización de BGP.
PE2#show mpls mldp database summary LSM ID Type Root Decoded Opaque Value Client Cnt. 4 P2MP 1.1.1.1 [gid 65536 (0x00010000)] 1 1 P2MP 2.2.2.2 [gid 65536 (0x00010000)] 1 3 P2MP 1.1.1.1 [gid 131071 (0x0001FFFF)] 1 PE2# PE2#show mvpn ipv4 vrf C-ONE auto-discovery s-pmsi * * detail I-PMSI - Intra-AS Inclusive-PMSI, S-PMSI - Selective-PMSI * - Indicates Wildcard source or group address [S-PMSI][1.1.1.1:1][*][*][1.1.1.1], Joined Orig: Remote Uptime: 04:44:27 Type: MLDP P2MP Root: 1.1.1.1 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][3.3.3.3:1][*][*][3.3.3.3], Orig: Remote Uptime: 04:44:22 Type: MLDP P2MP Root: 3.3.3.3 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][4.4.4.4:1][*][*][4.4.4.4], Orig: Remote Uptime: 04:44:20 Type: MLDP P2MP Root: 4.4.4.4 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][2.2.2.2:1][*][*][2.2.2.2], Joined Orig: Local Uptime: 04:44:24 Type: MLDP P2MP Root: 2.2.2.2 Fec-Opq: 1 Global-Id: 65536 (0x10000) PE2#show mpls mldp database opaque_type gid 65536 LSM ID : 4 Type: P2MP Uptime : 00:03:43 FEC Root : 1.1.1.1 Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 4 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 35 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 00:03:43 Path Set ID : None Interface : Lspvif1 RPF-ID : 0x1
Paso 4. Egress PE genera una sexta ruta BGP (que se une al árbol compartido hacia RP-PE). Esta ruta solo se importa a RP-PE.
PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 230.1.1.1 BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][230.1.1.1/32]/22, version 130 Paths: (1 available, best #1, table MVPNv4-BGP-Table) Advertised to update-groups: 1 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 Extended Community: RT:1.1.1.1:1 rx pathid: 1, tx pathid: 0x0
Paso 5. RP-PE traduce la ruta BGP recibida del sexto tipo en la unión PIM hacia RP. En este punto, el RP está listo para enviar tráfico de multidifusión hacia el PE de salida. Necesita enviar tráfico desde el origen al RP.
PE1#show ip mroute vrf C-ONE | b \( (*, 230.1.1.1), 00:07:08/stopped, RP 15.15.15.15, flags: SG Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.15 Outgoing interface list: Lspvif0, Forward/Sparse, 00:07:08/stopped
Paso 6. Cuando S-PE (PE4) recibe el primer paquete de multidifusión de la fuente (CE4), el tráfico se encapsula dentro del mensaje de registro PIM y se envía como un paquete de unidifusión hacia el C-RP (utilizando las reglas VPN MPLS L3 normales).
Paso 7. Después de recibir el Registro PIM, el C-RP comienza el proceso de construcción del árbol C (14.14.14.14, 230.1.1.1). RP-PE recibe PIM Join para C- (14.14.14.14, 230.1.1.1) de C-RP. Este mensaje se traduce al tipo de ruta BGP 7. Sin embargo, antes de enviar al lado de origen, debe crear un nuevo árbol MDT particionado con PE como RAÍZ.
Paso 8. RP-PE realiza comprobaciones RPF para encontrar BGP Next-Hop hacia la fuente. Esta dirección se utilizará como RAÍZ MDT particionada para mLDP.
Paso 9. Usando la ruta BGP Next-Hop y BGP recibida del tercer tipo de Ingress PE, RP-PR genera un mensaje de mapeo mLDP hacia la dirección IP de Ingress PE, construyendo así el árbol P2MP raíz para Ingress PE.
Paso 10. RP-PE envía el tipo de ruta BGP 7 (Join from RP) hacia Ingress PE.
Paso 11. Ingress PE convierte la ruta BGP recibida del séptimo tipo en PIM Join y la envía hacia la fuente de tráfico.
Adjuntar al árbol de origen y construir P2MP (ROOT = S-PE)
Paso 12. El Ingress PE también envía una ruta BGP de Tipo 5 a todos los mVPN PE, informándoles así que hay una fuente activa en la red. Esta ruta es un disparador para cambiar al árbol SPT.
Paso 13. Egress PE utiliza la ruta BGP tipo 5 recibida para generar un mensaje de mapeo mLDP hacia Ingress PE (la información MDT se toma de la ruta BGP tipo 3).
Por lo tanto, el tráfico ahora se puede redirigir de manera óptima desde el origen al destino utilizando etiquetas mpls (mLDP).
