Configuración de LSP de enrutamiento por segmentos
Habilitación de CSPF distribuido para LSP de enrutamiento de segmentos
Antes de Junos OS versión 19.2R1S1, para la ingeniería de tráfico de rutas de enrutamiento de segmentos, podía configurar explícitamente rutas estáticas o utilizar rutas calculadas desde un controlador externo. Con la característica distribuida Restricted Shortest Path First (CSPF) para LSP de enrutamiento de segmentos, puede calcular un LSP de enrutamiento de segmentos localmente en el dispositivo de entrada según las restricciones que haya configurado. Con esta característica, los LSP se optimizan en función de las restricciones configuradas y el tipo de métrica (ingeniería de tráfico o IGP). Los LSP se calculan para utilizar las rutas ECMP disponibles al destino con la compresión de pila de etiquetas de enrutamiento de segmentos habilitada o deshabilitada.
- Restricciones de cálculo de CSPF distribuidas
- Algoritmo de cálculo CSPF distribuido
- Base de datos de cómputo CSPF distribuida
- Configuración de restricciones de cálculo de CSPF distribuidas
- Cálculo distribuido de CSPF
- Interacción entre la computación CSPF distribuida y las características de SR-TE
- Configuraciones de ejemplo de cómputo CSPF distribuido
Restricciones de cálculo de CSPF distribuidas
Las rutas LSP de enrutamiento de segmentos se calculan cuando se cumplen todas las restricciones configuradas.
La característica de cálculo de CSPF distribuida admite el siguiente subconjunto de restricciones especificadas en el borrador de Internet, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineering:
-
Inclusión y exclusión de grupos administrativos.
-
Inclusión de direcciones IP de salto flexible o estricto.
Nota:Solo puede especificar ID de enrutador en las restricciones de salto flexibles o estrictas. Las etiquetas y otras direcciones IP no se pueden especificar como restricciones de salto flexibles o estrictas en Junos OS versión 19.2R1-S1.
-
Número máximo de identificadores de segmento (SID) en la lista de segmentos.
-
Número máximo de listas de segmentos por ruta de enrutamiento de segmento candidato.
La característica de cálculo de CSPF distribuida para los LSP de enrutamiento de segmentos no admite los siguientes tipos de restricciones y escenarios de implementación:
-
Direcciones IPV6.
-
LSP de ingeniería de tráfico de enrutamiento por segmentos entre dominios (SR-TE).
-
Interfaces no numeradas.
-
Múltiples protocolos de enrutamiento, como OSPF, ISIS y BGP-LS, habilitados al mismo tiempo.
-
Cálculo con prefijos o direcciones anycast como destinos.
-
Incluir y excluir direcciones IP de interfaz como restricciones.
Algoritmo de cálculo CSPF distribuido
La función de cálculo de CSPF distribuida para los LSP de enrutamiento de segmentos utiliza el algoritmo de compresión de pila de etiquetas con CSPF.
Compresión de pila de etiquetas habilitada
Una pila de etiquetas comprimidas representa un conjunto de rutas desde un origen hasta un destino. Generalmente consiste en SID de nodo y SID de adyacencia. Cuando la compresión de pila de etiquetas está habilitada, el resultado del cálculo es un conjunto de rutas que maximizan el ECMP al destino, con un número mínimo de SID en la pila, mientras se ajustan a las restricciones.
Compresión de pila de etiquetas deshabilitada
El cálculo de CSPF multiruta con la compresión de pila de etiquetas deshabilitada encuentra hasta listas de segmentos hasta destino, donde:N
-
El costo de todas las listas de segmentos es igual e igual que la métrica de ingeniería de tráfico más corta para llegar al destino.
-
Cada lista de segmentos se compone de SID de adyacencia.
-
El valor de es el número máximo de listas de segmentos permitidas para la ruta candidata por configuración.N
-
No hay dos listas de segmentos idénticas.
-
Cada lista de segmentos satisface todas las restricciones configuradas.
Base de datos de cómputo CSPF distribuida
La base de datos utilizada para el cálculo de SR-TE tiene todos los vínculos, nodos, prefijos y sus características, independientemente de si la ingeniería de tráfico está habilitada en esos nodos publicitarios. En otras palabras, es la unión de la base de datos de ingeniería de tráfico (TED) y la base de datos de estado de enlace IGP de todos los dominios de los que el nodo de computación ha aprendido. Como resultado, para que CSPF funcione, debe incluir la instrucción en el nivel jerárquico .igp-topology[edit protocols isis traffic-engineering]
Configuración de restricciones de cálculo de CSPF distribuidas
Puede usar un perfil de proceso para agrupar lógicamente las restricciones de cálculo. Las rutas de enrutamiento de segmentos hacen referencia a estos perfiles de proceso para calcular los LSP de enrutamiento de segmentos primario y secundario.
Para configurar un perfil de proceso, incluya la instrucción compute-profile en el nivel de jerarquía.compute-profile[edit protocols source-packet-routing]
La configuración de las restricciones de cálculo admitidas incluye:
-
Administrative groups
Puede configurar grupos de administradores en el nivel jerárquico .admin-groups
[edit protocols mpls]Junos OS aplica la configuración del grupo administrativo a las interfaces de ingeniería de tráfico de enrutamiento de segmentos (SR-TE).Para configurar las restricciones de cálculo, puede especificar tres categorías para un conjunto de grupos administrativos. La configuración de restricción de cálculo puede ser común a todas las rutas de enrutamiento de segmentos candidatos o puede ser bajo rutas candidatas individuales.
-
include-any: especifica que cualquier vínculo con al menos uno de los grupos administrativos configurados de la lista es aceptable para la ruta que se va a recorrer. -
include-all: especifica que cualquier vínculo con todos los grupos administrativos configurados en la lista es aceptable para la ruta que se va a recorrer. -
exclude: especifica que cualquier vínculo que no tenga ninguno de los grupos administrativos configurados en la lista es aceptable para la ruta que se va a recorrer.
-
-
Explicit path
Puede especificar una serie de ID de enrutador en el perfil de proceso como restricción para calcular las rutas candidatas de SR-TE . Cada salto tiene que ser una dirección IPv4 y puede ser de tipo estricto o suelto. Si el tipo de salto no está configurado, se utiliza strict. Debe incluir la opción bajo la instrucción segment-list al especificar la restricción de ruta explícita.
computesegment-list -
Maximum number of segment lists (ECMP paths)
Puede asociar una ruta candidata con una serie de listas de segmentos dinámicas. Las rutas son rutas ECMP, donde cada lista de segmentos se traduce en una puerta de enlace de salto siguiente con peso activo. Estas rutas son el resultado del cálculo de rutas con o sin compresión.
Puede configurar este atributo mediante la opción situada en la instrucción de configuración del perfil informático .
maximum-computed-segment-lists maximum-computed-segment-listscompute-profile Esta configuración determina el número máximo de listas de segmentos calculadas para un LSP primario y secundario determinados. -
Maximum segment list depth
El parámetro de cálculo de profundidad máxima de lista de segmentos garantiza que entre las rutas ECMP que satisfagan todas las demás restricciones, como el grupo administrativo, solo se utilicen las rutas que tengan listas de segmentos menores o iguales a la profundidad máxima de lista de segmentos. Cuando se configura este parámetro como una restricción en el perfil de proceso, se invalida la configuración en el nivel de jerarquía, si está presente.
maximum-segment-list-depth[edit protocols source-packet-routing]Puede configurar este atributo mediante la opción situada en la instrucción de configuración del perfil informático .
maximum-segment-list-depth maximum-segment-list-depthcompute-profile -
Protected or unprotected adjacency SIDs
Puede configurar SID de adyacencia protegido o no protegido como una restricción en el perfil de proceso para evitar vínculos con el tipo de SID especificado.compute-profile
-
Metric type
Puede especificar el tipo de métrica en el vínculo que se utilizará para el cálculo. De forma predeterminada, los LSP de SR-TE usan métricas de ingeniería de tráfico de los vínculos para el cálculo. La métrica de ingeniería de tráfico para los enlaces se anuncia mediante extensiones de ingeniería de tráfico de los protocolos IGP. Sin embargo, también puede optar por usar la métrica IGP para el cálculo mediante la configuración de tipo métrico en el perfil de proceso.
Puede configurar este atributo mediante la opción situada en la instrucción de configuración del perfil informático .
metric-type (igp | te)compute-profile
Cálculo distribuido de CSPF
Las rutas candidatas de SR-TE se calculan localmente de manera que satisfagan las restricciones configuradas. Cuando la compresión de pila de etiquetas está deshabilitada, el resultado del cálculo de CSPF de varias rutas es un conjunto de pilas SID de adyacencia. Cuando la compresión de pila de etiquetas está habilitada, el resultado es un conjunto de pilas de etiquetas comprimidas (compuestas por SID adyacentes y SID de nodo).
Cuando se calculan rutas secundarias, los vínculos, nodos y SRLG tomados por las rutas primarias no se evitan para el cálculo. Para obtener más información sobre las rutas principales y secundarias, consulte Configuración de LSP primarios y secundarios.Configuración de LSP primarios y secundarios
Para cualquier LSP con resultado de cálculo incorrecto, el cálculo se vuelve a intentar a medida que cambia la base de datos de ingeniería de tráfico (TED).
Interacción entre la computación CSPF distribuida y las características de SR-TE
- Pesos asociados a rutas de una política SR-TE
- Detección de vivacidad BFD
- inherit-label-nexthops
- Función de traducción automática
Pesos asociados a rutas de una política SR-TE
Puede configurar pesos con rutas de SR-TE calculadas y estáticas, que contribuyen a los siguientes saltos de la ruta. Sin embargo, una sola ruta que tenga habilitada la computación puede dar lugar a varias listas de segmentos. Estas listas de segmentos calculadas se tratan como ECMP entre sí. Puede asignar ponderaciones ECMP jerárquicas a estos segmentos, teniendo en cuenta las ponderaciones asignadas a cada una de las primarias configuradas.
Detección de vivacidad BFD
Puede configurar la detección de vivacidad de BFD para las rutas primarias o secundarias calculadas. Cada ruta primaria o secundaria calculada puede dar como resultado varias listas de segmentos; como resultado, los parámetros BFD configurados en las listas de segmentos se aplican a todas las listas de segmentos calculadas. Si todas las rutas primarias activas dejan de funcionar, la ruta secundaria preprogramada (si se proporciona) se activa.
inherit-label-nexthops
No es necesario habilitar explícitamente la configuración en la jerarquía para las rutas principales o secundarias calculadas, ya que es un comportamiento predeterminado.inherit-label-nexthops[edit protocols source-packet-routing segment-list segment-list-name]
Función de traducción automática
Puede configurar la función de traducción automática en las listas de segmentos, y las rutas principales o secundarias con la función de traducción automática hacen referencia a estas listas de segmentos. Por otro lado, la característica principal o secundaria en la que está habilitada la característica de proceso no puede hacer referencia a ninguna lista de segmentos. Como resultado, no puede habilitar tanto la característica de proceso como la función de traducción automática para una ruta principal o secundaria determinada. Sin embargo, podría tener un LSP configurado con una ruta principal con tipo de proceso y otra con tipo de traducción automática.
Configuraciones de ejemplo de cómputo CSPF distribuido
Ejemplo 1
En el ejemplo 1,
-
La ruta principal no calculada hace referencia a una lista de segmentos configurada. En este ejemplo, se hace referencia a la lista de segmentos configurados, que también sirve como nombre para esta ruta principal.static_sl1
-
Un primario calculado debe tener un nombre configurado y este nombre no debe hacer referencia a ninguna lista de segmentos configurada. En este ejemplo, no es una lista de segmentos configurada.compute_segment1
-
El perfil informático se aplica a la ruta principal con el nombre .compute_profile_redcompute_segment1
-
El perfil de proceso incluye una lista de segmentos de tipo , que se utiliza para especificar la restricción de ruta explícita para el cálculo.compute_profile_red
compute
[edit protocols source-packet-routing]
segment-list static_sl1{
hop1 label 80000
}
segment-list exp_path1 {
hop1 ip-address 10.1.1.1 loose
hop2 ip-address 10.2.2.2
compute
}
compute-profile compute_profile_red {
include-any red
segment-list exp_path1
maximum-segment-list-depth 5
}
Los pesos para los próximos saltos de ruta calculada y los siguientes saltos estáticos son 2 y 3, respectivamente. Suponiendo que los siguientes saltos para rutas calculadas son , , y , y que el siguiente salto para ruta estática es , los pesos se aplican de la siguiente manera:comp_nh1comp_nh2comp_nh3static_nh
|
Siguiente salto |
Peso |
|---|---|
|
comp_nh1 |
2 |
|
comp_nh2 |
2 |
|
comp_nh3 |
2 |
|
static_nh |
9 |
Ejemplo 2
En el ejemplo 2, tanto la ruta de acceso principal como la secundaria pueden ser de tipo informático y pueden tener sus propios perfiles de proceso.
[edit protocols source-packet-routing]
compute-profile compute_profile_green{
include-any green
maximum-segment-list-depth 5
}
compute-profile compute_profile_red{
include-any red
maximum-segment-list-depth 8
}
Ejemplo 3
En el ejemplo 3, cuando el proceso se menciona en una ruta principal o secundaria, se obtiene el cálculo local de una ruta al destino sin restricciones ni otros parámetros para el cálculo.
[edit protocols source-packet-routing]
source-routing-path srte_colored_policy1 {
to 10.5.5.5
color 5
binding-sid 10001
primary {
compute_segment1 {
compute
}
}
}
Etiqueta de enrutamiento de segmento estático Ruta conmutada
La arquitectura de enrutamiento por segmentos permite que los dispositivos de entrada en una red central dirijan el tráfico a través de rutas explícitas. Puede configurar estas rutas mediante listas de segmentos para definir las rutas que debe tomar el tráfico entrante. El tráfico entrante puede estar etiquetado o ser tráfico IP, lo que hace que la operación de reenvío en el dispositivo de entrada sea un intercambio de etiquetas o una búsqueda basada en el destino.
- Descripción del LSP de enrutamiento de segmentos estáticos en redes MPLS
- Ejemplo: Configuración de la ruta conmutada de etiquetas de enrutamiento de segmentos estáticos
Descripción del LSP de enrutamiento de segmentos estáticos en redes MPLS
El enrutamiento de paquetes de origen o enrutamiento de segmentos es una arquitectura de plano de control que permite a un enrutador de entrada dirigir un paquete a través de un conjunto específico de nodos y vínculos en la red sin depender de los nodos intermedios de la red para determinar la ruta real que debe tomar.
- Introducción a los LSP de enrutamiento por segmentos
- Ventajas de usar los LSP de enrutamiento por segmentos
- LSP de enrutamiento de segmentos estáticos coloreados
- LSP de enrutamiento de segmentos estáticos no coloreados
- Aprovisionamiento de LSP de enrutamiento por segmentos estáticos
- Limitaciones del LSP del enrutamiento de segmentos estáticos
- Creación dinámica de LSP de enrutamiento por segmentos
- Mapeo basado en colores de servicios VPN
- Plantillas de túnel para LSP de enrutamiento de segmentos iniciado por PCE
Introducción a los LSP de enrutamiento por segmentos
El enrutamiento por segmentos aprovecha el paradigma del enrutamiento de origen. Un dispositivo dirige un paquete a través de una lista ordenada de instrucciones, llamadas segmentos. Un segmento puede representar cualquier instrucción, topológica o basada en servicios. Un segmento puede tener una semántica local a un nodo de enrutamiento de segmento o a un nodo global dentro de un dominio de enrutamiento de segmento. El enrutamiento por segmentos aplica un flujo a través de cualquier ruta topológica y cadena de servicio, mientras mantiene el estado por flujo solo en el dispositivo de entrada al dominio de enrutamiento por segmento. El enrutamiento de segmentos se puede aplicar directamente a la arquitectura MPLS sin cambios en el plano de reenvío. Un segmento se codifica como una etiqueta MPLS. Una lista ordenada de segmentos se codifica como una pila de etiquetas. El segmento a procesar está en la parte superior de la pila. Al completar un segmento, la etiqueta relacionada se abre de la pila.
Los LSP de enrutamiento de segmentos pueden ser de naturaleza dinámica o estática.
|
Dynamic segment routing LSPs—Cuando un controlador externo crea un LSP de enrutamiento de segmento y lo descarga en un dispositivo de entrada mediante extensiones PCEP (Path Computation Element Protocol) o desde una política de enrutamiento de segmento BGP mediante extensiones de enrutamiento de segmento BGP, el LSP se aprovisiona dinámicamente. La lista de segmentos del LSP de enrutamiento de segmentos dinámicos se encuentra en el objeto de ruta explícito (ERO) PCEP o en la directiva de enrutamiento de segmentos BGP del LSP. |
|
Static segment routing LSPs: cuando se crea un LSP de enrutamiento de segmentos en el dispositivo de entrada mediante una configuración local, el LSP se aprovisiona estáticamente. Un LSP de enrutamiento de segmento estático se puede clasificar además como LSP coloreados y no coloreados en función de la configuración de la instrucción en el nivel de jerarquía. Por ejemplo: [edit protocols]
source-packet-routing {
source-routing-path lsp_name {
to destination_address;
color color_value;
binding-sid binding-label;
primary segment_list_1_name weight weight;
...
primary segment_list_n_name weight weight;
secondary segment_list_n_name;
sr-preference sr_preference_value;
}
}
Aquí, cada instrucción primaria y secundaria se refiere a una lista de segmentos. [edit protocols]
source-packet-routing {
segment-list segment_list_name {
hop_1_name label sid_label;
...
hop_n_name label sid_label;
}
}
|
Ventajas de usar los LSP de enrutamiento por segmentos
-
El enrutamiento de segmentos estáticos no depende del estado de reenvío por LSP en los enrutadores de tránsito. Por lo tanto, eliminar la necesidad de aprovisionamiento y mantenimiento por estado de reenvío LSP en el núcleo.
-
Proporcionar mayor escalabilidad a las redes MPLS.
LSP de enrutamiento de segmentos estáticos coloreados
Un LSP de enrutamiento de segmento estático configurado con la instrucción se denomina LSP coloreado.color
- Descripción de los LSP de enrutamiento de segmentos estáticos coloreados
- Lista de segmentos de LSP de enrutamiento de segmentos de color
Descripción de los LSP de enrutamiento de segmentos estáticos coloreados
De manera similar a una política de enrutamiento de segmentos BGP, la ruta de entrada del LSP coloreado se instala en las tablas de enrutamiento o , con una clave para mapear el tráfico IP.inetcolor.0inet6color.0destination-ip-address, color
Un LSP de enrutamiento de segmento de color estático puede tener un SID de enlace, para el cual se instala una ruta en la tabla de enrutamiento.mpls.0 Esta etiqueta SID de enlace se utiliza para asignar tráfico etiquetado al LSP de enrutamiento de segmento. Las puertas de enlace de la ruta se derivan de las configuraciones de la lista de segmentos en las rutas principal y secundaria.
Lista de segmentos de LSP de enrutamiento de segmentos de color
Los LSP de enrutamiento de segmentos estáticos de color ya proporcionan compatibilidad con el modo de etiqueta de primer salto para resolver un LSP. Sin embargo, el modo IP de primer salto no es compatible con los LSP de enrutamiento de segmentos coloreados. A partir de Junos OS versión 19.1R1, se introduce una función de comprobación de confirmación para garantizar que todas las listas de segmentos que contribuyen a las rutas coloreadas tengan la etiqueta mínima presente para todos los saltos. Si no se cumple este requisito, se bloquea la confirmación.
LSP de enrutamiento de segmentos estáticos no coloreados
Un LSP de enrutamiento de segmento estático que está configurado sin la instrucción es un LSP no coloreado.color Al igual que en los túneles de enrutamiento de segmentos PCEP, la ruta de entrada se instala en las tablas de enrutamiento o .inet.3inet6.3
Junos OS admite LSP de enrutamiento de segmentos estáticos no coloreados en enrutadores de entrada. Puede aprovisionar LSP de enrutamiento de segmentos estáticos no coloreados configurando una ruta enrutada de origen y una o más listas de segmentos. Estas listas de segmentos pueden ser utilizadas por varios LSP de enrutamiento de segmentos no coloreados.
- Descripción de los LSP de enrutamiento de segmentos no coloreados
- Lista de segmentos de LSP de enrutamiento de segmentos no coloreados
Descripción de los LSP de enrutamiento de segmentos no coloreados
El LSP de enrutamiento de segmento no coloreado tiene un nombre único y una dirección IP de destino. Se instala una ruta de entrada al destino en la tabla de enrutamiento inet.3 con una preferencia predeterminada de 8 y una métrica de 1. Esta ruta permite que los servicios no coloreados se asignen al segmento LSP de enrutamiento perteneciente al destino. En caso de que el LSP de enrutamiento de segmentos no coloreados no requiera una ruta de entrada, la ruta de entrada se puede deshabilitar. Un LSP de enrutamiento de segmentos no coloreado utiliza una etiqueta SID vinculante para lograr la unión LSP de enrutamiento de segmentos. Esta etiqueta que se puede utilizar para modelar el LSP de enrutamiento de segmento como un segmento que se puede utilizar posteriormente para construir otros LSP de enrutamiento de segmento de manera jerárquica. El tránsito de la etiqueta SID de enlace, de forma predeterminada, tiene una preferencia de 8 y una métrica de 1.
A partir de Junos OS versión 18.2R1, los LSP de enrutamiento de segmentos no coloreados configurados estáticamente en el dispositivo de entrada se notifican al elemento de cálculo de ruta (PCE) a través de una sesión de protocolo de elemento de cálculo de ruta (PCEP). Estos LSP de enrutamiento de segmentos no coloreados pueden tener etiquetas de identificador de servicio de enlace (SID) asociadas. Con esta característica, el PCE puede usar esta etiqueta SID de enlace en la pila de etiquetas para aprovisionar rutas LSP de enrutamiento de segmentos iniciadas por PCE.
Un LSP de enrutamiento de segmentos no coloreados puede tener un máximo de 8 rutas principales. Si hay varias rutas principales operativas, el motor de reenvío de paquetes (PFE) distribuye el tráfico entre las rutas en función de los factores de equilibrio de carga, como el peso configurado en la ruta. Se trata de una ruta múltiple de igual costo (ECMP) si ninguna de las rutas tiene un peso configurado en ellas, o ECMP ponderado si al menos una de las rutas tiene un peso distinto de cero configurado en las rutas. En ambos casos, cuando una o algunas de las rutas fallan, el PFE reequilibra el tráfico sobre las rutas restantes, lo que conduce automáticamente a lograr la protección de la ruta. Un LSP de enrutamiento de segmentos no coloreados puede tener una ruta secundaria para la protección de ruta dedicada. Cuando se produce un error en una ruta principal, el PFE reequilibra el tráfico con las rutas principales funcionales restantes. De lo contrario, el PFE cambia el tráfico a la ruta de respaldo, logrando así la protección de la ruta. Un LSP de enrutamiento de segmentos no coloreados puede especificar una métrica en para sus rutas SID de entrada y enlace.[edit protocols source-packet-routing source-routing-path lsp-name] Varios LSP de enrutamiento de segmentos no coloreados tienen la misma dirección de destino que contribuye al siguiente salto de la ruta de entrada.
Varios LSP de enrutamiento de segmentos no coloreados tienen la misma dirección de destino que contribuye al siguiente salto de la ruta de entrada. Cada ruta, ya sea primaria o secundaria, de cada LSP de enrutamiento de segmento se considera un candidato de puerta de enlace, si la ruta es funcional y el LSP de enrutamiento de segmento tiene la mejor preferencia de todos estos LSP de enrutamiento de segmento. Sin embargo, el número máximo de puertas de enlace que puede contener el salto siguiente no puede superar el límite de múltiples rutas de RPD, que es 128 de forma predeterminada. Se podan los caminos adicionales, primero los caminos secundarios y luego los caminos primarios. Una lista de segmentos determinada puede ser referida varias veces como rutas primarias o secundarias por estos LSP de enrutamiento de segmentos. En este caso, hay varias puertas de enlace, cada una con un ID de túnel LSP de enrutamiento de segmento único. Estas puertas de enlace son distintas, aunque tienen una pila de etiquetas y una interfaz de salida idénticas. Un LSP de enrutamiento de segmento no coloreado y un LSP de enrutamiento de segmento de color también pueden tener la misma dirección de destino. Sin embargo, corresponden a diferentes direcciones de destino para las rutas de entrada, ya que la dirección de destino del LSP del enrutamiento del segmento de color se construye con su dirección de destino y color.
En el caso de que un LSP de enrutamiento de segmento estático no coloreado y un LSP de enrutamiento de segmento creado por PCEP coexistan y tengan la misma dirección para que contribuya a la misma ruta de entrada, si también tienen la misma preferencia. De lo contrario, se instala el LSP de enrutamiento de segmento con la mejor preferencia para la ruta.
Lista de segmentos de LSP de enrutamiento de segmentos no coloreados
Una lista de segmentos consiste en una lista de lúpulos. Estos saltos se basan en la etiqueta SID o en una dirección IP. El número de etiquetas SID de la lista de segmentos no debe superar el límite máximo de lista de segmentos. El enlace máximo de lista de segmentos a un túnel LSP se incrementa de 8 a 128, con un máximo de 1000 túneles por sistema. Se admite un máximo de 128 rutas primarias por LSP de enrutamiento de segmento estático. Puede configurar el límite máximo de lista de segmentos en el nivel jerárquico .[edit protocols source-packet-routing]
Antes de Junos OS versión 19.1R1, para que un LSP de enrutamiento de segmento estático no coloreado fuera utilizable, el primer salto de la lista de segmentos tenía que ser una dirección IP de una interfaz saliente y el segundo a ésimo salto podían ser etiquetas SID.n A partir de Junos OS versión 19.1R1, este requisito no se aplica, ya que el primer salto de los LSP estáticos no coloreados ahora proporciona compatibilidad con etiquetas SID, además de direcciones IP. Con la compatibilidad con la etiqueta de primer salto, se habilita el reenrutamiento rápido (FRR) MPLS y la multiruta ponderada de igual costo para resolver los LSP de enrutamiento de segmentos estáticos no coloreados, similares a los LSP estáticos de color.
Para que el modo de etiqueta de primer salto surta efecto, debe incluir la instrucción global o individualmente para una lista de segmentos, y el primer salto de la lista de segmentos debe incluir tanto la dirección IP como la etiqueta.inherit-label-nexthops Si el primer salto incluye sólo la dirección IP, la instrucción no tiene ningún efecto.inherit-label-nexthops
Puede configurar en cualquiera de las siguientes jerarquías.inherit-label-nexthops La instrucción sólo surte efecto si el primer salto de la lista de segmentos incluye tanto la dirección IP como la etiqueta.inherit-label-nexthops
-
—En el nivel jerárquico.Segment list level
[edit protocols source-packet-routing segment-list segment-list-name] -
—En el nivel jerárquico.Globally
[edit protocols source-packet-routing]
Cuando la instrucción se configura globalmente, tiene prioridad sobre la configuración de nivel de lista de segmentos y la configuración se aplica a todas las listas de segmentos.inherit-label-nexthopsinherit-label-nexthops Cuando la instrucción no está configurada globalmente, sólo las listas de segmentos con etiquetas y dirección IP presentes en el primer salto y configuradas con instrucción se resuelven mediante etiquetas SID.inherit-label-nexthopsinherit-label-nexthops
Para los LSP estáticos dinámicos no coloreados, es decir, los LSP de enrutamiento de segmentos basados en PCEP, la instrucción debe habilitarse globalmente, ya que no se aplica la configuración a nivel de segmento.inherit-label-nexthops
Tabla 1 describe el modo de enrutamiento de segmentos de resolución LSP según la especificación del primer salto.
|
Especificación del primer salto |
Modo de resolución LSP |
|---|---|
|
Solo dirección IP Por ejemplo: segment-list path-1 {
hop-1 ip-address 172.16.12.2;
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
La lista de segmentos se resuelve utilizando la dirección IP. |
|
Solo SID Por ejemplo: segment-list path-2 {
hop-1 label 1000011;
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
La lista de segmentos se resuelve mediante etiquetas SID. |
|
Dirección IP y SID (sin la configuración) Por ejemplo: segment-list path-3 {
hop1 {
label 801006;
ip-address 172.16.1.2;
}
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
De forma predeterminada, la lista de segmentos se resuelve utilizando la dirección IP. |
|
Dirección IP y SID (con la configuración) Por ejemplo: segment-list path-3 {
inherit-label-nexthops;
hop1 {
label 801006;
ip-address 172.16.1.2;
}
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
La lista de segmentos se resuelve mediante etiquetas SID. |
Puede utilizar el comando para ver los LSP diseñados por tráfico de enrutamiento de segmentos no coloreados que tienen varias listas de segmentos instaladas en la tabla de enrutamiento inet.3.show route ip-address protocol spring-te active-path table inet.3
Por ejemplo:
user@host> show route 10.7.7.7 protocol spring-te active-path table inet.3
inet.3: 42 destinations, 59 routes (41 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.7.7.7/32 *[SPRING-TE/8] 00:01:25, metric 1, metric2 0
> to 10.11.1.2 via et-0/0/0.1, Push 801007
to 10.21.1.2 via et-0/0/2.1, Push 801007
to 10.102.1.2 via et-0/0/0.2, Push 801007, Push 801002(top)
to 10.21.1.2 via et-0/0/2.2, Push 801007, Push 801005(top)
to 10.103.1.2 via et-0/0/0.3, Push 801007, Push 801003(top)
to 10.203.1.2 via et-0/0/2.3, Push 801007, Push 801006(top)
to 10.104.1.2 via et-0/0/0.4, Push 801007, Push 801003, Push 801002(top)
to 10.204.1.2 via et-0/0/2.4, Push 801007, Push 801006, Push 801005(top)
El tipo de lista de segmentos de primer salto de un LSP de enrutamiento de segmento estático puede provocar un error en una confirmación si:
-
Las diferentes listas de segmentos de un túnel tienen diferentes tipos de resolución de primer salto. Esto es aplicable a los LSP de enrutamiento de segmentos estáticos coloreados y no coloreados. Sin embargo, esto no se aplica a los LSP basados en PCEP; Se genera un mensaje de registro del sistema para la discrepancia en el tipo de resolución del primer salto en el momento de calcular la ruta.
Por ejemplo:
segment-list path-1 { hop-1 ip-address 172.16.12.2; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } segment-list path-2 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; primary { path-1; path-2; } }Se produce un error en la confirmación del túnel , ya que la ruta 1 está en modo de dirección IP y la ruta 2 está en modo de etiqueta.lsp1
-
El SID de enlace está habilitado para el LSP estático no coloreado cuyo tipo de lista de segmentos es etiqueta SID.
Por ejemplo:
segment-list path-3 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; binding-sid 333; primary { path-3; } }La configuración de SID de enlace sobre la lista de segmentos de etiqueta solo se admite para LSP estáticos de color y no para LSP estáticos sin color.
Aprovisionamiento de LSP de enrutamiento por segmentos estáticos
El aprovisionamiento por segmentos se realiza por enrutador. Para un segmento determinado en un enrutador, se asigna una etiqueta de identificador de servicio único (SID) desde un grupo de etiquetas deseado que puede ser del grupo de etiquetas dinámicas para una etiqueta SID de adyacencia o del bloque global de enrutamiento de segmentos (SRGB) para un SID de prefijo o SID de nodo. La etiqueta SID de adyacencia se puede asignar dinámicamente, que es el comportamiento predeterminado, o asignarse desde un grupo de etiquetas estáticas locales (SRLB). A continuación, se instala una ruta para la etiqueta SID en la tabla mpls.0.
Junos OS permite el enrutamiento de segmentos estáticos LSP configurando la instrucción en el nivel de jerarquía.segment[edit protocols mpls static-label-switched-path static-label-switched-path] Un LSP de segmento estático se identifica mediante una etiqueta SID única que pertenece al grupo de etiquetas estáticas de Junos OS. Puede configurar el grupo de etiquetas estáticas de Junos OS configurando la instrucción en el nivel de jerarquía.static-label-range static-label-range[edit protocols mpls label-range]
Limitaciones del LSP del enrutamiento de segmentos estáticos
-
Actualmente, Junos OS tiene la limitación de que el siguiente salto no se puede generar para enviar etiquetas de profundidad de lista de segmentos más que el máximo. Por lo tanto, una lista de segmentos con más etiquetas SID que el máximo (excluyendo la etiqueta SID del primer salto que se utiliza para resolver el reenvío del siguiente salto) no se puede utilizar para los LSP de enrutamiento de segmentos coloreados o no coloreados. Además, el número real permitido para un LSP de enrutamiento de segmento determinado puede ser incluso inferior al límite máximo, si un servicio MPLS está en el LSP de enrutamiento de segmento o el LSP de enrutamiento de segmento está en un vínculo o una ruta de protección de nodo. En todos los casos, el número total de etiquetas de servicio, etiquetas SID y etiquetas de protección de nodo o vínculo no debe superar la profundidad máxima de la lista de segmentos. Puede configurar el límite máximo de lista de segmentos en el nivel jerárquico.
[edit protocols source-packet-routing]Se pueden unir varios LSP de enrutamiento de segmentos no coloreados con etiquetas SID menores o iguales al máximo para construir un LSP de enrutamiento de segmentos más largo. Esto se denomina unión LSP de enrutamiento de segmentos. Se puede lograr utilizando la etiqueta SID vinculante. -
La unión de LSP de enrutamiento de segmentos se realiza realmente a nivel de ruta. Si un LSP de enrutamiento de segmentos no coloreados tiene varias rutas que son varias listas de segmentos, cada ruta se puede unir independientemente a otro LSP de enrutamiento de segmento no coloreado en un punto de unión. Un LSP de enrutamiento de segmentos no coloreado que se dedica a la costura puede deshabilitar la instalación de la ruta de entrada mediante la configuración de la instrucción en el nivel de jerarquía.
no-ingress[edit protocols source-packet-routing source-routing-path lsp-name] -
Se admite un máximo de 128 rutas principales y 1 ruta secundaria por LSP de enrutamiento de segmento estático no coloreado. Si se produce una infracción en la configuración, se produce un error en la comprobación de confirmación.
-
El enlace máximo de lista de segmentos a un túnel LSP se incrementa de 8 a 128, con un máximo de 1000 túneles por sistema. Se admite un máximo de 128 rutas primarias por LSP de enrutamiento de segmento estático. Como limitación, el soporte máximo del sensor para la ruta LSP es solo 32000.
-
Si alguna lista de segmentos está configurada con más etiquetas que la profundidad máxima de lista de segmentos, la comprobación de confirmación de configuración produce un error.
Creación dinámica de LSP de enrutamiento por segmentos
En las redes de enrutamiento de segmentos que tienen cada dispositivo perimetral de proveedor (PE) conectado a todos los demás dispositivos de PE, se requiere una gran cantidad de configuración para configurar las rutas conmutadas por etiquetas de enrutamiento de segmentos (LSP), aunque es posible que solo se usen unas pocas rutas de enrutamiento de segmentos diseñadas para tráfico (SR-TE). Puede habilitar la creación dinámica trigerred BGP de estos LSP para reducir la cantidad de configuración en dichas implementaciones.
- Configuración de la plantilla LSP de enrutamiento de segmentos dinámicos
- Resolución de LSP de enrutamiento de segmentos dinámicos
- Consideraciones para configurar la creación dinámica de LSP de enrutamiento de segmentos
- Servicios admitidos en los LSP de enrutamiento de segmentos dinámicos
- Comportamiento con varios orígenes de túnel en el enrutamiento de segmentos
- Limitaciones de los LSP de enrutamiento de segmentos dinámicos
Configuración de la plantilla LSP de enrutamiento de segmentos dinámicos
Para configurar la plantilla que permita la creación dinámica de LSP de enrutamiento de segmentos, debe incluir la instrucción spring-te en la jerarquía.spring-te (Dynamic Tunnels)[edit routing-options dynamic-tunnels]
-
A continuación se muestra un ejemplo de configuración para la plantilla LSP de enrutamiento de segmentos dinámicos de color:
[edit routing-options] dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1> color [c1 c2]; <template-name2> color [c3]; <template-name3> color-any; } destination-networks { <dest1>; <dest2>; } } } } -
A continuación se muestra un ejemplo de configuración para la plantilla LSP de enrutamiento de segmentos dinámicos sin color:
dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1>; } destination-networks { <dest1>; <dest2>; } } } }
Resolución de LSP de enrutamiento de segmentos dinámicos
Resolución de LSP de enrutamiento de segmentos dinámicos de color
Cuando a los prefijos BGP se les asigna una comunidad de colores, inicialmente se resuelven mediante la política de ruta general para ese color en particular y, a su vez, se identifica la plantilla SR-TE en la que se debe resolver el prefijo BGP. A continuación, el SID de destino se deriva del atributo next-hop del prefijo de carga del BGP. Por ejemplo, si el siguiente salto del prefijo de carga BGP es una dirección IP que pertenece al dispositivo A, se toma el nodo SID del dispositivo A y se prepara una etiqueta correspondiente y se inserta en la parte inferior de la pila. El prefijo de carga BGP se resuelve en un modo de solo color, donde el nodo SID del dispositivo A está en la parte inferior de la pila de etiquetas final y las etiquetas de ruta SR-TE están en la parte superior.
El nombre final de la plantilla LSP es una combinación de prefijo, color y nombre de túnel; Por ejemplo, .<prefix>:<color>:dt-srte-<tunnel-name> El color del nombre LSP se muestra en formato hexadecimal y el formato del nombre del túnel es similar al de los nombres LSP de túnel activados por RSVP.
Para resolver correctamente una red de destino de color, el color debe tener una asignación de plantilla válida, ya sea a un color específico o a través de la plantilla.color-any Sin una asignación válida, el túnel no se crea y la ruta BGP que solicita resolución sigue sin resolverse.
Resolución de LSP de enrutamiento de segmentos dinámicos sin color
Las rutas generales para los LSP no coloreados se agregan a la tabla de enrutamiento inet.3. El destino del túnel sin color debe configurarse en una configuración diferente con un solo nombre de plantilla en la lista de asignación.spring-te Este nombre de plantilla se utiliza para todas las rutas de túnel que coincidan con cualquiera de las redes de destino configuradas en la misma configuración.spring-te Estos túneles son similares a los túneles RSVP en cuanto a funcionalidad.
El nombre final de la plantilla LSP es una combinación de prefijo y nombre de túnel; Por ejemplo, .<prefix>:dt-srte-<tunnel-name>
Configuración de ejemplo de LSP de enrutamiento de segmentos dinámicos
La plantilla LSP de enrutamiento de segmentos dinámicos siempre lleva una ruta parcial. El SID del nodo del último salto se deriva automáticamente en el momento de la creación del túnel, dependiendo del SID del nodo de la dirección del próximo salto (PNH) del protocolo. La misma plantilla puede ser utilizada por varios túneles a diferentes destinos. En tales casos, la ruta parcial sigue siendo la misma, y solo el último salto cambia dependiendo del PNH. Las plantillas LSP de enrutamiento dinámico de segmentos no son comunes a un solo túnel, por lo que no se puede transportar una ruta completa en él. Puede utilizar una lista de segmentos si se va a utilizar una ruta completa.
LSP de enrutamiento de segmentos dinámicos coloreados
Configuración de ejemplo para LSP de enrutamiento de segmentos dinámicos de color:
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color [101 124];
sr_lsp2 color-any
}
destination-networks {
10.22.44.0/24;
}
}
}
Para la configuración de ejemplo mencionada anteriormente, las entradas de ruta son las siguientes:
-
inetcolor.0 tunnel route: 10.22.44.0-0/24 --> RT_NH_TUNNEL
-
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
-
inetcolor.0 tunnel route:
10.22.44.55-101/64 --> <siguiente-salto>
10.22.44.55-124/64 --> <siguiente-salto>
LSP de enrutamiento de segmentos dinámicos no coloreados
Configuración de ejemplo para LSP de enrutamiento de segmentos dinámicos no coloreados:
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;
}
destination-networks {
10.33.44.0/24;
}
}
}
tunnel2 {
spring-te {
source-routing-path-template {
sr_lsp1;
}
destination-networks {
10.33.44.0/24;
}
}
}
}
Para la configuración de ejemplo mencionada anteriormente, las entradas de ruta son las siguientes:
-
inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(prefijo) -> 10.33.44.55(PNH) LSP template name = LSP1 --- 10.33.44.55:dt-srte-tunnel2
-
inet.3 tunnel route: 10.33.44.55/32 --> <siguiente-salto>
LSP de enrutamiento de segmentos dinámicos no resuelto
Configuración de ejemplo para LSP de enrutamiento de segmentos dinámicos no resueltos:
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color [120 121 122 123];
}
destination-networks {
10.33.44.0/24;
10.1.1.0/24;
}
}
}
Para la configuración de ejemplo mencionada anteriormente, las entradas de ruta son las siguientes:
-
inetcolor.0 tunnel route: 10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0 /24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping: R1(prefijo) -> 10.33.44.55-124(PNH) No se creará el túnel. (No se encontró la plantilla para el color).
Consideraciones para configurar la creación dinámica de LSP de enrutamiento de segmentos
Al configurar la creación dinámica de LSP de enrutamiento de segmentos, tenga en cuenta lo siguiente:
-
Se puede asignar una plantilla con un objeto de color. Cuando la configuración de túnel dinámico incluye una plantilla con un objeto de color, también debe configurar todas las demás plantillas con objetos de color.
spring-teSe supone que todos los destinos están coloreados dentro de esa configuración. -
Una plantilla puede tener una lista de colores definida en ella, o se puede configurar con la opción.
color-anyAmbas opciones pueden coexistir en la misma configuración.spring-teEn tales casos, las plantillas asignadas con colores específicos tienen una mayor preferencia. -
En una configuración, solo se puede definir una plantilla con la opción.
spring-tecolor-any -
El mapeo de color a plantilla se realiza de forma individual. Un color no puede asignarse a varias plantillas.
-
El nombre de la plantilla debe configurarse en la instrucción bajo la jerarquía y debe tener habilitada la opción.
spring-te[edit protocols]primary -
Los destinos coloreados y no coloreados no pueden coexistir en la misma configuración.
spring-te -
No puede configurar las mismas redes de destino, con o sin color, en instrucciones de configuración diferentes .
spring-te -
En la configuración sin color , solo se puede configurar una plantilla sin objeto de color.
spring-te
Servicios admitidos en los LSP de enrutamiento de segmentos dinámicos
Los siguientes servicios son compatibles con los LSP de enrutamiento de segmentos dinámicos de color:
-
VPN de capa 3
-
BGP EVPN
-
Servicios de política de exportación
Los siguientes servicios son compatibles con los LSP de enrutamiento de segmentos dinámicos no coloreados:
-
VPN de capa 3
-
VPN de capa 2
-
Configuraciones de múltiples rutas
Comportamiento con varios orígenes de túnel en el enrutamiento de segmentos
Cuando dos fuentes descargan rutas al mismo destino desde el enrutamiento de segmentos (por ejemplo, túneles de origen estáticos y dinámicos), se utiliza la preferencia de enrutamiento de segmentos para elegir la entrada de ruta activa. Un valor más alto tiene mayor preferencia. En caso de que la preferencia siga siendo la misma, se utiliza la fuente del túnel para determinar la entrada de la ruta.
Limitaciones de los LSP de enrutamiento de segmentos dinámicos
Los LSP dinámicos de SR-TE no admiten las siguientes características y funcionalidades:
-
Túneles de enrutamiento de segmentos IPv6.
-
Túneles estáticos.
-
6PE no es compatible.
-
CSPF distribuida.
-
La tunelización de sBFD y LDP no se admite para los LSP de SR-TE dinámicos ni en una plantilla.
-
Instalar rutas y B-SID en una plantilla.
Mapeo basado en colores de servicios VPN
Puede especificar el color como una restricción de protocolo del próximo salto (además de la dirección IPv4 o IPv6) para resolver túneles de transporte sobre LSP de enrutamiento de segmentos BGP (SR-TE) y de color estático. Esto se denomina resolución de próximo salto del protocolo de IP de color, donde debe configurar un mapa de resolución y aplicarlo a los servicios VPN. Con esta función, puede habilitar la dirección de tráfico basada en color de los servicios VPN de capa 2 y capa 3.
Junos OS admite LSP SR-TE de color asociados a un solo color. La función de asignación basada en colores de los servicios VPN es compatible con LSP de colores estáticos y LSP SR-TE BGP.
- Coloración del servicio VPN
- Especificación del modo de asignación de servicios VPN
- Resolución de próximo salto del protocolo Color-IP
- Respaldo a la resolución del protocolo IP del próximo salto
- Mapeo basado en color de unidifusión etiquetado con BGP a través de SR-TE
- Funciones admitidas y no compatibles para la asignación basada en colores de servicios VPN
Coloración del servicio VPN
En general, a un servicio VPN se le puede asignar un color en el enrutador de salida donde se anuncia la NLRI VPN, o en un enrutador de entrada donde se recibe y procesa la NLRI VPN.
Puede asignar un color a los servicios VPN en diferentes niveles:
-
Por instancia de enrutamiento.
-
Por grupo BGP.
-
Por vecino de BGP.
-
Por prefijo.
Una vez que asigna un color, el color se adjunta a un servicio VPN en forma de comunidad extendida de color BGP.
Puede asignar varios colores a un servicio VPN, denominados servicios VPN multicolor. En tales casos, el último color adjunto se considera como el color del servicio VPN, y todos los demás colores se ignoran.
Los dispositivos de salida o entrada asignan varios colores a través de varias políticas en el siguiente orden:
-
Política de exportación de BGP en el dispositivo de salida.
-
Política de importación de BGP en el dispositivo de entrada.
-
Política de importación de VRF en el dispositivo de entrada.
Los dos modos de coloración del servicio VPN son:
Asignación de color de salida
En este modo, el dispositivo de salida (es decir, el anunciante de la NLRI VPN) es responsable de colorear el servicio VPN. Para habilitar este modo, puede definir una política de enrutamiento y aplicarla en la instancia de enrutamiento, la exportación de grupo o la exportación de vecino de grupo del servicio VPN en el nivel jerárquico .vrf-export[edit protocols bgp] BGP anuncia la NLRI VPN con la comunidad extendida de color especificada.
Por ejemplo:
[edit policy-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-X {
...
vrf-export pol-color ...;
}
O
Cuando aplique la directiva de enrutamiento como una política de exportación de un grupo BGP o vecino de BGP, debe incluir la instrucción en el nivel de BGP, grupo BGP o vecino de BGP para que la directiva surta efecto en la NLRI VPN.vpn-apply-export
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}
Las políticas de enrutamiento se aplican a los NLRI de prefijo VPN de capa 3, NRLI de VPN de capa 2 y NLRI de EVPN. Todas las rutas VPN heredan la comunidad extendida por color, se importan y se instalan en los VRF de destino en uno o varios dispositivos de entrada.
Asignación de color de entrada
En este modo, el dispositivo de entrada (es decir, el receptor de la NLRI VPN) es responsable de colorear el servicio VPN. Para habilitar este modo, puede definir una política de enrutamiento y aplicarla a la instancia de enrutamiento, la importación de grupo o la importación de vecinos de grupo del servicio VPN en el nivel jerárquico .vrf-import[edit protocols bgp] Todas las rutas VPN que coincidan con la política de enrutamiento se adjuntan a la comunidad extendida de color especificada.
Por ejemplo:
[edit routing-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-Y {
...
vrf-import pol-color ...;
}
O
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-color ...;
}
}
Especificación del modo de asignación de servicios VPN
Para especificar modos de asignación de servicios VPN flexibles, debe definir una política mediante la instrucción y hacer referencia a la directiva en la instancia de enrutamiento, la importación de grupo o la importación de vecino de grupo de un servicio VPN en el nivel jerárquico.resolution-mapvrf-import[edit protocols bgp] Todas las rutas VPN que coincidan con la política de enrutamiento se adjuntan con el mapa de resolución especificado.
Por ejemplo:
[edit policy-options]
resolution-map map-A {
<mode-1>;
<mode-2>;
...
}
policy-statement pol-resolution {
term t1 {
from {
[any match conditions];
}
then {
resolution-map map-A;
accept;
}
}
}
Puede aplicar la política de importación a la instancia de enrutamiento del servicio VPN.
[edit routing-instances]
vpn-Y {
...
vrf-import pol-resolution ...;
}
También puede aplicar la directiva de importación a un grupo BGP o vecino de BGP.
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}
Cada modo de asignación de servicios VPN debe tener un nombre único definido en el mapa de resolución. Sólo se admite una entrada de color IP en el mapa de resolución, donde las rutas VPN se resuelven mediante el siguiente salto del protocolo IP coloreado en forma de .ip-address:color
Resolución de próximo salto del protocolo Color-IP
El proceso de resolución del protocolo del siguiente salto se ha mejorado para admitir la resolución del siguiente salto del protocolo IP de color. Para un servicio VPN de color, el proceso de resolución del protocolo del siguiente salto toma un color y un mapa de resolución, crea un siguiente salto de protocolo IP de color en forma de , y resuelve el siguiente salto del protocolo en la tabla de enrutamiento inet6color.0.IP-address:color
Debe configurar una política para admitir la resolución de múltiples rutas de servicios VPN de capa 2, VPN de capa 3 o EVPN de color sobre LSP de color. A continuación, la política debe aplicarse con la tabla RIB relevante como política de importación del solucionador.
Por ejemplo:
[edit policy-options]
policy-statement mpath {
then multipath-resolve;
}
[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.l3vpn-inet6.0 {
inet6color-import mpath;
}
}
resolution {
rib bgp.l2vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib mpls.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.evpn.0 {
inetcolor-import mpath;
}
}
Respaldo a la resolución del protocolo IP del próximo salto
Si un servicio VPN de color no tiene un mapa de resolución aplicado, el servicio VPN ignora su color y recurre a la resolución del protocolo IP del próximo salto. Por el contrario, si a un servicio VPN no coloreado se le aplica un mapa de resolución, el mapa de resolución se ignora y el servicio VPN utiliza la resolución del próximo salto del protocolo IP.
La reserva es un proceso sencillo que va desde los LSP SR-TE coloreados hasta los LSP LDP, mediante el uso de un grupo RIB para que LDP instale rutas en tablas de enrutamiento inet{6}color.0. Una coincidencia de prefijo más larga para el próximo salto de un protocolo IP de color garantiza que si no existe una ruta LSP SR-TE de color, se debe devolver una ruta LDP con una dirección IP coincidente.
Mapeo basado en color de unidifusión etiquetado con BGP a través de SR-TE
A partir de Junos OS versión 20.2R1, BGP etiquetado como unidifusión (BGP-LU) puede resolver rutas IPv4 o IPv6 a través de ingeniería de tráfico de enrutamiento de segmentos (SR-TE) para las familias de direcciones IPv4 e IPv6. BGP-LU admite la asignación de un color de comunidad BGP y la definición de a para SR-TE.resolution map Se construye un protocolo de color del siguiente salto y se resuelve en un túnel SR-TE de color en la tabla o .inetcolor.0inet6color.0 BGP utiliza y tablas para mapeo no basado en color.inet.3inet6.3 Esto le permite anunciar prefijos BGP-LU IPv6 e IPv4 con una dirección IPv6 del próximo salto en redes solo IPv6 donde los enrutadores no tienen ninguna dirección IPv4 configurada. Con esta característica, actualmente admitimos BGP IPv6 LU sobre SR-TE con base IS-IS.
En , el controlador configura 4 túneles de colores en una red central IPv6 configurada con SR-TE.Figura 1 Cada túnel de color toma una ruta diferente al enrutador D de destino dependiendo del mapa de resolución definido. El controlador configura un túnel SR-TE coloreado para la interfaz 2001:db8::3701:2d05 en el enrutador D. BGP importa políticas para asignar un mapa de color y resolución al prefijo recibido 2001:db8::3700:6/128. Según el color de comunidad asignado, BGP-LU resuelve el siguiente salto coloreado para el prefijo BGP IPv6 LU de acuerdo con la política de mapa de resolución asignada.
BGP-LU admite los siguientes escenarios:
-
LU BGP IPv4 sobre BGP IPv4 SR-TE coloreado, con extensiones ISIS/OSPF IPv4 SR.
-
LU BGP IPv4 sobre SR-TE IPv4 estático con y sin color, con extensiones ISIS/OSPF IPv4 SR.
-
LU BGP IPv6 sobre BGP IPv6 SR-TE coloreado, con extensiones ISIS IPv6 SR.
-
LU BGP IPv6 sobre SR-TE IPv6 estático con y sin color, con extensiones ISIS IPv6 SR.
-
Servicios VPN IPv6 de capa 3 con dirección local IPv6 y dirección de vecino IPv6.
-
Servicios VPN IPv6 de capa 3 sobre BGP IPv6 SR-TE, con extensiones ISIS IPv6 SR.
-
Servicios VPN de capa 3 de IPv6 sobre SR-TE IPv6 de color estático y no coloreado, con extensiones de SR IPv6 de ISIS.
Funciones admitidas y no compatibles para la asignación basada en colores de servicios VPN
Las siguientes características y funcionalidades son compatibles con la asignación basada en colores de los servicios VPN:
-
VPN BGP capa 2 (Kompella capa 2 VPN)
-
BGP EVPN
-
Mapa de resolución con una sola opción de color IP.
-
Resolución coloreada del próximo salto de los protocolos IPv4 e IPv6.
-
Base de información de enrutamiento (también conocida como tabla de enrutamiento) reserva basada en grupos a LDP LSP en la tabla de enrutamiento inetcolor.0.
-
Coloreado SR-TE LSP.
-
Plataformas virtuales.
-
Junos OS de 64 bits.
-
Sistemas lógicos.
-
BGP etiquetado como unidifusión.
Las siguientes características y funcionalidades no son compatibles con la asignación basada en colores de los servicios VPN:
-
LSP MPLS de color, como RSVP, LDP, BGP-LU, estáticos.
-
Circuito de capa 2
-
VPN de capa 2 con detección automática de BGP FEC-129 y señalizada por LDP.
-
VPLS
-
MVPN
-
IPv4 e IPv6 mediante resolution-map.
Plantillas de túnel para LSP de enrutamiento de segmentos iniciado por PCE
Puede configurar una plantilla de túnel para que los LSP de enrutamiento de segmentos iniciados por PCE transmitan dos parámetros adicionales para estos LSP: detección de reenvío bidireccional (BFD) y tunelización de LDP.
Cuando se crea un LSP de enrutamiento de segmento iniciado por PCE, el LSP se compara con las instrucciones de política (si las hay) y, si hay una coincidencia, la política aplica la plantilla configurada para ese LSP. La configuración de la plantilla solo se hereda si no la proporciona el origen LSP (PCEP); por ejemplo, métrica.
Para configurar una plantilla:
-
Incluya la instrucción source-routing-path-template en el nivel jerárquico .source-routing-path-template
[edit protocols source-packet-routing]Puede configurar los parámetros adicionales de tunelización BFD y LDP aquí. -
Incluya la instrucción source-routing-path-template-map en el nivel jerárquico para enumerar las instrucciones de política con las que se debe comprobar el LSP iniciado por PCE.https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/source-routing-path-template-map-edit-protocols-source-packet-routing.html
[edit protocols source-packet-routing] -
Defina una política para enumerar los LSP en los que se debe aplicar la plantilla.
La instrucción puede incluir el nombre LSP o la expresión regular LSP mediante las condiciones de coincidencia y .
fromlsplsp-regexEstas opciones son mutuamente excluyentes, por lo que solo puede especificar una opción en un momento dado.La instrucción debe incluir la opción con una acción de aceptación.
thensr-te-templateEsto aplica la plantilla al LSP iniciado por PCE.
Tenga en cuenta lo siguiente al configurar una plantilla para LSP iniciados por PCE:
-
La configuración de la plantilla no se aplica a los LSP de enrutamiento de segmentos configurados estáticamente ni al LSP de enrutamiento de segmentos de ningún otro cliente.
-
La configuración proporcionada por PCEP tiene prioridad sobre la configuración de plantilla.
-
PCEP LSP no hereda la configuración de la lista de segmentos de plantilla.
Ejemplo: Configuración de la ruta conmutada de etiquetas de enrutamiento de segmentos estáticos
En este ejemplo se muestra cómo configurar rutas conmutadas de etiqueta de enrutamiento de segmentos estáticos (LSP) en redes MPLS. Esta configuración ayuda a aportar una mayor escalabilidad a las redes MPLS.
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
-
Siete plataformas de enrutamiento universal 5G serie MX
-
Junos OS versión 18.1 o posterior ejecutándose en todos los enrutadores
Antes de comenzar, asegúrese de configurar las interfaces de dispositivo.
Descripción general
Junos OS configura un conjunto de rutas de enrutamiento de segmentos explícitos en el enrutador de entrada de un túnel de enrutamiento de segmento estático no coloreado configurando la instrucción en el nivel de jerarquía.segment-list[edit protocols source-packet-routing] Puede configurar el túnel de enrutamiento de segmentos configurando la instrucción en el nivel de jerarquía.source-routing-path[edit protocols source-packet-routing] El túnel de enrutamiento de segmentos tiene una dirección de destino y una o más rutas principales y, opcionalmente, rutas secundarias que hacen referencia a la lista de segmentos. Cada lista de segmentos consiste en una secuencia de saltos. Para el túnel de enrutamiento de segmentos estáticos no coloreados, el primer salto de la lista de segmentos especifica una dirección IP de salto siguiente inmediato y el segundo salto a enésimo especifica las etiquetas de identificación de segmento (SID) correspondientes al vínculo o nodo que atraviesa la ruta. La ruta hasta el destino del túnel de enrutamiento de segmentos se instala en la tabla inet.3.
Topología
En este ejemplo, configure VPN de capa 3 en los enrutadores perimetrales del proveedor PE1 y PE5. Configure el protocolo MPLS en todos los enrutadores. El túnel de enrutamiento de segmentos se configura del enrutador PE1 al enrutador PE5 con una ruta principal configurada en el enrutador PE1 y PE5. El enrutador PE1 también está configurado con una ruta secundaria para proteger la ruta. Los enrutadores de tránsito PE2 a PE4 están configurados con etiquetas SID de adyacencia con etiqueta pop y una interfaz de salida.
Configuración
- Configuración rápida de CLI
- Configuración del dispositivo PE1
- Configuración del dispositivo PE2
- Resultados
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.
PE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set interfaces ge-0/0/0 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set interfaces ge-0/0/1 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/5 unit 0 family inet address 10.10.17.1/24 set routing-options autonomous-system 65000 set routing-options forwarding-table export load-balance-policy set routing-options forwarding-table chained-composite-next-hop ingress l3vpn set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.147.211 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.146.181 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols source-packet-routing segment-list sl-15-primary hop-1 ip-address 10.10.13.3 set protocols source-packet-routing segment-list sl-15-primary hop-2 label 1000134 set protocols source-packet-routing segment-list sl-15-primary hop-3 label 1000145 set protocols source-packet-routing segment-list sl-15-backup hop-1 ip-address 10.10.12.2 set protocols source-packet-routing segment-list sl-15-backup hop-2 label 1000123 set protocols source-packet-routing segment-list sl-15-backup hop-3 label 1000134 set protocols source-packet-routing segment-list sl-15-backup hop-4 label 1000145 set protocols source-packet-routing source-routing-path lsp-15 to 192.168.146.181 set protocols source-packet-routing source-routing-path lsp-15 binding-sid 1000999 set protocols source-packet-routing source-routing-path lsp-15 primary sl-15-primary set protocols source-packet-routing source-routing-path lsp-15 secondary sl-15-backup set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options policy-statement load-balance-policy then load-balance per-packet set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/5.0 set routing-instances VRF1 route-distinguisher 192.168.147.211:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/5.0
PE2
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set interfaces ge-0/0/1 unit 0 family mpls set protocols mpls static-label-switched-path adj-23 segment 1000123 set protocols mpls static-label-switched-path adj-23 segment next-hop 10.10.23.3 set protocols mpls static-label-switched-path adj-23 segment pop set protocols mpls static-label-switched-path adj-21 segment 1000221 set protocols mpls static-label-switched-path adj-21 segment next-hop 10.10.12.1 set protocols mpls static-label-switched-path adj-21 segment pop set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
PE3
set interfaces ge-0/0/0 unit 0 family inet address 10.10.13.3/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.3/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.3/24 set interfaces ge-0/0/2 unit 0 family mpls set protocols mpls static-label-switched-path adj-34 segment 1000134 set protocols mpls static-label-switched-path adj-34 segment next-hop 10.10.34.4 set protocols mpls static-label-switched-path adj-34 segment pop set protocols mpls static-label-switched-path adj-32 segment 1000232 set protocols mpls static-label-switched-path adj-32 segment next-hop 10.10.23.2 set protocols mpls static-label-switched-path adj-32 segment pop set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
PE4
set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.4/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.4/24 set interfaces ge-0/0/3 unit 0 family mpls set protocols mpls static-label-switched-path adj-45 segment 1000145 set protocols mpls static-label-switched-path adj-45 segment next-hop 10.10.45.5 set protocols mpls static-label-switched-path adj-45 segment pop set protocols mpls static-label-switched-path adj-43 segment 1000243 set protocols mpls static-label-switched-path adj-43 segment next-hop 10.10.34.3 set protocols mpls static-label-switched-path adj-43 segment pop set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
PE5
set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.5/24 set interfaces ge-0/0/3 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.5/24 set routing-options autonomous-system 65000 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.146.181 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.147.211 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols bfd sbfd local-discriminator 0.0.0.32 minimum-receive-interval 1000 set protocols source-packet-routing segment-list sl-51 hop-1 ip-address 10.10.45.4 set protocols source-packet-routing segment-list sl-51 hop-2 label 1000243 set protocols source-packet-routing segment-list sl-51 hop-3 label 1000232 set protocols source-packet-routing segment-list sl-51 hop-4 label 1000221 set protocols source-packet-routing source-routing-path lsp-51 to 192.168.147.211 set protocols source-packet-routing source-routing-path lsp-51 primary sl-51 set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/4.0 set routing-instances VRF1 route-distinguisher 192.168.146.181:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/4.0
CE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.17.7/24 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
CE2
set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.6/24 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0
Configuración del dispositivo PE1
Procedimiento paso a paso
El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
Para configurar el dispositivo PE1:
-
Configure las interfaces.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set ge-0/0/0 unit 0 family mpls maximum-labels 5 set ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set ge-0/0/1 unit 0 family mpls maximum-labels 5 set ge-0/0/5 unit 0 family inet address 10.10.17.1/24
-
Configure el número y las opciones del sistema autónomo para controlar las opciones de enrutamiento de reenvío de paquetes.
[edit routing-options] set autonomous-system 65000 set forwarding-table export load-balance-policy set forwarding-table chained-composite-next-hop ingress l3vpn
-
Configure las interfaces con el protocolo MPLS y configure el intervalo de etiquetas MPLS.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
Configure el tipo de grupo del mismo nivel, la dirección local, la familia de protocolos para las NLRI en las actualizaciones y la dirección IP de un vecino para el grupo del mismo nivel.
[edit protocols bgp] set group pe type internal set group pe local-address 192.168.147.211 set group pe family inet-vpn unicast set group pe neighbor 192.168.146.181
-
Configure las interfaces de área de protocolo.
[edit protocols ospf] set area 0.0.0.0 interface ge-0/0/0.0 set area 0.0.0.0 interface lo0.0 set area 0.0.0.0 interface ge-0/0/1.0
-
Configure la dirección IPv4 y las etiquetas de las rutas principales y secundarias para las políticas de ingeniería de tráfico de enrutamiento (TE) de protocolo de enrutamiento de paquetes de origen (SPRING).
[edit protocols source-packet-routing segment-list] set sl-15-primary hop-1 ip-address 10.10.13.3 set sl-15-primary hop-2 label 1000134 set sl-15-primary hop-3 label 1000145 set sl-15-backup hop-1 ip-address 10.10.12.2 set sl-15-backup hop-2 label 1000123 set sl-15-backup hop-3 label 1000134 set sl-15-backup hop-4 label 1000145
-
Configure la dirección IPv4 de destino, la etiqueta SID de enlace, la ruta de enrutamiento de origen principal y secundario para el protocolo SPRING.
[edit protocols source-packet-routing source-routing-path] set lsp-15 to 192.168.146.181 set lsp-15 binding-sid 1000999 set lsp-15 primary sl-15-primary set lsp-15 secondary sl-15-backup
-
Configure las opciones de directiva.
[edit policy-options policy-statement] set VPN-A-export term a from protocol ospf set VPN-A-export term a from protocol direct set VPN-A-export term a then community add VPN-A set VPN-A-export term a then accept set VPN-A-export term b then reject set VPN-A-import term a from protocol bgp set VPN-A-import term a from community VPN-A set VPN-A-import term a then accept set VPN-A-import term b then reject set bgp-to-ospf from protocol bgp set bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set bgp-to-ospf then accept set load-balance-policy then load-balance per-packet
-
Configure la información de la comunidad BGP.
[edit policy-options] set community VPN-A members target:65000:1
-
Configure la instancia de enrutamiento VRF1 con el tipo de instancia, la interfaz, el distintivo del enrutador, la importación, la exportación y la etiqueta de tabla de VRF. Configure la política de exportación y la interfaz de área para el protocolo OSPF.
[edit routing-instances VRF1] set instance-type vrf set interface ge-0/0/5.0 set route-distinguisher 192.168.147.211:1 set vrf-import VPN-A-import set vrf-export VPN-A-export set vrf-table-label set protocols ospf export bgp-to-ospf set protocols ospf area 0.0.0.0 interface ge-0/0/5.0
Resultados
Desde el modo de configuración, escriba los comandos , , , y para confirmar la configuración.show interfacesshow policy-optionsshow protocolsshow routing-optionsshow routing-instances Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
[edit]
user@PE1# show
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.12.1/24;
}
family mpls {
maximum-labels 5;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.10.13.1/24;
}
family mpls {
maximum-labels 5;
}
}
}
ge-0/0/5 {
unit 0 {
family inet {
address 10.10.17.1/24;
}
}
}
}
policy-options {
policy-statement VPN-A-export {
term a {
from protocol [ ospf direct ];
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement bgp-to-ospf {
from {
protocol bgp;
route-filter 10.10.0.0/16 orlonger;
}
then accept;
}
policy-statement load-balance-policy {
then {
load-balance per-packet;
}
}
community VPN-A members target:65000:1;
}
routing-instances {
VRF1 {
instance-type vrf;
protocols {
ospf {
area 0.0.0.0 {
interface ge-0/0/5.0;
}
export bgp-to-ospf;
}
}
interface ge-0/0/5.0;
route-distinguisher 192.168.147.211:1;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
vrf-table-label;
}
}
routing-options {
autonomous-system 65000;
forwarding-table {
export load-balance-policy;
chained-composite-next-hop {
ingress {
l3vpn;
}
}
}
}
protocols {
bgp {
group pe {
type internal;
local-address 192.168.147.211;
family inet-vpn {
unicast;
}
neighbor 192.168.146.181;
}
}
mpls {
label-range {
static-label-range 1000000 1000999;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface lo0.0;
interface ge-0/0/1.0;
}
}
source-packet-routing {
segment-list sl-15-primary {
hop-1 ip-address 10.10.13.3;
hop-2 label 1000134;
hop-3 label 1000145;
}
segment-list sl-15-backup {
hop-1 ip-address 10.10.12.2;
hop-2 label 1000123;
hop-3 label 1000134;
hop-4 label 1000145;
}
source-routing-path lsp-15 {
to 192.168.146.181;
binding-sid 1000999;
primary {
sl-15-primary;
}
secondary {
sl-15-backup;
}
}
}
}
Configuración del dispositivo PE2
Procedimiento paso a paso
El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
-
Configure las interfaces.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set ge-0/0/0 unit 0 family mpls set ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set ge-0/0/1 unit 0 family mpls
-
Configure el LSP estático para el protocolo MPLS.
[edit protocols mpls static-label-switched-path] set adj-23 segment 1000123 set adj-23 segment next-hop 10.10.23.3 set adj-23 segment pop set adj-21 segment 1000221 set adj-21 segment next-hop 10.10.12.1 set adj-21 segment pop
-
Configure las interfaces y el rango de etiquetas estáticas para el protocolo MPLS.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
Configure interfaces para el protocolo OSPF.
[edit protocols ospf area 0.0.0.0] set interface ge-0/0/0.0 set interface ge-0/0/1.0
Resultados
Desde el modo de configuración en el enrutador PE2, confirme su configuración introduciendo los comandos y .show interfacesshow protocols Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
[edit]
user@PE2# show
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.12.2/24;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.10.23.2/24;
}
family mpls;
}
}
}
protocols {
mpls {
label-range {
static-label-range 1000000 1000999;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
static-label-switched-path adj-23 {
segment {
1000123;
next-hop 10.10.23.3;
pop;
}
}
static-label-switched-path adj-21 {
segment {
1000221;
next-hop 10.10.12.1;
pop;
}
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
}
}Verificación
Confirme que la configuración funcione correctamente.
- Comprobación de la entrada de ruta de la tabla de enrutamiento inet.3 del enrutador PE1
- Verificación de entradas de tabla de rutas de la tabla de enrutamiento mpls.0 del enrutador PE1
- Verificación del LSP de ingeniería de tráfico SPRING del enrutador PE1
- Verificación de LSP de ingeniería de tráfico SPRING en el enrutador de entrada del enrutador PE1
- Comprobación de las entradas de la tabla de enrutamiento de la tabla de enrutamiento mpls.0 del enrutador PE2
- Verificación del estado de segmentos LSP MPLS estáticos del enrutador PE2
Comprobación de la entrada de ruta de la tabla de enrutamiento inet.3 del enrutador PE1
Propósito
Verifique la entrada de ruta de la tabla de enrutamiento inet.3 del enrutador PE1.
Acción
Desde el modo operativo, ingrese el comando show route table inet.3.
user@PE1> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.146.181/32 *[SPRING-TE/8] 03:09:26, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Push 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, Push 1000123(top)Significado
El resultado muestra las rutas de entrada de los túneles de enrutamiento de segmentos.
Verificación de entradas de tabla de rutas de la tabla de enrutamiento mpls.0 del enrutador PE1
Propósito
Comprobar las entradas de ruta de la tabla de enrutamiento mpls.0
Acción
Desde el modo operativo, ingrese el comando show route table mpls.0.
user@PE1> show route table mpls.0
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:25:52, metric 1
Receive
1 *[MPLS/0] 03:25:52, metric 1
Receive
2 *[MPLS/0] 03:25:52, metric 1
Receive
13 *[MPLS/0] 03:25:52, metric 1
Receive
16 *[VPN/0] 03:25:52
> via lsi.0 (VRF1), Pop
1000999 *[SPRING-TE/8] 03:04:03, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Swap 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Swap 1000145, Push 1000134, Push 1000123(top)
Significado
El resultado muestra las etiquetas SID de los túneles de enrutamiento de segmentos.
Verificación del LSP de ingeniería de tráfico SPRING del enrutador PE1
Propósito
Verifique los LSP de ingeniería de tráfico SPRING en los enrutadores de entrada.
Acción
Desde el modo operativo, ingrese el comando show spring-traffic-engineering overview .
user@PE1> show spring-traffic-engineering overview
Overview of SPRING-TE:
Route preference: 8
Number of LSPs: 1 (Up: 1, Down: 0)
External controllers:
< Not configured >
Significado
El resultado muestra una descripción general de los LSP de ingeniería de tráfico SPRING en el enrutador de entrada.
Verificación de LSP de ingeniería de tráfico SPRING en el enrutador de entrada del enrutador PE1
Propósito
Verifique los LSP de ingeniería de tráfico SPRING en el enrutador de entrada.
Acción
Desde el modo operativo, ingrese el comando show spring-traffic-engineering lsp detail.
user@PE1# show spring-traffic-engineering lsp detail
Name: lsp-15
To: 192.168.146.181
State: Up
Path: sl-15-primary
Outgoing interface: ge-0/0/1.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.13.3
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Path: sl-15-backup
Outgoing interface: ge-0/0/0.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 4
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.12.2
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000123
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 4 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Total displayed LSPs: 1 (Up: 1, Down: 0)Significado
El resultado muestra detalles de los LSP de ingeniería de tráfico SPRING en el enrutador de entrada
Comprobación de las entradas de la tabla de enrutamiento de la tabla de enrutamiento mpls.0 del enrutador PE2
Propósito
Compruebe las entradas de la tabla de enrutamiento mpls.0 de la tabla de enrutamiento PE2.
Acción
Desde el modo operativo, ingrese el comando show route table mpls.0.
user@PE2> show route table mpls.0
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:22:29, metric 1
Receive
1 *[MPLS/0] 03:22:29, metric 1
Receive
2 *[MPLS/0] 03:22:29, metric 1
Receive
13 *[MPLS/0] 03:22:29, metric 1
Receive
1000123 *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000123(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000221 *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, Pop
1000221(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, PopVerificación del estado de segmentos LSP MPLS estáticos del enrutador PE2
Propósito
Verifique el estado de los segmentos MPLS LSP del enrutador PE2.
Acción
Desde el modo operativo, ingrese el comando show mpls static-lsp.
user@PE2> show mpls static-lsp
Ingress LSPs:
Total 0, displayed 0, Up 0, Down 0
Transit LSPs:
Total 0, displayed 0, Up 0, Down 0
Bypass LSPs:
Total 0, displayed 0, Up 0, Down 0
Segment LSPs:
LSPname SID-label State
adj-21 1000221 Up
adj-23 1000123 Up
Total 2, displayed 2, Up 2, Down 0Significado
El resultado muestra el estado de los segmentos LSP MPLS estáticos del enrutador PE2.
S-BFD basado en motor de enrutamiento para ingeniería de tráfico de enrutamiento por segmentos con resolución de etiqueta de primer salto
Puede ejecutar la detección de reenvío bidireccional (S-BFD) sin problemas en rutas conmutadas por etiquetas (LSP) no coloreadas y coloreadas con resolución de etiqueta de primer salto, utilizando S-BFD como un mecanismo rápido para detectar fallas en las rutas.
- 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 basado en RE para ingeniería de tráfico de enrutamiento por segmentos con resolución de etiqueta de primer salto
- Ejemplo
- Compruebe que los LSP estén configurados para túneles de enrutamiento de segmentos estáticos y que el estado de sesión de S-BFD sea visible
- Verificar la ruta del túnel de enrutamiento por segmentos con un salto siguiente primario y un salto siguiente secundario
- Verificar la sesión de 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 estáticos de enrutamiento de segmentos S-BFD para etiquetas de primer salto
- Limitaciones
- Derivación automática del discriminador remoto (RD) para sesión SBFD
Túneles estáticos de enrutamiento de segmentos S-BFD para etiquetas de primer salto
La arquitectura de enrutamiento por segmentos permite a los nodos de entrada en una red central dirigir el tráfico a través de rutas explícitas a través de la red. El siguiente salto de ingeniería de tráfico de enrutamiento por segmentos (TE) es una lista o listas de identificadores de segmento (SID). Estas listas de segmentos representan rutas en la red que desea que tome el tráfico entrante. El tráfico entrante puede estar etiquetado o el 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 TE de enrutamiento por segmentos en la ruta de reenvío.
Puede ejecutar BFD (S-BFD) sin problemas sobre LSP de enrutamiento de segmentos estáticos no coloreados y coloreados con resolución de etiqueta de primer salto, y usar S-BFD como un mecanismo rápido para detectar fallas de ruta y desencadenar la convergencia global. S-BFD requiere menos cambios de estado que BFD, lo que acelera la notificación de errores de ruta.
Dado un túnel de enrutamiento de segmentos con uno o varios LSP primarios y, opcionalmente, un LSP secundario, puede habilitar S-BFD en cualquiera de esos LSP. Si se cae una sesión de S-BFD, el software actualiza la ruta del túnel de enrutamiento de segmentos eliminando los siguientes saltos de los LSP fallidos. Si la etiqueta del primer salto del LSP apunta a más de un siguiente salto inmediato, el núcleo continúa enviando paquetes S-BFD si hay al menos un siguiente salto disponible (la detección de errores de accesibilidad del siguiente salto subyacente debe ser más rápida que la duración del temporizador de detección S-BFD).
Este modelo es compatible con los LSP derivados de la traducción automática.
S-BFD de nivel LSP
Se crea una sesión S-BFD para cada combinación única de etiqueta-stack+address-family. Puede configurar listas de segmentos idénticas y habilitar S-BFD para todas ellas. Las listas de segmentos que tienen combinaciones idénticas de pila de etiquetas + familia de direcciones comparten la misma sesión de S-BFD. La dirección de origen de la sesión de 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 sea enrutable.
La familia de direcciones de un LSP se deriva en función de la familia de direcciones de la dirección "a" del túnel TE de enrutamiento de 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 del LSP no se calcula hasta que S-BFD informa que la ruta está activa.
Parámetros S-BFD
Los siguientes parámetros S-BFD son compatibles con las rutas TE de enrutamiento de segmentos:
-
Discriminador remoto
-
Intervalo mínimo
-
Multiplicador
-
Sin opción de alerta de enrutador
En S-BFD, cada respondedor puede tener múltiples discriminadores. Los discriminadores pueden ser anunciados por IGP a otros enrutadores, o pueden estar configurados estáticamente en estos enrutadores. En un iniciador, se elige un discriminador particular como discriminador remoto para una sesión S-BFD por configuración estática, según 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 S-BFD está habilitado en cada uno de ellos con parámetros diferentes, el valor agresivo de cada parámetro se utiliza en la sesión compartida de S-BFD. Para el parámetro discriminador, 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 está configurada ninguna alerta de enrutador, 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 errores en función de los valores del temporizador configurados, el tiempo de convergencia depende del tiempo de reparación global ().seconds
Derivación automática del discriminador remoto (RD) para sesión SBFD
A partir de Junos OS versión 22.4R1, puede utilizar el discriminador remoto derivado automáticamente para sesiones SBFD para las rutas SR-TE. Con esta característica, no es necesario configurar un elemento en la configuración de SFBD en el dispositivo de entrada o tránsito y un discriminador local coincidente en su punto de conexión respectivo.remote-discriminator En su lugar, el dispositivo de PE de salida ahora aceptará direcciones IP como su discriminador local. Para permitir la dirección IP como discriminador local en BFD, utilice la configuración.set protocols bfd sbfd local-discriminator-ip
También puede usar una plantilla de SBFD común con las configuraciones de SBFD en varias políticas de SR-TE aprovisionadas por el controlador. En estas sesiones de SBFD, Junos OS deriva automáticamente el discriminador remoto del extremo del túnel para que coincida con las políticas de SR-TE.
-
Admitimos la derivación automática de RD solo para puntos de conexión IPv4, no para puntos de conexión IPv6.
-
No se admite la derivación automática de RD para túneles de solo color. Si RD no está configurado (por derivación automática de RD) para túneles de solo color SR-TE configurados estáticamente, el sistema mostrará un error de confirmación. Si RD no está configurado (por 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 basado en RE para ingeniería de tráfico de enrutamiento por segmentos con resolución de etiqueta de primer salto
Para habilitar S-BFD de nivel LSP para una lista de segmentos, configure la instrucción de configuración en la jerarquía y la jerarquía.bfd-liveness-detection [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] [edit protocols source-packet-routing source-routing-path lsp-path-name secondary segment-list-name]
Los siguientes pasos proporcionan la configuración básica y luego el funcionamiento de S-BFD con resolución de etiqueta de primer salto:
Los pasos siguientes describen los contornos 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 que un túnel estático de enrutamiento de segmentos lo utilice como rutas principales y secundarias.
En el enrutador de entrada, configure el túnel de enrutamiento de segmentos estáticos, con varias rutas principales (para el equilibrio de carga) o una ruta principal y una ruta secundaria (para la protección de la ruta). Cada ruta principal o secundaria (LSP) hace referencia a una de las listas de segmentos que ya configuró, creando rutas utilizando los siguientes saltos derivados de las etiquetas de primer salto de los LSP contribuyentes.
En el enrutador de entrada, se habilita el equilibrio de carga por paquete para que las rutas que se resuelven sobre las rutas de entrada y la ruta SID de enlace (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 de segmentos, configure el modo de respuesta S-BFD con un discriminador local D, 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 errores de ruta. Especifique un discriminador remoto D para que coincida con el discriminador S-BFD local del enrutador de salida. Se crea una sesión de iniciador S-BFD con la combinación label-stack+address-family 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 reevalúan 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 inmediatamente siguientes describen el funcionamiento básico:
La sesión del iniciador de S-BFD se ejecuta en modo centralizado en el motor de enrutamiento. El software rastrea los estados ascendentes y descendentes de la sesión S-BFD.
Cuando el estado S-BFD se mueve a UP, el LSP se considera para las rutas relevantes.
En el enrutador de entrada, si el software detecta una sesión S-BFD DOWN, se envía una notificación de sesión inactiva al demonio de enrutamiento (RPD) y RPD elimina el siguiente salto de los LSP fallidos de la ruta del túnel de enrutamiento de segmentos.
La pérdida total de tráfico 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 fallos de S-BFD está determinado por los parámetros de multiplicador e intervalo mínimo de S-BFD. El tiempo de reparación global depende del tiempo de proceso de TE de enrutamiento por segmentos y de la redescarga de las rutas al reenvío.
Las pilas de etiquetas LSP se cambian de la siguiente manera:
El LSP particular se separa de la sesión S-BFD existente. Si la sesión S-BFD existente tiene al menos un LSP que se refiere a ella, se conserva la sesión BFD anterior, pero los parámetros S-BFD se vuelven a evaluar para que se elijan los valores de parámetros agresivos entre las sesiones LSP existentes. Además, el nombre de la sesión S-BFD se actualiza al menos uno si hay un cambio. Si la antigua sesión de S-BFD no tiene más LSP asociados, 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+address-family; si existe tal coincidencia, el LSP se refiere a esa sesión S-BFD existente. La sesión S-BFD se vuelve a evaluar para detectar cualquier cambio en los parámetros o el nombre de la sesión de manera similar a las reevaluaciones del 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 y el multiplicador de una sesión S-BFD determinan el tiempo de detección de fallas para la sesión. El tiempo de reparación también depende del tiempo de reparación global.
El siguiente resultado muestra las instrucciones de configuración que usaría para un LSP coloreado con LSP primarios:
[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 están configuradas para los paquetes S-BFD. Cuando se quita 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 no-router-alert en el enrutador de entrada, la opción router-alert se elimina de las opciones 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, , para realizar un seguimiento de las actividades de BFD: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áticos no coloreado 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;
}
}
}
}
}
Compruebe que los LSP estén configurados para túneles de enrutamiento de segmentos estáticos y que el estado de sesión de S-BFD sea visible
Propósito
Utilice el comando s para mostrar los LSP para túneles de enrutamiento de segmentos estáticos, con estado de sesión S-BFD.how spring-traffic-engineering lsp detail
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 de BFD, cuando aparece el primer LSP con una combinación única de label-stack+address-family, el nombre de la sesión S-BFD utiliza address-family+lsp-name. Si más LSP comparten posteriormente la misma sesión, el nombre de la sesión puede cambiar a address-family+least-lsp-name, sin que ello afecte al estado de la sesión S-BFD. El nombre de la sesión S-BFD también aparece en la salida del comando.show bfd session extensive La salida de cada LSP muestra el estado de S-BFD, así como el nombre de S-BFD al que se refiere, como se muestra en el ejemplo anterior como .BFD status: Up BFD name: V4-sl2 Dado que puede 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 del túnel de enrutamiento por segmentos con un salto siguiente primario y un salto siguiente secundario
Propósito
En el motor de enrutamiento del enrutador de entrada, compruebe la ruta del túnel de enrutamiento de segmentos con un salto siguiente primario y un salto siguiente 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 de 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, compruebe la sesión S-BFD de la ruta secundaria de manera similar.
Configuración del identificador de segmento de adyacencia estática para vínculos de miembro Ethernet agregados mediante LSP estático de un solo salto
En una red en la que se utilizan paquetes Ethernet (AE) agregados, un vínculo agregado podría ser un paquete 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 enlaces miembro 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 dificulta aislar qué enlaces han fallado o están perdiendo el tráfico. Una forma de probar la ruta de reenvío disponible en la red es agregar una ruta conmutada de etiqueta estática (LSP) de un solo salto con el siguiente salto apuntando a un vínculo de miembro específico de la interfaz AE.
La operación de etiqueta predeterminada para los LSP estáticos debe ser pop y forward. Cuando un paquete llega a estas rutas etiquetadas, el paquete se reenvía a un vínculo miembro específico. Se utiliza una etiqueta única para identificar el enlace del 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 abre y el tráfico se reenvía en el vínculo miembro especificado en la configuración. Al reenviar el paquete, se elige un MAC de destino, el Mac de destino es la dirección MAC de la interfaz agregada (seleccionada según la dirección del próximo salto configurada).
Cuando el enlace de miembro deja de funcionar y la interfaz agregada está activa, se elimina la ruta correspondiente a ese vínculo de miembro. Cuando una interfaz agregada deja de funcionar, se eliminan todas las rutas correspondientes a los vínculos miembro de la interfaz agregada. Cuando la interfaz física secundaria está separada de 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 en un estado de reenvío no válido, los paquetes OAM se descartan en el PFE cuando se desconecta la interfaz física secundaria.
Utilice el ejemplo siguiente para configurar un LSP estático de un solo salto para un vínculo de miembro AE.
Defina un rango de etiquetas estáticas.
user@host# set protocols mpls label-range static-label-range 1000000 1048575;Nota:Se recomienda configurar el intervalo predeterminado de etiquetas estáticas de 1000000-1048575 para el LSP estático. Si desea configurar un rango de etiquetas distinto del rango de etiquetas estáticas predeterminado, configure varios rangos.
Cree un LSP estático para el vínculo de miembro AE desde el grupo de bloques locales de enrutamiento de segmentos (SRLB) del rango 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 con etiqueta de tránsito en mpls.0, abre la etiqueta y reenvía el paquete hacia abajo en el siguiente salto. La dirección del siguiente salto es obligatoria para las interfaces de difusión (como ge-, xe-, ae-) y el if-name se utiliza para las interfaces P2P (como so-). 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 del AE.
Las salidas de ejemplo muestran el nombre del vínculo miembro en la siguiente salida de salto:
Mostrar MPLS Static-LSP extensivo
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
mostrar etiqueta de ruta etiqueta-nombre extenso
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 188765184Retraso informático Rutas de enrutamiento de segmentos intradominio e interdominio optimizadas
- Descripción general de las métricas basadas en retrasos para rutas de ingeniería de tráfico
- Beneficios de las métricas basadas en retrasos para el cálculo de rutas
- Descripción general de la computación basada en DCSPF con métricas de retraso para la ruta de SR
- Descripción general de las métricas de retraso para casos de uso entre dominios e intradominios
- Caso de uso de métricas de retraso en redes ópticas
Descripción general de las métricas basadas en retrasos para rutas de ingeniería de tráfico
Aprovechar las métricas dinámicas basadas en retrasos se está convirtiendo en un atributo deseable en las redes modernas. Las métricas basadas en retrasos son esenciales para que un elemento de cálculo de ruta (PCE) calcule rutas de ingeniería de tráfico. Puede usar métricas basadas en retrasos para dirigir los paquetes en las rutas de menor latencia o en la ruta de menor retraso. Para hacer esto, debe medir el retraso en cada enlace y anunciarlo utilizando un protocolo de enrutamiento adecuado (IGP o BGP-LS), de modo que la entrada tenga las propiedades de retraso por enlace en su TED.
Para comprender cómo anunciar el retraso en cada vínculo o activar las mediciones de vínculos, consulte Cómo habilitar la medición del retraso de vínculos y la publicidad en ISIS.
La siguiente secuencia de eventos ocurre cuando se mide, anuncia y calcula la detección de cambios en la red y se calcula la ruta de ingeniería de tráfico 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 TE-métricas extendidas IGP.
- Anuncie los resultados a los controladores centralizados con las extensiones BGP-LS correspondientes.
- Calcule las rutas métricas de latencia acumulativa más cortas (Flex-algo) basadas en IGP.
- Calcule rutas explícitas diseñadas para el tráfico (origen a destino) con las métricas de retraso o latencia acumulada más cortas (SR-TE).
Beneficios de las métricas basadas en retrasos para el cálculo de rutas
- Implemente servicios de valor agregado basados en la latencia más baja en toda la red.
- Mida la latencia por ruta (mínima, máxima, promedio) utilizando métricas basadas en retrasos.
- Dirija los servicios sensibles al retraso (como los servicios VPN o 5G) en rutas optimizadas para SR de latencia ultrabaja.
Descripción general de la computación basada en DCSPF con métricas de retraso para la ruta de SR
Con la característica distribuida Restricted Shortest Path First (CSPF) para el LSP de enrutamiento de segmentos, puede calcular un LSP de enrutamiento de segmentos localmente en el dispositivo de entrada según las restricciones que haya configurado. Con esta característica, los LSP se optimizan en función de las restricciones configuradas y el tipo de métrica (ingeniería de tráfico o IGP). Los LSP se calculan para utilizar las rutas ECMP disponibles al destino con la compresión de pila de etiquetas de enrutamiento de segmentos habilitada o deshabilitada.
Puede configurar CSFP distribuido para que se ejecute en varias cabeceras y realizar cálculos de ruta de forma independiente en cada cabecera. Puede aplicar el perfil de proceso en la ruta de origen (ruta de enrutamiento de paquetes de origen). Si ha configurado un perfil informático optimizado para el promedio de retraso, también puede aplicar adicionalmente una restricción denominada .delay-variation-threshold Cuando configure un valor para , cualquier vínculo que supere el valor de umbral quedará excluido del cálculo de la ruta de acceso.delay-variation-threshold
Para configurar métricas de retraso para el cálculo basado en DCSPF para la ruta de SR, debe habilitar la instrucción de configuración en el nivel de jerarquía [].delayedit protocols source-packet-routing compute-profile profile-name metric-type delay Puede configurar las métricas de retraso, como el mínimo, el máximo, el promedio y el umbral de variación de retardo, para calcular la ruta.
minimum: valor de la métrica de retraso mínimo de TED para calcular la ruta de latencia más baja acumulada.average: valor métrico de retardo promedio de TED para calcular la ruta de latencia más baja acumulada.maximum: valor métrico de retardo máximo de TED para calcular la ruta de latencia más baja acumulada.delay-variation-threshold—Umbral de variación del retardo del vínculo (1..16777215). Cualquier vínculo que exceda el umbral de variación de retardo quedará excluido del cálculo de la ruta. El umbral de variación de retardo es independiente de si está realizando una optimización para mínimo, máximo o promedio. La instrucción de configuración aparece en estos niveles de jerarquía:delay-variation-threshold-
[]
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 las 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 las métricas de retraso para casos de uso entre dominios e intradominios
Para el caso intradominio (la ruta reside dentro de un solo dominio), el retraso del vínculo se tiene en cuenta al realizar el cálculo de la ruta. Las métricas de retraso para el cálculo de rutas de enrutamiento de segmentos se admiten tanto en SID comprimidos como en SID sin comprimir. Si tiene SID sin comprimir, los segmentos de adyacencia para las listas de segmentos se utilizan para producir varias listas de segmentos si hay costos iguales. Puede configurar SID sin comprimir mediante la instrucción configuration en el nivel de jerarquía [].no-label-stack-compressionedit protocols source-packet-routing compute-profile profile-name Esto proporciona una ruta completamente expandida mediante SID de adyacencia. Consulte compute-profile para obtener más información.https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/ref/statement/compute-profile-edit-protocols-source-packet-routing.html
A continuación, se muestra un ejemplo de configuración 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 utilizar las métricas de retardo como mínimo. Mínimo es la configuración predeterminada.
Para el caso de uso entre dominios (varios dominios), donde hay varios sistemas autónomos, puede usar segmentos expresos para configurar retrasos de vínculo para el cálculo de rutas. Los segmentos Express son enlaces que conectan nodos de borde o ASBR. Consulte Configuración del LSP del segmento Express para obtener información sobre los segmentos rápidos.https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/express-segment-lsp-configuration.html Puede configurar el retraso o heredar el retraso del LSP subyacente en el segmento rápido. Puede configurar en el nivel de jerarquía [] y establecer los valores de retrasos mínimos, máximos y medios.delayedit protocols express-segments segment-template template-name metric
Puede configurar métricas de retraso en un segmento rápido 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 los vínculos BGP EPE. Puede configurar un valor para en el nivel de jerarquía [] como se muestra a continuación:delay-metricedit protocols bgp group group-name neighbor ip address egress-te-adj-segment segment-name egress-te-link attribute
[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 siguientes topologías representan un ejemplo de un caso de uso óptico. Las soluciones de protección óptica y restauración hacen que los atributos físicos subyacentes, principalmente la longitud de la ruta, cambien debido a fallas de vínculo y la posterior optimización de la red DWDM.
En la figura, el enlace entre A y C es a través de los nodos ópticos O1 y O3 y tiene una latencia de 10 microsegundos.#id_yvq_j4d_xrb__d296e234 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 redirige a través del nodo óptico O2.#id_yvq_j4d_xrb__d296e237 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 el recálculo de la ruta optimizada para retraso y el enrutador de cabecera redirige 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 redirige y selecciona la ruta A-B-C como se muestra en la topología.
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.