EN ESTA PÁGINA
Ejemplo: Configuración del protocolo de elementos de computación de ruta para MPLS RSVP-TE
Habilitar el enrutamiento por segmentos para el protocolo de elemento de computación de ruta
Ruta conmutada con etiqueta de enrutamiento por segmento estático
Habilitación de CSPF distribuida para LSP de enrutamiento por segmentos
Habilitación de la seguridad de la capa de transporte para sesiones de PCEP
Optimización de ruta de informes y métricas computadas en PCEP
Configuración de PCEP
Descripción general de PCEP
Un elemento de computación 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 computación de ruta (PCC) es cualquier aplicación cliente que solicita una computación de ruta que debe realizar un PCE. El protocolo de elementos de computación de ruta (PCEP) permite las comunicaciones entre un PCC y un PCE, o entre dos PCE (definidos en rfc 5440).
El PCEP es un protocolo basado en TCP definido por el IETF PCE Working Group, y define un conjunto de mensajes y objetos que se utilizan para administrar sesiones de PCEP y para solicitar y enviar rutas para LSP de tráfico multidominio diseñados (LSP de TE). Proporciona un mecanismo para que un PCE realice cálculos de ruta para los LSP externos de un PCC. Las interacciones del 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 RSVP-TE de MPLS.
Una sesión de PCEP basada en TCP conecta un PCC a un PCE externo. El PCC inicia la sesión PCEP y permanece conectado al PCE durante la duración de la sesión PCEP. Durante la sesión 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ñalizar el LSP de TE. Cuando se termina 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 activo, un PCC intenta delegar todos los LSP a este PCE en un procedimiento llamado sincronización de estado de LSP. El PCEP permite la sincronización del estado LSP de PCC con el PCE.
Delegación de control sobre túneles LSP a una PCE con estado: una PCE con estado activa controla uno o más atributos LSP para rutas de computación, como ancho de banda, ruta (ERO) y prioridad (configuración y espera). El PCEP permite dicha delegación de LSP para el cálculo de rutas.
Control PCE de estado de la temporización y la secuencia de cálculos de rutas dentro y entre sesiones PCEP: una PCE con estado activa modifica uno o más atributos de LSP, como ancho de banda, ruta (ERO) y prioridad (configuración y espera). El PCEP comunica estos nuevos atributos de LSP desde el PCE al PCC, después de lo cual el PCC vuelve a señalizar el LSP en la ruta especificada.
Compatibilidad con el protocolo de elementos de computación de ruta para descripción general de RSVP-TE
- Descripción de MPLS RSVP-TE
- Limitaciones actuales de RSVP-TE de MPLS
- Uso de una entidad de computación de ruta externa
- Componentes de la computación de ruta externa
- Interacción entre un PCE y un PCC mediante PCEP
- Comportamiento de LSP con computación externa
- Instrucciones de configuración compatibles con computación externa
- Protección LSP controlada por PCE
- LSP controlado por PCE ERO
- LSP de punto a multipunto RSVP-TE controlado por PCE
- LSP de punto a punto iniciados por PCE
- LSP de bypass 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 el mapeo de flujos de tráfico en una topología física existente. La ingeniería de tráfico ofrece 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) hacia 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, se pueden implementar capacidades de MPLS, ya que potencialmente proporcionan la mayor parte de la funcionalidad disponible desde un modelo de superposición, de manera integrada y a un costo menor que las alternativas actuales de la competencia. La razón principal para implementar la ingeniería de tráfico de MPLS es controlar las rutas a través 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. Un paquete que llega a un enrutador de borde de proveedor (PE) desde el enrutador de borde del cliente (CE) tiene etiquetas aplicadas a él, y luego 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 paquete IP. Los enrutadores de conmutación de etiquetas (LSR) en el dominio de MPLS utilizan protocolos de distribución de etiquetas para comunicar el significado de las etiquetas utilizadas para reenviar tráfico entre y a través de las LSR. RSVP-TE es uno de esos protocolos de distribución de etiquetas que permite que un par LSR aprenda sobre las asignaciones de etiquetas de otros pares.
Cuando MPLS y RSVP están habilitados en un enrutador, MPLS se convierte en cliente de RSVP. El objetivo principal del software RSVP de Junos OS es admitir la señalización dinámica dentro de rutas conmutadas por etiquetas (LSP). RSVP reserva recursos, como para flujos de unidifusión y multidifusión IP, y solicita parámetros de calidad de servicio (QoS) para aplicaciones. El protocolo se extiende en la ingeniería de tráfico de 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 etiquetas al tráfico se realiza con diferentes criterios. El conjunto de paquetes a los que un nodo específico asigna el mismo valor de etiqueta pertenecen a la misma clase de equivalencia de reenvío (FEC) y definen 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 conmutadas por etiquetas. El RSVP-TE se basa en el protocolo de núcleo 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 —objeto LABEL-REQUEST (LRO), objeto RECORD-ROUTE (RRO), objeto LABEL y objeto EXPLICIT-ROUTE (ERO)— son opcionales con respecto al protocolo RSVP, a excepción de los objetos LRO y LABEL, ambos obligatorios para establecer túneles LSP.
En general, RSVP-TE establece una ruta conmutada por etiquetas que garantiza la entrega de tramas desde la entrada al 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 conmutada por etiquetas mediante una ruta explícita completa o parcial (RFC 3209).
-
Establecimiento de LSP basado en restricciones sobre vínculos que cumplen requisitos, como ancho de banda y propiedades de vínculo.
-
Control de punto de conexión, 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 hacer un enrutamiento consciente de los recursos de los LSP de ingeniería de tráfico y para programar etiquetas MPLS.
-
El 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 RSVP-TE de MPLS
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 MPLSVP-TE de hoy tiene varios problemas inherentes a su naturaleza distribuida. Esto provoca una serie de problemas durante la contención de la capacidad de bisección, especialmente dentro de una clase de prioridad LSP en la que un subconjunto de LSP comparte una configuración común y mantiene valores de prioridad. Las limitaciones de RSVP-TE incluyen:
-
Falta de visibilidad de las demandas de ancho de banda individuales por LSP y por dispositivo: los enrutadores de entrada en una red MPLS RSVP-TE establecen LSP sin tener una visión global de la demanda de ancho de banda en la red. La información sobre la utilización 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 de borde de etiquetas (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 tienen prioridad.
-
Naturaleza asincrónica e independiente de la señalización de RSVP: en el RSVP-TE, un administrador controla las restricciones para el establecimiento de rutas. Como tal, el administrador establece el ancho de banda reservado para un túnel LSP 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 vínculo 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 sin firmar de un túnel LSP conducen a la degradación del servicio del LSP que requiere un exceso de ancho de banda, así como de los otros LSP que cumplen con los requisitos de ancho de banda del vínculo de ingeniería de tráfico.
-
LSP establecidos según opciones de ruta dinámicas o explícitas en el orden de preferencia: los enrutadores de entrada en una red MPLS RSVP-TE establecen LSP para las demandas según 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, usar el orden de preferencia para establecer LSP puede causar que se caiga el 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 etiquetas (LER). Estos enrutadores de entrada establecen LSP de forma independiente según el orden de las demandas y no tienen conocimiento o control sobre los LSP de los otros. 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 según el orden en el que llegan las demandas. Si el enrutador G recibe dos demandas de capacidad 5 cada uno 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ñalizar LSP3 usando la misma ruta (A-B-C-E), ya que el vínculo B-C tiene una capacidad menor.
El enrutador A debería haber señalado el aumento de la demanda en LSP3 mediante la ruta A-B-D-C-E. Dado que LSP1 y LSP2 han utilizado el vínculo B-D según el orden de las demandas recibidas, LSP3 no está señalizadas.
Por lo tanto, aunque el ancho de banda de flujo máximo adecuado está disponible para todos los LSP, la LSP3 está sujeta a una degradación potencialmente prolongada del servicio. 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 de computación de ruta externa
Como solución a las limitaciones actuales que se encuentran en la computación de ruta RSVP-TE de MPLS, se requiere una entidad de computación de ruta externa con una vista global de la demanda por LSP, por dispositivo en la red independientemente de la capacidad disponible.
Actualmente, solo se proporciona computación de ruta de enrutamiento en línea y basada en restricciones en tiempo real en una red MPLS RSVP-TE. 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 la información de topología disponible actualmente, información que suele ser reciente, pero no del todo precisa. Las ubicaciones de LSP están optimizadas localmente, según el estado actual de la red. Los túneles MPLSVP-TE se configuran mediante la CLI. Un operador configura el LSP de TE, que luego es señalado por el enrutador de entrada.
Además de las capacidades existentes de ingeniería de tráfico, la funcionalidad RSVP-TE de MPLS se extiende para incluir una entidad de computación de ruta externa, llamada elemento de computación de ruta (PCE). El PCE calcula la ruta de los LSP de TE de los enrutadores de entrada configurados para el control externo. El enrutador de entrada que se conecta a un PCE se denomina cliente de computación de ruta (PCC). El PCC está configurado con el Protocolo de cliente de computación 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 rutas externas para los LSP de TE de un PCC, incluya la lsp-external-controller pccd instrucción en los [edit mpls] niveles y [edit mpls lsp lsp-name] de jerarquía.
Componentes de la computación de ruta externa
Los componentes que conforman un sistema informático de ruta externa son:
- Elemento de computación de ruta
- Cliente de computación de ruta
- Protocolo de elemento de computación de ruta
Elemento de computación de ruta
Un elemento de computación 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 puede calcular la ruta solo para aquellos LSP de TE de un PCC configurado para control externo.
Un PCE puede ser con estado o sin estado.
-
PCE con estado: una 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 los recursos reservados que se utilizan en la red. En otras palabras, una PCE con estado utiliza información de la base de datos de ingeniería de tráfico, así como información de rutas existentes (por ejemplo, LSP de TE) en la red cuando se procesan nuevas solicitudes del PCC.
Un PCE con estado es de dos tipos:
-
PCE con estado pasivo: mantiene la sincronización con el PCC y aprende los estados del LSP de PCC para optimizar mejor los cálculos de rutas, pero no tiene control sobre ellos.
-
PCE con estado activo: modifica activamente los LSP pcc, además de aprender acerca de los estados de LSP de PCC.
Nota:En una configuración redundante con PCE de estado principal y de copia de seguridad activa, la PCE de estado de copia de seguridad activa 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. En el caso de una conmutación, no hay preapreocupación de los PCE. El PCE principal está respaldado por un PCE de respaldo, y cuando el PCE principal cae, el PCE de respaldo asume el papel del PCE principal y sigue siendo el PCE principal incluso después de que el PCE que antes era el PCE principal esté operativo de nuevo.
Una PCE con estado proporciona las siguientes funciones:
-
Ofrece computación de ruta LSP sin conexión.
-
Activa la reenrutación de LSP cuando hay una necesidad de volver a optimizar la red.
-
Cambia el ancho de banda del LSP cuando hay un aumento de 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 mantener.
Un PCE tiene una vista global de la demanda de ancho de banda en la red y mantiene una base de datos diseñada para el 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 sin conexión de los LSP de TE del PCC. Aunque un sistema de computación de rutas de LSP sin conexión se puede integrar en un controlador de red, el PCE actúa como un controlador de red completo que proporciona control sobre los LSP de TE del PCC, además de las rutas de computación.
Aunque una PCE con estado permite una computación óptima de rutas y un aumento del éxito de la computación de rutas, requiere mecanismos de sincronización de estado confiables, con una sobrecarga potencialmente significativa del plano de control y el mantenimiento de una gran cantidad de datos en términos de estados, como en el caso de una malla completa de LSP de TE.
-
-
PCE sin estado: una PCE sin estado no recuerda ninguna ruta de computación y cada conjunto de solicitudes se procesa independientemente una de la otra (RFC 5440).
Cliente de computación de ruta
Un cliente de computación de ruta (PCC) es cualquier aplicación cliente que solicita una computación de ruta que debe realizar un PCE.
Un PCC puede conectarse a un máximo de 10 PCE a la vez. La conexión 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 de LSP. Para los LSP de TE que tienen el control externo habilitado, el PCC delega esos LSP en el 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 reenruta un LSP basado en la ruta calculada que recibe de un PCE. Cuando termina la sesión de PCEP con el PCE principal, el PCC elige un nuevo PCE principal y todos los LSP delegados a la PCE principal anterior se delegan en el PCE principal recién disponible.
Protocolo de elemento de computación de ruta
El protocolo de elementos de computación de ruta (PCEP) se utiliza para la comunicación entre PCC y PCE (así como entre dos PCE) (RFC 5440). El 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 de PCEP y para solicitar y enviar rutas para LSP de TE multidominio. Las interacciones de PCEP incluyen mensajes PCC, así como notificaciones de estados específicos relacionados con el uso de una PCE en el contexto de MPLS RSVP-TE. Cuando se utiliza PCEP para la comunicación PCE a PCE, la PCE solicitante asume el rol de un PCC.
Por lo tanto, las funciones de PCEP incluyen:
-
Sincronización de estado de túnel LSP entre PCC y una PCE con estado.
-
Delegación de control sobre túneles LSP a una PCE con estado.
Interacción entre un PCE y un PCC mediante 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 PCEP y permanece conectado a un PCE durante la duración de la sesión 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 enlazar la clave de autenticación MD5 en el [edit protocols pcep pce pce-id] nivel jerárquico de una sesión PCEP. Sin embargo, también puede usar un llavero predefinido desde el [edit security authentication-key-chains key-chain] nivel de jerarquía para proteger una sesión PCEP. En este caso, debe enlazar el llavero predefinido a la sesión PCEP en el [edit protocols pcep pce pce-id] nivel jerárquico.
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, lo que protege la comunicación PCEP entre los dispositivos, que pueden estar sujetos a ataques y pueden interrumpir los servicios en la red.
Para obtener más información sobre cómo proteger las sesiones de 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 de todos los LSP (locales y externos) a todos los PCE conectados. En el caso de los LSP externos, el PCC envía información sobre cualquier cambio de configuración, cambio de RRO, 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 LSP al PCC que ha indicado su capacidad de admitir 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 del LSP, el PCC delega los LSP externos en un PCE, que es el principal PCE activo. Solo el PCE principal puede establecer parámetros para el LSP externo. Los parámetros que modifica la PCE principal incluyen ancho de banda, ruta (ERO) y prioridad (configuración y mantener). Los parámetros especificados en la configuración local se anulan mediante los parámetros establecidos por la PCE principal.
Nota:Cuando termina la sesión de PCEP con el PCE principal, el PCC elige un nuevo PCE principal y todos los LSP delegados a la PCE principal anterior se delegan en el PCE principal recién disponible.
En el caso de los LSP iniciados por PCE, el PCC crea el LSP usando los parámetros recibidos del PCE. El PCC asigna al LSP iniciado por PCE un ID de LSP único y delega automáticamente el LSP al PCE. Un PCC no puede revocar la delegación para los LSP iniciados por PCE para una sesión PCEP activa.
Cuando termina una sesión de PCEP, el PCC inicia dos temporizadores sin eliminar de inmediato los LSP iniciados por PCE (
delegation cleanup timeoutylsp cleanup timer- para evitar la interrupción de los servicios. Durante este tiempo, un PCE activo con estado puede adquirir el control de los LSP aprovisionados por el PCE fallido, mediante el envío de una solicitud de creación para el LSP.El control sobre LSP iniciados por PCE vuelve al PCC al vencimiento de la .
delegation cleanup timeoutCuando eldelegation cleanup timeoutPCE caduca y ningún otro PCE adquirió el control sobre el LSP de la PCE fallida, el PCC toma el control local del LSP iniciado por PCE no delegado. Más tarde, cuando la PCE original o una nueva PCE activa desea adquirir el control de los LSP iniciados por PCE controlados localmente, el PCC delega estos LSP en el PCE y ellsp cleanup timertemporizador se detiene.Un PCE puede devolver la delegación del LSP iniciado por PCE al PCC para permitir la transferencia de LSP entre PCE. Esto activa el
lsp cleanup timerLSP iniciado por PCE. El PCC espera a que expire el temporizador de limpieza de LSP antes de quitar los LSP iniciados por PCE no delegados de la PCE fallida.Cuando el
lsp cleanup timerPCE caduca y ningún otro PCE ha adquirido el control sobre los LSP de la PCE fallida, el PCC elimina todos los LSP aprovisionados por la PCE fallida.Nota:En cumplimiento con el draft-ietf-pce-stateful-pce-09, la revocación de las delegaciones del LSP iniciadas por el PCE por un PCC se produce de forma previa al descanso antes de que los LSP se releguen a un PCE alternativo. A partir de la versión 18.1R1 de Junos OS, la
lsp-cleanup-timerversión 18.1R1 debe ser mayor o igual que ladelegation-cleanup-timeoutpara que el PCC revoque las delegaciones de LSP. Si no es así, el intervalo de tiempo de espera de redelegación para el PCC se puede establecer al infinito, donde las delegaciones LSP a dicho PCE permanecen intactas hasta que el PCC toma 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 LSP del PCE activo principal, el PCC vuelve a señalizar el LSP de TE según la ruta PCE proporcionada. Si el PCC no configura el LSP, notifica al PCE el error de configuración y espera que el PCE principal proporcione nuevos parámetros para ese LSP y, luego, vuelva a señalizarlo.
Cuando el PCE especifica una ruta que está incompleta o que tiene saltos sueltos en los que solo se especifican los puntos de conexión de la ruta, la PCC no realiza un enrutamiento local basado en restricciones para encontrar el conjunto completo de saltos. En su lugar, el PCC proporciona RSVP con la ruta proporcionada por PCE, tal como es, para la señalización, y la ruta se configura mediante el enrutamiento salto a salto de IGP.
Teniendo en cuenta la topología utilizada en Figura 2, Figura 4 se muestra la implementación parcial de PCE del lado del cliente en la red habilitada para RSVP-TE de MPLS. Los enrutadores de entrada A y G son los PCC que están configurados para conectarse a la PCE con estado externo mediante 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 consultar la base de datos de ingeniería de tráfico. A continuación, el PCE con estado activo modifica uno o más atributos LSP y envía una actualización al PCC. El PCC usa los parámetros que recibe de la PCE para re-señalizar el LSP.
De esta manera, el PCE de estado proporciona una operación cooperativa de funcionalidad distribuida que se utiliza para abordar desafíos específicos de una computación de rutas restringidas en un interdominio más corto. Elimina los escenarios de congestión en los que las secuencias de tráfico se asignan ineficientemente a los recursos disponibles, lo que provoca la sobreutilización de algunos subconjuntos de recursos de red, mientras que otros recursos permanecen subutilizados.
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 de 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 acerca de los LSP controlados por CLI durante el proceso de sincronización inicial de LSP. Después de la sincronización inicial de LSP, el PCC informa al PCE de cualquier LSP nuevo y eliminado también. -
LSP controlados por PCE: los LSP que tienen configurada la
lsp-external-controller pccdinstrucción se denominan LSP controlados por PCE. El PCC delega los LSP iniciados por 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 ancho de banda, ERO y prioridades. También informa al PCE sobre los valores reales utilizados para estos parámetros para configurar el LSP, incluida la 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 la 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 de la CLI de un LSP para un PCE:
-
Parámetros que no son anulados por un PCE y que se aplican de inmediato.
-
Parámetros que son anulados por un PCE. Estos parámetros incluyen ancho de banda, ruta y prioridad (valores de configuración y de espera). Cuando el modo de control cambia de externo a local, los valores configurados por CLI para estos parámetros se aplican en la próxima oportunidad para volver a señalizar el LSP. Los valores no se aplican de inmediato.
-
-
LSP aprovisionados externamente (o LSP iniciados por PCE): los LSP que tienen configurada la
lsp-provisioninginstrucción 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 mediante los parámetros proporcionados por el PCE y delega automáticamente el LSP en el 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 CLI, LSP controlados por PCE y 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 usa los parámetros proporcionados por PCE para configurar el LSP.
-
Local: un LSP controlado por PCE puede quedar bajo control local. Cuando el LSP pasa del control externo al control local, el cálculo de la ruta se realiza mediante los parámetros configurados por CLI y el enrutamiento basado en restricciones. Este cambio ocurre solo cuando hay un activador para volver a señalizar el LSP. Hasta entonces, el PCC usa 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, por ejemplo, sin conectividad con un PCE o cuando un PCE devuelve la delegación de los 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 compatibles con computación externa
Tabla 1 enumera las MPLS y las instrucciones de configuración de 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 tienen 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 se anulan mediante 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 entran en vigor cuando se aplica la configuración local. |
|
|
|
Estas instrucciones de configuración no se pueden configurar junto con la configuración PCE. |
|
|
El resto de las instrucciones de configuración de LSP se aplican 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 de MPLS para indicar cuándo los parámetros configurados tienen efecto.
Protección LSP controlada por PCE
Las rutas de protección, incluyendo el reenrutamiento rápido y la derivación de LSP, son calculadas localmente por el PCC mediante enrutamiento basado en restricciones. Una PCE con estado especifica solo la ruta principal (ERO). Un PCE también puede activar una ruta secundaria que no está en espera, incluso si la configuración local no tiene una ruta secundaria que no esté en espera para la protección de LSP.
LSP controlado por PCE ERO
En el caso de los LSP controlados por PCE (LSP delegados por PCC y LSP initatados por PCE), solo se debe enviar un objeto de ruta explícita (ERO) completo desde el PCE al PCC; de lo contrario, el PCC rechaza el mensaje PCUpdate o PCCreate para esa sesión PCEP.
A partir de Junos OS versión 17.2, además external cspfde , se introducen dos nuevos tipos de computación de ruta para los LSP controlados por PCE: local cspf y no cspf.
-
local cspf—Un PCC solo usa ellocal cspftipo de computación cuando el PCE envía un 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 de conexión y las restricciones se dan al módulo RSVP para configurar el LSP con la ruta IGP.Un PCC usa
no cspfel tipo de computación en los siguientes casos:-
Cuando el PCE envía
local cspfTLV y cuando la configuración o la plantilla de coincidencia de Junos OS 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 incluidono-cspfen el LSP iniciado por PCE. -
Cuando el PCE no envía
local cspfTLV con un ERO vacío o ERO suelto (con bit suelto establecido en el objeto ERO).
-
Con estos nuevos tipos de computación, un PCC puede aceptar un objeto ERO como un ERO suelto o como un ERO vacío. Una entidad de computación de ruta externa que no sea capaz de computar una ruta puede modificar parámetros como el ancho de banda y el color, según los análisis. En estos casos, se utiliza un objeto ERO vacío o un ERO suelto y el PCC decide la ruta a tomar.
LSP de punto a multipunto RSVP-TE controlado por PCE
Después de establecer una sesión PCEP entre un PCE y un PCC, el PCC informa todos los LSP del sistema al PCE para la sincronización del estado de LSP. Esto incluye LSP de punto a punto controlados por PCC, delegados por PCE y iniciados por PCE. A partir de Junos OS versión 15.1F6 y 16.1R1, esta capacidad se extiende para informar LSP de punto a multipunto también. Para un PCE, el LSP de punto a multipunto es similar al de LSP punto a multipunto RSVP, en el que el LSP de punto a multipunto se trata como una colección de LSP de 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 [edit protocols pcep pce pce-name] niveles de jerarquía o [edit protocols pcep pce-group group-id] . Después de configurar la capacidad del informe punto a multipunto en un PCC, el PCC anuncia esta capacidad en el PCE. Si el PCE anuncia la misma capacidad de informe de punto a multipunto a cambio, entonces el PCC informa el árbol LSP completo de punto a multipunto al PCE para la sincronización de estado de LSP.
Un PCC con la capacidad de LSP de TE de punto a multipunto admite la generación de informes de LSP de TE punto a multipunto para PCE con estado, actualización de punto a multipunto y base de datos de LSP que admite el nombre LSP de 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 de punto a multipunto delegados por PCE e iniciados por PCE
-
Ancho de banda automático
-
TE++
-
Mensaje de respuesta y solicitud PCE
-
Creación de LSP de punto a multipunto mediante plantillas
-
Configuración de entrada de reenvío en los LSP de punto a multipunto iniciados por PCE
-
Configurar entrada de reenvío en el enrutador que apunta a un LSP aprovisionado.
LSP de punto a punto iniciados por PCE
A partir de Junos OS versión 16.1, la funcionalidad de PCEP se extiende 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 configuraron 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 de ingeniería de tráfico de punto a punto dinámicamente sin la necesidad de un LSP configurado localmente en el PCC. Al recibir un mensaje PCCrear desde un PCE, el PCC crea el LSP iniciado por PCE y delega automáticamente el LSP en el PCE.
De forma predeterminada, un PCC rechaza la solicitud de aprovisionamiento de LSP de punto a punto iniciados por PCE desde un PCE. Para habilitar la compatibilidad con LSP initated PCE en el PCC, incluya la instrucción lsp-provisioning en los [edit protocols pcep pce pce-id] niveles o [edit protocols pcep pce-group group-id] jerarquía.
Un PCC indica su capacidad de admitir LSP de punto a punto iniciados por PCE mientras establece la sesión del protocolo de elemento de computación 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 de punto a punto iniciados por PCE, el PCC configura el LSP, asigna un ID de LSP y delega automáticamente el LSP en el PCE.
Cuando el PCE que inicia el LSP no proporciona los parámetros LSP de punto a punto iniciados por PCE, el PCC utiliza los parámetros predeterminados. También se puede configurar una plantilla LSP opcional para especificar valores para el LSP de punto a punto iniciado por PCE cuando el PCE no proporciona los parámetros LSP. Para configurar una plantilla LSP para LSP de punto a punto iniciados por PCE en el PCC, incluya la instrucción label-switched-path-template en el [edit protocols mpls lsp-external-controller lsp-external-controller] nivel jerárquico.
Cuando termina una sesión de PCEP, el PCC inicia dos temporizadores sin eliminar de inmediato los CSP iniciados por PCE ydelegation cleanup timeoutlsp cleanup timer—para evitar interrupciones de los servicios. Durante este tiempo, una PCE activa con estado puede adquirir el control de los LSP aprovisionados por la PCE fallida.
Un PCE puede devolver la delegación del LSP de punto a punto iniciado por PCE al PCC para permitir la transferencia de LSP entre PCE. El control sobre LSP iniciados por PCE vuelve al PCC al vencimiento del tiempo de espera de limpieza de la delegación. Cuando caduca el tiempo de espera de limpieza de la delegación y ningún otro PCE ha adquirido el control sobre el LSP a partir de la PCE fallida, el PCC toma el control local del LSP iniciado por PCE no delegado. Más tarde, cuando la PCE original o una nueva activa desea adquirir el control de los LSP de punto a punto iniciados por PCE controlados localmente, el PCC delega estos LSP en el PCE y el temporizador de limpieza de LSP se detiene.
El PCC espera a que expire el temporizador de limpieza de LSP antes de eliminar los LSP de punto a punto iniciados por PCE no delegados desde el PCE fallido. Cuando caduca el temporizador de limpieza de LSP y ningún otro PCE ha adquirido el control sobre los LSP a partir de la PCE fallida, el PCC elimina todos los LSP aprovisionados por el PCE fallido.
A partir de la versión 21.1R1 de Junos OS, admitemos el enrutamiento activo sin interrupciones (NSR) para los LSP de punto a punto y punto a multipunto iniciados por PCE. Solo el motor de enrutamiento principal mantiene la sesión PCEP con el controlador. Sincroniza todos los LSP RSVP iniciados por las PCE, incluidas las especificaciones de flujo de multidifusión para cualquier LSP P2MP iniciados por PCE, con el motor de enrutamiento de respaldo. Durante una conmutación, la sesión PCEP se cae y vuelve a establecer cuando el motor de enrutamiento de respaldo 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 LSP RSVP iniciados por PCE durante las conmutación del motor de enrutamiento. Esta función se habilita cuando se configura NSR.
LSP de bypass iniciado por PCE
- Descripción de los LSP de derivación iniciados por PCE
- Beneficios de la LSP de bypass iniciado por PCE
- Comportamiento de los LSP de bypass iniciados por PCE durante la falla de la sesión de PCEP
Descripción de los LSP de derivación iniciados por PCE
Puede haber interrupciones de tráfico en el momento de una falla de vínculo o nodo, ya que las rutas de protección de respaldo en la red no tienen suficiente ancho de banda para manejar el tráfico. En estas 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.
La versión 19.2R1 y las versiones posteriores de Junos OS proporcionan soporte parcial para el borrador de Internet draft-cbrt-pce-stateful-local-protection-01 (caduca en diciembre de 2018), extensiones de PCEP para RSVP-TE Local-Protection con PCE-Stateful, donde la funcionalidad PCEP se extiende para permitir que un PCE con estado inicie, aprovisione y administre LSP de omisión para una interfaz protegida. El PCE puede iniciar varios LSP de bypass con reserva de ancho de banda para proteger un vínculo o nodo. Se espera que el ancho de banda del LSP de bypass sea menor que el ancho de banda total de los LSP principales que podría proteger.
El mecanismo de selección de bypass existente, que prefiere los LSP de omisión manual (si está disponible) sobre los LSP de bypass dinámicos, se extiende para preferir los LSP de bypass aprovisionados por PCE (si están disponibles) en lugar de los LSP de omisión dinámicos. Los LSP de bypass aprovisionados por PCE tienen una mayor preferencia sobre los LSP de bypass dinámicos, pero son menos preferidos sobre los LSP de bypass manual.
El conjunto de operaciones que se utilizan para realizar en cualquier LSP de omisión operativa, como clear rsvp session, también se puede realizar en los LSP de bypass 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 de LSP de bypass iniciado por PCE, puede:
-
Cree un RSVP bypass LSP a través de PCEP desde un controlador externo, donde el LSP de omisión:
-
puede ser para protección de vínculo o nodo.
-
deben tener un ancho de banda que no sea cero.
-
debe tener una ERO estricta especificada.
-
-
Actualice el ancho de banda y la ERO para un LSP de derivación creado por PCE existente.
-
Suscribe sobrescriba el ancho de banda de LSP de bypass para el control de admisión de los LSP primarios. Este debe ser un parámetro por omisión y debe permitir actualizar la suscripción por LSP de omisión.
Beneficios de la LSP de bypass iniciado por PCE
Los LSP de bypass iniciados por PCE ofrecen los siguientes beneficios:
-
Mejor control sobre el tráfico después de una falla y cálculo de rutas de protección más determinista.
-
Cumpla con restricciones complejas y requisitos de diversidad, como mantener diversas rutas para LSP, así como sus rutas de protección local.
-
Asegúrese de que los vínculos no se sobrecargan durante los eventos de error.
Comportamiento de los LSP de bypass iniciados por PCE durante la falla de la sesión de PCEP
En el momento de un error de sesión PCEP, los LSP de derivación iniciados por PCE se vuelven huérfanos hasta que expire el temporizador de estado de espera. Los LSP de derivación iniciados por PCE se limpian al expirar el temporizador de estado de espera. Para obtener el control de un LSP de omisión iniciado por PCE (después de que se produce un error en la sesión de PCEP), un PCE (ya sea el PCE principal 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 LSP de punto a multipunto iniciado por PCE, un PCE puede iniciar y aprovisionar un LSP de punto a multipunto dinámicamente sin la necesidad de configuración local de LSP en el PCC. Esto permite que la PCE controle la temporización y la secuencia de las computaciones de ruta de punto a multipunto dentro y a través de las sesiones del Protocolo de elemento de computación de ruta (PCEP), lo que crea una red dinámica que se controla e implementa de forma centralizada.
Para obtener más información, consulte Descripción del protocolo de elementos de computación de ruta para RSVP-TE de MPLS con soporte para LSP de punto a multipunto iniciados por PCE.
LSP SRv6 en PCEP
El enrutamiento por segmentos se puede aplicar al plano de reenvío MPLS e IPv6. El elemento de computación de ruta (PCE) calcula las rutas 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 IPv6.
Beneficios de los LSP SRv6 en PCEP
- Le permite crear LSP SRv6 iniciados por PCE.
- Delega los LSP SRv6 creados en el enrutador al controlador.
- Reporte los LSP que se crean localmente en el enrutador al controlador.
- La programación de red SRv6 ofrece la flexibilidad para aprovechar el enrutamiento por segmentos sin implementar MPLS.
El PCEP admite la creación, la puesta al día y la eliminación de LSP SRv6 iniciados por PCE a color y sin color. Cuando el LSP SRv6 iniciado por PCE coexiste junto con un LSP SRv6 estático para la misma IP o IP basada en color, se prefiere la ruta de contribución SRv6 TE LSP estática sobre la ruta de contribución LSP de SRv6 TE iniciada por PCE.
Para configurar una sesión PCEP para que sea compatible con SRv6, debe habilitar la srv6-capability instrucción de configuración en [edit protocoles pcep pce pce-id] o en los niveles de jerarquía [edit protocols pcep pce-group pce-id] . Si la srv6-capability instrucción de 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 de jerarquía de [editar protocolos fuente-enrutamiento de paquetes].
[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 la lista de segmentos para SRv6 LSP, debe habilitar la maximum-srv6-segment-list-depth instrucción de 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 soporte de ancho de banda automático para LSP controlados por PCE. En versiones anteriores, la opción de ancho de banda automática no se aplicaba a los LSP controlados por PCE, aunque los LSP bajo el control de la banda automática y el enrutamiento 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 estaba teniendo efecto cuando el modo de control de un LSP controlado por PCE cambia de externo a local. Esto estaba sucediendo en casos como la ausencia 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 comunicación PCEP con un PCC. Un PCC envía informes de LSP a un servidor PCE, y el PCE actualiza o a provisiona los LSP al PCC. Los datos enviados a través de una sesión PCEP son cruciales para que un servidor PCE realice la computación de rutas externas. 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 inadecuados. De manera similar, si se envían mensajes PCEP alterados 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 manera efectiva, la versión 16.1 de Junos OS introduce la característica 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 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 enlazar la clave de autenticación MD5 en el [edit protocols pcep pce pce-id] nivel jerárquico de una sesión PCEP. Sin embargo, también puede usar un llavero predefinido desde el [edit security authentication-key-chains key-chain] nivel de jerarquía para proteger una sesión PCEP. En este caso, debe enlazar el llavero predefinido a la sesión PCEP en el [edit protocols pcep pce pce-id] nivel jerárquico.
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 correctamente, 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 usan la misma clave para verificar la autenticidad de cada segmento enviado en la conexión TCP de la sesión PCEP.
-
La versión 16.1 de Junos OS solo admite la autenticación TCP-MD5 para sesiones PCEP, sin extender 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 restablezca.
-
Si MD5 está mal configurado o no está configurado en un lado de la sesión PCEP, la sesión no se establece. Compruebe que las configuraciones de PCC y PCE coincidan.
-
Esta función no admite 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 de
show path-computation-client statuscomando yshow protocols pcep. -
Utilice el
show system statistics tcp | match authcomando para ver la cantidad de paquetes que TCP pierde debido a errores de autenticación. -
El funcionamiento del llavero se puede verificar mediante el resultado de
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 no puede ser trivial. En un único entorno de PCE centralizado, una PCE con estado simplemente debe 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 ESTADO DE PCE incluyen:
-
Cualquier mecanismo de sincronización confiable da como resultado una sobrecarga significativa del plano de control. Las PCE pueden sincronizar el estado comunicándose entre sí, pero cuando los LSP de TE se configuran mediante cálculos distribuidos realizados entre varios PCE, los problemas de sincronización y evitación de condiciones de carrera se vuelven más y más complejos.
-
La sincronización de bases de datos de ingeniería de tráfico fuera de banda puede ser compleja con múltiples PCE configurados en un modelo de computación de PCE distribuido, y puede ser propenso a condiciones de raza, problemas de escalabilidad, etc.
-
Los cálculos de ruta que incorporan el estado total de la red son altamente complejos, incluso si el PCE tiene información detallada de todas las rutas, prioridades y capas.
A pesar de las preocupaciones anteriores, la implementación parcial del lado del cliente de la PCE de estado es extremadamente eficaz en sistemas de ingeniería de tráfico de gran tamaño. Proporciona una convergencia rápida y beneficios significativos en términos de uso óptimo de recursos, ya que proporciona la necesidad de visibilidad global de un estado LSP de TE y un control ordenado de las reservas de rutas en todos los dispositivos dentro del sistema que se controla.
Ejemplo: Configuración del protocolo de elementos de computación de ruta para MPLS RSVP-TE
En este ejemplo, se muestra cómo habilitar la computación de rutas externas mediante un elemento de computación de ruta (PCE) para rutas conmutadas por etiquetas diseñadas por tráfico (LSP de TE) en un cliente de computación de ruta (PCC). También muestra cómo configurar el protocolo de elementos de computación de ruta (PCEP) en el PCC para habilitar la comunicación 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 de la serie ACX, enrutadores de borde multiservicio serie M, plataformas de enrutamiento universal de 5G serie MX, enrutadores de núcleo de la serie T o enrutadores de transporte de la serie PTX, uno de los cuales está configurado como PCC.
Una conexión TCP a una PCE externa con estado desde el PCC.
Junos OS versión 12.3 o posterior se ejecuta en el PCC junto con el paquete de complemento 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 RSVP-TE de MPLS se extiende para ofrecer una implementación parcial del lado del 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 de 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, como se define en el borrador de Internet draft-ietf-pce-stateful-pce-07. Las versiones anteriores a 16.1 admiten la versión anterior del borrador de PCE, lo que causa 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 rutas externas mediante un PCE, incluya la lsp-external-controller instrucción en el PCC en los [edit mpls] niveles de jerarquía y [edit mpls lsp lsp-name] .
lsp-external-controller pccd;
Un LSP configurado con la lsp-external-controller instrucción se conoce como un LSP controlado por PCE y está bajo el control externo de un PCE de forma predeterminada. Una PCE con estado activo puede invalidar los parámetros establecidos desde la CLI, como ancho de banda, ruta (ERO) y prioridad, para dichos LSP controlados por PCE del PCC.
Para habilitar la comunicación PCE a PCC, configure el PCEP en el PCC en el [edit protocols] nivel jerárquico.
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.
La versión 12.3 de Junos OS solo admite PC con estado.
Un PCC puede conectarse a un máximo de 10 PCE con estado. En cualquier momento dado, solo puede haber un PCE principal (el PCE con el valor de prioridad más bajo, o el PCE que se conecta al PCC primero en ausencia de una prioridad PCE) en el que el PCC delega LSP para el cálculo de rutas.
Para Junos OS versión 12.3, el PCC siempre inicia las sesiones de PCEP. Las sesiones PCEP iniciadas por PCE remotos no son aceptadas por el PCC.
Las funciones de LSP existentes, como la protección de LSP y hacer antes de la interrupción, funcionan para LSP controlados por PCE.
La opción de ancho de banda automática está desactivada para los LSP controlados por PCE, aunque los LSP bajo el control de la banda automática y el enrutamiento 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 de la computación de ruta externa, lo que afecta el tiempo de configuración general, los reenrutamientos y las funciones de "make-before-break".
El tiempo de configuración y el tiempo de convergencia (reenrutamiento, MBB) para eliminar LSP es el mismo que en versiones anteriores, en ausencia de LSP controlados por PCE. Sin embargo, se observa un pequeño impacto en la presencia de LSP controlados por PCE.
Se espera que el tiempo de computación 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 ENRUTADOR PCC se calculan de la siguiente manera:
El PCC del enrutador recibe la configuración de túnel LSP que se configuró mediante la CLI. Suponiendo que la configuración recibida está habilitada con computación de rutas externas, el enrutador PCC se da cuenta de que algunos de los atributos de LSP (ancho de banda, ruta y prioridad) están bajo el control de la PCE de estado y delega el LSP en el PCE.
En este ejemplo, se llama
PCC-to-R2el LSP externo y se está configurando desde el enrutador PCC al enrutador R2 . El ERO configurado por CLI paraPCC-to-R2es PCC-R0-R1-R2. El ancho de banda paraPCC-to-R2es de 10 m, y tanto la configuración como los valores de prioridad de espera son 4.El ENRUTADOR PCC intenta recuperar los atributos LSP controlados por PCE. Para ello, el enrutador PCC envía un mensaje PCRpt al PCE de estado que indica que el LSP se ha configurado. 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 más de los atributos LSP delegados y envía los nuevos parámetros de LSP al enrutador PCC a través del mensaje PCUpd.
Al recibir los nuevos parámetros de LSP, el enrutador PCC configura un nuevo LSP y lo vuelve a señalizar mediante 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 tanto la configuración como los valores de prioridad de espera son 3.El ENRUTADOR PCC envía un PCRpt con la nueva 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, luego, copie y pegue los comandos en la CLI en el [edit] nivel de 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
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración.
Para configurar el PCC del enrutador:
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 apropiados 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 conmutada por etiquetas (LSP) del enrutador PCC al enrutador R2 y habilite el control externo de los LSP mediante el 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 desde el enrutador PCC al enrutador R2, que tiene control local y es anulado 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 enrutador PCC 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 enrutador PCC 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 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, ingrese los comandos y show protocols para confirmar la show interfaces 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;
}
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Verificación
Confirme que la configuración funciona correctamente.
- Verificar el estado de la sesión de PCEP
- Verificar el estado de LSP controlado por PCE cuando el control de LSP es externo
- Verificar el estado de LSP controlado por PCE cuando el control de LSP es local
Verificar el estado de la sesión de PCEP
Propósito
Compruebe 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
El resultado 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 PCEP es PCE_STATE_UP, lo que indica que la sesión PCEP se ha establecido entre los pares PCEP.
Las estadísticas de PCRpts indican el número de mensajes enviados por el enrutador PCC al PCE para informar el 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 de PCE para los LSP controlados por PCE.
Verificar el estado de LSP controlado por PCE cuando el control de LSP es externo
Propósito
Verifique el estado del LSP controlado por PCE desde el 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 el resultado, los LSPtype campos y LSP Control Status de salida muestran que el LSP está controlado externamente. El resultado también muestra un registro de los mensajes PCEP enviados entre el enrutador PCC y el PCE.
La sesión PCEP entre el PCE y el ENRUTADOR PCC está activa, 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
Bandwidth—8Mbps
Prioridades: 3 3 (valores de configuración y de espera)
Verificar el estado de LSP controlado por PCE cuando el control de LSP es local
Propósito
Verifique el estado del LSP controlado por PCE desde el enrutador PCC al enrutador R2 cuando el control LSP se vuelva 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 el resultado, 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 enrutador PCC sigue usando los parámetros proporcionados por PCE, hasta la próxima oportunidad de volver a señalizar el LSP.
El resultado ahora muestra los parámetros 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 (Ancho de banda actual: 8 Mbps)
Prioridades: 4 4 (Prioridades reales 3 3)
En el desencadenador para volver a señalizar el LSP, el enrutador PCC usa 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 mediante los parámetros de configuración local.
Ejemplo: Configuración del protocolo de elementos de computación de ruta para MPLS RSVP-TE con soporte de LSP de punto a punto iniciados por PCE
En este ejemplo, se muestra cómo configurar el cliente de computación de ruta (PCC) con la capacidad de admitir rutas de conmutación de etiquetas (LSP) de punto a punto iniciadas por el elemento de computación 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 enrutadores serie T.
Una conexión TCP a dos PCE externos con estado del enrutador de entrada (PCC).
Junos OS versión 16.1 o posterior se ejecuta en el PCC.
Antes de empezar:
Configure las interfaces del dispositivo.
Configure MPLS y RSVP-TE (RSVP-Ingeniería de tráfico).
Configure el OSPF o cualquier otro protocolo IGP.
Descripción general
A partir de Junos OS versión 16.1, la funcionalidad de PCEP se extiende 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 configuraron 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 de ingeniería de tráfico de punto a punto dinámicamente sin la necesidad de un LSP configurado localmente en el PCC. Al recibir un mensaje PCCrear desde un PCE, el PCC crea el LSP iniciado por PCE y delega automáticamente el LSP en el PCE.
Al configurar la compatibilidad de LSP de punto a punto iniciados por PCE para un PCC, tenga en cuenta las siguientes consideraciones:
Junos OS versión 13.3 solo admite PC con estado.
Para Junos OS versión 13.3, el PCC siempre inicia las sesiones de PCEP. Las sesiones PCEP iniciadas por PCE remotos no son aceptadas por el PCC.
Las funciones de LSP existentes, como la protección de LSP y hacer antes de la interrupción, funcionan para LSP iniciados por PCE.
Los LSP iniciados por PCE no admiten la conmutación agraciada de motor de enrutamiento (GRES).
Los LSP iniciados por PCE bajo sistemas lógicos no son compatibles.
Los LSP iniciados por PCE no pueden ser LSP de punto a multipunto.
No se admiten LSP bidireccionales.
No se admite RSVP-TE para vínculos no numerados. Los LSP iniciados por PCE solo admiten vínculos numerados.
El PCE que inicia un LSP de enrutamiento por segmentos puede usar las etiquetas de ID de segmento de enlace (SID) asociadas con LSP de enrutamiento de segmentos sin color para aprovisionar las rutas LSP de enrutamiento de segmentos iniciados por PCE.
A partir de Junos OS versión 18.2R1, los LSP de enrutamiento de segmentos sin color configurados estáticamente en el dispositivo de entrada se informan a un PCE mediante una sesión PCEP. Estos LSP de enrutamiento de segmentos sin colores pueden tener etiquetas SID enlazantes asociadas con ellos. Con esta función, el PCE puede usar esta etiqueta SID de enlace en la pila de etiquetas para aprovisionar rutas LSP de enrutamiento por segmentos iniciados por PCE.
Topología
En este ejemplo, PCC es el enrutador de entrada que se conecta a dos PCE de estado externos: PCE1 y PCE2.
Cuando hay una nueva demanda, la PCE de estado activa inicia dinámicamente un LSP para cumplir con el requisito. Dado que la PCC está configurada con la capacidad de admitir el LSP iniciado por PCE, el cálculo de 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 mediante los parámetros recibidos del PCE y delega automáticamente el LSP iniciado por PCE en el PCE que lo inició.
En este ejemplo, PCE1 es el PCE con estado activo que inicia y abaste 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 termina la sesión PCEP entre PCC y PCE1, PCC inicia dos temporizadores para el LSP iniciado por PCE1: tiempo de espera de limpieza de la desagregación y el temporizador de limpieza de LSP. Durante este tiempo, PCE1 o PCE2 pueden adquirir el control de los LSP iniciados 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 la delegación se detienen.
Si el tiempo de espera de limpieza de la delegación expiró 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 que expire el 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, luego, copie y pegue los comandos en la CLI en el [edit] nivel de 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
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más 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 apropiados 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 mediante las PCE.
[edit protocols] user@PCC# set mpls lsp-external-controller pccd
Habilite MPLS en todas las interfaces de la 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 de la 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 con 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 los 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, ingrese los comandos y show protocols para confirmar la show interfaces 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;
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Verificación
Confirme que la configuración funciona correctamente.
- Verificar el estado de PCC
- Verificar el estado de PCE1
- Verificar el estado del LSP iniciado por PCE cuando el LSP se aprovisiona externamente
Verificar el estado de PCC
Propósito
Compruebe el estado de la sesión de PCEP y el resumen de LSP entre el PCC y las PCE conectadas.
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 PCEP entre las PCE con estado activo y el PCC. También muestra información sobre los diferentes tipos de LSP en el PCC, y la cantidad de LSP aprovisionados por las PCE conectadas y delegados en ellos.
La PCE1 es la PCE principal activa y tiene un LSP iniciado por PCE que el PCC le ha delegado automáticamente.
Verificar el estado de PCE1
Propósito
Compruebe el estado de la PCE de estado principal activa.
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
El resultado muestra información sobre el PCE de estado activo actual al que está conectado el PCC. El PCE status campo de salida indica el estado actual de la sesión PCEP entre un PCE y un PCC.
Para PCE1, el estado de la sesión PCEP es PCE_STATE_UP, lo que indica que la sesión PCEP se ha establecido con el PCC.
Verificar el estado del LSP iniciado por PCE cuando el LSP se aprovisiona externamente
Propósito
Compruebe 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 el resultado, el LSPtype campo de salida muestra que el LSP se aprovisiona externamente.
La sesión PCEP entre PCC y PCE1 está activa, 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 espera)
Configuración del protocolo de elementos de computación de ruta para MPLS RSVP-TE con soporte de LSP de punto a punto iniciados por PCE
Puede configurar un cliente de computación de ruta (PCC) con la capacidad de admitir rutas conmutadas por etiquetas (LSP) creadas dinámicamente desde una entidad de computación de ruta externa centralizada. Se puede utilizar un elemento computaiton de ruta de 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 de punto a punto iniciado por PCE mediante los parámetros LSP proporcionados por PCE o los parámetros de una plantilla LSP preconfigurada cuando el PCE no aprovisiona el LSP y delega automáticamente el LSP de punto a punto iniciado por PCE en el PCE respectivo. Como resultado, para los LSP iniciados por PCE, no es necesario un LSP configurado localmente en el PCC.
Un LSP controlado por CLI, LSP controlado por PCE y 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 el OSPF o cualquier otro protocolo IGP.
Para configurar el PCC para que admita LSP de punto a punto iniciados por PCE, complete 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 elementos de computación de ruta para MPLS RSVP-TE con soporte para LSP punto a multipunto controlado por PCE
En este ejemplo, se muestra cómo configurar el cliente de computación de ruta (PCC) con la capacidad de generar informes de tráfico de punto a multipunto de rutas conmutadas por etiquetas (LSP de TE) a un elemento de computación 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 enrutadores serie T.
Una máquina virtual configurada con la función reflector de ruta virtual (VRR).
Una conexión TCP a un PCE de estado externo desde el VRR.
Junos OS versión 16.1 o posterior se ejecuta en el PCC.
Antes de empezar:
Configure las interfaces del dispositivo.
Configure MPLS y RSVP-TE.
Configure el OSPF o cualquier otro protocolo IGP.
Descripción general
Después de establecer una sesión PCEP entre un PCE y un PCC, el PCC informa todos los LSP del sistema al PCE para la sincronización del estado de LSP. Esto incluye LSP de punto a punto controlados por PCC, delegados por PCE y iniciados por PCE. A partir de Junos OS versión 15.1F6 y 16.1R1, esta capacidad se extiende para informar LSP de punto a multipunto también.
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 [edit protocols pcep pce pce-name] niveles de 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. El PCC está conectado a un reflector de ruta virtual (VRR) que está conectado a un PCE. Hay muchas interfaces de punto a multipunto entre PCC, enrutador R1 y R2.
El informe de LSP punto a multipunto se ejecuta de la siguiente manera:
Si el PCC del enrutador está configurado con LSP de punto a punto y punto a multipunto sin la compatibilidad con la capacidad de generación de informes de punto a multipunto, solo se notifican los LSP punto a punto al PCE conectado. De forma predeterminada, un PCC no admite la capacidad de generación de informes de LSP de punto a multipunto.
Cuando el enrutador PCC está configurado con capacidad de generación de informes de LSP de punto a multipunto, PCC anuncia primero esta capacidad en PCE a través de un mensaje de informe.
De forma predeterminada, un PCE proporciona soporte para la capacidad LSP de punto a multipunto. Al recibir el anuncio de la PCC de la capacidad de LSP de punto a multipunto, el PCE a cambio anuncia su capacidad en el PCC.
Al recibir el anuncio de la PCE de la capacidad de punto a multipunto, PCC informa todas las sucursales de LSP de punto a multipunto al PCE mediante el mensaje de actualización.
Una vez que se informan todos los LSP al PCE, el estado del 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, luego, copie y pegue los comandos en la CLI en el [edit] nivel de 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
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más 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 desactive 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 los LSP de punto a multipunto y defina la entidad de computación 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 computación de rutas externas para los LSP MPLS y asigne una plantilla para 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 que son anulados 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 políticas 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 políticas de grupo administrativo 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 base 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 el 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 de punto a multipunto del enrutador PCC.
[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 enrutador PCC.
[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 enrutador PCC 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 LSP de punto a multipunto para la computación de rutas externas.
[edit protocols] set pcep pce pce1 p2mp-lsp-report-capability
Configure la política 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, ingrese los comandos y show protocols para confirmar la show interfaces 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 funciona correctamente.
Verificar la configuración de LSP en el PCC
Propósito
Compruebe el tipo de LSP y el estado de ejecución de la LSP de 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
El resultado muestra el LSP lsp2-pcc como LSP controlado por PCE.
Verificar la configuración de PCE en el PCC
Propósito
Verifique la configuración de los parámetros PCE y el estado 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
El resultado muestra el PCE activo al que está conectado el enrutador PCC, y los parámetros pce1 PCE y el estado.
Descripción del protocolo de elementos de computación de ruta para RSVP-TE de MPLS con soporte para LSP de punto a multipunto iniciado por PCE
Con la introducción de LSP de punto a multipunto iniciado por PCE, un PCE puede iniciar y aprovisionar un LSP de punto a multipunto dinámicamente sin la necesidad de configuración local de LSP en el PCC. Esto permite que la PCE controle la temporización y la secuencia de las computaciones de ruta de punto a multipunto dentro y a través de las sesiones del Protocolo de elemento de computación de ruta (PCEP), lo que crea una red dinámica que se controla e implementa de forma centralizada.
- Beneficios de los LSP de punto a multipunto iniciados por PCE
- Señalización de LSP de punto a multipunto iniciados por PCE
- Comportamiento de los LSP de punto a multipunto iniciados por PCE después de un error de sesión de PCEP
- Configuración de la capacidad LSP de punto a multipunto iniciado por PCE
- Funciones compatibles y no compatibles para LSP de punto a multipunto iniciados por PCE
- Asignación de LSP de punto a multipunto iniciados por PCE a MVPN
Beneficios de los LSP de punto a multipunto iniciados por PCE
Cumple con los requisitos de la colocación de LSP de ingeniería de tráfico de punto a multipunto en respuesta a las demandas de las aplicaciones mediante la creación y el desmontado dinámicos de LSP de punto a multipunto, lo que crea una red dinámica que se controla y despliega de forma centralizada.
Señalización de LSP de punto a multipunto iniciados por PCE
La señalización de los LSP de punto a multipunto iniciados por PCE es el siguiente:
-
When a new branch is added (Grafting)— Solo se indica el nuevo sub-LSP de la sucursal y no se vuelve a señalizar todo el árbol punto a multipunto.
Si se produjo algún cambio de topología antes del aprovisionamiento del nuevo sub-LSP, el servidor de computación de ruta (PCS) vuelve a computar 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 sucursal eliminado se elimina y no da lugar a una re-señalización de todo el árbol de punto a multipunto.
-
When a branch sub-LSP parameter is changed— Los cambios en los parámetros sub LSP, como el objeto de ruta explícita (ERO), el ancho de banda o la prioridad, pueden ocurrir ya sea debido a la optimización o a petición del usuario. Si hay una solicitud de re-señalización para un sub-LSP, se vuelve a señalizar todo el árbol de punto a multipunto y, luego, el cambio a la nueva instancia se realiza una vez que las nuevas instancias de todas las sucursales están activas.
-
When a branch sub-LSP path fails— Se informa de un error al PCS por el sub-LSP de la sucursal fallida. Al recibir el nuevo ERO desde el PCS, se vuelve a señalar todo el árbol de punto a multipunto junto con el sub-LSP de la sucursal fallida, y el cambio a la nueva instancia se realiza de forma de marcación antes de interrupción (MBB).
Comportamiento de los LSP de punto a multipunto iniciados por PCE después de un error de sesión de PCEP
Cuando se produce un error en una sesión de PCEP, los LSP de punto a multipunto iniciados por PCE quedan huérfanos hasta la expiración del state timeout temporizador. Después de que caduca el state timeout temporizador, los LSP iniciados por PCE se limpian.
Para obtener el control de un LSP de punto a multipunto iniciado por PCE después de un error de sesión PCEP, la PCE principal o secundaria envía un PCInitiate mensaje antes de que expire el state timeout temporizador.
Configuración de la capacidad LSP de punto a multipunto iniciado por PCE
De forma predeterminada, la creación y el aprovisionamiento de LSP de punto a multipunto por un PCE no se admiten en un PCC. Para habilitar esta capacidad, incluya las p2mp-lsp-init-capability instrucciones y p2mp-lsp-update-capability en los [edit protocols pcep pce pce-name] niveles de jerarquía o [edit protocols pcep pce-group group-id] .
La p2mp-lsp-init-capability instrucción proporciona la capacidad de aprovisionar LSP de punto a multipunto RSVP-TE mediante una PCE. La p2mp-lsp-update-capability instrucción proporciona la capacidad de actualizar los parámetros LSP de punto a multipunto RSVP-TE mediante una PCE.
Funciones compatibles y no compatibles para LSP de punto a multipunto iniciados por PCE
Se admiten las siguientes funciones con LSP de punto a multipunto iniciados por PCE:
-
Cumplimiento parcial con el borrador de Internet draft-ietf-pce-stateful-pce-p2mp (caduca en octubre de 2018), extensiones de protocolo del elemento de computación de ruta (PCE) para el uso de PCE de estado para las rutas conmutadas con etiqueta de ingeniería de tráfico punto a multipunto.
- A partir de Junos OS versión 21.1R1, somos compatibles con el enrutamiento activo sin interrupciones (NSR) para los LSP de punto a multipunto iniciados por PCE de RSVP. Solo el motor de enrutamiento principal mantiene la sesión PCEP con el controlador. Sincroniza todos los LSP RSVP iniciados por las PCE, incluidas las especificaciones de flujo de multidifusión para cualquier LSP P2MP iniciados por PCE, con el motor de enrutamiento de respaldo. Durante una conmutación, la sesión PCEP se cae y vuelve a establecer cuando el motor de enrutamiento de respaldo 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 LSP RSVP iniciados por PCE durante las conmutación del motor de enrutamiento. Esta función se habilita cuando se configura NSR.
Las siguientes funciones no se admiten con LSP de 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 el descubrimiento de PCE dentro de un dominio de enrutamiento IGP.
-
Mensajes de solicitud/respuesta.
-
Movimiento directo del sub-LSP de una sucursal de un árbol de punto a multipunto a otro.
Lo mismo se puede lograr mediante la eliminación de una sub-LSP de sucursal del primer árbol de punto a multipunto y volver a agregarlo a otro después de que el mensaje indique la
PCReporteliminación de LSP del dispositivo. -
No se admite IPv6.
-
No se admite la señalización basada en SERO.
-
No se admite la función ERO vacía.
-
No se admite la protección de vínculos.
Asignación de LSP de punto a multipunto iniciados por PCE a MVPN
Puede asociar un solo o 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 dinámicamente. Solo puede especificar tipos de flujos selectos para que funcione esta característica. entre las que se incluyen las siguientes:
-
Distinguidor de ruta (RD) que se asigna a la instancia de enrutamiento de MVPN.
-
(S, G) que es el origen de un paquete de multidifusión y una dirección de grupo de multidifusión de destino. Esto se utiliza para filtrar el tráfico entrante para 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 detalles, consulte borrador de Internet draft-ietf-pce-pcep-flowspec-05 (caduca el 16 de febrero de 2020) Extensión de PCEP para especificación de flujo.
La implementación actual de esta función no implementa las siguientes secciones del borrador:
-
Sección 3.1.2— Capacidades PCE publicitarias en IGP
-
Sección 3.2— Mensaje PCReq y PCRep
-
Sección 7: la mayoría de las especificaciones de flujo, excepto la distingu de rutaLa implementación actual de esta función no supone las especificaciones de flujo de multidifusión IPv4, no son compatibles.
Para habilitar la asignación de LSP de punto a multipunto iniciados por PCE a MVPN:
-
Incluya la
pce_traffic_steeringinstrucción en el[edit protocols pcep pce pce-id]nivel de jerarquía para indicar que el PCC admite la capacidad de especificación de flujo (también llamada dirección de tráfico). -
Incluya la
external-controllerinstrucción en el[edit routing-instances routing-instance-name provider-tunnel]nivel de jerarquía.La presencia en la configuración del túnel del
external-controllerproveedor para MVPN indica que el controlador externo puede proporcionar el LSP y (S, G) de punto a multipunto para esta instancia de MVPN. Esto permite que el controlador externo configure dinámicamente (S, G) y LSP de punto a multipunto para MVPN.
Tome en consideración lo siguiente para la asignación de LSP de 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 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 más alta.
-
Si el controlador externo aprende dinámicamente un controlador externo (S, G) y configura el mismo (S,G) para la misma instancia de MVPN, la herramienta 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 reconfigura todo el (S, G) de nuevo.
-
Si el proceso PCCD se reinicia, MVPN informa todos los PCCD configurados (S, G) al controlador externo.
-
Si el usuario habilita
external-controller pccduna instancia de MVPN en particular, MVPN solicita la configuración del proceso PCCD (S, G), si hay alguna. -
Si hay cambios de configuración importantes en una instancia de MPVN determinada, MVPN solicita al proceso PCCD para reconfigurar todo (S, G) para esa instancia de MVPN en particular.
-
Todas las especificaciones de flujo asociadas con cualquier LSP de punto a multipunto iniciado por PCE deben tener el mismo RD. Durante la iniciación de PC, si todas las especificaciones de flujo no tienen el mismo RD, el mensaje de inicio de PC se pierde con un error.
-
Puede asociar un LSP de punto a multipunto solo con especificaciones de tipo de flujo selectivas, de lo contrario, el mensaje de inicio de PC se pierde con un error.
-
Durante la actualización de PC, si todas las especificaciones de flujo no tienen el mismo RD debido a una nueva adición de especificación de flujo o debido a una actualización existente de la especificación de flujo, el PCC deja caer el mensaje de actualización.
-
Durante la actualización de PC, si todas las especificaciones de flujo no cumplen con la condición selectiva debido a la adición de nuevas especificaciones de flujo o debido a la actualización existente de las especificaciones de flujo, el PCC deja caer el mensaje de actualización.
-
El comportamiento para la asignación de LSP de punto a multipunto iniciado por PCE con instancia de enrutamiento MVPN y asignación de LSP de punto a multipunto estático (configurado localmente) con instancia de MVPN es el mismo a nivel de usuario.
-
Solo se puede asociar un ID de especificación de flujo 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 y (S, G).
-
En el caso de las dinámicas asignadas por PCEP (S, G), el valor de umbral siempre es el valor predeterminado de 0.
-
No hay límite en la cantidad de especificaciones de flujo asignadas a un único LSP de punto a multipunto iniciado por PCE.
-
La implementación actual de esta función no admite lo siguiente:
-
Informes de estados de reenvío asociados con el LSP de punto a multipunto.
-
Configuración dinámica de túnel de proveedor inclusivo
-
Asignación para túneles de replicación de entrada MVPN
-
Proceso de protocolo de enrutamiento programable (prpd)
-
Generación de informes de LSP de punto a multipunto configurado de CLI que se asigna a flujos de multidifusión (S, G) de MVPN.
-
Consulte también
Habilitar el enrutamiento por segmentos para el protocolo de elemento de computación de ruta
SUMMARY Puede habilitar el enrutamiento por segmentos o el enrutamiento de paquetes de origen en la ingeniería de tráfico de redes (SPRING) (SR-TE) con el protocolo de elementos de computación de ruta (PCEP) para dirigir el tráfico. Con este soporte, las ventajas del enrutamiento por segmentos se extienden a las rutas conmutadas por etiquetas (LSP) que son controladas externamente por un elemento de computación de ruta (PCE).
- Descripción general del enrutamiento por segmentos para el protocolo de elementos de computación de ruta
- Ejemplo: Configurar el enrutamiento por segmentos para el protocolo de elementos de computación de ruta
Descripción general del enrutamiento por segmentos para el protocolo de elementos de computación de ruta
- Beneficios del enrutamiento por segmentos para PCEP
- Enrutamiento por segmentos para la ingeniería de tráfico
- Implementación de Junos OS del enrutamiento por segmentos para PCEP
- Enrutamiento por segmentos para limitaciones de PCEP y funciones no compatibles
Beneficios del enrutamiento por segmentos para PCEP
La configuración de LSP a través de un controlador externo ofrece una vista global de la demanda de ancho de banda por LSP y por dispositivo en la red, lo que permite la computación de rutas en línea y basada en restricciones en tiempo real.
Las ventajas del enrutamiento por segmentos se extienden a los LSP iniciados por un controlador externo, también conocido como elemento de computación de ruta (PCE), aumentando las ventajas de la computación de rutas externas en una red MPLS.
Un cliente de computación 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 falla; 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 descartan o se pierden silenciosamente (también conocida como una condición de ruta nula).
Enrutamiento por segmentos para la ingeniería de tráfico
El enrutamiento por segmentos puede funcionar a través de un plano de datos IPv4 o IPv6, y admite varias rutas de costo igual (ECMP). Con las extensiones de IGP integradas, el enrutamiento por segmentos se integra con las ricas capacidades multiservicio de MPLS, incluyendo VPN de capa 3, servicio de cable privado virtual (VPWS), servicio de LAN privada virtual (VPLS) y VPN Ethernet (EVPN).
Algunos de los componentes de alto nivel de la solución de ingeniería de tráfico y enrutamiento por segmentos (SR–TE) incluyen:
Uso de un IGP para las características de los vínculos publicitarios. Esta funcionalidad es similar a la de RSVP-TE.
Uso de la primera ruta más corta restringida (CSPF) en el dispositivo de entrada o el PCE.
Uso de un IGP para anunciar etiquetas para enlaces.
En la funcionalidad de SR-TE:
El dispositivo de entrada crea un LSP apilando las etiquetas de los vínculos que desea atravesar.
El anuncio de IGP por vínculo se combina con el apilamiento de etiquetas para crear LSP enrutados de origen en el dispositivo de entrada, de modo que los dispositivos de tránsito no conozcan 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, ya que no hay señalización por LSP en SR-TE.)
Las etiquetas por vecino se apilan, lo que da como resultado la gestión de un gran número de etiquetas, lo que lleva a controlar el escalado del plano.
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: LSP iniciados por PCE y LSP delegados por PCE.
- LSP de enrutamiento por segmentos iniciados por PCE
- LSP de enrutamiento por segmentos delegados por PCE
LSP de enrutamiento por segmentos iniciados por PCE
Los LSP de enrutamiento por 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.
Abastece el LSP en el cliente de computación de ruta (PCC) mediante extensiones de enrutamiento por segmentos PCEP.
Analiza las extensiones de enrutamiento por segmentos PCEP.
Crea una ruta de túnel en la 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 de red (NAI) del objeto de ruta explícita de origen (S-ERO).
Junos OS admite S-EROs que contienen el primer salto como un salto estricto; Junos OS no admite la selección de la interfaz de salida en la PCC basada en un ID de segmento de nodo (SID) de salto flexible. Sin embargo, el resto de los saltos pueden ser flojos. 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 saltos.
El PCC crea una ruta multiruta 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 lleve a un cambio en el LSP de enrutamiento de segmentos después de su aprovisionamiento; por ejemplo, si se cambia o retira la etiqueta o si una de las interfaces atravesadas por el LSP falla.
Cuando la sesión PCEP falla, el LSP de enrutamiento por 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), Transmisión del tipo de configuración de ruta en mensajes PCEP; y draft-ietf-pce-segment-routing-06.txt (caduca el 10 de febrero de 2016), extensiones PCEP para enrutamiento por segmentos.
LSP de enrutamiento por segmentos delegados por PCE
Los LSP de enrutamiento por segmentos delegados por PCE son aquellos LSP que el PCC configura localmente y, luego, delega en un controlador PCE.
Junos OS versión 20.1R1 admite:
Capacidad de delegación de PCE solo para LSP de enrutamiento por segmentos sin color con destinos IPv4.
Delegación y presentación de informes solo del primer segmento de una lista de segmentos a un controlador externo. No se admiten varios segmentos para la delegación de PCE.
El PCC puede delegar un LSP de enrutamiento por segmentos 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 se produce 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 se realiza 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 por segmentos, el PCE controla los LSP delegados y puede modificar los atributos de LSP para el cálculo de rutas. El control LSP vuelve al PCC cuando la sesión PCEP entre el PCC y el PCE falla. Los LSP delegados por PCE tienen una ventaja sobre los LSP iniciados por PCE en caso de que la sesión del PCEP falla. En el caso de los LSP iniciados por PCE, cuando la sesión PCEP está desactivada, los LSP se eliminan del PCC. Sin embargo, en el caso de los LSP delegados por PCE, cuando la sesión PCEP falla, el PCC toma 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 null) cuando la sesión falla.
Los siguientes tipos de LSP de enrutamiento por segmentos admiten la capacidad de delegación de PCE:
Static LSPs— Rutas de enrutamiento de origen configuradas estáticamente que tienen toda la pila de etiquetas estáticamente configurada.
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 primera ruta de ruta más corta (CSPF) distribuida.
Dynamic LSPs— Los túneles creados dinámicamente se activan a través del módulo de túnel dinámico que tienen resolución ERO de último salto.
Según el origen del LSP de enrutamiento por 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 adecuado en 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 se habilita la capacidad de delegación.
Debe incluir la instrucción en los lsp-external-controller pccd[edit protocols source-packet-routing] niveles de jerarquía y y [edit protocols mpls] antes de configurar la capacidad de delegación en el PCC.
Fuente de LSP de enrutamiento por segmentos |
Jerarquía de configuración |
|---|---|
|
Lista de segmentos principales en |
LSP computados (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 de controlador externo lsp |
estado de delegación de ruta de enrutamiento de origen |
Interacción PCEP entre PCC y PCE |
|---|---|---|
Lista de segmentos principales de ruta de enrutamiento de origen |
Delegación inicial |
El mismo comportamiento se ve cuando el proceso de protocolo de enrutamiento (rpd) se reinicia o se produce una conmutación del motor de enrutamiento. |
Lista de segmentos principales 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 usa y se utiliza el resultado del cálculo de la configuración local. Cuando el resultado local de la lista de segmentos está disponible, se utiliza la lista de segmentos correspondiente para programar la ruta de forma que se haga antes de la pausa. |
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 la plantilla de ruta de enrutamiento de origen |
La delegación se habilita después de configurar LSP. |
|
Lista de segmentos principales de la plantilla 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 las rutas principales que coincidan con la configuración de la plantilla. |
Enrutamiento por segmentos para limitaciones de PCEP y funciones no compatibles
La compatibilidad con el enrutamiento por segmentos para PCEP no agrega a la carga de rendimiento del sistema. Sin embargo, tiene las siguientes limitaciones:
Un LSP de 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 más que para transportar tráfico IP sin formato.
No se admite la conmutación graceful del motor de enrutamiento (GRES) y la actualización unificada de software en servicio (ISSU unificado).
No se admite el enrutamiento activo sin interrupciones (NSR).
No se admite IPv6.
Los LSP delegados por PCE no admiten lo siguiente:
LSP DE 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 se delega el primer segmento de la lista de segmentos y se informa al controlador.
Ejemplo: Configurar el enrutamiento por segmentos para el protocolo de elementos de computación de ruta
En este ejemplo, se muestra cómo configurar el enrutamiento por segmentos o el enrutamiento de paquetes de origen en la ingeniería de tráfico de redes (SPRING) (SR-TE) para el protocolo de elementos de computación de ruta (PCEP). En la configuración, aprovechamos las ventajas del enrutamiento por segmentos con las ventajas de la computación de rutas externas 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 de 5G serie MX, donde el enrutador de entrada serie MX es el cliente de computación de ruta (PCC).
Una conexión TCP desde el PCC a un elemento de computación de ruta de estado (PCE) externo.
Junos OS versión 17.2 o posterior se ejecuta 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 LSP de SR-TE iniciados por PCE y delegados por PCE.
La implementación de los LSP iniciados por PCE se presenta 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 iniciados 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 presenta en Junos OS versión 20.1R1, donde los LSP de enrutamiento de segmentos IPv4 configurados localmente en el PCC se pueden delegar a un controlador PCE. Luego, el PCE controla el LSP y puede modificar los atributos de LSP para el cálculo de rutas.
Los LSP delegados por PCE tienen una ventaja sobre los LSP iniciados por PCE en el momento en que cae la sesión del PCEP. En el caso de los LSP iniciados por PCE, cuando la sesión PCEP está desactivada, los LSP se eliminan del PCC. Sin embargo, en el caso de los LSP delegados por PCE, cuando la sesión PCEP falla, el PCC toma 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 null) cuando la sesión PCEP falla.
Para habilitar el enrutamiento por segmentos para PCEP:
Para LSP de enrutamiento por segmentos iniciados por PCE:
Habilite la computación de rutas externas para MPLS mediante la inclusión de la
lsp-external-controllerinstrucción en el[edit protocols mpls]nivel de jerarquía.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 rutas externas para SR-TE mediante la inclusión de la
lsp-external-controller pccdinstrucción en el[edit protocols spring-traffic-engineering]nivel de jerarquía.Habilite el enrutamiento de segmentos para el PCE mediante la inclusión de la
spring-capabilityinstrucción en el[edit protocols pcep pce pce-name]nivel de jerarquía.Opcionalmente, configure la profundidad de SID máxima para el PCE mediante la inclusión de la
max-sid-depth numberinstrucción en el[edit protocols pcep pce pce-name]nivel de jerarquía.La profundidad máxima de SID es la cantidad de SID compatibles con 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-value[edit protocol spring-te]nivel de jerarquía.El valor de preferencia indica el orden en el que se selecciona una ruta como 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 por segmentos para la resolución de problemas mediante la inclusión de la
traceoptionsinstrucción en el[edit protocols spring-te]nivel de jerarquía.
Para la delegación PCE de LSP de enrutamiento por segmentos, además de los pasos mencionados, haga lo siguiente:
Defina una lista de segmentos con parámetros de etiqueta. Esto crea un LSP de enrutamiento por segmentos localmente en el PCC.
Habilite la capacidad de delegación del LSP configurado localmente en el PCC mediante la inclusión de la
lsp-external-controller pccdinstrucción en cualquiera de las jerarquías siguientes, según el origen del LSP de enrutamiento por segmentos:Para rutas de enrutamiento de origen configuradas estáticamente que se calculan con CSPF distribuido y
[edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name][edit protocols source-packet-routing source-routing-path lsp-name primary path-name]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 a
[edit protocols source-packet-routing source-routing-path lsp-name primary path-name]nivel de jerarquía.Para túneles creados dinámicamente que se activan a través del módulo de túnel dinámico que tienen resolución ERO de
[edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]último salto y[edit protocols source-packet-routing source-routing-path-template template-name]niveles de jerarquía.
Topología
Figura 8 muestra una topología de red de ejemplo que tiene una sesión PCEP que se ejecuta entre el PCE y el PCC (el enrutador de entrada de la serie MX). Los enrutadores R1, R2 y R3 son los otros enrutadores serie MX de la red. En este ejemplo, configuramos el enrutamiento por segmentos para PCEP en el PCC. También configuramos una ruta estática en el PCC al enrutador R3 para comprobar el uso de rutas de túnel SR-TE al enrutar 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 y, luego, ingrese commit desde el [edit] 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 solo documenta 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 más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el 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 al enrutador R3.
La ruta estática se crea solo con fines de verificación y no afecta a la funcionalidad de la función.
[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 rutas externas 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 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 de enrutamiento global (SRGB) para el enrutamiento por 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 rutas externas 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 mediante la PCE y la capacidad de enrutamiento por 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 de segmentos mediante el PCE.
[edit protocols] user@PCC# set pcep pce pce1 lsp-provisioning
Habilite la capacidad de enrutamiento por segmentos para el PCE.
[edit protocols] user@PCC# set pcep pce pce1 spring-capability
Defina los parámetros de la lista de
static_seg_list_1segmentos 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 por segmentos estático desde el PCC hasta el enrutador R3 para la delegación de 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 ruta de
static_srte_lsp_1enrutamiento 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 delega los LSP de enrutamiento de segmentos a la PCE.
Confirme la configuración.
Resultados
Desde el modo de configuración, ingrese los comandos , show routing-optionsy show protocols 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.
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 funciona correctamente.
- Verificar la adyacencia IS-IS y las etiquetas
- Verificar la base de datos de ingeniería de tráfico
- Verificar LSP de SR-TE
- Verificar la creación de ruta de túnel
- Verificar entradas de tabla de reenvío
- Verificar el uso de rutas de túnel para el reenvío de rutas estáticas
Verificar la adyacencia IS-IS y las etiquetas
Propósito
Compruebe la adyacencia IS-IS en el PCC. Tome nota del rango de etiquetas SRGB, los valores de segmentos de nodo y de adyacencia, 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 PCE y la entre el PCC y el enrutador R1 están funcionando. El resultado también muestra las asignaciones de etiquetas para los segmentos adyacentes y de nodo.
Verificar la base de datos de ingeniería de tráfico
Propósito
Verifique 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 de los enrutadores R1, R2 y R3, que la PCE utiliza para la computación de rutas externas para el PCC.
Verificar LSP de SR-TE
Propósito
Compruebe 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 dos LSP de SR-TE (adj_sid_lsp y node_sid_lsp) han sido creados por el PCE para los segmentos de adyacencia y nodo, respectivamente.
El LSP de enrutamiento por segmentos, static_srte_lsp_1, está habilitado con la capacidad de delegación. El Delegation info campo muestra el control y el estado de enrutamiento de los LSP delegados por PCE. Externally controlled significa que el PCE tiene control sobre los LSP. Externally routed significa que el PCE proporcionó la ERO para la ruta de enrutamiento de origen.
Verificar la creación de ruta 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 en el 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 crearon rutas de túnel para el destino LSP controlado por PCE con SR-TE como etiqueta de protocolo.
Verificar entradas de tabla de reenvío
Propósito
Compruebe que el destino LSP de 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 LSP de SR-TE al enrutador R3 se instala como 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 usa la ruta de túnel creada para el LSP de SR-TE.
Ruta conmutada con etiqueta de enrutamiento por segmento estático
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 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 por segmentos estáticos en las redes MPLS
- Ejemplo: Configuración de ruta conmutada de etiqueta de enrutamiento por segmentos estáticos
Descripción del LSP de enrutamiento por segmentos estáticos en las redes MPLS
El enrutamiento de paquetes de origen o el enrutamiento por 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 debería tomar.
- Introducción a los LSP de enrutamiento por segmentos
- Beneficios de usar LSP de enrutamiento por segmentos
- LSP de enrutamiento por segmentos estáticos de color
- LSP de enrutamiento por segmentos estáticos sin color
- Aprovisionamiento de LSP de enrutamiento por segmentos estáticos
- Limitaciones de LSP de enrutamiento por segmentos estáticos
- Creación dinámica de LSP de enrutamiento por segmentos
- Asignación basada en colores de servicios VPN
- Plantillas de túnel para LSP de enrutamiento por segmentos iniciados 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, llamada 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 por segmentos o a un nodo global dentro de un dominio de enrutamiento por segmentos. 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 de segmentos. El enrutamiento por 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 que se va a procesar está en la parte superior de la pila. Al completar un segmento, la etiqueta relacionada se extraerá de la pila.
Los LSP de enrutamiento por segmentos pueden ser de naturaleza dinámica o estática.
|
Dynamic segment routing LSPs— Cuando un controlador externo crea un LSP de enrutamiento de segmentos y se descarga en un dispositivo de entrada mediante extensiones del protocolo de elemento de computación de ruta (PCEP) o desde una política de enrutamiento de segmentos BGP mediante extensiones de enrutamiento de segmentos del BGP, el LSP se aprovisiona dinámicamente. La lista de segmentos del LSP de enrutamiento de segmentos dinámicos está contenida en el objeto de ruta explícita PCEP (ERO) o en la política de enrutamiento de segmentos del BGP del LSP. |
|
Static segment routing LSPs— Cuando se crea un LSP de enrutamiento de segmentos en el dispositivo de entrada mediante configuración local, el LSP se aprovisiona estáticamente. Un LSP de enrutamiento por segmentos estático se puede clasificar como LSP de color y no color según 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 principal y secundaria hace referencia 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;
}
}
|
Beneficios de usar LSP de enrutamiento por segmentos
-
El enrutamiento por segmentos estáticos no depende del estado de reenvío de LSP en enrutadores de tránsito. Por lo tanto, elimina la necesidad de aprovisionamiento y mantenimiento por estado de reenvío de LSP en el núcleo.
-
Proporcione una mayor escalabilidad a las redes MPLS.
LSP de enrutamiento por segmentos estáticos de color
Un LSP de enrutamiento de segmentos estático configurado con la color instrucción se denomina LSP de color.
- Descripción de LSP de enrutamiento por segmentos estáticos de color
- Lista de segmentos de LSP de enrutamiento por segmentos de color
Descripción de LSP de enrutamiento por segmentos estáticos de color
De manera similar a una política de enrutamiento de segmentos del 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 como clave para asignar tráfico IP.
Un LSP estático de enrutamiento de segmentos de color 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 por segmentos. Las puertas de enlace de la ruta se derivan de las configuraciones de la lista de segmentos en las rutas principal y secundarias.
Lista de segmentos de LSP de enrutamiento por segmentos de color
Los LSP de enrutamiento de segmentos estáticos de color ya soncompatibles con el modo de etiqueta de primer salto de resolver un LSP. Sin embargo, el modo de IP de primer salto no es compatible con los LSP de enrutamiento de segmentos de color. A partir de Junos OS versión 19.1R1, se introduce una función de verificación de confirmación para garantizar que todas las listas de segmentos que contribuyen a las rutas de color tengan la etiqueta mínima presente para todos los saltos. Si no se cumple este requisito, se bloqueará la confirmación.
LSP de enrutamiento por segmentos estáticos sin color
Un LSP de enrutamiento de segmentos estático que se configura sin la color instrucción es un LSP sin color. De manera similar a los túneles de enrutamiento por 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 sin color en enrutadores de entrada. Puede aprovisionar LSP de enrutamiento de segmentos estáticos sin color mediante la configuración de una ruta de origen enrutada y una o más listas de segmentos. Estas listas de segmentos pueden ser utilizadas por varios LSP de enrutamiento de segmentos sin color.
- Descripción de los LSP de enrutamiento por segmentos sin color
- Lista de segmentos de LSP de enrutamiento por segmentos sin color
Descripción de los LSP de enrutamiento por segmentos sin color
El LSP de enrutamiento de segmentos sin color tiene un nombre único y una dirección IP de destino. Una ruta de entrada al destino se instala 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 sin color se asignen al LSP de enrutamiento de segmentos correspondiente al destino. En caso de que el LSP de enrutamiento de segmentos sin color no requiera una ruta de entrada, la ruta de entrada se puede deshabilitar. Un LSP de enrutamiento por segmentos sin color usa una etiqueta SID de unión para lograr la unión de LSP de enrutamiento por segmentos. Esta etiqueta se puede utilizar para modelar el LSP de enrutamiento por segmentos como un segmento que se puede utilizar aún más para construir otros LSP de enrutamiento de segmentos 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 sin color configurados estáticamente en el dispositivo de entrada se informan al elemento de computación de ruta (PCE) a través de una sesión de protocolo de elemento de computación de ruta (PCEP). Estos LSP de enrutamiento de segmentos sin color pueden tener etiquetas asociadas con el identificador de servicio de enlace (SID). Con esta función, el PCE puede usar esta etiqueta SID de enlace en la pila de etiquetas para aprovisionar rutas LSP de enrutamiento por segmentos iniciados por PCE.
Un LSP de enrutamiento de segmentos sin color 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 a través de las rutas en función de los factores de equilibrio de carga, como el peso configurado en la ruta. Se trata de varias rutas de costo igual (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 no 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 la protección de rutas. Un LSP de enrutamiento de segmentos sin color puede tener una ruta secundaria para la protección de ruta dedicada. Cuando se falla una ruta principal, el PFE vuelve a equilibrar el tráfico a las rutas principales funcionales restantes. De lo contrario, el PFE cambia el tráfico a la ruta de copia de seguridad, logrando así la protección de ruta. Un LSP de enrutamiento de segmentos sin color puede especificar una métrica para [edit protocols source-packet-routing source-routing-path lsp-name] sus rutas SID de entrada y enlace. Varios LSP de enrutamiento de segmentos sin color tienen la misma dirección de destino que contribuyen al siguiente salto de la ruta de entrada.
Varios LSP de enrutamiento de segmentos sin color tienen la misma dirección de destino que contribuyen al siguiente salto de la ruta de entrada. Cada ruta, ya sea principal o secundaria, de cada LSP de enrutamiento de segmentos se considera como una candidata de puerta de enlace, si la ruta es funcional y el LSP de enrutamiento por segmentos tiene la mejor preferencia de todos estos LSP de enrutamiento de segmentos. Sin embargo, la cantidad máxima de puertas de enlace que puede contener el siguiente salto no puede superar el límite de varias rutas RPD, que es 128 de forma predeterminada. Las rutas adicionales se podan, primero las rutas secundarias y, luego, las rutas principales. Estos LSP de enrutamiento de segmentos pueden denominarse varias veces como rutas principales o secundarias. En este caso, hay varias puertas de enlace, cada una con un ID de túnel LSP de enrutamiento de segmentos único. Estas puertas de enlace son distintas, aunque tienen una pila e interfaz de etiquetas de salida idénticas. Un LSP de enrutamiento de segmentos sin color y un LSP de enrutamiento de segmentos 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 de enrutamiento de segmentos de color se construye con su dirección de destino y color.
En el caso de que coexistan un LSP de enrutamiento de segmentos estático sin color y un LSP de enrutamiento de segmentos creado por PCEP y tengan el mismo direccionamiento que contribuye a la misma ruta de entrada, si también tienen la misma preferencia. De lo contrario, el LSP de enrutamiento por segmentos con la mejor preferencia está instalado para la ruta.
Lista de segmentos de LSP de enrutamiento por segmentos sin color
Una lista de segmentos consta de una lista de saltos. 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 la lista de segmentos. La cantidad máxima de enlaces de lista de segmentos a un túnel LSP aumenta de 8 a 128, con un máximo de 1000 túneles por sistema. Se admiten un máximo de 128 rutas principales por LSP de enrutamiento de segmentos estáticos. Puede configurar el límite máximo de lista de segmentos en el [edit protocols source-packet-routing] nivel jerárquico.
Antes de la versión 19.1R1 de Junos OS, para que se pudiera usar un LSP de enrutamiento de segmentos estático sin color, el primer salto de la lista de segmentos tenía que ser una dirección IP de una interfaz de salida y el segundo a nlos saltos 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 sin color ahora admite etiquetas SID, además de direcciones IP. Con la compatibilidad con la primera etiqueta de salto, el reenrutamiento rápido (FRR) de MPLS y la multiruta ponderada de igual costo se habilitan para resolver los LSP estáticos de enrutamiento de segmentos sin color, similares a los LSP estáticos de color.
Para que el modo de etiqueta del primer salto entre en vigor, debe incluir la inherit-label-nexthops instrucción global o individualmente para una lista de segmentos, y el primer salto de la lista de segmentos debe incluir tanto la dirección IP como la etiqueta. Si el primer salto solo incluye dirección IP, la inherit-label-nexthops instrucción no tendrá ningún efecto.
Puede configurar inherit-label-nexthops en cualquiera de las jerarquías siguientes. La inherit-label-nexthops instrucción solo tiene 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 de jerarquía. -
Globally— En el
[edit protocols source-packet-routing]nivel de jerarquía.
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 inherit-label-nexthops instrucción no está configurada globalmente, solo las listas de 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 sin color, 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 resolución LSP de enrutamiento de segmentos basada en la especificación del primer salto.
|
Especificación del primer salto |
Modo de resolución de 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 mediante 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 mediante 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 usar el show route ip-address protocol spring-te active-path table inet.3 comando para ver los LSP de enrutamiento de segmentos sin color diseñados por tráfico con 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 primer tipo de salto de listas de segmentos de un LSP de enrutamiento de segmentos estático puede causar 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 se aplica a los LSP de enrutamiento de segmentos estáticos de color y no color. Sin embargo, esto no se aplica a los LSP basados en PCEP; se genera un mensaje de registro del sistema para la discordancia en el tipo de resolución de primer salto en el momento de computar 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; } }La confirmación de túnel lsp1 falla, ya que la ruta 1 es del modo de dirección IP y la ruta 2 es del modo de etiqueta.
-
El SID de enlace está habilitado para el LSP estático sin color cuyo tipo de lista de segmentos es la 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 a través de la lista de segmentos de etiquetas 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) de un conjunto de etiquetas deseado que puede ser del conjunto de etiquetas dinámico para una etiqueta SID de adyacencia o del bloque global de enrutamiento de segmentos (SRGB) para un prefijo SID o nodo SID. La etiqueta SID de adyacencia se puede asignar dinámicamente, que es el comportamiento predeterminado, o se puede asignar desde un conjunto de etiquetas estáticas local (SRLB). A continuación, se instala una ruta para la etiqueta SID en la tabla mpls.0.
Junos OS permite los LSP estáticos de enrutamiento de segmentos mediante la configuración de la segment instrucción en el [edit protocols mpls static-label-switched-path static-label-switched-path] nivel de jerarquía. Un LSP de segmento estático se identifica mediante una etiqueta SID única que cae en el conjunto de etiquetas estáticas de Junos OS. Puede configurar el conjunto de etiquetas estáticas de Junos OS configurando la static-label-range static-label-range instrucción en el [edit protocols mpls label-range] nivel de jerarquía.
Limitaciones de LSP de enrutamiento por segmentos estáticos
-
Actualmente, Junos OS tiene la limitación de que el siguiente salto no se puede crear para insertar más que las etiquetas de profundidad máxima de la lista de segmentos. Por lo tanto, una lista de segmentos con más de las etiquetas SID máximas (excluyendo la etiqueta SID del primer salto que se utiliza para resolver el reenvío del siguiente salto) no es utilizable para LSP de enrutamiento de segmentos de color o sin color. Además, el número real permitido para un LSP de enrutamiento de segmentos determinado puede ser incluso menor que el límite máximo, si un servicio MPLS está en el LSP de enrutamiento por segmentos o si el LSP de enrutamiento de segmentos está en un vínculo o una ruta de protección de nodos. En todos los casos, la cantidad total de etiquetas de servicio, etiquetas SID y etiquetas de protección de vínculo o nodo no debe superar la profundidad máxima de la lista de segmentos. Puede configurar el límite máximo de lista de segmentos en el
[edit protocols source-packet-routing]nivel jerárquico. Se pueden unir varios LSP de enrutamiento de segmentos sin color con etiquetas SID menores o iguales que el máximo para construir un LSP de enrutamiento por segmentos más largo. Esto se denomina unión de LSP de enrutamiento por segmentos. Se puede lograr mediante la etiqueta binding-SID. -
La unión de LSP de enrutamiento por segmentos se realiza a nivel de ruta. Si un LSP de enrutamiento de segmentos sin color tiene varias rutas que son varias listas de segmentos, cada ruta se puede unir de forma independiente a otro LSP de enrutamiento de segmentos sin color en un punto de unión. Un LSP de enrutamiento de segmentos sin color dedicado a la unión puede deshabilitar la instalación de la ruta de entrada configurando
no-ingressla 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 segmentos estáticos sin color. Si hay una infracción en la configuración, se produce un error en la comprobación de confirmación.
-
La cantidad máxima de enlaces de lista de segmentos a un túnel LSP aumenta de 8 a 128, con un máximo de 1000 túneles por sistema. Se admiten un máximo de 128 rutas principales por LSP de enrutamiento de segmentos estáticos. Como limitación, la compatibilidad máxima del sensor para la ruta LSP es solo de 32000.
-
Si alguna lista de segmentos está configurada con más etiquetas que la profundidad máxima de la lista de segmentos, se produce un error en la comprobación de confirmación de configuración.
Creación dinámica de LSP de enrutamiento por segmentos
En las redes de enrutamiento por segmentos que tienen cada dispositivo de borde de proveedor (PE) conectado a todos los demás dispositivos PE, se requiere una gran cantidad de configuración para configurar las rutas conmutadas por etiquetas (LSP) de enrutamiento por segmentos, aunque solo se pueden utilizar unas pocas rutas de tráfico de enrutamiento por segmentos (SR-TE). Puede habilitar la creación dinámica trigerred del BGP de estos LSP para reducir la cantidad de configuración en dichos despliegues.
- Configuración de la plantilla LSP de enrutamiento dinámico de segmentos
- Resolución de LSP de enrutamiento por segmentos dinámicos
- Consideraciones para configurar la creación dinámica de LSP de enrutamiento por segmentos
- Servicios compatibles a través de LSP de enrutamiento por segmentos dinámicos
- Comportamiento con varias fuentes de túnel en el enrutamiento por segmentos
- Limitaciones de LSP de enrutamiento por segmentos dinámicos
Configuración de la plantilla LSP de enrutamiento dinámico de segmentos
Para configurar la plantilla para habilitar 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.
-
La siguiente es una configuración de ejemplo 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>; } } } } -
La siguiente es una configuración de ejemplo 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 por segmentos dinámicos
Resolución de LSP de enrutamiento de segmentos dinámicos de color
Cuando se asignan los prefijos del BGP con comunidad de colores, inicialmente se resuelven mediante la política catch-all-route-for-that-particular-color y, a su vez, se identifica la plantilla SR-TE en la que se debe resolver el prefijo del BGP. El SID de destinos se deriva del atributo next-hop del prefijo de carga del BGP. Por ejemplo, si el siguiente salto del prefijo de carga del BGP es una dirección IP que pertenece al dispositivo A, se toma el nodo-SID del dispositivo A y se prepara y se inserta la etiqueta correspondiente en la parte inferior de la pila. El prefijo de carga del BGP se resuelve en un modo de solo color, en el que el nodo-SID del dispositivo A se encuentra en la parte inferior de la pila de etiquetas final y las etiquetas de la 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, no se crea el túnel y la ruta del BGP que solicita la resolución permanece sin resolver.
Resolución de LSP de enrutamiento de segmentos dinámicos sin color
Las rutas de captura general para LSP no color 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 solo un 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 bajo la misma spring-te configuración. Estos túneles son similares a los túneles RSVP en 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 muestra de LSP de enrutamiento por segmentos dinámicos
La plantilla LSP de enrutamiento de segmentos dinámico siempre lleva una ruta parcial. El SID del último salto del nodo se deriva automáticamente en el tiempo de creación del túnel, dependiendo del SID del nodo de dirección del próximo salto del protocolo (PNH). Varios túneles pueden utilizar la misma plantilla a diferentes destinos. En tales casos, la ruta parcial sigue siendo la misma, y solo cambia el último salto según el PNH. Las plantillas LSP de enrutamiento de segmentos dinámico no son comunes a un solo túnel, por lo que no se puede llevar una ruta completa en él. Puede usar una lista de segmentos si va a utilizarse una ruta completa.
LSP de enrutamiento por segmentos dinámicos de color
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 [ 123 124 125 ];
sr_lsp2 color-any
}
destination-networks {
10.22.44.0/24;
}
}
}
Para la configuración de ejemplo mencionada, las entradas de ruta son las siguientes:
-
inetcolor.0 tunnel route: 10. 22.44.0-0/24 --> RT_NH_TUNNEL
-
inetcolor6.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) Nombre del túnel LSP = 10. 22.44.55:7c:dt-srte-tunnel1
-
inetcolor.0 tunnel route:
10. 22.44.55-101/64 --> <next-hop>
10. 22.44.55-124/64 --> <next-hop>
-
inetcolor6.0 tunnel route:
ffff::10. 22.44.55-101/160 --> <next-hop>
ffff::10. 22.44.55-124/160 --> <next-hop>
LSP de enrutamiento por segmentos dinámicos sin color
Configuración de ejemplo para LSP de enrutamiento de segmentos dinámicos sin 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 ];
}
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, las entradas de ruta son las siguientes:
-
inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL
-
inet6.3 tunnel route: ffffff::10.33.44.0/120 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
Nombre de plantilla LSP R1(prefijo) -> 10.33.44.55(PNH) = LSP1 --- 10.33.44.55:dt-srte-tunnel2
R1(prefijo) -> ffff::10.33.44.55(PNH) Nombre de plantilla LSP = LSP1 --- 10.33.44.55:dt-srte-tunnel2
-
inet.3 tunnel route: 10.33.44.55/32 --> <next-hop>
-
inet6.3 tunnel route: ffffff::10.33.44.55/128 --> <next-hop>
LSP de enrutamiento por segmentos dinámicos no resueltos
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, 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
-
inetcolor6.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 creará un túnel. (No se encontró la plantilla para el color).
Consideraciones para configurar la creación dinámica de LSP de enrutamiento por segmentos
Al configurar la creación dinámica de LSP de enrutamiento de segmentos, tome en consideración 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 da por sentado que todos los destinos están color dentro de esa configuración. -
Una plantilla puede tener una lista de colores definida o configurarse 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 preferencia más alta. -
En una
spring-teconfiguración, solo se puede definir una plantilla con lacolor-anyopción. -
La asignación 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 laprimaryopción habilitada. -
Los destinos colorados 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 compatibles a través de LSP de enrutamiento por segmentos dinámicos
Los siguientes servicios se admiten a través de 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 se admiten a través de LSP de enrutamiento de segmentos dinámicos sin color:
-
VPN de capa 3
-
VPN de capa 2
-
Configuraciones de varias rutas
Comportamiento con varias fuentes de túnel en el enrutamiento por segmentos
Cuando dos fuentes descargan rutas al mismo destino desde el enrutamiento de segmentos (por ejemplo, túneles de origen estático y dinámico), se utiliza la preferencia de enrutamiento de segmentos para elegir la entrada de ruta activa. Un valor más alto tiene una mayor preferencia. En caso de que la preferencia siga siendo la misma, se utiliza el origen del túnel para determinar la entrada de ruta.
Limitaciones de LSP de enrutamiento por segmentos dinámicos
Los LSP dinámicos de SR-TE no admiten las siguientes características ni funcionalidades:
-
Túneles de enrutamiento por segmentos IPv6.
-
Túneles estáticos.
-
No se admite 6PE.
-
CSPF distribuida.
-
La tunelización de sBFD y LDP no se admite para LSP dinámicos de SR-TE y en una plantilla.
-
Instalar y rutas B-SID en una plantilla.
Asignación basada en colores de servicios VPN
Puede especificar el color como una restricción de próximo salto de protocolo (además de la dirección IPv4 o IPv6) para resolver los túneles de transporte mediante LSP estáticos de color y BGP diseñados por tráfico de enrutamiento de segmentos (SR-TE). Esto se denomina resolución de próximo salto del protocolo color-IP, en el que se requiere que configure una asignación de resolución y se aplique a los servicios VPN. Con esta función, puede habilitar la dirección de tráfico basada en colores de los servicios VPN de capa 2 y capa 3.
Junos OS admite LSP DE SR-TE de color asociados con un solo color. La función de asignación basada en colores de los servicios VPN se admite en LSP estáticos de color y LSP de SR-TE del BGP.
- Coloración del servicio VPN
- Especificación del modo de asignación de servicio VPN
- Resolución de próximo salto del protocolo COLOR-IP
- Devolución a la resolución del próximo salto del protocolo IP
- BGP etiquetado con asignación unidifusión basada en color sobre SR-TE
- Funciones compatibles y no compatibles para la asignación basada en colores de los servicios VPN
Coloración del servicio VPN
En general, se puede asignar un color a un servicio VPN en el enrutador de salida donde se anuncia el NLRI VPN o en un enrutador de entrada donde se recibe y procesa el NLRI VPN.
Puede asignar un color a los servicios VPN en diferentes niveles:
-
Por instancia de enrutamiento.
-
Por grupo BGP.
-
Por vecino del BGP.
-
Por prefijo.
Una vez que asigne 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 de varios colores. En tales casos, se considera que el último color adjunto es el color del servicio VPN y se omiten todos los demás colores.
Los dispositivos de salida o entrada asignan varios colores mediante varias políticas en el siguiente orden:
-
Política de exportación del BGP en el dispositivo de salida.
-
Política de importación del BGP en el dispositivo de entrada.
-
Política de importación de VRF en el dispositivo de entrada.
Los dos modos de coloración de servicio VPN son:
Asignación de color de salida
En este modo, el dispositivo de salida (es decir, el anunciantes de la VPN NLRI) 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 vecinos de grupo del servicio VPN en el [edit protocols bgp] nivel jerárquico. BGP anuncia la VPN NLRI 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 política de enrutamiento como política de exportación de un grupo BGP o un vecino de BGP, debe incluir la instrucción en el vpn-apply-export nivel de BGP, grupo BGP o vecino de BGP para que la política tenga efecto en el NLRI vpn.
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}
Las políticas de enrutamiento se aplican al prefijo VPN de capa 3 NLRIs, NRLIs VPN de capa 2 y NLRIs de EVPN. La comunidad extendida de color es heredada por todas las rutas VPN, importados e instalados en las 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 VPN NLRI) 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 [edit protocols bgp] nivel jerárquico. 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 servicio VPN
Para especificar modos de asignación de servicio VPN flexibles, debe definir una política mediante la resolution-map instrucción y hacer referencia a la política en la instancia vrf-importde enrutamiento, la importación de grupo o la importación de vecinos de grupo de un servicio VPN en el [edit protocols bgp] nivel jerárquico. 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 política de importación a un grupo BGP o un vecino de BGP.
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}
Cada modo de asignación de servicio VPN debe tener un nombre único definido en el mapa de resolución. Solo se admite una sola entrada de color IP en el mapa de resolución, en el que las rutas de VPN se resuelven mediante un siguiente salto del protocolo IP de color en forma de ip-address:color.
Resolución de próximo salto del protocolo COLOR-IP
El proceso de resolución del siguiente salto del protocolo se mejora para admitir la resolución del próximo salto del protocolo IP de color. Para un servicio VPN de color, el proceso de resolución del siguiente salto del protocolo 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 de protocolo en la tabla de IP-address:colorenrutamiento inet6color.0.
Debe configurar una política para admitir la resolución de varias rutas de vpn de capa 2, VPN de capa 3 o servicios EVPN de color mediante LSP de color. A continuación, la política se debe aplicar con la tabla RIB correspondiente como política de importación de resolver.
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;
}
}
Devolución a la resolución del próximo salto del protocolo IP
Si un servicio VPN de color no tiene un mapa de resolución aplicado a él, el servicio VPN ignora su color y vuelve a pasar a la resolución del siguiente salto del protocolo IP. Por el contrario, si un servicio VPN sin color tiene un mapa de resolución aplicado a él, el mapa de resolución se omite y el servicio VPN usa la resolución del siguiente salto del protocolo IP.
La reserva es un proceso simple desde LSP de SR-TE de color hasta LSP LDP, mediante el uso de un grupo RIB para LDP para instalar rutas en tablas de enrutamiento inet{6}color.0. Una coincidencia de prefijo más larga para un próximo salto del protocolo IP de color garantiza que si no existe una ruta LSP SR-TE colorada, se debe devolver una ruta LDP con una dirección IP correspondiente.
BGP etiquetado con asignación unidifusión basada en color sobre SR-TE
A partir de Junos OS versión 20.2R1, la unidifusión etiquetada BGP (BGP-LU) puede resolver rutas IPv4 o IPv6 mediante ingeniería de tráfico de enrutamiento por segmentos (SR-TE) para familias de direcciones IPv4 e IPv6. BGP-LU admite la asignación de un color de comunidad de BGP y la definición de un resolution map PARA SR-TE. Se construye un siguiente salto de protocolo de color y se resuelve en un túnel SR-TE colorado en la inetcolor.0 tabla o inet6color.0 . Usos inet.3 y inet6.3 tablas del BGP para la asignación no basada en colores. Esto le permite anunciar prefijos BGP-LU IPv6 e IPv4 con una dirección de salto siguiente IPv6 en redes solo IPv6 en las que los enrutadores no tienen configurada ninguna dirección IPv4. Con esta función, actualmente somos compatibles con LU IPv6 de BGP sobre SR-TE con base IS-IS.
En Figura 9, el controlador configura 4 túneles de color en una red de núcleo IPv6 configurada con SR-TE. Cada túnel de color toma una ruta diferente al enrutador de destino D según la asignación de resolución definida. El controlador configura un túnel SR-TE colorado a la interfaz 2001:db8::3701:2d05 en el enrutador D. El 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 la comunidad asignado, el BGP-LU resuelve el siguiente salto de color para el prefijo LU BGP IPv6 de acuerdo con la política de mapa de resolución asignada.
BGP-LU admite las siguientes situaciones:
-
LU BGP IPv4 sobre BGP IPv4 SR-TE de color, con extensiones ISIS/OSPF IPv4 SR.
-
LU BGP IPv4 sobre IPv4 SR-TE estático de color y sin color, con extensiones ISIS/OSPF IPv4 SR.
-
LU BGP IPv6 sobre BGP IPv6 SR-TE de color, con extensiones ISIS IPv6 SR.
-
LU BGP IPv6 sobre SR-TE IPv6 estático de color y sin color, con extensiones ISIS IPv6 SR.
-
Servicios VPN de capa 3 IPv6 con dirección local IPv6 y dirección de vecino IPv6.
-
Servicios VPN de capa 3 IPv6 sobre BGP IPv6 SR-TE, con extensiones ISIS IPv6 SR.
-
Servicios VPN de capa 3 IPv6 sobre IPv6 SR-TE estático y sin color, con extensiones ISIS IPv6 SR.
Funciones compatibles y no compatibles para la asignación basada en colores de los servicios VPN
Se admiten las siguientes características y funcionalidades con la asignación basada en colores de los servicios VPN:
-
VPN de capa 2 BGP (VPN de kompella de capa 2)
-
BGP EVPN
-
Mapa de resolución con una sola opción de color IP.
-
Resolución de próximo salto del protocolo IPv4 e IPv6 de color.
-
Grupo de base de información de enrutamiento (también conocido como tabla de enrutamiento) basado en reserva a LSP LDP en la tabla de enrutamiento inetcolor.0.
-
LSP DE SR-TE color.
-
Plataformas virtuales.
-
Junos OS de 64 bits.
-
Sistemas lógicos.
-
BGP etiquetado como unidifusión.
No se admiten las siguientes funciones y funcionalidades 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 de BGP descubierta automáticamente y señal de LDP.
-
VPLS
-
MVPN
-
IPv4 e IPv6 mediante el mapa de resolución.
Plantillas de túnel para LSP de enrutamiento por segmentos iniciados por PCE
Puede configurar una plantilla de túnel para los LSP de enrutamiento por segmentos iniciados por PCE para pasar 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 por segmentos iniciado por PCE, el LSP se comprueba con instrucciones de política (si las hubiera) 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
[edit protocols source-packet-routing]nivel jerárquico. Puede configurar los parámetros de tunelización BFD y LDP adicionales aquí. -
Incluya la instrucción source-routing-path-template-map en el
[edit protocols source-packet-routing]nivel jerárquico 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 ylsp-regexcoincidente. Estas opciones son excluyentes entre sí, por lo que puede especificar solo una opción en un momento determinado.La
theninstrucción debe incluir lasr-te-templateopción con una acción aceptar. Esto aplica la plantilla al LSP iniciado por PCE.
Tome en consideración 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 estáticos configurados, ni a los LSP de enrutamiento por segmentos de cualquier otro cliente.
-
La configuración proporcionada por PCEP tiene prioridad sobre la configuración de plantilla.
-
LSP PCEP no hereda la configuración de lista de segmentos de plantilla.
Ejemplo: Configuración de ruta conmutada de etiqueta de enrutamiento por segmentos estáticos
En este ejemplo, se muestra cómo configurar rutas conmutadas (LSP) de enrutamiento por segmentos estáticos en redes MPLS. Esta configuración ayuda a ofrecer 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 de 5G serie MX
-
Junos OS versión 18.1 o posterior se ejecuta en todos los enrutadores
Antes de comenzar, asegúrese de configurar las interfaces del dispositivo.
Descripción general
Junos OS, un conjunto de rutas de enrutamiento de segmentos explícitas se configuran en el enrutador de entrada de un túnel de enrutamiento de segmentos estáticos sin color mediante la configuración de la segment-list instrucción en el [edit protocols source-packet-routing] nivel de jerarquía. Puede configurar el túnel de enrutamiento por segmentos mediante la configuración de la source-routing-path instrucción en el [edit protocols source-packet-routing] nivel de 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 consta de una secuencia de saltos. En el caso del túnel de enrutamiento de segmentos estáticos sin color, el primer salto de la lista de segmentos especifica una dirección IP inmediata del siguiente salto y el segundo al Nth hop especifica las etiquetas de identificación de segmentos (SID) correspondientes al vínculo o nodo por el que atraviesa la ruta. La ruta al 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 de borde del proveedor PE1 y PE5. Configure el protocolo MPLS en todos los enrutadores. El túnel de enrutamiento por segmentos está configurado desde el enrutador PE1 hasta el enrutador PE5 con una ruta principal configurada en el enrutador PE1 y el enrutador PE5. El enrutador PE1 también está configurado con una ruta secundaria para la protección de rutas. Los enrutadores de tránsito PE2 a PE4 están configurados con etiquetas SID de adyacencia con pop de etiquetas 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 y, luego, ingrese commit desde el [edit] 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 siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el 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 rango 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 de pares, dirección local, familia de protocolo para NLRIs en actualizaciones y dirección IP de un vecino para el grupo par.
[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 primarias y secundarias para las políticas de ingeniería de enrutamiento y tráfico de origen (TE) del enrutamiento de paquetes de origen de protocolo (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, el enlace de la etiqueta SID, 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 política.
[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 de BGP.
[edit policy-options] set community VPN-A members target:65000:1
-
Configure la instancia de enrutamiento VRF1 con tipo de instancia, interfaz, distinguidor de enrutador, importación VRF, exportación y etiqueta de tabla. 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, ingrese los comandos , show policy-options, show protocols, show routing-optionsy 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 siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el 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 interfaces y 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 ingresando 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 funciona correctamente.
- Verificación de entrada de ruta de la tabla de enrutamiento inet.3 del enrutador PE1
- Verificar entradas de la tabla de rutas de la tabla de enrutamiento mpls.0 del enrutador PE1
- Verificar el LSP diseñado por el tráfico spring del enrutador PE1
- Verificar LSP diseñados por tráfico SPRING en el enrutador de entrada del enrutador PE1
- Verificar las entradas de la tabla de enrutamiento de la tabla de enrutamiento mpls.0 del enrutador PE2
- Verificar el estado de los segmentos LSP MPLS estáticos del enrutador PE2
Verificación de entrada de ruta de la tabla de enrutamiento inet.3 del enrutador PE1
Propósito
Compruebe la entrada de ruta de la tabla de enrutamiento inet.3 del enrutador PE1.
Acción
Desde el modo operativo, ingrese el show route table inet.3 comando.
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.
Verificar entradas de la tabla de rutas de la tabla de enrutamiento mpls.0 del enrutador PE1
Propósito
Verificar las entradas de ruta de la tabla de enrutamiento mpls.0
Acción
Desde el modo operativo, ingrese el show route table mpls.0 comando.
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 por segmentos.
Verificar el LSP diseñado por el tráfico spring del enrutador PE1
Propósito
Verifique los LSP diseñados por el tráfico spring en los enrutadores de entrada.
Acción
Desde el modo operativo, ingrese el show spring-traffic-engineering overview comando.
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 la descripción general de los LSP diseñados con tráfico SPRING en el enrutador de entrada.
Verificar LSP diseñados por tráfico SPRING en el enrutador de entrada del enrutador PE1
Propósito
Verifique los LSP diseñados por el tráfico spring en el enrutador de entrada.
Acción
Desde el modo operativo, ingrese el show spring-traffic-engineering lsp detail comando.
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 los detalles de los LSP diseñados con tráfico SPRING en el enrutador de entrada
Verificar las entradas de la tabla de enrutamiento de la tabla de enrutamiento mpls.0 del enrutador PE2
Propósito
Verifique las entradas de la tabla de enrutamiento de la tabla de enrutamiento mpls.0 del enrutador PE2.
Acción
Desde el modo operativo, ingrese el show route table mpls.0 comando.
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, PopVerificar el estado de los segmentos LSP MPLS estáticos del enrutador PE2
Propósito
Verifique el estado de los segmentos LSP de MPLS del enrutador PE2.
Acción
Desde el modo operativo, ingrese el show mpls static-lsp comando.
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 distribuida para LSP de enrutamiento por segmentos
Antes de la versión 19.2R1S1 de Junos OS, para la ingeniería de tráfico de rutas de enrutamiento de segmentos, podía configurar explícitamente rutas estáticas o usar rutas calculadas desde un controlador externo. Con la función LSP de ruta más corta restringida distribuida (CSPF) para el LSP de enrutamiento de segmentos, puede calcular un LSP de enrutamiento por segmentos localmente en el dispositivo de entrada de acuerdo con las restricciones que haya configurado. Con esta función, los LSP se optimizan según 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 la pila de etiquetas de enrutamiento por segmentos habilitada o deshabilitada.
- Limitaciones de computación distribuidas de CSPF
- Algoritmo de computación distribuido de CSPF
- Base de datos de computación distribuida de CSPF
- Configurar restricciones de computación distribuidas de CSPF
- Computación distribuida de CSPF
- Interacción entre la computación distribuida de CSPF y las funciones de SR-TE
- Configuraciones de muestra de computación distribuida de CSPF
Limitaciones de computación distribuidas de CSPF
Las rutas LSP de enrutamiento por segmentos se calculan cuando se cumplen todas las restricciones configuradas.
La función de computación distribuida de CSPF admite el siguiente subconjunto de restricciones especificados en el borrador de Internet, draft-ietf-spring-segment-routing-policy-03.txt, política de enrutamiento de segmentos para la ingeniería de tráfico:
-
Inclusión y exclusión de grupos administrativos.
-
Inclusión de direcciones IP de saltos sueltos o estrictos.
Nota:Solo puede especificar los identificaciones de enrutador en las restricciones de salto flexibles o estrictas. Las etiquetas y otras direcciones IP no se pueden especificar como restricciones de salto sueltas o estrictas en la versión 19.2R1-S1 de Junos OS.
-
Número máximo de IDENTIFICACIÓN de segmentos (SID) en la lista de segmentos.
-
Número máximo de listas de segmentos por ruta de enrutamiento de segmentos candidata.
La función de computación distribuida de CSPF para LSP de enrutamiento por segmentos no admite los siguientes tipos de restricciones ni escenarios de implementación:
-
Direcciones IPV6.
-
LSP de ingeniería de tráfico de enrutamiento por segmentos (SR-TE) entre dominios.
-
Interfaces sin numerar.
-
Varios protocolos de enrutamiento, como OSPF, ISIS y BGP-LS, habilitados al mismo tiempo.
-
Computación con prefijos o direcciones de cualquier transmisión como destinos.
-
Incluir y excluir direcciones IP de interfaz como restricciones.
Algoritmo de computación distribuido de CSPF
La función de computación distribuida de CSPF para los LSP de enrutamiento por segmentos utiliza el algoritmo de compresión de pila de etiquetas con CSPF.
Habilitada la compresión de la pila de etiquetas
Una pila de etiquetas comprimida representa un conjunto de rutas desde un origen hasta un destino. Generalmente se compone de SID de nodos y SID de adyacencia. Cuando se habilita la compresión de pila de etiquetas, 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, a la vez que se ajustan a las restricciones.
Compresión de pila de etiquetas deshabilitada
El cálculo de CSPF de varias rutas con compresión de pila de etiquetas deshabilitada encuentra listas de segmentos N hasta el destino, donde:
-
El costo de todas las listas de segmentos es igual y el mismo que la métrica de ingeniería de tráfico más corta para llegar al destino.
-
Cada lista de segmentos está compuesta por SID de adyacencia.
-
El valor de N es la cantidad máxima de listas de segmentos permitidas para la ruta de candidato por configuración.
-
Ninguna lista de dos segmentos es idéntica.
-
Cada lista de segmentos satisface todas las restricciones configuradas.
Base de datos de computación distribuida de CSPF
La base de datos utilizada para la computación 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 vínculo IGP de todos los dominios de los que el nodo informático ha aprendido. Como resultado, para que CSPF funcione, debe incluir la igp-topology instrucción en el [edit protocols isis traffic-engineering] nivel de jerarquía.
Configurar restricciones de computación distribuidas de CSPF
Puede usar un perfil de computación para agrupar lógicamente las restricciones de computación. Estos perfiles de computación son referenciados por las rutas de enrutamiento de segmentos para computar los LSP de enrutamiento de segmentos primarios y secundarios.
Para configurar un perfil de computación, incluya la instrucción compute-profile en el [edit protocols source-packet-routing] nivel jerárquico.
La configuración de las restricciones de computación compatibles incluye:
-
Administrative groups
Puede configurar grupos de administración en el
[edit protocols mpls]nivel de jerarquía. 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 computación puede ser común a todas las rutas de enrutamiento de segmentos candidatos, o puede estar en rutas de candidatos 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 va a atravesar. -
include-all— Especifica que cualquier vínculo con todos los grupos administrativos configurados de la lista es aceptable para la ruta de acceso a recorrer. -
exclude— Especifica que cualquier vínculo que no tenga ninguno de los grupos administrativos configurados de la lista es aceptable para la ruta de acceso que se va a recorrer.
-
-
Explicit path
Puede especificar una serie de identificaciones de enrutador en el perfil de computación como una restricción para computar 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 estricto. Debe incluir la opción debajo de
computela instrucción de lista de segmentos al especificar la restricción de ruta explícita. -
Maximum number of segment lists (ECMP paths)
Puede asociar una ruta de candidato con una serie de listas de segmentos dinámicas. Las rutas son rutas ECMP, en las que cada lista de segmentos se traduce en una puerta de enlace de salto siguiente con peso activo. Estas rutas son el resultado de la computación de rutas con o sin compresión.
Puede configurar este atributo mediante la
maximum-computed-segment-lists maximum-computed-segment-listsopción de la instrucción de configuración de perfil de procesamiento . Esta configuración determina la cantidad máxima de estas listas de segmentos calculadas para un LSP principal y secundario determinado. -
Maximum segment list depth
El parámetro de cálculo de la profundidad máxima de la lista de segmentos garantiza que entre las rutas ECMP que cumplen todas las demás restricciones, como el grupo administrativo, solo se utilizan las rutas que tienen listas de segmentos menores o iguales a la profundidad máxima de la lista de segmentos. Cuando configure este parámetro como una restricción en el perfil de computación, reemplaza la
maximum-segment-list-depthconfiguración en el[edit protocols source-packet-routing]nivel de jerarquía, si está presente.Puede configurar este atributo mediante la
maximum-segment-list-depth maximum-segment-list-depthopción de la instrucción de configuración de perfil de procesamiento . -
Protected or unprotected adjacency SIDs
Puede configurar SID de adyacencia protegido o desprotegido como una restricción bajo el perfil de computación 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 enlaces se anuncia mediante extensiones de ingeniería de tráfico de 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 computación.
Puede configurar este atributo mediante la
metric-type (igp | te)opción de la instrucción de configuración de perfil de procesamiento .
Computación distribuida de CSPF
Las rutas candidatas de SR-TE se calculan localmente para que cumplan con las restricciones configuradas. Cuando se deshabilita la compresión de la pila de etiquetas, el resultado de la computación de CSPF de varias rutas es un conjunto de pilas de SID de adyacencia. Cuando se habilita la compresión de pila de etiquetas, el resultado es un conjunto de pilas de etiquetas comprimidas (compuestas por SIDs y SID de nodo adyacentes).
Cuando se calculan rutas secundarias, los vínculos, los nodos y las S SRLG tomadas por las rutas principales 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 un resultado de computación no exitoso, 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 distribuida de CSPF y las funciones de SR-TE
- Ponderaciones asociadas con las rutas de una política de SR-TE
- Detección de liveliness de BFD
- heredar-label-nexthops
- Función de traducción automática
Ponderaciones asociadas con las rutas de una política de SR-TE
Puede configurar ponderaciones en rutas SR-TE calculadas y estáticas, que contribuyen a los próximos saltos de la ruta. Sin embargo, una sola ruta que tenga la computación habilitada puede dar lugar a varias listas de segmentos. Estas listas de segmentos computadas se tratan como ECMP entre sí. Puede asignar pesos ecmp jerárquicos a estos segmentos, teniendo en cuenta los pesos asignados a cada uno de los principales configurados.
Detección de liveliness de BFD
Puede configurar la detección de liveliness de BFD para las rutas primarias o secundarias calculadas. Cada ruta de acceso computada principal o secundaria 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 calculados. Si todas las rutas principales activas fallan, la ruta secundaria preprogramada (si se proporciona) se activa.
heredar-label-nexthops
No es necesario habilitar explícitamente la inherit-label-nexthops configuración bajo la [edit protocols source-packet-routing segment-list segment-list-name] jerarquía para las rutas primarias 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 principal o secundaria con la función de traducción automática hacen referencia a estas listas de segmentos. Por otro lado, la principal o secundaria en la que está habilitada la función de computación no puede hacer referencia a ninguna lista de segmentos. Como resultado, no puede habilitar tanto la función de computación 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 computación y otra con tipo de traducción automática.
Configuraciones de muestra de computación distribuida de CSPF
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 configurada y también sirve como nombre para esta ruta principal.
-
Un principal 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 de proceso 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 next-hops de ruta computada y los próximos saltos estáticos son 2 y 3, respectivamente. Suponiendo que los próximos saltos para las rutas calculadas son comp_nh1, comp_nh2y comp_nh3, y el siguiente salto para la 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 las rutas principal como la secundaria pueden ser de tipo de computación y pueden tener sus propios perfiles de computación.
[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 se menciona la computación en una ruta principal o secundaria, se obtiene el cálculo local de una ruta al destino sin restricciones u 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
SUMMARY El reenvío basado en CoS (CBF) y el enrutamiento basado en políticas (PBR, también conocido como reenvío basado en filtros) se pueden habilitar para los LSP de enrutamiento por segmentos sin color (SR-TE) con el fin de dirigir el tráfico selectivo a través de una ruta de SR-TE explícita, lo que le proporciona la ventaja de prestar servicio al tráfico según 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 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 el enrutamiento basado en políticas (PBR) para los LSP de SR-TE
- Fuentes de ruta de enrutamiento por segmentos que admiten CBF y PBR
- Consideraciones para configurar CBF y PBR para LSP SR-TE
Beneficios del reenvío basado en CoS (CBF) y el enrutamiento basado en políticas (PBR) para los LSP de SR-TE
Con CBF y PBR puede:
Utilice combinaciones de rutas de ingeniería de enrutamiento y tráfico de segmentos (SR-TE) para dirigir el tráfico de servicio en el núcleo.
Elija los servicios de soporte que se resolverán mediante las rutas de SR-TE seleccionadas.
Fuentes de ruta de enrutamiento por segmentos que admiten CBF y PBR
Las siguientes fuentes de ruta de enrutamiento por 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 estáticamente configurada.
PCEP—Aprovisionar dinámicamente rutas de enrutamiento de origen creadas en un controlador y descargadas en un enrutador de entrada en una ERO, ya sea a través de extensiones de enrutamiento por segmentos PCEP o en una política de enrutamiento de segmentos BGP mediante extensiones de enrutamiento por segmentos del BGP.
Dynamic LSPs— Los túneles creados dinámicamente se activan 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 SR-TE
Recordar:
CbF y PBR solo se habilitan en los LSP DE SR-TE sin color que están configurados estática o dinámicamente.
Las configuraciones de CBF y PBR para LSP de SR-TE pueden coexistir en un dispositivo; el orden de configuración decide el tipo en el que se reenvían las rutas.
En el caso de PBR, si el primer salto del SR-TE LSP es una etiqueta, debe incluir la
resolution preserve-nexthop-hiearchyinstrucción en el[edit routing-options]nivel de jerarquía.El reenvío basado en clases de rutas para CBF solo es visible en la tabla de reenvío y no en las rutas.
El reenvío de rutas basado en políticas para PBR se realiza en las rutas y se ve en la salida de
show routecomando.
Configurar el reenvío basado en CoS y el enrutamiento basado en políticas para LSP de SR-TE
SUMMARY El reenvío basado en CoS (CBF) y el enrutamiento basado en políticas (PBR, también conocido como FBF basado en filtros) se pueden utilizar para dirigir el tráfico selectivo mediante una ruta de enrutamiento por segmento explícito diseñada (SR-TE) por etiqueta (LSP). Solo los LSP de enrutamiento por segmentos sin color que tengan configurado el siguiente salto 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 de SR-TE sin color.
Configure las interfaces de los dispositivos y asegúrese de que estén conectados a la red.
Defina listas de segmentos y configure los 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 puntos de código de servicios diferenciados (DSCP) para manejar 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 (FCs) para agrupar paquetes para la 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 basada en CoS con el salto siguiente de LSP como 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 de siguiente salto de CoS especificada por nombre de mapa.
[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 permite la CBF para 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 cbf
Confirme la configuración.
user@host# commit
Verify CBF Configuration
Puede comprobar la configuración cbf con 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 de rutas basado en clases solo es visible en la tabla de reenvío, a diferencia del PBR, donde las rutas filtradas son visibles en la salida del show route comando.
Para configurar el 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 siguiente salto de LSP o que la carga se equilibra como multiruta 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 que realice una resolución de rutas personalizada en los próximos saltos del protocolo de rutas.
Nota:La
resolution preserve-nexthop-hierarchyinstrucció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 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 próximos saltos para el prefijo de destino 4.0.0.1. Las expanded-nh extensive opciones muestran los próximos saltos filtrados en el campo de Krt_inh 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)
En el caso del PBR, la show route salida del comando hace el filtrado de rutas basado en políticas.
Habilitación de varias rutas para LSP de SR-TE en PCEP
Puede configurar varias rutas (principales o secundarias) para LSP SR-TE PCEP (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 LSP DE SR-TE configurados estáticamente. Las extensiones de PCEP definidas en draft-ietf-pce-multipath-06 permiten que el PCEP propague varias rutas (multiruta) para los LSP entre puntos de conexión PCEP.
Beneficios de varias rutas para LSP SR-TE PCEP
-
Los LSP pueden tener varios conjuntos de ERE a un destino
-
Proporciona capacidades de equilibrio de carga mediante la configuración de pesos para EROs individuales
-
Se alinea con el borrador de arquitectura SR-TE para definir rutas candidatas
Se admiten las siguientes capacidades de ruta múltiple PCEP:
-
Cuando el PCEP para varias rutas está habilitado (por defecto), puede configurar varias rutas principales (o una secundaria) en una ruta de candidato configurada y controlada por PCC.
-
Cuando el PCEP para varias rutas está deshabilitado, solo puede configurar una ruta principal en una ruta candidata. No se permite la configuración de ruta secundaria.
Si habilita varias rutas PCEP, compute-profile ahora se puede configurar con un número máximo de listas de segmentos (maximum-computed-segment-lists) mayor que 1.
Cuando se habilita el PCEP para varias rutas, PCCD no enviará restricciones para las rutas candidatas controladas por PCC.
Cuando se habilita la capacidad multiruta PCEP, se permite la configuración de ruta secundaria para una ruta candidata PCC no delegada, el objeto EXPLICIT-ROUTE (EROs) específico de la ruta secundaria se envía a la PCE con marca de respaldo establecida para la ERO. Las rutas principales no incluyen multipath-BACKUP-TLV en el mensaje PCRpt. La ruta secundaria incluye MULTIPATH-BACKUP-TLV con marca de respaldo establecida.
Se admiten las siguientes funcionalidades de múltiples rutas PCEP:
-
TLV de peso de varias rutas (MULTIPATH-WEIGHT-TLV) en atributo de ruta (PATH-ATTRIB) objeto
-
TLV de TLV de atributo de ruta (PATH-ATTRIB) solo para LSP de SR-TE controlados por PCC
-
TLV MULTIPATH-CAP en el objeto LSP PCEP
-
Restringe varias rutas principales y secundarias en la ruta candidata sr cuando la multiruta PCEP está deshabilitada
-
Varias rutas principales y secundarias en la ruta candidata de SR cuando la multiruta PCEP está habilitada para LSP controlados por PCC
-
Listas máximas de segmentos computados (
max-computed-segment-lists) más de 1 en el perfil de computación de SR-TE para LSP delegados y iniciados por PCE -
Varios ERE para la ruta de candidato iniciada por PCE en SR-TE y PCCD
-
LSP SRv6
-
SR MPLS (IPv4)
-
Túneles dinámicos sr MPLS (IPv4)
-
Soporte para varios controladores
-
Varias rutas ERO para rutas de candidatos de color y no coloradas, configuradas y controladas por PCE
-
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 de código de error para fallas en la validación de rutas candidatas iniciadas por PCE
-
El total de rutas de subcandidato por ruta candidata está limitado a 127. En el caso de los LSP iniciados por PCE, si el número de rutas ERO cruza 127, SR-TE lanza 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 PCEP:
| Tipo de error | Valor de error | Significado | Uso |
|---|---|---|---|
| 19 | 20 | Ruta de copia de seguridad no compatible | Esto ocurre cuando el PCC recibe la TLV MULTIPATH-BACKUP. |
| 24 | 1 | Parámetros de instanciación inaceptables | Esto ocurre cuando PCE intenta agregar más de 127 rutas de subcandidación por ruta candidata. |
Limitaciones
Se aplican las siguientes limitaciones de PCEP:
-
No se admiten los siguientes TLV mencionados en el draft-ietf-pce-multipath-06 :
-
TLV de respaldo de varias rutas
-
TLV de dirección opuesta de varias rutas
-
Ruta de candidato compuesta
-
-
Cuando la capacidad de varias rutas está deshabilitada en el PCEP, no se permite configurar varias rutas de subcandidación. Sin embargo, en dispositivos Junos sin capacidad de múltiples rutas (versiones de Junos OS anteriores a 22.4R1), se permite la configuración de varias rutas de subcandidación. Cuando se habilita el multisegmento PCEP (de forma predeterminada), se permiten varias rutas principales para los LSP controlados por PCC con el propósito de generar informes. Sin embargo, solo se admite una ruta principal para la ruta de candidato delegado cuando se habilita el multisegmento PCEP.
-
Los grupos de administradores ni cualquier otra restricción no se notificarán a PCE para las rutas de candidatos SR-MPLS y SRv6 configuradas y controladas por PCC (con una o varias configuraciones principales). No hay ningún impacto para las rutas de candidatos delegados e iniciados por PCE.
-
Cuando se habilita la capacidad de múltiples rutas PCEP, se permite la configuración de ruta secundaria para rutas candidatas no delegados. Cuando la capacidad de varias rutas PCEP está deshabilitada, no se permite la configuración de ruta secundaria.
-
Las rutas de los candidatos no pueden tener una combinación de LSP iniciados por PCE y delegados.
-
No se admiten varias rutas de subcandidato para una ruta de candidato de color iniciada por PCE.
-
No se admiten funciones de delegación con varias rutas de subcandidato en una ruta de candidato.
Configuración
Para permitir que PCCD envíe capacidad de varias rutas TLV en el objeto LSP para notificar la lista máxima de segmentos computados para una ruta de candidato específica, incluya la propagate-max-segmentlist instrucción de 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 disable-multipath-capability instrucción de 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 opciones de seguimiento de protocolo para diagnósticos:
-
user@host# set protocols pcep traceoptions... -
user@host# set protocols pcep pce pce1 traceoptions... -
user@host# set protocols source-packet-routing traceoptions
Puede usar 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 computación de rutas (PCC). -
user@host> show path-computation-client lsp extensive— Muestra un amplio nivel de salida de cada LSP conocido( punto a punto y punto a multipunto) LSP. -
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 spring.
Habilitación de la seguridad de la capa de transporte para sesiones de PCEP
La seguridad de capa de transporte (TLS) proporciona soporte para la autenticación de pares, el cifrado de mensajes y la integridad. Puede habilitar TLS en el cliente de computación de ruta (PCC) para establecer una conexión TCP con el elemento de computación de ruta (PCE) como se define en el RFC 8253. Esto crea una sesión PCEP segura (PCEPS) para transportar mensajes PCEP.
En este documento se describe cómo habilitar TLS para sesiones de PCEP para proteger las interacciones con PCE, incluyendo la iniciación de los procedimientos TLS, el mecanismo de enlace TLS y los métodos TLS para la autenticación par. El transporte seguro para PCEP sobre TLS también se conoce como PCEPS.
- Ventajas de habilitar TLS para sesiones de PCEP
- Habilitación de TLS en el cliente de computación 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 apretón de manos TLS
- Diagnóstico y validación de TLS para sesiones de PCEP
- Salida de muestra
Ventajas de habilitar TLS para sesiones de PCEP
-
Protege las sesiones PCEP de ataques como suplantación de identidad (suplantación de PCC o PCE), esnooping (intercepción de mensajes), falsificación y denegación de servicio.
-
Aprovecha las ventajas de seguridad TLS.
Habilitación de TLS en el cliente de computación de ruta (PCC)
Para habilitar TLS en PCC y establecer la sesión PCEPS, establezca la tls-strict instrucción CLI en el nivel de jerarquía [edit protocols pcep].
Después de habilitar la instrucción de configuración estricta para tls, se producen los siguientes eventos:
-
Flaps de sesión PCEP. Cualquier conexión TCP existente se termina y se realiza una reconexión mediante TLS.
-
La PCC establece la conexión TCP con el PCE.
-
Los procedimientos TLS se inician mediante el StartTLS mensaje de PCE a PCC y de PCC a PCE. PCC StartTLS envía el mensaje y se inicia el StartTLSWait temporizador. Puede configurar el StartTLSWait temporizador configurando la instrucción de la
start-tls-wait-timer secondsCLI en el nivel de jerarquía [edit protocols pcep pce pce-id].Nota:El valor recomendado para el StartTLSWait temporizador es de 60 segundos y no debe ser inferior al temporizador OpenWait . El valor predeterminado OpenWait del temporizador se establece como 60 segundos.
-
Si pcc recibe mensaje abierto en lugar de mensaje, PCErr mensaje con tipo de StartTLS 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 no abierto), y la sesión TCP se cierra.
-
Si StartTLS el mensaje no se recibe desde PCE, después de que expire el StartTLSWait temporizador, PCC envía un PCErr mensaje con El tipo de error establecido en 25 (falla de PCEP StartTLS ) y el valor de error establecido en 5 (sin StartTLS mensaje (ni PCErr/Open) antes StartTLSWait de que expire el tiempo), 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], a continuación, mientras establece una sesión PCEP, si pcc recibe el StartTLS mensaje en lugar de mensaje, PCErr mensaje con tipo de Open 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 no abierto), a continuación, se cierra la sesión TCP.
Para establecer una sesión PCEPS correcta, TLS debe habilitarse tanto en PCC como en PCE.
Actualización de certificados mediante la infraestructura de clave pública (PKI)
La PKI no notifica a PCC sobre la expiración 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 vencimiento 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 este CSR a CA para obtener el certificado. Una vez que se emite el certificado, se copia en la caja e se instala.
-
Method 2— Genere el par de claves y el certificado fuera de la caja. Tanto el certificado como la clave privada se copian en el dispositivo y se instalan juntos.
-
-
Cargue la entidad de certificación (CA) en el PCC para que el certificado de 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 una jerarquía plana como una CA independiente. Si una CA es una sub CA 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 sobre TLS con mecanismo de apretón de manos TLS.
-
El servidor PCE escucha el puerto 4189 para solicitudes de conexión PCC entrantes mediante TLS.
-
PCC inicia la solicitud de conexión al puerto de destino 4189.
-
Una vez que se completa un apretón de manos de tres vías, el apretón de manos TLS comienza usando los certificados y la autenticación unívoca se realiza (PCC autentica certificado de servidor). Tanto el servidor como el cliente esperan StartTLSWait el tiempo para recibir el StartTLS mensaje. Puede configurar el StartTLSWait temporizador configurando la instrucción de la
start-tls-wait-timer secondsCLI en el nivel de jerarquía [edit protocols pcep pce pce-id].Nota:El valor recomendado para el StartTLSWait temporizador es de 60 segundos y no debe ser inferior al temporizador OpenWait . El valor predeterminado OpenWait del temporizador se establece como 60 segundos.
-
Después de la sesión de apretón de manos TLS correcta, PCC y PCE inician el establecimiento de sesión PCEP sobre TLS durante el cual se negocian los parámetros de sesión.
-
Si se produce un error en la validación del certificado, PCC termina la conexión TCP.
-
-
El mensaje PCEP se envía a través de la conexión TLS como datos de la aplicación.
-
El cifrado y el descifrado se producen 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 en curso sobre TLS, la sesión en curso no se ve afectada.
Descripción del mecanismo básico de apretón de manos TLS
El apretón de manos es una serie de mensajes intercambiados entre un servidor y un cliente. Los pasos exactos en el apretón de manos varían según el algoritmo de intercambio de claves, el conjunto de cifrado, etc. Los siguientes son los pasos básicos del mecanismo de apretón de manos TLS:
-
Client Hello— El cliente inicia el apretón de manos mediante el envío de este mensaje. Este mensaje contiene la versión de TLS, una lista de algoritmos criptográficos compatibles o conjunto de cifrado y otros detalles del cliente.
-
Server Hello— El servidor responde al saludo del cliente mediante el envío de un mensaje de Hola a Sever. Este mensaje contiene certificado de servidor, algoritmo criptográfico seleccionado, id de sesión y clave pública del servidor.
-
Authentication— El cliente en segundo plano verifica el certificado del servidor con la autoridad de certificación configurada que emitió el certificado. Cuando la verificación se realiza correctamente, 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 de saludo al servidor, entonces 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 de saludo al servidor).
-
Decrypt secret key— El servidor descifra la clave secreta mediante la clave privada.
-
Client Finished— El cliente envía un mensaje de finalización cifrado con la clave secreta compartida y el apretón de manos de señales completo.
-
Server Finished— El servidor responde con un mensaje de finalización cifrado con la clave secreta compartida y el apretón de manos de señales completo.
-
Exchange Messages— Los mensajes tras la finalización del apretón de manos se cifran simétricamente.
Diagnóstico y validación de TLS para sesiones de PCEP
Para diagnósticos, utilice las siguientes instrucciones de CLI de seguimiento:
user@host# set protocols pcep traceoptions … user@host# set protocols pcep pce pce-id traceoptions … user@host# set protocols source-packet-routing traceoptions
Habilite 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
El siguiente es 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.
-
El PCE es compatible con TLS.
-
Se establece la sesión TLS. Esto también indica que el certificado del servidor PCE es válido.
-
El estado de la sesión de PCEPS está activo y en funcionamiento.
Optimización de ruta de informes y métricas computadas en PCEP
Objeto de métrica en PCEP se utiliza para varios propósitos. El objeto metric indica el tipo de métrica que se utiliza para la optimización de rutas. El objeto metric también indica un límite en el costo de la ruta que no se debe superar para que la ruta se considere aceptable. El objeto de métrica también indica la métrica calculada.
Somos compatibles con el objeto métrico para la optimización de rutas (protocolo de puerta de enlace interior, ingeniería de tráfico y retraso de ruta) y la generación de informes de métricas computadas para LSP RSVP y SR-TE.
Objeto de métrica para la optimización de rutas y la generación de informes de métricas computadas no es aplicable para LSP SRv6-TE.
- Beneficios de la optimización de rutas de informes y métricas computadas en PCEP
- Descripción de métricas de optimización
- Configuración de métricas de optimización para LSP
- Salida de muestra
Beneficios de la optimización de rutas de informes y métricas computadas en PCEP
-
La generación de informes de métricas de optimización de rutas configuradas en PCC ayuda a PCE a ser consciente de las restricciones que se utilizan para el cálculo de rutas.
-
Informes de métricas calculadas al PCE. Esto ayuda a PCE a analizar si el LSP requiere una mayor optimización.
Descripción de métricas de optimización
En la siguiente sección se describen las métricas de optimización previstas y reales para los LSP RSVP y SR-TE (SR MPLS) en PCEP.
- LSP de RSVP creado localmente
- LSP de RSVP delegado
- LSP de RSVP iniciado por PCE
- LSP sr-TE delegado
- LSP de SR-TE iniciado por PCE
- Envío de métricas de optimización en mensaje PCRpt
- Envío de métricas computadas en mensaje PCRpt
- Incompatibilidad hacia atrás para métricas de ruta
LSP de RSVP creado localmente
Para optimizar los LSP RSVP creados localmente con métricas, configure las métricas de optimización (IGP, TE y retraso de ruta) de modo que la métrica configurada se informe a través del 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 LSP RSVP delegados, configure las métricas de optimización (IGP, TE y retraso de ruta).
Intended Metric:
-
Cuando la métrica de optimización se configura 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 de LSP, el cambio se aplica en el LSP/se comunica al PCE cuando el estado de control 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 subsiguientes no contienen la métrica prevista.
-
Cuando el estado del control LSP cambia a controlado localmente, la métrica de optimización configurada desde la CLI de Junos será la métrica prevista en el mensaje PCRpt.
Actual Metric:
-
Mientras se delega el LSP, el mensaje PCRpt no contiene una métrica real.
-
Cuando se recibe el mensaje PCUpd, si la métrica computada está presente en el mensaje, la métrica se utiliza como métrica real en mensajes PCRpt subsiguientes 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 subsiguientes no contienen métricas reales.
-
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 de RSVP 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 initatado por PCE cuando el estado de control 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 el 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 subsiguientes no contienen la métrica prevista.
-
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 mensajes PCRpt posteriores hasta que el estado del 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 subsiguientes no contienen 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 LSP de 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 se configura 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 de LSP, el cambio se aplica en el LSP/se comunica al PCE cuando el estado de control 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 subsiguientes no contienen la métrica prevista.
-
Cuando el estado del control LSP cambia a controlado localmente, la métrica de optimización configurada desde la CLI de Junos será la métrica prevista 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 computados 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 varios ERO, la métrica computada/métrica real no se envía en el mensaje PCRpt, ya que la métrica real se debe enviar por LSP (no por ERO) en el PCEP.
-
Cuando se recibe el mensaje PCUpd, si la métrica computada está presente en el mensaje, la métrica se utiliza como métrica real en mensajes PCRpt subsiguientes 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 subsiguientes no contienen métricas reales.
-
Cuando el estado del control LSP cambia a controlado localmente, IGP, TE y métricas de retraso computadas en PCC se envían como métricas reales en el mensaje PCRpt.
LSP de SR-TE iniciado por PCE
Las métricas previstas o métricas reales enviadas por PCE en PCInit/PCUpd los mensajes se informan de nuevo a PCE a través del mensaje PCRpt hasta que el LSP se controla externamente.
Intended Metric:
-
Cuando se recibe el 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 subsiguientes no contienen la métrica prevista.
-
Cuando el estado de control LSP se controle localmente, no se enviará la métrica prevista.
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 mensajes PCRpt subsiguientes hasta que el estado del 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 subsiguientes no contienen métricas reales.
-
Cuando el estado del control LSP cambia a controlado localmente, los mensajes PCRpt subsiguientes no contienen métricas reales.
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 B, las marcas C se establecen en 0. El tipo de métrica indica la métrica que se va a optimizar.
Envío de métricas computadas en mensaje PCRpt
La métrica calculada se envía al PCE a través del actual-attributes-list mensaje en el PCRpt. Valor de la métrica es el valor de la métrica calculada y el tipo de métrica indica el tipo de métrica calculada. La marca B se establece en 0, la marca C se establece en 1.
Incompatibilidad hacia atrás para métricas de ruta
Dado que se admite la métrica de ruta mediante el uso de TLV de proveedor, PCC no procesará la métrica de ruta enviada en objeto de métrica por Juniper PCE compatible con Northstar y versiones anteriores de paragon pathfinder.
Configuración de métricas de optimización para LSP
Puede configurar métricas de optimización (IGP, TE y retraso de ruta) para LSP RSVP y LSP de SR-TE.
Para configurar las métricas de optimización de retraso de IGP, TE y ruta para LSP 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 optimización de retraso de IGP, TE y ruta para 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 comandos y show path-computation-client lsp extensive cli show path-computation-client lsp para mostrar el estado de las rutas conmutadas por etiquetas (LSP) conocidas por el cliente de computación de rutas (PCC).
El siguiente es un resultado de 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 : , , , ,
El resultado muestra que el LSP está optimizado con el tipo de métrica IGP. El valor calculado de la métrica IGP es 50. La métrica Route instalada en la tabla de ruta es 50.
external cspfde , se introducen dos nuevos tipos de computación de ruta para los LSP controlados por PCE: local cspf y no cspf.