Descripción de RPF basado en remitente en una MVPN BGP con túneles de proveedor punto a multipunto RSVP-TE

Visión general

En general, es importante evitar (o recuperarse de) que varios enrutadores PE envíen tráfico duplicado al núcleo, ya que esto puede provocar el envío de tráfico duplicado al cliente. El RPF basado en remitente tiene un caso de uso limitado a las MVPN BGP. El alcance del caso de uso está limitado por las siguientes razones:

• Una comprobación RPF tradicional para PIM nativo se basa en la interfaz entrante. Esta comprobación RPF evita bucles, pero no impide múltiples reenviadores en una LAN. El RPF tradicional se ha utilizado porque los protocolos de multidifusión actuales evitan los duplicados en una LAN o tienen eventos controlados por datos para resolver los duplicados una vez que se detectan.

• En el modo disperso PIM, pueden producirse duplicados en una LAN en funcionamiento normal del protocolo. El protocolo tiene un mecanismo basado en datos (mensajes de aserción PIM) para detectar la duplicación cuando ocurre y resolverla.

• En el modo bidireccional PIM, se realiza una elección de reenviador designado (DF) en todas las LAN para evitar duplicaciones.

• Las MVPN de Draft Rosen usan el mecanismo de afirmación PIM porque con las MVPN de Draft Rosen la red central es análoga a una LAN.

El RPF basado en remitente es una solución que se debe usar junto con las MVPN de BGP, ya que las MVPN de BGP utilizan una alternativa a las soluciones de eventos controlados por datos y a la elección de DF en modo bidireccional. Esto es así, porque, por un lado, la red central no es exactamente una LAN. En un escenario MVPN, es posible determinar qué enrutador PE ha enviado el tráfico. Junos OS utiliza esta información solo para reenviar el tráfico si se envía desde el enrutador PE correcto. Con RPF basado en remitente, la comprobación del RPF se mejora para comprobar si los datos llegaron a la interfaz de túnel virtual entrante (vt-) correcta y si los datos se enviaron desde el enrutador de PE ascendente correcto.

Más específicamente, los datos deben llegar con la etiqueta MPLS correcta en el encabezado externo utilizado para encapsular los datos a través del núcleo. La etiqueta identifica el túnel y, si el túnel es de punto a multipunto, el enrutador de PE ascendente.

El RPF basado en remitente no sustituye a la elección de un solo reenviador, sino que es una característica complementaria. Configurar una dirección de circuito cerrado principal (o ID de enrutador) más alta en un dispositivo PE (PE1) que en otro (PE2) garantiza que PE1 sea el ganador de la elección de reenvío único. La unicast-umh-election instrucción hace que la preferencia de ruta de unidifusión determine la elección del reenviador único. Si no se utiliza la elección de reenvío único o si no es suficiente para evitar duplicados en el núcleo, se recomienda RPF basada en remitente.

Para los túneles de proveedor punto a multipunto RSVP, la etiqueta de transporte identifica al enrutador de PE de envío, ya que es un requisito que el estallido de penúltimo salto (PHP) esté deshabilitado cuando se utilizan túneles de proveedor de punto a multipunto con MVPNs. PHP está deshabilitado de forma predeterminada cuando se configura el protocolo MVPN en una instancia de enrutamiento. La etiqueta identifica el túnel y (porque el túnel RSVP-TE es punto a multipunto) el enrutador de PE de envío.

El mecanismo RPF basado en remitente se describe en RFC 6513, Multidifusión en VPN IP MPLS/BGP en la sección 9.1.1.

Nota:

La técnica de espera de raíz en caliente descrita en el borrador de Internet draft-morin-l3vpn-mvpn-fast-failover-05 La conmutación por error ascendente rápida de VPN de multidifusión es una funcionalidad de enrutador de PE de salida en la que el enrutador de PE de salida envía un mensaje de unión de multidifusión c de árbol de origen a un enrutador de PE ascendente principal y uno de respaldo. Esto permite que varias copias del tráfico fluyan a través del núcleo del proveedor hacia el enrutador de PE de salida. El RPF basado en remitente y el modo de espera de raíz activa se pueden usar juntos para admitir el tráfico MVPN BGP en vivo . Este es un esquema de multidifusión a través de MPLS para transportar tráfico profesional de transmisión de TV e IPTV de misión crítica. Un requisito clave para muchas de estas implementaciones es tener redundancia completa de los equipos de red, incluidos los enrutadores de PE de entrada y salida. En algunos casos, se requiere un enfoque en vivo, lo que significa que se envían dos flujos de tráfico duplicados a través de la red siguiendo diversas rutas. Cuando esta técnica se combina con el reenvío basado en remitentes, los dos flujos de tráfico en vivo se reciben en el enrutador de PE de salida, y el enrutador de PE de salida reenvía una sola secuencia a la red del cliente. Cualquier falla en la red se puede reparar localmente en el enrutador de PE de salida. Para obtener más información acerca del modo de espera de raíz activa, consulte Espera de raíz activa.

