Configuración del plano de datos y túneles del proveedor de señalización

P-PIM y C-PIM en el enrutador de PE del remitente

El enrutador de PE del remitente instala una entrada de unión local en su base de datos P-PIM para cada tabla VRF configurada para utilizar PIM como túnel de proveedor. La lista de interfaces salientes (OIL) de esta entrada apunta a la interfaz frontal del núcleo. Dado que la entrada P-PIM se instala como Local, el enrutador de PE del remitente establece la dirección de origen en su dirección IP de circuito cerrado principal.

Utilice el show pim join extensive comando para comprobar que el enrutador PE1 instaló el siguiente estado en su base de datos P-PIM.

En el lado VRF del enrutador de PE del remitente, C-PIM instala una Local Source entrada en su base de datos C-PIM para el origen VPN local activo. El OIL de esta entrada apunta a Pseudo-MVPN, lo que indica que la interfaz descendente apunta a los receptores de la red MVPN de próxima generación. Los enrutadores a los que se hace referencia en este tema se muestran en Descripción de la topología de red MVPN de próxima generación.

Utilice el show pim join extensive instance vpna 224.1.1.1 comando para comprobar que el enrutador PE1 instaló la siguiente entrada en su base de datos C-PIM.

La entrada de reenvío correspondiente al C-PIM Local Source (o Local RP) en el enrutador de PE del remitente apunta a la subinterfaz de encapsulación de túnel de multidifusión como la interfaz descendente. Esto indica que los paquetes de datos de multidifusión local se encapsulan a medida que se pasan al protocolo P-PIM.

Utilice el show multicast route extensive instance vpna group 224.1.1.1 comando para comprobar que el enrutador PE1 tiene la siguiente entrada de reenvío de multidifusión para el grupo 224.1.1.1. La interfaz ascendente es la interfaz PE-CE y la interfaz descendente es la subinterfaz de encapsulación de túnel de multidifusión:

P-PIM y C-PIM en el enrutador de PE del receptor

En el enrutador de PE receptor, los paquetes de datos de multidifusión recibidos de la red se desencapsulan a medida que pasan a través de la interfaz de desencapsulación del túnel de multidifusión.

La base de datos P-PIM en el enrutador de PE receptor contiene dos uniones P. Una es para P-RP y la otra es para el enrutador de PE del remitente. Para ambas entradas, el OIL contiene la interfaz de desencapsulación de túnel de multidifusión de la que se elimina el encabezado GRE. La interfaz ascendente para las uniones P es la interfaz orientada hacia el núcleo que mira hacia el enrutador de PE del remitente.

Utilice el show pim join extensive comando para comprobar que el enrutador PE3 tiene el siguiente estado en su base de datos P-PIM. La interfaz del vecino descendente apunta a la subinterfaz de desencapsulación GRE:

En el lado VRF del enrutador de PE receptor, C-PIM instala una entrada de unión en su base de datos C-PIM. El OIL de esta entrada apunta a la interfaz VPN local, lo que indica los receptores locales activos. El protocolo ascendente, la interfaz y el vecino de este punto de entrada a la red MVPN de próxima generación. Los enrutadores a los que se hace referencia en este tema se muestran en Descripción de la topología de red MVPN de próxima generación.

Utilice el show pim join extensive instance vpna 224.1.1.1 comando para comprobar que el enrutador PE3 tiene el siguiente estado en su base de datos C-PIM:

La entrada de reenvío correspondiente a la entrada C-PIM en el enrutador de PE del receptor utiliza la subinterfaz de desencapsulación de túnel de multidifusión como interfaz ascendente.

Utilice el show multicast route extensive instance vpna group 224.1.1.1 comando para comprobar que el enrutador PE3 instaló la siguiente entrada de reenvío de multidifusión para el receptor local:

Túneles inclusivos: Configuración de LSP punto a multipunto del enrutador de PE de entrada

