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

Descripción general

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

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

• En el modo disperso de PIM, pueden producirse duplicados en una LAN en el 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 de PIM, se realiza una elección de reenviador designado (DF) en todas las LAN para evitar la duplicación.

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

El RPF basado en remitentes es una solución que se debe usar junto con las MVPN de BGP, ya que las MVPN de BGP usan una alternativa a las soluciones de eventos basados en 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 caso de MVPN, es posible determinar qué enrutador de PE envió el tráfico. Junos OS utiliza esta información para reenviar el tráfico únicamente si se envía desde el enrutador de PE correcto. Con el RPF basado en remitentes, la comprobación de 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 concretamente, los datos deben llegar con la etiqueta MPLS correcta en el encabezado exterior que se usa 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 el remitente no reemplaza 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 causa que la preferencia de ruta de unidifusión determine la elección de reenvío ú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 el RPF basado en el remitente.

En el caso de los túneles de proveedor de punto a multipunto RSVP, la etiqueta de transporte identifica el enrutador de PE de envío, ya que es un requisito que el penúltimo salto (PHP) esté deshabilitado cuando se usan 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 (dado que el túnel RSVP-TE es de punto a multipunto) el enrutador de PE de envío.

El mecanismo de RPF basado en el 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 activa descrita en el borrador de Internet draft-morin-l3vpn-mvpn-fast-tolerancia a fallos-05 VPN de multidifusión tolerancia a fallos ascendente 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 una enrutador de PE ascendente principal y de respaldo. Esto permite que varias copias del tráfico fluyan a través del núcleo del proveedor hasta el enrutador de PE de salida. El RPF basado en el remitente y el modo de espera de raíz activa se pueden usar juntos para admitir tráfico MVPN de BGP en vivo . Este es un esquema de multidifusión a través de MPLS para transportar tráfico de transmisión de TV e IPTV profesional de misión crítica. Un requisito clave para muchos de estos despliegues es tener una redundancia completa del equipo de red, incluidos los enrutadores de PE de entrada y salida. En algunos casos, se requiere un enfoque de vivo a vivo, lo que significa que se envían dos flujos de tráfico duplicados a través de la red siguiendo rutas diversas. 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 un único flujo 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 de la espera de raíz activa, consulte hot-root-standby.

El RPF basado en el 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 reenvío único no es suficiente para evitar duplicados. La elección de un solo reenviador se utiliza para evitar duplicados en la red central, mientras que el RPF basado en el remitente evita duplicados para el cliente, incluso si hay duplicados en el núcleo. Hay casos en los que la elección de un único reenviador no puede impedir que llegue tráfico duplicado 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 PIM disperso 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 elige el enrutador de PE de entrada, la decisión de RPF basada en el remitente determina si se selecciona 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 un PMSI, es posible que pueda identificar el enrutador de PE que transmitió el paquete al PMSI. Si ese transmisor no es el enrutador de PE seleccionado por PE1 como el enrutador de PE ascendente, PE1 puede dejar caer el paquete. Esto significa que el enrutador de PE detecta un duplicado, pero el duplicado no se reenvía.

Cuando un enrutador de PE de salida genera una ruta de C-multidifusión tipo 7, utiliza la comunidad extendida de importación de ruta VRF transportada en la ruta VPN-IP hacia el origen para construir el destino de ruta transportado por la ruta de 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 desde este enrutador de PE y solo en un túnel determinado enraizado en ese enrutador de PE.

Cuando un enrutador de PE de salida genera una ruta de C-multidifusión tipo 6, utiliza la comunidad extendida de importación de ruta VRF transportada en la ruta VPN-IP hacia el punto de encuentro (RP) para construir el destino de ruta transportado por la ruta de 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 aceptar únicamente el tráfico de este enrutador de PE y solo en un túnel determinado enraizado en ese enrutador de PE. Sin embargo, si otros enrutadores de PE cambiaron al modo SPT para (C-S, C-G) y enviaron rutas de autodescubrimiento (A-D) de origen activo (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, pero el enrutador de PE que origina una ruta SA A-D para (C-S, C-G). El tráfico para (C-S, C-G) puede transportarse a través de un I-PMSI o S-PMSI, dependiendo de cómo lo haya anunciado 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), es posible que el enrutador de PE de salida esté recibiendo (C-S, C-G) rutas SA tipo 5 de varios enrutadores PE y elige el mejor, como se indica a continuación: Por cada ruta SA recibida (C-S, C-G), el enrutador de PE de salida encuentra en su salto de multidifusión ascendente (UMH) enrutado para C-S una ruta con el mismo distinguidor de ruta (RD). Entre todas estas rutas encontradas, el enrutador PE selecciona la ruta UMH (basada en 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 de cliente [CE]), el enrutador de PE ascendente para eso (C-S, C-G) no necesariamente va a ser el mismo enrutador de PE que originó la mejor ruta SA A-D ya seleccionada para (C-S, C-G). Es posible tener una situación en la que el enrutador de PE que originó la mejor ruta SA A-D para (C-S, C-G) lleve el (C-S, C-G) a través de un I-PMSI, mientras que algún otro enrutador de 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 de 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 de PE que lleva (C-S, C-G) a través del I-PMSI. Este es el comportamiento esperado.

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

Comportamiento RPF basado en remitentes específicos de la plataforma

Use el Explorador de características para confirmar la compatibilidad de plataforma y versión para características específicas.

Utilice la siguiente tabla para revisar el comportamiento específico de la plataforma para su plataforma.

Tabla 1: Comportamiento de RPF basado en remitentes específicos de la plataforma

Plataforma	Diferencia
serie MX	El RPF basado en remitentes es compatible con plataformas de la serie MX con tarjetas de línea MPC. Como requisito previo, el enrutador debe estar configurado en network-services enhanced-ip modo.