Contenido

Introducción

1. Antecedentes

1.1. Fuera de alcance

1.2. Suposición

1.3. Alcance técnico

1.4. Resumen del documento

Requisito

2. Requisitos del usuario

2.1. Resumen de requisitos

2.2. Componentes Utilizados

Descripción general de la tecnología

3. Routing de segmentos

3.1. ¿Qué es el routing de segmentos?

3.2. Identificadores de segmentos

4. Descripción general de SR-TE

4.1. ¿Qué es SR-TE?

4.2. Política SR-TE

5. FRR TI-LFA

5.1. Overview

5.2. Impacto del método de detección de fallos en FRR

5.3. Prevención de microbucle con SR

6. Superposición de EVPN

6.1.  Ventajas de EVPN

6.1.1. Acceso Ethernet multiinicio y activo

6.2. Tipos de Ruta EVPN

6.2.1. Tipo de ruta 1: ruta de detección automática (AD) de Ethernet

6.2.2. Tipo de ruta 4: ruta de segmento Ethernet

6.3. Conectividad de Host EVPN

7. BoB y equilibrio de carga

7.1. BFD sobre paquete (BoB)

7.2. Equilibrio de carga

7.2.1. Balanceo de Carga de Núcleo con Etiqueta FAT

7.2.2. Balanceo de Carga del Circuito de Conexión

Plantillas de configuración y ejemplos de comandos

8. La solución de diseño completa

8.1. Requisitos de bajo nivel

8.2. Resumen del diseño

8.3. Bloques de diseño

8.4. Topología física de ejemplo

8.5. Detalles de diseño de capa 1

8.5.1. Plantillas de configuración

8.6. Descripción general del diseño de OSPF/SR-TE

8.6.1. Escenario de tráfico normal de SR-TE

8.6.1.1. Plantillas de configuración

8.6.2.  SR-TE para escenarios de conmutación por fallas

8.6.3.  Escenario de conmutación por fallo de link único

8.6.3.1. Plantillas de configuración

8.6.4.  Escenario de conmutación por fallo de enlace doble

8.6.4.1. Plantillas de configuración

8.6.5. Escenario de conmutación por fallo de nodo único

8.6.5.1. Plantillas de configuración

8.6.6. Escenario de conmutación por fallo de nodo doble

8.6.6.1. Plantillas de configuración

8.7. Descripción General del Diseño de BGP/RR

8.7.1. Plantillas de configuración

8.8.  Descripción general del diseño de servicios

8.8.1.  Representación de la pila de etiquetas

8.8.2. Plantillas de configuración

9. Ejemplo de Configuración y Comandos Show

9.1.  Ejemplo de configuración en nodos PE

9.1. Comandos show relevantes en los nodos PE

Troubleshoot

Información Relacionada

Introducción

Este documento describe la guía de diseño detallada con descripciones técnicas basadas en los requisitos de Redes XYZ y también proporciona una plantilla de configuración y configuración de bajo nivel para los casos prácticos de la política de rutas explícitas de ingeniería de tráfico de routing de segmentos (SR-TE) con VPN Ethernet (EVPN) Virtual Private Wired Service (VPWS).

1. Antecedentes

1.1. Fuera de alcance

Este documento no cubre los requisitos de las políticas centralizadas "a demanda" SR-TE que utilizan el controlador XTC, EVPN ELAN, etc., pero se centra solamente en las políticas SR-TE dirigidas por el nodo de cabecera con superposición de VPWS EVPN.

1.2. Suposición

El lector de este documento debe estar familiarizado con los conceptos de IP/MPLS y Ethernet junto con las tecnologías de routing de segmentos e ingeniería de tráfico.

1.3. Alcance técnico

El principal ámbito técnico de este documento se limita a:

- OSPF con FRR TI-LFA

- Políticas SR-TE controladas por cabecera (distribuidas)

- Trayectoria principal explícita y rutas de conmutación por fallas dinámicas basadas en IGP

- VPWS EVPN de un solo enlace

Las plantillas de configuración proporcionadas en este documento se denominan Cisco IOS®-XR 7.5.x.

1.4. Resumen del documento

Tabla 1. Secciones de documentos

Tipo de tema

Nombre del tema

Número de sección

Introducción

Antecedentes

1

Requisito

Requisitos del usuario

2

Descripción general de la tecnología

Routing de segmentos

3

Descripción general de SR-TE

4

FRR TI-LFA

5

Superposición de EVPN

6

BoB y equilibrio de carga

7

Plantillas de configuración

y ejemplos de comandos

La solución de diseño completa

8

Ejemplo de Configuración y Comandos Show

9

Requisito

2. Requisitos del usuario

2.1. Resumen de requisitos

El proveedor de servicios XYZ Networks tiene el requisito de crear una red de campo verde a través de los dispositivos Cisco NCS 5500.

El propósito es llevar un flujo de datos multidifusión (voz, vídeo) como servicio a través de una red de transporte de capa 2 con determinados requisitos, uno de ellos es diseñar el tráfico de rutas a través de la red.

Han preferido SR para etiquetas de transporte, SR-TE para ingeniería de tráfico y EVPN como superposición para proporcionar etiquetas de servicio.

2.2. Componentes Utilizados

El usuario XYZ ha convergido en los routers NCS 5500 y en las tarjetas de línea:

Tabla 2. Requisitos de hardware del proyecto

Nodos PE

PID

Chasis

NCS-5504

MPA/LC que conectan nodos P

NC55-36X100G-A-SE

MPA/LC que conectan nodos CE

NC55-36X100G-A-SE

Nodos P

PID

Chasis

NCS-5508

MPA/LC que conectan otros nodos P

NC55-36X100G-A-SE

MPA/LC que conectan nodos PE

NC55-36X100G-A-SE

Esta sección ofrece una descripción general de las tecnologías que se utilizarán con descripciones breves.

Descripción general de la tecnología

3. Routing de segmentos

3.1. ¿Qué es el routing de segmentos?

Segment Routing es la tecnología MPLS avanzada más reciente que está en proceso de sustituir los protocolos LDP y RSVP-TE tradicionales por la introducción de la distribución de etiquetas y la ingeniería de tráfico bajo un mismo paraguas y hacer que esto suceda solamente a través de los protocolos IGP/BGP de estado de link.

El ruteo de segmentos es un método para reenviar paquetes en la red basado en el paradigma de ruteo de origen. El origen elige una trayectoria y la codifica en el encabezado del paquete como una lista ordenada de segmentos. Los segmentos son un identificador para cualquier tipo de instrucción. Por ejemplo, los segmentos de topología identifican el salto siguiente hacia un destino. Cada segmento se identifica mediante el ID de segmento (SID), que consta de un entero plano sin signo de 20 bits.

3.2. Identificadores de segmentos

Figura 1. SID de nodo SR y SID de adyacencia

Segmentos: El protocolo de gateway interior (IGP) distribuye dos tipos de segmentos: Segmentos de prefijo y segmentos de adyacencia. Cada router (nodo) y cada enlace (adyacencia) tienen un identificador de segmento (SID) asociado.

SID de prefijo: Un segmento de prefijo es un segmento global, por lo que un SID de prefijo es globalmente único dentro del dominio de ruteo de segmento como se ilustra en la Figura 1. Un SID de prefijo se asocia con un prefijo IP. El SID del prefijo se configura manualmente desde el rango de etiquetas del bloque global de routing de segmentos (SRGB) y se distribuye por IS-IS o OSPF. El segmento de prefijo dirige el tráfico a lo largo de la trayectoria más corta hasta su destino.

- Utiliza bloque global de SR (SRGB)

- SRGB anunciado con las capacidades del router TLV - En la configuración, Prefix-SID se puede configurar como un valor absoluto o un índice

- En el anuncio de protocolo, Prefix-SID siempre se codifica como un índice global único. El índice representa un desplazamiento desde la base SRGB, la numeración basada en cero, es decir, 0 es el primer índice. Por ejemplo, el índice 1 à SID es 16,000 + 1 = 16,001

SID de nodo: Un SID de nodo es un tipo especial de SID de prefijo que identifica un nodo específico. Se configura bajo la interfaz de loopback con la dirección de loopback del nodo como prefijo. Un segmento de prefijo es un segmento global, por lo que un SID de prefijo es globalmente único dentro del dominio de ruteo del segmento.

En otras palabras, el segmento de nodo es un segmento de prefijo asociado a un prefijo de host que identifica un nodo.

- Equivalente a un prefijo router-id, que es un prefijo que identifica un nodo

- Node-SID es Prefix-SID con el indicador N establecido en el anuncio

- De forma predeterminada, cada Prefix-SID configurado es un nodo-SID

- El Prefix-SID 'regular' (es decir, no Node-SID) se puede configurar para IS-IS

SID de adyacencia: Un segmento de adyacencia se identifica mediante una etiqueta denominada SID de adyacencia, que representa una adyacencia específica, como una interfaz de salida, a un router vecino. El SID de adyacencia se distribuye por IS-IS o OSPF. El segmento de adyacencia dirige el tráfico a una adyacencia específica. Un segmento de adyacencia es un segmento local, por lo que el SID de adyacencia es localmente único en relación con un router específico.

- Significativo local

- Asignado automáticamente para cada adyacencia

- Siempre codificado como un valor absoluto (es decir, no indizado)

SID de enlace o BSID: Se trata de un SID significativo a nivel local asociado con la política SR. Ayuda a dirigir los paquetes a su política SR asociada. El segmento de enlace es un segmento local que identifica una política SR-TE. Cada política SR-TE se asocia a un ID de segmento de enlace (BSID).