El LSP de punto a multipunto y los sub-LSP asociados son señalizados por el enrutador de PE de entrada. La información sobre el LSP de punto a multipunto se anuncia para los enrutadores de PE de salida en el atributo PMSI a través del BGP.

El enrutador de PE de entrada envía señales a sub-LSP de punto a multipunto mediante el origen de mensajes de ruta RSVP de punto a multipunto hacia enrutadores de PE de salida. El enrutador de PE de entrada aprende la identidad de los enrutadores de PE de salida de las rutas de tipo 1 instaladas en su <routing-instance-name>.mvpn.0 tabla. Cada mensaje de ruta de RSVP lleva un S2L_Sub_LSP objeto junto con el objeto de sesión punto a multipunto. El S2L_Sub_LSP objeto lleva una dirección IP de destino (salida) sub-LSP de 4 bytes.

En Junos OS, el sistema puede señalar automáticamente a los sub-LSP asociados con un LSP de punto a multipunto o a través de una configuración estática de sub-LSP. Cuando se señalan automáticamente, el sistema elige un nombre para el LSP punto a multipunto y cada sub-LSP asociado con él mediante la siguiente convención de nomenclatura.

Convención de nomenclatura de LSP punto a multipunto:

<rid de PE de entrada>:<a por número único de VRF>:mvpn:<routing-instance-name>

Convención de nomenclatura de sub-LSP:

<rid de PE de salida>:<rid de PE de entrada>:<a por número único de VRF>:mvpn:<nombre-de-instancia-de-enrutamiento>

Utilice el show mpls lsp p2mp comando para comprobar que el enrutador PE1 creó los siguientes LSP:

LSP P2MP principal: 10.1.1.1:65535:mvpn:vpna

Sub-LSP: 10.1.1.2:10.1.1.1:65535:mvpn:vpna (enrutador PE1 a enrutador PE2) y

10.1.1.3:10.1.1.1:65535:mvpn:vpna (enrutador PE1 a enrutador PE3)

Los valores de este ejemplo son los siguientes:

• Nombre del LSP P2MP de I-PMSI: 10.1.1.1:65535:mvpn:vpna

• Nombre del sub-LSP P2MP de I-PMSI (a PE2): 10.1.1.2:10.1.1.1:65535:mvpn:vpna

• Nombre del sub-LSP P2MP de I-PMSI (a PE3): 10.1.1.3:10.1.1.1:65535:mvpn:vpna

Túneles inclusivos: Configuración de LSP punto a multipunto del enrutador de PE de salida

Un enrutador de PE de salida responde a un mensaje de ruta de RSVP originando un mensaje de reserva de RSVP (RESV) según los procedimientos normales de RSVP. El mensaje RESV contiene la etiqueta MPLS asignada por el enrutador de PE de salida para este sub-LSP y se reenvía salto a salto hacia el enrutador de PE de entrada, configurando así el estado en la red. Los enrutadores a los que se hace referencia en este tema se muestran en Descripción de la topología de red MVPN de próxima generación.

Utilice el comando para comprobar que el show rsvp session enrutador PE2 tiene asignada una etiqueta 299840 para el subLSP 10.1.1.2:10.1.1.1:65535:mvpn:vpna:

Utilice el comando para comprobar que el show mpls lsp p2mp enrutador PE3 tiene asignada una etiqueta 16 para el sub-LSP 10.1.1.3:10.1.1.1:65535:mvpn:vpna:

Túneles inclusivos: Configuración del plano de datos del enrutador de PE de salida

El enrutador de PE de salida instala una entrada de reenvío en su mpls tabla para la etiqueta que asignó para el sub-LSP. La etiqueta MPLS se instala con una operación pop (una operación pop quita la etiqueta MPLS superior) y el paquete se pasa a la tabla VRF para una segunda búsqueda de ruta. La segunda búsqueda en el enrutador de PE de salida es necesaria para que los paquetes de datos de multidifusión VPN se procesen dentro de la tabla VRF mediante los procedimientos normales de C-PIM.

