Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuración de PCEP

Descripción general de PCEP

Un elemento de cálculo de ruta (PCE) es una entidad (componente, aplicación o nodo de red) que es capaz de calcular una ruta o ruta de red basada en un gráfico de red y aplicar restricciones computacionales. Un cliente de cálculo de ruta (PCC) es cualquier aplicación cliente que solicita que un PCE realice un cálculo de ruta. El protocolo de elemento de cálculo de ruta (PCEP) permite las comunicaciones entre un PCC y un PCE, o entre dos PCE (definidos en RFC 5440).

PCEP es un protocolo basado en TCP definido por el IETF PCE Working Group, y define un conjunto de mensajes y objetos utilizados para administrar sesiones PCEP y para solicitar y enviar rutas para LSP de ingeniería de tráfico multidominio (TE LSP). Proporciona un mecanismo para que un PCE realice el cálculo de la ruta para los LSP externos de un PCC. Las interacciones de PCEP incluyen informes de estado de LSP enviados por el PCC al PCE y actualizaciones de PCE para los LSP externos.

Figura 1 ilustra el papel de PCEP en la implementación del lado del cliente de una arquitectura PCE con estado en una red habilitada para MPLS RSVP-TE.

Figura 1: Sesión de PCEPSesión de PCEP

Una sesión de PCEP basada en TCP conecta un PCC a un PCE externo. El PCC inicia la sesión de PCEP y permanece conectado al PCE durante la sesión de PCEP. Durante la sesión de PCEP, el PCC solicita parámetros LSP del PCE con estado. Al recibir uno o más parámetros LSP del PCE, el PCC vuelve a señalar el LSP TE. Cuando finaliza la sesión PCEP, la conexión TCP subyacente se cierra inmediatamente y el PCC intenta restablecer la sesión PCEP.

Por lo tanto, las funciones de PCEP incluyen:

  • Sincronización de estado de túnel LSP entre un PCC y un PCE con estado: cuando se detecta una conexión PCE con estado activa, un PCC intenta delegar todos los LSP a este PCE en un procedimiento denominado sincronización de estado LSP. PCEP permite la sincronización del estado PCC LSP con el PCE.

  • Delegación del control sobre los túneles de LSP a un PCE con estado: un PCE con estado activo controla uno o más atributos de LSP para las rutas de cálculo, como el ancho de banda, la ruta (ERO) y la prioridad (configuración y retención). PCEP permite dicha delegación de LSP para el cálculo de rutas.

  • Control PCE con estado de temporización y secuencia de cálculos de ruta dentro y entre sesiones PCEP: un PCE con estado activo modifica uno o más atributos de LSP, como el ancho de banda, la ruta (ERO) y la prioridad (configuración y retención). PCEP comunica estos nuevos atributos de LSP del PCE al PCC, después de lo cual el PCC vuelve a señalar el LSP en la ruta especificada.

Descripción general de la compatibilidad del protocolo de elemento de cálculo de ruta para RSVP-TE

Descripción de MPLS RSVP-TE

La ingeniería de tráfico (TE) se ocupa de la optimización del rendimiento de las redes operativas, principalmente mapeando flujos de tráfico en una topología física existente. La ingeniería de tráfico proporciona la capacidad de alejar el flujo de tráfico de la ruta más corta seleccionada por el protocolo de puerta de enlace interior (IGP) a una ruta física potencialmente menos congestionada a través de una red.

Para la ingeniería de tráfico en redes grandes y densas, las capacidades MPLS se pueden implementar porque potencialmente proporcionan la mayor parte de la funcionalidad disponible desde un modelo superpuesto, de manera integrada y a un costo menor que las alternativas que compiten actualmente. La razón principal para implementar la ingeniería de tráfico MPLS es controlar las rutas a lo largo de las cuales el tráfico fluye a través de una red. La principal ventaja de implementar la ingeniería de tráfico MPLS es que proporciona una combinación de las capacidades de ingeniería de tráfico de ATM, junto con la diferenciación de clase de servicio (CoS) de IP.

En una red MPLS, la información del plano de datos se reenvía mediante la conmutación de etiquetas. A un paquete que llega a un enrutador perimetral de proveedor (PE) desde el enrutador perimetral del cliente (CE) se le aplican etiquetas y, a continuación, se reenvía al enrutador de PE de salida. Las etiquetas se eliminan en el enrutador de salida y luego se reenvían al destino apropiado como un paquete IP. Los enrutadores de conmutación de etiquetas (LSR) del dominio MPLS utilizan protocolos de distribución de etiquetas para comunicar el significado de las etiquetas utilizadas para reenviar el tráfico entre los LSR y a través de ellos. RSVP-TE es uno de esos protocolos de distribución de etiquetas que permite a un par LSR aprender sobre las asignaciones de etiquetas de otros pares.

Cuando tanto MPLS como RSVP están habilitados en un enrutador, MPLS se convierte en un cliente de RSVP. El objetivo principal del software RSVP de Junos OS es admitir la señalización dinámica dentro de las rutas de conmutación de etiquetas (LSP). RSVP reserva recursos, como para flujos de multidifusión y unidifusión IP, y solicita parámetros de calidad de servicio (QoS) para las aplicaciones. El protocolo se extiende en la ingeniería de tráfico MPLS para permitir que RSVP configure LSP que se pueden usar para la ingeniería de tráfico en redes MPLS.

Cuando se combinan MPLS y RSVP, las etiquetas se asocian con flujos RSVP. Una vez que se establece un LSP, el tráfico a través de la ruta se define mediante la etiqueta aplicada en el nodo de entrada del LSP. La asignación de la etiqueta al tráfico se realiza utilizando diferentes criterios. El conjunto de paquetes a los que un nodo específico asigna el mismo valor de etiqueta pertenece a la misma clase de equivalencia de reenvío (FEC) y define efectivamente el flujo RSVP. Cuando el tráfico se asigna a un LSP de esta manera, el LSP se denomina túnel LSP.

Los túneles LSP son una forma de establecer rutas unidireccionales con conmutación de etiquetas. RSVP-TE se basa en el protocolo central RSVP mediante la definición de nuevos objetos y la modificación de los objetos existentes utilizados en los objetos PATH y RESV para el establecimiento de LSP. Los nuevos objetos, el objeto LABEL-REQUEST (LRO), el objeto RECORD-ROUTE (RRO), el objeto LABEL y el objeto EXPLICIT-ROUTE (ERO), son opcionales con respecto al protocolo RSVP, excepto los objetos LRO y LABEL, que son obligatorios para establecer túneles LSP.

En general, RSVP-TE establece una ruta de conmutación de etiquetas que garantiza la entrega de la trama desde la entrada hasta el enrutador de salida. Sin embargo, con las nuevas capacidades de ingeniería de tráfico, se admiten las siguientes funciones en un dominio MPLS:

  • Posibilidad de establecer una ruta de conmutación de etiquetas utilizando una ruta explícita total o parcial (RFC 3209).

  • Establecimiento de LSP basado en restricciones sobre vínculos que cumplen requisitos, como el ancho de banda y las propiedades del vínculo.

  • Control de extremos, que se asocia con el establecimiento y la administración de túneles LSP en los enrutadores de entrada y salida.

  • Administración de vínculos, que administra los recursos de vínculos para realizar un enrutamiento consciente de los recursos de los LSP de ingeniería de tráfico y para programar etiquetas MPLS.

  • Reenrutamiento rápido (FRR) de MPLS, que administra los LSP que necesitan protección y asigna información de túnel de respaldo a estos LSP.

Limitaciones actuales de MPLS RSVP-TE

Aunque las extensiones RSVP para ingeniería de tráfico permiten una mejor utilización de la red y cumplen con los requisitos de las clases de tráfico, el conjunto de protocolos MPLS RSVP-TE de hoy en día tiene varios problemas inherentes a su naturaleza distribuida. Esto causa una serie de problemas durante la contención de la capacidad de bisección, especialmente dentro de una clase de prioridad LSP donde un subconjunto de LSP comparte valores de configuración y prioridad de retención. Las limitaciones de RSVP-TE incluyen:

  • Falta de visibilidad de las demandas individuales de ancho de banda por LSP y por dispositivo: los enrutadores de entrada en una red MPLS RSVP-TE establecen LSP sin tener una vista global de la demanda de ancho de banda en la red. La información sobre el uso de recursos de red solo está disponible como capacidad total reservada por clase de tráfico por interfaz. El estado de LSP individual está disponible localmente en cada enrutador perimetral de etiqueta (LER) solo para sus propios LSP. Como resultado, surgen una serie de problemas relacionados con el patrón de demanda, particularmente dentro de una configuración común y prioridad de retención.

  • Naturaleza asincrónica e independiente de la señalización RSVP: en RSVP-TE, un administrador controla las restricciones para el establecimiento de rutas. Como tal, el ancho de banda reservado para un túnel LSP es establecido por el administrador y no implica automáticamente ningún límite en el tráfico enviado a través del túnel. Por lo tanto, el ancho de banda disponible en un enlace de ingeniería de tráfico es el ancho de banda configurado para el vínculo, excluyendo la suma de todas las reservas realizadas en el vínculo. Por lo tanto, las demandas no señalizadas en un túnel LSP conducen a la degradación del servicio del LSP que requiere exceso de ancho de banda, así como de los otros LSP que cumplen con los requisitos de ancho de banda del enlace de ingeniería de tráfico.

  • Los LSP establecidos en función de las opciones de ruta dinámicas o explícitas en el orden de preferencia: los enrutadores de entrada en una red RSVP-TE de MPLS establecen LSP para las demandas basadas en el orden de llegada. Dado que los enrutadores de entrada no tienen una vista global de la demanda de ancho de banda en la red, el uso del orden de preferencia para establecer los LSP puede provocar la caída del tráfico o que los LSP no se establezcan en absoluto cuando hay un exceso de demanda de ancho de banda.

Como ejemplo, se configura con MPLS RSVP-TE, en el que A y G son los enrutadores de borde de etiqueta (LER).Figura 2 Estos enrutadores de entrada establecen LSP de forma independiente en función del orden de las demandas y no tienen conocimiento ni control sobre los LSP de los demás. Los enrutadores B, C y D son enrutadores intermedios o de tránsito que se conectan a los enrutadores de salida E y F.

Figura 2: Ejemplo de ingeniería de tráfico MPLSEjemplo de ingeniería de tráfico MPLS

Los enrutadores de entrada establecen LSP en función del orden en que llegan las demandas. Si el enrutador G recibe dos demandas de capacidad 5 cada una para G-F, entonces G señala dos LSP, LSP1 y LSP2, a través de G-B-D-F. De la misma manera, cuando el enrutador A recibe la tercera demanda de capacidad 10 para A-E, entonces señala un LSP, LSP3, a través de A-B-C-E. Sin embargo, si la demanda en el LSP A-E aumenta de 10 a 15, el enrutador A no puede señalar LSP3 utilizando la misma ruta (A-B-C-E), porque el enlace B-C tiene una capacidad menor.

El enrutador A debería haber señalado el aumento de la demanda en LSP3 utilizando la ruta A-B-D-C-E. Dado que LSP1 y LSP2 han utilizado el enlace B-D en función del orden de las demandas recibidas, LSP3 no está señalado.

Por lo tanto, aunque se dispone de un ancho de banda de flujo máximo adecuado para todos los LSP, el LSP3 está sujeto a una degradación del servicio potencialmente prolongada. Esto se debe a la falta de visibilidad de la demanda global del enrutador A y a la falta de coordinación sistémica en la colocación de la demanda por parte de los enrutadores de entrada A y G.

Uso de una entidad informática de ruta externa

Como solución a las limitaciones actuales que se encuentran en el cálculo de la ruta MPLS RSVP-TE, se requiere una entidad de computación de ruta externa con una visión global de la demanda por LSP y por dispositivo en la red, independientemente de la capacidad disponible.

Actualmente, en una red MPLS RSVP-TE solo se proporciona computación de ruta de enrutamiento en línea y basada en restricciones en tiempo real. Cada enrutador realiza cálculos de enrutamiento basados en restricciones independientemente de los demás enrutadores de la red. Estos cálculos se basan en información de topología disponible actualmente, información que suele ser reciente, pero no completamente precisa. Las ubicaciones de LSP se optimizan localmente, según el estado actual de la red. Los túneles RSVP-TE de MPLS se configuran mediante la CLI. Un operador configura el TE LSP, que luego es señalado por el enrutador de entrada.

Además de las capacidades de ingeniería de tráfico existentes, la funcionalidad RSVP-TE de MPLS SE AMPLÍA PARA INCLUIR UNA ENTIDAD DE COMPUTACIÓN DE RUTA EXTERNA, DENOMINADA ELEMENTO DE CÁLCULO DE RUTA (PCE). El PCE calcula la ruta para los LSP de TE de los enrutadores de entrada que se han configurado para el control externo. El enrutador de entrada que se conecta a un PCE se denomina cliente de cálculo de ruta (PCC). El PCC está configurado con el protocolo de cliente de cálculo de ruta (PCEP) para facilitar la computación de rutas externas mediante un PCE.

Para obtener más información, consulte Componentes de la computación de ruta externa.

Para habilitar la computación de ruta externa para los LSP de TE de un PCC, incluya la instrucción en los niveles de jerarquía y .lsp-external-controller pccd[edit mpls][edit mpls lsp lsp-name]

Componentes de la computación de ruta externa

Los componentes que componen un sistema de computación de ruta externa son:

Elemento de cálculo de ruta

Un elemento de cálculo de ruta (PCE) puede ser cualquier entidad (componente, aplicación o nodo de red) que sea capaz de calcular una ruta o ruta de red basada en un gráfico de red y aplicar restricciones computacionales. Sin embargo, un PCE solo puede calcular la ruta para aquellos LSP de TE de un PCC que se han configurado para el control externo.

Un PCE puede ser con estado o apátrida.

  • PCE con estado: un PCE con estado mantiene una sincronización estricta entre el PCE y los estados de la red (en términos de topología e información de recursos), junto con el conjunto de rutas calculadas y recursos reservados en uso en la red. En otras palabras, un PCE con estado utiliza información de la base de datos de ingeniería de tráfico, así como información sobre rutas existentes (por ejemplo, LSP TE) en la red al procesar nuevas solicitudes del PCC.

    Un PCE con estado es de dos tipos:

    • PCE pasivo con estado: mantiene la sincronización con el PCC y aprende los estados LSP del PCC para optimizar mejor los cálculos de ruta, pero no tiene control sobre ellos.

    • PCE con estado activo: modifica activamente los LSP de PCC, además de aprender sobre los estados de LSP de PCC.

      Nota:

      En una configuración redundante con PCE con estado principal y activo de copia de seguridad, el PCE con estado activo de copia de seguridad no puede modificar los atributos de los LSP delegados hasta que se convierta en el PCE principal en el momento de una conmutación por error. No hay preferencia sobre los ECF en el caso de un cambio. El PCE principal está respaldado por un PCE de respaldo, y cuando el PCE principal deja de funcionar, el PCE de respaldo asume el papel del PCE principal y sigue siendo el PCE principal incluso después de que el PCE que anteriormente era el PCE principal vuelva a funcionar.

    Un PCE con estado proporciona las siguientes funciones:

    • Ofrece computación de ruta LSP sin conexión.

    • Activa el reenrutamiento de LSP cuando es necesario volver a optimizar la red.

    • Cambia el ancho de banda de LSP cuando hay un aumento en la demanda de ancho de banda de una aplicación.

    • Modifica otros atributos de LSP en el enrutador, como ERO, prioridad de configuración y prioridad de retención.

    Una PCE tiene una visión global de la demanda de ancho de banda en la red y mantiene una base de datos de ingeniería de tráfico para realizar cálculos de rutas. Realiza la recopilación de estadísticas de todos los enrutadores del dominio MPLS mediante SNMP y NETCONF. Esto proporciona un mecanismo para el control fuera de línea de los LSP TE del PCC. Aunque un sistema de cálculo de ruta LSP fuera de línea se puede integrar en un controlador de red, el PCE actúa como un controlador de red completo que proporciona control sobre los LSP TE del PCC, además de las rutas informáticas.

    Aunque un PCE con estado permite un cálculo óptimo de la ruta y un mayor éxito en el cálculo de la ruta, requiere mecanismos de sincronización de estado confiables, con una sobrecarga del plano de control potencialmente significativa y el mantenimiento de una gran cantidad de datos en términos de estados, como en el caso de una malla completa de LSP TE.

  • PCE sin estado: un PCE sin estado no recuerda ninguna ruta calculada y cada conjunto de solicitudes se procesa de forma independiente entre sí (RFC 5440).

Cliente de cálculo de ruta

Un cliente de cálculo de ruta (PCC) es cualquier aplicación cliente que solicita que un PCE realice un cálculo de ruta.

Un PCC puede conectarse a un máximo de 10 PCE a la vez. La conexión de PCC a PCE puede ser una ruta estática configurada o una conexión TCP que establece la accesibilidad. El PCC asigna un número de prioridad a cada PCE conectado. Envía un mensaje a todas las PCE conectadas con información sobre sus LSP actuales, en un proceso llamado sincronización de estado LSP. Para los LSP de TE que tienen habilitado el control externo, el PCC delega esos LSP al PCE principal. El PCC elige, como PCE principal, un PCE con el número de prioridad más bajo, o el PCE al que se conecta primero en ausencia de un número de prioridad.

El PCC vuelve a señalar un LSP en función de la ruta calculada que recibe de un PCE. Cuando se termina la sesión de PCEP con el PCE principal, el PCC elige un nuevo PCE principal, y todos los LSP delegados al PCE principal anteriormente se delegan al PCE principal recientemente disponible.

Protocolo de elemento de cálculo de ruta

El protocolo de elemento de cálculo de ruta (PCEP) se utiliza para la comunicación entre PCC y PCE (así como entre dos PCE) (RFC 5440). PCEP es un protocolo basado en TCP definido por el IETF PCE Working Group, y define un conjunto de mensajes y objetos utilizados para administrar sesiones PCEP y para solicitar y enviar rutas para TE LSP multidominio. Las interacciones PCEP incluyen mensajes PCC, así como notificaciones de estados específicos relacionados con el uso de un PCE en el contexto de MPLS RSVP-TE. Cuando se utiliza PCEP para la comunicación de PCE a PCE, el PCE solicitante asume el papel de PCC.

Por lo tanto, las funciones de PCEP incluyen:

  • Sincronización del estado del túnel LSP entre PCC y un PCE con estado.

  • Delegación del control sobre túneles LSP a un PCE con estado.

Interacción entre un PCE y un PCC usando PCEP

Figura 3 ilustra la relación entre un PCE, PCC y el papel de PCEP en el contexto de MPLS RSVP-TE.

Figura 3: PCC y RSVP-TEPCC y RSVP-TE

La comunicación PCE a PCC está habilitada por el PCEP basado en TCP. El PCC inicia la sesión de PCEP y permanece conectado a un PCE durante la sesión de PCEP.

Nota:

A partir de Junos OS versión 16.1, puede proteger una sesión PCEP mediante la autenticación TCP-MD5 según RFC 5440. Para habilitar el mecanismo de seguridad MD5 para una sesión PCEP, se recomienda definir y vincular la clave de autenticación MD5 en el nivel jerárquico para una sesión PCEP.[edit protocols pcep pce pce-id] Sin embargo, también puede usar un llavero predefinido desde el nivel jerárquico para asegurar una sesión PCEP.[edit security authentication-key-chains key-chain] En este caso, debe enlazar el llavero predefinido a la sesión PCEP en el nivel jerárquico .[edit protocols pcep pce pce-id]

El PCE y el PCC utilizan la misma clave para verificar la autenticidad de cada segmento enviado en la conexión TCP de la sesión PCEP, asegurando así la comunicación PCEP entre los dispositivos, que podría estar sujeta a ataques y puede interrumpir los servicios en la red.

Para obtener más información sobre cómo proteger las sesiones PCEP mediante la autenticación MD5, consulte .Autenticación TCP-MD5 para sesiones PCEP

Una vez establecida la sesión de PCEP, el PCC realiza las siguientes tareas:

  1. Sincronización de estado de LSP: el PCC envía información sobre todos los LSP (locales y externos) a todos los PCE conectados. Para los LSP externos, el PCC envía información sobre cualquier cambio de configuración, RRO o cambio de estado, etc., al PCE.

    Para los LSP iniciados por PCE, no hay ninguna configuración de LSP presente en el PCC. El PCE que inicia el LSP envía los parámetros del LSP al PCC que ha indicado su capacidad de soportar LSP iniciados por PCE.

    Nota:

    La compatibilidad con LSP iniciados por PCE se proporciona en Junos OS versión 13.3 y versiones posteriores.

  2. Delegación de LSP: después de sincronizar la información de estado de LSP, el PCC delega los LSP externos en un PCE, que es el principal PCE de estado activo. Solo el PCE principal puede establecer parámetros para el LSP externo. Los parámetros que modifica el PCE principal incluyen ancho de banda, ruta (ERO) y prioridad (configuración y retención). Los parámetros especificados en la configuración local son reemplazados por los parámetros establecidos por el PCE principal.

    Nota:

    Cuando se termina la sesión de PCEP con el PCE principal, el PCC elige un nuevo PCE principal, y todos los LSP delegados al PCE principal anteriormente se delegan al PCE principal recientemente disponible.

    En el caso de los LSP iniciados por PCE, el PCC crea el LSP utilizando los parámetros recibidos del PCE. El PCC asigna al LSP iniciado por PCE un LSP-ID único y delega automáticamente el LSP al PCE. Un PCC no puede revocar la delegación de los LSP iniciados por el PCE para una sesión activa de PCEP.

    Cuando finaliza una sesión de PCEP, el PCC inicia dos temporizadores sin eliminar inmediatamente los LSP iniciados por PCE, y para evitar la interrupción de los servicios.delegation cleanup timeoutlsp cleanup timer Durante este tiempo, una PCE con estado activa puede adquirir el control de los LSP aprovisionados por la PCE fallida mediante el envío de una solicitud de creación para el LSP.

    El control sobre los LSP iniciados por PCE revierte al PCC al expirar el .delegation cleanup timeout Cuando el expira, y ningún otro PCE ha adquirido el control sobre el LSP del PCE fallido, el PCC toma el control local del LSP iniciado por PCE no delegado.delegation cleanup timeout Más tarde, cuando el PCE original o un nuevo PCE activo desea adquirir el control de los LSP iniciados por PCE controlados localmente, el PCC delega estos LSP al PCE y el temporizador se detiene.lsp cleanup timer

    Una ECF puede devolver la delegación del LSP iniciado por la ECF al CCP para permitir la transferencia de LSP entre ECF. Esto desencadena el para el LSP iniciado por PCE.lsp cleanup timer El PCC espera a que caduque el temporizador de limpieza de LSP antes de quitar los LSP iniciados por PCE no delegados del PCE fallido.

    Cuando el expira y ningún otro PCE ha adquirido el control sobre los LSP del PCE fallido, el PCC elimina todos los LSP aprovisionados por el PCE fallido.lsp cleanup timer

    Nota:

    De conformidad con el borrador-ietf-pce-stateful-pce-09, la revocación de las delegaciones LSP iniciadas por el PCE por un PCC ocurre de manera previa antes de que los LSP se redeleguen a un PCE alternativo. A partir de Junos OS versión 18.1R1, el debe ser mayor o igual que el para que el PCC revoque las delegaciones de LSP.lsp-cleanup-timerdelegation-cleanup-timeout De lo contrario, el intervalo de tiempo de espera de redelegación para el PCC se puede establecer en infinito, donde las delegaciones de LSP a ese PCE permanecen intactas hasta que el PCC tome medidas específicas para cambiar los parámetros establecidos por el PCE.

  3. Señalización de LSP: al recibir uno o más parámetros de LSP del PCE de estado activo principal, el PCC vuelve a señalar el LSP de TE en función de la ruta proporcionada por el PCE. Si el PCC no puede configurar el LSP, notifica al PCE el error de configuración y espera a que el PCE principal proporcione nuevos parámetros para ese LSP y, a continuación, lo vuelve a señalar.

    Cuando el PCE especifica una ruta que está incompleta o tiene saltos sueltos en los que solo se especifican los extremos de la ruta, el PCC no realiza un enrutamiento local basado en restricciones para averiguar el conjunto completo de saltos. En cambio, el PCC proporciona RSVP con la ruta proporcionada por PCE, tal como está, para la señalización, y la ruta se configura utilizando el enrutamiento IGP salto a salto.

Teniendo en cuenta la topología utilizada en , se ilustra la implementación parcial de PCE del lado cliente en la red habilitada para MPLS RSVP-TE.Figura 2Figura 4 Los enrutadores de entrada A y G son los PCC configurados para conectarse al PCE de estado externo a través de una conexión TCP.

El PCE tiene una vista global de la demanda de ancho de banda en la red y realiza cálculos de rutas externas después de buscar la base de datos de ingeniería de tráfico. A continuación, el PCE con estado activo modifica uno o varios atributos de LSP y envía una actualización al PCC. El PCC utiliza los parámetros que recibe del PCE para volver a señalar el LSP.

Figura 4: Ejemplo de PCE para MPLS RSVP-TEEjemplo de PCE para MPLS RSVP-TE

De esta manera, el PCE con estado proporciona una operación cooperativa de funcionalidad distribuida que se utiliza para abordar desafíos específicos de un cálculo de ruta restringida entre dominios más corto. Elimina los escenarios de congestión en los que los flujos de tráfico se asignan de manera ineficiente a los recursos disponibles, lo que provoca la sobreutilización de algunos subconjuntos de recursos de red, mientras que otros recursos permanecen infrautilizados.

Comportamiento de LSP con computación externa

Tipos de LSP