El BSID es una etiqueta local que se asigna automáticamente para cada política SR-TE cuando se crea una instancia de la política SR-TE. BSID se puede utilizar para dirigir el tráfico a la política SR-TE y a través de los límites de dominio, lo que crea políticas SR-TE integrales e integrales.

4. Descripción general de SR-TE

4.1. ¿Qué es SR-TE?

La ingeniería de tráfico de routing de segmentos (SR-TE) transforma el mecanismo de routing de origen sencillo y sin estado de SR en un nivel avanzado para programar y dirigir el tráfico de datos a través de rutas predefinidas que evitan la congestión y proporcionan rutas alternativas, al igual que un mapa de tráfico en directo.

Esto se logra cuando se configuran administrativamente las políticas definidas a través de una combinación de varias restricciones que programan las trayectorias principales y de respaldo desde los nodos de origen a los de destino. El controlador se puede centralizar (SDN) o distribuir (cabecera), lo que depende de los requisitos de la red.

Consideremos la topología presentada en la figura 2. Suponga que el costo de los links son valores predeterminados y que el trayecto más corto para alcanzar D desde A es A-B-C-D pero el trayecto de latencia baja es A-E-F-G-H-D. El operador puede definir la ruta diseñada para el tráfico según el requisito (por ejemplo, Latencia) y expresarla en forma de una lista de ID de segmento (A, E, F, G, H, D). A diferencia de RSVP-TE, el estado de esta política se mantiene solamente en el router A y no en los routers completos que atraviesan los paquetes (es decir, E, F, G y H).

Figura 2 Ejemplo de trayecto definido administrativamente de SR-TE

4.2. Política SR-TE

El routing de segmentos para la ingeniería de tráfico (SR-TE) utiliza una "política" para dirigir el tráfico a través de la red. Una ruta de acceso de política SR-TE se expresa como una lista de segmentos que especifica la ruta, denominada lista de ID de segmento (SID). Cada segmento es una trayectoria de extremo a extremo desde el origen al destino y da instrucciones a los routers en la red para que sigan la trayectoria especificada en lugar de seguir la trayectoria más corta calculada por el IGP. Si un paquete se dirige a una política SR-TE, la lista SID se envía en el paquete por el centro distribuidor. El resto de la red ejecuta las instrucciones incrustadas en la lista SID.

Una política SR-TE se identifica como una lista ordenada (cabecera, color, terminal):

- Terminal - Donde se crea una instancia de la política SR-TE

- Color: valor numérico que distingue entre dos o más políticas a los mismos pares de nodos (cabecera - terminal)

- Terminal: el destino de la política SR-TE

- Cada política SR-TE tiene un valor de color. Cada política entre los mismos pares de nodos requiere un valor de color único.

Una política SR-TE se configura con una o más trayectorias candidatas que incluyen trayectos primarios y de respaldo.

Por ejemplo, la trayectoria principal de la política se puede definir explícitamente con SID de adyacencia y, en caso de escenarios de falla, la trayectoria de respaldo puede ser dinámica de la que se ocupa la métrica IGP.

5. FRR TI-LFA

5.1. Overview

La alternativa independiente del loop de topología (TI-LFA) es una función que protege los enlaces, los nodos y los SRLG. Es fácil de configurar; sólo se necesitan dos líneas de configuración para implementar una configuración TI-LFA simple en el router. No requiere ningún cambio en los protocolos que existen en el router. Figura 3. muestra la ruta de tráfico principal y la ruta de respaldo precalculada por TI-LFA para escenarios de falla de link local y de falla de nodo.

Figura 3. Escenario de conmutación por fallo de link de LFA de TI

Figura 4 Escenario de conmutación por fallas de nodos LFA de TI

Cada nodo y ruta protegidos tiene una trayectoria de respaldo precalculada que se puede habilitar rápidamente. El tiempo de convergencia para una trayectoria protegida es de 50 milisegundos o menos. Esto significa que incluso las aplicaciones más sensibles a la latencia o a la pérdida de paquetes pueden funcionar sin interrupciones en caso de que falle un nodo o un link. TI-LFA calcula la trayectoria de respaldo y quita temporalmente el link o nodo protegido de la base de datos. Después de esto, calcula primero la trayectoria de respaldo con la trayectoria más corta. Esto asegura que el trayecto de respaldo tenga el menor costo de métrica posible mientras evita el trayecto protegido. Si se produce un error, se utiliza un túnel diseñado por tráfico que sigue la ruta de respaldo para el tráfico. Una lista de etiquetas de reparación determina el trayecto para los paquetes que necesitan una nueva ruta a su destino. Una lista de etiquetas de reparación es una pila de etiquetas normal pero sólo se utiliza cuando se produce una falla en la ruta protegida.

5.2. Impacto del método de detección de fallos en FRR

El Fast Reroute para las trayectorias modificadas por tráfico SR-TE se configura como un medio para conmutar el tráfico en caso de escenarios de conmutación por fallas desde la trayectoria principal a las trayectorias de respaldo en un rango de hasta 50 mseg como sea factible. La función de reenrutamiento rápido se configura en el protocolo IGP (OSPF/ISIS). El tiempo de convergencia depende del método por el cual se produce la detección de fallas de link. En el caso de un corte de fibra, la detección es inmediata y la posibilidad de obtener menos de 50 mseg de convergencia es alta. Sin embargo, en caso de que la detección de falla de link deba ser realizada por BFD con un intervalo de 15 mseg (multiplicador x3). El tiempo de convergencia es en su mayoría de más de 50 ms.

5.3. Prevención de microbucle con SR

Los microloops son bucles de paquetes breves que se producen en la red después de un cambio de topología (eventos de link inactivo, link activo o de cambio métrico). Los microloops son causados por la convergencia no simultánea de diferentes nodos en la red. Si los nodos convergen y envían tráfico a un nodo vecino que aún no ha convergido, el tráfico se puede conectar en loop entre estos dos nodos, lo que da como resultado la pérdida de paquetes, la fluctuación y los paquetes fuera de servicio.

La función Segment Routing Microloop Avoidance detecta si es posible que los microloops estén seguidos de un cambio de topología. Si un nodo calcula que un microbucle puede ocurrir en la nueva topología, el nodo crea una trayectoria de política SR-TE libre de loops al destino con el uso de una lista de segmentos. Después de que caduque el temporizador de retraso de actualización RIB, la política SR-TE se reemplaza por trayectorias de reenvío regulares. Hay un temporizador predeterminado para el retardo de actualización de RIB que se encarga TI-LFA.

6. Superposición de EVPN

EVPN es una tecnología diseñada inicialmente para servicios multipunto Ethernet, con capacidades avanzadas de reposición múltiple, con el uso de BGP para distribuir información de alcance de dirección MAC a través de la red MPLS, mientras que aporta las mismas características operativas y de escala de VPN IP a L2VPN. Hoy en día, más allá de las aplicaciones DCI y E-LAN, la familia de soluciones EVPN proporciona una base común para todos los tipos de servicios Ethernet, que incluye E-LINE y E-TREE, así como escenarios de routing y puentes del Data Center. EVPN también proporciona opciones para combinar servicios L2 y L3 en la misma instancia.

EVPN es una solución de próxima generación que proporciona servicios multipunto Ethernet a través de redes MPLS. EVPN funciona en contraste con el servicio de LAN privada virtual (VPLS) que existe, lo que permite el aprendizaje de MAC basado en el plano de control BGP en el núcleo. En EVPN, los PE que participan en las instancias de EVPN aprenden las rutas MAC del usuario en el Plano de Control con el uso del protocolo MP-BGP.

EVPN aporta una serie de ventajas como las mencionadas:

- Redundancia por flujo y equilibrio de carga

- Funcionamiento y aprovisionamiento simplificados

- Reenvío óptimo

- Convergencia Rápida

- Escalabilidad de direcciones MAC

- Soluciones de varios proveedores según la estandarización de IETF

Las direcciones MAC aprendidas en un dispositivo deben aprenderse o distribuirse en los otros dispositivos en una VLAN. La función de aprendizaje de MAC del software EVPN permite la distribución de las direcciones MAC aprendidas en un dispositivo a los otros dispositivos conectados a una red. Las direcciones MAC se aprenden de los dispositivos remotos con el uso de BGP.

En estas secciones, aprende algunas de las ventajas y tipos de ruta de EVPN en general y luego comprende los componentes específicos de la solución que se aplican al diseño de Servicios de Red XYZ.

6.1.  Ventajas de EVPN

L2VPN y L3VPN no solo proporcionan servicios bajo un único paraguas de solución con ayuda de diversos tipos de ruta, las EVPN resuelven dos limitaciones de larga data para los servicios Ethernet en las redes de proveedores de servicios:

- Acceso Ethernet multiinicio y activo

- Red de proveedores de servicios: integración con la oficina central o con el Data Center

6.1.1. Acceso Ethernet multiinicio y activo

La figura muestra la mayor limitación de las soluciones multipunto L2 tradicionales como VPLS.

Figura 5. Acceso completo EVPN

Cuando VPLS se ejecuta en el núcleo, la prevención de loop requiere que PE1/PE2 y PE3/PE4 sólo proporcionen redundancia de un solo activo hacia sus respectivos CE. Tradicionalmente, técnicas como mLACP o protocolos L2 heredados como MST, REP, G.8032, etc. se utilizaban para proporcionar redundancia de acceso de un solo activo.

La misma situación ocurre con Hierarchical-VPLS (H-VPLS), donde el nodo de acceso es responsable de proporcionar acceso H-VPLS único-activo por pseudowire de radio activo y de respaldo (PW).

