EN ESTA PÁGINA
Descripción general de la compatibilidad del protocolo de elemento de cálculo de ruta para RSVP-TE
Ejemplo: Configuración del protocolo de elemento de cálculo de ruta para MPLS RSVP-TE
Habilitar el enrutamiento de segmentos para el protocolo de elemento de cálculo de ruta
Etiqueta de enrutamiento de segmento estático Ruta conmutada
Habilitación de CSPF distribuido para LSP de enrutamiento de segmentos
Habilitación de la seguridad de la capa de transporte para sesiones PCEP
Optimización de rutas de informes y métricas calculadas en PCEP
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.
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
- Limitaciones actuales de MPLS RSVP-TE
- Uso de una entidad informática de ruta externa
- Componentes de la computación de ruta externa
- Interacción entre un PCE y un PCC usando PCEP
- Comportamiento de LSP con computación externa
- Instrucciones de configuración admitidas para informática externa
- Protección LSP controlada por PCE
- LSP ERO controlado por PCE
- RSVP-TE LSP de punto a multipunto controlados por PCE
- LSP punto a punto iniciados por PCE
- LSP de derivación iniciado por PCE
- LSP de punto a multipunto iniciados por PCE
- LSP SRv6 en PCEP
- Beneficios de los LSP SRv6 en PCEP
- Ancho de banda automático y LSP controlado por PCE
- Autenticación TCP-MD5 para sesiones PCEP
- Impacto de la implementación de PCE del lado del cliente en el rendimiento de la red
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, Figura 2 se configura con MPLS RSVP-TE, en el que A y G son los enrutadores de borde de etiqueta (LER). 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.
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 lsp-external-controller pccd instrucción en los niveles de [edit mpls] jerarquía y [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.
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.
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 [edit protocols pcep pce pce-id] para una sesión PCEP. Sin embargo, también puede usar un llavero predefinido desde el [edit security authentication-key-chains key-chain] nivel jerárquico para asegurar una sesión PCEP. 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:
-
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.
-
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
delegation cleanup timeoutiniciados por PCE, ylsp cleanup timerpara evitar la interrupción de los servicios. 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 eldelegation cleanup timeoutexpira, 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. 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 ellsp cleanup timertemporizador se detiene.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
lsp cleanup timerpara el LSP iniciado por PCE. 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
lsp cleanup timerexpira 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.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
lsp-cleanup-timerdebe ser mayor o igual que el para quedelegation-cleanup-timeoutel PCC revoque las delegaciones de LSP. 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. -
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 Figura 2, Figura 4 se ilustra la implementación parcial de PCE del lado cliente en la red habilitada para MPLS RSVP-TE. 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.
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
lsp-external-controller pccdinstrucción se denominan LSP controlados por CLI. 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
lsp-external-controller pccdinstrucción configurada se denominan LSP controlados por PCE. 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
lsp-provisioninginstrucción configurada se denominan LSP iniciados por PCE. 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.
|
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. |
|
|
|
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. |
|
|
|
Estas instrucciones de configuración no se pueden configurar junto con la configuración de PCE. |
|
|
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 external cspf, se introducen dos nuevos tipos de cálculo de ruta para los LSP controlados por PCE: local cspf y no cspf.
-
local cspf: un PCC utiliza ellocal cspftipo de cálculo solo cuando el PCE envía una TLV de proveedor de Juniper (número de empresa: 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
no cspfel tipo de cálculo en los siguientes casos:-
Cuando el PCE envía
local cspfTLV y cuando la configuración de Junos OS o la plantilla coincidente para este LSP se incluyeno-cspfen el LSP delegado por PCC. -
Cuando el PCE envía
local cspfTLV y cuando la plantilla de configuración de Junos OS para este LSP se incluyeno-cspfen el LSP iniciado por PCE. -
Cuando el PCE no envía
local cspfTLV con un ERO vacío o ERO suelto (con un bit suelto establecido en el objeto ERO).
-
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 p2mp-lsp-report-capability instrucción en los niveles de [edit protocols pcep pce pce-name] jerarquía o [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 [edit protocols pcep pce pce-id] jerarquía o [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 [edit protocols mpls lsp-external-controller lsp-external-controller] jerarquía.
Cuando finaliza una sesión de PCEP, el PCC inicia dos temporizadores sin eliminar inmediatamente los LSP iniciados por PCE (delegation cleanup timeout y lsp cleanup timer) para evitar la interrupción de los servicios. 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
- Beneficios del LSP de derivación iniciado por PCE
- Comportamiento de los LSP de derivación iniciados por PCE durante la falla de sesión PCEP
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 clear rsvp session, también se puede realizar en los LSP de derivación iniciados por PCE. Puede usar comandos, como show path-computation-client status extensive y show path-computation-client lsp para ver estadísticas de LSP de omisión iniciadas por PCE.
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.
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 srv6-capability configuración en los niveles de jerarquía [edit protocols pcep pce-group pce-idedit protocols pcep pce pce-id] o en []. Si la instrucción de srv6-capability configuración está habilitada, también debe habilitar la instrucción de configuración srv6 en el nivel de jerarquía [edit protocols source-packet-routing] de lo contrario, durante la confirmación y el error se mostrarán.
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.
Para configurar la profundidad máxima de lista de segmentos para SRv6 LSP, debe habilitar la instrucción de maximum-srv6-segment-list-depth configuración en el nivel de jerarquía [edit 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 [edit protocols pcep pce pce-id] para una sesión PCEP. Sin embargo, también puede usar un llavero predefinido desde el [edit security authentication-key-chains key-chain] nivel jerárquico para asegurar una sesión PCEP. 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:
[edit protocols pcep pce pce-id] user@PCC# set authentication-key key
-
Uso del llavero de autenticación predefinido:
[edit protocols pcep pce pce-id] user@PCC# set authentication-key-chain key-chain user@PCC# set authentication-algorithm md5
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.
-
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
show path-computation-client statuscomando yshow protocols pcep. -
Utilice el
show system statistics tcp | match authcomando para ver el número de paquetes que TCP descarta debido a errores de autenticación. -
El funcionamiento del llavero se puede verificar utilizando la salida del
show security keychain detailcomando.
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.
Es necesario instalar el paquete del complemento JSDN junto con el paquete de instalación principal de Junos OS.
Antes de empezar:
Configure las interfaces del dispositivo.
Configure MPLS y RSVP-TE.
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.
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 lsp-external-controller instrucción en el PCC en los niveles jerárquico [edit mpls] y [edit mpls lsp lsp-name] .
lsp-external-controller pccd;
Un LSP configurado con la lsp-external-controller instrucción se denomina LSP controlado por PCE y está bajo el control externo de un PCE de forma predeterminada. 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] .
pcep { ... }
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
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:
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
PCC-to-R2al LSP externo y se está configurando desde el enrutador PCC al enrutador R2. El ERO configurado por CLI esPCC-to-R2PCC-R0-R1-R2. El ancho de banda paraPCC-to-R2es de 10 m y tanto la configuración como los valores de prioridad de retención son 4.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.
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.
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
PCC-to-R2es PCC-R3-R2. El ancho de banda paraPCC-to-R2es de 8 m y los valores de prioridad de configuración y retención son 3.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 [edit] jerarquía.
PCC
set interfaces ge-1/0/1 unit 0 family inet address 20.31.4.1/24 set interfaces ge-1/0/1 unit 0 family iso set interfaces ge-1/0/1 unit 0 family mpls set interfaces ge-1/1/1 unit 0 family inet address 20.31.1.1/24 set interfaces ge-1/1/1 unit 0 family iso set interfaces ge-1/1/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.95/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls lsp-external-controller pccd set protocols mpls label-switched-path PCC-to-R2 to 10.255.179.98 set protocols mpls label-switched-path PCC-to-R2 bandwidth 10m set protocols mpls label-switched-path PCC-to-R2 priority 4 4 set protocols mpls label-switched-path PCC-to-R2 primary to-R2-path set protocols mpls label-switched-path PCC-to-R2 lsp-external-controller pccd set protocols mpls path to-R2-path 20.31.1.2 strict set protocols mpls path to-R2-path 20.31.2.2 strict set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 set protocols pcep pce pce1 destination-ipv4-address 10.209.57.166 set protocols pcep pce pce1 destination-port 4189 set protocols pcep pce pce1 pce-type active set protocols pcep pce pce1 pce-type stateful
R0
set interfaces ge-1/0/6 unit 0 family inet address 20.31.1.2/24 set interfaces ge-1/0/6 unit 0 family iso set interfaces ge-1/0/6 unit 0 family mpls set interfaces ge-1/0/7 unit 0 family inet address 20.31.2.1/24 set interfaces ge-1/0/7 unit 0 family iso set interfaces ge-1/0/7 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.96/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
R1
set system ports console log-out-on-disconnect set interfaces ge-2/0/3 unit 0 family inet address 20.31.2.2/24 set interfaces ge-2/0/3 unit 0 family iso set interfaces ge-2/0/3 unit 0 family mpls set interfaces ge-2/0/4 unit 0 family inet address 20.31.8.1/24 set interfaces ge-2/0/4 unit 0 family iso set interfaces ge-2/0/4 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.97/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
R2
set interfaces ge-1/0/2 unit 0 family inet address 20.31.8.2/24 set interfaces ge-1/0/2 unit 0 family iso set interfaces ge-1/0/2 unit 0 family mpls set interfaces ge-1/0/3 unit 0 family inet address 20.31.5.2/24 set interfaces ge-1/0/3 unit 0 family iso set interfaces ge-1/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.98/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
R3
set interfaces ge-2/0/1 unit 0 family inet address 20.31.4.2/24 set interfaces ge-2/0/1 unit 0 family iso set interfaces ge-2/0/1 unit 0 family mpls set interfaces ge-2/0/3 unit 0 family inet address 20.31.5.1/24 set interfaces ge-2/0/3 unit 0 family iso set interfaces ge-2/0/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.179.99/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis level 1 disable set protocols isis interface all set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0
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.
Para configurar el enrutador PCC:
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.
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.
[edit interfaces]user@PCC# set ge-1/0/1 unit 0 family inet address 20.31.4.1/24 user@PCC# set ge-1/0/1 unit 0 family iso user@PCC# set ge-1/0/1 unit 0 family mpls user@PCC# set ge-1/1/1 unit 0 family inet address 20.31.1.1/24 user@PCC# set ge-1/1/1 unit 0 family iso user@PCC# set ge-1/1/1 unit 0 family mpls user@PCC# set lo0 unit 0 family inet address 10.255.179.95/32Habilite RSVP en todas las interfaces del enrutador PCC, excluyendo la interfaz de administración.
[edit protocols]user@PCC# set rsvp interface all user@PCC# set rsvp interface fxp0.0 disableConfigure 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.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd user@PCC# set mpls label-switched-path PCC-to-R2 to 10.255.179.98/32 user@PCC# set mpls label-switched-path PCC-to-R2 bandwidth 10m user@PCC# set protocols mpls label-switched-path PCC-to-R2 priority 4 4 user@PCC# set protocols mpls label-switched-path PCC-to-R2 primary to-R2-path user@PCC# set protocols mpls label-switched-path PCC-to-R2 lsp-external-controller pccd
Configure el LSP del enrutador PCC al enrutador R2, que tiene control local y es reemplazado por los parámetros LSP proporcionados por PCE.
[edit protocols] user@PCC# set mpls path to-R2-path 20.31.1.2/30 strict user@PCC# set mpls path to-R2-path 20.31.2.2/30 strict
Habilite MPLS en todas las interfaces del enrutador PCC, excluyendo la interfaz de administración.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Configure IS-IS en todas las interfaces del enrutador PCC, excluyendo la interfaz de administración.
[edit protocols] user@PCC# set isis level 1 disable user@PCC# set isis interface all user@PCC# set isis interface fxp0.0 disable user@PCC# set isis interface lo0.0
Defina el PCE al que se conecta el PCC del enrutador y configure la dirección IP del PCE.
[edit protocols] user@PCC# set pcep pce pce1 destination-ipv4-address 10.209.57.166
Configure el puerto de destino para el PCC del enrutador que se conecta a un PCE mediante el PCEP basado en TCP.
[edit protocols] user@PCC# set pcep pce pce1 destination-port 4189
Configure el tipo de PCE.
[edit protocols] user@PCC# set pcep pce pce1 pce-type active user@PCC# set pcep pce pce1 pce-type stateful
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.
user@PCC# show interfaces
ge-1/0/1 {
unit 0 {
family inet {
address 20.31.4.1/24;
}
family iso;
family mpls;
}
}
ge-1/1/1 {
unit 0 {
family inet {
address 20.31.1.1/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.179.95/32;
}
}
}
user@PCC# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
lsp-external-controller pccd;
label-switched-path PCC-to-R2 {
to 10.255.179.98;
bandwidth 10m;
priority 4 4;
primary to-R2-path;
lsp-external-controller pccd;
}
path to-R2-path {
20.31.1.2 strict;
20.31.2.2 strict;
}
interface all;
interface fxp0.0 {
disable;
}
}
isis {
level 1 disable;
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0;
}
pcep {
pce pce1 {
destination-ipv4-address 10.209.57.166;
destination-port 4189;
pce-type active stateful;
}
}
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
- Comprobación del estado de LSP controlado por PCE cuando el control LSP es externo
- Comprobación del estado de LSP controlado por PCE cuando el control LSP es local
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 show path-computation-client active-pce comando.
user@PCC> show path-computation-client active-pce
PCE pce1
General
IP address : 10.209.57.166
Priority : 0
PCE status : PCE_STATE_UP
Session type : PCE_TYPE_STATEFULACTIVE
PCE-mastership : main
Counters
PCReqs Total: 0 last 5min: 0 last hour: 0
PCReps Total: 0 last 5min: 0 last hour: 0
PCRpts Total: 5 last 5min: 5 last hour: 5
PCUpdates Total: 1 last 5min: 1 last hour: 1
Timers
Local Keepalive timer: 30 [s] Dead timer: 120 [s]
Remote Keepalive timer: 30 [s] Dead timer: 120 [s]
Errors
PCErr-recv
PCErr-sent
PCE-PCC-NTFS
PCC-PCE-NTFSSignificado
La salida muestra información sobre el PCE de estado activo actual al que está conectado el PCC del enrutador. El PCE status campo de salida indica el estado actual de la sesión PCEP entre el PCE y el PCC del enrutador.
Para pce1, el estado de la sesión de PCEP es PCE_STATE_UP, lo que indica que la sesión de PCEP se ha establecido entre los pares de PCEP.
Las estadísticas de PCRpts indican el número de mensajes enviados por el enrutador PCC al PCE para informar del estado actual de los LSP. Las PCUpdates estadísticas indican el número de mensajes recibidos por el enrutador PCC desde el PCE. Los PCUpdates mensajes incluyen los parámetros modificados por PCE para los LSP controlados por PCE.
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 show mpls lsp name PCC-to-R2 extensive comando.
user@PCC> show mpls lsp name PCC-to-R2 extensive
Ingress LSP: 1 sessions
10.255.179.98
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
ActivePath: to-R2-path (primary)
LSPtype: Externally controlled, Penultimate hop popping
LSP Control Status: Externally controlled
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary to-R2-path State: Up
Priorities: 3 3
Bandwidth: 8Mbps
SmartOptimizeTimer: 180
No computed ERO.
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
20.31.4.2 20.31.5.2
21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
19 Mar 11 05:00:56.735 Selected as active path
18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
12 Mar 11 05:00:56.712 Originate Call
11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters : 20.31.4.2 20.31.5.2
10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0Significado
En la salida, los LSPtype campos y LSP Control Status de salida muestran que el LSP está controlado externamente. 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 show mpls lsp name PCC-to-R2 extensive comando.
user@PCC> show mpls lsp name PCC-to-R2 extensive
Ingress LSP: 1 sessions
10.255.179.98
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
ActivePath: to-R2-path (primary)
LSPtype: Externally controlled, Penultimate hop popping
LSP Control Status: Locally controlled
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary to-R2-path State: Up
Priorities: 4 4 (ActualPriorities 3 3)
Bandwidth: 10Mbps (ActualBandwidth: 8Mbps)
SmartOptimizeTimer: 180
No computed ERO.
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
20.31.4.2 20.31.5.2
22 Mar 11 05:02:09.618 EXTCTRL_LSP: Control status became local
21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
19 Mar 11 05:00:56.735 Selected as active path
18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
12 Mar 11 05:00:56.712 Originate Call
11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters : 20.31.4.2 20.31.5.2
10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0Significado
En la salida, el LSP Control Status campo de salida muestra que el LSP está bajo control local. 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.
user@PCC> show mpls lsp name PCC-to-R2 extensive externally-controlled
Ingress LSP: 1 sessions
10.255.179.98
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
ActivePath: to-R2-path (primary)
LSPtype: Externally controlled, Penultimate hop popping
LSP Control Status: Locally controlled
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary to-R2-path State: Up
Priorities: 4 4
Bandwidth: 10Mbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
20.31.1.2 S 20.31.2.2 S 20.31.8.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
20.31.1.2 20.31.2.2 20.31.8.2
28 Mar 11 05:02:51.787 Record Route: 20.31.1.2 20.31.2.2 20.31.8.2
27 Mar 11 05:02:51.787 Up
26 Mar 11 05:02:51.697 EXTCTRL_LSP: Applying local parameters with this signalling attempt
25 Mar 11 05:02:51.697 Originate Call
24 Mar 11 05:02:51.696 Clear Call
23 Mar 11 05:02:51.696 CSPF: computation result accepted 20.31.1.2 20.31.2.2 20.31.8.2
22 Mar 11 05:02:09.618 EXTCTRL_LSP: Control status became local
21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
19 Mar 11 05:00:56.735 Selected as active path
18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
16 Mar 11 05:00:56.734 Record Route: 20.31.4.2 20.31.5.2
15 Mar 11 05:00:56.734 Up
14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
12 Mar 11 05:00:56.712 Originate Call
11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters : 20.31.4.2 20.31.5.2
10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains: bandwidth 10000000 priority - setup 4 hold 4 hops: 20.31.1.2 20.31.2.2
1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
El Computed ERO es 20.31.1.2, 20.31.2.2 y 20.31.8.2. 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
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:
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.
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.
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.
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.
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 [edit] jerarquía.
PCC
set interfaces ge-0/1/1 unit 0 family inet address 10.0.102.9/24 set interfaces ge-0/1/1 unit 0 family iso set interfaces ge-0/1/1 unit 0 family mpls set interfaces ge-0/1/3 unit 0 family inet address 10.0.112.14/24 set interfaces ge-0/1/3 unit 0 family iso set interfaces ge-0/1/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.12.1/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls lsp-external-controller ppcd set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols pcep pce-group PCEGROUP pce-type active set protocols pcep pce-group PCEGROUP pce-type stateful set protocols pcep pce-group PCEGROUP lsp-provisioning set protocols pcep pce-group PCEGROUP lsp-cleanup-timer 30 set protocols pcep pce PCE1 destination-ipv4-address 192.168.69.58 set protocols pcep pce PCE1 destination-port 4189 set protocols pcep pce PCE1 pce-group PCEGROUP set protocols pcep pce PCE2 destination-ipv4-address 192.168.70.65 set protocols pcep pce PCE2 destination-port 4189 set protocols pcep pce PCE2 pce-group PCEGROUP
R1
set interfaces ge-3/1/1 unit 0 family inet address 10.0.102.10/24 set interfaces ge-3/1/1 unit 0 family iso set interfaces ge-3/1/1 unit 0 family mpls set interfaces ge-3/1/2 unit 0 family inet address 10.0.101.9/24 set interfaces ge-3/1/2 unit 0 family iso set interfaces ge-3/1/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.10.1/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable
R2
set interfaces ge-0/1/1 unit 0 family inet address 10.0.101.10/24 set interfaces ge-0/1/1 unit 0 family iso set interfaces ge-0/1/1 unit 0 family mpls set interfaces ge-0/1/3 unit 0 family inet address 10.0.112.13/24 set interfaces ge-0/1/3 unit 0 family iso set interfaces ge-0/1/3 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.11.1/32 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable
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.
Para configurar el enrutador PCC:
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.
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.
[edit interfaces]user@PCC# set ge-0/1/1 unit 0 family inet address 10.0.102.9/24 user@PCC# set ge-0/1/1 unit 0 family iso user@PCC# set ge-0/1/1 unit 0 family mpls user@PCC# set ge-0/1/3 unit 0 family inet address 10.0.112.14/24 user@PCC# set ge-0/1/3 unit 0 family iso user@PCC# set ge-0/1/3 unit 0 family mpls user@PCC# set lo0 unit 0 family inet address 192.168.12.1/32Habilite RSVP en todas las interfaces del PCC, excluyendo la interfaz de administración.
[edit protocols]user@PCC# set rsvp interface all user@PCC# set rsvp interface fxp0.0 disableHabilite el control externo de los LSP por parte de los PCE.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd
Habilite MPLS en todas las interfaces del PCC, excluyendo la interfaz de administración.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Configure OSPF en todas las interfaces del PCC, excluyendo la interfaz de administración.
[edit protocols] user@PCC# set ospf traffic-engineering user@PCC# set ospf area 0.0.0.0 interface all user@PCC# set ospf area 0.0.0.0 interface fxp0.0 disable user@PCC# set ospf interface lo0.0
Defina el grupo PCE y habilite la compatibilidad de LSP iniciados por PCE para el grupo PCE.
[edit protocols] user@PCC# set protocols pcep pce-group PCEGROUP pce-type active user@PCC# set protocols pcep pce-group PCEGROUP pce-type stateful user@PCC# set protocols pcep pce-group PCEGROUP lsp-provisioning user@PCC# set protocols pcep pce-group PCEGROUP lsp-cleanup-timer 30
Defina las PCE que se conectan al PCC.
[edit protocols] user@PCC# set pcep pce PCE1 destination-ipv4-address 192.168.69.58 user@PCC# set pcep pce PCE1 destination-port 4189 user@PCC# set pcep pce PCE1 pce-group PCEGROUP user@PCC# set pcep pce PCE2 destination-ipv4-address 192.168.70.65 user@PCC# set pcep pce PCE2 destination-port 4189 user@PCC# set pcep pce PCE2 pce-group PCEGROUP
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.
user@PCC# show interfaces
ge-0/1/1 {
unit 0 {
family inet {
address 10.0.102.9/24;
}
family iso;
family mpls;
}
}
ge-0/1/3 {
unit 0 {
family inet {
address 10.0.112.14/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.12.1/32;
}
}
}
user@PCC# show protocols
rsvp {
interface all;
}
interface fxp0.0 {
disable;
}
}
mpls {
lsp-external-controller pccd;
interface all;
interface fxp0.0 {
disable;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
pce-group PCEGROUP {
pce-type active stateful;
lsp-provisioning;
lsp-cleanup-timer 30;
}
pce PCE1 {
destination-ipv4-address 192.168.69.58;
destination-port 4189;
pce-group PCEGROUP;
}
pce PCE2 {
destination-ipv4-address 192.168.70.65;
destination-port 4189;
pce-group PCEGROUP;
}
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
- Verificación del estado de PCE1
- Comprobación del estado del LSP iniciado por PCE cuando el LSP está aprovisionado externamente
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 show path-computation-client status comando.
user@PCC# show path-computation-client status Session Type Provisioning Status PCE1 Stateful Active On Up PCE2 Stateful Active On Up LSP Summary Total number of LSPs : 1 Static LSPs : 0 Externally controlled LSPs : 0 Externally provisioned LSPs : 1/16000 (current/limit) Orphaned LSPs : 0 PCE1 (main) Delegated : 1 Externally provisioned : 1 PCE2 Delegated : 0 Externally provisioned : 0
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 show path-computation-client active-pce detail comando.
user@PCC# show path-computation-client active-pce PCE PCE1 -------------------------------------------- General IP address : 192.168.69.58 Priority : 0 PCE status : PCE_STATE_UP Session type : PCE_TYPE_STATEFULACTIVE LSP provisioning allowed : On LSP cleanup timer : 30 [s] PCE-mastership : main Max unknown messages : 5 Keepalives received : 0 Keepalives sent : 0 Dead timer : 0 [s] Elapsed as main current : 1 [s] Elapsed as main total : 446380 [s] Unknown msgs/min rate : 0 Session failures : 2198 Corrupted messages : 0 Delegation timeout set : 30 Delegation timeout in : 0 [s] Delegation failures : 0 Connection down : 167092 [s] Counters PCReqs Total: 0 last 5min: 0 last hour: 0 PCReps Total: 0 last 5min: 0 last hour: 0 PCRpts Total: 5 last 5min: 5 last hour: 5 PCUpdates Total: 0 last 5min: 0 last hour: 0 PCCreates Total: 1 last 5min: 1 last hour: 1 Timers Local Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 30 [s] Remote Keepalive timer: 0 [s] Dead timer: 0 [s] LSP cleanup timer: - [s] Errors PCErr-recv PCErr-sent PCE-PCC-NTFS PCC-PCE-NTFS
Significado
La salida muestra información sobre el PCE con estado activo actual al que está conectado el PCC. El PCE status campo de salida indica el estado actual de la sesión de PCEP entre un PCE y un PCC.
Para PCE1, el estado de la sesión de PCEP es PCE_STATE_UP, lo que indica que la sesión de PCEP se ha establecido con el PCC.
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 show mpls lsp externally-provisioned detail comando.
user@PCC# show mpls lsp externally-provisioned detail Ingress LSP: 1 sessions 10.0.101.10 From: 10.0.102.9, State: Up, ActiveRoute: 0, LSPname: lsp15 ActivePath: path1 (primary) Link protection desired LSPtype: Externally Provisioned, Penultimate hop popping LSP Control Status: Externally controlled LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary path1 State: Up Priorities: 7 0 Bandwidth: 8Mbps Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 10.0.102.10 S 10.0.101.9 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 10.0.102.10 S 10.0.101.9 S
Significado
En la salida, el LSPtype campo de salida muestra que el LSP está aprovisionado externamente.
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:
Salida de muestra
[edit]
user@PCC# edit protocols pcep
[edit protocols pcep]
user@PCC# set message-rate-limit 50
[edit protocols pcep]
user@PCC# set max-provisioned-lsps 16000
[edit protocols pcep]
user@PCC# edit pce PCE
[edit protocols pcep pce PCE]
user@PCC# set delegation-cleanup-timeout 20
[edit protocols pcep pce PCE]
user@PCC# set destination-ipv4-address 192.168.69.58
[edit protocols pcep pce PCE]
user@PCC# set destination-port 4189
[edit protocols pcep pce PCE]
user@PCC# set lsp-cleanup-timer 50
[edit protocols pcep pce PCE]
user@PCC# set lsp-provisioning
[edit protocols pcep pce PCE]
user@PCC# set max-unknown-messages 5
[edit protocols pcep pce PCE]
user@PCC# set max-unknown-requests 5
[edit protocols pcep pce PCE]
user@PCC# set request-timer 50
[edit protocols pcep pce PCE]
user@PCC# up
[edit protocols pcep]
user@PCC# show
message-rate-limit 50;
max-provisioned-lsps 16000;
pce PCE {
destination-ipv4-address 192.168.69.58;
destination-port 4189;
lsp-provisioning;
lsp-cleanup-timer 50;
request-timer 50;
max-unknown-requests 5;
max-unknown-messages 5;
delegation-cleanup-timeout 20;
}
[edit protocols pcep]
user@PCC# commit
commit completeEjemplo: 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 p2mp-lsp-report-capability instrucción en los niveles de [edit protocols pcep pce pce-name] jerarquía o [edit protocols pcep pce-group group-id] .
Topología
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:
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.
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.
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.
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.
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 [edit] jerarquía.
PCC
set interfaces ge-0/0/0 unit 0 family inet address 1.2.4.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 1.2.3.1/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 1.2.2.1/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 1.2.5.1/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces ge-0/0/4 unit 0 family inet address 1.4.0.1/30 set interfaces ge-0/0/4 unit 0 family mpls set interfaces ge-0/0/5 unit 0 family inet address 1.2.1.1/30 set interfaces ge-0/0/5 unit 0 family mpls set interfaces ge-0/0/6 unit 0 family inet address 1.2.0.1/30 set interfaces ge-0/0/6 unit 0 family mpls set routing-options autonomous-system 100 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls lsp-external-controller pccd pce-controlled-lsp pcc_delegated_no_cspf_* label-switched-path-template lsp_template_no_cspf set protocols mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_no_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf set protocols mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_loose_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf set protocols mpls traffic-engineering database import policy TE set protocols mpls admin-groups violet 1 set protocols mpls admin-groups indigo 2 set protocols mpls admin-groups blue 3 set protocols mpls admin-groups green 4 set protocols mpls admin-groups yellow 5 set protocols mpls admin-groups orange 6 set protocols mpls label-switched-path lsp_template_no_cspf template set protocols mpls label-switched-path lsp_template_no_cspf no-cspf set protocols mpls label-switched-path lsp1-pcc to 128.102.177.16 set protocols mpls label-switched-path lsp2-pcc to 128.102.177.16 set protocols mpls label-switched-path lsp2-pcc lsp-external-controller pccd set protocols mpls path loose-path 1.2.3.2 loose set protocols mpls path strict-path 1.2.3.2 strict set protocols mpls path strict-path 2.3.3.2 strict set protocols mpls path path-B set protocols mpls path path-C set protocols mpls interface all set protocols mpls interface ge-0/0/6.0 admin-group violet set protocols mpls interface ge-0/0/5.0 admin-group indigo set protocols mpls interface ge-0/0/2.0 admin-group blue set protocols mpls interface ge-0/0/1.0 admin-group green set protocols mpls interface ge-0/0/0.0 admin-group yellow set protocols mpls interface ge-0/0/3.0 admin-group orange set protocols mpls interface fxp0.0 disable set protocols bgp group northstar type internal set protocols bgp group northstar local-address 128.102.180.228 set protocols bgp group northstar family traffic-engineering unicast set protocols bgp group northstar export TE set protocols bgp group northstar neighbor 128.102.180.215 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/6.0 set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p set protocols pcep pce pce1 local-address 10.102.180.228 set protocols pcep pce pce1 destination-ipv4-address 10.102.180.246 set protocols pcep pce pce1 destination-port 4189 set protocols pcep pce pce1 pce-type active set protocols pcep pce pce1 pce-type stateful set protocols pcep pce pce1 lsp-provisioning set protocols pcep pce pce1 lsp-cleanup-timer 0 set protocols pcep pce pce1 delegation-cleanup-timeout 60 set protocols pcep pce pce1 p2mp-lsp-report-capability set policy-options policy-statement TE term 1 from family traffic-engineering set policy-options policy-statement TE term 1 then accept
R1
set interfaces ge-0/0/0 unit 0 family inet address 2.3.4.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 1.2.0.2/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 1.2.4.2/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 1.2.2.2/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces ge-0/0/4 unit 0 family inet address 2.3.1.1/30 set interfaces ge-0/0/4 unit 0 family mpls set interfaces ge-0/0/5 unit 0 family inet address 1.2.3.2/30 set interfaces ge-0/0/5 unit 0 family mpls set interfaces ge-0/0/6 unit 0 family inet address 1.2.5.2/30 set interfaces ge-0/0/6 unit 0 family mpls set interfaces ge-0/0/7 unit 0 family inet address 1.2.1.2/30 set interfaces ge-0/0/7 unit 0 family mpls set interfaces ge-0/0/8 unit 0 family inet address 2.3.5.1/30 set interfaces ge-0/0/8 unit 0 family mpls set interfaces ge-0/0/9 unit 0 family inet address 2.3.2.1/30 set interfaces ge-0/0/9 unit 0 family mpls set interfaces ge-0/1/0 unit 0 family inet address 2.3.3.1/30 set interfaces ge-0/1/0 unit 0 family mpls set interfaces ge-0/1/1 unit 0 family inet address 2.3.0.1/30 set interfaces ge-0/1/1 unit 0 family mpls set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls admin-groups violet 1 set protocols mpls admin-groups indigo 2 set protocols mpls admin-groups blue 3 set protocols mpls admin-groups green 4 set protocols mpls admin-groups yellow 5 set protocols mpls admin-groups orange 6 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols mpls interface ge-0/0/1.0 admin-group violet set protocols mpls interface ge-0/0/7.0 admin-group indigo set protocols mpls interface ge-0/0/3.0 admin-group blue set protocols mpls interface ge-0/0/5.0 admin-group green set protocols mpls interface ge-0/0/2.0 admin-group yellow set protocols mpls interface ge-0/0/6.0 admin-group orange set protocols mpls interface ge-0/1/1.0 admin-group violet set protocols mpls interface ge-0/0/4.0 admin-group indigo set protocols mpls interface ge-0/0/9.0 admin-group blue set protocols mpls interface ge-0/1/0.0 admin-group green set protocols mpls interface ge-0/0/0.0 admin-group yellow set protocols mpls interface ge-0/0/8.0 admin-group orange set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/7.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/6.0 set protocols ospf area 0.0.0.0 interface ge-0/1/1.0
R2
set interfaces ge-0/0/0 unit 0 family inet address 2.3.0.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 2.3.1.2/30 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 2.3.5.2/30 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 2.3.4.2/30 set interfaces ge-0/0/3 unit 0 family mpls set interfaces ge-0/0/4 unit 0 family inet address 2.3.2.2/30 set interfaces ge-0/0/4 unit 0 family mpls set interfaces ge-0/0/5 unit 0 family inet address 2.3.3.2/30 set interfaces ge-0/0/5 unit 0 family mpls set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls admin-groups violet 1 set protocols mpls admin-groups indigo 2 set protocols mpls admin-groups blue 3 set protocols mpls admin-groups green 4 set protocols mpls admin-groups yellow 5 set protocols mpls admin-groups orange 6 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols mpls interface ge-0/0/0.0 admin-group violet set protocols mpls interface ge-0/0/1.0 admin-group indigo set protocols mpls interface ge-0/0/4.0 admin-group blue set protocols mpls interface ge-0/0/5.0 admin-group green set protocols mpls interface ge-0/0/3.0 admin-group yellow set protocols mpls interface ge-0/0/2.0 admin-group orange set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive
R3
set interfaces em0 unit 0 family inet address 10.102.180.215/19 set interfaces em1 unit 0 family inet address 4.5.0.1/30 set interfaces em2 unit 0 family inet address 1.4.0.2/30 set interfaces em2 unit 0 family mpls set routing-options router-id 128.102.180.215 set routing-options autonomous-system 100 set protocols topology-export set protocols rsvp interface all set protocols mpls lsp-external-controller pccd set protocols mpls traffic-engineering database import igp-topology set protocols mpls traffic-engineering database import policy TE set protocols mpls interface all set protocols bgp group northstar type internal set protocols bgp group northstar local-address 128.102.180.215 set protocols bgp group northstar family traffic-engineering unicast set protocols bgp group northstar neighbor 128.102.180.228 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface em2.0 interface-type p2p set policy-options policy-statement TE from family traffic-engineering set policy-options policy-statement TE then accept
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.
Para configurar el enrutador PCC:
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.
[edit interfaces] user@PCC# set ge-0/0/0 unit 0 family inet address 1.2.4.1/30 user@PCC# set ge-0/0/0 unit 0 family mpls user@PCC# set ge-0/0/1 unit 0 family inet address 1.2.3.1/30 user@PCC# set ge-0/0/1 unit 0 family mpls user@PCC# set ge-0/0/2 unit 0 family inet address 1.2.2.1/30 user@PCC# set ge-0/0/2 unit 0 family mpls user@PCC# set ge-0/0/3 unit 0 family inet address 1.2.5.1/30 user@PCC# set ge-0/0/3 unit 0 family mpls user@PCC# set ge-0/0/4 unit 0 family inet address 1.4.0.1/30 user@PCC# set ge-0/0/4 unit 0 family mpls user@PCC# set ge-0/0/5 unit 0 family inet address 1.2.1.1/30 user@PCC# set ge-0/0/5 unit 0 family mpls user@PCC# set ge-0/0/6 unit 0 family inet address 1.2.0.1/30 user@PCC# set ge-0/0/6 unit 0 family mpls
Configure el número de sistema autónomo para el enrutador PCC.
[edit routing-options] user@PCC# set autonomous-system 100
Habilite RSVP en todas las interfaces del enrutador PCC, excluyendo la interfaz de administración.
[edit protocols] user@PCC# set rsvp interface all user@PCC# set rsvp interface fxp0.0 disable
Habilite MPLS en todas las interfaces del enrutador PCC, excluyendo la interfaz de administración.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Configure un LSP dinámico y deshabilite el cálculo automático de rutas para el LSP.
[edit protocols] user@PCC# set mpls label-switched-path lsp_template_no_cspf template user@PCC# set mpls label-switched-path lsp_template_no_cspf no-cspf
Configure LSP punto a multipunto y defina una entidad de informática de ruta externa para el LSP.
[edit protocols] user@PCC# set mpls label-switched-path lsp1-pcc to 128.102.177.16 user@PCC# set mpls label-switched-path lsp2-pcc to 128.102.177.16 user@PCC# set mpls label-switched-path lsp2-pcc lsp-external-controller pccd
Habilite la informática de ruta externa para los LSP MPLS y asigne una plantilla para los LSP aprovisionados externamente.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd pce-controlled-lsp pcc_delegated_no_cspf_* label-switched-path-template lsp_template_no_cspf user@PCC# set mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_no_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf user@PCC# set mpls lsp-external-controller pccd pce-controlled-lsp pce_initiated_loose_ero_no_cspf_* label-switched-path-template lsp_template_no_cspf
Configure los LSP que tienen control local y son reemplazados por los parámetros LSP proporcionados por PCE.
[edit protocols] user@PCC# set mpls path loose-path 1.2.3.2 loose user@PCC# set mpls path strict-path 1.2.3.2 strict user@PCC# set mpls path strict-path 2.3.3.2 strict user@PCC# set mpls path path-B user@PCC# set mpls path path-C
Configure las directivas de grupo administrativo de MPLS para el cálculo de LSP de ruta restringida.
[edit protocols] user@PCC# set mpls admin-groups violet 1 user@PCC# set mpls admin-groups indigo 2 user@PCC# set mpls admin-groups blue 3 user@PCC# set mpls admin-groups green 4 user@PCC# set mpls admin-groups yellow 5 user@PCC# set mpls admin-groups orange 6
Asigne las directivas de grupo administrativas configuradas a las interfaces PCC del enrutador.
[edit protocols] user@PCC# set mpls interface ge-0/0/6.0 admin-group violet user@PCC# set mpls interface ge-0/0/5.0 admin-group indigo user@PCC# set mpls interface ge-0/0/2.0 admin-group blue user@PCC# set mpls interface ge-0/0/1.0 admin-group green user@PCC# set mpls interface ge-0/0/0.0 admin-group yellow user@PCC# set mpls interface ge-0/0/3.0 admin-group orange
Configure una política de importación de bases de datos de ingeniería de tráfico (TED).
[edit protocols] user@PCC# set mpls traffic-engineering database import policy TE
Configure un grupo interno de BGP.
[edit protocols] user@PCC# set bgp group northstar type internal user@PCC# set bgp group northstar local-address 128.102.180.228 user@PCC# set bgp group northstar neighbor 128.102.180.215
Configure la ingeniería de tráfico para BGP y asigne la política de exportación.
[edit protocols] user@PCC# set bgp group northstar family traffic-engineering unicast user@PCC# set bgp group northstar export TE
Configure el área 0 de OSPF en todas las interfaces punto a multipunto del PCC del enrutador.
[edit protocols] user@PCC# set ospf area 0.0.0.0 interface lo0.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/6.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/5.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/2.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/1.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/0.0 user@PCC# set ospf area 0.0.0.0 interface ge-0/0/3.0
Configure el área 0 de OSPF en la interfaz punto a punto del PCC del enrutador.
[edit protocols] user@PCC# set ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p
Habilite la ingeniería de tráfico para OSPF.
[edit protocols] user@PCC# set ospf traffic-engineering
Defina el PCE al que se conecta el PCC del enrutador y configure los parámetros PCE.
[edit protocols] user@PCC# set pcep pce pce1 local-address 10.102.180.228 user@PCC# set pcep pce pce1 destination-ipv4-address 10.102.180.246 user@PCC# set pcep pce pce1 destination-port 4189 user@PCC# set pcep pce pce1 pce-type active user@PCC# set pcep pce pce1 pce-type stateful user@PCC# set pcep pce pce1 lsp-provisioning user@PCC# set pcep pce pce1 lsp-cleanup-timer 0 user@PCC# set pcep pce pce1 delegation-cleanup-timeout 60
Configure el PCC del enrutador para habilitar la capacidad de LSP punto a multipunto para la computación de ruta externa.
[edit protocols] set pcep pce pce1 p2mp-lsp-report-capability
Configure la directiva de ingeniería de tráfico.
[edit policy-options] user@PCC# set policy-statement TE term 1 from family traffic-engineering user@PCC# set policy-statement TE term 1 then accept
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.
user@PCC# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 1.2.4.1/30;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 1.2.3.1/30;
}
family mpls;
}
}
ge-0/0/2 {
unit 0 {
family inet {
address 1.2.2.1/30;
}
family mpls;
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 1.2.5.1/30;
}
family mpls;
}
}
ge-0/0/4 {
unit 0 {
family inet {
address 1.4.0.1/30;
}
family mpls;
}
}
ge-0/0/5 {
unit 0 {
family inet {
address 1.2.1.1/30;
}
family mpls;
}
}
ge-0/0/6 {
unit 0 {
family inet {
address 1.2.0.1/30;
}
family mpls;
}
}
user@PCC# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
lsp-external-controller pccd {
pce-controlled-lsp pcc_delegated_no_cspf_* {
label-switched-path-template {
lsp_template_no_cspf;
}
}
pce-controlled-lsp pce_initiated_no_ero_no_cspf_* {
label-switched-path-template {
lsp_template_no_cspf;
}
}
pce-controlled-lsp pce_initiated_loose_ero_no_cspf_* {
label-switched-path-template {
lsp_template_no_cspf;
}
}
}
traffic-engineering {
database {
import {
policy TE;
}
}
}
admin-groups {
violet 1;
indigo 2;
blue 3;
green 4;
yellow 5;
orange 6;
}
label-switched-path lsp_template_no_cspf {
template;
no-cspf;
}
label-switched-path lsp1-pcc {
to 128.102.177.16;
}
label-switched-path lsp2-pcc {
to 128.102.177.16;
lsp-external-controller pccd;
}
path loose-path {
1.2.3.2 loose;
}
path strict-path {
1.2.3.2 strict;
2.3.3.2 strict;
}
path path-B;
path path-C;
interface all;
interface ge-0/0/6.0 {
admin-group violet;
}
interface ge-0/0/5.0 {
admin-group indigo;
}
interface ge-0/0/2.0 {
admin-group blue;
}
interface ge-0/0/1.0 {
admin-group green;
}
interface ge-0/0/0.0 {
admin-group yellow;
}
interface ge-0/0/3.0 {
admin-group orange;
}
interface fxp0.0 {
disable;
}
}
bgp {
group northstar {
type internal;
local-address 128.102.180.228;
family traffic-engineering {
unicast;
}
export TE;
neighbor 128.102.180.215;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/6.0;
interface ge-0/0/5.0;
interface ge-0/0/2.0;
interface ge-0/0/1.0;
interface ge-0/0/0.0;
interface ge-0/0/3.0;
interface ge-0/0/4.0 {
interface-type p2p;
}
}
}
pcep {
pce pce1 {
local-address 10.102.180.228;
destination-ipv4-address 10.102.180.246;
destination-port 4189;
pce-type active stateful;
lsp-provisioning;
lsp-cleanup-timer 0;
delegation-cleanup-timeout 60;
p2mp-lsp-report-capability;
}
}
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 show mpls lsp extensive comando.
user@PCC> show mpls lsp extensive
Ingress LSP: 2 sessions
128.102.177.16
From: 128.102.180.228, State: Up, ActiveRoute: 0, LSPname: lsp1-pcc
ActivePath: (primary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2)
1.2.1.2 S 2.3.0.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
1.2.1.2 2.3.0.2
6 Jul 12 14:44:10.620 Selected as active path
5 Jul 12 14:44:10.617 Record Route: 1.2.1.2 2.3.0.2
4 Jul 12 14:44:10.615 Up
3 Jul 12 14:44:10.175 Originate Call
2 Jul 12 14:44:10.174 CSPF: computation result accepted 1.2.1.2 2.3.0.2
1 Jul 12 14:43:41.442 CSPF failed: no route toward 128.102.177.16[2 times]
Created: Tue Jul 12 14:42:43 2016
128.102.177.16
From: 128.102.180.228, State: Up, ActiveRoute: 0, LSPname: lsp2-pcc
ActivePath: (primary)
LSPtype: Externally controlled - static configured, Penultimate hop popping
LSP Control Status: Externally controlled
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
External Path CSPF Status: external
SmartOptimizeTimer: 180
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
1.2.4.2 2.3.0.2
50 Jul 12 14:50:14.699 EXTCTRL LSP: Sent Path computation request and LSP status
49 Jul 12 14:50:14.698 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
48 Jul 12 14:49:27.859 EXTCTRL LSP: Sent Path computation request and LSP status
47 Jul 12 14:49:27.859 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
46 Jul 12 14:49:27.858 EXTCTRL LSP: Sent Path computation request and LSP status
45 Jul 12 14:49:27.858 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
44 Jul 12 14:49:27.858 EXTCTRL_LSP: Control status became external
43 Jul 12 14:49:03.746 EXTCTRL_LSP: Control status became local
42 Jul 12 14:46:52.367 EXTCTRL LSP: Sent Path computation request and LSP status
41 Jul 12 14:46:52.367 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
40 Jul 12 14:46:52.367 EXTCTRL LSP: Sent Path computation request and LSP status
39 Jul 12 14:46:52.366 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
38 Jul 12 14:46:52.366 EXTCTRL_LSP: Control status became external
37 Jul 12 14:46:41.584 Selected as active path
36 Jul 12 14:46:41.565 Record Route: 1.2.4.2 2.3.0.2
35 Jul 12 14:46:41.565 Up
34 Jul 12 14:46:41.374 EXTCTRL_LSP: Applying local parameters with this signalling attempt
33 Jul 12 14:46:41.374 Originate Call
32 Jul 12 14:46:41.374 CSPF: computation result accepted 1.2.4.2 2.3.0.2
31 Jul 12 14:46:28.254 EXTCTRL_LSP: Control status became local
30 Jul 12 14:46:12.494 EXTCTRL LSP: Sent Path computation request and LSP status
29 Jul 12 14:46:12.494 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
28 Jul 12 14:45:43.164 EXTCTRL LSP: Sent Path computation request and LSP status
27 Jul 12 14:45:43.164 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
26 Jul 12 14:45:13.424 EXTCTRL LSP: Sent Path computation request and LSP status
25 Jul 12 14:45:13.423 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
24 Jul 12 14:44:44.774 EXTCTRL LSP: Sent Path computation request and LSP status
23 Jul 12 14:44:44.773 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
22 Jul 12 14:44:15.053 EXTCTRL LSP: Sent Path computation request and LSP status
21 Jul 12 14:44:15.053 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
20 Jul 12 14:43:45.705 EXTCTRL LSP: Sent Path computation request and LSP status
19 Jul 12 14:43:45.705 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
18 Jul 12 14:43:45.705 EXTCTRL LSP: Sent Path computation request and LSP status
17 Jul 12 14:43:45.705 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
16 Jul 12 14:43:45.705 EXTCTRL_LSP: Control status became external
15 Jul 12 14:43:42.398 CSPF failed: no route toward 128.102.177.16
14 Jul 12 14:43:13.009 EXTCTRL_LSP: Control status became local
13 Jul 12 14:43:13.009 EXTCTRL LSP: Sent Path computation request and LSP status
12 Jul 12 14:43:13.008 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
11 Jul 12 14:42:43.343 EXTCTRL LSP: Sent Path computation request and LSP status
10 Jul 12 14:42:43.343 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
9 Jul 12 14:42:43.343 EXTCTRL LSP: Sent Path computation request and LSP status
8 Jul 12 14:42:43.343 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
7 Jul 12 14:42:43.342 EXTCTRL LSP: Sent Path computation request and LSP status
6 Jul 12 14:42:43.342 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
5 Jul 12 14:42:43.341 EXTCTRL_LSP: Control status became external
4 Jul 12 14:42:43.337 EXTCTRL_LSP: Control status became local
3 Jul 12 14:42:43.323 EXTCTRL LSP: Sent Path computation request and LSP status
2 Jul 12 14:42:43.323 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 7 hold 0
1 Jul 12 14:42:43.258 EXTCTRL LSP: Awaiting external controller connection
Created: Tue Jul 12 14:42:43 2016
Total 2 displayed, Up 2, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0Significado
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 show path-computation-client active-pce comando.
user@PCC> show path-computation-client active-pce
PCE pce1
--------------------------------------------
General
PCE IP address : 10.102.180.246
Local IP address : 10.102.180.228
Priority : 0
PCE status : PCE_STATE_UP
Session type : PCE_TYPE_STATEFULACTIVE
LSP provisioning allowed : On
P2MP LSP report allowed : On
P2MP LSP update allowed : Off
P2MP LSP init allowed : Off
PCE-mastership : main
Counters
PCReqs Total: 0 last 5min: 0 last hour: 0
PCReps Total: 0 last 5min: 0 last hour: 0
PCRpts Total: 12 last 5min: 0 last hour: 12
PCUpdates Total: 1 last 5min: 0 last hour: 1
PCCreates Total: 0 last 5min: 0 last hour: 0
Timers
Local Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 0 [s]
Remote Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 0 [s]
Errors
PCErr-recv
PCErr-sent
Type: 1 Value: 2 Count: 1
PCE-PCC-NTFS
PCC-PCE-NTFSSignificado
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
- Señalización de LSP punto a multipunto iniciados por PCE
- Comportamiento de los LSP punto a multipunto iniciados por PCE después de una falla de sesión PCEP
- Configuración de la capacidad de LSP punto a multipunto iniciada por PCE
- Características admitidas y no compatibles para LSP punto a multipunto iniciados por PCE
- Asignación de LSP de punto a multipunto iniciados por PCE a MVPN
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 state timeout temporizador. Después de que expira el state timeout temporizador, se limpian los LSP iniciados por PCE.
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 PCInitiate mensaje antes de que caduque el state timeout temporizador.
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 p2mp-lsp-init-capability instrucciones y p2mp-lsp-update-capability en los niveles de [edit protocols pcep pce pce-name] jerarquía o [edit protocols pcep pce-group group-id] .
La p2mp-lsp-init-capability instrucción proporciona la capacidad de aprovisionar LSP RSVP-TE punto a multipunto mediante un PCE. La p2mp-lsp-update-capability instrucción proporciona la capacidad de actualizar los parámetros LSP RSVP-TE punto a multipunto mediante un PCE.
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
PCReportmensaje indique la eliminación de LSP del dispositivo. -
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
pce_traffic_steeringinstrucción en el nivel jerárquico[edit protocols pcep pce pce-id]para indicar la compatibilidad con la capacidad de especificación de flujo (también denominada dirección de tráfico) por parte del PCC. -
Incluya la
external-controllerinstrucción en el[edit routing-instances routing-instance-name provider-tunnel]nivel jerárquico.La presencia de en la configuración del túnel de
external-controllerproveedor para MVPN indica que el controlador externo puede proporcionar el LSP punto a multipunto y (S,G) para esta instancia de MVPN. 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
external-controller pccdinstrucción para una instancia de MVPN determinada, el proceso PCCD no se configura (S,G) dinámicamente. -
Si deshabilita la
external-controller pccdconfiguració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. -
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
external-controller pccdpara una instancia de MVPN determinada, MVPN solicita al proceso PCCD que configure (S,G), si lo hay. -
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).
-
Consulte también
Habilitar el enrutamiento de segmentos para el protocolo de elemento de cálculo de ruta
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
- Ejemplo: Configurar el enrutamiento de segmentos para el protocolo de elemento de cálculo de ruta
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
- Enrutamiento por segmentos para ingeniería de tráfico
- Implementación de Junos OS del enrutamiento por segmentos para PCEP
- Enrutamiento por segmentos para limitaciones de PCEP y características no compatibles
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:
El dispositivo de entrada construye un LSP apilando las etiquetas de los vínculos que desea atravesar.
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.
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).
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
- LSP de enrutamiento por segmentos delegado 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:
Calcula la ruta del LSP de enrutamiento de segmentos.
Aprovisiona el LSP en el cliente de cálculo de ruta (PCC) mediante extensiones de enrutamiento de segmento PCEP.
Analiza las extensiones de enrutamiento del segmento PCEP.
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:
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.
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.
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:
Permanece activo durante 300 segundos.
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), Extensiones PCEP para enrutamiento de segmentos.
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.
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 lsp-external-controller pccd instrucción en el nivel apropiado bajo la [edit protocols source-packet-routing] jerarquía.
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.
Debe incluir la lsp-external-controller pccd instrucción en los niveles de [edit protocols source-packet-routing] jerarquía y [edit protocols mpls] antes de configurar la capacidad de delegación en el PCC.
Fuente del LSP de enrutamiento por segmentos |
Jerarquía de configuración |
|---|---|
|
Lista de segmentos primarios en |
LSP calculados (CSPF distribuido) |
Lista de segmentos principales de la ruta de enrutamiento de origen en:
|
LSP dinámicos |
Lista de segmentos principales de la plantilla de ruta de enrutamiento de origen en:
|
Puede ver el estado de control de los LSP de SR-TE desde la salida del comando show spring-traffic-engineering .
Tabla 3 muestra la interacción PCEP cuando la lsp-external-controller instrucción está configurada para una ruta de enrutamiento de origen.
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 |
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 |
|
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. |
|
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:
Habilite la informática de ruta externa para MPLS incluyendo la
lsp-external-controllerinstrucción en el nivel jerárquico[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.
Habilite la computación de ruta externa para SR-TE incluyendo la
lsp-external-controller pccdinstrucción en el nivel jerárquico[edit protocols spring-traffic-engineering].Habilite el enrutamiento de segmentos para la PCE incluyendo la
spring-capabilityinstrucción en el nivel de[edit protocols pcep pce pce-name]jerarquía.Opcionalmente, configure la profundidad SID máxima para el PCE incluyendo la
max-sid-depth numberinstrucción en el nivel de[edit protocols pcep pce pce-name]jerarquía.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.
Opcionalmente, configure el valor de preferencia para el enrutamiento de segmentos incluyendo el
preference preference-valueen el nivel de[edit protocol spring-te]jerarquía.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.
Opcionalmente, configure el registro de enrutamiento de segmentos para solucionar problemas incluyendo la
traceoptionsinstrucción en el nivel de[edit protocols spring-te]jerarquía.
Para la delegación PCE de LSP de enrutamiento de segmentos, además de los pasos mencionados anteriormente, haga lo siguiente:
Defina una lista de segmentos con parámetros de etiqueta. Esto crea un LSP de enrutamiento de segmento localmente en el PCC.
Habilite la capacidad de delegación del LSP configurado localmente en el PCC incluyendo la
lsp-external-controller pccdinstrucción en cualquiera de las siguientes jerarquías según el origen del LSP de enrutamiento de segmentos:Para rutas de enrutamiento de origen configuradas estáticamente que se calculan con CSPF
[edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name]distribuido y[edit protocols source-packet-routing source-routing-path lsp-name primary path-name]niveles de jerarquía.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:
[edit protocols source-packet-routing source-routing-path lsp-name primary path-name]nivel de jerarquía.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.
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
set interfaces ge-0/0/5 unit 0 family inet address 10.100.41.1/24 set interfaces ge-0/0/5 unit 0 family iso set interfaces ge-0/0/5 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.4/32 primary set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0101.00 set interfaces lo0 unit 0 family mpls set routing-options static route 100.1.1.1/32 next-hop 192.168.100.3 set routing-options router-id 192.168.100.4 set routing-options autonomous-system 64496 set protocols rsvp interface fxp0.0 disable set protocols rsvp interface all set protocols mpls lsp-external-controller pccd set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 101 set protocols isis source-packet-routing node-segment ipv6-index 11 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive set protocols source-packet-routing segment-list static_seg_list_1 hop1 label 800102 set protocols source-packet-routing segment-list static_seg_list_1 hop2 label 800103 set protocols source-packet-routing source-routing-path static_srte_lsp_1 to 192.168.100.3 set protocols source-packet-routing source-routing-path static_srte_lsp_1 primary static_seg_list_1 lsp-external-controller pccd set protocols spring-traffic-engineering lsp-external-controller pccd set protocols source-packet-routing source-routing-path static1 lsp-external-controller pccd set protocols pcep pce pce1 local-address 192.168.100.4 set protocols pcep pce pce1 destination-ipv4-address 10.102.180.232 set protocols pcep pce pce1 destination-port 4189 set protocols pcep pce pce1 pce-type active set protocols pcep pce pce1 pce-type stateful set protocols pcep pce pce1 lsp-provisioning set protocols pcep pce pce1 spring-capability
Enrutador R1
set interfaces ge-0/0/5 unit 0 family inet address 10.100.41.2/24 set interfaces ge-0/0/5 unit 0 family iso set interfaces ge-0/0/5 unit 0 family mpls set interfaces ge-0/1/2 unit 0 family inet address 10.100.12.1/24 set interfaces ge-0/1/2 unit 0 family iso set interfaces ge-0/1/2 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.1/32 primary set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0102.00 set interfaces lo0 unit 0 family mpls set routing-options router-id 192.168.100.1 set routing-options autonomous-system 64496 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 102 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive
Enrutador R2
set interfaces ge-0/1/2 unit 0 family inet address 10.100.12.2/24 set interfaces ge-0/1/2 unit 0 family iso set interfaces ge-0/1/2 unit 0 family mpls set interfaces ge-0/1/8 unit 0 family inet address 10.100.23.1/24 set interfaces ge-0/1/8 unit 0 family iso set interfaces ge-0/1/8 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.2/32 set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0105.00 set interfaces lo0 unit 0 family mpls set routing-options router-id 192.168.100.2 set routing-options autonomous-system 64496 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 105 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface all level 1 disable set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive
Enrutador R3
set interfaces ge-0/1/8 unit 0 family inet address 10.100.23.2/24 set interfaces ge-0/1/8 unit 0 family iso set interfaces ge-0/1/8 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.168.100.3/32 primary set interfaces lo0 unit 0 family iso address 49.0011.0110.0000.0103.00 set interfaces lo0 unit 0 family mpls set routing-options static route 100.1.1.1/32 receive set routing-options router-id 192.168.100.3 set routing-options autonomous-system 64496 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols isis source-packet-routing srgb start-label 800000 set protocols isis source-packet-routing srgb index-range 4000 set protocols isis source-packet-routing node-segment ipv4-index 103 set protocols isis level 1 disable set protocols isis level 2 wide-metrics-only set protocols isis interface all point-to-point set protocols isis interface all level 2 metric 10 set protocols isis interface fxp0.0 disable set protocols isis interface lo0.0 passive
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.
Para configurar el PCC:
Configure las interfaces del PCC.
[edit interfaces] user@PCC# set ge-0/0/5 unit 0 family inet address 10.100.41.1/24 user@PCC# set ge-0/0/5 unit 0 family iso user@PCC# set ge-0/0/5 unit 0 family mpls user@PCC# set lo0 unit 0 family inet address 192.168.100.4/32 primary user@PCC# set lo0 unit 0 family iso address 49.0011.0110.0000.0101.00 user@PCC# set lo0 unit 0 family mpls
Configure el ID del enrutador y asigne un número de sistema autónomo para el PCC.
[edit routing-options] user@PCC# set router-id 192.168.100.4 user@PCC# set autonomous-system 64496
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.
[edit routing-options] user@PCC# set static route 100.1.1.1/32 next-hop 192.168.100.3
Configure RSVP en todas las interfaces del PCC, excluyendo la interfaz de administración.
[edit protocols] user@PCC# set rsvp interface fxp0.0 disable user@PCC# set rsvp interface all
Configure MPLS en todas las interfaces del PCC, excluyendo la interfaz de administración.
[edit protocols] user@PCC# set mpls interface all user@PCC# set mpls interface fxp0.0 disable
Habilite la capacidad de computación de ruta externa para MPLS.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd
Configure IS-IS nivel 2 en todas las interfaces del PCC, excluyendo las interfaces de administración y de circuito cerrado.
[edit protocols] user@PCC# set isis level 1 disable user@PCC# set isis level 2 wide-metrics-only user@PCC# set isis interface all point-to-point user@PCC# set isis interface all level 2 metric 10 user@PCC# set isis interface fxp0.0 disable user@PCC# set isis interface lo0.0 passive
Configure los atributos de bloque global de enrutamiento de segmentos (SRGB) para el enrutamiento de segmentos.
[edit protocols] user@PCC# set isis source-packet-routing srgb start-label 800000 user@PCC# set isis source-packet-routing srgb index-range 4000 user@PCC# set isis source-packet-routing node-segment ipv4-index 101 user@PCC# set isis source-packet-routing node-segment ipv6-index 11
Habilite la capacidad de computación de ruta externa para SR-TE.
[edit protocols] user@PCC# set spring-traffic-engineering lsp-external-controller pccd
Configure los parámetros PCE y habilite el aprovisionamiento del LSP por parte del PCE y la capacidad de enrutamiento de segmentos.
[edit protocols] user@PCC# set pcep pce pce1 local-address 192.168.100.4 user@PCC# set pcep pce pce1 destination-ipv4-address 10.102.180.232 user@PCC# set pcep pce pce1 destination-port 4189 user@PCC# set pcep pce pce1 pce-type active user@PCC# set pcep pce pce1 pce-type stateful
Habilite el aprovisionamiento de LSP de enrutamiento por segmentos por parte de la PCE.
[edit protocols] user@PCC# set pcep pce pce1 lsp-provisioning
Habilite la capacidad de enrutamiento de segmentos para el PCE.
[edit protocols] user@PCC# set pcep pce pce1 spring-capability
Defina los parámetros de la lista
static_seg_list_1de segmentos estáticos.[edit protocols] user@PCC# set source-packet-routing segment-list static_seg_list_1 hop1 label 800102 user@PCC# set source-packet-routing segment-list static_seg_list_1 hop2 label 800103
Configure un LSP de enrutamiento de segmento estático desde el PCC al enrutador R3 para la delegación PCE.
[edit protocols] user@PCC# set source-packet-routing source-routing-path static_srte_lsp_1 to 192.168.100.3
Habilite la capacidad de delegación para la
static_srte_lsp_1ruta de enrutamiento de origen.[edit protocols] user@PCC# set source-packet-routing source-routing-path static_srte_lsp_1 primary static_seg_list_1 lsp-external-controller pccd
Al completar los pasos 13, 14 y 15, permite que el PCC delegue los LSP de enrutamiento de segmento al PCE.
Confirme la configuración.
Resultados
Desde el modo de configuración, escriba los comandos , y show protocols para confirmar la show interfacesconfiguración. show routing-options Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@PCC# show interfaces
ge-0/0/5 {
unit 0 {
family inet {
address 10.100.41.1/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.168.100.4/32 {
primary;
}
}
family iso {
address 49.0011.0110.0000.0101.00;
}
family mpls;
}
}
user@PCC# show routing-options
static {
route 100.1.1.1/32 next-hop 192.168.100.3;
}
router-id 192.168.100.4;
autonomous-system 64496;
user@PCC# show protocols
rsvp {
interface fxp0.0 {
disable;
}
interface all;
}
mpls {
lsp-external-controller pccd;
interface all;
interface fxp0.0 {
disable;
}
}
isis {
source-packet-routing {
srgb start-label 800000 index-range 4000;
node-segment {
ipv4-index 101;
ipv6-index 11;
}
}
level 1 disable;
level 2 wide-metrics-only;
interface all {
point-to-point;
level 2 metric 10;
}
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
spring-traffic-engineering {
lsp-external-controller pccd;
}
source-packet-routing {
segment-list static_seg_list_1 {
hop1 label 800102
hop1 label 800102
}
source-routing-path static_srte_lsp_1 {
to 192.168.100.3;
primary {
static_seg_list_1 {
lsp-external-controller pccd;
}
}
}
}
pcep {
pce pce1 {
local-address 192.168.100.4;
destination-ipv4-address 10.102.180.232;
destination-port 4189;
pce-type active stateful;
lsp-provisioning;
spring-capability;
}
}
Si ha terminado de configurar el dispositivo (el PCC), ingrese commit desde el modo de configuración.
Verificación
Confirme que la configuración funcione correctamente.
- Verificar la adyacencia y las etiquetas de IS-IS
- Comprobar la base de datos de ingeniería de tráfico
- Verificar los LSP de SR-TE
- Verificar la creación de rutas de túnel
- Comprobar las entradas de la tabla de reenvío
- Verificar el uso de rutas de túnel para el reenvío de rutas estáticas
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 show isis adjacency extensivecomandos , show isis database extensivey show isis overview .
user@PCC> show isis adjacency extensive R1 Interface: ge-0/0/5.0, Level: 2, State: Up, Expires in 25 secs Priority: 0, Up/Down transitions: 1, Last transition: 00:37:15 ago Circuit type: 2, Speaks: IP, IPv6 Topologies: Unicast Restart capable: Yes, Adjacency advertisement: Advertise IP addresses: 10.100.41.2 Level 2 IPv4 Adj-SID: 16 Transition log: When State Event Down reason Wed Apr 5 02:42:48 Up Seenself PCE Interface: gre.0, Level: 2, State: Up, Expires in 25 secs Priority: 0, Up/Down transitions: 1, Last transition: 00:27:00 ago Circuit type: 2, Speaks: IP, IPv6 Topologies: Unicast Restart capable: Yes, Adjacency advertisement: Advertise IP addresses: 11.105.199.2 Level 2 Transition log: When State Event Down reason Wed Apr 5 02:53:03 Up Seenself
user@PCC> show isis database extensive
IS-IS level 1 link-state database:
IS-IS level 2 link-state database:
PCC.00-00 Sequence: 0x2a6, Checksum: 0x1a4f, Lifetime: 1150 secs
IPV4 Index: 101
Node Segment Blocks Advertised:
Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ]
IS neighbor: R1.00 Metric: 10
Two-way fragment: R1.00-00, Two-way first fragment: R1.00-00
IS neighbor: PCE.00 Metric: 16777215
IP prefix: 192.168.100.4/32 Metric: 0 Internal Up
IP prefix: 11.101.102.0/30 Metric: 10 Internal Up
IP prefix: 11.105.199.0/30 Metric: 16777215 Internal Up
Header: LSP ID: PCC.00-00, Length: 243 bytes
Allocated length: 1492 bytes, Router ID: 192.168.100.4
Remaining lifetime: 1150 secs, Level: 2, Interface: 0
Estimated free bytes: 1084, Actual free bytes: 1249
Aging timer expires in: 1150 secs
Protocols: IP, IPv6
Packet: LSP ID: PCC.00-00, Length: 243 bytes, Lifetime : 1198 secs
Checksum: 0x1a4f, Sequence: 0x2a6, Attributes: 0x3 L1 L2
NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes
Packet type: 20, Packet version: 1, Max area: 0
TLVs:
Area address: 49.0011 (3)
LSP Buffer Size: 1492
Speaks: IP
Speaks: IPV6
IP router id: 192.168.100.4
IP address: 192.168.100.4
Hostname: PCC
IS extended neighbor: R1.00, Metric: default 10
IP address: 10.100.41.1
Neighbor's IP address: 10.100.41.2
Local interface index: 334, Remote interface index: 333
Current reservable bandwidth:
Priority 0 : 10Mbps
Priority 1 : 10Mbps
Priority 2 : 10Mbps
Priority 3 : 10Mbps
Priority 4 : 10Mbps
Priority 5 : 10Mbps
Priority 6 : 10Mbps
Priority 7 : 10Mbps
Maximum reservable bandwidth: 10Mbps
Maximum bandwidth: 10Mbps
Administrative groups: 0 none
P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16
IS extended neighbor: PCE.00, Metric: default 16777215
IP address: 11.105.199.1
Neighbor's IP address: 11.105.199.2
Local interface index: 329, Remote interface index: 329
IP extended prefix: 11.101.102.0/30 metric 10 up
IP extended prefix: 11.105.199.0/30 metric 16777215 up
IP extended prefix: 192.168.100.4/32 metric 0 up
8 bytes of subtlvs
Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 101
Router Capability: Router ID 192.168.100.4, Flags: 0x00
SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000
SPRING Algorithm - Algo: 0
No queued transmissions
R1.00-00 Sequence: 0x297, Checksum: 0x1615, Lifetime: 839 secs
IPV4 Index: 102
Node Segment Blocks Advertised:
Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ]
IS neighbor: PCC.00 Metric: 10
Two-way fragment: PCC.00-00, Two-way first fragment: PCC.00-00
IS neighbor: R2.00 Metric: 10
Two-way fragment: R2.00-00, Two-way first fragment: R2.00-00
IP prefix: 192.168.100.1/32 Metric: 0 Internal Up
IP prefix: 11.101.102.0/30 Metric: 10 Internal Up
IP prefix: 11.102.105.0/30 Metric: 10 Internal Up
Header: LSP ID: R1.00-00, Length: 302 bytes
Allocated length: 302 bytes, Router ID: 192.168.100.1
Remaining lifetime: 839 secs, Level: 2, Interface: 334
Estimated free bytes: 0, Actual free bytes: 0
Aging timer expires in: 839 secs
Protocols: IP, IPv6
Packet: LSP ID: R1.00-00, Length: 302 bytes, Lifetime : 1196 secs
Checksum: 0x1615, Sequence: 0x297, Attributes: 0x3 L1 L2
NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes
Packet type: 20, Packet version: 1, Max area: 0
TLVs:
Area address: 49.0011 (3)
LSP Buffer Size: 1492
Speaks: IP
Speaks: IPV6
IP router id: 192.168.100.1
IP address: 192.168.100.1
Hostname: R1
IP extended prefix: 192.168.100.1/32 metric 0 up
8 bytes of subtlvs
Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 102
IP extended prefix: 11.101.102.0/30 metric 10 up
IP extended prefix: 11.102.105.0/30 metric 10 up
Router Capability: Router ID 192.168.100.1, Flags: 0x00
SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000
SPRING Algorithm - Algo: 0
IS extended neighbor: R2.00, Metric: default 10
IP address: 10.100.12.1
Neighbor's IP address: 10.100.12.2
Local interface index: 334, Remote interface index: 333
Current reservable bandwidth:
Priority 0 : 10Mbps
Priority 1 : 10Mbps
Priority 2 : 10Mbps
Priority 3 : 10Mbps
Priority 4 : 10Mbps
Priority 5 : 10Mbps
Priority 6 : 10Mbps
Priority 7 : 10Mbps
Maximum reservable bandwidth: 10Mbps
Maximum bandwidth: 10Mbps
Administrative groups: 0 none
P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 17
IS extended neighbor: PCC.00, Metric: default 10
IP address: 10.100.41.2
Neighbor's IP address: 10.100.41.1
Local interface index: 333, Remote interface index: 334
Current reservable bandwidth:
Priority 0 : 10Mbps
Priority 1 : 10Mbps
Priority 2 : 10Mbps
Priority 3 : 10Mbps
Priority 4 : 10Mbps
Priority 5 : 10Mbps
Priority 6 : 10Mbps
Priority 7 : 10Mbps
Maximum reservable bandwidth: 10Mbps
Maximum bandwidth: 10Mbps
Administrative groups: 0 none
P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16
No queued transmissions
R3.00-00 Sequence: 0x95, Checksum: 0xd459, Lifetime: 895 secs
IPV4 Index: 103
Node Segment Blocks Advertised:
Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ]
IS neighbor: R2.00 Metric: 10
Two-way fragment: R2.00-00, Two-way first fragment: R2.00-00
IP prefix: 192.168.100.3/32 Metric: 0 Internal Up
IP prefix: 11.102.1.0/24 Metric: 10 Internal Up
IP prefix: 11.103.107.0/30 Metric: 10 Internal Up
Header: LSP ID: R3.00-00, Length: 209 bytes
Allocated length: 284 bytes, Router ID: 192.168.100.3
Remaining lifetime: 895 secs, Level: 2, Interface: 334
Estimated free bytes: 75, Actual free bytes: 75
Aging timer expires in: 895 secs
Protocols: IP, IPv6
Packet: LSP ID: R3.00-00, Length: 209 bytes, Lifetime : 1192 secs
Checksum: 0xd459, Sequence: 0x95, Attributes: 0x3 L1 L2
NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes
Packet type: 20, Packet version: 1, Max area: 0
TLVs:
Area address: 49.0011 (3)
LSP Buffer Size: 1492
Speaks: IP
Speaks: IPV6
IP router id: 192.168.100.3
IP address: 192.168.100.3
Hostname: R3
IS extended neighbor: R2.00, Metric: default 10
IP address: 10.100.23.2
Neighbor's IP address: 10.100.23.1
Local interface index: 336, Remote interface index: 334
Current reservable bandwidth:
Priority 0 : 10Mbps
Priority 1 : 10Mbps
Priority 2 : 10Mbps
Priority 3 : 10Mbps
Priority 4 : 10Mbps
Priority 5 : 10Mbps
Priority 6 : 10Mbps
Priority 7 : 10Mbps
Maximum reservable bandwidth: 10Mbps
Maximum bandwidth: 10Mbps
Administrative groups: 0 none
P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16
IP extended prefix: 192.168.100.3/32 metric 0 up
8 bytes of subtlvs
Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 103
IP extended prefix: 11.103.107.0/30 metric 10 up
IP extended prefix: 11.102.1.0/24 metric 10 up
Router Capability: Router ID 192.168.100.3, Flags: 0x00
SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000
SPRING Algorithm - Algo: 0
No queued transmissions
R2.00-00 Sequence: 0x2aa, Checksum: 0xf8f4, Lifetime: 1067 secs
IPV4 Index: 105
Node Segment Blocks Advertised:
Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ]
IS neighbor: R1.00 Metric: 10
Two-way fragment: R1.00-00, Two-way first fragment: R1.00-00
IS neighbor: R3.00 Metric: 10
Two-way fragment: R3.00-00, Two-way first fragment: R3.00-00
IP prefix: 192.168.100.2/32 Metric: 0 Internal Up
IP prefix: 11.102.105.0/30 Metric: 10 Internal Up
IP prefix: 11.103.107.0/30 Metric: 10 Internal Up
Header: LSP ID: R2.00-00, Length: 302 bytes
Allocated length: 302 bytes, Router ID: 192.168.100.2
Remaining lifetime: 1067 secs, Level: 2, Interface: 334
Estimated free bytes: 0, Actual free bytes: 0
Aging timer expires in: 1067 secs
Protocols: IP, IPv6
Packet: LSP ID: R2.00-00, Length: 302 bytes, Lifetime : 1194 secs
Checksum: 0xf8f4, Sequence: 0x2aa, Attributes: 0x3 L1 L2
NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes
Packet type: 20, Packet version: 1, Max area: 0
TLVs:
Area address: 49.0011 (3)
LSP Buffer Size: 1492
Speaks: IP
Speaks: IPV6
IP router id: 192.168.100.2
IP address: 192.168.100.2
Hostname: R2
IP extended prefix: 192.168.100.2/32 metric 0 up
8 bytes of subtlvs
Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 105
IP extended prefix: 11.102.105.0/30 metric 10 up
IP extended prefix: 11.103.107.0/30 metric 10 up
Router Capability: Router ID 192.168.100.2, Flags: 0x00
SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 4000, SID-Label: 800000
SPRING Algorithm - Algo: 0
IS extended neighbor: R3.00, Metric: default 10
IP address: 10.100.23.1
Neighbor's IP address: 10.100.23.2
Local interface index: 334, Remote interface index: 336
Current reservable bandwidth:
Priority 0 : 10Mbps
Priority 1 : 10Mbps
Priority 2 : 10Mbps
Priority 3 : 10Mbps
Priority 4 : 10Mbps
Priority 5 : 10Mbps
Priority 6 : 10Mbps
Priority 7 : 10Mbps
Maximum reservable bandwidth: 10Mbps
Maximum bandwidth: 10Mbps
Administrative groups: 0 none
P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 16
IS extended neighbor: R1.00, Metric: default 10
IP address: 10.100.12.2
Neighbor's IP address: 10.100.12.1
Local interface index: 333, Remote interface index: 334
Current reservable bandwidth:
Priority 0 : 10Mbps
Priority 1 : 10Mbps
Priority 2 : 10Mbps
Priority 3 : 10Mbps
Priority 4 : 10Mbps
Priority 5 : 10Mbps
Priority 6 : 10Mbps
Priority 7 : 10Mbps
Maximum reservable bandwidth: 10Mbps
Maximum bandwidth: 10Mbps
Administrative groups: 0 none
P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0), Weight:0, Label: 17
No queued transmissions
PCE.00-00 Sequence: 0x277, Checksum: 0x64a5, Lifetime: 533 secs
IS neighbor: PCC.00 Metric: 16777215
IP prefix: 11.0.0.199/32 Metric: 0 Internal Up
IP prefix: 11.105.199.0/30 Metric: 16777215 Internal Up
Header: LSP ID: PCE.00-00, Length: 120 bytes
Allocated length: 284 bytes, Router ID: 11.0.0.199
Remaining lifetime: 533 secs, Level: 2, Interface: 329
Estimated free bytes: 164, Actual free bytes: 164
Aging timer expires in: 533 secs
Protocols: IP, IPv6
Packet: LSP ID: PCE.00-00, Length: 120 bytes, Lifetime : 1196 secs
Checksum: 0x64a5, Sequence: 0x277, Attributes: 0x3 L1 L2
NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes
Packet type: 20, Packet version: 1, Max area: 0
TLVs:
Area address: 11.0007 (3)
LSP Buffer Size: 1492
Speaks: IP
Speaks: IPV6
IP router id: 11.0.0.199
IP address: 11.0.0.199
Hostname: PCE
Router Capability: Router ID 11.0.0.199, Flags: 0x00
IP extended prefix: 11.105.199.0/30 metric 16777215 up
IP extended prefix: 11.0.0.199/32 metric 0 up
IS extended neighbor: PCC.00, Metric: default 16777215
IP address: 11.105.199.2
Neighbor's IP address: 11.105.199.1
Local interface index: 329, Remote interface index: 329
No queued transmissionsuser@PCC> show isis overview
Instance: master
Router ID: 192.168.100.4
Hostname: PCC
Sysid: 0110.0000.0101
Areaid: 49.0011
Adjacency holddown: enabled
Maximum Areas: 3
LSP life time: 1200
Attached bit evaluation: enabled
SPF delay: 200 msec, SPF holddown: 5000 msec, SPF rapid runs: 3
IPv4 is enabled, IPv6 is enabled, SPRING based MPLS is enabled
Traffic engineering: enabled
Restart: Disabled
Helper mode: Enabled
Layer2-map: Disabled
Source Packet Routing (SPRING): Enabled
SRGB Config Range:
SRGB Start-Label : 800000, SRGB Index-Range : 4000
SRGB Block Allocation: Success
SRGB Start Index : 800000, SRGB Size : 4000, Label-Range: [ 800000, 803999 ]
Node Segments: Enabled
Ipv4 Index : 101, Ipv6 Index : 11
Level 1
Internal route preference: 15
External route preference: 160
Prefix export count: 0
Wide metrics are enabled, Narrow metrics are enabled
Source Packet Routing is enabled
Level 2
Internal route preference: 18
External route preference: 165
Prefix export count: 0
Wide metrics are enabled
Source Packet Routing is enabledSignificado
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 show ted database extensive comando.
user@PCC# show ted database extensive
TED database: 5 ISIS nodes 5 INET nodes
NodeID: PCC.00(192.168.100.4)
Type: Rtr, Age: 403 secs, LinkIn: 1, LinkOut: 1
Protocol: IS-IS(2)
192.168.100.4
To: R1.00(192.168.100.1), Local: 10.100.41.1, Remote: 10.100.41.2
Local interface index: 334, Remote interface index: 333
Color: 0 none
Metric: 10
IGP metric: 10
Static BW: 10Mbps
Reservable BW: 10Mbps
Available BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
P2P Adjacency-SID:
IPV4, SID: 16, Flags: 0x30, Weight: 0
Prefixes:
192.168.100.4/32
Metric: 0, Flags: 0x00
Prefix-SID:
SID: 101, Flags: 0x40, Algo: 0
SPRING-Capabilities:
SRGB block [Start: 800000, Range: 4000, Flags: 0xc0]
SPRING-Algorithms:
Algo: 0
NodeID: R1.00(192.168.100.1)
Type: Rtr, Age: 712 secs, LinkIn: 2, LinkOut: 2
Protocol: IS-IS(2)
192.168.100.1
To: PCC.00(192.168.100.4), Local: 10.100.41.2, Remote: 10.100.41.1
Local interface index: 333, Remote interface index: 334
Color: 0 none
Metric: 10
IGP metric: 10
Static BW: 10Mbps
Reservable BW: 10Mbps
Available BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
P2P Adjacency-SID:
IPV4, SID: 16, Flags: 0x30, Weight: 0
To: R2.00(192.168.100.2), Local: 10.100.12.1, Remote: 10.100.12.2
Local interface index: 334, Remote interface index: 333
Color: 0 none
Metric: 10
IGP metric: 10
Static BW: 10Mbps
Reservable BW: 10Mbps
Available BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
P2P Adjacency-SID:
IPV4, SID: 17, Flags: 0x30, Weight: 0
Prefixes:
192.168.100.1/32
Metric: 0, Flags: 0x00
Prefix-SID:
SID: 102, Flags: 0x40, Algo: 0
SPRING-Capabilities:
SRGB block [Start: 800000, Range: 4000, Flags: 0xc0]
SPRING-Algorithms:
Algo: 0
NodeID: R3.00(192.168.100.3)
Type: Rtr, Age: 435 secs, LinkIn: 1, LinkOut: 1
Protocol: IS-IS(2)
192.168.100.3
To: R2.00(192.168.100.2), Local: 10.100.23.2, Remote: 10.100.23.1
Local interface index: 336, Remote interface index: 334
Color: 0 none
Metric: 10
IGP metric: 10
Static BW: 10Mbps
Reservable BW: 10Mbps
Available BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
P2P Adjacency-SID:
IPV4, SID: 16, Flags: 0x30, Weight: 0
Prefixes:
192.168.100.3/32
Metric: 0, Flags: 0x00
Prefix-SID:
SID: 103, Flags: 0x40, Algo: 0
SPRING-Capabilities:
SRGB block [Start: 800000, Range: 4000, Flags: 0xc0]
SPRING-Algorithms:
Algo: 0
NodeID: R2.00(192.168.100.2)
Type: Rtr, Age: 456 secs, LinkIn: 2, LinkOut: 2
Protocol: IS-IS(2)
192.168.100.2
To: R1.00(192.168.100.1), Local: 10.100.12.2, Remote: 10.100.12.1
Local interface index: 333, Remote interface index: 334
Color: 0 none
Metric: 10
IGP metric: 10
Static BW: 10Mbps
Reservable BW: 10Mbps
Available BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
P2P Adjacency-SID:
IPV4, SID: 17, Flags: 0x30, Weight: 0
To: R3.00(192.168.100.3), Local: 10.100.23.1, Remote: 10.100.23.2
Local interface index: 334, Remote interface index: 336
Color: 0 none
Metric: 10
IGP metric: 10
Static BW: 10Mbps
Reservable BW: 10Mbps
Available BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps
P2P Adjacency-SID:
IPV4, SID: 16, Flags: 0x30, Weight: 0
Prefixes:
192.168.100.2/32
Metric: 0, Flags: 0x00
Prefix-SID:
SID: 105, Flags: 0x40, Algo: 0
SPRING-Capabilities:
SRGB block [Start: 800000, Range: 4000, Flags: 0xc0]
SPRING-Algorithms:
Algo: 0
NodeID: PCE.00(11.0.0.199)
Type: Rtr, Age: 267 secs, LinkIn: 0, LinkOut: 0
Protocol: IS-IS(2)
11.0.0.199Significado
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 show path-computation-client lspcomandos , show spring-traffic-engineering lsp detaily show route protocol spring-te .
user@PCC> show path-computation-client lsp Name Status PLSP-Id LSP-Type Controller Path-Setup-Type Template adj_sid_lsp (Up) 3 ext-provised pce1 spring-te node_sid_lsp (Up) 5 ext-provised pce1 spring-te
user@PCC> show spring-traffic-engineering lsp detail
Name: adj_sid_lsp
To: 192.168.100.3
State: Up, Outgoing interface: ge-0/0/5.0
Delegation info:
Control-status: Externally controlled
Routing-status: Externally routed
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 10.100.41.1 -> 10.100.41.2
SID type: 20-bit label, Value: 16
Hop 2 (Strict):
NAI: IPv4 Adjacency ID, 10.100.12.1 -> 10.100.12.2
SID type: 20-bit label, Value: 17
Hop 3 (Strict):
NAI: IPv4 Adjacency ID, 10.100.23.1 -> 10.100.23.2
SID type: 20-bit label, Value: 16
Name: node_sid_lsp
To: 192.168.100.3
State: Up, Outgoing interface: ge-0/0/5.0
Delegation info:
Control-status: Externally controlled
Routing-status: Externally routed
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 10.100.41.1 -> 10.100.41.2
SID type: 20-bit label, Value: 16
Hop 2 (Strict):
NAI: IPv4 Node ID, Node address: 192.168.100.1
SID type: 20-bit label, Value: 800105
Hop 3 (Strict):
NAI: IPv4 Node ID, Node address: 192.168.100.2
SID type: 20-bit label, Value: 800103
Name: static_srte_lsp_1
Tunnel-source: Static configuration
To: 192.168.100.3
State: Up
Path: static_seg_list_1
Outgoing interface: NA
Delegation info:
Control-status: Externally controlled
Routing-status: Externally routed
Auto-translate status: Disabled Auto-translate result: N/A
BFD status: Up BFD name: V4-srte_bfd_session-4
SR-ERO hop count: 2
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 13.1.1.2 -> 36.12.16.1
SID type: None
Hop 2 (Strict):
NAI: IPv4 Node ID, Node address: 192.168.100.3
SID type: 20-bit label, Value: 804000
Total displayed LSPs: 3 (Up: 3, Down: 0)user@PCC> show route protocol spring-te
inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.100.3/32 *[SPRING-TE/8] 00:23:32, metric 0
to 10.100.41.2 via ge-0/0/5.0, Push 16, Push 17(top)
> to 10.100.41.2 via ge-0/0/5.0, Push 800103, Push 800105(top)
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)Significado
Los resultados muestran que el PCE ha creado dos LSP SR-TE —adj_sid_lsp y node_sid_lsp—para los segmentos de adyacencia y nodo, respectivamente.
El LSP de enrutamiento de segmentos, static_srte_lsp_1, está habilitado con la capacidad de delegación. El Delegation info campo muestra el estado de control y enrutamiento de los LSP delegados por PCE. Externally controlled significa que el PCE tiene control sobre los LSP. Externally routed significa que el PCE ha proporcionado el ERO para la ruta de enrutamiento de origen.
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 show route table inet.3 extensive comando.
user@PCC> show route table inet.3 extensive
inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
192.168.100.1/32 (1 entry, 1 announced)
*L-ISIS Preference: 14
Level: 2
Next hop type: Router, Next hop index: 581
Address: 0xb7a23b0
Next-hop reference count: 13
Next hop: 10.100.41.2 via ge-0/0/5.0, selected
Session Id: 0x172
State: Active Int
Local AS: 64496
Age: 45:51 Metric: 10
Validation State: unverified
ORR Generation-ID: 0
Task: IS-IS
Announcement bits (2): 0-Resolve tree 1 2-Resolve tree 3
AS path: I
192.168.100.3/32 (2 entries, 1 announced)
*SPRING-TE Preference: 8
Next hop type: Router, Next hop index: 0
Address: 0xb61c190
Next-hop reference count: 7
Next hop: 10.100.41.2 via ge-0/0/5.0 weight 0x1
Label operation: Push 16, Push 17(top)
Label TTL action: prop-ttl, prop-ttl(top)
Load balance label: Label 16: None; Label 17: None;
Label element ptr: 0xb7a2a60
Label parent element ptr: 0x0
Label element references: 5
Label element child references: 0
Label element lsp id: 0
Session Id: 0x0
Next hop: 10.100.41.2 via ge-0/0/5.0 weight 0x1, selected
Label operation: Push 800103, Push 800105(top)
Label TTL action: prop-ttl, prop-ttl(top)
Load balance label: Label 800103: None; Label 800105: None;
Label element ptr: 0xb7a2c40
Label parent element ptr: 0x0
Label element references: 2
Label element child references: 0
Label element lsp id: 0
Session Id: 0x0
State: Active Int
Local AS: 64496
Age: 9:44 Metric: 0
Validation State: unverified
Task: SPRING-TE
Announcement bits (2): 0-Resolve tree 1 2-Resolve tree 3
AS path: I
L-ISIS Preference: 14
Level: 2
Next hop type: Router, Next hop index: 0
Address: 0xb7a28f0
Next-hop reference count: 1
Next hop: 10.100.41.2 via ge-0/0/5.0, selected
Label operation: Push 800103
Label TTL action: prop-ttl
Load balance label: Label 800103: None;
Label element ptr: 0xb7a2880
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x0
State: Int
Inactive reason: Route Preference
Local AS: 64496
Age: 45:40 Metric: 30
Validation State: unverified
ORR Generation-ID: 0
Task: IS-IS
AS path: I
192.168.100.2/32 (1 entry, 1 announced)
*L-ISIS Preference: 14
Level: 2
Next hop type: Router, Next hop index: 0
Address: 0xb7a29b0
Next-hop reference count: 1
Next hop: 10.100.41.2 via ge-0/0/5.0, selected
Label operation: Push 800105
Label TTL action: prop-ttl
Load balance label: Label 800105: None;
Label element ptr: 0xb7a2940
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x0
State: Active Int
Local AS: 64496
Age: 45:40 Metric: 20
Validation State: unverified
ORR Generation-ID: 0
Task: IS-IS
Announcement bits (2): 0-Resolve tree 1 2-Resolve tree 3
AS path: ISignificado
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 show route forwarding-table destination ip-address extensive comando.
user@PCC> show route forwarding-table destination 192.168.100.3 extensive
Routing table: default.inet [Index 0]
Internet:
Enabled protocols: Bridging,
Destination: 192.168.100.3/32
Route type: user
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
P2mpidx: 0
Flags: sent to PFE, rt nh decoupled
Nexthop: 10.100.41.2
Next-hop type: unicast Index: 581 Reference: 14
Next-hop interface: ge-0/0/5.0
Routing table: __pfe_private__.inet [Index 3]
Internet:
Enabled protocols: Bridging,
Destination: default
Route type: permanent
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
P2mpidx: 0
Flags: sent to PFE
Next-hop type: discard Index: 517 Reference: 2
Routing table: __juniper_services__.inet [Index 5]
Internet:
Enabled protocols: Bridging,
Destination: default
Route type: permanent
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
P2mpidx: 0
Flags: sent to PFE
Next-hop type: discard Index: 530 Reference: 2
Routing table: __master.anon__.inet [Index 6]
Internet:
Enabled protocols: Bridging, Dual VLAN,
Destination: default
Route type: permanent
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
P2mpidx: 0
Flags: sent to PFE
Next-hop type: reject Index: 545 Reference: 1 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 show route ip-address comandos y show route forwarding-table destination ip-address .
user@PCC> show route 100.1.1.1
inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.1.1.1/32 *[Static/5] 00:33:36, metric2 0
> to 10.100.41.2 via ge-0/0/5.0, Push 16, Push 17(top)
to 10.100.41.2 via ge-0/0/5.0, Push 800103, Push 800105(top)user@PCC> show route forwarding-table destination 100.1.1.1
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination Type RtRef Next hop Type Index NhRef Netif
100.1.1.1/32 user 0 indr 1048575 2
10.100.41.2 Push 16, Push 17(top) 590 2 ge-0/0/5.0
Routing table: __pfe_private__.inet
Internet:
Enabled protocols: Bridging,
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 517 2
Routing table: __juniper_services__.inet
Internet:
Enabled protocols: Bridging,
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 530 2
Routing table: __master.anon__.inet
Internet:
Enabled protocols: Bridging, Dual VLAN,
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 545 1Significado
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
- Ejemplo: Configuración de la ruta conmutada de etiquetas de enrutamiento de segmentos estáticos
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
- Ventajas de usar los LSP de enrutamiento por segmentos
- LSP de enrutamiento de segmentos estáticos coloreados
- LSP de enrutamiento de segmentos estáticos no coloreados
- Aprovisionamiento de LSP de enrutamiento por segmentos estáticos
- Limitaciones del LSP del enrutamiento de segmentos estáticos
- Creación dinámica de LSP de enrutamiento por segmentos
- Mapeo basado en colores de servicios VPN
- Plantillas de túnel para LSP de enrutamiento de segmentos iniciado por PCE
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 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 color instrucción se denomina LSP coloreado.
- Descripción de los LSP de enrutamiento de segmentos estáticos coloreados
- Lista de segmentos de LSP de enrutamiento de segmentos de 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 inetcolor.0 tablas de enrutamiento o inet6color.0 , con destination-ip-address, color una clave para mapear el tráfico IP.
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 mpls.0 enrutamiento. 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 color instrucción es un LSP no coloreado. Al igual que en los túneles de enrutamiento de segmentos PCEP, la ruta de entrada se instala en las tablas de inet.3 enrutamiento o inet6.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
- Lista de segmentos de 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 [edit protocols source-packet-routing source-routing-path lsp-name] para sus rutas SID de entrada y enlace. 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.
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 nésimo salto podían ser etiquetas SID. 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 inherit-label-nexthops dirección IP como la etiqueta. Si el primer salto incluye sólo la dirección IP, la inherit-label-nexthops instrucción no tiene ningún efecto.
Puede configurar inherit-label-nexthops en cualquiera de las siguientes jerarquías. La inherit-label-nexthops instrucción sólo surte efecto si el primer salto de la lista de segmentos incluye tanto la dirección IP como la etiqueta.
-
Segment list level—En el
[edit protocols source-packet-routing segment-list segment-list-name]nivel jerárquico. -
Globally—En el
[edit protocols source-packet-routing]nivel jerárquico.
Cuando la inherit-label-nexthops instrucción se configura globalmente, tiene prioridad sobre la configuración de nivel de lista de segmentos y la inherit-label-nexthops configuración se aplica a todas las listas de segmentos. Cuando la instrucción no está configurada globalmente, sólo las listas de inherit-label-nexthops segmentos con etiquetas y dirección IP presentes en el primer salto y configuradas con inherit-label-nexthops instrucción se resuelven mediante etiquetas SID.
Para los LSP estáticos dinámicos no coloreados, es decir, los LSP de enrutamiento de segmentos basados en PCEP, la inherit-label-nexthops instrucción debe habilitarse globalmente, ya que no se aplica la configuración a nivel de segmento.
Tabla 4 describe el modo de enrutamiento de segmentos de resolución LSP según 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 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 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 show route ip-address protocol spring-te active-path table inet.3 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.
Por ejemplo:
user@host> show route 10.7.7.7 protocol spring-te active-path table inet.3
inet.3: 42 destinations, 59 routes (41 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.7.7.7/32 *[SPRING-TE/8] 00:01:25, metric 1, metric2 0
> to 10.11.1.2 via et-0/0/0.1, Push 801007
to 10.21.1.2 via et-0/0/2.1, Push 801007
to 10.102.1.2 via et-0/0/0.2, Push 801007, Push 801002(top)
to 10.21.1.2 via et-0/0/2.2, Push 801007, Push 801005(top)
to 10.103.1.2 via et-0/0/0.3, Push 801007, Push 801003(top)
to 10.203.1.2 via et-0/0/2.3, Push 801007, Push 801006(top)
to 10.104.1.2 via et-0/0/0.4, Push 801007, Push 801003, Push 801002(top)
to 10.204.1.2 via et-0/0/2.4, Push 801007, Push 801006, Push 801005(top)
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:
segment-list path-1 { hop-1 ip-address 172.16.12.2; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } segment-list path-2 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; primary { path-1; path-2; } }Se produce un error en la confirmación del túnel lsp1 , ya que la ruta 1 está en modo de dirección IP y la ruta 2 está en modo de etiqueta.
-
El SID de enlace está habilitado para el LSP estático no coloreado cuyo tipo de lista de segmentos es etiqueta SID.
Por ejemplo:
segment-list path-3 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; binding-sid 333; primary { path-3; } }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 segment instrucción en el nivel de [edit protocols mpls static-label-switched-path static-label-switched-path] jerarquía. 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 static-label-range static-label-range instrucción en el nivel de [edit protocols mpls label-range] jerarquía.
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
[edit protocols source-packet-routing]el nivel jerárquico. 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
no-ingressde la instrucción en[edit protocols source-packet-routing source-routing-path lsp-name]el nivel de jerarquía. -
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
- Resolución de LSP de enrutamiento de segmentos dinámicos
- Consideraciones para configurar la creación dinámica de LSP de enrutamiento de segmentos
- Servicios admitidos en los LSP de enrutamiento de segmentos dinámicos
- Comportamiento con varios orígenes de túnel en el enrutamiento de segmentos
- Limitaciones de los LSP de enrutamiento de segmentos dinámicos
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 [edit routing-options dynamic-tunnels] jerarquía.
-
A continuación se muestra un ejemplo de configuración para la plantilla LSP de enrutamiento de segmentos dinámicos de color:
[edit routing-options] dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1> color [c1 c2]; <template-name2> color [c3]; <template-name3> color-any; } destination-networks { <dest1>; <dest2>; } } } } -
A continuación se muestra un ejemplo de configuración para la plantilla LSP de enrutamiento de segmentos dinámicos sin color:
dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1>; } destination-networks { <dest1>; <dest2>; } } } }
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 color-any plantilla. 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 spring-te con un solo nombre de plantilla en la lista de asignación. 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 spring-te configuración. 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:
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color [101 124];
sr_lsp2 color-any
}
destination-networks {
10.22.44.0/24;
}
}
}
Si el servicio BGP PNH es 10.22.44.0/24 con comunidad de color 123/124/125, entonces utiliza la plantilla SR-TE sr_lsp1 para crear un túnel. Cualquier otro color para el mismo prefijo PNH utiliza sr_lsp2 plantilla debido a la color-any configuración.
Para la configuración de ejemplo mencionada anteriormente, las entradas de ruta son las siguientes:
-
inetcolor.0 tunnel route: 10.22.44.0-0/24 --> RT_NH_TUNNEL
-
inet6color.0 tunnel route: ffff::10.22.44.0-0/120 --> RT_NH_TUNNEL
-
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
R1(prefijo) -> ffff::10.22.44.55-101(PNH) Nombre del túnel LSP = 10.22.44.55:65:dt-srte-tunnel1
R1(prefijo) -> ffff::10.22.44.55-124(PNH) LSP tunnel name = 10.22.44.55:7c:dt-srte-tunnel1
-
inetcolor.0 tunnel route:
10.22.44.55-101/64 --> <siguiente-salto>
10.22.44.55-124/64 --> <siguiente-salto>
-
inet6color.0 tunnel route:
ffff::10.22.44.55-101/160 --> <next-hop>
ffff::10.22.44.55-124/160 --> <next-hop>
El túnel de color 101 (10.22.44.55:65:dt-srte-tunnel1) se crea debido a la color-any configuración.
Las rutas IPv6 en inet6color.0 se deben a la mpls ipv6-tunneling configuración. Permite que las rutas IPv6 con comunidad de colores se resuelvan a través de la tabla inet6color.0 convirtiendo las rutas SR-TE almacenadas en la tabla de enrutamiento inetcolor.0 en direcciones IPv6 asignadas IPv4 y, a continuación, copiándolas en la tabla de enrutamiento inet6color.0.
LSP de enrutamiento de segmentos dinámicos no coloreados
Configuración de ejemplo para LSP de enrutamiento de segmentos dinámicos no coloreados:
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels {
tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color 101;
}
destination-networks {
10.33.44.0/24;
}
}
}
tunnel2 {
spring-te {
source-routing-path-template {
sr_lsp1;
}
destination-networks {
10.33.44.0/24;
}
}
}
}
Para la configuración de ejemplo mencionada anteriormente, las entradas de ruta son las siguientes:
-
inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL
-
inet6.3 tunnel route: ffff::10.33.44.0/120 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(prefijo) -> 10.33.44.55(PNH) LSP template name = LSP1 --- 10.33.44.55:dt-srte-tunnel2
R1(prefijo) -> ffff::10.33.44.55(PNH) LSP template name = LSP1 --- 10.33.44.55:dt-srte-tunnel2
-
inet.3 tunnel route: 10.33.44.55/32 --> <siguiente-salto>
-
inet6.3 tunnel route: ffff::10.33.44.55/128 --> <next-hop>
El túnel sin color (10.33.44.55:dt-srte-tunnel2) se crea utilizando el túnel dinámico2, ya que no tiene el color configurado. Las rutas IPv6 en inet6.3 se deben a la mpls ipv6-tunneling configuración. Permite que las rutas IPv6 se resuelvan a través de una red MPLS convirtiendo las rutas SR-TE almacenadas en la tabla de enrutamiento inet.3 en direcciones IPv6 asignadas a IPv4 y, a continuación, copiándolas en la tabla de enrutamiento inet6.3.
LSP de enrutamiento de segmentos dinámicos no resuelto
Configuración de ejemplo para LSP de enrutamiento de segmentos dinámicos no resueltos:
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color [120 121 122 123];
}
destination-networks {
10.33.44.0/24;
10.1.1.0/24;
}
}
}
Para la configuración de ejemplo mencionada anteriormente, las entradas de ruta son las siguientes:
-
inetcolor.0 tunnel route: 10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0 /24 --> RT_NH_TUNNEL
-
inet6color.0 tunnel route: ffff::10.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff::10.1.1.0 - 0 /24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping: R1(prefijo) -> 10.33.44.55-124(PNH) No se crea 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
spring-tedinámico incluye una plantilla con un objeto de color, también debe configurar todas las demás plantillas con objetos de color. 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
color-anyopción. Ambas opciones pueden coexistir en la mismaspring-teconfiguración. En tales casos, las plantillas asignadas con colores específicos tienen una mayor preferencia. -
En una
spring-teconfiguración, solo se puede definir una plantilla con lacolor-anyopción. -
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
spring-teinstrucción bajo la[edit protocols]jerarquía y debe tener habilitada laprimaryopción. -
Los destinos coloreados y no coloreados no pueden coexistir en la misma
spring-teconfiguración. -
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
spring-te, solo se puede configurar una plantilla sin objeto de color.
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
- Especificación del modo de asignación de servicios VPN
- Resolución de próximo salto del protocolo Color-IP
- Respaldo a la resolución del protocolo IP del próximo salto
- Mapeo basado en color de unidifusión etiquetado con BGP a través de SR-TE
- Funciones admitidas y no compatibles para la asignación basada en colores de servicios VPN
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 vrf-exportde enrutamiento, la exportación de grupo o la exportación de vecino de grupo del servicio VPN en el nivel jerárquico [edit protocols bgp] . BGP anuncia la NLRI VPN con la comunidad extendida de color especificada.
Por ejemplo:
[edit policy-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-X {
...
vrf-export pol-color ...;
}
O
Cuando aplique la directiva de enrutamiento como una política de exportación de un grupo BGP o vecino de BGP, debe incluir la vpn-apply-export instrucción en el nivel de BGP, grupo BGP o vecino de BGP para que la directiva surta efecto en la NLRI VPN.
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
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 vrf-importde enrutamiento, la importación de grupo o la importación de vecinos de grupo del servicio VPN en el nivel jerárquico [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:
[edit routing-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-Y {
...
vrf-import pol-color ...;
}
O
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-color ...;
}
}
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 resolution-map instrucción y hacer referencia a la directiva en la instancia vrf-importde enrutamiento, la importación de grupo o la importación de vecino de grupo de un servicio VPN en el nivel jerárquico [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:
[edit policy-options]
resolution-map map-A {
<mode-1>;
<mode-2>;
...
}
policy-statement pol-resolution {
term t1 {
from {
[any match conditions];
}
then {
resolution-map map-A;
accept;
}
}
}
Puede aplicar la política de importación a la instancia de enrutamiento del servicio VPN.
[edit routing-instances]
vpn-Y {
...
vrf-import pol-resolution ...;
}
También puede aplicar la directiva de importación a un grupo BGP o vecino de BGP.
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}
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 IP-address:colorenrutamiento inet6color.0.
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:
[edit policy-options]
policy-statement mpath {
then multipath-resolve;
}
[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.l3vpn-inet6.0 {
inet6color-import mpath;
}
}
resolution {
rib bgp.l2vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib mpls.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.evpn.0 {
inetcolor-import mpath;
}
}
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 resolution map para SR-TE. Se construye un protocolo de color del siguiente salto y se resuelve en un túnel SR-TE de color en la inetcolor.0 tabla o inet6color.0 . BGP utiliza inet.3 y inet6.3 tablas para mapeo no basado en color. 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 Figura 9, el controlador configura 4 túneles de colores en una red central IPv6 configurada con SR-TE. 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.
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:
-
Incluya la instrucción source-routing-path-template en el nivel jerárquico
[edit protocols source-packet-routing]. Puede configurar los parámetros adicionales de tunelización BFD y LDP aquí. -
Incluya la instrucción source-routing-path-template-map en el nivel jerárquico
[edit protocols source-packet-routing]para enumerar las instrucciones de política con las que se debe comprobar el LSP iniciado por PCE. -
Defina una política para enumerar los LSP en los que se debe aplicar la plantilla.
La
frominstrucción puede incluir el nombre LSP o la expresión regular LSP mediante laslspcondiciones de coincidencia ylsp-regex. Estas opciones son mutuamente excluyentes, por lo que solo puede especificar una opción en un momento dado.La
theninstrucción debe incluir lasr-te-templateopción con una acción de aceptación. 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 segment-list instrucción en el [edit protocols source-packet-routing] nivel de jerarquía. Puede configurar el túnel de enrutamiento de segmentos configurando la instrucción en [edit protocols source-packet-routing] el nivel de source-routing-path jerarquía. 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.
Configuración
- Configuración rápida de CLI
- Configuración del dispositivo PE1
- Configuración del dispositivo PE2
- Resultados
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
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set interfaces ge-0/0/0 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set interfaces ge-0/0/1 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/5 unit 0 family inet address 10.10.17.1/24 set routing-options autonomous-system 65000 set routing-options forwarding-table export load-balance-policy set routing-options forwarding-table chained-composite-next-hop ingress l3vpn set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.147.211 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.146.181 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols source-packet-routing segment-list sl-15-primary hop-1 ip-address 10.10.13.3 set protocols source-packet-routing segment-list sl-15-primary hop-2 label 1000134 set protocols source-packet-routing segment-list sl-15-primary hop-3 label 1000145 set protocols source-packet-routing segment-list sl-15-backup hop-1 ip-address 10.10.12.2 set protocols source-packet-routing segment-list sl-15-backup hop-2 label 1000123 set protocols source-packet-routing segment-list sl-15-backup hop-3 label 1000134 set protocols source-packet-routing segment-list sl-15-backup hop-4 label 1000145 set protocols source-packet-routing source-routing-path lsp-15 to 192.168.146.181 set protocols source-packet-routing source-routing-path lsp-15 binding-sid 1000999 set protocols source-packet-routing source-routing-path lsp-15 primary sl-15-primary set protocols source-packet-routing source-routing-path lsp-15 secondary sl-15-backup set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options policy-statement load-balance-policy then load-balance per-packet set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/5.0 set routing-instances VRF1 route-distinguisher 192.168.147.211:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/5.0
PE2
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set interfaces ge-0/0/1 unit 0 family mpls set protocols mpls static-label-switched-path adj-23 segment 1000123 set protocols mpls static-label-switched-path adj-23 segment next-hop 10.10.23.3 set protocols mpls static-label-switched-path adj-23 segment pop set protocols mpls static-label-switched-path adj-21 segment 1000221 set protocols mpls static-label-switched-path adj-21 segment next-hop 10.10.12.1 set protocols mpls static-label-switched-path adj-21 segment pop set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
PE3
set interfaces ge-0/0/0 unit 0 family inet address 10.10.13.3/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.3/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.3/24 set interfaces ge-0/0/2 unit 0 family mpls set protocols mpls static-label-switched-path adj-34 segment 1000134 set protocols mpls static-label-switched-path adj-34 segment next-hop 10.10.34.4 set protocols mpls static-label-switched-path adj-34 segment pop set protocols mpls static-label-switched-path adj-32 segment 1000232 set protocols mpls static-label-switched-path adj-32 segment next-hop 10.10.23.2 set protocols mpls static-label-switched-path adj-32 segment pop set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
PE4
set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.4/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.4/24 set interfaces ge-0/0/3 unit 0 family mpls set protocols mpls static-label-switched-path adj-45 segment 1000145 set protocols mpls static-label-switched-path adj-45 segment next-hop 10.10.45.5 set protocols mpls static-label-switched-path adj-45 segment pop set protocols mpls static-label-switched-path adj-43 segment 1000243 set protocols mpls static-label-switched-path adj-43 segment next-hop 10.10.34.3 set protocols mpls static-label-switched-path adj-43 segment pop set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
PE5
set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.5/24 set interfaces ge-0/0/3 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.5/24 set routing-options autonomous-system 65000 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.146.181 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.147.211 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols bfd sbfd local-discriminator 0.0.0.32 minimum-receive-interval 1000 set protocols source-packet-routing segment-list sl-51 hop-1 ip-address 10.10.45.4 set protocols source-packet-routing segment-list sl-51 hop-2 label 1000243 set protocols source-packet-routing segment-list sl-51 hop-3 label 1000232 set protocols source-packet-routing segment-list sl-51 hop-4 label 1000221 set protocols source-packet-routing source-routing-path lsp-51 to 192.168.147.211 set protocols source-packet-routing source-routing-path lsp-51 primary sl-51 set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/4.0 set routing-instances VRF1 route-distinguisher 192.168.146.181:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/4.0
CE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.17.7/24 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
CE2
set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.6/24 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0
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.
Para configurar el dispositivo PE1:
-
Configure las interfaces.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set ge-0/0/0 unit 0 family mpls maximum-labels 5 set ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set ge-0/0/1 unit 0 family mpls maximum-labels 5 set ge-0/0/5 unit 0 family inet address 10.10.17.1/24
-
Configure el número y las opciones del sistema autónomo para controlar las opciones de enrutamiento de reenvío de paquetes.
[edit routing-options] set autonomous-system 65000 set forwarding-table export load-balance-policy set forwarding-table chained-composite-next-hop ingress l3vpn
-
Configure las interfaces con el protocolo MPLS y configure el intervalo de etiquetas MPLS.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
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.
[edit protocols bgp] set group pe type internal set group pe local-address 192.168.147.211 set group pe family inet-vpn unicast set group pe neighbor 192.168.146.181
-
Configure las interfaces de área de protocolo.
[edit protocols ospf] set area 0.0.0.0 interface ge-0/0/0.0 set area 0.0.0.0 interface lo0.0 set area 0.0.0.0 interface ge-0/0/1.0
-
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).
[edit protocols source-packet-routing segment-list] set sl-15-primary hop-1 ip-address 10.10.13.3 set sl-15-primary hop-2 label 1000134 set sl-15-primary hop-3 label 1000145 set sl-15-backup hop-1 ip-address 10.10.12.2 set sl-15-backup hop-2 label 1000123 set sl-15-backup hop-3 label 1000134 set sl-15-backup hop-4 label 1000145
-
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.
[edit protocols source-packet-routing source-routing-path] set lsp-15 to 192.168.146.181 set lsp-15 binding-sid 1000999 set lsp-15 primary sl-15-primary set lsp-15 secondary sl-15-backup
-
Configure las opciones de directiva.
[edit policy-options policy-statement] set VPN-A-export term a from protocol ospf set VPN-A-export term a from protocol direct set VPN-A-export term a then community add VPN-A set VPN-A-export term a then accept set VPN-A-export term b then reject set VPN-A-import term a from protocol bgp set VPN-A-import term a from community VPN-A set VPN-A-import term a then accept set VPN-A-import term b then reject set bgp-to-ospf from protocol bgp set bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set bgp-to-ospf then accept set load-balance-policy then load-balance per-packet
-
Configure la información de la comunidad BGP.
[edit policy-options] set community VPN-A members target:65000:1
-
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.
[edit routing-instances VRF1] set instance-type vrf set interface ge-0/0/5.0 set route-distinguisher 192.168.147.211:1 set vrf-import VPN-A-import set vrf-export VPN-A-export set vrf-table-label set protocols ospf export bgp-to-ospf set protocols ospf area 0.0.0.0 interface ge-0/0/5.0
Resultados
Desde el modo de configuración, escriba los comandos , show policy-options, show routing-optionsshow protocols, y show routing-instances para confirmar la show interfacesconfiguración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
[edit]
user@PE1# show
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.12.1/24;
}
family mpls {
maximum-labels 5;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.10.13.1/24;
}
family mpls {
maximum-labels 5;
}
}
}
ge-0/0/5 {
unit 0 {
family inet {
address 10.10.17.1/24;
}
}
}
}
policy-options {
policy-statement VPN-A-export {
term a {
from protocol [ ospf direct ];
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement bgp-to-ospf {
from {
protocol bgp;
route-filter 10.10.0.0/16 orlonger;
}
then accept;
}
policy-statement load-balance-policy {
then {
load-balance per-packet;
}
}
community VPN-A members target:65000:1;
}
routing-instances {
VRF1 {
instance-type vrf;
protocols {
ospf {
area 0.0.0.0 {
interface ge-0/0/5.0;
}
export bgp-to-ospf;
}
}
interface ge-0/0/5.0;
route-distinguisher 192.168.147.211:1;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
vrf-table-label;
}
}
routing-options {
autonomous-system 65000;
forwarding-table {
export load-balance-policy;
chained-composite-next-hop {
ingress {
l3vpn;
}
}
}
}
protocols {
bgp {
group pe {
type internal;
local-address 192.168.147.211;
family inet-vpn {
unicast;
}
neighbor 192.168.146.181;
}
}
mpls {
label-range {
static-label-range 1000000 1000999;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface lo0.0;
interface ge-0/0/1.0;
}
}
source-packet-routing {
segment-list sl-15-primary {
hop-1 ip-address 10.10.13.3;
hop-2 label 1000134;
hop-3 label 1000145;
}
segment-list sl-15-backup {
hop-1 ip-address 10.10.12.2;
hop-2 label 1000123;
hop-3 label 1000134;
hop-4 label 1000145;
}
source-routing-path lsp-15 {
to 192.168.146.181;
binding-sid 1000999;
primary {
sl-15-primary;
}
secondary {
sl-15-backup;
}
}
}
}
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.
-
Configure las interfaces.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set ge-0/0/0 unit 0 family mpls set ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set ge-0/0/1 unit 0 family mpls
-
Configure el LSP estático para el protocolo MPLS.
[edit protocols mpls static-label-switched-path] set adj-23 segment 1000123 set adj-23 segment next-hop 10.10.23.3 set adj-23 segment pop set adj-21 segment 1000221 set adj-21 segment next-hop 10.10.12.1 set adj-21 segment pop
-
Configure las interfaces y el rango de etiquetas estáticas para el protocolo MPLS.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
Configure interfaces para el protocolo OSPF.
[edit protocols ospf area 0.0.0.0] set interface ge-0/0/0.0 set interface ge-0/0/1.0
Resultados
Desde el modo de configuración en el enrutador PE2, confirme su configuración introduciendo los show interfaces comandos y show protocols . Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
[edit]
user@PE2# show
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.12.2/24;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.10.23.2/24;
}
family mpls;
}
}
}
protocols {
mpls {
label-range {
static-label-range 1000000 1000999;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
static-label-switched-path adj-23 {
segment {
1000123;
next-hop 10.10.23.3;
pop;
}
}
static-label-switched-path adj-21 {
segment {
1000221;
next-hop 10.10.12.1;
pop;
}
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
}
}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
- Verificación de entradas de tabla de rutas de la tabla de enrutamiento mpls.0 del enrutador PE1
- Verificación del LSP de ingeniería de tráfico SPRING del enrutador PE1
- Verificación de LSP de ingeniería de tráfico SPRING en el enrutador de entrada del enrutador PE1
- Comprobación de las entradas de la tabla de enrutamiento de la tabla de enrutamiento mpls.0 del enrutador PE2
- Verificación del estado de segmentos LSP MPLS estáticos del enrutador PE2
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.
user@PE1> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.146.181/32 *[SPRING-TE/8] 03:09:26, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Push 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, Push 1000123(top)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.
user@PE1> show route table mpls.0
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:25:52, metric 1
Receive
1 *[MPLS/0] 03:25:52, metric 1
Receive
2 *[MPLS/0] 03:25:52, metric 1
Receive
13 *[MPLS/0] 03:25:52, metric 1
Receive
16 *[VPN/0] 03:25:52
> via lsi.0 (VRF1), Pop
1000999 *[SPRING-TE/8] 03:04:03, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Swap 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Swap 1000145, Push 1000134, Push 1000123(top)
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 .
user@PE1> show spring-traffic-engineering overview
Overview of SPRING-TE:
Route preference: 8
Number of LSPs: 1 (Up: 1, Down: 0)
External controllers:
< Not configured >
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.
user@PE1# show spring-traffic-engineering lsp detail
Name: lsp-15
To: 192.168.146.181
State: Up
Path: sl-15-primary
Outgoing interface: ge-0/0/1.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.13.3
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Path: sl-15-backup
Outgoing interface: ge-0/0/0.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 4
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.12.2
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000123
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 4 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Total displayed LSPs: 1 (Up: 1, Down: 0)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.
user@PE2> show route table mpls.0
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:22:29, metric 1
Receive
1 *[MPLS/0] 03:22:29, metric 1
Receive
2 *[MPLS/0] 03:22:29, metric 1
Receive
13 *[MPLS/0] 03:22:29, metric 1
Receive
1000123 *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000123(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000221 *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, Pop
1000221(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, PopVerificació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.
user@PE2> show mpls static-lsp
Ingress LSPs:
Total 0, displayed 0, Up 0, Down 0
Transit LSPs:
Total 0, displayed 0, Up 0, Down 0
Bypass LSPs:
Total 0, displayed 0, Up 0, Down 0
Segment LSPs:
LSPname SID-label State
adj-21 1000221 Up
adj-23 1000123 Up
Total 2, displayed 2, Up 2, Down 0Significado
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
- Algoritmo de cálculo CSPF distribuido
- Base de datos de cómputo CSPF distribuida
- Configuración de restricciones de cálculo de CSPF distribuidas
- Cálculo distribuido de CSPF
- Interacción entre la computación CSPF distribuida y las características de SR-TE
- Configuraciones de ejemplo de cómputo CSPF distribuido
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, Política de enrutamiento por segmentos para ingeniería de tráfico:
-
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 N segmentos hasta destino, donde:
-
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 N es el número máximo de listas de segmentos permitidas para la ruta candidata por configuració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 igp-topology instrucción en el nivel jerárquico [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 [edit protocols source-packet-routing] jerarquía.
La configuración de las restricciones de cálculo admitidas incluye:
-
Administrative groups
Puede configurar grupos de administradores en el nivel jerárquico
[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
computeopción bajo la instrucción segment-list al especificar la restricción de ruta explícita. -
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
maximum-computed-segment-lists maximum-computed-segment-listsopción situada en la instrucción de configuración del perfil informático . 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
maximum-segment-list-depthconfiguración en el nivel de[edit protocols source-packet-routing]jerarquía, si está presente.Puede configurar este atributo mediante la
maximum-segment-list-depth maximum-segment-list-depthopción situada en la instrucción de configuración del perfil informático . -
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.
-
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
metric-type (igp | te)opción situada en la instrucción de configuración del perfil informático .
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.
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
- Detección de vivacidad BFD
- inherit-label-nexthops
- Función de traducción automática
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 inherit-label-nexthops configuración en la [edit protocols source-packet-routing segment-list segment-list-name] jerarquía para las rutas principales o secundarias calculadas, ya que es un comportamiento predeterminado.
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 static_sl1 de segmentos configurados, que también sirve como nombre para esta ruta principal.
-
Un primario calculado debe tener un nombre configurado y este nombre no debe hacer referencia a ninguna lista de segmentos configurada. En este ejemplo, compute_segment1 no es una lista de segmentos configurada.
-
El compute_profile_red perfil informático se aplica a la ruta principal con el nombre compute_segment1.
-
El compute_profile_red perfil de proceso incluye una lista de segmentos de tipo
compute, que se utiliza para especificar la restricción de ruta explícita para el cálculo.
[edit protocols source-packet-routing]
segment-list static_sl1{
hop1 label 80000
}
segment-list exp_path1 {
hop1 ip-address 10.1.1.1 loose
hop2 ip-address 10.2.2.2
compute
}
compute-profile compute_profile_red {
include-any red
segment-list exp_path1
maximum-segment-list-depth 5
}
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 comp_nh1, comp_nh2, y comp_nh3, y que el siguiente salto para ruta estática es static_nh, los pesos se aplican de la siguiente manera:
|
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.
[edit protocols source-packet-routing]
compute-profile compute_profile_green{
include-any green
maximum-segment-list-depth 5
}
compute-profile compute_profile_red{
include-any red
maximum-segment-list-depth 8
}
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.
[edit protocols source-packet-routing]
source-routing-path srte_colored_policy1 {
to 10.5.5.5
color 5
binding-sid 10001
primary {
compute_segment1 {
compute
}
}
}
Ejemplo: Configuración del reenvío basado en CoS y el enrutamiento basado en políticas para LSP de SR-TE
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
- Configurar el reenvío basado en CoS y el enrutamiento basado en políticas para los LSP de SR-TE
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
- Fuentes de rutas de enrutamiento de segmentos compatibles con CBF y PBR
- Consideraciones para configurar CBF y PBR 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
resolution preserve-nexthop-hiearchyinstrucción en el nivel de[edit routing-options]jerarquía.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
show routecomando.
Configurar el reenvío basado en CoS y el enrutamiento basado en políticas para los LSP de SR-TE
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:
Ahora puede configurar CBF y PBR para los LSP de SR-TE configurados.
Para configurar CBF, haga lo siguiente
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.
[edit class-of-service] user@host# set classifiers dscpclassifier-name forwarding-class forwarding-class-name loss-priority level code-points [ aliases ] [ 6 bit-patterns ]
Por ejemplo:
[edit class-of-service] user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority low code-points 001010 user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority medium-high code-points 001100 user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority high code-points 001110 user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority low code-points 010010 user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority medium-high code-points 010100 user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority high code-points 010110 user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority low code-points 011010 user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority medium-high code-points 011100 user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority high code-points 011110 user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority low code-points 100010 user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority medium-high code-points 100100 user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority high code-points 100110
Defina clases de reenvío (FC) para agrupar paquetes para su transmisión y asigne paquetes a colas de salida.
[edit class-of-service] user@host# set forwarding-classes queue queue-numner class-name
Por ejemplo:
[edit class-of-service] user@host# set forwarding-classes queue 0 af11 user@host# set forwarding-classes queue 1 af21 user@host# set forwarding-classes queue 2 af31 user@host# set forwarding-classes queue 3 af41
Asigne los clasificadores configurados a las interfaces del dispositivo.
[edit class-of-service] user@host# set interfaces interface-name unit unit classifiers dscp classifier-name
Por ejemplo:
[edit class-of-service] user@host# set interfaces ge-0/0/8 unit 1 classifiers dscp mydscp user@host# set interfaces ge-0/0/8 unit 2 classifiers dscp mydscp
Defina las opciones de política de reenvío basadas en CoS con el siguiente salto de LSP como el LSP de SR-TE.
[edit class-of-service] user@host# set forwarding-policy next-hop-map map-name forwarding-classes class-name lsp-next-hop source-routing-path-name
Por ejemplo:
[edit class-of-service] user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af11 lsp-next-hop srtelsp1 user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af21 lsp-next-hop srtelsp2 user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af41 lsp-next-hop srtelsp3 user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af31 lsp-next-hop srtelsp4
Descarte el tráfico que no cumpla con ninguna clase de reenvío en el mapa del salto siguiente.
[edit class-of-service] user@host# set forwarding-policy next-hop-map map-name forwarding-class-default discard
Por ejemplo:
[edit class-of-service] user@host# set forwarding-policy next-hop-map my_cbf forwarding-class-default discard
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.
[edit policy-options] user@host# set policy-statement policy-name from route-filter destination-prefix match-type <actions> user@host# set policy-statement policy-name then cos-next-hop-map map-name
Por ejemplo:
[edit policy-options] user@host# set policy-statement cbf from route-filter 4.0.0.1/16 orlonger user@host# set policy-statement cbf then cos-next-hop-map my_cbf
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.
[edit routing-options] user@host# set forwarding-table export policy-name
Por ejemplo:
[edit routing-options] user@host# set forwarding-table export cbf
Confirme la configuración.
user@host# commit
Verify CBF Configuration
Puede comprobar la configuración CBF mediante el show route forwarding-table destination ip-address vpn vpn-name extensive comando.
user@host> show route forwarding-table destination 4.0.0.1 vpn vpn1 extensive Routing table: vpn1.inet [Index 8] Internet: Destination: 4.0.0.1/32 Route type: user Route reference: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: sent to PFE Next-hop type: indirect Next-hop type: indexed Route type: idx:0 Nexthop: 11.1.1.2 Next-hop type: Push 296, Push 801007, Push 801003, Push 801002(top) Index: 807 Reference: 1 Route interface-index: 0 Index: 1048579 Reference: 10001 Index: 837 Reference: 2 Load Balance Label: None Next-hop interface: ge-0/0/1.1 Route type: idx:1 Nexthop: 11.11.1.2 Next-hop type: Push 296, Push 801007, Push 801003, Push 801002(top) Index: 809
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 show route comando.
Para configurar PBR, haga lo siguiente
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.
[edit policy-options] user@host# set policy-statement policy-name from protocol protocol-name user@host# set policy-statement policy-name from route-filter destination-prefix match-type <actions> user@host# set policy-statement policy-name then install-nexthop lsp lsp-name user@host# set policy-statement policy-name then load-balance per-packet
Por ejemplo:
[edit policy-options] user@host# set policy-statement pbr term 1 from protocol bgp user@host# set policy-statement pbr term 1 from route-filter 4.0.0.1/32 exact user@host# set policy-statement pbr term 1 then install-nexthop lsp srtelsp1 user@host# set policy-statement pbr term 1 then load-balance per-packet user@host# set policy-statement pbr term 1 then reject
Configure el dispositivo para realizar una resolución de ruta personalizada en los siguientes saltos de rutas del protocolo.
Nota:La
resolution preserve-nexthop-hierarchydeclaración es obligatoria para que el PBR funcione cuando el primer salto del SR-TE LSP es una etiqueta.[edit routing-options] user@host# set resolution preserve-nexthop-hierarchy
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.
[edit routing-options] user@host# set forwarding-table export policy-name
Por ejemplo:
[edit routing-options] user@host# set forwarding-table export pbr
Confirme la configuración.
user@host# commit
Verify PBR Configuration
Puede comprobar la configuración del PBR mediante el show route destination-prefix comando.
user@host> show route 4.0.0.1
vpn1.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
4.0.0.1/32 *[BGP/170] 00:24:12, localpref 100, from 7.7.7.7
AS path: 10 I, validation-state: unverified
to 11.1.1.2 via ge-0/0/1.1, Push 50983, Push 801007, Push 801003, Push 801002(top)
> to 11.11.1.2 via ge-0/0/1.2, Push 50983, Push 801007, Push 801003, Push 801002(top)
to 11.12.1.2 via ge-0/0/1.3, Push 50983, Push 801007, Push 801003, Push 801002(top)
to 11.13.1.2 via ge-0/0/1.4, Push 50983, Push 801007, Push 801003, Push 801002(top)
user@host> show route 4.0.0.1 expanded-nh extensive
vpn1.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden)
4.0.0.1/32 (1 entry, 1 announced)
Installed-nexthop:
Indr (0xc7aaa54) 7.7.7.7 Push 50983 Session-ID: 0x16f
Krt_inh (0xc745a84) Index:1048579 PNH: 7.7.7.7
Chain (0xc7aa798) Index:823 Push 50983
Router (0xc417034) 11.1.1.2 Push 801007, Push 801003, Push 801002(top) via ge-0/0/1.1
El resultado muestra todos los saltos siguientes para el prefijo de destino, 4.0.0.1. Las expanded-nh extensive opciones muestran los próximos saltos filtrados en el Krt_inh campo de salida.
user@host> show route 4.0.0.2
vpn1.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
4.0.0.2/32 *[BGP/170] 00:30:14, localpref 100, from 7.7.7.7
AS path: 10 I, validation-state: unverified
to 11.1.1.2 via ge-0/0/1.1, Push 569, Push 801007, Push 801003, Push 801002(top)
> to 11.11.1.2 via ge-0/0/1.2, Push 569, Push 801007, Push 801003, Push 801002(top)
to 11.12.1.2 via ge-0/0/1.3, Push 569, Push 801007, Push 801003, Push 801002(top)
to 11.17.1.2 via ge-0/0/1.8, Push 569, Push 801007, Push 801003, Push 801002(top)
user@host> show route 7.7.7.7 protocol spring-te
inet.0: 10082 destinations, 10119 routes (10082 active, 0 holddown, 0 hidden)
inet.3: 25 destinations, 77 routes (25 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
7.7.7.7/32 *[SPRING-TE/1] 00:00:32, metric 1, metric2 4
> to 11.1.1.2 via ge-0/0/1.1, Push 801007, Push 801003, Push 801002(top)
to 11.11.1.2 via ge-0/0/1.2, Push 801007, Push 801003, Push 801002(top)
to 11.12.1.2 via ge-0/0/1.3, Push 801007, Push 801003, Push 801002(top)
to 11.17.1.2 via ge-0/0/1.8, Push 801007, Push 801003, Push 801002(top)
Para PBR, la show route salida del comando realiza el filtrado de rutas basado en políticas.
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, compute-profile ahora se pueden configurar con un número máximo de listas de segmentos (maximum-computed-segment-lists) mayor que 1.
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 (
max-computed-segment-lists) más de 1 en el perfil de cómputo de SR-TE para LSP delegados e iniciados por PCE -
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
disable-multipath-capabilityla instrucción de configuración en el nivel de jerarquía [edit 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:
| 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 propagate-max-segmentlist configuración en el nivel de jerarquía [edit protocols pcep]. De forma predeterminada, el TLV no se envía en el objeto LSP.
user@host# set protocols pcep propagate-max-computed-segmentlist;
Para deshabilitar la sesión de capacidad múltiple PCEP para todas las PCE, incluya la instrucción de disable-multipath-capability configuración en el nivel de jerarquía [edit protocols pcep].
user@host# set protocols pcep disable-multipath-capability;
[edit protocols]
pcep {
disable-multipath-capability;
propagate-max-segmentlist;
}
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
- Habilitación de TLS en el cliente de cálculo de ruta (PCC)
- Actualización de certificados mediante la infraestructura de clave pública (PKI)
- Establecer una conexión TLS
- Descripción del mecanismo básico de protocolo de enlace TLS
- Diagnóstico y validación de TLS para sesiones PCEP
- Salida de muestra
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 tls-strict instrucción CLI en el nivel jerárquico [edit protocols pcep].
Después de habilitar la instrucción tls-strict configuration, ocurren los siguientes eventos:
-
Colgajos de sesión PCEP. Cualquier conexión TCP existente se termina y se realiza una reconexión mediante TLS.
-
PCC establece una conexión TCP con el PCE.
-
Los procedimientos TLS se inician mediante el StartTLS mensaje de PCE a PCC y de PCC a PCE. El StartTLS mensaje es enviado por PCC y se inicia el StartTLSWait temporizador. Puede configurar el StartTLSWait temporizador configurando la
start-tls-wait-timer secondsinstrucción CLI en el nivel jerárquico [edit protocols pcep pce pce-id].Nota:El valor recomendado para el StartTLSWait temporizador es de 60 segundos y no debe ser inferior al OpenWait temporizador. El valor predeterminado OpenWait del temporizador se establece en 60 segundos.
-
Si PCC recibe el mensaje Abrir en lugar del StartTLS mensaje, PCErr 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.
-
Si StartTLS no se recibe el mensaje de PCE, después de que expire el StartTLSWait temporizador, PCC envía un PCErr mensaje con Error-Type establecido en 25 (error de PCEP StartTLS ) y Error-value establecido en 5 (sin StartTLS mensaje (ni PCErr/Open) antes StartTLSWait de que expire el temporizador), y la sesión TCP se cierra.
-
-
Se produce la negociación y el establecimiento de la conexión TLS.
-
El intercambio de mensajes PCEP se inicia según RFC5440.
Si no habilita la tls-strict instrucción CLI en el nivel de jerarquía [edit protocols pcep], al establecer una sesión PCEP, si PCC recibe el StartTLS mensaje en lugar de Open message, PCErr 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.
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.
user@host> request security pki local-certificates re-enroll certificate id
Establecer una conexión TLS
Los pasos siguientes describen cómo se establece una conexión TLS (mediante TLS v1.2):
-
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.
-
-
Cargue la entidad de certificación (CA) en la PCC para que el certificado del servidor PCE se pueda validar con la CA cargada.
user@host# set security pki ca-profile pccd-tls ca-identity pccd-tls user@host# commit
user@host> request security pki ca-certificate load ca-profile pccd-tls filename /var/tmp/ca.crt
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.
-
Habilite TLS en PCC.
-
La sesión PCEP se establece a través de TLS con mecanismo de protocolo de enlace TLS.
-
El servidor PCE escucha el puerto 4189 para las solicitudes de conexión PCC entrantes a través de TLS.
-
PCC inicia la solicitud de conexión al puerto de destino 4189.
-
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 StartTLSWait recibir el StartTLS mensaje. Puede configurar el StartTLSWait temporizador configurando la
start-tls-wait-timer secondsinstrucción CLI en el nivel jerárquico [edit protocols pcep pce pce-id].Nota:El valor recomendado para el StartTLSWait temporizador es de 60 segundos y no debe ser inferior al OpenWait temporizador. El valor predeterminado OpenWait del temporizador se establece en 60 segundos.
-
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.
-
-
El mensaje PCEP se envía a través de la conexión TLS como datos de aplicación.
-
El cifrado y el descifrado ocurren tanto en PCC como en PCE después de un apretón de manos TLS exitoso.
-
Cuando se cierra la sesión PCEP, se elimina la sesión TLS.
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 del protocolo de enlace varían según el algoritmo de intercambio de claves, el conjunto de cifrado, etcetera. Los siguientes son los pasos básicos del mecanismo de protocolo de enlace TLS:
-
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.
-
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.
-
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.
-
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).
-
Client Key Exchange: el cliente envía la clave secreta cifrada con la clave pública del servidor (adquirida en el mensaje Server Hello).
-
Decrypt secret key: el servidor descifra la clave secreta mediante la clave privada.
-
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.
-
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.
-
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:
user@host# set protocols pcep traceoptions … user@host# set protocols pcep pce pce-id traceoptions … user@host# set protocols source-packet-routing traceoptions
Habilite los registros de PKI mediante la siguiente configuración y capture el mismo archivo desde /var/log/<filename>
user@host# set security pki traceoptions file <filename> user@host# set security pki traceoptions flag all sss
Compruebe el certificado de CA cargado mediante el siguiente comando:
user@host> show security pki ca-certificate detail
Salida de muestra
A continuación se muestra un ejemplo de salida del show path-computation-client statistics comando:
user@host> show path-computation-client statistics
Warning: License key missing; requires 'PCEP' license
PCE ns1
--------------------------------------------
General
PCE IP address : 192.168.18.1
Local IP address : 190.168.18.101
Priority : 0
PCE status : PCE_STATE_UP
Session type : PCE_TYPE_STATEFULACTIVE
LSP provisioning allowed : On
P2MP LSP report allowed : On
P2MP LSP update allowed : On
P2MP LSP init allowed : On
Session SRv6 Capable : No
PCE-mastership : main
PCE Traffic Steering : Off
PCC TLS Enabled : Yes
PCE TLS Enabled : Yes
Session TLS Enabled : Yes
Counters
PCReqs Total: 0 last 5min: 0 last hour: 0
PCReps Total: 0 last 5min: 0 last hour: 0
PCRpts Total: 0 last 5min: 0 last hour: 0
PCUpdates Total: 0 last 5min: 0 last hour: 0
PCCreates Total: 0 last 5min: 0 last hour: 0
Timers
Local Keepalive timer: 0 [s] Dead timer: 0 [s] LSP cleanup timer: - [s]
Remote Keepalive timer: 0 [s] Dead timer: 0 [s] LSP cleanup timer: - [s]
Errors
PCErr-recv
PCErr-sent
PCE-PCC-NTFS
PCC-PCE-NTFS
Pcupdate empty ero action counters
Send-err : 0
Tear down path : 0
Routing decision : 0
Routing decision failed: 0
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.
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
- Descripción de las métricas de optimización
- Configuración de métricas de optimización para proveedores de servicios lingüísticos
- Salida de muestra
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
- LSP de RSVP delegado
- RSVP LSP iniciado por PCE
- LSP SR-TE delegado
- LSP SR-TE iniciado por PCE
- Envío de métricas de optimización en mensaje PCRpt
- Envío de métrica calculada en mensaje PCRpt
- Incompatibilidad con versiones anteriores de la métrica de ruta
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 intended-attributes-list mensaje en el PCRpt. 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 actual-attributes-list mensaje en el PCRpt. 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 metric-type <igp|te|delay|delay minimum> instrucción CLI en el nivel de jerarquía [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 metric-type <igp|te|delay|delay minimum> instrucción CLI en el nivel de jerarquía [edit protocols source-packet-routing compute-profile <compute-profile-name>].
Salida de muestra
Puede usar los show path-computation-client lsp comandos y show path-computation-client lsp extensive CLI para mostrar el estado de las rutas conmutadas por etiquetas (LSP) conocidas por el cliente de cálculo de rutas (PCC).
A continuación se muestra un ejemplo de show path-computation-client lsp extensive:
user@host> show path-computation-client lsp extensive name sr_lsp
LSP Name : sr_lsp
PathName : -
From : 192.168.1.101
To : 192.168.1.106
Path Setup Type : spring-te
State : Up
Active Path : Yes
Link Protection : none
LSP Type : ext-provised
P2mp tree : NULL
Path cspf status : external_cspf
Controller : ns1
Template : NULL
PLSP-ID : 31
LSP-ID : 0
RSVP Error : 0x0
Requested AutoBw : 0bps
Record Route : (Label=299792)
From PCE ERO (received) : (Label=299792)
From RPD ERO (reported) : (Label=299792)
Configured ERO on PCC : Not Supported
Bandwidth:
Intended : 98.76Kbps
Actual : 0bps
Intended Metric:
Metric type Bound Optimization
IGP 0 TRUE
Actual Metric:
Metric type Computed value
IGP 50
Route Metric : 50
Mapped Flowspec (FS-Ids) : -
LSP Attributes:
Exclude-Any: 0, Include-Any: 0, Include-All: 0
Setup Priority: 0, Hold-Priority: 0
Local Protection Bit: FALSE
Last Rpt/Pcreqest received from RPD at : 22:15:32.000
Last Update sent to PCE at : 16:00:00.000
Last PcUpdate/PcCreate received from PCE at : 22:15:32.000
Last error sent to PCE at : 16:00:00.000
Last 5 reasons to send Report/Pcrequest : , , , ,
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.
Túneles SRv6-TE con microSID en PCEP
La compatibilidad con túneles SRv6-TE con microSID en PCEP mejora la ingeniería de tráfico y la optimización de la red al permitir la generación de informes, la delegación y la creación de estos túneles. Puede informar y delegar túneles SRv6-TE estáticos con configuraciones de microSID a un PCE e iniciar estos túneles a través de PCE, mejorando el control y la administración. Las funcionalidades clave incluyen la generación de informes de túneles SRv6-TE estáticos con microSID al PCE, la delegación de su administración y su creación con la estructura SID adecuada y las comprobaciones de comportamiento del punto final. Los comandos de CLI existentes se amplían para admitir estas funciones, lo que facilita una configuración y supervisión eficaces.
Beneficios de los túneles SRv6-TE con compatibilidad con microSID en PCEP
-
Mejore la ingeniería de tráfico al permitir que PCE cree y administre túneles SRv6-TE con microSID, optimizando el rendimiento de la red y la utilización de recursos.
-
Proporcione un mejor control y visibilidad de la red mediante la generación de informes y la delegación de túneles SRv6-TE estáticos con configuraciones de microSID al PCE.
Descripción general
Con la integración de túneles SRv6-TE con soporte de microSID en PCEP, puede mejorar significativamente las capacidades de ingeniería de tráfico de su red. Esta característica le permite informar, delegar y crear túneles SRv6-TE con microSID, aprovechando el elemento de cálculo de ruta (PCE) para una mejor optimización y administración de la red. Cuando se reportan túneles SRv6-TE estáticos con configuraciones de microSID al PCE, se incluyen detalles completos, como la estructura del SID y el comportamiento del punto de conexión, lo que permite al PCE administrar estos túneles de manera eficaz.
La delegación de túneles SRv6-TE con microSID al PCE permite un control mejorado, ya que el PCE puede administrar las configuraciones del túnel y optimizar las rutas de enrutamiento de forma dinámica. Esta delegación se puede configurar para que tenga lugar después de la creación, o puede configurarla para combinar la creación y la delegación en una sola confirmación, agilizando su proceso de configuración. Además, el PCE puede iniciar túneles SRv6-TE con microSID, lo que garantiza que la estructura del SID y las comprobaciones de comportamiento del punto final estén en su lugar, manteniendo así la integridad y el rendimiento de su enrutamiento de red.
Puede usar los siguientes comandos show para supervisar túneles SRv6-TE:
user@host> show spring-traffic-engineering lsp detail user@host> show ted spring-te-policy extensive user@host> show route table lsdist.0 protocol spring-te extensive user@host> show path-computation-client lsp extensive name <lsp-name>
Estos comandos proporcionan información detallada sobre el estado y la configuración de los túneles SRv6-TE, lo que le permite solucionar problemas y optimizar según sea necesario. Puede aprovechar al máximo las capacidades mejoradas de los túneles SRv6-TE con compatibilidad con microSID en PCEP.
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.
external cspf, se introducen dos nuevos tipos de cálculo de ruta para los LSP controlados por PCE: local cspf y no cspf.