Utilice el show route table mpls label 16 comando para comprobar que el enrutador PE3 instaló la siguiente entrada de etiqueta en su tabla de reenvío MPLS:

En Junos OS, las entradas de enrutamiento de multidifusión VPN se almacenan en la <routing-instance-name>.inet.1 tabla, que es donde tiene lugar la segunda búsqueda de ruta. En el ejemplo anterior, aunque vpna.inet.0 aparece como la tabla de enrutamiento donde se produce la segunda búsqueda después de la operación pop, internamente la búsqueda apunta a la vpna.inet.1 tabla. Los enrutadores a los que se hace referencia en este tema se muestran en Descripción de la topología de red MVPN de próxima generación.

Utilice el show route table vpna.inet.1 comando para comprobar que el enrutador PE3 contiene la siguiente entrada en su tabla de enrutamiento de multidifusión VPN:

Utilice el show multicast route extensive instance vpna comando para comprobar que el enrutador PE3 contiene la siguiente entrada de reenvío de multidifusión VPN correspondiente a la entrada de enrutamiento de multidifusión para la unión local. La interfaz ascendente apunta y lsi.0 la interfaz descendente (OIL) apunta a la interfaz (hacia los so-0/2/0.0 receptores locales). El Upstream protocol valor se debe MVPN a que se puede acceder a la fuente de multidifusión VPN a través de la red MVPN de última generación. La lsi.0 interfaz es similar a la interfaz de túnel de multidifusión que se utiliza cuando se utilizan túneles de proveedor basados en PIM. La lsi.0 interfaz se utiliza para quitar el encabezado MPLS superior.

El requisito de una búsqueda de ruta doble en el encabezado del paquete VPN requiere dos instrucciones de configuración adicionales en los enrutadores de PE de salida cuando los túneles del proveedor están señalizados por RSVP-TE.

En primer lugar, dado que la etiqueta MPLS superior utilizada para el subLSP punto a multipunto está vinculada a la tabla VRF en los enrutadores de PE de salida, la operación de popping de penúltimo salto (PHP) no se utiliza para las MVPN de última generación. Solo se usa el estallido de salto definitivo. PHP permite que el penúltimo enrutador (enrutador antes del enrutador de PE de salida) elimine la etiqueta MPLS superior. PHP funciona bien para paquetes de datos de unidifusión VPN porque normalmente llevan dos etiquetas MPLS: una para la VPN y otra para el LSP de transporte.

Después de quitar la etiqueta LSP, los paquetes VPN de unidifusión siguen teniendo una etiqueta VPN que se puede utilizar para determinar la VPN a la que pertenecen los paquetes. Los paquetes de datos de multidifusión VPN, por otro lado, llevan solo una etiqueta MPLS que está directamente vinculada a la VPN. Por lo tanto, la etiqueta MPLS que llevan los paquetes de multidifusión VPN debe conservarse hasta que los paquetes lleguen al enrutador de PE de salida. Normalmente, PHP debe desactivarse mediante la configuración manual.

Para simplificar la configuración, PHP está deshabilitado de forma predeterminada en los enrutadores PE de Juniper Networks cuando se incluye la mvpn instrucción en el nivel jerárquico [edit routing-instances routing-interface-name interface] . PHP también está deshabilitado de forma predeterminada cuando incluye la vrf-table-label instrucción en el nivel de [edit routing-instances routing-instance-name] jerarquía.

En segundo lugar, en Junos OS, las etiquetas VPN asociadas con una tabla VRF se pueden asignar de dos maneras.

• Asigne una etiqueta única para cada próximo salto de VPN (interfaz PE-CE). Este es el comportamiento predeterminado.