Los modelos de redundancia de acceso "All-Active" no se pueden implementar, ya que la tecnología VPLS carece de la capacidad para evitar bucles L2 que derivan de los mecanismos de reenvío empleados en el núcleo para ciertas categorías de tráfico. El tráfico de difusión, unidifusión desconocida y multidifusión (BUM) procedente de CE se inunda en todo el núcleo de VPLS y lo reciben todos los PE, que a su vez lo inundan en todos los CE conectados. En nuestro ejemplo, PE1 puede inundar el tráfico BUM de CE1 al Núcleo, y PE2 puede enviarlo de vuelta a CE1 cuando se recibe.

EVPN utiliza técnicas de plano de control basadas en BGP para abordar este problema y habilita modelos de redundancia de acceso Activo-Activo para el acceso Ethernet o H-EVPN.

6.2. Tipos de Ruta EVPN

EVPN define un nuevo BGP NLRI que se utiliza para transportar todas las rutas EVPN. EVPN NLRI se transporta en BGP con el uso de extensiones multiprotocolo con un AFI de 25 (L2VPN) y un SAFI de 70. El anuncio de capacidades BGP se utiliza para garantizar que dos altavoces admitan EVPN NLRI.

Figura 6. EVPN NLRI

A continuación se describen los tipos de ruta EVPN necesarios para esta implementación:

6.2.1. Tipo de ruta 1: ruta de detección automática (AD) de Ethernet

Las rutas de descubrimiento automático de Ethernet (AD) se anuncian por EVI y por ESI. Estas rutas se envían por ES. Llevan la lista de EVI que pertenecen a la ES. El campo ESI se establece en cero cuando un CE está monomotor. Este tipo de ruta se utiliza para una retirada masiva de direcciones MAC, aliasing para el balanceo de carga y Split Horizon Filtering.

6.2.2. Tipo de ruta 4: ruta de segmento Ethernet

Las rutas del segmento Ethernet habilitan la conexión de un dispositivo CE a dos o dispositivos PE. La ruta ES permite la detección de dispositivos PE conectados que están conectados al mismo segmento Ethernet, es decir, la detección de grupos de redundancia. También se utiliza para la elección del reenviador designado (DF).

6.3. Conectividad de Host EVPN

Estos modos EVPN son compatibles:

- Conexión única: permite conectar un dispositivo de borde de usuario (CE) a un dispositivo de borde de proveedor (PE). En este valor ESI es nulo para cada link PE-CE.

- Multihoming (Conexión múltiple): permite conectar un dispositivo de la frontera del usuario (CE) a dos o más dispositivos de la frontera del proveedor (PE) para proporcionar conectividad redundante. No se requiere ningún enlace entre chasis. El dispositivo PE redundante garantiza que no haya interrupción del tráfico cuando se produce una falla de red. Los tipos de multihoming son:

Figura 7 Página de inicio única EVPN

Multihoming - Estos son los tipos de multihoming:

1. Single-Active - En un modo de un solo activo, sólo un único PE entre un grupo de PE conectados al segmento Ethernet específico puede reenviar tráfico hacia y desde ese segmento Ethernet.

Figura 8 EVPN Single-Active

2. Activo-Activo - En el modo activo-activo, todos los PE conectados al segmento Ethernet particular tienen permiso para reenviar tráfico hacia y desde ese segmento Ethernet.

Figura 9. EVPN Dual Activo

7. BoB y equilibrio de carga

7.1. BFD sobre paquete (BoB)

La detección de reenvío bidireccional (BFD) proporciona una detección de fallos de poca carga y corta duración en la ruta entre los motores de reenvío adyacentes. BFD permite utilizar un único mecanismo para la detección de fallas en cualquier medio y en cualquier capa de protocolo, con una amplia gama de tiempos de detección y sobrecarga. La rápida detección de fallas proporciona una reacción inmediata a la falla en el caso de un link o vecino fallido.

Esto desencadenaría que el IGP comience a reenviar el tráfico hacia la trayectoria de respaldo ya calculada con el uso de FRR (en el caso de IGP) y PIC (en el caso de BGP).

En la función BFD Over Bundle (BoB), la sesión IPv4 BFD se ejecuta sobre cada miembro del paquete activo.

Figura 10. Diagrama lógico de BoB

Bundlemgr considera los estados BFD, además de los estados L1/L2 que existen, para determinar la usabilidad del link de miembro. El estado del miembro del paquete es una función de:

Estado L1 (enlace físico)

Estado L2 (LACP)

Estado L3 (BFD)

El agente BFD todavía se ejecuta en la tarjeta de línea. Los estados de BFD de los links de miembro del paquete se consolidan en RP. Los links de miembro deben estar conectados adosados, sin ningún switch L2 en el medio. La función BoB se configura en todas las interfaces Ethernet del paquete a través de la Red XYZ.

7.2. Equilibrio de carga

Equilibrio de carga ECMP por flujo en la red de que se trate se extiende a través de interfaces Ethernet entre paquetes y redes Ethernet dentro del agrupamiento (entre los miembros físicos de una interfaz de agrupamiento). Esto es aplicable en toda la red de PE a PE (balance de carga de núcleo), así como de PE a CE (balance de carga de CA), como se explica.

7.2.1. Balanceo de Carga de Núcleo con Etiqueta FAT

Según el alcance de Red XYZ, debe considerar solamente el Balanceo de Carga ECMP (trayecto múltiple de igual costo) por flujo como se mencionó:

Los routers normalmente equilibran la carga del tráfico basándose en la etiqueta más baja de la pila de etiquetas, que es la misma etiqueta para todos los flujos de un pseudowire determinado. Esto puede conducir a un equilibrio de carga asimétrico. El flujo, en este contexto, se refiere a una secuencia de paquetes que tienen el mismo par de origen y destino. Los paquetes se transportan desde un borde del proveedor de origen (PE) a un PE de borde del proveedor de destino.

El Pseudowire de transporte con detección de flujos (FAT PW) proporciona la capacidad de identificar flujos individuales dentro de un pseudowire y proporciona a los routers la capacidad de utilizar estos flujos para equilibrar la carga del tráfico. Los PW FAT se utilizan para equilibrar la carga del tráfico en el núcleo cuando se utilizan trayectos múltiples de igual costo (ECMP). Se crea una etiqueta de flujo basada en flujos indivisibles de paquetes que ingresan a un pseudowire y se inserta como la etiqueta más baja del paquete. Los routers pueden utilizar la etiqueta de flujo para el balanceo de carga, lo que proporciona una mejor distribución del tráfico entre las trayectorias ECMP o las trayectorias agrupadas de link en el núcleo.

Se agrega una etiqueta adicional a la pila, denominada etiqueta de flujo, que se genera para cada flujo entrante único en el PE. Una etiqueta de flujo es un identificador único que distingue un flujo dentro del PW y se deriva de las direcciones MAC de origen y destino, y las direcciones IP de origen y destino. La etiqueta de flujo contiene el final del conjunto de bits de la pila de etiquetas (EOS). La etiqueta de flujo se inserta después de la etiqueta del VC y antes de la palabra de control (si la hay). El PE de ingreso calcula y reenvía la etiqueta de flujo. La configuración de FAT PW habilita la etiqueta de flujo. El PE de salida descarta la etiqueta de flujo de modo que no se tomen decisiones.

7.2.2. Balanceo de Carga del Circuito de Conexión

Sin embargo, para el balanceo de carga de los miembros de AC Bundle, necesita un enfoque diferente debido a la ausencia de SR-MPLS en esta sección de la red.

El balanceo de carga por flujo aquí se puede lograr cuando los botones de configuración específicos de l2vpn a través de todos los routers PE se modifican explícitamente. Puede ser por SRC/DST MAC o SRC/DST IP según el requisito.

Plantillas de configuración y ejemplos de comandos

8. La solución de diseño completa

Esta sección trata los detalles completos del diseño empapelados por todos los diferentes componentes individuales que se han explicado en secciones anteriores. Esta sección describe la topología y la plantilla de configuración relevante con referencia a Cisco IOS-XR 7.5.x.

8.1. Requisitos de bajo nivel

Para el escenario de tráfico normal, el flujo de tráfico está diseñado para propagarse siempre entre las terminaciones de servicio de PE1 y PE3 y sólo entre PE2 y PE4. El objetivo principal en esta situación es mantener la ruta de tráfico completamente desconectada, como se muestra en la figura 12.

El tráfico afectado aquí sería flujos de multidifusión encapsulados a través de la superposición EVPN. Desde los nodos CE1 y CE2, los flujos de medios multicast (voz/vídeo) se transmiten en los nodos PE1 y PE2 y se transportan a través de la superposición EVPN L2 a los nodos CE3 y CE4 respectivamente después de que se desencapsula en los nodos PE3 y PE4 respectivamente.

Por lo tanto, el par de tráfico de origen-destino se considera PE1-PE3 y PE2-PE4 en adelante en todas las circunstancias, a menos que se mencione lo contrario. Para más detalles sobre los requisitos, véase la subsección 2.2.

8.2. Resumen del diseño

Para lograr los requisitos, OSPF se elige como IGP subyacente según lo deseado por Redes XYZ. Para dirigir el flujo multicast encapsulado a través del par de tráfico de origen-destino a través de la trayectoria deseada, SR-TE debe implementarse entre nodos PE.

Las políticas SR-TE se han diseñado con Trayectorias Explícitas e IGP Dinámicas.

Las Trayectorias Explícitas abarcan:

- Escenario de tráfico normal

- Escenario de conmutación por fallo hasta que las opciones de trayectoria alternativas estén disponibles

Las rutas dinámicas IGP abarcan:

