Configuración de LSP de enrutamiento por segmentos
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
}
}
}
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 1 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 1, 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.
S-BFD basado en motores de enrutamiento para ingeniería de tráfico de enrutamiento por segmentos con resolución de etiquetas de primer salto
Puede ejecutar la detección de reenvío bidireccional (S-BFD) sin problemas sobre rutas conmutadas por etiquetas (LSP) sin colores y con resolución de etiquetas de primer salto, usando S-BFD como un mecanismo rápido para detectar fallas de ruta.
- Descripción de S-BFD basado en RE para la ingeniería de tráfico de enrutamiento por segmentos con resolución de etiquetas de primer salto
- Configuración de S-BFD basada en RE para la ingeniería de tráfico de enrutamiento por segmentos con resolución de etiquetas de primer salto
- Ejemplo
- Verifique que los LSP estén configurados para túneles de enrutamiento por segmentos estáticos y que el estado de la sesión de S-BFD sea visible
- Verificar la ruta de túnel de enrutamiento por segmentos con un salto siguiente principal y un salto siguiente secundario
- Verificar la sesión S-BFD de la ruta principal
Descripción de S-BFD basado en RE para la ingeniería de tráfico de enrutamiento por segmentos con resolución de etiquetas de primer salto
- Túneles de enrutamiento por segmentos estáticos S-BFD para etiquetas de primer salto
- Limitaciones
- Derivación automática de discriminador remoto (RD) para sesión SBFD
Túneles de enrutamiento por segmentos estáticos S-BFD para etiquetas de primer salto
La arquitectura de enrutamiento por segmentos permite que los nodos de entrada en una red central dirijan el tráfico a través de rutas explícitas a través de la red. El siguiente salto de la ingeniería de tráfico de enrutamiento de segmentos (TE) es una lista o listas de identificadores de segmentos (SID). Estas listas de segmentos representan las rutas de la red que desea que tome el tráfico entrante. El tráfico entrante puede estar etiquetado o tráfico IP y la operación de reenvío en el nodo de entrada puede ser un intercambio de etiquetas o una búsqueda basada en el destino para dirigir el tráfico hacia estas rutas de TE de enrutamiento de segmentos en la ruta de reenvío.
Puede ejecutar BFD (S-BFD) sin problemas sobre LSP de enrutamiento por segmentos estáticos sin color y de color con resolución de etiquetas de primer salto, y usar S-BFD como mecanismo rápido para detectar fallas de rutas y activar la convergencia global. S-BFD requiere menos cambios de estado que BFD, lo que acelera la notificación de fallas de ruta.
Dado un túnel de enrutamiento por segmentos con uno o varios LSP principales y, opcionalmente, un LSP secundario, puede habilitar S-BFD en cualquiera de esos LSP. Si una sesión S-BFD falla, el software actualiza la ruta del túnel de enrutamiento por segmentos mediante la eliminación de los saltos siguientes de los LSP fallidos. Si la etiqueta del primer salto del LSP apunta a más de un salto inmediato, el kernel sigue enviando paquetes S-BFD si hay al menos un salto siguiente disponible (la detección subyacente de fallas de accesibilidad del salto siguiente debe ser más rápida que la duración del temporizador de detección S-BFD).
Este modelo es compatible con LSP de traducción automática.
S-BFD de nivel LSP
Se crea una sesión S-BFD para cada combinación única de etiquetas, pila+ familia de direcciones. Puede configurar listas de segmentos idénticas y habilitar S-BFD para todos ellos. Las listas de segmentos que tienen combinaciones idénticas de label-stack+ familia de direcciones comparten la misma sesión S-BFD. La dirección de origen de la sesión S-BFD se establece en la dirección de circuito cerrado menos configurada (excepto las direcciones especiales) en la instancia principal.
Asegúrese de que la dirección de origen elegida es enrutable.
La familia de direcciones de un LSP se deriva según la familia de direcciones de la dirección "a" en el túnel de TE de enrutamiento por segmentos. El estado del LSP con S-BFD configurado también depende de si BFD está activo; si S-BFD está configurado para un LSP, la ruta LSP no se calcula hasta que S-BFD informa que la ruta está activa.
Parámetros S-BFD
Se admiten los siguientes parámetros S-BFD para rutas de TE de enrutamiento por segmentos:
-
Discriminación remota
-
Intervalo mínimo
-
Multiplicador
-
Sin opción de alerta de enrutador
En S-BFD, cada persona que responde puede tener múltiples discriminaciones. IGP puede anunciar los discriminadores a otros enrutadores o configurarse estáticamente en estos enrutadores. En un iniciador, se elige a un discriminador en particular como discriminador remoto para una sesión S-BFD por configuración estática, en función de la decisión o resolución tomada por usted o por un controlador central. Cuando se crean varios LSP con la misma pila de etiquetas de clave y se habilita el S-BFD en cada uno de ellos con parámetros diferentes, el valor agresivo de cada parámetro se utiliza en la sesión de S-BFD compartida. Para el parámetro discriminatorio, el valor más bajo se considera el más agresivo. De manera similar para la opción de alerta de enrutador, si una de las configuraciones no hay ninguna alerta de enrutador configurada, el parámetro S-BFD derivado no tendrá ninguna opción de alerta de enrutador.
Limitaciones
-
Solo se admite la reparación global.
-
Aunque S-BFD detecta fallas según los valores de temporizador configurados, el tiempo de convergencia depende del tiempo de reparación global (seconds).
Derivación automática de discriminador remoto (RD) para sesión SBFD
A partir de Junos OS versión 22.4R1, puede usar el discriminador remoto derivado automáticamente para sesiones SBFD para las rutas SR-TE. Con esta función, no es necesario configurar una remote-discriminator en la configuración de SFBD en el dispositivo de entrada o tránsito y una discriminación local coincidente en su respectivo punto de conexión. En su lugar, el dispositivo PE de salida ahora aceptará direcciones IP como su discriminador local. Para permitir que la dirección IP sea discriminatoria local en BFD, utilice la set protocols bfd sbfd local-discriminator-ip configuración.
También puede usar una plantilla de SBFD común con las configuraciones de SBFD en varias políticas de SR-TE aprovisionadas del controlador. En estas sesiones de SBFD, Junos OS deriva automáticamente el discriminador remoto del punto de conexión del túnel para hacer coincidir las políticas de SR-TE.
-
Somos compatibles con la derivación automática de RD solo para puntos de conexión IPv4, no para puntos de conexión IPv6.
-
No admitemos la derivación automática de RD para túneles de solo color. Si la RD no está configurada (por derivación automática de RD) para túneles de SOLO color de SR-TE configurados estáticamente, el sistema mostrará un error de confirmación. Si la RD no está configurada (mediante derivación automática de RD) para túneles dinámicos de solo color mediante la configuración de plantilla SR-TE, Junos OS omite la configuración sbfd para ese túnel.
Configuración de S-BFD basada en RE para la ingeniería de tráfico de enrutamiento por segmentos con resolución de etiquetas de primer salto
Para habilitar S-BFD de nivel LSP para una lista de segmentos, configure la bfd-liveness-detection instrucción de configuración en la [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] jerarquía y en la [edit protocols source-packet-routing source-routing-path lsp-path-name secondary segment-list-name] jerarquía.
Los siguientes pasos dan la configuración básica y, luego, el funcionamiento de S-BFD con resolución de etiqueta de primer salto:
Los pasos que se parecen a continuación describen los esquemas de la configuración básica:
En un enrutador de entrada, configure una o más listas de segmentos con etiquetas de primer salto para un túnel estático de enrutamiento por segmentos para usar como rutas principal y secundaria.
En el enrutador de entrada, configure el túnel de enrutamiento por segmentos estático con varias rutas principales (para equilibrio de carga) o una ruta principal y una ruta secundaria (para protección de rutas). Cada ruta principal o secundaria (LSP) hace referencia a una de las listas de segmentos que ya configuró, que crea rutas mediante los saltos siguientes derivados de las etiquetas del primer salto a partir de LSP contribuyentes.
En el enrutador de entrada, habilite el equilibrio de carga por paquete para que las rutas que resuelven sobre rutas de entrada y la ruta binding-SID (que tienen etiquetas de primer salto) instalen todas las rutas activas en el motor de reenvío de paquetes. Una sesión S-BFD bajo un LSP protege todas las rutas que utilizan ese LSP.
En el enrutador de salida del túnel de enrutamiento por segmentos, configure el modo de respuesta de S-BFD con una D discriminatoria local, creando una sesión de escucha de S-BFD distribuida para D en cada FPC.
En el enrutador de entrada, configure S-BFD para cualquier LSP para el que desee ver la detección de fallas de ruta. Especifique una D discriminatoria remota que coincida con el S-BFD discriminador local del enrutador de salida. Se crea una sesión de iniciador S-BFD con la combinación label-stack+ familia de direcciones LSP como clave, si aún no existe una sesión de iniciador para la clave LSP actual. Los parámetros S-BFD en el caso de una sesión BFD coincidente se reevaluan teniendo en cuenta los nuevos LSP compartidos. Cuando se derivan los parámetros S-BFD, se elige el valor agresivo de cada parámetro.
Los pasos que se indican a continuación describen el funcionamiento básico:
La sesión del iniciador S-BFD se ejecuta en un modo centralizado en el motor de enrutamiento. El software rastrea los estados de la sesión S-BFD hacia arriba y hacia abajo.
Cuando el estado S-BFD se mueve a UP, el LSP se considera para las rutas pertinentes.
En el enrutador de entrada, si el software detecta una sesión de S-BFD ABAJO, se envía una notificación de sesión caída al demonio de enrutamiento (RPD) y RPD elimina el siguiente salto de los LSP fallidos de la ruta del túnel de enrutamiento por segmentos.
La pérdida de tráfico total en el procedimiento está vinculada al tiempo de detección de fallas de S-BFD y al tiempo de reparación global. El tiempo de detección de fallas de S-BFD está determinado por el intervalo mínimo S-BFD y los parámetros del multiplicador. El tiempo de reparación global depende del tiempo de proceso de te de enrutamiento por segmentos y de la reenvío de las rutas de reenvío.
Las pilas de etiquetas LSP se cambian de la siguiente manera:
El LSP en particular se desconecta de la sesión S-BFD existente. Si la sesión S-BFD existente tiene al menos un LSP referido a ella, se conserva la sesión BFD antigua, pero los parámetros S-BFD se vuelven a evaluar de modo que se elijan los valores de parámetro agresivo entre las sesiones LSP existentes. Además, el nombre de la sesión S-BFD se actualiza al menos si hay un cambio. Si la sesión S-BFD antigua no tiene más LSP conectados, esa sesión de S-BFD se elimina.
El software intenta encontrar una sesión BFD existente que coincida con el valor de combinación new-label-stack+familia de direcciones; si existe una coincidencia de este tipo, el LSP se refiere a esa sesión S-BFD existente. La sesión S-BFD se vuelve a evaluar para cualquier cambio en los parámetros o el nombre de la sesión de manera similar a las reevaluaciones en el paso 1.
Si no hay ninguna sesión BFD coincidente en el sistema, se crea una nueva sesión BFD y los parámetros S-BFD se derivan de este LSP.
Nota:El intervalo mínimo de una sesión de S-BFD y el multiplicador determinan el tiempo de detección de fallas de la sesión. El tiempo de reparación depende del tiempo de reparación global.
El siguiente resultado muestra instrucciones de configuración que usaría para un LSP de color con LSP principal:
[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;
... {
bfd-liveness-detection {
sbfd {
remote-discriminator value;
}
}
}
}
}
En el lado del respondedor, debe configurar el discriminador correcto:
[edit protocols bfd]
sbfd {
local-discriminator value;
}
De forma predeterminada, las alertas de enrutador se configuran para paquetes S-BFD. Cuando se elimina el encabezado MPLS en el extremo del respondedor, el paquete se envía al host para su procesamiento sin una búsqueda de dirección de destino para el paquete. Si habilita la opción sin alerta de enrutador en el enrutador de entrada, la opción de alerta de enrutador se elimina de las opciones de IP y, por lo tanto, del lado de salida. Debe configurar la dirección de destino explícitamente en lo0; de lo contrario, el paquete se descarta y S-BFD permanece inactivo.
[edit interfaces lo0 unit 0 family inet] address 127.0.0.1/32;
Puede usar un nuevo indicador de seguimiento, bfd, para rastrear actividades de BFD:
user@host# set protocols source-packet-routing traceoptions flag bfd
Ejemplo
La siguiente configuración es un ejemplo de un túnel de enrutamiento de segmentos estático sin color con protección LSP.
protocols {
source-packet-routing {
source-routing-path ncsrlsp5 {
to 10.10.10.10;
primary {
ncsrpath12 {
weight 1;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath13 {
weight 2;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath14 {
weight 3;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath15 {
weight 4;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
segment-list ncsrpath12 {
hop1 label 50191;
hop2 label 801000;
}
segment-list ncsrpath13 {
hop1 label 50191;
hop2 label 801001;
hop3 label 801000;
}
segment-list ncsrpath14 {
hop1 label 801000;
}
segment-list ncsrpath15 {
hop1 label 801002;
hop2 label 801000;
}
}
}
}
}
Verifique que los LSP estén configurados para túneles de enrutamiento por segmentos estáticos y que el estado de la sesión de S-BFD sea visible
Propósito
Utilice el comando show spring-traffic-engineering lsp detail para mostrar LSP para túneles de enrutamiento por segmentos estáticos con estado de sesión S-BFD.
Acción
user@host> show spring-traffic-engineering lsp detail
Name: abc
To: 77.77.77.77
State: Up
Path: sl1
Outgoing interface: NA
BFD status: Up BFD name: V4-sl1
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801007
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 22222
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 3333
Path: sl2
Outgoing interface: NA
BFD status: Up BFD name: V4-sl2
SR-ERO hop count: 2
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801006
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 121212
Path: sl2
Outgoing interface: NA
BFD status: Up BFD name: V4-sl2
SR-ERO hop count: 2
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801006
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 121212
Total displayed LSPs: 1 (Up: 1, Down: 0)
Dado que muchos LSP pueden compartir la misma sesión BFD, cuando aparece el primer LSP con una combinación exclusiva de label-stack+ familia de direcciones, el nombre de la sesión S-BFD usa address-family+ lsp-name. Si más LSP más tarde comparten la misma sesión, el nombre de la sesión puede cambiar a address-family + least-lsp-name, sin afectar el estado de la sesión S-BFD. El nombre de la sesión S-BFD también aparece en la salida del show bfd session extensive comando. La salida de cada LSP muestra el estado de S-BFD, así como el nombre de S-BFD al que hace referencia, tal como se muestra en el ejemplo anterior como BFD status: Up BFD name: V4-sl2. Dado que es posible que no haya una sesión de S-BFD por LSP, no se muestran los contadores de S-BFD de nivel LSP.
Verificar la ruta de túnel de enrutamiento por segmentos con un salto siguiente principal y un salto siguiente secundario
Propósito
En el motor de enrutamiento del enrutador de entrada, verifique la ruta de túnel de enrutamiento por segmentos con un salto siguiente principal y otro secundario.
Acción
user@host> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
128.9.146.157/32 *[SPRING-TE/8] 00:43:16, metric 1
> to 55.1.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, Push 1000123(top)
to 55.1.12.2 via ge-0/0/1.0, Push 1000934, Push 1000923(top)
Verificar la sesión S-BFD de la ruta principal
Propósito
En el motor de enrutamiento del enrutador de entrada, compruebe la sesión S-BFD de la ruta principal.
Acción
user@host> show bfd session extensive
Detect Transmit
Address State Interface Time Interval Multiplier
127.0.0.1 Up 4.000 1.000 4
Client SPRING-TE, TX interval 1.000, RX interval 1.000
Session up time 00:40:53, previous down time 00:02:08
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Multi hop BFD (Seamless)
Min async interval 1.000, min slow interval 1.000
Adaptive async TX interval 1.000, RX interval 1.000
Local min TX interval 1.000, minimum RX interval 1.000, multiplier 4
Remote min TX interval 1.000, min RX interval 0.001, multiplier 4
Local discriminator 28, remote discriminator 32
Echo mode disabled/inactive
Remote is control-plane independent
Path-Name V4-sl-1
1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 pps
En el motor de enrutamiento del enrutador de entrada, verifique la sesión S-BFD de la ruta secundaria también de manera similar.
Configuración del identificador de segmento de adyacencia estático para agregar vínculos de miembro Ethernet mediante LSP estático de salto único
En una red en la que se utilizan paquetes ethernet agregados (AE), un vínculo agregado podría ser un conjunto de cualquier número de vínculos físicos. El tráfico enviado a través de estas interfaces de paquete AE se reenvía en cualquiera de los vínculos miembros de una interfaz AE. El tráfico puede tomar cualquier vínculo físico basado en el hash definido para equilibrar la carga del tráfico, lo que hace que sea difícil aislar qué enlaces se han vuelto malos o están dejando caer el tráfico. Una forma de probar la ruta de reenvío disponible en la red es agregar una ruta estática de etiqueta conmutada (LSP) de salto único con el siguiente salto apuntando a un vínculo miembro específico de la interfaz AE.
La operación de etiqueta predeterminada para los LSP estáticos debe ser pop y reenvío. Cuando un paquete llega a estas rutas etiquetadas, el paquete se reenvía a un vínculo de miembro específico. Se utiliza una etiqueta única para identificar el vínculo de miembro. Estas etiquetas se denominan identificadores de segmento de adyacencia (SID) y se aprovisionan estáticamente.
Puede controlar el flujo de los paquetes en la red mediante la construcción de una pila de etiquetas en el controlador, que incluye las etiquetas asignadas por todos los LSP estáticos de tránsito. Los paquetes de operación, administración y mantenimiento (OAM) se diseñan e inyectan en la red con toda la pila de etiquetas.
Cuando un paquete llega a esta ruta de etiqueta, la etiqueta se reventa y el tráfico se reenvía en el vínculo miembro especificado en la configuración. Se elige una MAC de destino mientras se reenvía el paquete, la Mac de destino es la dirección MAC de interfaz agregada (seleccionada según la dirección de siguiente salto configurada).
Cuando el vínculo miembro se cae y la interfaz agregada está activa, entonces se elimina la ruta correspondiente a ese vínculo de miembro. Cuando se cae una interfaz de agregado, se eliminan todas las rutas correspondientes a los vínculos miembros de la interfaz agregada. Cuando la interfaz física secundaria se desconecta la LACP pero la interfaz física secundaria está activa, se elimina la ruta etiquetada para el vínculo secundario. En el caso de la separación LACP, si el vínculo miembro está activo y el estado de reenvío no válido, los paquetes OAM se pierden en el PFE cuando la interfaz física secundaria se desconecta.
Utilice el siguiente ejemplo para configurar LSP estáticos de salto único para un vínculo de miembro de AE.
Defina un intervalo estático de etiquetas.
user@host# set protocols mpls label-range static-label-range 1000000 1048575;Nota:Se recomienda configurar el intervalo de etiquetas estáticas predeterminada de 1000000-1048575 para el LSP estático. Si desea configurar un intervalo de etiquetas distinto del intervalo estático de etiquetas predeterminado, configure varios rangos.
Cree un LSP estático para el vínculo de miembro de AE desde el grupo de bloque local de enrutamiento de segmentos (SRLB) del intervalo de etiquetas estáticas.
user@host# set protocols mpls static-label-switched-path statc-lsp transit 100001 pop next-hop 10.1.1.1 member-interface ge-0/0/0
En esta configuración, se instala un enrutador de tránsito etiquetado en mpls.0, extrae la etiqueta y reenvía el paquete en el siguiente salto. La dirección del siguiente salto es obligatorio para las interfaces de difusión (como ge-, xe-, ae-) y el nombre if se utiliza para interfaces P2P (como tal-). La dirección es necesaria para las interfaces de difusión, ya que la dirección IP del siguiente salto se utiliza para elegir la dirección MAC de destino. La dirección MAC de origen del paquete es la dirección MAC de AE.
Las salidas de ejemplo muestran el nombre del vínculo de miembro en la salida del salto siguiente:
mostrar mpls estático-lsp extenso
user@host> show mpls static-lsp extensive Ingress LSPs: Total 0, displayed 0, Up 0, Down 0 Transit LSPs: LSPname: static-lsp1, Incoming-label: 1000001 Description: verify-static-lsp-behavior State: Up, Sub State: Traffic via primary but unprotected Nexthop: 10.2.1.1 Via ae0.0 -> ge-0/0/0 LabelOperation: Pop Created: Thu May 25 15:31:26 2017 Bandwidth: 0 bps Statistics: Packets 0, Bytes 0
muestra el nombre de etiqueta de ruta extenso de la etiqueta
user@host> show route label 1000001 extensive
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
1000001 (1 entry, 1 announced)
TSI:
KRT in-kernel 1000001/52 -> {Pop }
*MPLS Preference: 6
Next hop type: Router, Next hop index: 611
Address: 0xb7a17b0
Next-hop reference count: 2
Next hop: 10.2.1.1 via ae0.0 -> ge-0/0/0 weight 0x1, selected
Label operation: Pop
Load balance label: None;
Label element ptr: 0xb7a1800
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x15d
State: <Active Int>
Age: 3:13:15 Metric: 1
Validation State: unverified
Task: MPLS
Announcement bits (1): 1-KRT
AS path: I
Label 188765184Rutas de enrutamiento de segmentos intradominio e interdominio optimizados para retrasos informáticos
- Descripción general de métricas basadas en retrasos para rutas diseñadas de tráfico
- Beneficios de las métricas basadas en retrasos para la computación de rutas
- Computación basada en DCSPF con métricas de retraso para descripción general de rutas SR
- Descripción general de casos de uso de métricas de retraso para interdominio e intradominio
- Caso de uso de métricas de retraso en redes ópticas
Descripción general de métricas basadas en retrasos para rutas diseñadas de tráfico
Aprovechar las métricas dinámicas basadas en el retraso se está convirtiendo en un atributo deseable en las redes modernas. Las métricas basadas en retrasos son esenciales para un elemento de computación de ruta (PCE) para calcular las rutas diseñadas por tráfico. Puede usar métricas basadas en retrasos para dirigir los paquetes en las rutas de menor latencia o la ruta de menor retraso. Para ello, debe medir el retraso en cada vínculo y anunciarlo utilizando un protocolo de enrutamiento adecuado (IGP o BGP-LS), de modo que la entrada tenga las propiedades de retraso por vínculo en su TED.
Para comprender cómo anunciar la demora en cada vínculo o activar las mediciones de vínculo, consulte Cómo habilitar la medición de retrasos de vínculo y la publicidad en ISIS.
La siguiente secuencia de eventos se producen cuando se mide, anuncia y calcula la detección de cambios en la red y se calcula la ruta de tráfico diseñada con la latencia más corta:
- Detecte cambios en la red midiendo la latencia, con sondas sintéticas de enrutador a enrutador.
- Inunde los resultados a los nodos de entrada a través de extensiones métricas de TE extendidas de IGP.
- Anuncie los resultados a controladores centralizados con las extensiones BGP-LS correspondientes.
- Las rutas métricas de latencia acumulativa más corta (Flex-algo) basadas en IGP.
- Rutas explícitas diseñadas para computar el tráfico (de origen a destino) con menor latencia acumulada o métricas de retraso (SR-TE).
Beneficios de las métricas basadas en retrasos para la computación de rutas
- Implemente servicios de valor agregado según la latencia más baja en toda la red.
- Mida la latencia por ruta (mínima, máxima, media) mediante métricas basadas en retrasos.
- Dirigir los servicios sensibles al retraso (como vpn o servicios 5G) en rutas optimizadas para SR de latencia ultrabaja.
Computación basada en DCSPF con métricas de retraso para descripción general de rutas SR
Con la primera ruta más corta restringida distribuida (CSPF) para la función 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.
Puede configurar CSFP distribuido para que se ejecute en varias cabeceras y hacer cálculos de ruta de forma independiente en cada cabecera. Puede aplicar el perfil de computación en la ruta de origen (ruta de enrutamiento de paquetes de origen). Si ha configurado el perfil de computación optimizado para el promedio de retraso, también puede aplicar adicionalmente una restricción denominada .delay-variation-threshold Cuando configure un valor para delay-variation-threshold, cualquier vínculo que supere el valor de umbral se excluirá del cálculo de ruta.
Para configurar las métricas de retraso para el cálculo basado en DCSPF para la ruta SR, debe habilitar la delay instrucción de configuración en el nivel de jerarquía [edit protocols source-packet-routing compute-profile profile-name metric-type delay]. Puede configurar las métricas de retraso, como mínimo, máximo, promedio y umbral de variación de retraso para el cálculo de ruta.
minimum— Valor de la métrica de retraso mínimo de TED para el cálculo de la ruta de latencia más baja acumulada.average— Valor medio de la métrica de retraso de TED para el cálculo de la ruta de latencia más baja acumulada.maximum— Valor de métrica de retraso máximo de TED para el cálculo de la ruta de latencia más baja acumulada.delay-variation-threshold—Umbral de variación de retraso del vínculo (1..16777215). Se excluiría del cálculo de ruta cualquier vínculo que supere el umbral de variación de retraso. El umbral de variación de retraso es independiente de si se está optimizando para el mínimo, el máximo o el promedio. Ladelay-variation-thresholdinstrucción de configuración aparece en estos niveles jerárquicos:-
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay] -
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay minimum] -
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay maximum] -
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay average]
-
Puede configurar métricas de retraso en la siguiente jerarquía de CLI:
[edit]
protocols {
source-packet-routing {
compute-profile <name> {
metric-type delay {
minimum;
maximum;
average;
delay-variation-threshold <value>;
}
}
}
}
Descripción general de casos de uso de métricas de retraso para interdominio e intradominio
Para el caso de intradominio (la ruta reside dentro de un solo dominio), el retraso del vínculo se tiene en cuenta al realizar el cálculo de rutas. Las métricas de retraso para la computación de rutas de enrutamiento de segmentos se admiten tanto en SID comprimidos como en SID no comprimidos. Si tiene SID sin comprimir, se utilizan segmentos de adyacencia para listas de segmentos para producir varias listas de segmentos si hay costos iguales. Puede configurar SID sin comprimir mediante la no-label-stack-compression instrucción de configuración en el nivel de jerarquía [edit protocols source-packet-routing compute-profile profile-name]. Esto proporciona una ruta completamente expandida mediante SID de adyacencia. Consulte el perfil de computación para obtener más información.
La siguiente es una configuración de ejemplo para métricas de retraso:
[edit protocols source-packet-routing]
user@host# show
compute-profile profile1 {
no-label-stack-compression;
metric-type {
delay {
minimum;
delay-variation-threshold 300;
}
}
}
Para el cálculo de rutas ópticas, se recomienda usar las métricas de retraso como mínimo. El mínimo es la configuración predeterminada.
Para el caso de uso de interdominio (multidominio), en el que hay varios sistemas autónomos, puede usar segmentos expresos para configurar retrasos de vínculos para el cálculo de rutas. Los segmentos expresos son vínculos que conectan nodos de borde o ASBR. Consulte Configuración de LSP por segmentos express para obtener información sobre los segmentos expresos. Puede configurar el retraso o heredar el retraso del LSP subyacente en el segmento express. Puede configurar delay en el nivel de jerarquía [edit protocols express-segments segment-template template-name metric] y establecer los valores para retrasos mínimos, máximos y promedios.
Puede configurar métricas de retraso en un segmento expreso en la siguiente jerarquía de CLI:
[edit]
protocols {
express-segments {
segment-template <name> {
metric delay [ min <value> | avg <value> | max <value>
}
}
}
Para el cálculo de rutas entre dominios, puede asignar métricas de retraso en vínculos EPE del BGP. Puede configurar un valor para delay-metric el nivel de jerarquía [edit protocols bgp group group-name neighbor ip address egress-te-adj-segment segment-name egress-te-link attribute] como se muestra a continuación:
[edit]
protocols {
bgp {
group <name> {
type external;
}
neighbor <ip_addr> {
egress-te-adj-segment <name> {
egress-te-link-attribute {
delay-metric <value>
}
}
}
}
}
Caso de uso de métricas de retraso en redes ópticas
Las topologías siguientes muestran un ejemplo de caso de uso óptico. Las soluciones de restauración y protección óptica dan como resultado los atributos físicos subyacentes, principalmente la longitud de la ruta, que cambian debido a fallas de vínculo y la consiguiente optimización de red MDCLO.
En la figura, el vínculo entre A y C se encuentra a través de los nodos ópticos O1 y O3 y tiene una latencia de 10 microsegundos. En la figura, puede ver una falla de vínculo entre los nodos ópticos O1 y O3 y que la conexión óptica real se reenruta a través del nodo óptico O2. Esto aumenta la latencia de 15 microsegundos. La métrica del vínculo que conecta A y B cambia dinámicamente entre time=0 y time=1.
Cuando la entrada detecta un cambio en el retraso por vínculo, la entrada activa la recomputación de la ruta optimizada de retraso y el enrutador de cabecera reenruta la ruta a través de la siguiente ruta de menor latencia disponible. El cambio en el retraso del vínculo puede hacer que la entrada elija otro conjunto de vínculos que tenga la ruta de menor latencia. En la figura B, puede ver que hay un cambio en el vínculo entre la ruta A y C y el enrutador de cabecera reenruta y selecciona la ruta A-B-C como se muestra en la topología.