Guía de diseño detallada y ejemplos de configuración de la política de ruta explícita de SR-TE con EVPN VPWS, IOS XR Release - 7.5.x
Contenido
Introducción
Este documento describe la guía de diseño detallada con descripciones técnicas basadas en los requisitos de las redes XYZ y también proporciona una plantilla de configuración de bajo nivel y una configuración para los casos prácticos de la política de ruta explícita de la ingeniería de tráfico de routing de segmentos (SR-TE) con el servicio de cable privado virtual (VPWS) de VPN Ethernet (EVPN).
1. Información general
1.1. Fuera de alcance
Este documento no cubre los requisitos de las políticas SR-TE centralizadas 'a demanda' que utilizan el controlador XTC, EVPN ELAN, etc., pero se centra solamente en las políticas SR-TE dirigidas por nodos de cabecera con superposición EVPN VPWS.
1.2. Hipótesis
El lector de este documento debe estar familiarizado con los conceptos de IP/MPLS y Ethernet junto con las tecnologías de Ruteo de Segmentos e Ingeniería de Tráfico.
1.3. Ámbito técnico
El ámbito técnico principal de este documento se limita a:
- OSPF con TI-LFA FRR
- Políticas SR-TE controladas por cabecera (distribuidas)
- Trayectoria Primaria Explícita y Trayectorias de Failover Basadas en IGP Dinámico
- VPWS de EVPN de enlace único
Las plantillas de configuración proporcionadas en este documento se conocen como 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 |
|
| TI-LFA FRR |
5 |
|
| Superposición de EVPN |
6 |
|
| BoB y equilibrio de carga |
7 |
|
| Plantillas de configuración |
La solución de diseño completa |
8 |
| Configuración de muestra 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 respetuosa con el medio ambiente mediante los dispositivos Cisco NCS 5500.
El objetivo es transmitir 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 las 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 y tarjetas de línea de NCS 5500:
Tabla 2. Requisitos de hardware del proyecto
| Nodos PE |
PID |
| Chasis |
NCS-5504 |
| MPA/LC que conectan los nodos IP |
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 IP |
NC55-36X100G-A-SE |
| MPA/LC que conectan nodos PE |
NC55-36X100G-A-SE |
En esta sección se ofrece una descripción general de las tecnologías que se utilizarán con descripciones breves.
Descripción general de la tecnología
3. Ruteo 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 reemplazar los protocolos LDP y RSVP-TE tradicionales con la introducción de la distribución de etiquetas y la ingeniería de tráfico bajo un mismo marco y para hacerlo posible solo 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 de 20 bits sin signo plano.
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 del segmento como se ilustra en la Figura 1. Un SID de prefijo está asociado con un prefijo IP. El SID del prefijo se configura manualmente desde el rango de etiquetas de bloque global de ruteo de segmentos (SRGB) y se distribuye mediante IS-IS o OSPF. El segmento de prefijo dirige el tráfico a lo largo de la trayectoria más corta hacia su destino.
- Utiliza el bloqueo global de SR (SRGB)
- SRGB anunciado con capacidades de router TLV - En la configuración, Prefix-SID se puede configurar como un valor absoluto o un índice
- En el anuncio del protocolo, Prefix-SID siempre se codifica como un índice globalmente único. El índice representa un desplazamiento de la numeración de base cero de SRGB, es decir, 0 es el primer índice. Por ejemplo, index 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 en 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 con un prefijo de host que identifica un nodo.
- Equivalente a un prefijo de ID de router, 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 SID de prefijo configurado es un SID de nodo
- 'regular' (es decir, non-Node-SID) Prefix-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 es distribuido 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 a nivel local
- Asignado automáticamente para cada adyacencia
- Siempre codificado como un valor absoluto (es decir, no indizado)
SID o BSID de enlace: es un SID localmente significativo asociado con la política SR. Ayuda a dirigir los paquetes a su política de SR asociada. El segmento de enlace es un segmento local que identifica una política SR-TE. Cada directiva SR-TE se asocia a un identificador de segmento de enlace (BSID).
El BSID es una etiqueta local que se asigna automáticamente para cada directiva SR-TE cuando se crea una instancia de la directiva SR-TE. BSID se puede utilizar para dirigir el tráfico hacia la política SR-TE y a través de los límites del dominio, lo que crea políticas integrales de SR-TE entre dominios.
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 sencillo mecanismo de routing de origen sin información de 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 directo de vía rápida.
Esto se logra cuando se configuran administrativamente las políticas definidas a través de una combinación de diversas restricciones que programan las rutas de acceso principal y de copia de seguridad desde los nodos de origen a los de destino. El controlador puede ser centralizado (SDN) o distribuido (cabecera), lo que depende de los requisitos de la red.
Consideremos la topología que se muestra en la figura 2. Supongamos que el costo de los links son valores predeterminados y el trayecto más corto para alcanzar D desde A es A-B-C-D pero el trayecto de baja latencia es A-E-F-G-H-D. El operador puede definir la ruta de 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 todos los routers que atraviesan los paquetes (es decir, E, F, G y H).
Figura 2 Ejemplo de trayecto definido administrativamente 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 directiva 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 hasta el destino e indica a los routers de la red 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 de SID es enviada al 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):
- Cabecera: donde se crean instancias 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 (Head-end - Endpoint)
- Terminal: 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 rutas candidatas que incluyen rutas de acceso principales y de copia de seguridad.
Por ejemplo, la ruta principal de la política se puede definir explícitamente con SID de adyacencia y, en caso de escenarios de falla, la ruta de respaldo puede ser dinámica y la métrica IGP puede encargarse de ella.
5. TI-LFA FRR
5.1. Descripción general
La alternativa sin bucles independiente de la topología (TI-LFA) es una función que protege enlaces, nodos y SRLG. Es fácil de configurar; sólo se requieren 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 utilizados en el router. La Figura 3. muestra la trayectoria de tráfico principal y la trayectoria de respaldo precalculada por TI-LFA para los Escenarios de Falla de Link Local y Falla de Nodo.
Figura 3. Escenario de falla de link TI LFA
Figura 4 Escenario de Failover de Nodo TI LFA
Cada nodo y ruta protegidos tiene una ruta de copia de seguridad 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 el trayecto de respaldo y elimina temporalmente el link o nodo protegido de la base de datos. Después de esto, primero calcula la trayectoria de respaldo con la trayectoria más corta. Esto garantiza que la trayectoria de respaldo tenga el menor costo de métrica posible mientras evita la trayectoria protegida. Si se produce un error, se utiliza para el tráfico un túnel diseñado para el tráfico que sigue la ruta de respaldo. Una lista de etiquetas de reparación determina la trayectoria de los paquetes que necesitan una nueva ruta a su destino. Una lista de etiquetas de reparación es una pila de etiquetas normal, pero solo se utiliza cuando se produce un error en la ruta protegida.
5.2. Impacto del método de detección de fallos en FRR
El Fast Reroute para las trayectorias de ingeniería de tráfico SR-TE se configura como un medio para conmutar el tráfico en caso de escenarios de failover de la trayectoria primaria a las trayectorias de respaldo en un lapso tan cercano a 50 mseg como sea posible. La función de reruteo rápido se configura bajo el protocolo IGP (OSPF/ISIS). El tiempo de convergencia depende del método por el cual ocurre la detección de falla de link. En el caso de un corte de fibra, la detección es inmediata y la posibilidad de obtener una convergencia inferior a 50 mseg es alta. Sin embargo, en caso de que la detección de fallas de link deba ser realizada por BFD con un intervalo de 15 mseg (multiplicador x3). El tiempo de convergencia es de más de 50 ms.
5.3. Prevención de microbucles con SR
Los microloops son breves bucles de paquetes que se producen en la red después de un cambio de topología (link down, link up o eventos de cambio de métrica). 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 crear en loop entre estos dos nodos, lo que resulta en pérdida de paquetes, fluctuación y paquetes fuera de orden.
La función Segment Routing Microloop Avoidance detecta si es posible que los microloops vayan seguidos de un cambio de topología. Si un nodo calcula que puede producirse un microbucle en la nueva topología, crea una ruta de acceso de directiva SR-TE sin bucles al destino con el uso de una lista de segmentos. Una vez que vence el temporizador de retraso de actualización RIB, la política SR-TE se reemplaza con trayectorias de reenvío normales. Existe un temporizador predeterminado para la demora de actualización de RIB del cual se ocupa TI-LFA.
6. Superposición de EVPN
EVPN es una tecnología diseñada inicialmente para servicios multipunto Ethernet, con capacidades avanzadas de multi-homing, con el uso de BGP para distribuir información de alcance de dirección MAC sobre la red MPLS, mientras que trae las mismas características operativas y de escala de VPNs IP a L2VPNs. 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 los escenarios de ruteo y bridging del Data Center. EVPN también proporciona opciones para combinar servicios L2 y L3 en la misma instancia.
EVPN es una solución de última 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 trae una serie de beneficios como se mencionó:
- 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 bajo la estandarización IETF
Las direcciones MAC aprendidas en un dispositivo deben aprenderse o distribuirse en los otros dispositivos de una VLAN. La función de aprendizaje de MAC del software EVPN permite la distribución de las direcciones MAC detectadas 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, obtendrá información sobre algunas de las ventajas y los tipos de ruta de EVPN en general y, a continuación, comprenderá los componentes específicos de la solución que se aplican al diseño de los servicios de red XYZ.
6.1. Ventajas de EVPN
L2VPN y L3VPN no solo proporcionan servicios bajo un mismo marco de solución con ayuda de varios tipos de rutas, sino que las EVPN resuelven dos limitaciones de larga data para los servicios Ethernet en las redes de proveedores de servicios:
- Acceso Ethernet con varias conexiones y todo activo
- Red de proveedores de servicios: integración con la oficina central o con el Data Center
6.1.1. Acceso Ethernet con varias conexiones y todo activo
La figura muestra la mayor limitación de las soluciones multipunto L2 tradicionales como VPLS.
Figura 5. Acceso todo activo a EVPN
Cuando VPLS se ejecuta en el núcleo, la prevención de loops requiere que PE1/PE2 y PE3/PE4 solo proporcionen redundancia de un solo activo hacia sus respectivos CE. Tradicionalmente, se utilizaban técnicas como los protocolos mLACP o L2 heredado, como MST, REP, G.8032, etc., 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 activo único mediante pseudowire de radio (PW) activo y de respaldo.
Los modelos de redundancia de acceso totalmente activos no se pueden implementar, ya que la tecnología VPLS carece de la capacidad de evitar bucles L2 que se 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) originado en el CE se inunda a través del núcleo VPLS y lo reciben todos los PE, que a su vez lo inundan a 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 NLRI EVPN.
Figura 6. NLRI EVPN
Los tipos de ruta EVPN relevantes necesarios para esta implementación se describen aquí:
6.2.1. Tipo de ruta 1: ruta de detección automática de Ethernet (AD)
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 EVIs que pertenecen al ES. El campo ESI se establece en cero cuando un CE es de enlace único. Este tipo de ruta se utiliza para la extracción masiva de direcciones MAC, el alias para el equilibrio de carga y el filtrado de horizonte dividido.
6.2.2. Tipo de ruta 4: ruta del segmento Ethernet
Las rutas de segmentos Ethernet permiten la conexión de un dispositivo CE a dos o más 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:
- Single Homing: permite conectar un dispositivo de extremo de usuario (CE) a un dispositivo de extremo de proveedor (PE). En este caso, el valor de ESI es nulo para cada enlace PE-CE.
- Reposición múltiple: permite conectar un dispositivo de extremo de usuario (CE) a dos o más dispositivos de extremo de proveedor (PE) para proporcionar conectividad redundante. No se requiere ningún enlace entre chasis. El dispositivo PE redundante garantiza que no haya interrupciones del tráfico cuando se produce un fallo de red. Los tipos de multihoming son:
Figura 7 EVPN Single Homing
Multihoming - Estos son los tipos de multihoming:
1. Single-Active: en un modo de single-active, solo un PE de un grupo de PE conectados al segmento Ethernet concreto puede reenviar tráfico hacia y desde dicho segmento Ethernet.
Figura 8 EVPN Single-Active
2. Activo-Activo: en el modo activo-activo, todos los PE conectados al segmento Ethernet concreto pueden reenviar tráfico hacia y desde dicho segmento Ethernet.
Figura 9. EVPN Dual Active
7. Balance de carga y BoB
7.1. BFD sobre paquete (BoB)
La detección de reenvío bidireccional (BFD) proporciona una detección de poca sobrecarga y de corta duración de los fallos en la ruta entre los motores de reenvío adyacentes. BFD permite utilizar un único mecanismo para la detección de fallos 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 caso de un link o vecino fallido.
Esto haría que el IGP comenzara a reenviar el tráfico hacia la trayectoria de respaldo ya calculada con el uso de FRR (en el caso del IGP) y PIC (en el caso del BGP).
En la función BFD Over Bundle (BoB), la sesión BFD IPv4 se ejecuta en todos los miembros del paquete activos.
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 miembro. El estado miembro del conjunto es una función de:
Estado L1 (enlace físico)
Estado de L2 (LACP)
Estado L3 (BFD)
El agente BFD aún se ejecuta en la tarjeta de línea. Los estados BFD de los links de miembro de agrupamiento se consolidan en RP. Los links de miembro deben estar conectados adosados, sin ningún switch L2 en medio. La función BoB se configura en todas las interfaces Bundle Ethernet de la red XYZ.
7.2. Equilibrio de carga
Equilibrio de carga por flujo ECMP en la red en cuestión se extiende a través de interfaces Ethernet entre paquetes y ethernets dentro de paquetes (entre miembros físicos de una interfaz de paquete). Esto se aplica en toda la red, desde PE a PE (equilibrio de carga de núcleo) y desde PE a CE (equilibrio de carga de CA), como se ha explicado.
7.2.1. Equilibrio de carga del núcleo con etiqueta FAT
Según el alcance de la red XYZ, debe tener en cuenta únicamente el equilibrio de carga ECMP (múltiples rutas de igual coste) por flujo, como se ha mencionado:
Los routers típicamente balancean la carga del tráfico basado en la etiqueta más baja de la pila de etiquetas que es la misma etiqueta para todos los flujos en un pseudowire dado. Esto puede llevar a un balanceo 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 extremo del proveedor de origen (PE) a un extremo del proveedor de destino PE.
Flow-Aware Transport Pseudowire (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 FAT PW se utilizan para equilibrar la carga del tráfico en el núcleo cuando se utilizan múltiples rutas de igual coste (ECMP). Se crea una etiqueta de flujo basada en flujos de paquetes indivisibles que entran en 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 a través de las rutas ECMP o las rutas agrupadas en enlaces en el núcleo.
Se agrega una etiqueta adicional a la pila, denominada etiqueta de flujo, que se genera para cada flujo de entrada ú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 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. Equilibrio de carga del circuito de conexión
Sin embargo, para el equilibrio de carga de los miembros del paquete AC, 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 se ajustan explícitamente los botones de configuración l2vpn específicos en todos los routers PE. 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
En esta sección se tratan todos los detalles de diseño cosidos por los diferentes componentes individuales que se han explicado en las 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 entre PE2 y PE4 solamente. El objetivo principal en esta situación es mantener la ruta de tráfico totalmente inconexa, como se muestra en la figura 12.
El tráfico en cuestión aquí sería flujos de multidifusión encapsulados a través de la superposición EVPN. Desde los nodos CE1 y CE2, las transmisiones de medios multidifusión (voz/vídeo) vienen en las que, puede encapsularse en los nodos PE1 y PE2 y transportarse 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 lo sucesivo bajo todas las circunstancias a menos que se indique lo contrario. Para obtener información detallada sobre los requisitos, consulte la subsección 2.2.
8.2. Resumen del diseño
Para cumplir los requisitos, OSPF se elige como IGP subyacente según lo deseado por las redes XYZ. Para dirigir la secuencia de multidifusión encapsulada a través del par de tráfico de origen y destino a través de la ruta deseada, SR-TE debe implementarse entre los nodos PE.
Las políticas SR-TE se han diseñado con rutas IGP dinámicas y rutas de acceso explícitas.
Las trayectorias explícitas cubren:
- Situación de tráfico normal
- Escenario de Failover hasta que estén disponibles las opciones de trayecto alternativo
Las trayectorias IGP dinámicas abarcan:
- Ruta de respaldo para el escenario de falla donde las opciones de trayectoria alternativa NO están disponibles
Las funciones como BFD, TI-LFA y Microloop Avoidance se configuran bajo 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 de tráfico, la plantilla de configuración y otros detalles se mencionan en la subsección 8.5.2.
Aparte de estos, también se tienen en cuenta los requisitos como la prevención de microbucles y la convergencia inferior a 50 mseg en caso de escenarios de fallos.
8.3. Bloques de diseño
En esta subsección se recogen todos los bloques de diseño que posteriormente se tratan a fondo en estas secciones.
Descripción general del diseño (capa 1):
- El tamaño de MTU en la red XYZ se ha fijado en '9216' con el objetivo de admitir hasta 5 o 6 pilas de etiquetas SR
- El 'BFD over Bundle' se implementa con un intervalo de 15 mseg para detectar cortes de fibra inferiores a 50 mseg
Descripción general del diseño OSPF/SR-TE:
- OSPF como protocolo IGP con TI-LFA configurado para proporcionar FRR bajo 50 mseg de tiempo de convergencia
- Capa de transporte basada en Segment Routing as Forwarding Plane y OSPF como protocolo de routing
- En la red XYZ, la ruta explícita Segment Routing Traffic Engineering dirige el tráfico en todas las direcciones de ruta principales requeridas. En el caso de escenarios de failover 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
- El proceso de red XYZ y BGP en cada PE forma iguales 'IPv4' y 'L2VPN EVPN' con ambos RR por separado
Descripción general del diseño de servicios:
- Las capas de servicio se basan en 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 los PW EVPN-VPWS punto a punto
- El balanceo de carga ECMP se logra mediante la configuración de la etiqueta FAT en la sección EVPN
- El servicio tiene como objetivo admitir de 5 a 6 etiquetas de pila de SR que incluyan etiquetas de transporte SR, etiquetas EVPN y etiquetas FAT para el equilibrio de carga
8.4. Topología física de muestra
En esta figura se muestra la topología física de las redes XYZ. En aras de la simplicidad, solo 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 del diseño de la capa 1
En el diseño genérico de capa 1, hay un paquete Ethernet con al menos dos links miembro por paquete configurado. Para una detección rápida de fallas de link, elija BFD sobre la función Bundle. El intervalo de tiempo puede variar idealmente entre 5 y 15 ms. Depende de la capacidad de 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 debe configurarse solamente bajo la interfaz Ethernet del paquete y no es necesario configurarla bajo IGP. El tamaño de MTU se fija en 9216 con el objetivo de admitir hasta 5 a 6 pilas de etiquetas SR.
8.5.1. Plantillas de configuración
Las plantillas de configuración de BFD over Bundle para todos los nodos son las siguientes:
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 OSPF/SR-TE
Todos los routers OSPFv2 de la red están en el Área 0 y, por lo tanto, la red maneja un único dominio IGP.
En el router OSPF, se habilita el ruteo de segmentos y se configuran las interfaces Ethernet de paquetes relevantes. Del mismo modo, en Interfaces de agrupamiento, se habilitan los parámetros de tipo de red y de reruteo rápido. Lo más importante es que una interfaz de loopback está habilitada en modo pasivo con 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 ruta de respaldo que sea necesaria. Para ello, se configura BFD over Bundle bajo Bundle Interface y TI-LFA FRR bajo OSPF, lo que mantiene el tiempo de convergencia en 50 mseg en el caso de escenarios de corte de fibra.
Estas subsecciones describen en detalle los escenarios Normal y Failover de las trayectorias de tráfico:
8.6.1. Situación de tráfico normal de SR-TE
Para mantener una ruta principal muy estricta, las políticas SR-TE deben diseñarse con rutas explícitas de extremo a extremo entre los pares de tráfico de origen y destino mencionados anteriormente. Además, se necesitan varias rutas candidatas de preferencia dentro de una política SR-TE para proporcionar una provisión para varios escenarios de conmutación por error.
Esta figura muestra los detalles de la red de 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 la 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 enlaces entre P y P se han marcado con color verde. El costo OSPF de los links PE-a-P es 100 y el costo de los links P-a-P es 10.
El flujo de tráfico primario SR-TE se ha marcado con flechas azules entre el par PE1-PE3 y con flechas violetas entre el par PE2-PE4.
Figura 12. Detalles de 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 los nodos PE1 y PE2 según se indica:
# 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
El comando source address en la configuración de ruteo de segmentos 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 congelar uno de esos. 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 ipv4Configure 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
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>
!
!
!
!
!
!
En caso de que cualquier link remoto, aparte del link local de un nodo PE, falle, la trayectoria sigue siendo válida. Esto es como se diseñó 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 fallo
Para entender los escenarios de falla de tráfico, se debe observar de cerca el tráfico de trayectoria principal en 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 estrictos requisitos para dirigir administrativamente el tráfico a través de nodos específicos en rutas de copia de seguridad para mantener la máxima separación entre los pares de nodos de origen y destino. Este diseño se realiza para evitar la sobrecarga de los enlaces utilizados y para mantener un mínimo de enlaces no utilizados.
Estas subsecciones muestran los diversos escenarios de conmutación por fallas, como link único, link doble, nodo único y nodo doble con la trayectoria de conmutación por fallas que toma el tráfico para mantener la incoherencia máxima.
8.6.3. Escenario de conmutación por fallo de enlace ú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 centrales P2 y P1. Administrativamente, esto se dirige a través de la lista de segmentos <SIDLIST1> que forma la ruta de respaldo principal entre los nodos PE1 y PE3
Figura 13. Escenario de falla de link único
Incoherencia: en el caso de un fallo de enlace único, el número de enlaces 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 los nodos PE1 y PE2, como se indica a continuación:
# 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>
!
!
!
!
!
!
# 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 falla de link doble
Este es el escenario de falla de link doble donde el link local entre PE1 y P1 y el link local entre PE2 y P2 falla. El tráfico de PE1 toma un desvío a través de los nodos centrales P2 y P1 y el tráfico de PE2 toma un desvío a través de los nodos centrales P1 y P2.
Éstas se dirigen administrativamente a través de la lista de segmentos <SIDLIST2> respectiva 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 Failover de link doble
Incoherencia: en caso de fallo de enlace doble, el número de enlaces 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 los nodos PE1 y PE2, como se indica a continuación:
# 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>
!
!
!
!
!
!
# 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 del núcleo. Esto se dirige administrativamente a través de la lista de segmentos <SIDLIST3> que forma la trayectoria de respaldo secundaria entre los 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 falla de nodo único
Incoherencia: en el caso de un fallo de nodo único, el número de enlaces 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 los nodos PE1 y PE2 según se indica:
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>
!
!
!
!
!
!
# 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 falla de nodo doble
Este es el escenario de falla de doble nodo donde los nodos P1 y P3 fallan y el tráfico toma un desvío a través de los nodos P2 y P4 del núcleo. Esto se dirige administrativamente a través de la lista de segmentos <SIDLIST3> que forma la trayectoria de respaldo secundaria entre los nodos PE1 y PE3. Dado que las trayectorias explícitas se definen solamente para los 2 escenarios mencionados anteriormente, aquí la trayectoria IGP dinámica forma la trayectoria de respaldo terciaria y asume la función de ruteo del 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 Failover de nodo doble.
Incoherencia: en caso de fallo de nodo doble, el número de enlaces 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 los nodos PE1 y PE2 según se indica:
# 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>
!
!
!
!
!
!
# 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
El protocolo de gateway fronterizo (BGP) es el protocolo que toma las decisiones de routing de núcleo en Internet. Mantiene una tabla de redes IP o "prefijos" que designan la disponibilidad de la red entre los sistemas autónomos (AS). Se describe como un protocolo de vector de trayecto. BGP no utiliza las métricas tradicionales del protocolo de gateway interior (IGP), pero toma decisiones de routing basadas en la ruta, las políticas de red o los conjuntos de reglas. Por esta razón, es más apropiado llamarlo protocolo de alcance en lugar de protocolo de ruteo.
MP-BGP se puede utilizar para propagar los prefijos de estado de link, VPNv4, VPNv6, EVPN e IPv6 a través de la red. Esto se realiza con una configuración de reflector de ruta que forma vecinos iBGP con dispositivos de núcleo, agregación, acceso y dispositivos SR-PCE.
A través del RR, los prefijos aprendidos 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 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:
# 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 del servicio
Esta subsección describe el servicio de superposición VPWS de EVPN junto con la representación de la pila de etiquetas admitida 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 de EVPN entre un par de PE. Tiene la capacidad de reenviar tráfico de una red a otra sin búsqueda de MAC. El uso de EVPN para VPWS elimina la necesidad de señalización de PW de segmento único y multisegmento para servicios Ethernet punto a punto. La tecnología EVPN-VPWS funciona en el núcleo de IP y MPLS; el núcleo de IP admite el núcleo de BGP y MPLS para conmutar paquetes entre los terminales.
8.8.1. Representación de la pila de etiquetas
El servicio tiene como objetivo admitir hasta 5 a 6 etiquetas de pila de etiquetas SR, incluidas las etiquetas de transporte SR, las etiquetas EVPN y las 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 Principal 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 trayectoria explícita de respaldo o la trayectoria dinámica de respaldo definida por IGP:
| TI-LFA SID1 |
| TI-LFA SID2 |
| TI-LFA SID3 |
| 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:
# 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. Configuración de muestra y comandos Show
Esta última sección contiene la configuración relevante y los comandos show de los nodos PE sólo para el escenario de tráfico normal. Estos se capturan aquí alineados con los parámetros dados en esta figura como una referencia que ayuda a entender las plantillas de configuración explicadas en las 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
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
01-Jul-2022 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)