- Ruta de respaldo para el escenario de conmutación por fallas donde las opciones de trayectoria alternativas NO están disponibles

Las funciones como BFD, TI-LFA y Microloop Avoidance se configuran en OSPF como se muestra en las subsecciones de plantillas de configuración.

Para escenarios de tráfico normales, la plantilla de configuración y otros detalles se mencionan en la subsección 8.5.1.

Para los escenarios de failover del tráfico, la plantilla de configuración y otros detalles se mencionan en la subsección 8.5.2.

Aparte de esto, también se tienen en cuenta los requisitos como la prevención de microbucles y menos de 50 milisegundos de convergencia en caso de fallas.

8.3. Bloques de diseño

Esta subsección captura todos los bloques de diseño que posteriormente se abordan a fondo en estas secciones.

Descripción general del diseño (Capa 1):

- El tamaño de MTU en la red XYZ se fija en '9216' con el objetivo de admitir hasta 5 a 6 pilas de etiquetas SR

- 'BFD over Bundle' se implementa con un intervalo de 15 mseg para detectar el corte de fibra inferior a 50 mseg

Descripción General del Diseño OSPF/SR-TE:

- OSPF como protocolo IGP con TI-LFA configurado para proporcionar FRR menos de 50 mseg de tiempo de convergencia

- Capa de Transporte basada en Ruteo de Segmentos como Plano de Reenvío y OSPF como protocolo de ruteo

- En Red XYZ, la ruta explícita de Ingeniería de tráfico de ruteo de segmentos dirige el tráfico en todas las direcciones de trayectoria principal requeridas. En el caso de escenarios de conmutación por fallas de link/nodo, el tráfico es ruteado por un trayecto igp dinámico

- Microloop Avoidance y OSPF Max-Metric también forman parte de este diseño

Descripción General del Diseño BGP/RR:

- Hay dos RR configurados en un clúster para proporcionar redundancia

- La Red XYZ, el proceso BGP en cada PE forma el peering 'IPv4' y 'L2VPN EVPN' con ambos RR por separado

Descripción general del diseño de servicios:

- Las capas de servicio se construyen sobre el plano de control basado en BGP y la EVPN punto a punto de capa 2 (EVPN-VPWS)

- El tráfico de vídeo multidifusión (UDP) se envía encapsulado a través de PW EVPN-VPWS punto a punto

- El equilibrio de carga ECMP se logra mediante la configuración de la etiqueta FAT en la sección EVPN

- El servicio tiene como objetivo admitir hasta 5 a 6 pilas de etiquetas SR que incluyen etiquetas de transporte SR, etiquetas EVPN y etiquetas FAT para equilibrar la carga

8.4. Topología física de ejemplo

La topología física de Redes XYZ se muestra en esta figura. En aras de la simplicidad, sólo se muestran 4 nodos PE y 4 P. Hay dos nodos RR que actúan en clústeres para proporcionar redundancia.

Figura 11. Topología física

8.5. Detalles de diseño de capa 1

En el diseño genérico de capa 1, hay una Ethernet de paquete con al menos dos enlaces de miembro por paquete configurado. Para una detección rápida de la falla del link, elija BFD en lugar de la función Bundle. El intervalo de tiempo puede variar idealmente entre 5 y 15 ms. Depende de la capacidad del hardware para descargar.

Para obtener más información sobre BFD, consulte https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/routing/73x/b-routing-cg-ncs5500-73x/implementing-bfd.html. Tenga en cuenta que esta función sólo debe configurarse en la interfaz Ethernet del paquete y no es necesario configurarla en IGP. El tamaño de MTU se fija en 9216 con el fin de soportar hasta 5 a 6 SR Label-stack.

8.5.1. Plantillas de configuración

Las plantillas de configuración de BFD over Bundle para todos los nodos se muestran aquí:

interface Bundle-Ether <Intf-Number>

bfd address-family ipv4 timers start 60

bfd address-family ipv4 timers nbr-unconfig 60

bfd address-family ipv4 multiplier 3

bfd address-family ipv4 destination <Connected-Intf-IP>

bfd address-family ipv4 fast-detect

bfd address-family ipv4 minimum-interval <Time in msec>

mtu <Value as per requirement>

ipv4 address <Intf IP> <Subnet Mask>>

bundle minimum-active links 1

!

8.6. Descripción general del diseño de OSPF/SR-TE

Todos los routers OSPFv2 en la red se encuentran en el Área 0, por lo que la red gestiona un único dominio IGP.

En el router OSPF, el ruteo de segmentos está habilitado y se configuran las interfaces Ethernet de agrupamiento relevantes. De la misma manera, en Interfaces de agrupamiento, se habilitan los parámetros de tipo de red y reroute rápido. Lo más importante es que una interfaz de loopback está habilitada en modo pasivo con el Prefix-SID configurado.

OSPF es un protocolo de estado de link, por lo que debe ser una prioridad identificar inmediatamente los links descendentes y crear una trayectoria de respaldo es necesaria. Para cuidarlo, se configura BFD over Bundle en Bundle Interface y TI-LFA FRR en OSPF, lo que mantiene el tiempo de convergencia en 50 mseg en caso de escenarios de corte de fibra.

Estas subsecciones describen en detalle los escenarios de conmutación por fallas y normales de las rutas de tráfico:

8.6.1. Escenario de tráfico normal de SR-TE

Para mantener una ruta primaria muy estricta, las políticas SR-TE se deben diseñar con trayectos explícitos de extremo a extremo entre los pares de tráfico de origen-destino mencionados anteriormente. Además, se necesitan varias trayectorias candidatas de preferencia dentro de una política SR-TE para proporcionar provisión para múltiples escenarios de failover.

Esta figura representa los detalles de la red del usuario en consonancia con los bloques de diseño mencionados en la subsección 8.3.

- Enlaces entre nodos PE a P y P a P

- Direcciones de loopback de todos los nodos

- Direcciones de interfaz de todos los nodos

- Dirección de ruta de tráfico normal dirigida por SR-TE

- Superposición de EVPN entre nodos PE

Los RR no se han mostrado intencionalmente para reducir el desorden en la topología.

Los enlaces entre PE y P se han marcado con azul y los vínculos entre P y P se han marcado con color verde. El costo OSPF de los links PE-to-P es 100 y el costo de los links P-to-P es 10.

El flujo de tráfico SR-TE primario se ha marcado con flechas azules entre el par PE1-PE3 y con flechas violetas entre el par PE2-PE4.

Figura 12. Detalles de la topología

8.6.1.1. Plantillas de configuración

Esta subsección contiene las plantillas de configuración relevantes de OSPF/SR-TE para nodos PE1 y PE2, como se indica a continuación:

# PE1 Node: OSPF & SR-TE configs

router ospf CORE

nsr

distribute link-state                Command to distribute OSPF database into SR-TE database

log adjacency changes

router-id <Router-ID-PE1>            OSPF Router-ID

segment-routing mpls

nsf cisco

microloop avoidance segment-routing  Command to enable microloop avoidance with TI-LFA

area 0

interface Bundle-Ether<Intf-Number>  OSPF PE to P Link

cost 100                           OSPF PE to P Metric

authentication keychain <Key-Chain>     Command to enable OSPF Authentication per link

network point-to-point

fast-reroute per-prefix            Commands to enable TI-LFA

fast-reroute per-prefix ti-lfa enable

fast-reroute per-prefix tiebreaker node-protecting index <Index-Value>

prefix-suppression

!

interface Loopback <Loopback-ID-PE1>

passive enable

prefix-sid index <SID-Index-Number1>    OSPF Loopback Prefix SID

Nota: Para configurar el comando Source-Address" GLOBALMENTE O bajo POLICY. Como comportamiento predeterminado, la dirección de origen bajo política reemplaza el comando global.

El comando source address bajo la configuración de ruteo de segmento como se muestra es necesario en escenarios específicos donde, en el mismo PE, como origen de la política SR-TE, necesitamos elegir una dirección de loopback entre múltiples o cuando ISIS y OSPF se ejecutan con loopbacks separados, y necesitamos congelarnos en uno de ellos. De lo contrario, en escenarios normales donde sólo hay un IGP que se ejecuta con un loopback único, la configuración de la dirección de origen es opcional.

segment-routing

global-block 16000 23999   Default SRGB Value (Need not be configured). Needs to be configured only if non-default value is assigned

local-block 15000 15999    Default SRLB Value (Need not be configured). Needs to be configured only if non-default value is assigned

traffic-eng

candidate-paths

all

source-address ipv4

Configure SR-TE source address as OSPF loopback (Global Option)

!

!

segment-list name <SIDLIST1>    Primary/Normal Path SID-LIST1

index <Index ID> mpls adjacency <Remote-IP-Address-Link1>

index <Index ID> mpls adjacency <Remote-IP-Address-Link2>

index <Index ID> mpls adjacency <Remote-IP-Address-Link3>

!

segment-list name <SIDLIST2>    Primary Back Up Path SID-LIST2

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

segment-list name <SIDLIST3>    Secondary Back Up Path SID-LIST3

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

policy <Pol-Name1>

source-address ipv4

 Configure SR-TE source address as OSPF loopback (Policy Specific Option)

color <Color-ID> end-point ipv4 <Destn-PE3>

candidate-paths

preference 50     Tertiary Back Up Path with least preference

dynamic

metric

type igp

!

!

!

preference 100     Secondary Back Up Path with 3rd highest preference

explicit segment-list <SIDLIST3>

!

!

preference 150     Primary Back Up Path with 2nd highest preference

explicit segment-list <SIDLIST2>

!

!

preference 200     Primary/Normal Path with highest preference (Active Path for PE1 in this scenario)