• Asigne una etiqueta para toda la tabla VRF, lo que requiere una configuración adicional. Solo la asignación de una etiqueta para toda la tabla VRF permite una segunda búsqueda en el encabezado del paquete VPN. Por lo tanto, los enrutadores de PE que admiten servicios MVPN de última generación deben configurarse para asignar etiquetas para la tabla VRF. Hay dos maneras de hacer esto, como se muestra en la Figura 1.

  • Una es mediante la inclusión de una interfaz de túnel virtual denominada vt en el nivel de [edit routing-instances routing-instance-name interfaces] jerarquía, lo que requiere una PIC de túnel.

  • La segunda es incluyendo la vrf-table-label instrucción en el nivel de [routing-instances routing-instance-name] jerarquía, que no requiere una PIC de túnel.

Ambas opciones permiten que un enrutador de PE de salida realice dos búsquedas de ruta. Sin embargo, existen algunas diferencias en la forma en que se realiza la segunda búsqueda

Si se usa la vt interfaz, la etiqueta asignada se instala en la mpls tabla con una pop operación y un próximo salto de reenvío que apunta a la vt interfaz.

Utilice el show route table mpls label 299840 comando para comprobar que el enrutador PE2 instaló la siguiente entrada y utiliza una vt interfaz en la mpls tabla. La etiqueta asociada con el sub-LSP punto a multipunto (299840) se instala con una operación pop y una operación directa, siendo la vt-0/1/0.0 interfaz el siguiente salto. Los paquetes de multidifusión VPN recibidos del núcleo salen de la vt-0/1/0.0 interfaz sin su encabezado MPLS y el enrutador de salida PE2 realiza una segunda búsqueda en el encabezado del paquete de la vpna.inet.1 tabla.

Si está vrf-table-label configurado, la etiqueta asignada se instala en la mpls tabla con una operación pop y los puntos de entrada de reenvío a la <routing-instance-name>.inet.0 tabla (lo que desencadena internamente la segunda búsqueda que se realizará en la <routing-instance-name>.inet.1 tabla).

Utilice el show route table mpls label 16 comando para comprobar que el enrutador PE3 ha instalado la siguiente entrada en su mpls tabla y utiliza la vrf-table-label instrucción:

La configuración de la asignación de etiquetas para cada tabla VRF afecta tanto a las rutas VPN de unidifusión como a las rutas MVPN. Sin embargo, puede habilitar la asignación de etiquetas por VRF para rutas MVPN solo si la asignación por VRF está configurada a través vtde . Esta característica se configura mediante palabras clave de multidifusión y unidifusión en el [edit routing-instances routing-instance-name interface vt-x/y/z.0] nivel jerárquico.

Tenga en cuenta que la inclusión de la instrucción habilita la vrf-table-label asignación de etiquetas por VRF para rutas de unidifusión y MVPN y no se puede desactivar para ninguno de los tipos de rutas (está activada o desactivada para ambos).

Si un enrutador de PE es un enrutador de brotes, lo que significa que tiene receptores locales y también reenvía paquetes MPLS recibidos a través de un LSP de punto a multipunto descendente a otros enrutadores P y PE, entonces hay una diferencia en cómo funcionan las vrf-table-label instrucciones y vt . Cuando se incluye la vrf-table-label instrucción, el enrutador bud PE recibe dos copias del paquete del penúltimo enrutador: una que se reenviará a los receptores locales y la otra que se reenviará a los enrutadores P y PE descendentes. Cuando se incluye la vt instrucción, el enrutador de PE recibe una única copia del paquete.

Túneles inclusivos: Configuración del plano de datos del enrutador de PE de entrada y sucursal

En el enrutador de PE de entrada, los paquetes de datos VPN locales se encapsulan con la etiqueta MPLS recibida de la red para los sub-LSP.

Utilice el show rsvp session comando para comprobar que en el enrutador de entrada PE1, los paquetes de datos de multidifusión VPN se encapsulan con la etiqueta 300016 MPLS (anunciada por el enrutador P1 según los procedimientos normales de RSVP RESV) y se reenvían hacia el enrutador P1 por los sub-LSP 10.1.1.3:10.1.1.1:65535:mvpn:vpna y 10.1.1.2:10.1.1.1:65535:mvpn:vpna.