En una implementación de PCE del lado del cliente, hay tres tipos de LSP TE:

  • LSP controlados por CLI: los LSP que no tienen configurada la instrucción se denominan LSP controlados por CLI.lsp-external-controller pccd Aunque estos LSP están bajo control local, el PCC actualiza las PCE conectadas con información sobre los LSP controlados por la CLI durante el proceso inicial de sincronización de LSP. Después de la sincronización inicial de LSP, el PCC también informa al PCE de cualquier LSP nuevo y eliminado.

  • LSP controlados por PCE: los LSP que tienen la instrucción configurada se denominan LSP controlados por PCE.lsp-external-controller pccd El PCC delega los LSP iniciados por el PCC al PCE principal para el cálculo de rutas externas.

    El PCC informa al PCE sobre los parámetros configurados de un LSP controlado por PCE, como el ancho de banda, la ERO y las prioridades. También informa al PCE sobre los valores reales utilizados para estos parámetros para configurar el LSP, incluido el RRO, cuando estén disponibles.

    El PCC envía dichos informes de estado de LSP al PCE solo cuando se ha producido una reconfiguración o cuando hay un cambio en el ERO, RRO o estado de los LSP controlados por PCE bajo control externo.

    Hay dos tipos de parámetros que provienen de la configuración CLI de un LSP para un PCE:

    • Parámetros que no son anulados por un PCE y que se aplican inmediatamente.

    • Parámetros que son reemplazados por un PCE. Estos parámetros incluyen ancho de banda, ruta y prioridad (valores de configuración y retención). Cuando el modo de control cambia de externo a local, los valores configurados por la CLI para estos parámetros se aplican en la próxima oportunidad para volver a señalar el LSP. Los valores no se aplican inmediatamente.

  • LSP aprovisionados externamente (o LSP iniciados por PCE): los LSP que tienen la instrucción configurada se denominan LSP iniciados por PCE.lsp-provisioning Un LSP iniciado por PCE es creado dinámicamente por un PCE externo; como resultado, no hay ninguna configuración de LSP presente en el PCC. El PCC crea el LSP iniciado por PCE utilizando los parámetros proporcionados por el PCE y delega automáticamente el LSP al PCE.

    Nota:

    La compatibilidad con LSP iniciados por PCE se proporciona en Junos OS versión 13.3 y versiones posteriores.

Los LSP controlados por la CLI, los LSP controlados por PCE y los LSP iniciados por PCE pueden coexistir en un PCC.

Los LSP controlados por CLI y los LSP controlados por PCE pueden coexistir en un PCC.

Modo de control LSP

En una implementación de PCE del lado del cliente, hay dos tipos de modos de control para un LSP controlado por PCC:

  • Externo: de forma predeterminada, todos los LSP controlados por PCE están bajo control externo. Cuando un LSP está bajo control externo, el PCC utiliza los parámetros proporcionados por PCE para configurar el LSP.

  • Local: un LSP controlado por PCE puede estar bajo control local. Cuando el LSP cambia de control externo a control local, el cálculo de la ruta se realiza mediante los parámetros configurados por la CLI y el enrutamiento basado en restricciones. Tal cambio ocurre solo cuando hay un disparador para volver a señalar el LSP. Hasta entonces, el PCC utiliza los parámetros proporcionados por PCE para señalar el LSP controlado por PCE, aunque el LSP permanece bajo control local.

Un LSP controlado por PCE cambia al control local desde su modo de control externo predeterminado en casos como la falta de conectividad a un PCE o cuando un PCE devuelve la delegación de LSP al PCC.

Para obtener más información acerca de los LSP controlados por CLI y los LSP controlados por PCE, consulte .Tipos de LSP

Instrucciones de configuración admitidas para informática externa

Tabla 1 enumera las instrucciones de configuración MPLS y LSP existentes que se aplican a un LSP controlado por PCE.

Tabla 1: Aplicabilidad de MPLS y configuraciones LSP existentes a un LSP controlado por PCE

Soporte para LSP controlado por PCE

Instrucciones de configuración de LSP aplicables

Instrucciones de configuración de MPLS aplicables

Estas instrucciones de configuración se pueden configurar junto con la configuración PCE. Sin embargo, solo surten efecto cuando la configuración local está en uso. Durante el control PCE, estas instrucciones de configuración permanecen inactivas.

  • grupo administrativo

  • ancho de banda automático

  • límite de salto

  • menos llenado

  • más llenado

  • Aleatorio

  • grupo administrativo

  • grupos de administración

  • admin-group-extended

  • límite de salto

  • no-CSPF

  • temporizador de optimización inteligente

Estas instrucciones de configuración se pueden configurar junto con la configuración PCE, pero son reemplazadas por los atributos LSP controlados por PCE. Sin embargo, cuando la configuración local está en uso, se aplican los valores configurados para estas instrucciones de configuración.

Nota:

Los cambios en la configuración local mediante la CLI mientras el LSP está bajo el control de un PCE con estado no tienen ningún efecto en el LSP. Estos cambios solo surten efecto cuando se aplica la configuración local.

  • Banda

  • principal

  • Prioridad

  • Prioridad

Estas instrucciones de configuración no se pueden configurar junto con la configuración de PCE.

  • p2mp

  • Plantilla

  • p2mp-lsp-next-hop

El resto de las instrucciones de configuración de LSP son aplicables de la misma manera que para los LSP existentes. Al configurar cualquiera de las instrucciones de configuración anteriores para un LSP controlado por PCE, se genera un mensaje de registro MPLS para indicar cuándo surten efecto los parámetros configurados.

Protección LSP controlada por PCE

El PCC calcula localmente las rutas de protección, incluidos el reenrutamiento rápido y los LSP de derivación, mediante el enrutamiento basado en restricciones. Un PCE con estado especifica solo la ruta principal (ERO). Una PCE también puede activar una ruta secundaria no en espera, incluso si la configuración local no tiene una ruta secundaria no en espera para la protección de LSP.

LSP ERO controlado por PCE

Para los LSP controlados por PCE (LSP delegados por PCC y LSP iniciados por PCE), solo se debe enviar un objeto de objeto de ruta explícito (ERO) completo desde el PCE al PCC; de lo contrario, el PCC rechaza el mensaje PCUpdate o PCCreate para esa sesión de PCEP.

A partir de Junos OS versión 17.2, además de , se introducen dos nuevos tipos de cálculo de ruta para los LSP controlados por PCE:external cspf local cspf y no cspf.

  • : un PCC utiliza el tipo de cálculo solo cuando el PCE envía una TLV de proveedor de Juniper (número de empresa:local cspflocal cspf 0x0a4c) del tipo 5.

  • no cspf—Ni el PCE ni el PCC realizan un cálculo de ruta restringida. Los puntos finales y las restricciones se proporcionan al módulo RSVP para configurar el LSP con la ruta IGP.

    Un PCC utiliza el tipo de cálculo en los siguientes casos:no cspf

    • Cuando el PCE envía TLV y cuando la configuración de Junos OS o la plantilla coincidente para este LSP se incluye en el LSP delegado por PCC.local cspfno-cspf

    • Cuando el PCE envía TLV y cuando la plantilla de configuración de Junos OS para este LSP se incluye en el LSP iniciado por PCE.local cspfno-cspf

    • Cuando el PCE no envía TLV con un ERO vacío o ERO suelto (con un bit suelto establecido en el objeto ERO).local cspf

Con estos nuevos tipos de cálculo, un PCC puede aceptar un objeto ERO como un ERO suelto o como un ERO vacío. Una entidad de informática de ruta externa que no es capaz de calcular una ruta puede modificar parámetros como el ancho de banda y el color, en función de los análisis. En tales casos, se utiliza un objeto ERO vacío o ERO suelto y el PCC decide el camino a seguir.

RSVP-TE LSP de punto a multipunto controlados por PCE

Después de establecer una sesión de PCEP entre un PCE y un PCC, el PCC informa todos los LSP del sistema al PCE para la sincronización del estado del LSP. Esto incluye los LSP punto a punto controlados por PCC, delegados por PCE e iniciados por PCE. A partir de Junos OS versión 15.1F6 y 16.1R1, esta capacidad se amplía para informar también de LSP punto a multipunto. Para un PCE, el LSP punto a multipunto es similar al del LSP punto a multipunto RSVP, donde el LSP punto a multipunto se trata como una colección de LSP punto a punto agrupados bajo un identificador de punto a multipunto.

De forma predeterminada, el control PCE de LSP punto a multipunto no se admite en un PCC. Para agregar esta capacidad, incluya la instrucción en los niveles de jerarquía o .p2mp-lsp-report-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id] Después de configurar la capacidad de informe punto a multipunto en un PCC, el PCC anuncia esta capacidad al PCE. Si el PCE anuncia a cambio la misma capacidad de informe punto a multipunto, el PCC notifica el árbol LSP completo de punto a multipunto al PCE para la sincronización del estado del LSP.

Un PCC con la capacidad de TE LSP punto a multipunto admite la notificación de LSP de TE punto a multipunto para PCE con estado, actualización punto a multipunto y base de datos LSP que admite el nombre LSP punto a multipunto como clave. Sin embargo, las siguientes características y funciones no son compatibles con Junos OS versión 15.1F6 y 16.1:

  • LSP estáticos de punto a multipunto

  • LSP punto a multipunto delegados por PCE e iniciados por PCE

  • Ancho de banda automático

  • TE++

  • Mensaje de solicitud y respuesta de PCE

  • Creación de LSP punto a multipunto mediante plantillas

  • Configuración de la entrada directa en los LSP punto a multipunto iniciados por PCE

  • Configuración de la entrada directa en el enrutador que apunta a un LSP aprovisionado.

LSP punto a punto iniciados por PCE

A partir de Junos OS versión 16.1, la funcionalidad PCEP se amplía para permitir que un PCE con estado inicie y aprovisione LSP de ingeniería de tráfico a través de un PCC. Anteriormente, los LSP se configuraban en el PCC y el PCC delegaba el control sobre los LSP externos a un PCE. La propiedad del estado LSP fue mantenida por el PCC. Con la introducción de los LSP iniciados por PCE, un PCE puede iniciar y aprovisionar un LSP punto a punto de ingeniería de tráfico dinámicamente sin la necesidad de un LSP configurado localmente en el PCC. Al recibir un mensaje PCCreate de un PCE, el PCC crea el LSP iniciado por PCE y delega automáticamente el LSP al PCE.

De forma predeterminada, un PCC rechaza la solicitud de aprovisionamiento de LSP punto a punto iniciados por PCE desde un PCE. Para habilitar la compatibilidad de los LSP iniciados por PCE en el PCC, incluya la instrucción lsp-provisioning en los niveles de jerarquía o .https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/lsp-provisioning-edit-protocols-pcep-pce.html[edit protocols pcep pce pce-id][edit protocols pcep pce-group group-id]

Un PCC indica su capacidad de admitir LSP punto a punto iniciados por PCE mientras establece la sesión de Protocolo de elemento de cálculo de ruta (PCEP) con el PCE. Un PCE selecciona un PCC con esta capacidad para iniciar un LSP. El PCE proporciona al PCC los parámetros LSP iniciados por PCE. Al recibir los parámetros LSP punto a punto iniciados por PCE, el PCC configura el LSP, asigna un ID de LSP y delega automáticamente el LSP al PCE.

Cuando el PCE que inicia el LSP no proporciona los parámetros LSP punto a punto iniciados por el PCE, el PCC utiliza los parámetros predeterminados. También se puede configurar una plantilla LSP opcional para especificar valores para el LSP punto a punto iniciado por PCE cuando el PCE no proporciona los parámetros LSP. Para configurar una plantilla de LSP para LSP punto a punto iniciados por PCE en el PCC, incluya la instrucción label-switched-path-template en el nivel de jerarquía.label-switched-path-template[edit protocols mpls lsp-external-controller lsp-external-controller]

Cuando finaliza una sesión de PCEP, el PCC inicia dos temporizadores sin eliminar inmediatamente los LSP iniciados por PCE ( y ) para evitar la interrupción de los servicios.delegation cleanup timeoutlsp cleanup timer Durante este tiempo, una PCE con estado activa puede adquirir el control de los LSP aprovisionados por la PCE fallida.

Una ECF puede devolver la delegación del LSP punto a punto iniciado por la ECF al CCP para permitir la transferencia de LSP entre ECF. El control sobre los LSP iniciados por PCE revierte al PCC al expirar el tiempo de espera de limpieza de la delegación. Cuando expira el tiempo de espera de limpieza de la delegación y ningún otro PCE ha adquirido el control sobre el LSP del PCE fallido, el PCC toma el control local del LSP iniciado por el PCE no delegado. Más tarde, cuando el PCE con estado original o nuevo activo desea adquirir el control de los LSP punto a punto iniciados por PCE controlados localmente, el PCC delega estos LSP al PCE y el temporizador de limpieza de LSP se detiene.

El PCC espera a que caduque el temporizador de limpieza de LSP antes de eliminar los LSP punto a punto iniciados por PCE no delegados del PCE fallido. Cuando el temporizador de limpieza de LSP expira y ningún otro PCE ha adquirido el control sobre los LSP del PCE fallido, el PCC elimina todos los LSP aprovisionados por el PCE fallido.

A partir de Junos OS versión 21.1R1, admitimos el enrutamiento activo sin paradas (NSR) para los LSP punto a punto y punto a multipunto basados en RSVP iniciados por PCE. Solo el motor de enrutamiento principal mantiene la sesión PCEP con el controlador. Sincroniza todos los LSP de RSVP iniciados por PCE, incluidas las especificaciones de flujo de multidifusión para cualquier LSP P2MP iniciado por PCE, con el motor de enrutamiento de respaldo. Durante un cambio, la sesión PCEP deja de funcionar y se restablece cuando el motor de enrutamiento de reserva se convierte en el motor de enrutamiento principal. Esto reduce la pérdida de tráfico para el tráfico transportado a través de los LSP de RSVP iniciados por PCE durante los cambios de motor de enrutamiento. Esta función se habilita cuando se configura NSR.

LSP de derivación iniciado por PCE

Descripción de los LSP de derivación iniciados por PCE

Puede haber interrupciones de tráfico en el momento de un error de vínculo o nodo porque las rutas de protección de copia de seguridad en la red no tienen suficiente ancho de banda para manejar el tráfico. En tales redes, aunque se puede usar una PCE para calcular todas las rutas, para optimizar el rendimiento de la red, las rutas de protección local también deben controlarse a través de la PCE.

Junos OS versión 19.2R1 y versiones posteriores proporcionan compatibilidad parcial para el borrador de Internet draft-cbrt-pce-stateful-local-protection-01 (caduca en diciembre de 2018), PCEP Extensions for RSVP-TE Local-Protection with PCE-Stateful, donde la funcionalidad PCEP se amplía para permitir que un PCE con estado inicie, aprovisione y gestione LSP de derivación para una interfaz protegida. El PCE puede iniciar múltiples LSP de derivación con reserva de ancho de banda para proteger un vínculo o nodo. Se espera que el ancho de banda del LSP de derivación sea menor que el ancho de banda total de los LSP primarios que podría proteger.

El mecanismo de selección de derivación existente, que prefiere los LSP de derivación manual (si están disponibles) sobre los LSP de derivación dinámica, se amplía para preferir los LSP de derivación aprovisionados por PCE (si están disponibles) sobre los LSP de derivación dinámica. Los LSP de derivación aprovisionados por PCE tienen una mayor preferencia sobre los LSP de derivación dinámica, pero son menos preferidos que los LSP de derivación manual.

El conjunto de operaciones que se usan para realizar cualquier LSP de derivación operativa, como , también se puede realizar en los LSP de derivación iniciados por PCE.clear rsvp session Puede usar comandos, como y para ver estadísticas de LSP de omisión iniciadas por PCE.show path-computation-client status extensiveshow path-computation-client lsp

Con el soporte del LSP de derivación iniciado por PCE, puede:

  • Cree un LSP de derivación RSVP a través de PCEP desde un controlador externo, donde el LSP de derivación:

    • puede ser para protección de vínculos o nodos.

    • Debe tener un ancho de banda distinto de cero.

    • debe tener una ERO estricta especificada.

  • Actualice el ancho de banda y ERO para un LSP de derivación creado por PCE existente.

  • Sobresuscribir el ancho de banda de LSP de derivación para el control de admisión de LSP primarios. Debe ser un parámetro por bypass y debe permitir actualizar la suscripción por LSP de derivación.

Beneficios del LSP de derivación iniciado por PCE

Los LSP de derivación iniciados por PCE proporcionan los siguientes beneficios:

  • Mejor control sobre el tráfico después de una falla y un cálculo de ruta más determinista de las rutas de protección.

  • Cumpla con restricciones complejas y requisitos de diversidad, como el mantenimiento de diversas rutas para los LSP, así como sus rutas de protección local.

  • Asegúrese de que los vínculos no se sobrecarguen durante los eventos de falla.

Comportamiento de los LSP de derivación iniciados por PCE durante la falla de sesión PCEP

En el momento de un error en la sesión de PCEP, los LSP de derivación iniciados por PCE quedan huérfanos hasta que expira el temporizador de tiempo de espera de estado. Los LSP de derivación iniciados por PCE se limpian al expirar el temporizador de tiempo de espera de estado. Para obtener el control de un LSP de derivación iniciado por PCE (después de que falle la sesión de PCEP), un PCE (ya sea el PCE primario o cualquier PCE secundario) envía un mensaje PCInitiate antes de que expire el temporizador de tiempo de espera de estado.

LSP de punto a multipunto iniciados por PCE

Con la introducción de los LSP iniciados por PCE punto a multipunto, un PCE puede iniciar y aprovisionar un LSP punto a multipunto dinámicamente sin la necesidad de una configuración de LSP local en el PCC. Esto permite que el PCE controle la temporización y la secuencia de los cálculos de ruta punto a multipunto dentro y entre las sesiones del Protocolo de elemento de cálculo de ruta (PCEP), creando así una red dinámica que se controla y despliega de forma centralizada.

Para obtener más información, consulte Descripción del protocolo de elemento de cálculo de ruta para MPLS RSVP-TE con compatibilidad para LSP punto a multipunto iniciados por PCE.Descripción del protocolo de elemento de cálculo de ruta para MPLS RSVP-TE con soporte para LSP punto a multipunto iniciados por PCE

LSP SRv6 en PCEP

El enrutamiento por segmentos se puede aplicar tanto al plano de reenvío MPLS como al IPv6. El elemento de cálculo de ruta (PCE) calcula las rutas de SR para el plano de reenvío MPLS e IPv6. El enrutamiento por segmentos para PCEP admite LSP de SR, como los LSP de SR iniciados por PCE, creados localmente y delegados en el plano de reenvío de IPv6.

Beneficios de los LSP SRv6 en PCEP

  • Permite crear LSP SRv6 iniciados por PCE.
  • Delegue los LSP SRv6 creados en el enrutador al controlador.
  • Informe al controlador de los LSP que se crean localmente en el enrutador.
  • La programación de red SRv6 proporciona la flexibilidad necesaria para aprovechar el enrutamiento por segmentos sin necesidad de implementar MPLS.

PCEP admite la creación, actualización y eliminación de LSP SRv6 con y sin color iniciados por PCE. Cuando el LSP SRv6 iniciado por PCE coexiste junto con un LSP SRv6 estático para la misma IP o IP basada en color, entonces se prefiere la ruta contribuyente LSP SRv6 TE estática sobre la ruta contribuyente LSP SRv6 TE iniciada por PCE.

Para configurar una sesión PCEP para que sea compatible con SRv6, debe habilitar la instrucción de configuración en los niveles de jerarquía [edit protocols pcep pce pce-id] o en [].srv6-capabilityedit protocols pcep pce-group pce-id Si la instrucción de configuración está habilitada, también debe habilitar la instrucción de configuración srv6 en el nivel de jerarquía [] de lo contrario, durante la confirmación y el error se mostrarán.srv6-capabilityedit protocols source-packet-routing

Para configurar SRv6 para SR-TE, debe agregar la instrucción de configuración srv6 en el nivel jerárquico [edit protocols source-packet-routing].