explicit segment-list <SIDLIST1>

!

!

!

!

!

!

# PE2 Node: OSPF & SR-TE configs

router ospf CORE

nsr

distribute link-state                     Command to distribute OSPF database into SR-TE database

log adjacency changes

router-id <Router-ID-PE2>                 OSPF Router-ID

segment-routing mpls

nsf cisco

microloop avoidance segment-routing       Command to enable microloop avoidance with TI-LFA

area 0

interface Bundle-Ether<Intf-Number>     OSPF PE to P Link

cost 100                                OSPF PE to P Metric

authentication keychain <Key-Chain>          Command to enable OSPF Authentication per link

network point-to-point

fast-reroute per-prefix                 Commands to enable TI-LFA

fast-reroute per-prefix ti-lfa enable

fast-reroute per-prefix tiebreaker node-protecting index <Index-Value>

prefix-suppression

!

interface Loopback <Loopback-ID-PE2>

passive enable

prefix-sid index <SID-Index-Number2>         OSPF Loopback Prefix SID

Nota: Se han eliminado los comandos opcionales source address, default SRGB y SRLB.

segment-routing

traffic-eng

!

!

segment-list name <SIDLIST1>    Primary/Normal Path SID-LIST1

index <Index ID> mpls adjacency <Remote-IP-Address-Link1>

index <Index ID> mpls adjacency <Remote-IP-Address-Link2>

index <Index ID> mpls adjacency <Remote-IP-Address-Link3>

!

segment-list name <SIDLIST2>    Primary Back Up Path SID-LIST2

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

segment-list name <SIDLIST3>    Secondary Back Up Path SID-LIST3

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

policy <Pol-Name1>

source-address ipv4

 Configure SR-TE source address as OSPF loopback (Policy Specific Option)

color <Color-ID> end-point ipv4 <Destn-PE4>

candidate-paths

preference 50     Tertiary Back Up Path with least preference

dynamic

metric

type igp

!

!

!

preference 100     Secondary Back Up Path with 3rd highest preference

explicit segment-list <SIDLIST3>

!

!

preference 150     Primary Back Up Path with 2nd highest preference

explicit segment-list <SIDLIST2>

!

!

preference 200     Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)

explicit segment-list <SIDLIST1>

!

!

!

!

!

!

Nota: En la solución mencionada anteriormente, los saltos explícitos de las listas de segmentos se basan en las direcciones IP, ya que, como se menciona aquí, la configuración de la política SR-TE de trayectoria explícita basada en "etiqueta mpls", la validación de trayectoria no funciona para la falla de link remoto en 7.3.x

En caso de que cualquier link remoto, aparte del link local de un nodo PE, falle, la trayectoria sigue siendo válida. Esto es así y no se puede modificar hasta XR 7.5.x

# PE Node: SR-TE configs

router ospf <Process-Name>

address-family ipv4 unicast

area 0

interface <Core BE Intf1>

adjacency-sid absolute <Adj-SID1>

interface <Core BE Intf2>

adjacency-sid absolute < Adj-SID2>

interface <Core BE Intf3>

adjacency-sid absolute < Adj-SID3>

segment-routing

traffic-eng

policy <Pol-Name1>

color <Color-ID> end-point ipv4 <Destn-PE>

candidate-paths

preference 10

explicit segment-list <SIDLIST1>

!

preference 20

dynamic

metric

type igp

!

segment-list name <SIDLIST1>

index 10 mpls label <Adj-SID-Link1>

index 20 mpls label <Adj-SID-Link2>

index 30 mpls label <Adj-SID-Link3>

8.6.2.  SR-TE para escenarios de conmutación por fallas

Para entender los escenarios de conmutación por fallas del tráfico, se debe observar de cerca el tráfico de trayectoria principal bajo condiciones de tráfico normales, como se mencionó en el diagrama de topología en la subsección anterior.

El objetivo principal en el caso de escenarios de failover es mantener la incoherencia de la trayectoria de tráfico en la máxima medida posible dada la infraestructura de topología actual. La Red XYZ tiene requerimientos estrictos para dirigir administrativamente el tráfico a través de nodos específicos en trayectos de respaldo para mantener la máxima separación entre los pares de nodos de origen-destino. Este diseño se realiza para evitar la sobrecarga de los links usados y para mantener el mínimo de links no usados.

Estas sub-secciones muestran los diversos escenarios de failover como link único, link doble, nodo único y nodo doble con la trayectoria de failover que el tráfico toma para mantener la máxima inunicidad.

8.6.3.  Escenario de conmutación por fallo de link único

Este es el escenario de falla de link único donde el link local entre PE1 y P1 falla y el tráfico toma un desvío a través de los nodos P2 y P1 del núcleo. Esto se administra administrativamente a través de la lista de segmentos <SIDLIST1> que forma la ruta de respaldo principal entre nodos PE1 y PE3

Figura 13. Escenario de conmutación por fallo de link único

Discordancia: Para una falla de link único, el número de links comunes compartidos es cero (0) como se muestra en la topología anterior.

8.6.3.1. Plantillas de configuración

Esta subsección contiene las plantillas de configuración relevantes de OSPF/SR-TE para nodos PE1 y PE2, como se indica aquí:

Nota: Las plantillas de configuración OSPF del router de PE1 y PE2 son similares a la situación normal.

# PE1 Node: OSPF & SR-TE configs

segment-routing

traffic-eng

!

!

segment-list name <SIDLIST1>    Primary/Normal Path SID-LIST1

index <Index ID> mpls adjacency <Remote-IP-Address-Link1>

index <Index ID> mpls adjacency <Remote-IP-Address-Link2>

index <Index ID> mpls adjacency <Remote-IP-Address-Link3>

!

segment-list name <SIDLIST2>    Primary Back Up Path SID-LIST2

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

segment-list name <SIDLIST3>    Secondary Back Up Path SID-LIST3

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

policy <Pol-Name1>

source-address ipv4

 Configure SR-TE source address as OSPF loopback (Policy Specific Option)

color <Color-ID> end-point ipv4 <Destn-PE3>

candidate-paths

preference 50     Tertiary Back Up Path with least preference

dynamic

metric

type igp

!

!

!

preference 100     Secondary Back Up Path with 3rd highest preference

explicit segment-list <SIDLIST3>

!

!

preference 150     Primary Back Up Path with 2nd highest preference (Active Path for PE1 in this scenario)

explicit segment-list <SIDLIST2>

!

!

preference 200     Primary/Normal Path with highest preference

explicit segment-list <SIDLIST1>

!

!

!

!

!

!

Nota: Las plantillas de configuración OSPF del router de PE1 y PE2 son similares a la situación normal.

# PE2 Node: OSPF & SR-TE configs

segment-routing

traffic-eng

!

!

segment-list name <SIDLIST1>    Primary/Normal Path SID-LIST1

index <Index ID> mpls adjacency <Remote-IP-Address-Link1>

index <Index ID> mpls adjacency <Remote-IP-Address-Link2>

index <Index ID> mpls adjacency <Remote-IP-Address-Link3>

!

segment-list name <SIDLIST2>    Primary Back Up Path SID-LIST2

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

segment-list name <SIDLIST3>    Secondary Back Up Path SID-LIST3

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

policy <Pol-Name1>

source-address ipv4

 Configure SR-TE source address as OSPF loopback (Policy Specific Option)

color <Color-ID> end-point ipv4 <Destn-PE4>

candidate-paths

preference 50     Tertiary Back Up Path with least preference

dynamic

metric

type igp

!

!

!

preference 100     Secondary Back Up Path with 3rd highest preference

explicit segment-list <SIDLIST3>

!

!

preference 150     Primary Back Up Path with 2nd highest preference

explicit segment-list <SIDLIST2>

!

!

preference 200     Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)

explicit segment-list <SIDLIST1>

!

!

!

!

!

!

8.6.4.  Escenario de conmutación por fallo de enlace doble

Este es el escenario de falla de link doble donde falla el link local entre PE1 y P1 y el link local entre PE2 y P2. El tráfico de PE1 toma un desvío a través de los nodos P2 y P1 de núcleo y el tráfico de PE2 toma un desvío a través de los nodos P1 y P2 de núcleo.

Estos se dirigen administrativamente a través de la respectiva lista de segmentos <SIDLIST2> de PE1 y PE2 que forman las trayectorias de respaldo secundarias entre los nodos PE1 y PE3 y PE2 y PE4 respectivamente.

Figura 14. Escenario de conmutación por fallo de enlace doble

Discordancia: Para una falla de link doble, el número de links comunes compartidos es uno (1) como se muestra en la topología mencionada anteriormente.

8.6.4.1. Plantillas de configuración

Esta subsección contiene las plantillas de configuración relevantes de OSPF/SR-TE para nodos PE1 y PE2, como se indica aquí:

Nota: Las plantillas de configuración OSPF del router de PE1 y PE2 son similares a la situación normal.

# PE1 Node: OSPF & SR-TE configs

#show run router ospf

router ospf CORE

distribute link-state

log adjacency changes

router-id 11.11.11.11

segment-routing mpls

microloop avoidance segment-routing

area 0

interface Bundle-Ether11

cost 100

authentication keychain XYZ-CONT-PE1

network point-to-point

fast-reroute per-prefix

fast-reroute per-prefix ti-lfa enable

fast-reroute per-prefix tiebreaker node-protecting index 200

prefix-suppression

!

interface Bundle-Ether12

cost 100

authentication keychain XYZ-CONT-PE1

network point-to-point

fast-reroute per-prefix

fast-reroute per-prefix ti-lfa enable