El RFC 4875 describe un nodo de sucursal como "un LSR que replica los datos entrantes en una o más interfaces de salida". En un enrutador r de sucursal, los datos entrantes que llevan una etiqueta MPLS se replican en una o más interfaces de salida que pueden usar etiquetas MPLS diferentes. Los nodos de sucursal realizan un seguimiento de las etiquetas entrantes y salientes asociadas con los LSP de punto a multipunto. Los enrutadores a los que se hace referencia en este tema se muestran en Descripción de la topología de red MVPN de próxima generación.

Utilice el comando para comprobar que el show rsvp session nodo de sucursal P1 tiene la etiqueta 300016 de entrada y las etiquetas 16 de salida para el sub-LSP 10.1.1.3:10.1.1.1:65535:mvpn:vpna (al enrutador PE3) y 299840 para el sub-LSP 10.1.1.2:10.1.1.1:65535:mvpn:vpna (al enrutador PE2).

Utilice el show route table mpls label 300016 comando para comprobar que la entrada de reenvío correspondiente en el enrutador P1 muestra que los paquetes que vienen con una etiqueta MPLS (300016) se intercambian con etiquetas 16 y 299840 se reenvían a través de sus respectivas interfaces (so-0/0/3.0 y so-0/0/1.0 respectivamente hacia el enrutador PE2 y el enrutador PE3).

Túneles selectivos: Rutas de autodescubrimiento S-PMSI tipo 3 y autodescubrimiento de hoja tipo 4

Los túneles de proveedor selectivo se configuran incluyendo la selective instrucción en el nivel de [edit routing-instances routing-instance-name provider-tunnel] jerarquía. Puede configurar un umbral para activar la señalización de un túnel de proveedor selectivo. La inclusión de la selective instrucción desencadena los siguientes eventos.

Primero, el enrutador de PE de entrada origina una ruta de autodescubrimiento S-PMSI tipo 3. La ruta de autodescubrimiento S-PMSI contiene el distinguidor de ruta de la VPN en la que está configurado el túnel y el par (C-S, C-G) que utiliza el túnel de proveedor selectivo.

En esta sección, suponga que el enrutador PE1 está señalando un túnel selectivo para (192.168.1.2, 224.1.1.1) y que el enrutador PE3 tiene un receptor activo.

Utilice el show route table vpna.mvpn.0 | find 3: comando para comprobar que el enrutador PE1 instaló la siguiente ruta de tipo 3 después de configurar el túnel de proveedor selectivo:

En segundo lugar, el enrutador de PE de entrada asocia un atributo PMSI a una ruta de tipo 3. Este atributo PMSI es similar al atributo PMSI anunciado para túneles de proveedores inclusivos con una diferencia: el atributo PMSI que se lleva con rutas de tipo 3 tiene su Flags bit establecido en Leaf Information Required. Esto significa que el enrutador de PE del remitente solicita a los enrutadores de PE del receptor que envíen una ruta de tipo 4 si tienen receptores activos para el (C-S, C-G) transportado en la ruta de tipo 3. Además, recuerde que para cada túnel de proveedor selectivo, se señala un nuevo punto a multipunto y sub-LSP asociados. El atributo PMSI de una ruta de tipo 3 contiene información sobre el nuevo LSP de punto a multipunto.

Utilice el show route advertising-protocol bgp 10.1.1.3 detail table vpna.mvpn | find 3: comando para comprobar que el enrutador PE1 anuncia la siguiente ruta de tipo 3 y el PMSI atributo. El objeto de sesión punto a multipunto incluido en el PMSI atributo tiene un número de puerto (29499) distinto del que se utiliza para el túnel inclusivo (6574), lo que indica que se trata de un nuevo túnel punto a multipunto.