[Consulte Descripción de la política de SR-TE para el túnel SRv6 para obtener más información.https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp-egress-traffic-engineering.html#id_unb_hnk_1rb

Para configurar la profundidad máxima de lista de segmentos para SRv6 LSP, debe habilitar la instrucción de configuración en el nivel de jerarquía [].maximum-srv6-segment-list-depthedit protocols pcep

Ancho de banda automático y LSP controlado por PCE

A partir de Junos OS versión 14.2R4, se proporciona compatibilidad con ancho de banda automático para LSP controlados por PCE. En versiones anteriores, la opción de ancho de banda automático no se aplicaba a los LSP controlados por PCE, aunque los LSP bajo el control del enrutamiento automático y basado en restricciones podían coexistir con los LSP controlados por PCE. La recopilación de estadísticas para el ancho de banda automático solo surtía efecto cuando el modo de control de un LSP controlado por PCE cambia de externo a local. Esto sucedía en casos como la falta de conectividad con un PCE o cuando un PCE devuelve la delegación de LSP al PCC.

Autenticación TCP-MD5 para sesiones PCEP

Un servidor PCE con estado automatiza la creación de rutas de ingeniería de tráfico a través de la red, lo que aumenta la utilización de la red y permite una experiencia de red programable personalizada con el uso de la comunicación PCEP con un PCC. Un PCC envía informes de LSP a un servidor PCE, y el PCE actualiza o aprovisiona los LSP de vuelta al PCC. Los datos enviados a través de una sesión PCEP son cruciales para que un servidor PCE realice computación de ruta externa. Como resultado, un ataque a la comunicación PCEP puede interrumpir los servicios de red. Si se envían mensajes PCEP alterados a un PCC, se pueden configurar LSP inapropiados. Del mismo modo, si los mensajes PCEP alterados se envían a un PCE, el PCE aprende una vista incorrecta de la red.

Teniendo en cuenta la importancia de la comunicación PCEP entre un PCE y un PCC para ejecutar las funcionalidades de PCE de forma eficaz, Junos OS versión 16.1 presenta la función de proteger una sesión PCEP mediante la autenticación TCP-MD5 según RFC 5440. Esta función protege la comunicación entre un PCE y un PCC a través de una sesión de PCEP, que podría estar sujeta a un ataque y puede interrumpir los servicios de red.

Para habilitar el mecanismo de seguridad MD5 para una sesión PCEP, se recomienda definir y vincular la clave de autenticación MD5 en el nivel jerárquico para una sesión PCEP.[edit protocols pcep pce pce-id] Sin embargo, también puede usar un llavero predefinido desde el nivel jerárquico para asegurar una sesión PCEP.[edit security authentication-key-chains key-chain] En este caso, debe enlazar el llavero predefinido a la sesión PCEP en el nivel jerárquico .[edit protocols pcep pce pce-id]

La siguiente configuración se ejecuta en el PCC para establecer una sesión PCEP segura con un PCE:

  • Uso de la clave de autenticación MD5:

  • Uso del llavero de autenticación predefinido:

Para que las sesiones PCEP seguras se establezcan con éxito, la autenticación MD5 debe configurarse con la clave de autenticación previamente compartida tanto en el servidor PCE como en el PCC. El PCE y el PCC utilizan la misma clave para verificar la autenticidad de cada segmento enviado en la conexión TCP de la sesión PCEP.

Nota:
  • Junos OS versión 16.1 solo admite la autenticación TCP-MD5 para sesiones PCEP, sin ampliar la compatibilidad con TLS y TCP-AO, como la protección contra escuchas, manipulación y falsificación de mensajes.

  • La aplicación inicial del mecanismo de seguridad a una sesión PCEP hace que la sesión se reinicie.

  • Si MD5 está mal configurado o no está configurado en un lado de la sesión PCEP, la sesión no se establece. Verifique que las configuraciones en PCC y PCE coinciden.

  • Esta característica no proporciona compatibilidad con ningún mecanismo de autenticación de sesión.

  • Para ver el llavero de autenticación utilizado por la sesión PCEP, utilice las salidas del comando y .show path-computation-client statusshow protocols pcep

  • Utilice el comando para ver el número de paquetes que TCP descarta debido a errores de autenticación.show system statistics tcp | match auth

  • El funcionamiento del llavero se puede verificar utilizando la salida del comando.show security keychain detail

Impacto de la implementación de PCE del lado del cliente en el rendimiento de la red

El mantenimiento de una base de datos con estado puede no ser trivial. En un único entorno de PCE centralizado, un PCE con estado simplemente necesita recordar todos los LSP de TE que el PCE ha calculado, los LSP de TE que se configuraron realmente (si esto se puede saber) y cuándo se derribaron los LSP de TE. Sin embargo, estos requisitos causan una sobrecarga sustancial del protocolo de control en términos de estado, uso y procesamiento de la red, y optimización de vínculos a nivel mundial en toda la red. Por lo tanto, las preocupaciones de una implementación de PCE con estado incluyen:

  • Cualquier mecanismo de sincronización confiable da como resultado una sobrecarga significativa del plano de control. Los PCE pueden sincronizar el estado comunicándose entre sí, pero cuando los LSP de TE se configuran utilizando computación distribuida realizada entre varios PCE, los problemas de sincronización y evitación de la condición de raza se vuelven más grandes y complejos.

  • La sincronización de bases de datos de ingeniería de tráfico fuera de banda puede ser compleja con varias PCE configuradas en un modelo de cálculo de PCE distribuido, y puede ser propensa a condiciones de carrera, problemas de escalabilidad, etc.

  • Los cálculos de rutas que incorporan el estado total de la red son muy complejos, incluso si el PCE tiene información detallada sobre todas las rutas, prioridades y capas.

A pesar de las preocupaciones anteriores, la implementación parcial del PCE con estado del lado del cliente es extremadamente efectiva en grandes sistemas de ingeniería de tráfico. Proporciona una convergencia rápida y beneficios significativos en términos de uso óptimo de recursos, al proporcionar el requisito de visibilidad global de un estado de TE LSP y de control ordenado de reservas de rutas en todos los dispositivos dentro del sistema que se está controlando.

Ejemplo: Configuración del protocolo de elemento de cálculo de ruta para MPLS RSVP-TE

En este ejemplo se muestra cómo habilitar la informática de rutas externas mediante un elemento de cálculo de ruta (PCE) para rutas de conmutación de etiquetas (LSP) de ingeniería de tráfico en un cliente de cálculo de ruta (PCC). También muestra cómo configurar el protocolo de elemento de cálculo de ruta (PCEP) en el PCC para habilitar la comunicación de PCE a PCC.

Requisitos

En este ejemplo, se utilizan los siguientes componentes de hardware y software:

  • Tres enrutadores que pueden ser una combinación de enrutadores serie ACX, enrutadores de borde multiservicio serie M, plataformas de enrutamiento universal 5G serie MX, enrutadores de núcleo serie T o enrutador de transporte serie PTX, uno de los cuales está configurado como PCC.

  • Una conexión TCP a un PCE externo con estado desde el PCC.

  • Junos OS versión 12.3 o posterior ejecutándose en el PCC junto con el paquete adicional JSDN.

Nota:

Es necesario instalar el paquete del complemento JSDN junto con el paquete de instalación principal de Junos OS.

Antes de empezar:

  1. Configure las interfaces del dispositivo.

  2. Configure MPLS y RSVP-TE.

  3. Configure IS-IS o cualquier otro protocolo IGP.

Descripción general

A partir de Junos OS versión 12.3, la funcionalidad MPLS RSVP-TE se amplía para proporcionar una implementación parcial del lado cliente de la arquitectura PCE con estado (draft-ietf-pce-stateful-pce) en un PCC.

Nota:

La implementación parcial del lado del cliente de la arquitectura PCE con estado se basa en la versión 2 del borrador de Internet draft-ietf-pce-stateful-pce. A partir de Junos OS versión 16.1, esta implementación se actualiza para admitir la versión 7, tal como se define en el borrador de Internet draft-ietf-pce-stateful-pce-07. Las versiones anteriores a la 16.1 admiten la versión anterior del borrador PCE, lo que provoca problemas de interoperabilidad entre un PCC que ejecuta una versión anterior y un servidor PCE con estado que se adhiere al borrador de Internet draft-ietf-pce-stateful-pce-07.

Para habilitar la computación de ruta externa por un PCE, incluya la instrucción en el PCC en los niveles jerárquico y .lsp-external-controller[edit mpls][edit mpls lsp lsp-name]

Un LSP configurado con la instrucción se denomina LSP controlado por PCE y está bajo el control externo de un PCE de forma predeterminada.lsp-external-controller Un PCE con estado activo puede anular los parámetros establecidos desde la CLI, como el ancho de banda, la ruta (ERO) y la prioridad, para dichos LSP controlados por PCE del PCC.

Para habilitar la comunicación de PCE a PCC, configure PCEP en el PCC en el nivel jerárquico .[edit protocols]

Al configurar PCEP en un PCC, tenga en cuenta las siguientes consideraciones:

  • Es necesario instalar el paquete del complemento JSDN junto con el paquete de instalación principal de Junos OS.

  • Junos OS versión 12.3 solo admite PCE con estado.

  • Un PCC puede conectarse a un máximo de 10 PCE con estado. En un momento dado, solo puede haber un PCE principal (el PCE con el valor de prioridad más bajo, o el PCE que se conecta primero al PCC en ausencia de una prioridad PCE) al que el PCC delega los LSP para el cálculo de la ruta.

  • Para Junos OS versión 12.3, el PCC siempre inicia las sesiones PCEP. Las sesiones de PCEP iniciadas por PCE remotas no son aceptadas por el PCC.

  • Las características existentes de LSP, como la protección LSP y hacer antes de romper, funcionan para LSP controlados por PCE.

  • La opción de ancho de banda automático está desactivada para los LSP controlados por PCE, aunque los LSP bajo el control del enrutamiento automático y basado en restricciones pueden coexistir con los LSP controlados por PCE.

  • Otras configuraciones de CLI pueden hacer referencia a los LSP controlados por PCE, como lsp-nexthop a rutas, adyacencias de reenvío, conexiones CCC y túneles lógicos.

  • Los LSP controlados por PCE no admiten GRES.

  • Los LSP controlados por PCE bajo sistemas lógicos no son compatibles.

  • Los LSP controlados por PCE no pueden ser LSP de punto a multipunto.

  • No se admiten LSP bidireccionales.

  • Los LSP controlados por PCE no pueden tener rutas secundarias sin una ruta principal.

  • Los LSP controlados por PCE dependen del cálculo de rutas externas, lo que afecta el tiempo general de configuración, las rerutas y las funciones de preparación antes de la interrupción.

  • El tiempo de configuración y el tiempo de convergencia (redireccionamiento, MBB) para los LSP existentes es el mismo que en versiones anteriores, en ausencia de LSP controlados por PCE. Sin embargo, se observa un pequeño impacto en presencia de LSP controlados por PCE.

  • Se espera que el tiempo de cálculo de ERO sea significativamente mayor que el CSPF local.

Topología

Figura 5: Configuración de PCEP para MPLS RSVP-TEConfiguración de PCEP para MPLS RSVP-TE

En este ejemplo, PCC es el enrutador de entrada que se conecta al PCE de estado activo externo.

Los LSP externos del PCC del enrutador se calculan de la siguiente manera:

  1. El PCC del enrutador recibe la configuración del túnel LSP que se configuró mediante la CLI. Suponiendo que la configuración recibida está habilitada con informática de ruta externa, el PCC del enrutador se da cuenta de que algunos de los atributos de LSP (ancho de banda, ruta y prioridad) están bajo el control del PCE con estado y delega el LSP al PCE.

    En este ejemplo, se llama al LSP externo y se está configurando desde el enrutador PCC al enrutador R2.PCC-to-R2 El ERO configurado por CLI es PCC-R0-R1-R2.PCC-to-R2 El ancho de banda para es de 10 m y tanto la configuración como los valores de prioridad de retención son 4.PCC-to-R2

  2. El PCC del enrutador intenta recuperar los atributos LSP controlados por PCE. Para ello, el PCC del enrutador envía un mensaje PCRpt al PCE con estado indicando que se ha configurado el LSP. El mensaje PCRpt comunica el estado del LSP y contiene los parámetros de configuración local del LSP.

  3. El PCE con estado modifica uno o varios de los atributos LSP delegados y envía los nuevos parámetros LSP al PCC del enrutador a través del mensaje PCUpd.

  4. Al recibir los nuevos parámetros LSP, el enrutador PCC configura un nuevo LSP y lo vuelve a señalar utilizando la ruta proporcionada por PCE.

    En este ejemplo, el ERO proporcionado por PCE para es PCC-R3-R2.PCC-to-R2 El ancho de banda para es de 8 m y los valores de prioridad de configuración y retención son 3.PCC-to-R2

  5. El PCC del enrutador envía un PCRpt con el nuevo RRO al PCE con estado.

Configuración

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, a continuación, copie y pegue los comandos en la CLI en el nivel de jerarquía.[edit]

PCC

R0

R1

R2

R3

Procedimiento

Procedimiento paso a paso

En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración.Usar el editor de CLI en el modo de configuración

Para configurar el enrutador PCC:

Nota:

Repita este procedimiento para cada enrutador de entrada de Juniper Networks en el dominio MPLS, después de modificar los nombres de interfaz, las direcciones y cualquier otro parámetro adecuados para cada enrutador.

  1. Configure las interfaces.

    Para habilitar MPLS, incluya la familia de protocolos en la interfaz para que la interfaz no descarte el tráfico MPLS entrante.

  2. Habilite RSVP en todas las interfaces del enrutador PCC, excluyendo la interfaz de administración.

  3. Configure la ruta de conmutación de etiquetas (LSP) del enrutador PCC al enrutador R2 y habilite el control externo de los LSP por parte del PCE.

  4. Configure el LSP del enrutador PCC al enrutador R2, que tiene control local y es reemplazado por los parámetros LSP proporcionados por PCE.

  5. Habilite MPLS en todas las interfaces del enrutador PCC, excluyendo la interfaz de administración.

  6. Configure IS-IS en todas las interfaces del enrutador PCC, excluyendo la interfaz de administración.

  7. Defina el PCE al que se conecta el PCC del enrutador y configure la dirección IP del PCE.

  8. Configure el puerto de destino para el PCC del enrutador que se conecta a un PCE mediante el PCEP basado en TCP.

  9. Configure el tipo de PCE.

Resultados

Desde el modo de configuración, escriba los comandos show interfaces y show protocols para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.

Verificación

Confirme que la configuración funcione correctamente.

Verificación del estado de la sesión PCEP

Propósito

Verifique el estado de la sesión PCEP entre el PCE y el PCC del enrutador cuando el estado PCE esté activo.

Acción

Desde el modo operativo, ejecute el comando.show path-computation-client active-pce

Significado

La salida muestra información sobre el PCE de estado activo actual al que está conectado el PCC del enrutador. El campo de salida indica el estado actual de la sesión PCEP entre el PCE y el PCC del enrutador.PCE status

Para , el estado de la sesión de PCEP es , lo que indica que la sesión de PCEP se ha establecido entre los pares de PCEP.pce1PCE_STATE_UP

Las estadísticas de indican el número de mensajes enviados por el enrutador PCC al PCE para informar del estado actual de los LSP.PCRpts Las estadísticas indican el número de mensajes recibidos por el enrutador PCC desde el PCE.PCUpdates Los mensajes incluyen los parámetros modificados por PCE para los LSP controlados por PCE.PCUpdates

Comprobación del estado de LSP controlado por PCE cuando el control LSP es externo

Propósito

Verifique el estado del LSP controlado por PCE del enrutador PCC al enrutador R2 cuando el LSP está bajo control externo.

Acción

Desde el modo operativo, ejecute el comando.show mpls lsp name PCC-to-R2 extensive

Significado

En la salida, los campos y de salida muestran que el LSP está controlado externamente.LSPtypeLSP Control Status La salida también muestra un registro de los mensajes PCEP enviados entre el enrutador PCC y el PCE.

La sesión de PCEP entre el PCE y el PCC del enrutador ha terminado, y el PCC del enrutador recibe los siguientes parámetros LSP controlados por PCE:

  • ERO (ruta): 20.31.4.2 y 20.31.5.2

  • Ancho de banda: 8 Mbps

  • Prioridades: 3 3 (valores de configuración y retención)

Comprobación del estado de LSP controlado por PCE cuando el control LSP es local

Propósito

Verifique el estado del LSP controlado por PCE del enrutador PCC al enrutador R2 cuando el control LSP se convierta en local.

Acción

Desde el modo operativo, ejecute el comando.show mpls lsp name PCC-to-R2 extensive

Significado

En la salida, el campo de salida muestra que el LSP está bajo control local.LSP Control Status Aunque el LSP controlado por PCE está bajo control local, el PCC del enrutador continúa utilizando los parámetros proporcionados por PCE, hasta la próxima oportunidad de volver a señalar el LSP.

El resultado ahora muestra los parámetros de LSP que se configuraron mediante la CLI junto con los parámetros proporcionados por PCE utilizados para establecer el LSP como los valores reales en uso.

  • Ancho de banda: 10 Mbps (ActualBandwidth: 8 Mbps)

  • Prioridades: 4 4 (Prioridades actuales 3 3)

En el disparador para volver a señalar el LSP, el PCC del enrutador utiliza los parámetros de configuración local para establecer el LSP controlado por PCE.

El es 20.31.1.2, 20.31.2.2 y 20.31.8.2.Computed ERO El LSP controlado por PCE se establece utilizando los parámetros de configuración local.

Ejemplo: Configuración del protocolo de elemento de cálculo de ruta para MPLS RSVP-TE con soporte de LSP punto a punto iniciados por PCE

En este ejemplo se muestra cómo configurar el cliente de cálculo de ruta (PCC) con la capacidad de admitir rutas de acceso conmutadas por etiquetas punto a punto (LSP) iniciadas por elementos de cálculo de ruta (PCE).

Requisitos

En este ejemplo, se utilizan los siguientes componentes de hardware y software:

  • Tres enrutadores que pueden ser una combinación de enrutadores serie ACX, serie M, serie MX o serie T.

  • Una conexión TCP a dos PCE con estado externas desde el enrutador de entrada (PCC).

  • Junos OS versión 16.1 o posterior ejecutándose en el PCC.

Antes de empezar:

  • Configure las interfaces del dispositivo.

  • Configure MPLS y RSVP-TE (ingeniería de tráfico RSVP).

  • Configure OSPF o cualquier otro protocolo IGP.

Descripción general

A partir de Junos OS versión 16.1, la funcionalidad PCEP se amplía para permitir que un PCE con estado inicie y aprovisione LSP de ingeniería de tráfico a través de un PCC. Anteriormente, los LSP se configuraban en el PCC y el PCC delegaba el control sobre los LSP externos a un PCE. La propiedad del estado LSP fue mantenida por el PCC. Con la introducción de los LSP iniciados por PCE, un PCE puede iniciar y aprovisionar un LSP punto a punto de ingeniería de tráfico dinámicamente sin la necesidad de un LSP configurado localmente en el PCC. Al recibir un mensaje PCCreate de un PCE, el PCC crea el LSP iniciado por PCE y delega automáticamente el LSP al PCE.

Al configurar la compatibilidad de LSP punto a punto iniciados por PCE para un PCC, tenga en cuenta las siguientes consideraciones:

  • Junos OS versión 13.3 solo admite PCE con estado.

  • Para Junos OS versión 13.3, el PCC siempre inicia las sesiones PCEP. Las sesiones de PCEP iniciadas por PCE remotas no son aceptadas por el PCC.

  • Las características existentes de LSP, como la protección LSP y hacer antes de romper, funcionan para LSP iniciados por PCE.

  • Los LSP iniciados por PCE no admiten el cambio de motor de enrutamiento (GRES) correcto.

  • No se admiten LSP iniciados por PCE en sistemas lógicos.

  • Los LSP iniciados por PCE no pueden ser LSP de punto a multipunto.

  • No se admiten LSP bidireccionales.

  • No se admite RSVP-TE para enlaces no numerados. Los LSP iniciados por PCE solo admiten enlaces numerados.

  • El PCE que inicia un LSP de enrutamiento de segmento puede usar las etiquetas de ID de segmento de enlace (SID) asociadas con los LSP de enrutamiento de segmentos no coloreados para aprovisionar las rutas de LSP de enrutamiento de segmentos iniciadas por PCE.

    A partir de Junos OS versión 18.2R1, los LSP de enrutamiento de segmentos no coloreados configurados estáticamente en el dispositivo de entrada se notifican a un PCE a través de una sesión PCEP. Estos LSP de enrutamiento de segmentos no coloreados pueden tener etiquetas SID de enlace asociadas. Con esta característica, el PCE puede usar esta etiqueta SID de enlace en la pila de etiquetas para aprovisionar rutas LSP de enrutamiento de segmentos iniciadas por PCE.

Topología

Figura 6: Ejemplo de LSP punto a punto iniciado por PCE para MPLS RSVP-TEEjemplo de LSP punto a punto iniciado por PCE para MPLS RSVP-TE

En este ejemplo, PCC es el enrutador de entrada que se conecta a dos PCE de estado externas: PCE1 y PCE2.

Cuando hay una nueva demanda, el PCE con estado activo inicia dinámicamente un LSP para cumplir con el requisito. Dado que PCC está configurado con la capacidad de admitir el LSP iniciado por PCE, el cálculo de la ruta en PCC se realiza de la siguiente manera:

  1. Un PCE envía un mensaje PCCreate al PCC para iniciar y aprovisionar un LSP. El PCC configura el LSP iniciado por PCE utilizando los parámetros recibidos del PCE, y delega automáticamente el LSP iniciado por PCE al PCE que lo inició.

    En este ejemplo, PCE1 es el PCE de estado activo que inicia y aprovisiona el LSP iniciado por PCE en PCC. Al recibir los parámetros LSP iniciados por PCE, PCC configura el LSP y delega automáticamente el LSP iniciado por PCE a PCE1.

  2. Cuando finaliza la sesión PCEP entre PCC y PCE1, PCC inicia dos temporizadores para el LSP iniciado por PCE1: tiempo de espera de limpieza de delgation y el temporizador de limpieza de LSP. Durante este tiempo, PCE1 o PCE2 pueden adquirir el control del LSP iniciado por PCE.

  3. Si PCE2 adquiere el control sobre el LSP iniciado por PCE antes de que expire el temporizador de limpieza de LSP, PCC delega el LSP iniciado por PCE a PCE2, y el temporizador de limpieza de LSP y el tiempo de espera de limpieza de delegación se detienen.

  4. Si expiró el tiempo de espera de limpieza de la delegación y ni PCE1 ni PCE2 adquirieron el control sobre el LSP iniciado por PCE, PCC toma el control local del LSP iniciado por PCE no delegado hasta el vencimiento del temporizador de limpieza de LSP.

  5. Después de la expiración del temporizador de limpieza de LSP, PCC elimina el LSP iniciado por PCE aprovisionado por PCE1.

Configuración

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, a continuación, copie y pegue los comandos en la CLI en el nivel de jerarquía.[edit]

PCC

R1

R2

Procedimiento

Procedimiento paso a paso

En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración.Usar el editor de CLI en el modo de configuración

Para configurar el enrutador PCC:

Nota:

Repita este procedimiento para cada enrutador de entrada de Juniper Networks en el dominio MPLS, después de modificar los nombres de interfaz, las direcciones y cualquier otro parámetro adecuados para cada enrutador.

  1. Configure las interfaces.

    Para habilitar MPLS, incluya la familia de protocolos en la interfaz para que la interfaz no descarte el tráfico MPLS entrante.

  2. Habilite RSVP en todas las interfaces del PCC, excluyendo la interfaz de administración.

  3. Habilite el control externo de los LSP por parte de los PCE.

  4. Habilite MPLS en todas las interfaces del PCC, excluyendo la interfaz de administración.

  5. Configure OSPF en todas las interfaces del PCC, excluyendo la interfaz de administración.

  6. Defina el grupo PCE y habilite la compatibilidad de LSP iniciados por PCE para el grupo PCE.

  7. Defina las PCE que se conectan al PCC.

Resultados

Desde el modo de configuración, escriba los comandos show interfaces y show protocols para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.

Verificación

Confirme que la configuración funcione correctamente.

Verificación del estado del PCC

Propósito

Verifique el estado de la sesión de PCEP y el resumen de LSP entre el PCC y los PCE conectados.

Acción

Desde el modo operativo, ejecute el comando.show path-computation-client status

Significado

El resultado muestra el estado de la sesión de PCEP entre las PCE con estado activas y el PCC. También muestra información sobre los diferentes tipos de LSP en el PCC y el número de LSP aprovisionados por los PCE conectados y delegados a ellos.

PCE1 es el PCE activo principal y tiene un LSP iniciado por PCE que le ha sido delegado automáticamente por el PCC.

Verificación del estado de PCE1

Propósito

Verifique el estado de la PCE de estado activa principal.

Acción

Desde el modo operativo, ejecute el comando.show path-computation-client active-pce detail

Significado

La salida muestra información sobre el PCE con estado activo actual al que está conectado el PCC. El campo de salida indica el estado actual de la sesión de PCEP entre un PCE y un PCC.PCE status

Para PCE1, el estado de la sesión de PCEP es , lo que indica que la sesión de PCEP se ha establecido con el PCC.PCE_STATE_UP

Comprobación del estado del LSP iniciado por PCE cuando el LSP está aprovisionado externamente

Propósito

Verifique el estado del LSP iniciado por PCE.

Acción

Desde el modo operativo, ejecute el comando.show mpls lsp externally-provisioned detail

Significado

En la salida, el campo de salida muestra que el LSP está aprovisionado externamente.LSPtype

La sesión de PCEP entre PCC y PCE1 ha terminado, y el PCC recibe los siguientes parámetros LSP iniciados por PCE:

  • ERO (ruta): 10.0.102.10 y 10.0.101.9

  • Ancho de banda: 8 Mbps

  • Prioridad: 7 0 (valores de configuración y retención)

Configuración del protocolo de elemento de cálculo de ruta para MPLS RSVP-TE con soporte de LSP punto a punto iniciados por PCE

Puede configurar un cliente de cálculo de rutas (PCC) con la capacidad de admitir rutas conmutadas de etiquetas (LSP) creadas dinámicamente desde una entidad informática de ruta externa centralizada. Se puede usar un elemento de computación de ruta con estado (PCE) para realizar cálculos de rutas externas y generar LSP dinámicos cuando hay un aumento de la demanda.

Un PCC crea el LSP punto a punto iniciado por PCE utilizando los parámetros LSP proporcionados por PCE, o parámetros de una plantilla LSP preconfigurada cuando el PCE no aprovisiona el LSP, y delega automáticamente el LSP punto a punto iniciado por PCE al PCE respectivo. Como resultado, para los LSP iniciados por PCE, no hay necesidad de un LSP configurado localmente en el PCC.

Un LSP controlado por CLI, un LSP controlado por PCE y un LSP iniciado por PCE pueden coexistir entre sí en un PCC.

Antes de empezar:

  • Configure las interfaces del dispositivo.

  • Configure MPLS y RSVP-TE.

  • Configure OSPF o cualquier otro protocolo IGP.

Para configurar PCC para que admita LSP punto a punto iniciados por PCE, realice las siguientes tareas:

  1. En el modo de configuración, vaya al siguiente nivel de jerarquía:
  2. Especifique el número de mensajes por minuto que el PCC puede recibir como máximo.
  3. Especifique el número de rutas conmutadas de etiquetas (LSP) aprovisionadas externamente en todos los PCE conectados que el PCC puede aceptar como máximo.
  4. Especifique el ID único definido por el usuario para la PCE conectada para configurar los parámetros PCE.
  5. Especifique la cantidad de tiempo (en segundos) que el PCC debe esperar antes de devolver el control de los LSP al proceso del protocolo de enrutamiento después de desconectar una sesión PCEP.
  6. Especifique la dirección IPv4 del PCE con el que desea conectarse.
  7. Especifique el número de puerto TCP que utiliza el PCE

    El valor puede oscilar entre 1 y 65535 y el valor predeterminado es 4189.

  8. Especifique la cantidad de tiempo (en segundos) que el PCC debe esperar antes de eliminar cualquier LSP iniciado por PCE no delegado del PCE fallido después de que finalice una sesión de PCEP.
  9. Configure el PCC para que acepte proveedores de servicios aprovisionados externamente por PCE conectadas. De forma predeterminada, el PCC rechaza los LSP iniciados por PCE.
  10. Especifique el número de mensajes desconocidos por minuto que el PCC puede recibir como máximo después de lo cual se cierra la sesión de PCEP.

    El valor puede oscilar entre 1 y 16384, y el valor predeterminado es 0 (deshabilitado o sin límite).

  11. Especifique el número de solicitudes desconocidas por minuto que el PCC puede recibir como máximo después de lo cual finaliza la sesión PCEP.

    El valor puede oscilar entre 0 y 16384 y el valor predeterminado es 5. Un valor de 0 deshabilita esta instrucción.

  12. Configure el tipo de PCE.
  13. Especifique la cantidad de tiempo (en segundos) que el PCC debe esperar una respuesta antes de volver a enviar una solicitud.

    El valor puede oscilar entre 0 y 65535 segundos.

  14. Compruebe y confirme la configuración.

Salida de muestra

Ejemplo: Configuración del protocolo de elemento de cálculo de ruta para MPLS RSVP-TE con soporte para LSP de punto a multipunto controlados por PCE

En este ejemplo se muestra cómo configurar el cliente de cálculo de ruta (PCC) con la capacidad de notificar rutas de conmutación de etiquetas (LSP) de ingeniería de tráfico punto a multipunto (LSP) a un elemento de cálculo de ruta (PCE).

Requisitos

En este ejemplo, se utilizan los siguientes componentes de hardware y software:

  • Tres enrutadores que pueden ser una combinación de enrutadores serie ACX, serie M, serie MX o serie T.

  • Una máquina virtual configurada con la función Virtual Route Reflector (VRR).

  • Una conexión TCP a un PCE externo con estado desde el VRR.

  • Junos OS versión 16.1 o posterior ejecutándose en el PCC.

Antes de empezar:

  • Configure las interfaces del dispositivo.

  • Configure MPLS y RSVP-TE.

  • Configure OSPF o cualquier otro protocolo IGP.

Descripción general

Después de establecer una sesión de PCEP entre un PCE y un PCC, el PCC informa todos los LSP del sistema al PCE para la sincronización del estado del LSP. Esto incluye los LSP punto a punto controlados por PCC, delegados por PCE e iniciados por PCE. A partir de Junos OS versión 15.1F6 y 16.1R1, esta capacidad se amplía para informar también de LSP punto a multipunto.

De forma predeterminada, el control PCE de LSP punto a multipunto no se admite en un PCC. Para agregar esta capacidad, incluya la instrucción en los niveles de jerarquía o .p2mp-lsp-report-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id]

Topología

Figura 7: Ejemplo de LSP punto a multipunto controlados por PCEEjemplo de LSP punto a multipunto controlados por PCE

En este ejemplo, PCC es el enrutador de entrada, el enrutador R1 es el enrutador de tránsito y el enrutador R2 es el enrutador de salida. PCC está conectado a un reflector de ruta virtual (VRR) que está conectado a un PCE. Hay muchas interfaces punto a multipunto entre PCC, el enrutador R1 y el enrutador R2.

La notificación de los LSP punto a multipunto se ejecuta de la siguiente manera:

  1. Si el PCC del enrutador está configurado con LSP punto a punto y punto a multipunto sin la compatibilidad con la capacidad de generación de informes punto a multipunto, solo los LSP punto a punto se informan al PCE conectado. De forma predeterminada, un PCC no admite la capacidad de generación de informes LSP punto a multipunto.

  2. Cuando el enrutador PCC está configurado con la capacidad de generación de informes LSP punto a multipunto, PCC primero anuncia esta capacidad a PCE a través de un mensaje de informe.

  3. De forma predeterminada, un PCE proporciona compatibilidad con la capacidad de LSP punto a multipunto. Al recibir el anuncio del PCC para la capacidad de LSP punto a multipunto, el PCE a cambio anuncia su capacidad al PCC.

  4. Al recibir el anuncio del PCE de la capacidad punto a multipunto, PCC informa todas las ramas de LSP punto a multipunto al PCE utilizando el mensaje de actualización.

  5. Una vez que todos los LSP se notifican al PCE, el estado de LSP se sincroniza entre el PCE y el PCC.

Configuración

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, a continuación, copie y pegue los comandos en la CLI en el nivel de jerarquía.[edit]

PCC

R1

R2

R3

Procedimiento

Procedimiento paso a paso

En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración.Usar el editor de CLI en el modo de configuración

Para configurar el enrutador PCC:

  1. Configure las interfaces del enrutador PCC. Para habilitar MPLS, incluya la familia de protocolos en la interfaz para que la interfaz no descarte el tráfico MPLS entrante.

  2. Configure el número de sistema autónomo para el enrutador PCC.

  3. Habilite RSVP en todas las interfaces del enrutador PCC, excluyendo la interfaz de administración.

  4. Habilite MPLS en todas las interfaces del enrutador PCC, excluyendo la interfaz de administración.

  5. Configure un LSP dinámico y deshabilite el cálculo automático de rutas para el LSP.

  6. Configure LSP punto a multipunto y defina una entidad de informática de ruta externa para el LSP.

  7. Habilite la informática de ruta externa para los LSP MPLS y asigne una plantilla para los LSP aprovisionados externamente.

  8. Configure los LSP que tienen control local y son reemplazados por los parámetros LSP proporcionados por PCE.

  9. Configure las directivas de grupo administrativo de MPLS para el cálculo de LSP de ruta restringida.

  10. Asigne las directivas de grupo administrativas configuradas a las interfaces PCC del enrutador.

  11. Configure una política de importación de bases de datos de ingeniería de tráfico (TED).

  12. Configure un grupo interno de BGP.

  13. Configure la ingeniería de tráfico para BGP y asigne la política de exportación.

  14. Configure el área 0 de OSPF en todas las interfaces punto a multipunto del PCC del enrutador.

  15. Configure el área 0 de OSPF en la interfaz punto a punto del PCC del enrutador.

  16. Habilite la ingeniería de tráfico para OSPF.

  17. Defina el PCE al que se conecta el PCC del enrutador y configure los parámetros PCE.

  18. Configure el PCC del enrutador para habilitar la capacidad de LSP punto a multipunto para la computación de ruta externa.

  19. Configure la directiva de ingeniería de tráfico.