fast-reroute per-prefix tiebreaker node-protecting index 200

prefix-suppression

!

interface Loopback0

passive enable

prefix-sid index 11

!

!

!

segment-routing

traffic-eng

!

!

segment-list name <SIDLIST1>    Primary/Normal Path SID-LIST1

index <Index ID> mpls adjacency <Remote-IP-Address-Link1>

index <Index ID> mpls adjacency <Remote-IP-Address-Link2>

index <Index ID> mpls adjacency <Remote-IP-Address-Link3>

!

segment-list name <SIDLIST2>    Primary Back Up Path SID-LIST2

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

segment-list name <SIDLIST3>    Secondary Back Up Path SID-LIST3

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

policy <Pol-Name1>

source-address ipv4

 Configure SR-TE source address as OSPF loopback (Policy Specific Option)

color <Color-ID> end-point ipv4 <Destn-PE3>

candidate-paths

preference 50     Tertiary Back Up Path with least preference

dynamic

metric

type igp

!

!

!

preference 100     Secondary Back Up Path with 3rd highest preference

explicit segment-list <SIDLIST3>

!

!

preference 150     Primary Back Up Path with 2nd highest preference (Active Path for PE1 in this scenario)

explicit segment-list <SIDLIST2>

!

!

preference 200     Primary/Normal Path with highest preference

explicit segment-list <SIDLIST1>

!

!

!

!

!

!

Nota: Las plantillas de configuración OSPF del router de PE1 y PE2 son similares a la situación normal.

# PE2 Node: OSPF & SR-TE configs

segment-routing

traffic-eng

!

!

segment-list name <SIDLIST1>    Primary/Normal Path SID-LIST1

index <Index ID> mpls adjacency <Remote-IP-Address-Link1>

index <Index ID> mpls adjacency <Remote-IP-Address-Link2>

index <Index ID> mpls adjacency <Remote-IP-Address-Link3>

!

segment-list name <SIDLIST2>    Primary Back Up Path SID-LIST2

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

segment-list name <SIDLIST3>    Secondary Back Up Path SID-LIST3

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

policy <Pol-Name1>

source-address ipv4

 Configure SR-TE source address as OSPF loopback (Policy Specific Option)

color <Color-ID> end-point ipv4 <Destn-PE4>

candidate-paths

preference 50     Tertiary Back Up Path with least preference

dynamic

metric

type igp

!

!

!

preference 100     Secondary Back Up Path with 3rd highest preference

explicit segment-list <SIDLIST3>

!

!

preference 150     Primary Back Up Path with 2nd highest preference (Active Path for PE2 in this scenario)

explicit segment-list <SIDLIST2>

!

!

preference 200     Primary/Normal Path with highest preference

explicit segment-list <SIDLIST1>

!

!

!

!

!

!

8.6.5. Escenario de conmutación por fallo de nodo único

Este es el escenario de falla de nodo único donde el nodo P1 falla y el tráfico toma un desvío a través de los nodos P2 y P4 centrales. Esto se administra administrativamente a través de la lista de segmentos <SIDLIST3> que forma la trayectoria de respaldo secundaria entre nodos PE1 y PE3.

Sin embargo, el tráfico entre PE2 y PE4 permanece igual que la ruta principal como se muestra en esta topología.

Figura 15 Escenario de conmutación por fallo de nodo único

Discordancia: Para una falla de nodo único, el número de links comunes compartidos es uno (1) como se muestra en la topología mencionada anteriormente.

8.6.5.1. Plantillas de configuración

Esta subsección contiene las plantillas de configuración relevantes de OSPF/SR-TE para nodos PE1 y PE2, como se indica a continuación:

Nota: Las plantillas de configuración OSPF del router de PE1 y PE2 son similares a la situación normal.

segment-routing

traffic-eng

!

!

segment-list name <SIDLIST1>    Primary/Normal Path SID-LIST1

index <Index ID> mpls adjacency <Remote-IP-Address-Link1>

index <Index ID> mpls adjacency <Remote-IP-Address-Link2>

index <Index ID> mpls adjacency <Remote-IP-Address-Link3>

!

segment-list name <SIDLIST2>    Primary Back Up Path SID-LIST2

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

segment-list name <SIDLIST3>    Secondary Back Up Path SID-LIST3

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

policy <Pol-Name1>

source-address ipv4

 Configure SR-TE source address as OSPF loopback (Policy Specific Option)

color <Color-ID> end-point ipv4 <Destn-PE3>

candidate-paths

preference 50     Tertiary Back Up Path with least preference

dynamic

metric

type igp

!

!

!

preference 100     Secondary Back Up Path with 3rd highest preference (Active Path for PE1 in this scenario)

explicit segment-list <SIDLIST3>

!

!

preference 150     Primary Back Up Path with 2nd highest preference

explicit segment-list <SIDLIST2>

!

!

preference 200     Primary/Normal Path with highest preference

explicit segment-list <SIDLIST1>

!

!

!

!

!

!

Nota: Las plantillas de configuración OSPF del router de PE1 y PE2 son similares a la situación normal.

# PE2 Node: OSPF & SR-TE configs

segment-routing

traffic-eng

!

!

segment-list name <SIDLIST1>    Primary/Normal Path SID-LIST1

index <Index ID> mpls adjacency <Remote-IP-Address-Link1>

index <Index ID> mpls adjacency <Remote-IP-Address-Link2>

index <Index ID> mpls adjacency <Remote-IP-Address-Link3>

!

segment-list name <SIDLIST2>    Primary Back Up Path SID-LIST2

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

segment-list name <SIDLIST3>    Secondary Back Up Path SID-LIST3

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

policy <Pol-Name1>

source-address ipv4

 Configure SR-TE source address as OSPF loopback (Policy Specific Option)

color <Color-ID> end-point ipv4 <Destn-PE4>

candidate-paths

preference 50     Tertiary Back Up Path with least preference

dynamic

metric

type igp

!

!

!

preference 100     Secondary Back Up Path with 3rd highest preference

explicit segment-list <SIDLIST3>

!

!

preference 150     Primary Back Up Path with 2nd highest preference

explicit segment-list <SIDLIST2>

!

!

preference 200     Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)

explicit segment-list <SIDLIST1>

!

!

!

!

!

!

8.6.6. Escenario de conmutación por fallo de nodo doble

Este es el escenario de falla de nodo doble donde los nodos P1 y P3 fallan y el tráfico toma un desvío a través de los nodos P2 y P4 centrales. Esto se administra administrativamente a través de la lista de segmentos <SIDLIST3> que forma la trayectoria de respaldo secundaria entre nodos PE1 y PE3. Dado que las trayectorias explícitas se definen solamente para los dos escenarios mencionados anteriormente, aquí la trayectoria IGP dinámica forma la trayectoria de respaldo terciaria y asume el rol de rutear el tráfico a través de los nodos P2 y P4.

Sin embargo, el tráfico entre PE2 y PE4 permanece igual que la ruta principal como se muestra en esta topología.

Figura 16 Escenario de conmutación por fallas de dos nodos.

Discordancia: Para una falla de nodo doble, el número de links comunes compartidos es uno (1) como se muestra en esta topología.

8.6.6.1. Plantillas de configuración

Esta subsección contiene las plantillas de configuración relevantes de OSPF/SR-TE para nodos PE1 y PE2, como se indica a continuación:

Nota: Las plantillas de configuración OSPF del router de PE1 y PE2 son similares a la situación normal.

# PE1 Node: OSPF & SR-TE configs

segment-routing

traffic-eng

!

!

segment-list name <SIDLIST1>    Primary/Normal Path SID-LIST1

index <Index ID> mpls adjacency <Remote-IP-Address-Link1>

index <Index ID> mpls adjacency <Remote-IP-Address-Link2>

index <Index ID> mpls adjacency <Remote-IP-Address-Link3>

!

segment-list name <SIDLIST2>    Primary Back Up Path SID-LIST2

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

segment-list name <SIDLIST3>    Secondary Back Up Path SID-LIST3

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

policy <Pol-Name1>

source-address ipv4

 Configure SR-TE source address as OSPF loopback (Policy Specific Option)

color <Color-ID> end-point ipv4 <Destn-PE3>

candidate-paths

preference 50     Tertiary Back Up Path with least preference (Active Path for PE1 in this scenario -

Policy chooses Least Cost IGP Back Up Path in absence of Valid Explicit Path)

dynamic

metric

type igp

!

!

!

preference 100     Secondary Back Up Path with 3rd highest preference

explicit segment-list <SIDLIST3>

!

!

preference 150     Primary Back Up Path with 2nd highest preference

explicit segment-list <SIDLIST2>

!

!

preference 200     Primary/Normal Path with highest preference

explicit segment-list <SIDLIST1>

!

!

!

!

!

!

Nota: Las plantillas de configuración OSPF del router de PE1 y PE2 son similares a la situación normal.

# PE2 Node: OSPF & SR-TE configs

segment-routing

traffic-eng

!

!

segment-list name <SIDLIST1>    Primary/Normal Path SID-LIST1

index <Index ID> mpls adjacency <Remote-IP-Address-Link1>

index <Index ID> mpls adjacency <Remote-IP-Address-Link2>

index <Index ID> mpls adjacency <Remote-IP-Address-Link3>

!

segment-list name <SIDLIST2>    Primary Back Up Path SID-LIST2

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

segment-list name <SIDLIST3>    Secondary Back Up Path SID-LIST3

index <Index ID> mpls adjacency <Remote-IP-Address-Link4>

index <Index ID> mpls adjacency <Remote-IP-Address-Link5>

index <Index ID> mpls adjacency <Remote-IP-Address-Link6>

!