Los enrutadores de PE de salida con receptores activos deben responder a una ruta de tipo 3 originando una ruta de autodescubrimiento de hoja de tipo 4. Una ruta de autodescubrimiento de hoja contiene una clave de ruta y los campos de dirección IP del enrutador de origen. El Route Key campo de la ruta de autodescubrimiento leaf contiene la ruta original de tipo 3 que se recibe. El campo dirección IP del enrutador de origen se establece en el ID de enrutador del enrutador de PE que origina la ruta de autodescubrimiento de hoja.

El enrutador de PE de entrada agrega cada enrutador de PE de salida que originó la ruta de autodescubrimiento de hoja como una hoja (destino del sub-LSP para el LSP selectivo de punto a multipunto). De manera similar, el enrutador de PE de salida que originó la ruta de autodescubrimiento de hoja configura un estado de reenvío para comenzar a recibir datos a través del túnel del proveedor selectivo.

Los enrutadores de PE de salida anuncian rutas de tipo 4 con un destino de ruta específico para el enrutador de PE que señala el túnel de proveedor selectivo. Este destino de ruta tiene la forma de target:<rid del remitente PE>:0. El enrutador de PE del remitente (el enrutador de PE que señala el túnel de proveedor selectivo) aplica una política de importación interna especial a las rutas de tipo 4 que busca un destino de ruta con su propio ID de enrutador. Los enrutadores a los que se hace referencia en este tema se muestran en Descripción de la topología de red MVPN de próxima generación.

Utilice el show route table vpna.mvpn | find 4:3: comando para comprobar que el enrutador PE3 origina la siguiente ruta de tipo 4. El módulo MVPN instala la ruta local de tipo 4.

Utilice el show route advertising-protocol bgp 10.1.1.1 table vpna.mvpn detail | find 4:3: comando para comprobar que el enrutador PE3 ha anunciado la ruta local tipo 4 con la siguiente comunidad de destino de ruta. Este destino de ruta lleva la dirección IP del enrutador de PE emisor (10.1.1.1) seguida de un 0.

Utilice el show policy __vrf-mvpn-import-cmcast-leafAD-global-internal__ comando para comprobar que el enrutador PE1 (el enrutador de PE que señala el túnel de proveedor selectivo) aplicó la siguiente política de importación a rutas de tipo 4. Las rutas se aceptan si su destino de ruta coincide con target:10.1.1.1:0.

Por cada túnel de proveedor selectivo configurado, se anuncia una ruta de tipo 3 y se señala un nuevo LSP de punto a multipunto. Los LSP punto a multipunto creados por Junos OS para túneles de proveedor selectivo se les asigna nombres mediante las siguientes convenciones de nomenclatura:

• Convención de nomenclatura de LSP de punto a multipunto selectivos:

  <rid de PE de entrada>:<a por número único VRF>:mv<un número único>:<nombre-de-instancia-de-enrutamiento>

• Convención de nomenclatura selectiva de sub-LSP de punto a multipunto:

  <rid de PE de salida>:<rid de PE de entrada>:<a por VRF único>:mv<un número único>:<nombre-de-instancia-de-enrutamiento>

Utilice el comando para comprobar que el show mpls lsp p2mp enrutador PE1 señala un LSP 10.1.1.1:65535:mv5:vpna de punto a multipunto con un subLSP 10.1.1.3:10.1.1.1:65535:mv5:vpna. El primer LSP 10.1.1.1:65535:mvpn:vpna de punto a multipunto es el LSP creado para el túnel inclusivo.

Los valores de este ejemplo son los siguientes.

• Nombre del LSP P2MP de I-PMSI: 10.1.1.1:65535:mvpn:vpna

• Nombre del sub-LSP P2MP de I-PMSI (a PE2): 10.1.1.2:10.1.1.1:65535:mvpn:vpna

• Nombre del sub-LSP P2MP de I-PMSI (a PE3): 10.1.1.3:10.1.1.1:65535:mvpn:vpna

• Nombre del LSP P2MP de S-PMSI: 10.1.1.1:65535:mv5:vpna

• Nombre del sub-LSP P2MP de S-PMSI (a PE3): 10.1.1.3:10.1.1.1:65535:mv5:vpna