El RPF basado en remitente evita que se envíen duplicados al cliente, incluso si hay duplicación en la red del proveedor. Podría existir duplicación en el proveedor debido a una configuración de espera de raíz activa o si la elección de un solo reenviador no es suficiente para evitar duplicados. La elección de reenviador único se usa para evitar duplicados en la red principal, mientras que el RPF basado en remitente evita duplicados para el cliente, incluso si hay duplicados en el núcleo. Hay casos en los que la elección de reenviador único no puede evitar que el tráfico duplicado llegue al enrutador de PE de salida. Un ejemplo de esto (descrito en la sección 9.3.1 de RFC 6513) es cuando el modo disperso PIM está configurado en la red del cliente y la MVPN está en modo RPT-SPT con un I-PMSI.

Determinación del enrutador de PE ascendente

Después de que Junos OS elija el enrutador de PE de entrada, la decisión de RPF basada en remitente determina si se ha seleccionado el enrutador de PE de entrada correcto. Como se describe en RFC 6513, sección 9.1.1, un enrutador de PE de salida, PE1, elige un enrutador de PE ascendente específico, para dado (C-S, C-G). Cuando PE1 recibe un paquete (C-S,C-G) de una PMSI, es posible que pueda identificar el enrutador PE que transmitió el paquete a la PMSI. Si ese transmisor no es el enrutador de PE seleccionado por PE1 como enrutador de PE ascendente, PE1 puede descartar el paquete. Esto significa que el enrutador PE detecta un duplicado, pero el duplicado no se reenvía.

Cuando un enrutador PE de salida genera una ruta de multidifusión C tipo 7, utiliza la comunidad extendida de importación de rutas VRF que se lleva en la ruta VPN-IP hacia el origen para construir el destino de ruta que lleva la ruta C-multidifusión. Este destino de ruta da como resultado que la ruta de C-multidifusión se envíe al enrutador de PE ascendente y se importe al VRF correcto en el enrutador de PE ascendente. El enrutador de PE de salida programa la entrada de reenvío para que solo acepte tráfico de este enrutador de PE y solo en un túnel particular enraizado en ese enrutador de PE.

Cuando un enrutador PE de salida genera una ruta de multidifusión C tipo 6, utiliza la comunidad extendida de importación de rutas VRF transportada en la ruta VPN-IP hacia el punto de encuentro (RP) para construir el destino de ruta transportado por la ruta de multidifusión C.

Este destino de ruta da como resultado que la ruta de multidifusión C se envíe al enrutador de PE ascendente y se importe al VRF correcto en el enrutador de PE ascendente. El enrutador de PE de salida programa la entrada de reenvío para aceptar tráfico solo de este enrutador de PE y solo en un túnel particular enraizado en ese enrutador de PE. Sin embargo, si otros enrutadores de PE han cambiado al modo SPT para (C-S, C-G) y han enviado rutas de autodescubrimiento (A-D) activas de origen (SA) (rutas de tipo 5), y si el enrutador de PE de salida solo tiene el estado (C-*, C-G), el enrutador de PE ascendente para (C-S, C-G) no es el enrutador de PE hacia el RP al que envió una ruta de tipo 6, sino el enrutador PE para el que se origina una ruta SA A-D (C-S, C-G). El tráfico para (C-S, C-G) puede ser transportado a través de un I-PMSI o S-PMSI, dependiendo de cómo fue anunciado por el enrutador de PE ascendente.

Además, cuando un enrutador de PE de salida solo tiene el estado (C-*, C-G) y no tiene el estado (C-S, C-G), el enrutador de PE de salida podría estar recibiendo rutas SA de tipo 5 (C-S, C-G) de varios enrutadores PE y elige la mejor, como se indica a continuación: Para cada ruta SA recibida (C-S, C-G), el enrutador de PE de salida encuentra en su conjunto de candidatos a ruta de salto de multidifusión ascendente (UMH) para C-S una ruta con el mismo diferenciador de ruta (RD). Entre todas estas rutas encontradas, el enrutador PE selecciona la ruta UMH (según la selección UMH). La mejor ruta (C-S, C-G) SA es aquella cuyo RD es el mismo que el de la ruta UMH seleccionada.

Cuando un enrutador de PE de salida solo tiene el estado (C-*, C-G) y no tiene el estado (C-S, C-G), y si posteriormente el enrutador de PE de salida crea el estado (C-S, C-G) (por ejemplo, como resultado de recibir un mensaje de unión PIM (C-S, C-G) de uno de sus vecinos de borde del cliente [CE]), el enrutador de PE ascendente para eso (C-S, C-G) no necesariamente será el mismo enrutador PE que originó la mejor ruta SA A-D ya seleccionada (C-S, C-G). Es posible tener una situación en la que el enrutador PE que originó la mejor ruta SA A-D (C-S, C-G) lleve el (C-S, C-G) a través de un I-PMSI, mientras que algún otro enrutador PE, que también está conectado al sitio que contiene C-S, lleve (C-S, C-G) a través de un S-PMSI. En este caso, el enrutador PE descendente no se uniría al S-PMSI, sino que continuaría recibiendo (C-S, C-G) a través del I-PMSI, porque la ruta UMH para C-S es la que ha sido anunciada por el enrutador PE que lleva (C-S, C-G) sobre el I-PMSI. Este es el comportamiento esperado.

El enrutador PE de salida determina el remitente de una ruta SA A-D (C-S, C-G) tipo 5 al encontrar en su conjunto de candidatos a ruta UMH para C-S una ruta cuyo RD es el mismo que en la ruta SA A-D. La comunidad extendida de importación de ruta VRF de la ruta encontrada contiene la dirección IP del remitente de la ruta SA A-D.