policy <Pol-Name1>

source-address ipv4

 Configure SR-TE source address as OSPF loopback (Policy Specific Option)

color <Color-ID> end-point ipv4 <Destn-PE4>

candidate-paths

preference 50     Tertiary Back Up Path with least preference

dynamic

metric

type igp

!

!

!

preference 100     Secondary Back Up Path with 3rd highest preference

explicit segment-list <SIDLIST3>

!

!

preference 150     Primary Back Up Path with 2nd highest preference

explicit segment-list <SIDLIST2>

!

!

preference 200     Primary/Normal Path with highest preference (Active Path for PE2 in this scenario)

explicit segment-list <SIDLIST1>

!

!

!

!

!

!

8.7. Descripción General del Diseño de BGP/RR

Border Gateway Protocol (BGP) es el protocolo que toma las decisiones de ruteo de núcleo en Internet. Mantiene una tabla de redes IP o "prefijos" que designan el alcance de la red entre sistemas autónomos (AS). Se describe como un protocolo de vector de trayectoria. BGP no utiliza métricas tradicionales de protocolo de gateway interior (IGP), pero toma decisiones de routing basadas en rutas, políticas de red y/o conjuntos de reglas. Por esta razón, es más apropiado denominarlo protocolo de alcance que protocolo de ruteo.

MP-BGP se puede utilizar para propagar prefijos de estado de link, VPNv4, IPv6, VPNv4, VPNv6 y EVPN a través de la red. Esto se hace con una configuración del reflector de ruta que forma vecinos iBGP con dispositivos de núcleo, agregación, acceso y SR-PCE.

A través del RR, los prefijos aprendidos de BGP se propagan internamente a través de iBGP. Las rutas BGP nunca se redistribuyen en los IGP. Los Reflectores de Ruta están totalmente aislados del plano de datos y están dedicados a los fines del plano de control.

8.7.1. Plantillas de configuración

Esta subsección contiene las plantillas de configuración relevantes para BGP/RR como se muestra a continuación:

# PE Node: Relevant BGP configs

router bgp <PE-ASN>

address-family l2vpn evpn

!

neighbor-group <RR-EVPN>         Neighbor group of Route Reflector (RR)

remote-as <RR-ASN>

update-source <PE-Self-Loopback>

!

address-family l2vpn evpn      AF L2VPN EVPN Neighborship with RR

maximum-prefix <PREFIX> <PERCENT> warning-only

!

address-family ipv4 rt-filter

!

neighbor <RR1-Loopback>          Neighborship with RR1 using the above neighbor group

use neighbor-group <RR-EVPN>

neighbor <RR2-Loopback>          Neighborship with RR2 using the above neighbor group

use neighbor-group <RR-EVPN>

# RR Nodes: Relevant BGP configs

router bgp <RR-ASN>

address-family l2vpn evpn

!

neighbor-group <PE-EVPN>        Neighbor group of Provider Edge (PE)

remote-as <PE-ASN>

update-source <RR-Self-Loopback>

!

address-family l2vpn evpn      AF L2VPN EVPN Neighborship with PE

route-reflector-client

!

address-family ipv4 rt-filter

!

neighbor <PE1-Loopback>         Neighborship with PE1 using the above neighbor group

use neighbor-group <PE-EVPN>

neighbor <PE2-Loopback>         Neighborship with PE2 using the above neighbor group

use neighbor-group <PE-EVPN>

8.8.  Descripción general del diseño de servicios

Esta subsección describe el servicio de superposición de VPWS de EVPN junto con la representación de la pila de etiquetas soportada y las plantillas de configuración.

EVPN-VPWS es una solución de plano de control BGP para servicios punto a punto. Implementa las técnicas de señalización y encapsulación que establecen una instancia EVPN entre un par de PEs. Tiene la capacidad de reenviar el tráfico de una red a otra sin búsqueda de MAC. El uso de EVPN para VPWS elimina la necesidad de señalizar PW de segmento único y segmentos múltiples para los servicios Ethernet punto a punto. La tecnología EVPN-VPWS funciona en el núcleo IP y MPLS; el núcleo IP soporta el núcleo BGP y MPLS para conmutar paquetes entre los terminales.

8.8.1.  Representación de la pila de etiquetas

El servicio pretende admitir hasta 5 a 6 etiquetas de SR, incluidas etiquetas de transporte SR, etiquetas EVPN y etiquetas FAT para el equilibrio de carga. Este es el número máximo analizado de etiquetas en Escenarios Normales donde el tráfico fluye a través de una Trayectoria Primaria Explícita:

ADJ SID1

ADJ SID2

ADJ SID3

ETIQUETA EVPN

ETIQUETA DE FLUJO (S=1)

Este es el número máximo analizado de etiquetas en Escenarios de Failover donde el tráfico fluye a través de la ruta explícita de respaldo o ruta de respaldo dinámica definida por IGP:

SID1 de TI-LFA

SID2 de TI-LFA

SID3 de TI-LFA

ETIQUETA EVPN

ETIQUETA DE FLUJO (S=1)

8.8.2. Plantillas de configuración

Esta subsección contiene las plantillas de configuración relevantes para EVPN-VPWS como se muestra a continuación:

# PE Node: EVPN configs

evpn

evi <EVI-ID>      Ethernet Virtual Identifier

bgp

rd <RD-Value>

route-target import <RT-Value>

route-target export <RT-Value>

!

load-balancing

flow-label static   Generates bottom-most label (S=1) for load balancing between intra & inter BE end-to-end

!

!

interface <AC-Interface>

l2vpn

pw-class <PW-Class-Name1>

encapsulation mpls

preferred-path sr-te policy <Pol-Name1>           Attaching SR-TE policy as the traffic path of EVPN

!

!

xconnect group <Group-Name>

p2p <P2P-Name>

interface <AC-Subinterface>                  EVPN Attachment Circuit Interface towards CE

neighbor evpn evi <EVI-ID> service <Service-ID> Service ID defined should match at both the end PEs

pw-class <PW-Class-Name1>

!

9. Ejemplo de Configuración y Comandos Show

Esta última sección contiene la configuración relevante y los comandos show de los nodos PE solamente para el escenario de tráfico normal. Estas se capturan aquí alineadas con los parámetros dados en esta figura como referencia que ayuda a entender las plantillas de configuración explicadas en secciones anteriores.

9.1.  Ejemplo de configuración en nodos PE

Figura 17 Topología con parámetros de configuración.

# PE1 Node: OSPF & SR-TE Config

#show run router ospf

router ospf CORE

distribute link-state                     Command to distribute OSPF database into SR-TE database

log adjacency changes

router-id 11.11.11.11                    OSPF Router ID

segment-routing mpls

microloop avoidance segment-routing       Command to enable microloop avoidance with TI-LFA

area 0

interface Bundle-Ether111                OSPF PE to P Link

cost 100                                          OSPF PE to P Metric

authentication keychain XYZ-CONT-PE1         Command to enable OSPF Authentication per link

network point-to-point

fast-reroute per-prefix                 Commands to enable TI-LFA

fast-reroute per-prefix ti-lfa enable

fast-reroute per-prefix tiebreaker node-protecting index 200

prefix-suppression

!

interface Bundle-Ether211

cost 100

authentication keychain XYZ-CONT-PE1

network point-to-point

fast-reroute per-prefix

fast-reroute per-prefix ti-lfa enable

fast-reroute per-prefix tiebreaker node-protecting index 200

prefix-suppression

!

interface Loopback0

passive enable

prefix-sid index 11                     OSPF Loopback Prefix SID

!

!

!

#show run segment-routing

Sat Apr 16 23:22:42.727 UTC

segment-routing

traffic-eng

segment-list PrimaryPath           Primary/Normal Path

index 10 mpls adjacency 10.1.11.0

index 20 mpls adjacency 10.1.3.1

index 30 mpls adjacency 10.3.13.1

!

segment-list PrimaryBackUpPath     Primary Back Up Path

index 10 mpls adjacency 10.2.11.0

index 20 mpls adjacency 10.1.2.0

index 30 mpls adjacency 10.1.3.1

!

segment-list SecondaryBackUpPath        Secondary Back Up Path

index 10 mpls adjacency 10.2.11.0

index 20 mpls adjacency 10.2.4.1

index 30 mpls adjacency 10.3.4.0

!

policy SR-TE_POLICY_PE1-to-PE3     SR-TE Policy Towards PE3

color 10 end-point ipv4 33.33.33.33    SR-TE Policy End-Point PE3 Loopback

candidate-paths

preference 50                    Tertiary Back Up Dynamic IGP Path with 4th highest preference

dynamic

metric

type igp

!

!

!

preference 100               Secondary Back Up Path with 3rd highest preference

explicit segment-list SecondaryBackUpPath

!

!

preference 150               Primary Back Up Path with 2nd highest preference

explicit segment-list PrimaryBackUpPath

!

!

preference 200               Primary and Active Path with highest preference

explicit segment-list PrimaryPath

!

!

!

!

!

!

# PE2 Node: OSPF & SR-TE Config

#show run router ospf

router ospf CORE

distribute link-state                     Command to distribute OSPF database into SR-TE database

log adjacency changes

router-id 22.22.22.22                    OSPF Router ID

segment-routing mpls

microloop avoidance segment-routing       Command to enable microloop avoidance with TI-LFA

area 0

interface Bundle-Ether112                OSPF PE to P Link

cost 100                                OSPF PE to P Metric

authentication keychain XYZ-CONT-PE2

network point-to-point

fast-reroute per-prefix                 Commands to enable TI-LFA

fast-reroute per-prefix ti-lfa enable

