Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Introducción a los túneles de LSP de RSVP

 

Un túnel de etiqueta de protocolo de reserva de recursos (de RSVP) para la ruta de acceso conmutada (LSP) le permite enviar LSP de RSVP dentro de otros LSP de RSVP. Esto permite a un administrador de red proporcionar ingeniería de tráfico de un extremo de la red al otro. Una aplicación útil para esta característica consiste en conectar enrutadores perimetrales del cliente (CE) con enrutadores perimetrales de proveedor (PE) mediante un LSP de RSVP y, a continuación, canalizar el LSP de este perímetro dentro de un segundo LSP que viajan por el núcleo de la red.

Debe tener conocimientos generales sobre MPLS y conceptos de conmutación de etiquetas. Para obtener más información acerca de MPLS, consulte la Guía de configuración de aplicaciones MPLS Junos.

Un túnel LSP de RSVP agrega el concepto de una adyacencia de reenvío, similar al usado para el conmutación de etiquetas multiprotocolo generalizado (GMPLS). (Para obtener más información acerca de GMPLS, consulte Guía de usuario de Junos GMPLS.

La adyacencia de reenvío crea una ruta de acceso de túnel para enviar datos entre dispositivos del mismo nivel en una red de LSP de RSVP. Una vez que se ha establecido un LSP de reenvío (FA-LSP), se pueden enviar otros LSP a través del LSP de AF con la ruta más corta primero (CSPF), el protocolo de administración de vínculos (LMP), el Primera trayectoria abierta más corta (Open Shortest Path First) (OSPF) y RSVP.

Para habilitar un túnel de LSP de RSVP, el Junos OS utiliza los siguientes mecanismos:

  • LMP—diseñado originalmente para GMPLS, LMP establece el reenvío de adyacencias entre los interlocutores del túnel RSVP LSP, y mantiene y asigna recursos para los vínculos de ingeniería de tráfico.

  • OSPF Extensions—OSPF se diseñó para enrutar paquetes a interfaces físicas y lógicas relacionadas con una tarjeta de interfaz física (PIC). Este protocolo se ha ampliado para enrutar paquetes a interfaces del mismo nivel virtual definidas en una configuración de LMP.

  • Extensiones—RSVP-te la RSVP-te fue diseñada para indicar la instalación de LSP de paquetes en interfaces físicas. El protocolo se ha extendido para solicitar una configuración de ruta para LSP de paquetes que viajan a interfaces de punto virtual definidas en una configuración de LMP.

    Nota

    A partir de Junos OS versión 15,1, la compatibilidad de varias instancias se extiende a MPLS RSVP-TE. Esta compatibilidad solo está disponible para el tipo de instancia de enrutador virtual. Un enrutador puede crear y participar en varias particiones independientes de TE de la TI, lo que permite escalar cada dominio de TE particionado de forma independiente. Multi-Instance RSVP-TE proporciona flexibilidad a mano elegir las entidades de plano de control que deben tener en cuenta las instancias, por ejemplo, un enrutador puede participar en varias instancias de TE mientras se sigue ejecutando una sola instancia de BGP.

    La implementación Junos OS de MPLS RSVP-TE se amplía para mejorar la facilidad de uso, la visibilidad, la configuración y la solución de problemas de LSP en la versión 16,1 de Junos OS.

    Estas mejoras facilitan la configuración de RSVP-TE:

    • Garantizar la preparación del plano de datos del LSP durante la Reseñalización del LSP antes de que el tráfico recorra al LSP con el mecanismo de ping automático RSVP-TE LSP.

      Un LSP no debe empezar a transportar tráfico a menos que se sepa que se ha programado en el plano de datos. El intercambio de datos en el plano de datos del LSP, como solicitudes de ping LSP, ocurre en el enrutador de entrada antes de cambiar el tráfico a un LSP o a su instancia MBB. En redes de gran tamaño, este tráfico puede saturar un enrutador de salida de LSP, ya que el LSP de salida debe responder a las solicitudes de ping de LSP. El mecanismo de auto-ping de LSP permite que los LER de entrada creen mensajes de respuesta de ping LSP y los envíen a través del avión de datos del LSP. Al recibir estos mensajes, la salida LER los reenvía a la entrada, indicando el liveliness del plano de datos del LSP. Esto garantiza que el LSP no comience a transportar tráfico antes de que se haya programado el plano de datos.

    • Quitando el límite de hardware actual de 64K LSP en un enrutador de entrada y escalar el número total de LSP con LSP señalizados de RSVP-TE. Puede haber hasta 64 KB de LSP configurados para cada salida. Anteriormente, este límite era el número agregado de proveedores de idiomas que podían configurarse en el LER de entrada.

    • Impedir que el enrutador de entrada recorte abruptamente los LSP debido a un retraso en la señalización del LSP en los enrutadores de tránsito.

    • Habilitación de una vista flexible de conjuntos de datos de LSP para facilitar la visualización de datos característico de LSP.

    Nota

    A partir de Junos OS versión 17,4, se introduce un cronómetro predeterminado de 1800 segundos para el ping automático.

Existen las siguientes limitaciones para las jerarquías de LSP:

  • No se admiten LSP con conexión cruzada de circuito (CCC).

  • No se admite el reinicio correcto.

  • La protección de enlaces no está disponible para los proveedores de inactivos de AF ni en el punto de salida de la adyacencia de reenvío.

  • No se admiten LSP de punto a multipunto en todos los proveedores de LSP de FA.