Resultados

Desde el modo de configuración, escriba los comandos show interfaces y show protocols para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Verificación

Confirme que la configuración funcione correctamente.

Verificación de la configuración de LSP en el PCC

Propósito

Compruebe el tipo de LSP y el estado de ejecución del LSP punto a multipunto.

Acción

Desde el modo operativo, ejecute el comando.show mpls lsp extensive

Significado

La salida muestra el LSP lsp2-pcc como el LSP controlado por PCE.

Verificación de la configuración de PCE en el PCC

Propósito

Compruebe la configuración de los parámetros PCE y el estado de PCE.

Acción

Desde el modo operativo, ejecute el comando.show path-computation-client active-pce

Significado

La salida muestra el PCE activo al que está conectado el PCC del enrutador y los parámetros y el estado de PCE pce1.

Descripción del protocolo de elemento de cálculo de ruta para MPLS RSVP-TE con soporte para LSP punto a multipunto iniciados por PCE

Con la introducción de los LSP iniciados por PCE punto a multipunto, un PCE puede iniciar y aprovisionar un LSP punto a multipunto dinámicamente sin la necesidad de una configuración de LSP local en el PCC. Esto permite que el PCE controle la temporización y la secuencia de los cálculos de ruta punto a multipunto dentro y entre las sesiones del Protocolo de elemento de cálculo de ruta (PCEP), creando así una red dinámica que se controla y despliega de forma centralizada.

Beneficios de los LSP punto a multipunto iniciados por PCE

Cumple con los requisitos de colocación de LSP de ingeniería de tráfico punto a multipunto en respuesta a las demandas de las aplicaciones mediante la creación y el desmontaje dinámicos de LSP de punto a multipunto, creando así una red dinámica que se controla y despliega de forma centralizada.

Señalización de LSP punto a multipunto iniciados por PCE

La señalización de los LSP punto a multipunto iniciados por PCE es la siguiente:

  • When a new branch is added (Grafting): sólo se señaliza el nuevo sub-LSP de rama y no da como resultado la reseñalización de todo el árbol de punto a multipunto.

    Si se produjo algún cambio de topología antes del aprovisionamiento del nuevo sub-LSP, el servidor de cálculo de ruta (PCS) vuelve a calcular todo el árbol de punto a multipunto y actualiza el LSP de punto a multipunto mediante un mensaje de actualización de PC.

  • When a branch is deleted (Pruning): el sub-LSP de rama eliminado se desmonta y no da como resultado la reseñalización de todo el árbol de punto a multipunto.

  • When a branch sub-LSP parameter is changed: el cambio en los parámetros sub-LSP, como el objeto de ruta explícito (ERO), el ancho de banda o la prioridad, puede ocurrir debido a la optimización o a petición del usuario. Si hay una solicitud de reseñalización para un subLSP, se vuelve a señalar todo el árbol de punto a multipunto y, a continuación, se produce el cambio a la nueva instancia una vez que las nuevas instancias de todas las ramas estén activas.

  • When a branch sub-LSP path fails: se notifica un error al PCS para el sub-LSP de rama fallido. Al recibir el nuevo ERO del PCS, se vuelve a señalar todo el árbol de punto a multipunto junto con el sub-LSP de rama fallido, y el cambio a la nueva instancia se produce de forma innovadora (MBB).

Comportamiento de los LSP punto a multipunto iniciados por PCE después de una falla de sesión PCEP

Cuando se produce un error en una sesión de PCEP, los LSP punto a multipunto iniciados por PCE quedan huérfanos hasta la expiración del temporizador.state timeout Después de que expira el temporizador, se limpian los LSP iniciados por PCE.state timeout

Para obtener el control de un LSP punto a multipunto iniciado por PCE después de una falla en la sesión de PCEP, el PCE primario o secundario envía un mensaje antes de que caduque el temporizador.PCInitiatestate timeout

Configuración de la capacidad de LSP punto a multipunto iniciada por PCE

De forma predeterminada, la creación y el aprovisionamiento de LSP punto a multipunto por parte de un PCE no se admite en un PCC. Para habilitar esta capacidad, incluya las instrucciones y en los niveles de jerarquía o .p2mp-lsp-init-capabilityp2mp-lsp-update-capability[edit protocols pcep pce pce-name][edit protocols pcep pce-group group-id]

La instrucción proporciona la capacidad de aprovisionar LSP RSVP-TE punto a multipunto mediante un PCE.p2mp-lsp-init-capability La instrucción proporciona la capacidad de actualizar los parámetros LSP RSVP-TE punto a multipunto mediante un PCE.p2mp-lsp-update-capability

Características admitidas y no compatibles para LSP punto a multipunto iniciados por PCE

Los LSP de punto a multipunto iniciados por PCE admiten las siguientes características:

  • Cumplimiento parcial del borrador de Internet draft-ietf-pce-stateful-pce-p2mp (expira en octubre de 2018), extensiones de protocolo de elemento de cálculo de ruta (PCE) para el uso de PCE con estado para rutas conmutadas de etiquetas de ingeniería de tráfico punto a multipunto.

  • A partir de Junos OS versión 21.1R1, admitimos el enrutamiento activo sin paradas (NSR) para los LSP punto a multipunto basados en RSVP iniciados por PCE. Solo el motor de enrutamiento principal mantiene la sesión PCEP con el controlador. Sincroniza todos los LSP de RSVP iniciados por PCE, incluidas las especificaciones de flujo de multidifusión para cualquier LSP P2MP iniciado por PCE, con el motor de enrutamiento de respaldo. Durante un cambio, la sesión PCEP deja de funcionar y se restablece cuando el motor de enrutamiento de reserva se convierte en el motor de enrutamiento principal. Esto reduce la pérdida de tráfico para el tráfico transportado a través de los LSP de RSVP iniciados por PCE durante los cambios de motor de enrutamiento. Esta función se habilita cuando se configura NSR.

Las siguientes características no son compatibles con los LSP punto a multipunto iniciados por PCE:

  • Delegación de LSP de punto a multipunto controlado localmente.

  • Delegación de control LSP.

  • Extensión del protocolo de puerta de enlace interior (IGP) para la detección de PCE dentro de un dominio de enrutamiento IGP.

  • Mensajes de solicitud/respuesta.

  • Movimiento directo de la rama sub-LSP de un árbol de punto a multipunto a otro.

    Lo mismo se puede lograr eliminando una rama sub-LSP del primer árbol de punto a multipunto y volviéndola a agregarla a otra después de que el mensaje indique la eliminación de LSP del dispositivo.PCReport

  • IPv6 no es compatible.

  • No se admite la señalización basada en SERO.

  • La función Empty-ERO no es compatible.

  • No se admite la protección de vínculos.

Asignación de LSP de punto a multipunto iniciados por PCE a MVPN

Puede asociar uno o un rango de flujos de multidifusión MVPN (S,G) a una ruta de conmutación de etiquetas (LSP) de punto a multipunto iniciada por PCE creada dinámicamente. Solo puede especificar tipos selectivos de flujos para que esta característica funcione. entre las que se incluyen las siguientes:

  • Distinguidor de ruta (RD) que se asigna a la instancia de enrutamiento MVPN.

  • (S,G) que es el origen de un paquete de multidifusión y la dirección del grupo de multidifusión de destino. Esto se utiliza para filtrar el tráfico entrante y asignarlo al túnel.

  • LSP de punto a multipunto que se utiliza para enviar tráfico que coincide con la especificación de flujo mencionada anteriormente.

Para obtener más información, consulte Internet draft draft-ietf-pce-pcep-flowspec-05 (caduca el 16 de febrero de 2020) Extensión PCEP para especificación de flujo.

La implementación actual de esta característica no implementa las siguientes secciones del borrador:

  • Sección 3.1.2—Publicidad de las capacidades de PCE en el IGP

  • Sección 3.2—Mensaje de PCReq y PCRep

  • Sección 7: La mayoría de las especificaciones de flujo, excepto la distinción de rutaLa implementación actual de esta función no admite las especificaciones de flujo de multidifusión IPv4.

Para habilitar la asignación de LSP punto a multipunto iniciados por PCE a MVPN:

  • Incluya la instrucción en el nivel jerárquico para indicar la compatibilidad con la capacidad de especificación de flujo (también denominada dirección de tráfico) por parte del PCC.pce_traffic_steering[edit protocols pcep pce pce-id]

  • Incluya la instrucción en el nivel jerárquico.external-controller[edit routing-instances routing-instance-name provider-tunnel]

    La presencia de en la configuración del túnel de proveedor para MVPN indica que el controlador externo puede proporcionar el LSP punto a multipunto y (S,G) para esta instancia de MVPN.external-controller Esto permite al controlador externo configurar dinámicamente (S,G) y LSP punto a multipunto para MVPN.

Tenga en cuenta lo siguiente para asignar LSP punto a multipunto iniciados por PCE a MVPN:

  • Si no habilita la instrucción para una instancia de MVPN determinada, el proceso PCCD no se configura (S,G) dinámicamente.external-controller pccd

  • Si deshabilita la configuración desde la CLI, los flujos de multidifusión aprendidos dinámicamente (S,G) para esa instancia de MVPN en particular se eliminan y se notifican al controlador externo.external-controller pccd

  • Cuando (S,G) ya está configurado desde la CLI, el PCC no puede configurar (S,G) dinámicamente, ya que la configuración local tiene una prioridad mayor.

  • Si se aprende dinámicamente algo en particular (S,G) del controlador externo y luego se configura el mismo (S,G) para la misma instancia de MVPN, el aprendida dinámicamente (S,G) se elimina y se informa al controlador externo a través del PCC.

  • Si el proceso de protocolo de enrutamiento se reinicia, el proceso PCCD vuelve a configurar todas las (S,G).

  • Si el proceso PCCD se reinicia, MVPN notifica todo el PCCD configurado (S,G) al controlador externo.

  • Si el usuario habilita para una instancia de MVPN determinada, MVPN solicita al proceso PCCD que configure (S,G), si lo hay.external-controller pccd

  • Si hay cambios importantes en la configuración de una instancia de MPVN determinada, MVPN solicita al proceso PCCD que vuelva a configurar todas (S,G) para esa instancia de MVPN en particular.

  • Todas las especificaciones de flujo asociadas con cualquier LSP punto a multipunto iniciado por PCE deben tener el mismo RD. Durante el inicio de PC, si todas las especificaciones de flujo no tienen el mismo RD, el mensaje de inicio de PC se elimina con un error.

  • Puede asociar un LSP de punto a multipunto solo con un tipo selectivo de especificaciones de flujo; de lo contrario, el mensaje de inicio de PC se deja caer con un error.

  • Durante la actualización de PC, si todas las especificaciones de flujo no tienen el mismo RD, ya sea debido a una nueva adición de especificación de flujo o debido a una actualización de especificación de flujo existente, el PCC elimina el mensaje de actualización.

  • Durante la actualización de PC, si todas las especificaciones de flujo no cumplen con la condición selectiva, ya sea debido a la adición de una nueva especificación de flujo o debido a una actualización de especificaciones de flujo existente, el PCC elimina el mensaje de actualización.

  • El comportamiento para la asignación de LSP punto a multipunto iniciado por PCE con instancia de enrutamiento MVPN y la asignación de LSP estático (configurado localmente) de punto a multipunto con instancia MVPN es el mismo a nivel de usuario.

  • Un ID de especificación de flujo solo se puede asociar con un LSP de punto a multipunto. Para asociar el mismo RD y (S,G) a varios LSP punto a multipunto, puede agregar varias especificaciones de flujo con diferentes ID y el mismo RD & (S,G).

  • Para la dinámica asignada a PCEP (S,G), el valor umbral es siempre el valor predeterminado de .0

  • No hay límite en el número de especificaciones de flujo asignadas a un único LSP punto a multipunto iniciado por PCE.

  • La implementación actual de esta característica no admite:

    • Informes de los estados de reenvío asociados al LSP de punto a multipunto.

    • Configuración dinámica de túnel de proveedor inclusiva

    • Asignación para túnel de replicación de entrada MVPN

    • Proceso de protocolo de enrutamiento programable (prpd)

    • Informes de LSP punto a multipunto configurado por la CLI que se asigna a flujos de multidifusión MVPN (S,G).

Habilitar el enrutamiento de segmentos para el protocolo de elemento de cálculo de ruta

SUMMARY Puede habilitar el enrutamiento por segmentos o la ingeniería de tráfico del enrutamiento de paquetes fuente en redes (SPRING) (SR-TE) con el protocolo de elemento de cálculo de ruta (PCEP) para la dirección del tráfico. Con este soporte, las ventajas del enrutamiento de segmentos se extienden a las rutas conmutadas por etiquetas (LSP) que son controladas externamente por un elemento de cálculo de ruta (PCE).

Información general sobre el enrutamiento por segmentos para el protocolo de elemento de cálculo de ruta

Beneficios del enrutamiento por segmentos para PCEP

  • La configuración de LSP a través de un controlador externo proporciona una vista global de la demanda de ancho de banda por LSP y por dispositivo en la red, lo que permite el cálculo de rutas en línea y basado en restricciones en tiempo real.

    Las ventajas del enrutamiento de segmentos se extienden a los LSP iniciados por un controlador externo, también conocido como elemento de cálculo de ruta (PCE), lo que aumenta los beneficios de la computación de ruta externa en una red MPLS.

  • Un cliente de cálculo de ruta (PCC, que es un enrutador de la serie MX de entrada) con capacidad de delegación puede recuperar el control de los LSP de enrutamiento de segmentos delegados desde el PCE cuando la sesión PCEP deja de funcionar; de lo contrario, los LSP se eliminarían del PCC. Por lo tanto, puede garantizar la protección de datos de LSP evitando una situación en la que los paquetes se descarten o descarten silenciosamente (también conocida como condición de ruta nula).

Enrutamiento por segmentos para ingeniería de tráfico

El enrutamiento por segmentos puede operar sobre un plano de datos IPv4 o IPv6 y admite múltiples rutas de igual costo (ECMP). Con las extensiones IGP integradas, el enrutamiento de segmentos se integra con las ricas capacidades multiservicio de MPLS, incluidas VPN de capa 3, servicio de cable privado virtual (VPWS), servicio de LAN privada virtual (VPLS) y VPN de Ethernet (EVPN).

Algunos de los componentes de alto nivel de la solución de ingeniería de tráfico de enrutamiento por segmentos (SR-TE) incluyen:

  • Uso de un IGP para las características de los enlaces publicitarios. Esta funcionalidad es similar a RSVP-TE.

  • Uso de la ruta más corta restringida primero (CSPF) en el dispositivo de entrada o el PCE.

  • Uso de un IGP para etiquetas publicitarias de enlaces.

    En la funcionalidad SR-TE:

    1. El dispositivo de entrada construye un LSP apilando las etiquetas de los vínculos que desea atravesar.

    2. El anuncio IGP por vínculo se combina con el apilamiento de etiquetas para crear LSP enrutados en origen en el dispositivo de entrada, por lo que los dispositivos de tránsito no son conscientes de los LSP de extremo a extremo.

    3. Los LSP se crean entre nodos de borde sin colocar ningún requisito de memoria por LSP en los dispositivos de tránsito. (La creación de dichos LSP está habilitada porque no hay señalización por LSP en SR-TE).

    4. Las etiquetas por vecino se apilan, lo que da como resultado la administración de un gran número de etiquetas, lo que lleva a la escala del plano de control.

Implementación de Junos OS del enrutamiento por segmentos para PCEP

Junos OS implementa el enrutamiento por segmentos para PCEP para dos tipos de LSP: los LSP iniciados por PCE y los LSP delegados por PCE.

LSP de enrutamiento por segmentos iniciado por PCE

Los LSP de enrutamiento de segmentos iniciados por PCE son aquellos LSP que el PCE crea para los segmentos de adyacencia y nodo

El PCE realiza las siguientes funciones:

  1. Calcula la ruta del LSP de enrutamiento de segmentos.

  2. Aprovisiona el LSP en el cliente de cálculo de ruta (PCC) mediante extensiones de enrutamiento de segmento PCEP.

  3. Analiza las extensiones de enrutamiento del segmento PCEP.

  4. Crea una ruta de túnel en el PCC que tiene su propio valor de preferencia y está disponible en la tabla de enrutamiento inet.3 para resolver el tráfico IP y los servicios como cualquier otra ruta de túnel.

El PCC realiza las siguientes funciones:

  1. Selecciona la interfaz de salida según el primer identificador de acceso a la red (NAI) del objeto de ruta explícito (S-ERO) de origen.

    Junos OS admite S-EROO que contienen el primer salto como un salto estricto; Junos OS no admite la selección de la interfaz de salida en el PCC en función de un ID de segmento de nodo (SID) de salto suelto. Sin embargo, los lúpulos restantes pueden estar sueltos. No se realiza ningún procesamiento específico para los S-ERO que están más allá del primer salto, aparte de simplemente usar la etiqueta para la creación del próximo salto.

  2. Rechaza el S-ERO si:

    • El S-ERO no tiene etiquetas.

    • El S-ERO lleva más de seis lúbolos.

    El PCC crea una ruta múltiple de igual costo (ECMP) cuando hay varios LSP al mismo destino con la misma métrica.

  3. Espera a que el PCE procese cualquier evento que conduzca a un cambio en el LSP de enrutamiento del segmento después de aprovisionarlo, por ejemplo, si se cambia o retira la etiqueta, o si una de las interfaces atravesadas por el LSP deja de funcionar.

Cuando la sesión PCEP deja de funcionar, el LSP de enrutamiento de segmentos iniciado por PCE:

  1. Permanece activo durante 300 segundos.

  2. Se elimina del PCC después de 300 segundos.

Para obtener más detalles, consulte Borradores de Internet draft-ietf-pce-lsp-setup-type-03.txt (caduca el 25 de diciembre de 2015), Conveying path setup type in PCEP messages; y draft-ietf-pce-segment-routing-06.txt (expira el 10 de febrero de 2016), PCEP Extensions for Segment Routing.

LSP de enrutamiento por segmentos delegado por PCE

Los LSP de enrutamiento de segmento delegado por PCE son aquellos LSP que el PCC configura localmente y luego delega a un controlador PCE.

Nota:

Junos OS versión 20.1R1 admite:

  • Capacidad de delegación PCE solo para LSP de enrutamiento de segmentos no coloreados con destinos IPv4.

  • Delegación e informe de solo el primer segmento de una lista de segmentos a un controlador externo. No se admiten varios segmentos para la delegación PCE.

El PCC puede delegar un LSP de enrutamiento de segmento a un controlador externo (el PCE) de las siguientes maneras:

  • Initial delegation: los LSP locales aún no se han configurado en el PCC y la delegación del LSP ocurre en el momento en que se configura el LSP.

  • Delegation of existing LSP: los LSP locales se configuran en el PCC y la delegación del LSP tiene lugar después de configurar la ruta de enrutamiento de origen. Es decir, la capacidad de delegación está habilitada en los LSP de enrutamiento de segmentos existentes.

Después de delegar un LSP de enrutamiento de segmento, el PCE controla los LSP delegados y puede modificar los atributos LSP para calcular la ruta. El control LSP vuelve al PCC cuando la sesión de PCEP entre el PCC y el PCE deja de funcionar. Los LSP delegados por PCE tienen una ventaja sobre los LSP iniciados por PCE en caso de que la sesión de PCEP se caiga. En el caso de los LSP iniciados por PCE, cuando la sesión de PCEP está inactiva, los LSP se eliminan del PCC. Sin embargo, en el caso de los LSP delegados por PCE, cuando la sesión de PCEP deja de funcionar, el PCC recupera el control de los LSP delegados del PCE. Como resultado, con los LSP delegados por PCE, evitamos una situación en la que los paquetes se descartan silenciosamente (también conocida como condición de ruta nula) cuando la sesión deja de funcionar.

Los siguientes tipos de LSP de enrutamiento de segmentos admiten la capacidad de delegación PCE:

  • Static LSPs: rutas de enrutamiento de origen configuradas estáticamente que tienen toda la pila de etiquetas configurada estáticamente.

  • Auto-translated LSPs: rutas de enrutamiento de origen configuradas estáticamente que se traducen automáticamente.

  • Computed LSPs—Rutas de enrutamiento de origen configuradas estáticamente que se calculan con la ruta más corta restringida (CSPF) distribuida.

  • Dynamic LSPs—Túneles creados dinámicamente activados a través del módulo de túnel dinámico que tienen resolución ERO de último salto.

En función del origen del LSP de enrutamiento de segmentos, puede configurar la capacidad de delegación en el PCC. Para habilitar la delegación de LSP de enrutamiento de segmentos, incluya la instrucción en el nivel apropiado bajo la jerarquía.lsp-external-controller pccd[edit protocols source-packet-routing]

Tabla 2 muestra una asignación del origen LSP al nivel de jerarquía de configuración correspondiente en el que está habilitada la capacidad de delegación.

Nota:

Debe incluir la instrucción en los niveles de jerarquía y antes de configurar la capacidad de delegación en el PCC.lsp-external-controller pccd[edit protocols source-packet-routing][edit protocols mpls]

Tabla 2: Asignación del origen de LSP de enrutamiento de segmentos con jerarquía de configuración

Fuente del LSP de enrutamiento por segmentos

Jerarquía de configuración

  • LSP traducidos automáticamente

  • LSP estáticos

Lista de segmentos primarios en [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

LSP calculados (CSPF distribuido)

Lista de segmentos principales de la ruta de enrutamiento de origen en:

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name]

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

LSP dinámicos

Lista de segmentos principales de la plantilla de ruta de enrutamiento de origen en:

  • [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]

  • [edit protocols source-packet-routing source-routing-path-template template-name]

Puede ver el estado de control de los LSP de SR-TE desde la salida del comando show spring-traffic-engineering .show spring-traffic-engineering

muestra la interacción PCEP cuando la instrucción está configurada para una ruta de enrutamiento de origen.Tabla 3lsp-external-controller

Tabla 3: Interacción PCEP Delegación LSP

Jerarquía de configuración lsp-external-controller

Estado de delegación source-routing-path

Interacción de PCEP entre PCC y PCE

Lista de segmentos primarios de ruta de enrutamiento de origen

Delegación inicial

  1. Se envía un mensaje PCReport al PCE para su delegación. El PCReport solo contiene restricciones y detalles de ruta (como ERO).

  2. PCE calcula la ruta para LSP e informa que la ruta está en estado inactivo.

  3. El LSP local no programa ninguna ruta hasta que el controlador calcula el ERO y notifica el resultado al PCC a través de PCUpdate.

El mismo comportamiento se observa cuando se reinicia el proceso de protocolo de enrutamiento (rpd) o se produce un cambio de motor de enrutamiento.

Lista de segmentos primarios de ruta de enrutamiento de origen

Delegación de ruta existente

  1. Se envía un PCReport al PCE para su delegación. El PCReport solo contiene restricciones y detalles de ruta (como ERO).

  2. Un segmento primario correspondiente se delega al PCE.

  3. PCE calcula la ruta para el LSP.

  4. El segmento primario continúa contribuyendo a la ruta según lo determinado por la configuración local o el cálculo hasta que se recibe una PCUpdate del PCE.

    • Si Seamless BFD (S-BFD) no está configurado para el segmento primario, entonces no hay más actualizaciones en la ruta y el estado de LSP tampoco se supervisa ni se informa al PCE. El estado de LSP en este punto se notifica como hacia arriba o hacia abajo, dependiendo de si el cálculo de la ruta se realizó correctamente en ese punto.

    • Si S-BFD está configurado para el segmento primario, entonces el estado del segmento primario se rastrea y se informa al PCE. Si BFD detecta que el segmento primario está inactivo, la ruta principal correspondiente se elimina de la ruta. La misma ruta que se calculó anteriormente se reprograma si esa ruta está activa ahora.

  5. Si se recibe un mensaje PCUpdate del PCE, SR-TE utiliza el parámetro recibido para configurar la ruta para la que se envió el mensaje PCReport. La ruta programada incluye solo la lista de segmentos recibida del PCE, y se eliminan todas las demás listas de segmentos que se programaron anteriormente. Esta reprogramación de la ruta ocurre de una manera de hacer antes de romper.

Segmento principal de la ruta de enrutamiento de origen

La delegación no está configurada o se ha eliminado.

La lista de segmentos del PCE (si está disponible) ya no se utiliza y se utiliza el resultado del cálculo de la configuración local. Cuando el resultado local de la lista de segmentos está disponible, la lista de segmentos correspondiente se utiliza para programar la ruta de forma prediseñada.

Lista de segmentos de ruta de enrutamiento de origen

La delegación se habilita después de configurar LSP.

La funcionalidad de delegación se activa para la lista de segmentos principales en la ruta de enrutamiento de origen.

Lista de segmentos de ruta de enrutamiento de origen

La delegación no está configurada o se ha eliminado.

La funcionalidad de delegación se elimina de la lista de segmentos principales en la ruta de enrutamiento de origen.

Lista de segmentos principales de plantillas de ruta de enrutamiento de origen

La delegación se habilita después de configurar LSP.

  • En la plantilla de ruta de enrutamiento de origen, la funcionalidad de delegación se activa para toda la ruta de enrutamiento de origen.

    Las configuraciones de plantilla solo se pueden aplicar al módulo de túnel dinámico.

  • En la ruta principal de la plantilla de ruta de enrutamiento de origen, la funcionalidad de delegación se activa para esa ruta principal concreta según la configuración.

Lista de segmentos principales de plantillas de ruta de enrutamiento de origen

La delegación no está configurada o se ha eliminado.

La funcionalidad de delegación se elimina de todas las rutas de enrutamiento de origen y rutas principales que coincidan con la configuración de la plantilla.

Enrutamiento por segmentos para limitaciones de PCEP y características no compatibles