fast-reroute per-prefix tiebreaker node-protecting index 200

prefix-suppression

!

interface Bundle-Ether222

cost 100

authentication keychain XYZ-CONT-PE2         Command to enable OSPF Authentication per link

network point-to-point

fast-reroute per-prefix                 Commands to enable TI-LFA

fast-reroute per-prefix ti-lfa enable

fast-reroute per-prefix tiebreaker node-protecting index 200

prefix-suppression

!

interface Loopback0

passive enable

prefix-sid index 22                     OSPF Loopback Prefix SID

!

!

!

#show run segment-routing

Sat Apr 16 23:22:42.727 UTC

segment-routing

traffic-eng

segment-list PrimaryPath           Primary/Normal Path

index 10 mpls adjacency 10.2.12.0

index 20 mpls adjacency 10.2.4.1

index 30 mpls adjacency 10.4.14.1

!

segment-list PrimaryBackUpPath     Primary Back Up Path

index 10 mpls adjacency 10.1.12.0

index 20 mpls adjacency 10.1.2.1

index 30 mpls adjacency 10.2.4.1

!

segment-list SecondaryBackUpPath        Secondary Back Up Path

index 10 mpls adjacency 10.1.12.0

index 20 mpls adjacency 10.1.3.1

index 30 mpls adjacency 10.3.4.1

!

policy SR-TE_POLICY_PE2-to-PE4     SR-TE Policy Towards PE4

color 10 end-point ipv4 44.44.44.44    SR-TE Policy End-Point PE4 Loopback

candidate-paths

preference 50                    Tertiary Back Up Dynamic IGP Path with 4th highest preference

dynamic

metric

type igp

!

!

!

preference 100               Secondary Back Up Path with 3rd highest preference

explicit segment-list SecondaryBackUpPath

!

!

preference 150               Primary Back Up Path with 2nd highest preference

explicit segment-list PrimaryBackUpPath

!

!

preference 200               Primary and Active Path with highest preference

explicit segment-list PrimaryPath

!

!

!

!

!

!

# PE1 Node: BGP Config

#show run router bgp

router bgp 64848

bgp router-id 11.11.11.11       BGP Router-ID

address-family l2vpn evpn

!

neighbor-group RR-EVPN

remote-as 64848

update-source Loopback0

address-family l2vpn evpn      BGP AF L2VPN EVPN

!

!

neighbor 10.10.10.10            Neighbor Route Reflector

use neighbor-group RR-EVPN

!

!

# PE2 Node: BGP Config

#show run router bgp

router bgp 64848

bgp router-id 22.22.22.22       BGP Router-ID

address-family l2vpn evpn

!

neighbor-group RR-EVPN

remote-as 64848

update-source Loopback0

address-family l2vpn evpn      BGP AF L2VPN EVPN

!

!

neighbor 10.10.10.10            Neighbor Route Reflector

use neighbor-group RR-EVPN

!

!

# PE1 Node: EVPN-VPWS Config

evpn

evi 100                    Ethernet Virtual Identifier

bgp

rd 11:11

route-target import 100:100

route-target export 100:100

!

load-balancing                 Generates bottom-most label (S=1) for load balancing between intra & inter BE end-to-end

flow-label static

!

!

interface Bundle-Ether99        Interface Attachment Circuit

ethernet-segment

identifier type 0 00.00.00.00.00.00.00.00.00

!

!

!

# PE2 Node: EVPN-VPWS Config

evpn

evi 100                    Ethernet Virtual Identifier

bgp

rd 11:11

route-target import 100:100

route-target export 100:100

!

load-balancing                 Generates bottom-most label (S=1) for load balancing between intra & inter BE end-to-end

flow-label static

!

!

interface Bundle-Ether99        Interface Attachment Circuit

ethernet-segment

identifier type 0 00.00.00.00.00.00.00.00.00

!

!

!

9.1. Comandos show relevantes en los nodos PE

# PE1 Node: SR-TE Show Command

#show segment-routing traffic-eng policy

Sat Apr 16 23:35:32.731 UTC

SR-TE policy database

---------------------

Color: 10, End-point: 33.33.33.33

Name: srte_c_10_ep_33.33.33.33

Status:

Admin: up  Operational: up for 00:12:54 (since Apr 16 23:22:38.278)

Candidate-paths:

Preference: 200 (configuration) (active)    Active Path (Path in use)

Name: SR-TE_POLICY_PE1-to-PE3

Requested BSID: dynamic

Protection Type: protected-preferred

Maximum SID Depth: 12

Explicit: segment-list PrimaryPath (valid)   Only the Active Path shows valid

Weight: 1, Metric Type: TE

24007 [Adjacency-SID, 10.1.11.0 - 10.1.11.1]

24007 [Adjacency-SID, 10.1.3.0 - 10.1.3.1]

24005 [Adjacency-SID, 10.3.13.0 - 10.3.13.1]

Preference: 150 (configuration)

Name: SR-TE_POLICY_PE1-to-PE3

Requested BSID: dynamic

Protection Type: protected-preferred

Maximum SID Depth: 12

Explicit: segment-list PrimaryBackUpPath (invalid)     All inactive paths show invalid

Weight: 1, Metric Type: TE

Preference: 100 (configuration)

Name: SR-TE_POLICY_PE1-to-PE3

Requested BSID: dynamic

Protection Type: protected-preferred

Maximum SID Depth: 12

Explicit: segment-list SecondaryBackUpPath (invalid)

Weight: 1, Metric Type: TE

Preference: 50 (configuration)                      All inactive paths show invalid

Name: SR-TE_POLICY_PE1-to-PE3

Requested BSID: dynamic

Protection Type: protected-preferred

Maximum SID Depth: 12

Dynamic (invalid)

Metric Type: IGP,   Path Accumulated Metric: 0

Attributes:

Binding SID: 24020

Forward Class: Not Configured

Steering labeled-services disabled: no

Steering BGP disabled: no

IPv6 caps enable: yes

Invalidation drop enabled: no

# PE2 Node: SR-TE Show Command

#show segment-routing traffic-eng policy

Sat Apr 16 23:35:32.731 UTC

SR-TE policy database

---------------------

Color: 10, End-point: 44.44.44.44

Name: srte_c_10_ep_44.44.44.44

Status:

Admin: up  Operational: up for 00:12:54 (since Apr 16 23:22:38.278)

Candidate-paths:

Preference: 200 (configuration) (active)    Active Path (Path in use)

Name: SR-TE_POLICY_PE1-to-PE3

Requested BSID: dynamic

Protection Type: protected-preferred

Maximum SID Depth: 12

Explicit: segment-list PrimaryPath (valid)   Only the Active Path shows valid

Weight: 1, Metric Type: TE

24007 [Adjacency-SID, 10.2.12.0 - 10.2.12.1]

24007 [Adjacency-SID, 10.2.4.0 - 10.2.4.1]

24005 [Adjacency-SID, 10.4.14.0 - 10.4.14.1]

Preference: 150 (configuration)

Name: SR-TE_POLICY_PE1-to-PE3

Requested BSID: dynamic

Protection Type: protected-preferred

Maximum SID Depth: 12

Explicit: segment-list PrimaryBackUpPath (invalid)     All inactive paths show invalid

Weight: 1, Metric Type: TE

Preference: 100 (configuration)

Name: SR-TE_POLICY_PE1-to-PE3

Requested BSID: dynamic

Protection Type: protected-preferred

Maximum SID Depth: 12

Explicit: segment-list SecondaryBackUpPath (invalid)

Weight: 1, Metric Type: TE

Preference: 50 (configuration)                      All inactive paths show invalid

Name: SR-TE_POLICY_PE1-to-PE3

Requested BSID: dynamic

Protection Type: protected-preferred

Maximum SID Depth: 12

Dynamic (invalid)

Metric Type: IGP,   Path Accumulated Metric: 0

Attributes:

Binding SID: 24020

Forward Class: Not Configured

Steering labeled-services disabled: no

Steering BGP disabled: no

IPv6 caps enable: yes

Invalidation drop enabled: no

# PE1 Node: BGP Show Command

#show bgp l2vpn evpn summary

Sun Apr 17 07:16:23.574 UTC

Address Family: L2VPN EVPN

--------------------------

BGP router identifier 11.11.11.11, local AS number 64848

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0x0   RD version: 0

BGP main routing table version 25

BGP NSR Initial initsync version 1 (Reached)

BGP NSR/ISSU Sync-Group versions 25/0

BGP scan interval 60 secs

BGP is operating in STANDALONE mode.

Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer

Speaker              25         25         25         25          25          25

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd

10.10.10.10      0  64848    9500    9484       25    0    0    5d16h          1

# PE2 Node: BGP Show Command

#show bgp l2vpn evpn summary

Sun Apr 17 07:16:23.574 UTC

Address Family: L2VPN EVPN

--------------------------

BGP router identifier 22.22.22.22, local AS number 64848

BGP generic scan interval 60 secs

Non-stop routing is enabled

BGP table state: Active

Table ID: 0x0   RD version: 0

BGP main routing table version 25

BGP NSR Initial initsync version 1 (Reached)

BGP NSR/ISSU Sync-Group versions 25/0

BGP scan interval 60 secs

BGP funciona en modo STANDALONE.

Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer

Speaker              25         25         25         25          25          25

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd

10.10.10.10      0  64848    9500    9484       25    0    0    5d16h          1

Troubleshoot

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

Información Relacionada

- https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-5/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-75x/about-segment-routing.html

- https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-5/lxvpn/configuration/guide/b-l2vpn-cg-asr9000-75x/evpn-features.html

- Soporte Técnico y Documentación - Cisco Systems