La compatibilidad con el enrutamiento por segmentos para PCEP no aumenta la carga de rendimiento del sistema. Sin embargo, tiene las siguientes limitaciones:

  • Un LSP SR-TE no está protegido localmente en el PCC. Cuando el LSP tiene más de seis saltos, no se proporciona ningún servicio en el LSP que no sea transportar tráfico IP simple.

  • No se admiten el cambio de motor de enrutamiento correcto (GRES) ni la actualización de software en servicio unificada (ISSU unificada).

  • No se admite el enrutamiento activo sin detención (NSR).

  • IPv6 no es compatible.

  • Los LSP delegados por PCE no admiten lo siguiente:

    • LSP SR-TE de color

    • LSP IPv6

    • Lista de segmentos secundarios de la ruta de enrutamiento de origen. Solo se puede delegar una ruta de la lista de segmentos.

    • Estándar multisegmento. Solo el primer segmento de la lista de segmentos se delega y se informa al controlador.

Ejemplo: Configurar el enrutamiento de segmentos para el protocolo de elemento de cálculo de ruta

En este ejemplo se muestra cómo configurar el enrutamiento de segmentos o la ingeniería de tráfico del enrutamiento de paquetes fuente en redes (SPRING) (SR-TE) para el protocolo de elemento de cálculo de ruta (PCEP). En la configuración, aprovechamos las ventajas del enrutamiento de segmentos con los beneficios de la computación de ruta externa para una ingeniería de tráfico eficiente.

Requisitos

En este ejemplo, se utilizan los siguientes componentes de hardware y software:

  • Cuatro plataformas de enrutamiento universal 5G de la serie MX, donde el enrutador de entrada de la serie MX es el cliente de cálculo de ruta (PCC).

  • Una conexión TCP desde el PCC a un elemento de cálculo de ruta de acceso (PCE) con estado externo.

  • Junos OS versión 17.2 o posterior ejecutándose en el PCC para la implementación de LSP iniciados por PCE.

    Para la funcionalidad de delegación de PCE, debe ejecutar Junos OS versión 20.1R1 o una versión posterior.

Antes de empezar:

  • Configure las interfaces del dispositivo.

  • Configure MPLS.

  • Configure IS-IS.

Descripción general

La implementación de Junos OS del enrutamiento por segmentos para PCEP incluye los LSP de SR-TE iniciados y delegados por PCE.

  • La implementación de LSP iniciados por PCE se introdujo en Junos OS versión 17.2R1, donde las capacidades de ingeniería de tráfico del enrutamiento de segmentos se admiten en sesiones de PCEP para LSP iniciadas por un PCE. El PCE crea los LSP para los segmentos de adyacencia y nodo. Las rutas de túnel se crean en la tabla de enrutamiento inet.3 del PCC correspondiente a los LSP de SR-TE iniciados por PCE.

  • La implementación de los LSP delegados por PCE se introdujo en Junos OS versión 20.1R1, donde los LSP de enrutamiento de segmentos no coloreados IPv4 configurados localmente en el PCC se pueden delegar a un controlador PCE. A continuación, el PCE controla el LSP y puede modificar los atributos de LSP para el cálculo de la ruta.

Los LSP delegados por PCE tienen una ventaja sobre los LSP iniciados por PCE en el momento en que la sesión de PCEP deja de funcionar. En el caso de los LSP iniciados por PCE, cuando la sesión de PCEP está inactiva, los LSP se eliminan del PCC. Sin embargo, en el caso de los LSP delegados por PCE, cuando la sesión de PCEP deja de funcionar, el PCC recupera el control de los LSP delegados del PCE. Como resultado, con los LSP delegados por PCE, evitamos una situación en la que los paquetes se descartan silenciosamente (también conocida como condición de ruta nula) cuando la sesión PCEP deja de funcionar.

Para habilitar el enrutamiento por segmentos para PCEP:

Para los LSP de enrutamiento de segmentos iniciados por PCE:

  1. Habilite la informática de ruta externa para MPLS incluyendo la instrucción en el nivel jerárquico .lsp-external-controller[edit protocols mpls]

    Esta configuración también es necesaria para PCEP con extensiones RSVP-TE. No puede deshabilitar PCEP con RSVP-TE cuando el enrutamiento de segmentos para PCEP está habilitado.

  2. Habilite la computación de ruta externa para SR-TE incluyendo la instrucción en el nivel jerárquico .lsp-external-controller pccd[edit protocols spring-traffic-engineering]

  3. Habilite el enrutamiento de segmentos para la PCE incluyendo la instrucción en el nivel de jerarquía.spring-capability[edit protocols pcep pce pce-name]

  4. Opcionalmente, configure la profundidad SID máxima para el PCE incluyendo la instrucción en el nivel de jerarquía.max-sid-depth number[edit protocols pcep pce pce-name]

    La profundidad máxima del SID es el número de SID admitidos por un nodo o un vínculo en un nodo. Cuando no está configurado, se aplica un valor SID máximo predeterminado de 5.

  5. Opcionalmente, configure el valor de preferencia para el enrutamiento de segmentos incluyendo el en el nivel de jerarquía.preference preference-value[edit protocol spring-te]

    El valor de preferencia indica el orden en que se selecciona una ruta como la forma de ruta activa entre las rutas candidatas, donde un valor más alto tiene una preferencia más alta. Cuando no está configurado, se aplica un valor de preferencia predeterminado de 8.

  6. Opcionalmente, configure el registro de enrutamiento de segmentos para solucionar problemas incluyendo la instrucción en el nivel de jerarquía.traceoptions[edit protocols spring-te]

Para la delegación PCE de LSP de enrutamiento de segmentos, además de los pasos mencionados anteriormente, haga lo siguiente:

  1. Defina una lista de segmentos con parámetros de etiqueta. Esto crea un LSP de enrutamiento de segmento localmente en el PCC.

  2. Habilite la capacidad de delegación del LSP configurado localmente en el PCC incluyendo la instrucción en cualquiera de las siguientes jerarquías según el origen del LSP de enrutamiento de segmentos:lsp-external-controller pccd

    • Para rutas de enrutamiento de origen configuradas estáticamente que se calculan con CSPF distribuido y niveles de jerarquía.[edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name][edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

    • Para rutas de enrutamiento de origen configuradas estáticamente que tienen toda la pila de etiquetas configuradas estáticamente y rutas de enrutamiento de origen que se traducen automáticamente: nivel de jerarquía.[edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

    • Para túneles creados dinámicamente activados a través del módulo de túnel dinámico que tienen niveles jerárquicos y de resolución ERO de último salto.[edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name][edit protocols source-packet-routing source-routing-path-template template-name]

Topología

Figura 8 ilustra un ejemplo de topología de red que tiene una sesión PCEP ejecutándose entre el PCE y el PCC (el enrutador de la serie MX de entrada). Los enrutadores R1, R2 y R3 son los otros enrutadores de la serie MX en la red. En este ejemplo, configuramos el enrutamiento de segmentos para PCEP en el PCC. También configuramos una ruta estática en el PCC al enrutador R3 para verificar el uso de rutas de túnel SR-TE al enrutar el tráfico para la ruta estática.

Figura 8: Enrutamiento por segmentos para PCEPEnrutamiento por segmentos para PCEP

Configuración

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.

Aunque presentamos la configuración de todos los dispositivos (PCC y los tres enrutadores) en esta sección, el procedimiento paso a paso documenta solo la configuración del PCC.

PCC

Enrutador R1

Enrutador R2

Enrutador R3

Procedimiento
Procedimiento paso a paso

En este ejemplo, configuramos solo el PCC.

Los pasos siguientes requieren que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

Para configurar el PCC:

  1. Configure las interfaces del PCC.

  2. Configure el ID del enrutador y asigne un número de sistema autónomo para el PCC.

  3. Configure una ruta estática desde el PCC hasta el enrutador R3.

    La ruta estática se crea únicamente con fines de verificación y no afecta a la funcionalidad de la característica.

  4. Configure RSVP en todas las interfaces del PCC, excluyendo la interfaz de administración.

  5. Configure MPLS en todas las interfaces del PCC, excluyendo la interfaz de administración.

  6. Habilite la capacidad de computación de ruta externa para MPLS.

  7. Configure IS-IS nivel 2 en todas las interfaces del PCC, excluyendo las interfaces de administración y de circuito cerrado.

  8. Configure los atributos de bloque global de enrutamiento de segmentos (SRGB) para el enrutamiento de segmentos.

  9. Habilite la capacidad de computación de ruta externa para SR-TE.

  10. Configure los parámetros PCE y habilite el aprovisionamiento del LSP por parte del PCE y la capacidad de enrutamiento de segmentos.

  11. Habilite el aprovisionamiento de LSP de enrutamiento por segmentos por parte de la PCE.

  12. Habilite la capacidad de enrutamiento de segmentos para el PCE.

  13. Defina los parámetros de la lista de segmentos estáticos.static_seg_list_1

  14. Configure un LSP de enrutamiento de segmento estático desde el PCC al enrutador R3 para la delegación PCE.

  15. Habilite la capacidad de delegación para la ruta de enrutamiento de origen.static_srte_lsp_1

    Al completar los pasos 13, 14 y 15, permite que el PCC delegue los LSP de enrutamiento de segmento al PCE.

  16. Confirme la configuración.

Resultados

Desde el modo de configuración, escriba los comandos , y para confirmar la configuración. show interfacesshow routing-optionsshow protocols Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo (el PCC), ingrese desde el modo de configuración.commit

Verificación

Confirme que la configuración funcione correctamente.

Verificar la adyacencia y las etiquetas de IS-IS
Propósito

Verifique la adyacencia IS-IS en el PCC. Tome nota del rango de etiquetas SRGB, los valores de adyacencia y segmento de nodo, y los campos de salida de capacidad SPRING.

Acción

Desde el modo operativo, ejecute los comandos , y .show isis adjacency extensiveshow isis database extensiveshow isis overview

Significado

La adyacencia IS-IS entre el PCC y el PCE y la que existe entre el PCC y el enrutador R1 están activas y operativas. El resultado también muestra las asignaciones de etiquetas para los segmentos adyacentes y de nodo.

Comprobar la base de datos de ingeniería de tráfico
Propósito

Compruebe las entradas de la base de datos de ingeniería de tráfico en el PCC.

Acción

Desde el modo operativo, ejecute el comando.show ted database extensive

Significado

La base de datos de ingeniería de tráfico incluye entradas anunciadas desde los enrutadores R1, R2 y R3, que el PCE utiliza para la computación de rutas externas para el PCC.

Verificar los LSP de SR-TE
Propósito

Verifique la creación de LSP de SR-TE en el PCC.

Acción

Desde el modo operativo, ejecute los comandos , y .show path-computation-client lspshow spring-traffic-engineering lsp detailshow route protocol spring-te

Significado

Los resultados muestran que el PCE ha creado dos LSP SR-TE — y —para los segmentos de adyacencia y nodo, respectivamente.adj_sid_lspnode_sid_lsp

El LSP de enrutamiento de segmentos, , está habilitado con la capacidad de delegación.static_srte_lsp_1 El campo muestra el estado de control y enrutamiento de los LSP delegados por PCE. significa que el PCE tiene control sobre los LSP. significa que el PCE ha proporcionado el ERO para la ruta de enrutamiento de origen. Delegation infoExternally controlledExternally routed

Verificar la creación de rutas de túnel
Propósito

Compruebe las rutas de túnel creadas para los LSP de SR-TE que se incluyen en la tabla de enrutamiento inet.3 del PCC.

Acción

Desde el modo de operación, ejecute el comando.show route table inet.3 extensive

Significado

Se han creado rutas de túnel para el destino LSP controlado por PCE con SR-TE como etiqueta de protocolo.

Comprobar las entradas de la tabla de reenvío
Propósito

Verifique que el destino LSP SR-TE al enrutador R3 esté instalado en la tabla de reenvío del PCC.

Acción

Desde el modo de operación, ejecute el comando.show route forwarding-table destination ip-address extensive

Significado

La dirección IP de destino de LSP SR-TE para el enrutador R3 se instala como una entrada de reenvío.

Verificar el uso de rutas de túnel para el reenvío de rutas estáticas
Propósito

Compruebe que la ruta estática está tomando la ruta de túnel creada para los LSP de SR-TE.

Acción

Desde el modo operativo, ejecute los comandos y .show route ip-addressshow route forwarding-table destination ip-address

Significado

Los resultados muestran que la ruta estática al enrutador R3 utiliza la ruta de túnel creada para el SR-TE LSP.

Etiqueta de enrutamiento de segmento estático Ruta conmutada

La arquitectura de enrutamiento por segmentos permite que los dispositivos de entrada en una red central dirijan el tráfico a través de rutas explícitas. Puede configurar estas rutas mediante listas de segmentos para definir las rutas que debe tomar el tráfico entrante. El tráfico entrante puede estar etiquetado o ser tráfico IP, lo que hace que la operación de reenvío en el dispositivo de entrada sea un intercambio de etiquetas o una búsqueda basada en el destino.

Descripción del LSP de enrutamiento de segmentos estáticos en redes MPLS

El enrutamiento de paquetes de origen o enrutamiento de segmentos es una arquitectura de plano de control que permite a un enrutador de entrada dirigir un paquete a través de un conjunto específico de nodos y vínculos en la red sin depender de los nodos intermedios de la red para determinar la ruta real que debe tomar.

Introducción a los LSP de enrutamiento por segmentos

El enrutamiento por segmentos aprovecha el paradigma del enrutamiento de origen. Un dispositivo dirige un paquete a través de una lista ordenada de instrucciones, llamadas segmentos. Un segmento puede representar cualquier instrucción, topológica o basada en servicios. Un segmento puede tener una semántica local a un nodo de enrutamiento de segmento o a un nodo global dentro de un dominio de enrutamiento de segmento. El enrutamiento por segmentos aplica un flujo a través de cualquier ruta topológica y cadena de servicio, mientras mantiene el estado por flujo solo en el dispositivo de entrada al dominio de enrutamiento por segmento. El enrutamiento de segmentos se puede aplicar directamente a la arquitectura MPLS sin cambios en el plano de reenvío. Un segmento se codifica como una etiqueta MPLS. Una lista ordenada de segmentos se codifica como una pila de etiquetas. El segmento a procesar está en la parte superior de la pila. Al completar un segmento, la etiqueta relacionada se abre de la pila.

Los LSP de enrutamiento de segmentos pueden ser de naturaleza dinámica o estática.

Dynamic segment routing LSPs—Cuando un controlador externo crea un LSP de enrutamiento de segmento y lo descarga en un dispositivo de entrada mediante extensiones PCEP (Path Computation Element Protocol) o desde una política de enrutamiento de segmento BGP mediante extensiones de enrutamiento de segmento BGP, el LSP se aprovisiona dinámicamente. La lista de segmentos del LSP de enrutamiento de segmentos dinámicos se encuentra en el objeto de ruta explícito (ERO) PCEP o en la directiva de enrutamiento de segmentos BGP del LSP.

Static segment routing LSPs: cuando se crea un LSP de enrutamiento de segmentos en el dispositivo de entrada mediante una configuración local, el LSP se aprovisiona estáticamente.

Un LSP de enrutamiento de segmento estático se puede clasificar además como LSP coloreados y no coloreados en función de la configuración de la instrucción en el nivel de jerarquía.color[edit protocols source-packet-routing source-routing-path lsp-name]

Por ejemplo:

[edit protocols]
    source-packet-routing {
    source-routing-path lsp_name {
        to destination_address;
        color color_value;
        binding-sid binding-label;
        primary segment_list_1_name weight weight;
        ...
        primary segment_list_n_name weight weight;
        secondary segment_list_n_name;
        sr-preference sr_preference_value;
    }
}

Aquí, cada instrucción primaria y secundaria se refiere a una lista de segmentos.

[edit protocols]
source-packet-routing {
    segment-list segment_list_name {
        hop_1_name label sid_label;
        ...
        hop_n_name label sid_label;
    }
}

Ventajas de usar los LSP de enrutamiento por segmentos

  • El enrutamiento de segmentos estáticos no depende del estado de reenvío por LSP en los enrutadores de tránsito. Por lo tanto, eliminar la necesidad de aprovisionamiento y mantenimiento por estado de reenvío LSP en el núcleo.

  • Proporcionar mayor escalabilidad a las redes MPLS.

LSP de enrutamiento de segmentos estáticos coloreados

Un LSP de enrutamiento de segmento estático configurado con la instrucción se denomina LSP coloreado.color

Descripción de los LSP de enrutamiento de segmentos estáticos coloreados

De manera similar a una política de enrutamiento de segmentos BGP, la ruta de entrada del LSP coloreado se instala en las tablas de enrutamiento o , con una clave para mapear el tráfico IP.inetcolor.0inet6color.0destination-ip-address, color

Un LSP de enrutamiento de segmento de color estático puede tener un SID de enlace, para el cual se instala una ruta en la tabla de enrutamiento.mpls.0 Esta etiqueta SID de enlace se utiliza para asignar tráfico etiquetado al LSP de enrutamiento de segmento. Las puertas de enlace de la ruta se derivan de las configuraciones de la lista de segmentos en las rutas principal y secundaria.

Lista de segmentos de LSP de enrutamiento de segmentos de color

Los LSP de enrutamiento de segmentos estáticos de color ya proporcionan compatibilidad con el modo de etiqueta de primer salto para resolver un LSP. Sin embargo, el modo IP de primer salto no es compatible con los LSP de enrutamiento de segmentos coloreados. A partir de Junos OS versión 19.1R1, se introduce una función de comprobación de confirmación para garantizar que todas las listas de segmentos que contribuyen a las rutas coloreadas tengan la etiqueta mínima presente para todos los saltos. Si no se cumple este requisito, se bloquea la confirmación.

LSP de enrutamiento de segmentos estáticos no coloreados

Un LSP de enrutamiento de segmento estático que está configurado sin la instrucción es un LSP no coloreado.color Al igual que en los túneles de enrutamiento de segmentos PCEP, la ruta de entrada se instala en las tablas de enrutamiento o .inet.3inet6.3

Junos OS admite LSP de enrutamiento de segmentos estáticos no coloreados en enrutadores de entrada. Puede aprovisionar LSP de enrutamiento de segmentos estáticos no coloreados configurando una ruta enrutada de origen y una o más listas de segmentos. Estas listas de segmentos pueden ser utilizadas por varios LSP de enrutamiento de segmentos no coloreados.

Descripción de los LSP de enrutamiento de segmentos no coloreados

El LSP de enrutamiento de segmento no coloreado tiene un nombre único y una dirección IP de destino. Se instala una ruta de entrada al destino en la tabla de enrutamiento inet.3 con una preferencia predeterminada de 8 y una métrica de 1. Esta ruta permite que los servicios no coloreados se asignen al segmento LSP de enrutamiento perteneciente al destino. En caso de que el LSP de enrutamiento de segmentos no coloreados no requiera una ruta de entrada, la ruta de entrada se puede deshabilitar. Un LSP de enrutamiento de segmentos no coloreado utiliza una etiqueta SID vinculante para lograr la unión LSP de enrutamiento de segmentos. Esta etiqueta que se puede utilizar para modelar el LSP de enrutamiento de segmento como un segmento que se puede utilizar posteriormente para construir otros LSP de enrutamiento de segmento de manera jerárquica. El tránsito de la etiqueta SID de enlace, de forma predeterminada, tiene una preferencia de 8 y una métrica de 1.

A partir de Junos OS versión 18.2R1, los LSP de enrutamiento de segmentos no coloreados configurados estáticamente en el dispositivo de entrada se notifican al elemento de cálculo de ruta (PCE) a través de una sesión de protocolo de elemento de cálculo de ruta (PCEP). Estos LSP de enrutamiento de segmentos no coloreados pueden tener etiquetas de identificador de servicio de enlace (SID) asociadas. Con esta característica, el PCE puede usar esta etiqueta SID de enlace en la pila de etiquetas para aprovisionar rutas LSP de enrutamiento de segmentos iniciadas por PCE.

Un LSP de enrutamiento de segmentos no coloreados puede tener un máximo de 8 rutas principales. Si hay varias rutas principales operativas, el motor de reenvío de paquetes (PFE) distribuye el tráfico entre las rutas en función de los factores de equilibrio de carga, como el peso configurado en la ruta. Se trata de una ruta múltiple de igual costo (ECMP) si ninguna de las rutas tiene un peso configurado en ellas, o ECMP ponderado si al menos una de las rutas tiene un peso distinto de cero configurado en las rutas. En ambos casos, cuando una o algunas de las rutas fallan, el PFE reequilibra el tráfico sobre las rutas restantes, lo que conduce automáticamente a lograr la protección de la ruta. Un LSP de enrutamiento de segmentos no coloreados puede tener una ruta secundaria para la protección de ruta dedicada. Cuando se produce un error en una ruta principal, el PFE reequilibra el tráfico con las rutas principales funcionales restantes. De lo contrario, el PFE cambia el tráfico a la ruta de respaldo, logrando así la protección de la ruta. Un LSP de enrutamiento de segmentos no coloreados puede especificar una métrica en para sus rutas SID de entrada y enlace.[edit protocols source-packet-routing source-routing-path lsp-name] Varios LSP de enrutamiento de segmentos no coloreados tienen la misma dirección de destino que contribuye al siguiente salto de la ruta de entrada.

Varios LSP de enrutamiento de segmentos no coloreados tienen la misma dirección de destino que contribuye al siguiente salto de la ruta de entrada. Cada ruta, ya sea primaria o secundaria, de cada LSP de enrutamiento de segmento se considera un candidato de puerta de enlace, si la ruta es funcional y el LSP de enrutamiento de segmento tiene la mejor preferencia de todos estos LSP de enrutamiento de segmento. Sin embargo, el número máximo de puertas de enlace que puede contener el salto siguiente no puede superar el límite de múltiples rutas de RPD, que es 128 de forma predeterminada. Se podan los caminos adicionales, primero los caminos secundarios y luego los caminos primarios. Una lista de segmentos determinada puede ser referida varias veces como rutas primarias o secundarias por estos LSP de enrutamiento de segmentos. En este caso, hay varias puertas de enlace, cada una con un ID de túnel LSP de enrutamiento de segmento único. Estas puertas de enlace son distintas, aunque tienen una pila de etiquetas y una interfaz de salida idénticas. Un LSP de enrutamiento de segmento no coloreado y un LSP de enrutamiento de segmento de color también pueden tener la misma dirección de destino. Sin embargo, corresponden a diferentes direcciones de destino para las rutas de entrada, ya que la dirección de destino del LSP del enrutamiento del segmento de color se construye con su dirección de destino y color.

Nota:

En el caso de que un LSP de enrutamiento de segmento estático no coloreado y un LSP de enrutamiento de segmento creado por PCEP coexistan y tengan la misma dirección para que contribuya a la misma ruta de entrada, si también tienen la misma preferencia. De lo contrario, se instala el LSP de enrutamiento de segmento con la mejor preferencia para la ruta.

Lista de segmentos de LSP de enrutamiento de segmentos no coloreados

Una lista de segmentos consiste en una lista de lúpulos. Estos saltos se basan en la etiqueta SID o en una dirección IP. El número de etiquetas SID de la lista de segmentos no debe superar el límite máximo de lista de segmentos. El enlace máximo de lista de segmentos a un túnel LSP se incrementa de 8 a 128, con un máximo de 1000 túneles por sistema. Se admite un máximo de 128 rutas primarias por LSP de enrutamiento de segmento estático. Puede configurar el límite máximo de lista de segmentos en el nivel jerárquico .[edit protocols source-packet-routing]

Antes de Junos OS versión 19.1R1, para que un LSP de enrutamiento de segmento estático no coloreado fuera utilizable, el primer salto de la lista de segmentos tenía que ser una dirección IP de una interfaz saliente y el segundo a ésimo salto podían ser etiquetas SID.n A partir de Junos OS versión 19.1R1, este requisito no se aplica, ya que el primer salto de los LSP estáticos no coloreados ahora proporciona compatibilidad con etiquetas SID, además de direcciones IP. Con la compatibilidad con la etiqueta de primer salto, se habilita el reenrutamiento rápido (FRR) MPLS y la multiruta ponderada de igual costo para resolver los LSP de enrutamiento de segmentos estáticos no coloreados, similares a los LSP estáticos de color.

Para que el modo de etiqueta de primer salto surta efecto, debe incluir la instrucción global o individualmente para una lista de segmentos, y el primer salto de la lista de segmentos debe incluir tanto la dirección IP como la etiqueta.inherit-label-nexthops Si el primer salto incluye sólo la dirección IP, la instrucción no tiene ningún efecto.inherit-label-nexthops

Puede configurar en cualquiera de las siguientes jerarquías.inherit-label-nexthops La instrucción sólo surte efecto si el primer salto de la lista de segmentos incluye tanto la dirección IP como la etiqueta.inherit-label-nexthops

  • —En el nivel jerárquico.Segment list level[edit protocols source-packet-routing segment-list segment-list-name]

  • —En el nivel jerárquico.Globally[edit protocols source-packet-routing]

Cuando la instrucción se configura globalmente, tiene prioridad sobre la configuración de nivel de lista de segmentos y la configuración se aplica a todas las listas de segmentos.inherit-label-nexthopsinherit-label-nexthops Cuando la instrucción no está configurada globalmente, sólo las listas de segmentos con etiquetas y dirección IP presentes en el primer salto y configuradas con instrucción se resuelven mediante etiquetas SID.inherit-label-nexthopsinherit-label-nexthops

Para los LSP estáticos dinámicos no coloreados, es decir, los LSP de enrutamiento de segmentos basados en PCEP, la instrucción debe habilitarse globalmente, ya que no se aplica la configuración a nivel de segmento.inherit-label-nexthops

Tabla 4 describe el modo de enrutamiento de segmentos de resolución LSP según la especificación del primer salto.

Tabla 4: Resolución LSP estática no coloreada basada en la especificación del primer salto

Especificación del primer salto

Modo de resolución LSP

Solo dirección IP

Por ejemplo:

segment-list path-1 {
    hop-1 ip-address 172.16.12.2;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

La lista de segmentos se resuelve utilizando la dirección IP.

Solo SID

Por ejemplo:

segment-list path-2 {
    hop-1 label 1000011;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

La lista de segmentos se resuelve mediante etiquetas SID.

Dirección IP y SID (sin la configuración)inherit-label-nexthops

Por ejemplo:

segment-list path-3 {
    hop1 {
        label 801006;
        ip-address 172.16.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

De forma predeterminada, la lista de segmentos se resuelve utilizando la dirección IP.

Dirección IP y SID (con la configuración)inherit-label-nexthops

Por ejemplo:

segment-list path-3 {
    inherit-label-nexthops;
    hop1 {
        label 801006;
        ip-address 172.16.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

La lista de segmentos se resuelve mediante etiquetas SID.

Puede utilizar el comando para ver los LSP diseñados por tráfico de enrutamiento de segmentos no coloreados que tienen varias listas de segmentos instaladas en la tabla de enrutamiento inet.3.show route ip-address protocol spring-te active-path table inet.3

Por ejemplo:

Nota:

El tipo de lista de segmentos de primer salto de un LSP de enrutamiento de segmento estático puede provocar un error en una confirmación si:

  • Las diferentes listas de segmentos de un túnel tienen diferentes tipos de resolución de primer salto. Esto es aplicable a los LSP de enrutamiento de segmentos estáticos coloreados y no coloreados. Sin embargo, esto no se aplica a los LSP basados en PCEP; Se genera un mensaje de registro del sistema para la discrepancia en el tipo de resolución del primer salto en el momento de calcular la ruta.

    Por ejemplo:

    Se produce un error en la confirmación del túnel , ya que la ruta 1 está en modo de dirección IP y la ruta 2 está en modo de etiqueta.lsp1

  • El SID de enlace está habilitado para el LSP estático no coloreado cuyo tipo de lista de segmentos es etiqueta SID.

    Por ejemplo:

    La configuración de SID de enlace sobre la lista de segmentos de etiqueta solo se admite para LSP estáticos de color y no para LSP estáticos sin color.

Aprovisionamiento de LSP de enrutamiento por segmentos estáticos

El aprovisionamiento por segmentos se realiza por enrutador. Para un segmento determinado en un enrutador, se asigna una etiqueta de identificador de servicio único (SID) desde un grupo de etiquetas deseado que puede ser del grupo de etiquetas dinámicas para una etiqueta SID de adyacencia o del bloque global de enrutamiento de segmentos (SRGB) para un SID de prefijo o SID de nodo. La etiqueta SID de adyacencia se puede asignar dinámicamente, que es el comportamiento predeterminado, o asignarse desde un grupo de etiquetas estáticas locales (SRLB). A continuación, se instala una ruta para la etiqueta SID en la tabla mpls.0.

Junos OS permite el enrutamiento de segmentos estáticos LSP configurando la instrucción en el nivel de jerarquía.segment[edit protocols mpls static-label-switched-path static-label-switched-path] Un LSP de segmento estático se identifica mediante una etiqueta SID única que pertenece al grupo de etiquetas estáticas de Junos OS. Puede configurar el grupo de etiquetas estáticas de Junos OS configurando la instrucción en el nivel de jerarquía.static-label-range static-label-range[edit protocols mpls label-range]

Limitaciones del LSP del enrutamiento de segmentos estáticos

  • Actualmente, Junos OS tiene la limitación de que el siguiente salto no se puede generar para enviar etiquetas de profundidad de lista de segmentos más que el máximo. Por lo tanto, una lista de segmentos con más etiquetas SID que el máximo (excluyendo la etiqueta SID del primer salto que se utiliza para resolver el reenvío del siguiente salto) no se puede utilizar para los LSP de enrutamiento de segmentos coloreados o no coloreados. Además, el número real permitido para un LSP de enrutamiento de segmento determinado puede ser incluso inferior al límite máximo, si un servicio MPLS está en el LSP de enrutamiento de segmento o el LSP de enrutamiento de segmento está en un vínculo o una ruta de protección de nodo. En todos los casos, el número total de etiquetas de servicio, etiquetas SID y etiquetas de protección de nodo o vínculo no debe superar la profundidad máxima de la lista de segmentos. Puede configurar el límite máximo de lista de segmentos en el nivel jerárquico.[edit protocols source-packet-routing] Se pueden unir varios LSP de enrutamiento de segmentos no coloreados con etiquetas SID menores o iguales al máximo para construir un LSP de enrutamiento de segmentos más largo. Esto se denomina unión LSP de enrutamiento de segmentos. Se puede lograr utilizando la etiqueta SID vinculante.

  • La unión de LSP de enrutamiento de segmentos se realiza realmente a nivel de ruta. Si un LSP de enrutamiento de segmentos no coloreados tiene varias rutas que son varias listas de segmentos, cada ruta se puede unir independientemente a otro LSP de enrutamiento de segmento no coloreado en un punto de unión. Un LSP de enrutamiento de segmentos no coloreado que se dedica a la costura puede deshabilitar la instalación de la ruta de entrada mediante la configuración de la instrucción en el nivel de jerarquía.no-ingress[edit protocols source-packet-routing source-routing-path lsp-name]

  • Se admite un máximo de 128 rutas principales y 1 ruta secundaria por LSP de enrutamiento de segmento estático no coloreado. Si se produce una infracción en la configuración, se produce un error en la comprobación de confirmación.

  • El enlace máximo de lista de segmentos a un túnel LSP se incrementa de 8 a 128, con un máximo de 1000 túneles por sistema. Se admite un máximo de 128 rutas primarias por LSP de enrutamiento de segmento estático. Como limitación, el soporte máximo del sensor para la ruta LSP es solo 32000.

  • Si alguna lista de segmentos está configurada con más etiquetas que la profundidad máxima de lista de segmentos, la comprobación de confirmación de configuración produce un error.

Creación dinámica de LSP de enrutamiento por segmentos

En las redes de enrutamiento de segmentos que tienen cada dispositivo perimetral de proveedor (PE) conectado a todos los demás dispositivos de PE, se requiere una gran cantidad de configuración para configurar las rutas conmutadas por etiquetas de enrutamiento de segmentos (LSP), aunque es posible que solo se usen unas pocas rutas de enrutamiento de segmentos diseñadas para tráfico (SR-TE). Puede habilitar la creación dinámica trigerred BGP de estos LSP para reducir la cantidad de configuración en dichas implementaciones.

Configuración de la plantilla LSP de enrutamiento de segmentos dinámicos

Para configurar la plantilla que permita la creación dinámica de LSP de enrutamiento de segmentos, debe incluir la instrucción spring-te en la jerarquía.spring-te (Dynamic Tunnels)[edit routing-options dynamic-tunnels]

  • A continuación se muestra un ejemplo de configuración para la plantilla LSP de enrutamiento de segmentos dinámicos de color:

  • A continuación se muestra un ejemplo de configuración para la plantilla LSP de enrutamiento de segmentos dinámicos sin color:

Resolución de LSP de enrutamiento de segmentos dinámicos
Resolución de LSP de enrutamiento de segmentos dinámicos de color

Cuando a los prefijos BGP se les asigna una comunidad de colores, inicialmente se resuelven mediante la política de ruta general para ese color en particular y, a su vez, se identifica la plantilla SR-TE en la que se debe resolver el prefijo BGP. A continuación, el SID de destino se deriva del atributo next-hop del prefijo de carga del BGP. Por ejemplo, si el siguiente salto del prefijo de carga BGP es una dirección IP que pertenece al dispositivo A, se toma el nodo SID del dispositivo A y se prepara una etiqueta correspondiente y se inserta en la parte inferior de la pila. El prefijo de carga BGP se resuelve en un modo de solo color, donde el nodo SID del dispositivo A está en la parte inferior de la pila de etiquetas final y las etiquetas de ruta SR-TE están en la parte superior.

El nombre final de la plantilla LSP es una combinación de prefijo, color y nombre de túnel; Por ejemplo, .<prefix>:<color>:dt-srte-<tunnel-name> El color del nombre LSP se muestra en formato hexadecimal y el formato del nombre del túnel es similar al de los nombres LSP de túnel activados por RSVP.

Para resolver correctamente una red de destino de color, el color debe tener una asignación de plantilla válida, ya sea a un color específico o a través de la plantilla.color-any Sin una asignación válida, el túnel no se crea y la ruta BGP que solicita resolución sigue sin resolverse.

Resolución de LSP de enrutamiento de segmentos dinámicos sin color

Las rutas generales para los LSP no coloreados se agregan a la tabla de enrutamiento inet.3. El destino del túnel sin color debe configurarse en una configuración diferente con un solo nombre de plantilla en la lista de asignación.spring-te Este nombre de plantilla se utiliza para todas las rutas de túnel que coincidan con cualquiera de las redes de destino configuradas en la misma configuración.spring-te Estos túneles son similares a los túneles RSVP en cuanto a funcionalidad.

El nombre final de la plantilla LSP es una combinación de prefijo y nombre de túnel; Por ejemplo, .<prefix>:dt-srte-<tunnel-name>

Configuración de ejemplo de LSP de enrutamiento de segmentos dinámicos

La plantilla LSP de enrutamiento de segmentos dinámicos siempre lleva una ruta parcial. El SID del nodo del último salto se deriva automáticamente en el momento de la creación del túnel, dependiendo del SID del nodo de la dirección del próximo salto (PNH) del protocolo. La misma plantilla puede ser utilizada por varios túneles a diferentes destinos. En tales casos, la ruta parcial sigue siendo la misma, y solo el último salto cambia dependiendo del PNH. Las plantillas LSP de enrutamiento dinámico de segmentos no son comunes a un solo túnel, por lo que no se puede transportar una ruta completa en él. Puede utilizar una lista de segmentos si se va a utilizar una ruta completa.

LSP de enrutamiento de segmentos dinámicos coloreados

Configuración de ejemplo para LSP de enrutamiento de segmentos dinámicos de color:

Para la configuración de ejemplo mencionada anteriormente, las entradas de ruta son las siguientes:

  1. inetcolor.0 tunnel route: 10.22.44.0-0/24 --> RT_NH_TUNNEL

  2. BGP prefix to tunnel mapping:

    R1(prefijo) -> 10.22.44.55-101(PNH) Nombre del túnel LSP = 10.22.44.55:65:dt-srte-tunnel1

  3. inetcolor.0 tunnel route:

    10.22.44.55-101/64 --> &lt;siguiente-salto>

    10.22.44.55-124/64 --> &lt;siguiente-salto>

LSP de enrutamiento de segmentos dinámicos no coloreados

Configuración de ejemplo para LSP de enrutamiento de segmentos dinámicos no coloreados:

Para la configuración de ejemplo mencionada anteriormente, las entradas de ruta son las siguientes:

  1. inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL

  2. BGP prefix to tunnel mapping:

    R1(prefijo) -> 10.33.44.55(PNH) LSP template name = LSP1 --- 10.33.44.55:dt-srte-tunnel2

  3. inet.3 tunnel route: 10.33.44.55/32 --> &lt;siguiente-salto>

LSP de enrutamiento de segmentos dinámicos no resuelto

Configuración de ejemplo para LSP de enrutamiento de segmentos dinámicos no resueltos:

Para la configuración de ejemplo mencionada anteriormente, las entradas de ruta son las siguientes:

  1. inetcolor.0 tunnel route: 10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0 /24 --> RT_NH_TUNNEL

  2. BGP prefix to tunnel mapping: R1(prefijo) -> 10.33.44.55-124(PNH) No se creará el túnel. (No se encontró la plantilla para el color).

Consideraciones para configurar la creación dinámica de LSP de enrutamiento de segmentos

Al configurar la creación dinámica de LSP de enrutamiento de segmentos, tenga en cuenta lo siguiente:

  • Se puede asignar una plantilla con un objeto de color. Cuando la configuración de túnel dinámico incluye una plantilla con un objeto de color, también debe configurar todas las demás plantillas con objetos de color.spring-te Se supone que todos los destinos están coloreados dentro de esa configuración.

  • Una plantilla puede tener una lista de colores definida en ella, o se puede configurar con la opción.color-any Ambas opciones pueden coexistir en la misma configuración.spring-te En tales casos, las plantillas asignadas con colores específicos tienen una mayor preferencia.

  • En una configuración, solo se puede definir una plantilla con la opción.spring-tecolor-any

  • El mapeo de color a plantilla se realiza de forma individual. Un color no puede asignarse a varias plantillas.

  • El nombre de la plantilla debe configurarse en la instrucción bajo la jerarquía y debe tener habilitada la opción.spring-te[edit protocols]primary

  • Los destinos coloreados y no coloreados no pueden coexistir en la misma configuración.spring-te

  • No puede configurar las mismas redes de destino, con o sin color, en instrucciones de configuración diferentes .spring-te

  • En la configuración sin color , solo se puede configurar una plantilla sin objeto de color.spring-te

Servicios admitidos en los LSP de enrutamiento de segmentos dinámicos

Los siguientes servicios son compatibles con los LSP de enrutamiento de segmentos dinámicos de color:

  • VPN de capa 3

  • BGP EVPN

  • Servicios de política de exportación

Los siguientes servicios son compatibles con los LSP de enrutamiento de segmentos dinámicos no coloreados:

  • VPN de capa 3

  • VPN de capa 2

  • Configuraciones de múltiples rutas

Comportamiento con varios orígenes de túnel en el enrutamiento de segmentos

Cuando dos fuentes descargan rutas al mismo destino desde el enrutamiento de segmentos (por ejemplo, túneles de origen estáticos y dinámicos), se utiliza la preferencia de enrutamiento de segmentos para elegir la entrada de ruta activa. Un valor más alto tiene mayor preferencia. En caso de que la preferencia siga siendo la misma, se utiliza la fuente del túnel para determinar la entrada de la ruta.

Limitaciones de los LSP de enrutamiento de segmentos dinámicos

Los LSP dinámicos de SR-TE no admiten las siguientes características y funcionalidades:

  • Túneles de enrutamiento de segmentos IPv6.

  • Túneles estáticos.

  • 6PE no es compatible.

  • CSPF distribuida.

  • La tunelización de sBFD y LDP no se admite para los LSP de SR-TE dinámicos ni en una plantilla.

  • Instalar rutas y B-SID en una plantilla.

Mapeo basado en colores de servicios VPN

Puede especificar el color como una restricción de protocolo del próximo salto (además de la dirección IPv4 o IPv6) para resolver túneles de transporte sobre LSP de enrutamiento de segmentos BGP (SR-TE) y de color estático. Esto se denomina resolución de próximo salto del protocolo de IP de color, donde debe configurar un mapa de resolución y aplicarlo a los servicios VPN. Con esta función, puede habilitar la dirección de tráfico basada en color de los servicios VPN de capa 2 y capa 3.

Junos OS admite LSP SR-TE de color asociados a un solo color. La función de asignación basada en colores de los servicios VPN es compatible con LSP de colores estáticos y LSP SR-TE BGP.

Coloración del servicio VPN

En general, a un servicio VPN se le puede asignar un color en el enrutador de salida donde se anuncia la NLRI VPN, o en un enrutador de entrada donde se recibe y procesa la NLRI VPN.

Puede asignar un color a los servicios VPN en diferentes niveles:

  • Por instancia de enrutamiento.

  • Por grupo BGP.

  • Por vecino de BGP.

  • Por prefijo.

Una vez que asigna un color, el color se adjunta a un servicio VPN en forma de comunidad extendida de color BGP.

Puede asignar varios colores a un servicio VPN, denominados servicios VPN multicolor. En tales casos, el último color adjunto se considera como el color del servicio VPN, y todos los demás colores se ignoran.

Los dispositivos de salida o entrada asignan varios colores a través de varias políticas en el siguiente orden:

  • Política de exportación de BGP en el dispositivo de salida.

  • Política de importación de BGP en el dispositivo de entrada.

  • Política de importación de VRF en el dispositivo de entrada.

Los dos modos de coloración del servicio VPN son:

Asignación de color de salida

En este modo, el dispositivo de salida (es decir, el anunciante de la NLRI VPN) es responsable de colorear el servicio VPN. Para habilitar este modo, puede definir una política de enrutamiento y aplicarla en la instancia de enrutamiento, la exportación de grupo o la exportación de vecino de grupo del servicio VPN en el nivel jerárquico .vrf-export[edit protocols bgp] BGP anuncia la NLRI VPN con la comunidad extendida de color especificada.

Por ejemplo:

O

Nota:

Cuando aplique la directiva de enrutamiento como una política de exportación de un grupo BGP o vecino de BGP, debe incluir la instrucción en el nivel de BGP, grupo BGP o vecino de BGP para que la directiva surta efecto en la NLRI VPN.vpn-apply-export

Las políticas de enrutamiento se aplican a los NLRI de prefijo VPN de capa 3, NRLI de VPN de capa 2 y NLRI de EVPN. Todas las rutas VPN heredan la comunidad extendida por color, se importan y se instalan en los VRF de destino en uno o varios dispositivos de entrada.

Asignación de color de entrada

En este modo, el dispositivo de entrada (es decir, el receptor de la NLRI VPN) es responsable de colorear el servicio VPN. Para habilitar este modo, puede definir una política de enrutamiento y aplicarla a la instancia de enrutamiento, la importación de grupo o la importación de vecinos de grupo del servicio VPN en el nivel jerárquico .vrf-import[edit protocols bgp] Todas las rutas VPN que coincidan con la política de enrutamiento se adjuntan a la comunidad extendida de color especificada.

Por ejemplo:

O

Especificación del modo de asignación de servicios VPN

Para especificar modos de asignación de servicios VPN flexibles, debe definir una política mediante la instrucción y hacer referencia a la directiva en la instancia de enrutamiento, la importación de grupo o la importación de vecino de grupo de un servicio VPN en el nivel jerárquico.resolution-mapvrf-import[edit protocols bgp] Todas las rutas VPN que coincidan con la política de enrutamiento se adjuntan con el mapa de resolución especificado.

Por ejemplo:

Puede aplicar la política de importación a la instancia de enrutamiento del servicio VPN.

También puede aplicar la directiva de importación a un grupo BGP o vecino de BGP.

Nota:

Cada modo de asignación de servicios VPN debe tener un nombre único definido en el mapa de resolución. Sólo se admite una entrada de color IP en el mapa de resolución, donde las rutas VPN se resuelven mediante el siguiente salto del protocolo IP coloreado en forma de .ip-address:color

Resolución de próximo salto del protocolo Color-IP

El proceso de resolución del protocolo del siguiente salto se ha mejorado para admitir la resolución del siguiente salto del protocolo IP de color. Para un servicio VPN de color, el proceso de resolución del protocolo del siguiente salto toma un color y un mapa de resolución, crea un siguiente salto de protocolo IP de color en forma de , y resuelve el siguiente salto del protocolo en la tabla de enrutamiento inet6color.0.IP-address:color

Debe configurar una política para admitir la resolución de múltiples rutas de servicios VPN de capa 2, VPN de capa 3 o EVPN de color sobre LSP de color. A continuación, la política debe aplicarse con la tabla RIB relevante como política de importación del solucionador.

Por ejemplo:

Respaldo a la resolución del protocolo IP del próximo salto

Si un servicio VPN de color no tiene un mapa de resolución aplicado, el servicio VPN ignora su color y recurre a la resolución del protocolo IP del próximo salto. Por el contrario, si a un servicio VPN no coloreado se le aplica un mapa de resolución, el mapa de resolución se ignora y el servicio VPN utiliza la resolución del próximo salto del protocolo IP.

La reserva es un proceso sencillo que va desde los LSP SR-TE coloreados hasta los LSP LDP, mediante el uso de un grupo RIB para que LDP instale rutas en tablas de enrutamiento inet{6}color.0. Una coincidencia de prefijo más larga para el próximo salto de un protocolo IP de color garantiza que si no existe una ruta LSP SR-TE de color, se debe devolver una ruta LDP con una dirección IP coincidente.

Mapeo basado en color de unidifusión etiquetado con BGP a través de SR-TE

A partir de Junos OS versión 20.2R1, BGP etiquetado como unidifusión (BGP-LU) puede resolver rutas IPv4 o IPv6 a través de ingeniería de tráfico de enrutamiento de segmentos (SR-TE) para las familias de direcciones IPv4 e IPv6. BGP-LU admite la asignación de un color de comunidad BGP y la definición de a para SR-TE.resolution map Se construye un protocolo de color del siguiente salto y se resuelve en un túnel SR-TE de color en la tabla o .inetcolor.0inet6color.0 BGP utiliza y tablas para mapeo no basado en color.inet.3inet6.3 Esto le permite anunciar prefijos BGP-LU IPv6 e IPv4 con una dirección IPv6 del próximo salto en redes solo IPv6 donde los enrutadores no tienen ninguna dirección IPv4 configurada. Con esta característica, actualmente admitimos BGP IPv6 LU sobre SR-TE con base IS-IS.

En , el controlador configura 4 túneles de colores en una red central IPv6 configurada con SR-TE.Figura 9 Cada túnel de color toma una ruta diferente al enrutador D de destino dependiendo del mapa de resolución definido. El controlador configura un túnel SR-TE coloreado para la interfaz 2001:db8::3701:2d05 en el enrutador D. BGP importa políticas para asignar un mapa de color y resolución al prefijo recibido 2001:db8::3700:6/128. Según el color de comunidad asignado, BGP-LU resuelve el siguiente salto coloreado para el prefijo BGP IPv6 LU de acuerdo con la política de mapa de resolución asignada.

Figura 9: LU IPv6 BGP sobre SR-TE IPv6 coloreadoLU IPv6 BGP sobre SR-TE IPv6 coloreado

BGP-LU admite los siguientes escenarios:

  • LU BGP IPv4 sobre BGP IPv4 SR-TE coloreado, con extensiones ISIS/OSPF IPv4 SR.

  • LU BGP IPv4 sobre SR-TE IPv4 estático con y sin color, con extensiones ISIS/OSPF IPv4 SR.

  • LU BGP IPv6 sobre BGP IPv6 SR-TE coloreado, con extensiones ISIS IPv6 SR.

  • LU BGP IPv6 sobre SR-TE IPv6 estático con y sin color, con extensiones ISIS IPv6 SR.

  • Servicios VPN IPv6 de capa 3 con dirección local IPv6 y dirección de vecino IPv6.

  • Servicios VPN IPv6 de capa 3 sobre BGP IPv6 SR-TE, con extensiones ISIS IPv6 SR.

  • Servicios VPN de capa 3 de IPv6 sobre SR-TE IPv6 de color estático y no coloreado, con extensiones de SR IPv6 de ISIS.

Funciones admitidas y no compatibles para la asignación basada en colores de servicios VPN

Las siguientes características y funcionalidades son compatibles con la asignación basada en colores de los servicios VPN:

  • VPN BGP capa 2 (Kompella capa 2 VPN)

  • BGP EVPN

  • Mapa de resolución con una sola opción de color IP.

  • Resolución coloreada del próximo salto de los protocolos IPv4 e IPv6.

  • Base de información de enrutamiento (también conocida como tabla de enrutamiento) reserva basada en grupos a LDP LSP en la tabla de enrutamiento inetcolor.0.

  • Coloreado SR-TE LSP.

  • Plataformas virtuales.

  • Junos OS de 64 bits.

  • Sistemas lógicos.

  • BGP etiquetado como unidifusión.

Las siguientes características y funcionalidades no son compatibles con la asignación basada en colores de los servicios VPN:

  • LSP MPLS de color, como RSVP, LDP, BGP-LU, estáticos.

  • Circuito de capa 2

  • VPN de capa 2 con detección automática de BGP FEC-129 y señalizada por LDP.

  • VPLS

  • MVPN

  • IPv4 e IPv6 mediante resolution-map.

Plantillas de túnel para LSP de enrutamiento de segmentos iniciado por PCE

Puede configurar una plantilla de túnel para que los LSP de enrutamiento de segmentos iniciados por PCE transmitan dos parámetros adicionales para estos LSP: detección de reenvío bidireccional (BFD) y tunelización de LDP.

Cuando se crea un LSP de enrutamiento de segmento iniciado por PCE, el LSP se compara con las instrucciones de política (si las hay) y, si hay una coincidencia, la política aplica la plantilla configurada para ese LSP. La configuración de la plantilla solo se hereda si no la proporciona el origen LSP (PCEP); por ejemplo, métrica.

Para configurar una plantilla:

  1. Incluya la instrucción source-routing-path-template en el nivel jerárquico .source-routing-path-template[edit protocols source-packet-routing] Puede configurar los parámetros adicionales de tunelización BFD y LDP aquí.

  2. Incluya la instrucción source-routing-path-template-map en el nivel jerárquico para enumerar las instrucciones de política con las que se debe comprobar el LSP iniciado por PCE.https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/source-routing-path-template-map-edit-protocols-source-packet-routing.html[edit protocols source-packet-routing]

  3. Defina una política para enumerar los LSP en los que se debe aplicar la plantilla.

    La instrucción puede incluir el nombre LSP o la expresión regular LSP mediante las condiciones de coincidencia y .fromlsplsp-regex Estas opciones son mutuamente excluyentes, por lo que solo puede especificar una opción en un momento dado.

    La instrucción debe incluir la opción con una acción de aceptación.thensr-te-template Esto aplica la plantilla al LSP iniciado por PCE.

Tenga en cuenta lo siguiente al configurar una plantilla para LSP iniciados por PCE:

  • La configuración de la plantilla no se aplica a los LSP de enrutamiento de segmentos configurados estáticamente ni al LSP de enrutamiento de segmentos de ningún otro cliente.

  • La configuración proporcionada por PCEP tiene prioridad sobre la configuración de plantilla.

  • PCEP LSP no hereda la configuración de la lista de segmentos de plantilla.

Ejemplo: Configuración de la ruta conmutada de etiquetas de enrutamiento de segmentos estáticos

En este ejemplo se muestra cómo configurar rutas conmutadas de etiqueta de enrutamiento de segmentos estáticos (LSP) en redes MPLS. Esta configuración ayuda a aportar una mayor escalabilidad a las redes MPLS.

Requisitos

En este ejemplo, se utilizan los siguientes componentes de hardware y software:

  • Siete plataformas de enrutamiento universal 5G serie MX

  • Junos OS versión 18.1 o posterior ejecutándose en todos los enrutadores

Antes de comenzar, asegúrese de configurar las interfaces de dispositivo.

Descripción general

Junos OS configura un conjunto de rutas de enrutamiento de segmentos explícitos en el enrutador de entrada de un túnel de enrutamiento de segmento estático no coloreado configurando la instrucción en el nivel de jerarquía.segment-list[edit protocols source-packet-routing] Puede configurar el túnel de enrutamiento de segmentos configurando la instrucción en el nivel de jerarquía.source-routing-path[edit protocols source-packet-routing] El túnel de enrutamiento de segmentos tiene una dirección de destino y una o más rutas principales y, opcionalmente, rutas secundarias que hacen referencia a la lista de segmentos. Cada lista de segmentos consiste en una secuencia de saltos. Para el túnel de enrutamiento de segmentos estáticos no coloreados, el primer salto de la lista de segmentos especifica una dirección IP de salto siguiente inmediato y el segundo salto a enésimo especifica las etiquetas de identificación de segmento (SID) correspondientes al vínculo o nodo que atraviesa la ruta. La ruta hasta el destino del túnel de enrutamiento de segmentos se instala en la tabla inet.3.

Topología

En este ejemplo, configure VPN de capa 3 en los enrutadores perimetrales del proveedor PE1 y PE5. Configure el protocolo MPLS en todos los enrutadores. El túnel de enrutamiento de segmentos se configura del enrutador PE1 al enrutador PE5 con una ruta principal configurada en el enrutador PE1 y PE5. El enrutador PE1 también está configurado con una ruta secundaria para proteger la ruta. Los enrutadores de tránsito PE2 a PE4 están configurados con etiquetas SID de adyacencia con etiqueta pop y una interfaz de salida.

Figura 10: Etiqueta de enrutamiento de segmento estático Ruta conmutadaEtiqueta de enrutamiento de segmento estático Ruta conmutada

Configuración

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.

PE1

PE2

PE3

PE4

PE5

CE1

CE2

Configuración del dispositivo PE1
Procedimiento paso a paso

El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

Para configurar el dispositivo PE1:

  1. Configure las interfaces.

  2. Configure el número y las opciones del sistema autónomo para controlar las opciones de enrutamiento de reenvío de paquetes.

  3. Configure las interfaces con el protocolo MPLS y configure el intervalo de etiquetas MPLS.

  4. Configure el tipo de grupo del mismo nivel, la dirección local, la familia de protocolos para las NLRI en las actualizaciones y la dirección IP de un vecino para el grupo del mismo nivel.

  5. Configure las interfaces de área de protocolo.

  6. Configure la dirección IPv4 y las etiquetas de las rutas principales y secundarias para las políticas de ingeniería de tráfico de enrutamiento (TE) de protocolo de enrutamiento de paquetes de origen (SPRING).

  7. Configure la dirección IPv4 de destino, la etiqueta SID de enlace, la ruta de enrutamiento de origen principal y secundario para el protocolo SPRING.

  8. Configure las opciones de directiva.

  9. Configure la información de la comunidad BGP.

  10. Configure la instancia de enrutamiento VRF1 con el tipo de instancia, la interfaz, el distintivo del enrutador, la importación, la exportación y la etiqueta de tabla de VRF. Configure la política de exportación y la interfaz de área para el protocolo OSPF.

Resultados

Desde el modo de configuración, escriba los comandos , , , y para confirmar la configuración.show interfacesshow policy-optionsshow protocolsshow routing-optionsshow routing-instances Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Configuración del dispositivo PE2
Procedimiento paso a paso

El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

  1. Configure las interfaces.

  2. Configure el LSP estático para el protocolo MPLS.

  3. Configure las interfaces y el rango de etiquetas estáticas para el protocolo MPLS.

  4. Configure interfaces para el protocolo OSPF.

Resultados

Desde el modo de configuración en el enrutador PE2, confirme su configuración introduciendo los comandos y .show interfacesshow protocols Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.

Verificación

Confirme que la configuración funcione correctamente.

Comprobación de la entrada de ruta de la tabla de enrutamiento inet.3 del enrutador PE1
Propósito

Verifique la entrada de ruta de la tabla de enrutamiento inet.3 del enrutador PE1.

Acción

Desde el modo operativo, ingrese el comando show route table inet.3.

Significado

El resultado muestra las rutas de entrada de los túneles de enrutamiento de segmentos.

Verificación de entradas de tabla de rutas de la tabla de enrutamiento mpls.0 del enrutador PE1
Propósito

Comprobar las entradas de ruta de la tabla de enrutamiento mpls.0

Acción

Desde el modo operativo, ingrese el comando show route table mpls.0.

Significado

El resultado muestra las etiquetas SID de los túneles de enrutamiento de segmentos.

Verificación del LSP de ingeniería de tráfico SPRING del enrutador PE1
Propósito

Verifique los LSP de ingeniería de tráfico SPRING en los enrutadores de entrada.

Acción

Desde el modo operativo, ingrese el comando show spring-traffic-engineering overview .

Significado

El resultado muestra una descripción general de los LSP de ingeniería de tráfico SPRING en el enrutador de entrada.

Verificación de LSP de ingeniería de tráfico SPRING en el enrutador de entrada del enrutador PE1
Propósito

Verifique los LSP de ingeniería de tráfico SPRING en el enrutador de entrada.

Acción

Desde el modo operativo, ingrese el comando show spring-traffic-engineering lsp detail.

Significado

El resultado muestra detalles de los LSP de ingeniería de tráfico SPRING en el enrutador de entrada

Comprobación de las entradas de la tabla de enrutamiento de la tabla de enrutamiento mpls.0 del enrutador PE2
Propósito

Compruebe las entradas de la tabla de enrutamiento mpls.0 de la tabla de enrutamiento PE2.

Acción

Desde el modo operativo, ingrese el comando show route table mpls.0.

Verificación del estado de segmentos LSP MPLS estáticos del enrutador PE2
Propósito

Verifique el estado de los segmentos MPLS LSP del enrutador PE2.

Acción

Desde el modo operativo, ingrese el comando show mpls static-lsp.

Significado

El resultado muestra el estado de los segmentos LSP MPLS estáticos del enrutador PE2.

Habilitación de CSPF distribuido para LSP de enrutamiento de segmentos

Antes de Junos OS versión 19.2R1S1, para la ingeniería de tráfico de rutas de enrutamiento de segmentos, podía configurar explícitamente rutas estáticas o utilizar rutas calculadas desde un controlador externo. Con la característica distribuida Restricted Shortest Path First (CSPF) para LSP de enrutamiento de segmentos, puede calcular un LSP de enrutamiento de segmentos localmente en el dispositivo de entrada según las restricciones que haya configurado. Con esta característica, los LSP se optimizan en función de las restricciones configuradas y el tipo de métrica (ingeniería de tráfico o IGP). Los LSP se calculan para utilizar las rutas ECMP disponibles al destino con la compresión de pila de etiquetas de enrutamiento de segmentos habilitada o deshabilitada.

Restricciones de cálculo de CSPF distribuidas

Las rutas LSP de enrutamiento de segmentos se calculan cuando se cumplen todas las restricciones configuradas.

La característica de cálculo de CSPF distribuida admite el siguiente subconjunto de restricciones especificadas en el borrador de Internet, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineering:

  • Inclusión y exclusión de grupos administrativos.

  • Inclusión de direcciones IP de salto flexible o estricto.

    Nota:

    Solo puede especificar ID de enrutador en las restricciones de salto flexibles o estrictas. Las etiquetas y otras direcciones IP no se pueden especificar como restricciones de salto flexibles o estrictas en Junos OS versión 19.2R1-S1.

  • Número máximo de identificadores de segmento (SID) en la lista de segmentos.

  • Número máximo de listas de segmentos por ruta de enrutamiento de segmento candidato.

La característica de cálculo de CSPF distribuida para los LSP de enrutamiento de segmentos no admite los siguientes tipos de restricciones y escenarios de implementación:

  • Direcciones IPV6.

  • LSP de ingeniería de tráfico de enrutamiento por segmentos entre dominios (SR-TE).

  • Interfaces no numeradas.

  • Múltiples protocolos de enrutamiento, como OSPF, ISIS y BGP-LS, habilitados al mismo tiempo.

  • Cálculo con prefijos o direcciones anycast como destinos.

  • Incluir y excluir direcciones IP de interfaz como restricciones.

Algoritmo de cálculo CSPF distribuido

La función de cálculo de CSPF distribuida para los LSP de enrutamiento de segmentos utiliza el algoritmo de compresión de pila de etiquetas con CSPF.

Compresión de pila de etiquetas habilitada

Una pila de etiquetas comprimidas representa un conjunto de rutas desde un origen hasta un destino. Generalmente consiste en SID de nodo y SID de adyacencia. Cuando la compresión de pila de etiquetas está habilitada, el resultado del cálculo es un conjunto de rutas que maximizan el ECMP al destino, con un número mínimo de SID en la pila, mientras se ajustan a las restricciones.

Compresión de pila de etiquetas deshabilitada

El cálculo de CSPF multiruta con la compresión de pila de etiquetas deshabilitada encuentra hasta listas de segmentos hasta destino, donde:N

  • El costo de todas las listas de segmentos es igual e igual que la métrica de ingeniería de tráfico más corta para llegar al destino.

  • Cada lista de segmentos se compone de SID de adyacencia.

  • El valor de es el número máximo de listas de segmentos permitidas para la ruta candidata por configuración.N

  • No hay dos listas de segmentos idénticas.

  • Cada lista de segmentos satisface todas las restricciones configuradas.

Base de datos de cómputo CSPF distribuida

La base de datos utilizada para el cálculo de SR-TE tiene todos los vínculos, nodos, prefijos y sus características, independientemente de si la ingeniería de tráfico está habilitada en esos nodos publicitarios. En otras palabras, es la unión de la base de datos de ingeniería de tráfico (TED) y la base de datos de estado de enlace IGP de todos los dominios de los que el nodo de computación ha aprendido. Como resultado, para que CSPF funcione, debe incluir la instrucción en el nivel jerárquico .igp-topology[edit protocols isis traffic-engineering]

Configuración de restricciones de cálculo de CSPF distribuidas

Puede usar un perfil de proceso para agrupar lógicamente las restricciones de cálculo. Las rutas de enrutamiento de segmentos hacen referencia a estos perfiles de proceso para calcular los LSP de enrutamiento de segmentos primario y secundario.

Para configurar un perfil de proceso, incluya la instrucción compute-profile en el nivel de jerarquía.compute-profile[edit protocols source-packet-routing]

La configuración de las restricciones de cálculo admitidas incluye:

  • Administrative groups

    Puede configurar grupos de administradores en el nivel jerárquico .admin-groups[edit protocols mpls] Junos OS aplica la configuración del grupo administrativo a las interfaces de ingeniería de tráfico de enrutamiento de segmentos (SR-TE).

    Para configurar las restricciones de cálculo, puede especificar tres categorías para un conjunto de grupos administrativos. La configuración de restricción de cálculo puede ser común a todas las rutas de enrutamiento de segmentos candidatos o puede ser bajo rutas candidatas individuales.

    • include-any: especifica que cualquier vínculo con al menos uno de los grupos administrativos configurados de la lista es aceptable para la ruta que se va a recorrer.

    • include-all: especifica que cualquier vínculo con todos los grupos administrativos configurados en la lista es aceptable para la ruta que se va a recorrer.

    • exclude: especifica que cualquier vínculo que no tenga ninguno de los grupos administrativos configurados en la lista es aceptable para la ruta que se va a recorrer.

  • Explicit path

    Puede especificar una serie de ID de enrutador en el perfil de proceso como restricción para calcular las rutas candidatas de SR-TE . Cada salto tiene que ser una dirección IPv4 y puede ser de tipo estricto o suelto. Si el tipo de salto no está configurado, se utiliza strict. Debe incluir la opción bajo la instrucción segment-list al especificar la restricción de ruta explícita.computesegment-list

  • Maximum number of segment lists (ECMP paths)

    Puede asociar una ruta candidata con una serie de listas de segmentos dinámicas. Las rutas son rutas ECMP, donde cada lista de segmentos se traduce en una puerta de enlace de salto siguiente con peso activo. Estas rutas son el resultado del cálculo de rutas con o sin compresión.

    Puede configurar este atributo mediante la opción situada en la instrucción de configuración del perfil informático .maximum-computed-segment-lists maximum-computed-segment-listscompute-profile Esta configuración determina el número máximo de listas de segmentos calculadas para un LSP primario y secundario determinados.

  • Maximum segment list depth

    El parámetro de cálculo de profundidad máxima de lista de segmentos garantiza que entre las rutas ECMP que satisfagan todas las demás restricciones, como el grupo administrativo, solo se utilicen las rutas que tengan listas de segmentos menores o iguales a la profundidad máxima de lista de segmentos. Cuando se configura este parámetro como una restricción en el perfil de proceso, se invalida la configuración en el nivel de jerarquía, si está presente.maximum-segment-list-depth[edit protocols source-packet-routing]

    Puede configurar este atributo mediante la opción situada en la instrucción de configuración del perfil informático .maximum-segment-list-depth maximum-segment-list-depthcompute-profile

  • Protected or unprotected adjacency SIDs

    Puede configurar SID de adyacencia protegido o no protegido como una restricción en el perfil de proceso para evitar vínculos con el tipo de SID especificado.compute-profile

  • Metric type

    Puede especificar el tipo de métrica en el vínculo que se utilizará para el cálculo. De forma predeterminada, los LSP de SR-TE usan métricas de ingeniería de tráfico de los vínculos para el cálculo. La métrica de ingeniería de tráfico para los enlaces se anuncia mediante extensiones de ingeniería de tráfico de los protocolos IGP. Sin embargo, también puede optar por usar la métrica IGP para el cálculo mediante la configuración de tipo métrico en el perfil de proceso.

    Puede configurar este atributo mediante la opción situada en la instrucción de configuración del perfil informático .metric-type (igp | te)compute-profile

Cálculo distribuido de CSPF

Las rutas candidatas de SR-TE se calculan localmente de manera que satisfagan las restricciones configuradas. Cuando la compresión de pila de etiquetas está deshabilitada, el resultado del cálculo de CSPF de varias rutas es un conjunto de pilas SID de adyacencia. Cuando la compresión de pila de etiquetas está habilitada, el resultado es un conjunto de pilas de etiquetas comprimidas (compuestas por SID adyacentes y SID de nodo).

Cuando se calculan rutas secundarias, los vínculos, nodos y SRLG tomados por las rutas primarias no se evitan para el cálculo. Para obtener más información sobre las rutas principales y secundarias, consulte Configuración de LSP primarios y secundarios.Configuración de LSP primarios y secundarios

Para cualquier LSP con resultado de cálculo incorrecto, el cálculo se vuelve a intentar a medida que cambia la base de datos de ingeniería de tráfico (TED).

Interacción entre la computación CSPF distribuida y las características de SR-TE

Pesos asociados a rutas de una política SR-TE

Puede configurar pesos con rutas de SR-TE calculadas y estáticas, que contribuyen a los siguientes saltos de la ruta. Sin embargo, una sola ruta que tenga habilitada la computación puede dar lugar a varias listas de segmentos. Estas listas de segmentos calculadas se tratan como ECMP entre sí. Puede asignar ponderaciones ECMP jerárquicas a estos segmentos, teniendo en cuenta las ponderaciones asignadas a cada una de las primarias configuradas.

Detección de vivacidad BFD

Puede configurar la detección de vivacidad de BFD para las rutas primarias o secundarias calculadas. Cada ruta primaria o secundaria calculada puede dar como resultado varias listas de segmentos; como resultado, los parámetros BFD configurados en las listas de segmentos se aplican a todas las listas de segmentos calculadas. Si todas las rutas primarias activas dejan de funcionar, la ruta secundaria preprogramada (si se proporciona) se activa.

inherit-label-nexthops

No es necesario habilitar explícitamente la configuración en la jerarquía para las rutas principales o secundarias calculadas, ya que es un comportamiento predeterminado.inherit-label-nexthops[edit protocols source-packet-routing segment-list segment-list-name]

Función de traducción automática

Puede configurar la función de traducción automática en las listas de segmentos, y las rutas principales o secundarias con la función de traducción automática hacen referencia a estas listas de segmentos. Por otro lado, la característica principal o secundaria en la que está habilitada la característica de proceso no puede hacer referencia a ninguna lista de segmentos. Como resultado, no puede habilitar tanto la característica de proceso como la función de traducción automática para una ruta principal o secundaria determinada. Sin embargo, podría tener un LSP configurado con una ruta principal con tipo de proceso y otra con tipo de traducción automática.

Configuraciones de ejemplo de cómputo CSPF distribuido

Ejemplo 1

En el ejemplo 1,

  • La ruta principal no calculada hace referencia a una lista de segmentos configurada. En este ejemplo, se hace referencia a la lista de segmentos configurados, que también sirve como nombre para esta ruta principal.static_sl1

  • Un primario calculado debe tener un nombre configurado y este nombre no debe hacer referencia a ninguna lista de segmentos configurada. En este ejemplo, no es una lista de segmentos configurada.compute_segment1

  • El perfil informático se aplica a la ruta principal con el nombre .compute_profile_redcompute_segment1

  • El perfil de proceso incluye una lista de segmentos de tipo , que se utiliza para especificar la restricción de ruta explícita para el cálculo.compute_profile_redcompute

Los pesos para los próximos saltos de ruta calculada y los siguientes saltos estáticos son 2 y 3, respectivamente. Suponiendo que los siguientes saltos para rutas calculadas son , , y , y que el siguiente salto para ruta estática es , los pesos se aplican de la siguiente manera:comp_nh1comp_nh2comp_nh3static_nh

Siguiente salto

Peso

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Ejemplo 2

En el ejemplo 2, tanto la ruta de acceso principal como la secundaria pueden ser de tipo informático y pueden tener sus propios perfiles de proceso.

Ejemplo 3

En el ejemplo 3, cuando el proceso se menciona en una ruta principal o secundaria, se obtiene el cálculo local de una ruta al destino sin restricciones ni otros parámetros para el cálculo.

Ejemplo: Configuración del reenvío basado en CoS y el enrutamiento basado en políticas para LSP de SR-TE

SUMMARY El reenvío basado en CoS (CBF) y el enrutamiento basado en políticas (PBR, también conocido como reenvío basado en filtros) se pueden habilitar para los LSP con ingeniería de tráfico de enrutamiento de segmentos no coloreados (SR-TE) para dirigir el tráfico selectivo a través de una ruta de SR-TE explícita, lo que le proporciona el beneficio de atender el tráfico según la clase de servicio o una política.

Descripción general del reenvío basado en CoS y el enrutamiento basado en políticas para LSP de SR-TE

Beneficios del reenvío basado en CoS (CBF) y del enrutamiento basado en políticas (PBR) para LSP de SR-TE

Con CBF y PBR usted puede:

  • Utilice combinaciones de rutas de ingeniería de tráfico de enrutamiento de segmentos (SR-TE) para dirigir el tráfico de servicio en el núcleo.

  • Elija los servicios auxiliares que desea resolver en las rutas de SR-TE seleccionadas.

Fuentes de rutas de enrutamiento de segmentos compatibles con CBF y PBR

Los siguientes orígenes de rutas de enrutamiento de segmentos admiten el reenvío basado en CoS y el enrutamiento basado en políticas:

  • Static SR–TE paths: rutas de enrutamiento de origen configuradas estáticamente que tienen toda la pila de etiquetas configurada estáticamente.

  • PCEP: aprovisionamiento dinámico de rutas de enrutamiento de origen creadas en un controlador y descargadas a un enrutador de entrada en una ERO, ya sea mediante extensiones de enrutamiento de segmento PCEP o en una política de enrutamiento de segmento BGP mediante extensiones de enrutamiento de segmento BGP.

  • Dynamic LSPs—Túneles creados dinámicamente activados a través del módulo de túnel dinámico que tienen resolución ERO de último salto.

  • Auto-translated paths: rutas de enrutamiento de origen configuradas estáticamente que se traducen automáticamente.

Consideraciones para configurar CBF y PBR para LSP de SR-TE

Recordar:

  • CBF y PBR solo se habilitan en LSP SR-TE no coloreados que están configurados estática o dinámicamente.

  • Tanto las configuraciones CBF como PBR para los LSP SR-TE pueden coexistir en un dispositivo; El orden de configuración decide el tipo en el que se reenvían las rutas.

  • Para PBR, si el primer salto del LSP SR-TE es una etiqueta, debe incluir la instrucción en el nivel de jerarquía.resolution preserve-nexthop-hiearchy[edit routing-options]

  • El reenvío basado en la clase de rutas para CBF solo es visible en la tabla de reenvío y no en las rutas.

  • El reenvío basado en políticas de rutas para PBR se realiza en las rutas y se ve en la salida del comando.show route

Configurar el reenvío basado en CoS y el enrutamiento basado en políticas para los LSP de SR-TE

SUMMARY El reenvío basado en CoS (CBF) y el enrutamiento basado en políticas (PBR, también conocido como FBF de reenvío basado en filtros) se pueden usar para dirigir el tráfico selectivo mediante una ruta de tráfico de enrutamiento de segmentos explícitos (SR-TE). Solo los LSP de enrutamiento de segmentos no coloreados que tienen el siguiente salto configurado como etiqueta de primer salto o dirección IP admiten CBF y PBR.

Antes de empezar

  • Debe ejecutar Junos OS versión 20.1 y versiones posteriores para habilitar CBF y PBR para LSP SR-TE no coloreados.

  • Configure las interfaces de dispositivos y asegúrese de que los dispositivos estén conectados a la red.

  • Defina listas de segmentos y configure LSP de SR-TE y sus parámetros asociados.

Para configurar un LSP de SR-TE, haga lo siguiente:

  1. Defina la lista de segmentos con parámetros de etiqueta.

    Por ejemplo:

  2. Configure la ruta de enrutamiento de origen para los LSP de SR-TE y especifique el valor de preferencia y el segmento principal para la ruta.

    Por ejemplo:

Ahora puede configurar CBF y PBR para los LSP de SR-TE configurados.

Para configurar CBF, haga lo siguiente

  1. Defina clasificadores de punto de código de servicios diferenciados (DSCP) para controlar paquetes IPv4 entrantes, clases de reenvío y valores de opción.

    Por ejemplo:

  2. Defina clases de reenvío (FC) para agrupar paquetes para su transmisión y asigne paquetes a colas de salida.

    Por ejemplo:

  3. Asigne los clasificadores configurados a las interfaces del dispositivo.

    Por ejemplo:

  4. Defina las opciones de política de reenvío basadas en CoS con el siguiente salto de LSP como el LSP de SR-TE.

    Por ejemplo:

  5. Descarte el tráfico que no cumpla con ninguna clase de reenvío en el mapa del salto siguiente.

    Por ejemplo:

  6. Configure una instrucción de política que especifique que las rutas que coincidan con el filtro de ruta están sujetas a la asignación del próximo salto de CoS especificada por map-name.

    Por ejemplo:

  7. Aplique la política a las rutas que se exportan de la tabla de enrutamiento a la tabla de reenvío. Esto habilita CBF para LSP SR-TE.

    Por ejemplo:

  8. Confirme la configuración.

Verify CBF Configuration

Puede comprobar la configuración CBF mediante el comando.show route forwarding-table destination ip-address vpn vpn-name extensive

Para CBF, el reenvío basado en clases de rutas solo es visible en la tabla de reenvío, a diferencia de PBR, donde las rutas filtradas son visibles en la salida del comando.show route

Para configurar PBR, haga lo siguiente

  1. Configure una instrucción de política que especifique que las rutas que coincidan con el protocolo y el filtro de ruta están sujetas al próximo salto del LSP o tienen un equilibrio de carga como multiruta de acceso de igual costo (ECMP) en la tabla de reenvío.

    Por ejemplo:

  2. Configure el dispositivo para realizar una resolución de ruta personalizada en los siguientes saltos de rutas del protocolo.

    Nota:

    La declaración es obligatoria para que el PBR funcione cuando el primer salto del SR-TE LSP es una etiqueta.resolution preserve-nexthop-hierarchy

  3. Aplique la política a las rutas que se exportan de la tabla de enrutamiento a la tabla de reenvío. Esto habilita el PBR para los LSP de SR-TE.

    Por ejemplo:

  4. Confirme la configuración.

Verify PBR Configuration

Puede comprobar la configuración del PBR mediante el comando.show route destination-prefix

El resultado muestra todos los saltos siguientes para el prefijo de destino, 4.0.0.1. Las opciones muestran los próximos saltos filtrados en el campo de salida.expanded-nh extensiveKrt_inh

Para PBR, la salida del comando realiza el filtrado de rutas basado en políticas.show route

Habilitación de múltiples rutas para LSP de SR-TE en PCEP

Puede configurar varias rutas (primarias o secundarias) para los LSP PCEP SR-TE (configurados estáticamente, delegados e iniciados por PCE) como se define en draft-ietf-pce-multipath-06. Solo se admite una configuración de ruta secundaria y solo para los LSP de SR-TE configurados estáticamente. Las extensiones PCEP definidas en draft-ietf-pce-multipath-06 permiten que PCEP propague múltiples rutas (multipath) para los LSP entre los puntos finales de PCEP.

Beneficios de múltiples rutas para los LSP PCEP SR-TE

  • Los LSP pueden tener varios conjuntos de EROs en un destino

  • Proporciona capacidades de equilibrio de carga mediante la configuración de pesos para EROOs individuales

  • Se alinea con el borrador de la arquitectura SR-TE para definir rutas candidatas

Se admiten las siguientes capacidades de ruta múltiple PCEP:

  • Cuando PCEP para varias rutas está habilitado (predeterminado), puede configurar varias rutas principales (o una secundaria) en una ruta candidata configurada y controlada por PCC.

  • Cuando PCEP para varias rutas está deshabilitado, solo puede configurar una ruta principal en una ruta candidata. No se permite la configuración de rutas secundarias.

Si habilita las múltiples rutas PCEP, ahora se pueden configurar con un número máximo de listas de segmentos () mayor que 1.compute-profilemaximum-computed-segment-lists

Nota:

Cuando PCEP para múltiples rutas está habilitado, PCCD no enviará restricciones para las rutas candidatas controladas por PCC.

Cuando la capacidad de múltiples rutas PCEP está habilitada, se permite la configuración de ruta secundaria para una ruta candidata PCC no delegada, el objeto EXPLICIT-ROUTE (ERO) específico de la ruta secundaria se envía al PCE con el indicador de respaldo establecido para el ERO. Las rutas principales no incluyen MULTIPATH-BACKUP-TLV en el mensaje PCRpt. La ruta secundaria incluye MULTIPATH-BACKUP-TLV con el indicador de copia de seguridad establecido.

Se admiten las siguientes funcionalidades de múltiples rutas de PCEP:

  • TLV DE PESO MULTIRUTA (MULTIPATH-WEIGHT-TLV) en el objeto de atributo de ruta (PATH-ATTRIB)

  • Objeto MULTIPATH-BACKUP TLV en el atributo path (PATH-ATTRIB) solo para LSP SR-TE controlados por PCC

  • TLV MULTIPATH-CAP en objeto LSP PCEP

  • Restringe múltiples rutas primarias y secundarias en la ruta candidata de SR cuando la ruta múltiple PCEP está deshabilitada

  • Múltiples rutas primarias y rutas secundarias en ruta candidata de SR cuando la ruta múltiple PCEP está habilitada para LSP controlados por PCC

  • El segmento calculado máximo enumera () más de 1 en el perfil de cómputo de SR-TE para LSP delegados e iniciados por PCEmax-computed-segment-lists

  • Múltiples EROs para la ruta candidata iniciada por PCE en SR-TE y en PCCD

  • LSP SRv6

  • MPLS de SR (IPv4)

  • Túneles dinámicos MPLS (IPv4) de SR

  • Soporte multicontrolador

  • Múltiples rutas de ERO para rutas candidatas iniciadas por PCE, configuradas y controladas por PCC, y delegadas con color y sin color

  • Compatible con versiones anteriores de Paragon Pathfinder. Para la compatibilidad con versiones anteriores, debe configurar la instrucción de configuración en el nivel de jerarquía [].disable-multipath-capabilityedit protocols pcep

  • Compatibilidad con código de error para errores en la validación de rutas candidatas iniciadas por PCE

    • El total de rutas de subcandidatos por ruta candidata está limitado a 127. Para los LSP iniciados por PCE, si el número de rutas ERO cruza 127, SR-TE arroja ERROR a PCCD (y PCCD envía un mensaje de error PCEP a PCE) y se rechazan las rutas ERO correspondientes.

Se admiten los siguientes mensajes de error de PCEP:

Tabla 5: Mensajes de error de PCEP
Tipo de error Valor de error Significado Uso
19 20 Ruta de copia de seguridad no compatible Esto ocurre cuando el PCC recibe MULTIPATH-BACKUP TLV.
24 1 Parámetros de creación de instancias inaceptables Esto ocurre cuando PCE intenta agregar más de 127 rutas subcandidatas por ruta candidata.

Limitaciones

Se aplican las siguientes limitaciones de PCEP:

  • Los siguientes TLV mencionados en el draft-ietf-pce-multipath-06 no son compatibles:

    • TLV de copia de seguridad de múltiples rutas

    • TLV de ruta de dirección opuesta de múltiples rutas

    • Ruta del candidato compuesto

  • Cuando la capacidad de múltiples rutas está deshabilitada en PCEP, no se permite configurar múltiples rutas candidatas. Sin embargo, en los dispositivos Junos sin capacidad de múltiples rutas (versiones de Junos OS anteriores a 22.4R1), se permite la configuración de varias rutas candidatas. Cuando PCEP multisegmento está habilitado (de forma predeterminada), se permiten múltiples rutas primarias para los LSP controlados por PCC con el fin de informar. Sin embargo, solo se admite una ruta principal para la ruta del candidato delegado cuando PCEP multisegmento está habilitado.

  • Los grupos de administradores y cualquier otra restricción no serán notificados a PCE para las rutas candidatas SR-MPLS y SRv6 configuradas y controladas por PCC (con configuraciones primarias únicas o múltiples). No hay impacto para las rutas candidatas delegadas e iniciadas por PCE.

  • Cuando la capacidad de múltiples rutas PCEP está habilitada, se permite la configuración de rutas secundarias para rutas candidatas no delegadas. Cuando la capacidad de múltiples rutas PCEP está deshabilitada, no se permite la configuración de ruta secundaria.

  • Las rutas candidatas no pueden tener una combinación de LSP iniciados por PCE y delegados.

  • No se admiten varias rutas de subcandidatos para una ruta candidata de color iniciada por PCE.

  • No se admiten entidades de delegación con varias rutas de subcandidatos en una ruta candidata.

Configuración

Para permitir que PCCD envíe TLV con capacidad de múltiples rutas en un objeto LSP para notificar la lista de segmentos calculada máxima para una ruta candidata específica, incluya la instrucción de configuración en el nivel de jerarquía [].propagate-max-segmentlistedit protocols pcep De forma predeterminada, el TLV no se envía en el objeto LSP.

Para deshabilitar la sesión de capacidad múltiple PCEP para todas las PCE, incluya la instrucción de configuración en el nivel de jerarquía [].disable-multipath-capabilityedit protocols pcep

Puede habilitar las siguientes traceoptions de protocolo para el diagnóstico:

  • user@host# set protocols pcep traceoptions ...

  • user@host# set protocols pcep pce pce1 traceoptions ...

  • user@host# set protocols source-packet-routing traceoptions

Puede utilizar los siguientes comandos show para mostrar el estado de los LSP en PCC:

  • user@host> show path-computation-client lsp: muestra el estado de las rutas conmutadas por etiquetas (LSP) conocidas por el cliente de cálculo de rutas (PCC).

  • user@host> show path-computation-client lsp extensive: muestra un amplio nivel de salida de cada LSP conocido: LSP punto a punto y punto a multipunto.

  • user@host> show path-computation active-pce: muestra el estado de varias rutas en las sesiones.

  • user@host> show spring-traffic-engineering lsp detail—Muestra los detalles de entrada de la ingeniería de tráfico de SPRING.

Habilitación de la seguridad de la capa de transporte para sesiones PCEP

La Seguridad de la capa de transporte (TLS) proporciona compatibilidad con la autenticación del mismo nivel, el cifrado de mensajes y la integridad. Puede habilitar TLS en el cliente de cálculo de ruta (PCC) para establecer una conexión TCP con el elemento de cálculo de ruta (PCE) tal como se define en RFC 8253. Esto crea una sesión PCEP segura (PCEPS) para transportar mensajes PCEP.

Este documento describe cómo habilitar TLS para sesiones PCEP para asegurar las interacciones con PCE, incluido el inicio de los procedimientos TLS, el mecanismo de protocolo de enlace TLS y los métodos TLS para la autenticación entre pares. El transporte seguro para PCEP a través de TLS también se conoce como PCEPS.

Beneficios de habilitar TLS para sesiones PCEP

  • Protege las sesiones de PCEP de ataques como suplantación de identidad (suplantación de PCC o PCE), espionaje (interceptación de mensajes), falsificación y denegación de servicio.

  • Aprovecha las ventajas de la seguridad TLS.

Habilitación de TLS en el cliente de cálculo de ruta (PCC)

Para habilitar TLS en PCC y establecer una sesión PCEPS, establezca la instrucción CLI en el nivel jerárquico [].tls-strictedit protocols pcep

Después de habilitar la instrucción tls-strict configuration, ocurren los siguientes eventos:

  1. Colgajos de sesión PCEP. Cualquier conexión TCP existente se termina y se realiza una reconexión mediante TLS.

  2. PCC establece una conexión TCP con el PCE.

  3. Los procedimientos TLS se inician mediante el mensaje de PCE a PCC y de PCC a PCE.StartTLS El mensaje es enviado por PCC y se inicia el temporizador.StartTLSStartTLSWait Puede configurar el temporizador configurando la instrucción CLI en el nivel jerárquico [].StartTLSWaitstart-tls-wait-timer secondsedit protocols pcep pce pce-id

    Nota:

    El valor recomendado para el temporizador es de 60 segundos y no debe ser inferior al temporizador.StartTLSWaitOpenWait El valor predeterminado del temporizador se establece en 60 segundos.OpenWait

    • Si PCC recibe el mensaje Abrir en lugar del mensaje, mensaje con Tipo de error establecido en 1 (error de establecimiento de sesión PCEP) y Valor de error establecido en 1 (recepción de un mensaje abierto no válido o un mensaje no abierto), y la sesión TCP se cierra.StartTLSPCErr

    • Si no se recibe el mensaje de PCE, después de que expire el temporizador, PCC envía un mensaje con Error-Type establecido en 25 (error de PCEP) y Error-value establecido en 5 (sin mensaje (ni) antes de que expire el temporizador), y la sesión TCP se cierra.StartTLSStartTLSWaitPCErrStartTLSStartTLS PCErr/OpenStartTLSWait

  4. Se produce la negociación y el establecimiento de la conexión TLS.

  5. El intercambio de mensajes PCEP se inicia según RFC5440.

Nota:

Si no habilita la instrucción CLI en el nivel de jerarquía [], al establecer una sesión PCEP, si PCC recibe el mensaje en lugar de message, mensaje con Error-Type establecido en 1 (error de establecimiento de sesión PCEP) y Error-value establecido en 1 (recepción de un mensaje abierto no válido o un mensaje no abierto), la sesión TCP se cierra.tls-strictedit protocols pcepStartTLSOpenPCErr

Nota:

Para establecer una sesión PCEPS exitosa, TLS debe estar habilitado tanto en PCC como en PCE.

Actualización de certificados mediante la infraestructura de clave pública (PKI)

La PKI no notifica al PCC sobre la caducidad del certificado. Debe actualizar manualmente el certificado mediante el siguiente comando de CLI. En este método, debe realizar un seguimiento de la fecha de caducidad del certificado.

Establecer una conexión TLS

Los pasos siguientes describen cómo se establece una conexión TLS (mediante TLS v1.2):

  1. Genere certificados para los nodos (dispositivos Junos OS/pce-server). Puede generar los certificados mediante uno de los métodos siguientes:

    • Method 1: genere el par de claves y CSR en el dispositivo y envíe esta CSR a CA para obtener el certificado. Una vez que se emite el certificado, se copia en la caja y se instala.

    • Method 2: genere el par de claves y el certificado listos para usar. Tanto el certificado como la clave privada se copian en el dispositivo y se instalan juntos.

  2. Cargue la entidad de certificación (CA) en la PCC para que el certificado del servidor PCE se pueda validar con la CA cargada.

    Nota:

    Las CA se pueden cargar en jerarquía plana como una CA independiente. Si una CA es una subCA de otra CA, la cadena se construye internamente mediante PKI.

    Nota:

    El certificado de servidor debe estar firmado por una CA. No se permiten certificados autofirmados.

  3. Habilite TLS en PCC.

  4. La sesión PCEP se establece a través de TLS con mecanismo de protocolo de enlace TLS.

  5. El servidor PCE escucha el puerto 4189 para las solicitudes de conexión PCC entrantes a través de TLS.

  6. PCC inicia la solicitud de conexión al puerto de destino 4189.

  7. Al finalizar un protocolo de enlace de tres vías, el protocolo de enlace TLS comienza utilizando los certificados y se realiza la autenticación unidireccional (PCC autentica el certificado del servidor). Tanto el servidor como el cliente esperan tiempo para recibir el mensaje.StartTLSWaitStartTLS Puede configurar el temporizador configurando la instrucción CLI en el nivel jerárquico [].StartTLSWait start-tls-wait-timer secondsedit protocols pcep pce pce-id

    Nota:

    El valor recomendado para el temporizador es de 60 segundos y no debe ser inferior al temporizador.StartTLSWaitOpenWait El valor predeterminado del temporizador se establece en 60 segundos.OpenWait

  8. Después de la sesión de protocolo de enlace TLS exitosa, PCC y PCE inician el establecimiento de la sesión PCEP a través de TLS durante la cual se negocian los parámetros de la sesión.

    • Si se produce un error en la validación del certificado, PCC finaliza la conexión TCP.

  9. El mensaje PCEP se envía a través de la conexión TLS como datos de aplicación.

  10. El cifrado y el descifrado ocurren tanto en PCC como en PCE después de un apretón de manos TLS exitoso.

  11. Cuando se cierra la sesión PCEP, se elimina la sesión TLS.

Nota:

Si el certificado caduca, se revoca o se vuelve a cargar durante una sesión PCEP a través de TLS en curso, la sesión en curso no se verá afectada.

Descripción del mecanismo básico de protocolo de enlace TLS

El apretón de manos es una serie de mensajes intercambiados entre un servidor y un cliente. Los pasos exactos en el protocolo de enlace varían según el algoritmo de intercambio de claves, el conjunto de cifrado, etc. Los siguientes son los pasos básicos del mecanismo de protocolo de enlace TLS:

  1. Client Hello: el cliente inicia el protocolo de enlace enviando este mensaje. Este mensaje contiene la versión de TLS, la lista de algoritmos criptográficos compatibles o el conjunto de cifrado y otros detalles del cliente.

  2. Server Hello: el servidor responde a Client Hello enviando el mensaje Sever Hello. Este mensaje contiene el certificado del servidor, el algoritmo criptográfico seleccionado, el ID de sesión y la clave pública del servidor.

  3. Authentication: el cliente en segundo plano verifica el certificado del servidor con la autoridad de certificación configurada que había emitido el certificado. Tras una verificación exitosa, el cliente confirma que el servidor es genuino y continúa interactuando.

  4. Optional Client Certificate: si el servidor ha solicitado un certificado al cliente en el mensaje Server Hello, el cliente envía el certificado de cliente (solo en caso de TLS mutuo).

  5. Client Key Exchange: el cliente envía la clave secreta cifrada con la clave pública del servidor (adquirida en el mensaje Server Hello).

  6. Decrypt secret key: el servidor descifra la clave secreta mediante la clave privada.

  7. Client Finished: el cliente envía un mensaje de finalización que se cifra con la clave secreta compartida y señala que se ha completado el protocolo de enlace.

  8. Server Finished: el servidor responde con el mensaje de finalización que se cifra con la clave secreta compartida y señala que se ha completado el protocolo de enlace.

  9. Exchange Messages: los mensajes después de completar el protocolo de enlace se cifran simétricamente.

Diagnóstico y validación de TLS para sesiones PCEP

Para el diagnóstico, utilice las siguientes instrucciones de la CLI traceoptions:

Habilite los registros de PKI mediante la siguiente configuración y capture el mismo archivo desde /var/log/<filename>

Compruebe el certificado de CA cargado mediante el siguiente comando:

Salida de muestra

A continuación se muestra un ejemplo de salida del comando:show path-computation-client statistics

Este resultado de ejemplo proporciona la siguiente información:

  • TLS está habilitado en PCC.

  • PCE es compatible con TLS.

  • Se ha establecido la sesión TLS. Esto también indica que el certificado de servidor PCE es válido.

  • El estado de la sesión de PCEPS está en funcionamiento.

Optimización de rutas de informes y métricas calculadas en PCEP

El objeto métrico en PCEP se utiliza para varios propósitos. El objeto de métrica indica el tipo de métrica que se utiliza para la optimización de rutas. El objeto de métrica también indica un límite en el costo de la ruta que no debe superarse para que la ruta se considere aceptable. El objeto métrico también indica la métrica calculada.

Admitimos objetos métricos para la optimización de rutas (protocolo de puerta de enlace interior, ingeniería de tráfico y retraso de ruta) e informes de métricas calculadas para RSVP y LSP SR-TE.

Nota:

El objeto métrico para la optimización de rutas y la generación de informes de métricas calculadas no es aplicable para los LSP SRv6-TE.

Beneficios de la optimización de rutas de informes y métricas calculadas en PCEP

  • Los informes de métricas de optimización de rutas configuradas en PCC ayudan a PCE a conocer las restricciones que se utilizan para el cálculo de rutas.

  • Reporte de métricas computadas al PCE. Esto ayuda a PCE a analizar si el LSP requiere una optimización adicional.

Descripción de las métricas de optimización

En la siguiente sección se describen las métricas de optimización previstas y reales para RSVP y SR-TE (SR MPLS) LSP en PCEP.

LSP de RSVP creado localmente

Para optimizar los LSP de RSVP creados localmente con métricas, configure las métricas de optimización (IGP, TE y retraso de ruta) para que la métrica configurada se informe a través de PCEP. La métrica calculada se envía como una métrica real en PCEP a través del mensaje PCRpt.

LSP de RSVP delegado

Para informar las métricas de optimización para los LSP de RSVP delegados, configure las métricas de optimización (IGP, TE y retraso de ruta).

Intended Metric:

  • Cuando la métrica de optimización está configurada en el momento de la delegación de LSP, la información se envía a PCE a través del mensaje PCRpt.

  • Cuando la métrica de optimización se configura después de la delegación del LSP, el cambio se aplica en el LSP/se comunica al PCE cuando el estado de control del LSP se controla localmente.

  • Cuando se recibe el mensaje PCUpd, si la métrica de optimización está presente en el mensaje, la métrica se utiliza como métrica prevista en mensajes PCRpt posteriores hasta que el estado de control LSP se controla externamente.

  • Cuando se recibe el mensaje PCUpd, si la métrica de optimización no está presente en el mensaje, los mensajes PCRpt posteriores no contienen la métrica deseada.

  • Cuando el estado del control LSP cambia a controlado localmente, la métrica de optimización configurada desde Junos CLI será la métrica deseada en el mensaje PCRpt.

Actual Metric:

  • Al delegar el LSP, el mensaje PCRpt no contiene una métrica real.

  • Cuando se recibe el mensaje PCUpd, si la métrica calculada está presente en el mensaje, la métrica se utiliza como métrica real en mensajes PCRpt posteriores hasta que el estado de control LSP se controla externamente.

  • Cuando se recibe el mensaje PCUpd, si la métrica calculada no está presente en el mensaje, los mensajes PCRpt posteriores no contienen la métrica real.

  • Cuando el estado del control LSP cambia a controlado localmente, la métrica calculada por PCC se envía como métrica real en el mensaje PCRpt.

RSVP LSP iniciado por PCE

Para informar las métricas de optimización para los LSP de RSVP iniciados por PCE, configure las métricas de optimización (IGP, TE y retraso de ruta) en una plantilla. A continuación, la plantilla se aplica al LSP iniciado por PCE cuando el estado de control del LSP se controla localmente.

Intended Metric:

  • Cuando un LSP iniciado por PCE se asigna a una plantilla con métrica de optimización, la configuración se aplica al LSP y se envía al PCE cuando el estado del control LSP cambia a controlado localmente.

  • Cuando se recibe un mensaje PCInit/PCUpd, si la métrica de optimización está presente en el mensaje, la métrica se utiliza como métrica prevista en mensajes PCRpt posteriores hasta que el estado de control LSP se controla externamente.

  • Cuando se recibe el mensaje PCInit/PCUpd, si la métrica de optimización no está presente en el mensaje, los mensajes PCRpt posteriores no contienen la métrica deseada.

  • Cuando el estado del control LSP se controla localmente, la métrica de optimización presente en la plantilla se utiliza como métrica prevista en el mensaje PCRpt.

Actual Metric:

  • Cuando se recibe el mensaje PCInit/PCUpd, si la métrica calculada está presente en el mensaje, la métrica se utiliza como métrica real en los mensajes PCRpt posteriores hasta que el estado de control LSP se controla externamente.

  • Cuando se recibe el mensaje PCInit/PCUpd, si la métrica calculada no está presente en el mensaje, los mensajes PCRpt posteriores no contienen la métrica real.

  • Cuando el estado del control LSP cambia a controlado localmente, la métrica calculada por PCC se envía como métrica real en el mensaje PCRpt.

LSP SR-TE delegado

Para informar las métricas de optimización para los LSP SR-TE (SR MPLS) delegados, configure las métricas de optimización (IGP, TE y retraso de ruta).

Intended Metric:

  • Cuando la métrica de optimización está configurada en el momento de la delegación de LSP, la información se envía al PCE a través del mensaje PCRpt.

  • Cuando la métrica de optimización se configura después de la delegación del LSP, el cambio se aplica en el LSP/se comunica al PCE cuando el estado de control del LSP se controla localmente.

  • Cuando se recibe el mensaje PCUpd, si la métrica de optimización está presente en el mensaje, la métrica se utiliza como métrica prevista en mensajes PCRpt posteriores hasta que el estado de control LSP se controla externamente.

  • Cuando se recibe el mensaje PCUpd, si la métrica de optimización no está presente en el mensaje, los mensajes PCRpt posteriores no contienen la métrica deseada.

  • Cuando el estado del control LSP cambia a controlado localmente, la métrica de optimización configurada desde Junos CLI será la métrica deseada en el mensaje PCRpt.

Actual Metric:

  • Cuando se delega LSP después de la creación, en el momento de la delegación de LSP si LSP tiene 1 ERO, los valores calculados de IGP, TE y métricas de retraso se envían como métricas reales en el mensaje PCRpt.

  • Cuando se delega LSP después de la creación, en el momento de la delegación de LSP, si LSP tiene múltiples ERO, la métrica/métrica real calculada no se envía en el mensaje PCRpt, ya que la métrica real debe enviarse por LSP (no por ERO) en PCEP.

  • Cuando se recibe el mensaje PCUpd, si la métrica calculada está presente en el mensaje, la métrica se utiliza como métrica real en mensajes PCRpt posteriores hasta que el estado de control LSP se controla externamente.

  • Cuando se recibe el mensaje PCUpd, si la métrica calculada no está presente en el mensaje, los mensajes PCRpt posteriores no contienen la métrica real.

  • Cuando el estado del control LSP cambia a controlado localmente, las métricas de IGP, TE y retardo calculadas en PCC se envían como métricas reales en el mensaje PCRpt.

LSP SR-TE iniciado por PCE

Las métricas previstas o las métricas reales enviadas por PCE en mensajes PCInit/PCUpd se informan a PCE a través del mensaje PCRpt hasta que el LSP se controla externamente.

Intended Metric:

  • Cuando se recibe un mensaje PCInit/PCUpd, si la métrica de optimización está presente en el mensaje, la métrica se utiliza como métrica prevista en mensajes PCRpt posteriores hasta que el estado de control LSP se controla externamente.

  • Cuando se recibe el mensaje PCInit/PCUpd, si la métrica de optimización no está presente en el mensaje, los mensajes PCRpt posteriores no contienen la métrica deseada.

  • Cuando el estado de control LSP se controla localmente, no se enviará la métrica deseada.

Actual Metric:

  • Cuando se recibe el mensaje PCInit/PCUpd, si la métrica calculada está presente en el mensaje, la métrica se utiliza como métrica real en los mensajes PCRpt posteriores hasta que el estado de control LSP se controla externamente.

  • Cuando se recibe el mensaje PCInit/PCUpd, si la métrica calculada no está presente en el mensaje, los mensajes PCRpt posteriores no contienen la métrica real.

  • Cuando el estado del control LSP cambia a controlado localmente, los mensajes PCRpt posteriores no contienen una métrica real.

Envío de métricas de optimización en mensaje PCRpt

La métrica de optimización se envía al PCE a través del mensaje en el PCRpt.intended-attributes-list El valor de la métrica se establece en 0 y las banderas B y C se establecen en 0. Tipo de métrica indica la métrica que se va a optimizar.

Envío de métrica calculada en mensaje PCRpt

La métrica calculada se envía al PCE a través del mensaje en el PCRpt.actual-attributes-list El valor de métrica es el valor de métrica calculado y el tipo de métrica indica el tipo de métrica calculada. El indicador B se establece en 0, el indicador C se establece en 1.

Incompatibilidad con versiones anteriores de la métrica de ruta

Dado que la métrica de ruta se admite mediante TLV del proveedor, PCC no procesará la métrica de ruta enviada en objeto métrico por Juniper PCE compatible con Northstar y versiones anteriores de Paragon Pathfinder.

Configuración de métricas de optimización para proveedores de servicios lingüísticos

Puede configurar métricas de optimización (IGP, TE y retraso de ruta) para RSVP LSP y SR-TE LSP.

Para configurar las métricas de IGP, TE y optimización del retraso de ruta para los LSP de RSVP, incluya la instrucción CLI en el nivel de jerarquía [].metric-type <igp|te|delay|delay minimum>edit protocols mpls label-switched-path <lsp-name>

Para configurar las métricas de IGP, TE y optimización del retraso de ruta para los LSP de SR-TE, incluya la instrucción CLI en el nivel de jerarquía [].metric-type <igp|te|delay|delay minimum>edit protocols source-packet-routing compute-profile <compute-profile-name>

Salida de muestra

Puede usar los comandos y CLI para mostrar el estado de las rutas conmutadas por etiquetas (LSP) conocidas por el cliente de cálculo de rutas (PCC).show path-computation-client lspshow path-computation-client lsp extensive

A continuación se muestra un ejemplo de :show path-computation-client lsp extensive

La salida muestra que el LSP está optimizado con el tipo métrico IGP. El valor calculado de la métrica IGP es 50. La métrica Route instalada en la tabla de rutas es 50.

Tabla de historial de cambios

La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.

Liberación
Descripción
21.R1
A partir de Junos OS versión 21.1R1, Junos OS admite el enrutamiento activo sin paradas (NSR) para los LSP punto a punto y punto a multipunto basados en RSVP iniciados por PCE.
21.R1
A partir de Junos OS versión 21.1R1, Junos OS admite el enrutamiento activo sin paradas (NSR) para los LSP punto a multipunto basados en RSVP iniciados por PCE.
20.2R1
A partir de Junos OS versión 20.2R1, BGP etiquetado como unidifusión (BGP-LU) puede resolver rutas IPv4 o IPv6 a través de ingeniería de tráfico de enrutamiento de segmentos (SR-TE) para las familias de direcciones IPv4 e IPv6.
19.4R1
Puede asociar uno o un rango de flujos de multidifusión MVPN (S,G) a una ruta de conmutación de etiquetas (LSP) de punto a multipunto iniciada por PCE creada dinámicamente.
19.4R1
Puede configurar una plantilla de túnel para que los LSP de enrutamiento de segmentos iniciados por PCE transmitan dos parámetros adicionales para estos LSP: detección de reenvío bidireccional (BFD) y tunelización de LDP.
19.1R1
A partir de Junos OS versión 19.1R1, se introduce una función de comprobación de confirmación para garantizar que todas las listas de segmentos que contribuyen a las rutas coloreadas tengan la etiqueta mínima presente para todos los saltos.
19.1R1
A partir de Junos OS versión 19.1R1, este requisito no se aplica, ya que el primer salto de los LSP estáticos no coloreados ahora proporciona compatibilidad con etiquetas SID, además de direcciones IP. Con la compatibilidad con la etiqueta de primer salto, se habilita el reenrutamiento rápido (FRR) MPLS y la multiruta ponderada de igual costo para resolver los LSP de enrutamiento de segmentos estáticos no coloreados, similares a los LSP estáticos de color.
18.2R1
A partir de Junos OS versión 18.2R1, los LSP de enrutamiento de segmentos no coloreados configurados estáticamente en el dispositivo de entrada se notifican al elemento de cálculo de ruta (PCE) a través de una sesión de protocolo de elemento de cálculo de ruta (PCEP).
17.2R1
A partir de Junos OS versión 17.2, además de , se introducen dos nuevos tipos de cálculo de ruta para los LSP controlados por PCE:external cspf local cspf y no cspf.
16.1
A partir de Junos OS versión 16.1, puede proteger una sesión PCEP mediante la autenticación TCP-MD5 según RFC 5440.
16.1
Junos OS versión 16.1 presenta la función de asegurar una sesión PCEP mediante la autenticación TCP-MD5 según RFC 5440.
14.2R4
A partir de Junos OS versión 14.2R4, se proporciona compatibilidad con ancho de banda automático para LSP controlados por PCE.