Un controlador SR-TE para routers abiertos.
Un router elige la mejor ruta desde su propia posición y, para casi todo el tráfico que usted transporta, esa es la respuesta correcta. Sin embargo, tres decisiones requieren una visión de toda la red: reservar capacidad a lo largo de una ruta, mantener dos servicios fuera de los mismos enlaces y elegir por qué peering sale un servicio. Traffic Dictator, de Vegvísir Systems, calcula esas decisiones sobre la topología en vivo e instala las rutas en los routers abiertos de IP Infusion que ejecutan OcNOS.
Lo que sus routers ya hacen y lo que aporta un controlador.
Los routers OcNOS ya hacen mucho por sí solos, con ECMP, protección local TI-LFA y planos Flex-Algo construidos dentro del IGP. Un controlador solo aporta las decisiones que requieren una visión de toda la red. La etiqueta de cada tarjeta indica qué mitad lo proporciona.
Evite que un fallo provoque el siguiente
TI-LFA precalcula una ruta de reparación local, de modo que el router conmuta a ella sin esperar a que la red vuelva a converger. El controlador reparte ese desvío entre enlaces con capacidad libre, para que el primer fallo no provoque un segundo.
OcNOS + controladorLleve el tráfico sensible a la latencia por una ruta corta
Flex-Algo construye un plano de bajo retardo dentro del IGP. El trading, los medios y el fronthaul móvil lo siguen, mientras que el resto del tráfico sigue tomando la ruta más económica.
OcNOS por sí soloReserve capacidad para un servicio que ha vendido
La política incluye una cifra de ancho de banda. El controlador comprueba que hay capacidad libre antes de instalar la ruta y retiene la política si un enlace ya está lleno.
OcNOS + controladorAproveche los enlaces que ya está pagando
ECMP ya llena sus enlaces de igual coste. El controlador coloca servicios en los de coste desigual y convierte la capacidad ociosa en capacidad que puede vender.
OcNOS + controladorMantenga la ruta de respaldo fuera de los enlaces que usa la principal
Un grupo disjunto convierte la separación en parte de la política, de modo que una ruta de protección nunca comparte un enlace con la ruta que protege.
OcNOS + controladorCómo una restricción que usted escribe se convierte en una etiqueta que impone el router.
En este diseño solo dos protocolos cruzan entre las dos mitades y, como ambos son estándar, cada mitad puede sustituirse por separado.
Una lista de segmentos es un conjunto ordenado de etiquetas. Cada etiqueta designa un router o un peering, y el router head-end las impone al paquete para que los recorra en orden. Una política es un head-end, un extremo y las restricciones que dan forma a la lista entre ambos.
Plano de datos y plano de control
Se suministra como un router completo, porque IP Infusion integra, valida y da soporte al hardware y a OcNOS en conjunto, de modo que la responsabilidad del hardware y del software recae en un único proveedor.
- Opera la red. IS-IS con extensiones de segment routing, de modo que las etiquetas, ECMP y el fast reroute TI-LFA se ejecutan en los propios routers.
- Actúa como head-end. Instala la política que recibe, impone la lista de segmentos e informa del estado operativo.
- Etiqueta las salidas. Asigna un BGP Peer SID a cada peering externo, para que el controlador pueda designar ese peering en una lista de segmentos.
Solo plano de control
Se suministra como contenedor Docker, en un servidor, en un entorno de virtualización existente o en un router capaz de alojar contenedores, con una HTTP API para la automatización.
- Construye el grafo. La información de nodos, enlaces y prefijos llega mediante BGP-LS y se convierte en una topología en vivo con los segment IDs asociados.
- Mantiene las restricciones. Los saltos explícitos, las afinidades de enlace, el ancho de banda, los grupos disjuntos y los peers de salida se expresan como restricciones de una política.
- Calcula e instala. Determina la lista de segmentos, la envía al head-end y la actualiza cuando cambia la topología.
OcNOS puede realizar un direccionamiento distribuido del tráfico mediante mecanismos del IGP como Flex-Algo, mientras que un PCE o controlador externo puede calcular políticas SR explícitas con restricciones de toda la red. El ancho de banda es la restricción que requiere una visión única: segment routing consigue su escala al no señalizar reservas salto a salto, por lo que el total acumulado de lo que ha reservado cada política se mantiene de forma centralizada. Usted fija esa cifra por política y, hoy por hoy, no se ajusta automáticamente según el tráfico medido. RSVP-TE adopta el enfoque contrario y señaliza una reserva en cada salto.
Cuatro pasos llevan desde la activación de segment routing hasta una política en funcionamiento en la red.
Los dos primeros son una configuración única en los routers. Los dos últimos se repiten para cada política que usted cree.
Active segment routing
IS-IS transporta las extensiones de segment routing en todos los routers, junto con las extensiones de ingeniería de tráfico, de modo que también se anuncian el ancho de banda de los enlaces y los grupos administrativos. Las etiquetas proceden del propio segment routing.
Exporte la topología al controlador
Un router redistribuye la base de datos link-state en BGP-LS con distribute bgp-ls y establece peering con el controlador.
Defina la política y sus restricciones
Una política designa un head-end, un extremo y las restricciones que debe cumplir. El controlador calcula la ruta sobre la topología en vivo y devuelve una lista de segmentos, que es la lista de etiquetas que el head-end impondrá al paquete.
Instálela y manténgala actualizada
El controlador envía la política mediante PCEP y el head-end confirma que está activa y que reenvía por ella. Si la topología cambia más adelante, la misma política se actualiza en su sitio en lugar de reconstruirse.
Cómo cambia cada restricción la ruta que devuelve el controlador.
Seleccione una restricción para ver la ruta y las etiquetas que produce. Cada lista de segmentos y cada métrica que se muestran aquí son salidas registradas en el laboratorio conjunto.
Deslice el diagrama lateralmente para seguir la ruta
Cinco restricciones y la ruta que devuelve cada una
- Permanecer en los enlaces azules, una restricción de afinidad de enlace
- Ruta de R3 a R4. Lista de segmentos 16004. Métrica agregada 10, un salto. Cada enlace de la ruta debe llevar la etiqueta BLUE, y el enlace directo de R3 a R4 la lleva, así que basta con un segmento de nodo. Política
R3_R4_BLUE,affinity-set BLUE_ONLY. - Permanecer en los enlaces amarillos, una restricción de afinidad de enlace
- Ruta de R3 a R2 a R4. Lista de segmentos 16002, 16004. Métrica agregada 20, dos saltos. La etiqueta YELLOW es obligatoria en cada enlace, así que el enlace directo queda descartado y el controlador pasa por R2, sin cambiar ninguna métrica en la red. Política
R3_R4_YELLOW,affinity-set YELLOW_ONLY. - Reservar 40 Gbps, una restricción de ancho de banda
- Ruta de R3 a R2 a R4. Lista de segmentos 16002, 16004. Métrica agregada 20, con 40 Gbps reservados. La misma ruta con capacidad asociada: el controlador comprobó que ambos enlaces podían transportar 40 Gbps antes de instalar nada y registró la reserva en su propia contabilidad. Política
R3_R4_YELLOW,bandwidth 40 gbps. - Elegir el peer de salida, egress peer engineering
- Ruta de R3 a R2 a AS 101. Lista de segmentos 16002, 25600. Métrica agregada 10, un salto más la salida. 25600 es el BGP Peer SID que R2 asignó para su peering con AS 101, así que la lista de segmentos termina designando una salida. Política
R3_R2_EPE. - Esa salida, por enlaces azules, afinidad más egress peer engineering
- Ruta de R3 a R1 a R2 a AS 101. Lista de segmentos 16001, 16002, 25600. Métrica agregada 20, dos saltos más la salida. Ambas restricciones a la vez: la salida sigue siendo AS 101 y la ruta hasta ella debe permanecer en enlaces BLUE, así que el controlador da el rodeo por R1. Política
R3_R2_EPE_BLUE,affinity-set BLUE_ONLY.
Cada lista de segmentos, métrica y nombre de política que aparece aquí procede de la nota de aplicación conjunta de IP Infusion y Vegvísir. Cada uno se muestra allí como salida en vivo de show traffic-eng policy <name> detail en el controlador. La sintaxis de Traffic Dictator está documentada en vegvisir.ie/documentation.
El router de entrada puede elegir por qué peering sale el paquete.
La ingeniería de tráfico suele detenerse en su propio borde, mientras que egress peer engineering se extiende un salto más allá, de modo que el router de entrada elige por qué peering sale el paquete. Cuando el tránsito cuesta más que el peering, esa elección reduce costes.
Un ejemplo práctico del mecanismo, no una medición de laboratorio.
Cuatro routers envían cada uno 30 Gbps hacia un mismo destino, repartidos entre dos peerings privados de 100 Gbps que se prefieren porque cuestan menos que el tránsito. Después, uno de esos peerings falla.
Con BGP estándar, los 120 Gbps completos recaen en el peering restante y todos los servicios que lo atraviesan se degradan a la vez.
Una restricción de ancho de banda hace que el controlador admita solo lo que el peering puede transportar, de modo que tres políticas se asignan al peering restante y la cuarta toma su segunda ruta candidata por el tránsito.
El resultado es un pequeño gasto en tránsito, mientras todo lo demás en el peering sigue funcionando.
Cada peering recibe su propia etiqueta
egress-engineering en el router de borde asigna un BGP Peer SID a ese peering y lo anuncia, para que el controlador pueda colocar una salida al final de una lista de segmentos.
La afinidad de enlace se aplica hasta el borde
Un BGP Peer SID no lleva atributos de enlace, así que usted asigna una afinidad y un ancho de banda al peer de salida en el controlador, y este los compara con el SID anunciado.
Use la salida más cercana con capacidad libre
Una política con un extremo nulo solicita la salida adecuada más cercana, de modo que el controlador elige la salida válida más próxima al head-end y el tráfico sale antes de atravesar su backbone.
Capacidad del controlador, fuera de la validación conjunta: los extremos nulos requieren direccionamiento por color, y el laboratorio conjunto utilizó en todo momento direccionamiento por loopback de servicio.
Un peering caído es visible en el estado de la política
Cuando el vecino cae, el peer SID se retira y la política de salida falla, y ese fallo se refleja en el estado de la política.
Lo que probó el laboratorio conjunto y lo que obtuvo.
IP Infusion y Vegvísir Systems diseñaron la solución conjuntamente y la publicaron. La tabla siguiente enumera cada capacidad probada, junto con el resultado de cada prueba.
| Capacidad | Cómo se ejecutó | Resultado |
|---|---|---|
| Exportación de topología | Base de datos IS-IS de nivel 2 redistribuida en BGP-LS en un router | R3 exportó 34 elementos de información link-state: 5 nodos, 10 enlaces y 19 prefijos. La tabla del propio controlador mostró que se habían recibido. |
| Ruta explícita | Saltos estrictos designados en la política, más una reserva de 2 Gbps | Lista de segmentos [16001, 16002, 16005] instalada. |
| Restricción de ancho de banda | Una cifra de ancho de banda incluida en la ruta candidata | Una reserva de 2 Gbps en la política de ruta explícita se comprobó en el momento del cálculo y quedó registrada en la base de datos del controlador, visible como una reducción del ancho de banda no reservado en cada enlace de la ruta. Las políticas de afinidad usaron el mismo mecanismo con 40 Gbps. |
| Afinidad de enlace | Dos políticas entre el mismo par de routers, una por grupo administrativo | BLUE produjo [16004] con métrica 10, YELLOW produjo [16002, 16004] con métrica 20. Mismos extremos, rutas distintas, sin cambios de métrica en ningún punto. |
| Asignación de servicios | Dos clientes L3VPN en loopbacks de servicio independientes | Cada VRF se resolvió sobre su propia política. Un ping en VRF101 se capturó en el router de tránsito y llevaba las etiquetas de transporte y de VPN esperadas. |
| Diversidad de rutas | Dos políticas en el mismo grupo disjunto | Las dos políticas tomaron siempre enlaces distintos, sin ninguna afinidad ni ruta explícita configurada. |
| ECMP y anycast SID | Un prefix SID compartido anunciado por dos routers con el indicador de nodo desactivado | Dos listas de segmentos se unificaron en una, lo que ahorra espacio en la tabla de reenvío. |
| Egress peer engineering | Un BGP Peer SID asignado a un peering externo, con tráfico dirigido hacia él | Lista de segmentos [16002, 25600], donde la última etiqueta es el peering y no un router. Al añadir una afinidad se obtuvo [16001, 16002, 25600]. |
| Conmutación por fallo del controlador | Controlador principal detenido con políticas delegadas en él | El router volvió a delegar todas las políticas en el segundo controlador. No se sincronizó ningún estado entre ambos. |
| Pérdida total de controladores | Todos los controladores detenidos | Políticas retiradas, las rutas de servicio se resolvieron sobre segment routing IS-IS y el next hop no cambió. Las entradas de sustitución estaban instaladas y activas cuando se leyó la tabla. |
La validación se realizó en una sola plataforma. La arquitectura probada se basa en IS-IS, BGP-LS y PCEP estándar, por lo que el diseño es portable, y la compatibilidad de plataforma y versión debe confirmarse en la lista de compatibilidad de hardware y la matriz de funciones para el equipo que tenga en mente.
Qué ocurre cuando se pierde un controlador y cuando se pierden todos.
El tráfico sigue circulando en ambos casos. Si se pierde un controlador, los routers trasladan sus políticas a otro, y si se pierden todos, los servicios vuelven a la ruta más corta que el IGP ya estaba calculando.
Si se pierde un controlador, los propios routers vuelven a delegar las políticas
Cada política se delega en el controlador que la creó y, cuando ese controlador deja de responder, el router la vuelve a delegar en otro. Como el mecanismo se ejecuta en el router y no entre los controladores, los controladores nunca comparten estado, por lo que añadir un tercero no supone ningún coste de sincronización de estado.
Si se pierden todos los controladores, todo vuelve a resolverse sobre IS-IS
Las políticas se retiran y las rutas de servicio se resuelven sobre segment routing IS-IS. El next hop BGP no cambia.
P> 172.16.101.4/32 out-label 3 out-intf cd1 nexthop 10.100.3.2
P> 172.16.102.4/32 out-label 3 out-intf cd0 nexthop 10.100.6.4
P es una entrada de SR Policy. Dos servicios, dos rutas de ingeniería de tráfico distintas. Columnas resumidas de la salida completa de show mpls forwarding-table.B> 172.16.101.4/32 out-label 24962 out-intf cd0 nexthop 4.4.4.4
B> 172.16.102.4/32 out-label 24963 out-intf cd0 nexthop 4.4.4.4
B es una entrada BGP resuelta mediante segment routing IS-IS. El next hop BGP de las rutas VPN no cambia. Lo que cambia es cómo se resuelve, sobre segment routing IS-IS en lugar de sobre una política, y por eso difieren la etiqueta y la interfaz de salida. Ambas entradas tenían 16 segundos de antigüedad cuando se leyó la tabla. Columnas resumidas de la salida completa.En el lado del router, la configuración es IS-IS y BGP convencional, con un único bloque PCEP añadido.
Son extractos de la validación conjunta, con comentarios añadidos. Como Traffic Dictator utiliza una CLI estándar del sector, la configuración del controlador es tan legible como la del router, de modo que un mismo ingeniero puede trabajar en ambas mitades.
PCEP Combinación validada
Es un protocolo con estado, de modo que el controlador sabe si el router instaló la política y reenvía por ella, y requiere una sesión por head-end. Es la opción que utilizó la validación conjunta.
BGP SR-TE Menos sesiones
Las políticas se transportan como rutas BGP, de modo que viajan por sus route reflectors existentes en lugar de requerir una sesión con cada head-end. En una red grande, es la diferencia entre unas pocas sesiones y cientos de ellas.
! feed the IS-IS link-state database into BGP
router isis 1
distribute bgp-ls
!
router bgp 65002
bgp router-id 3.3.3.3
neighbor 192.168.123.1 remote-as 65001
!
address-family link-state link-state
neighbor 192.168.123.1 activate
exit-address-familyQué hace cada línea
distribute bgp-lses toda la exportación: IS-IS pasa su base de datos a BGP.- El controlador es un vecino BGP más, en su propio sistema autónomo.
link-statees la familia de direcciones que transporta la topología. Por ella pasan tres tipos de información: Node, con los system IDs y el bloque global de segment routing; Link, con la métrica, el ancho de banda, el grupo administrativo y el adjacency SID; y Prefix, con los prefijos y sus SIDs.- Solo un router necesita esta configuración, porque vuelve a anunciar la base de datos link-state que ya le ha proporcionado todo el nivel IS-IS.
Extracto de la nota de aplicación conjunta, IP Infusion y Vegvísir Systems, agosto de 2025. Verifique la sintaxis actual en documentation.ipinfusion.com.
pce configuration 1
capability
segment-routing pcep
pce instantiation
exit-capability
!
update-source 192.168.123.3
peer-address ipv4 192.168.123.1Qué hace cada línea
segment-routing pcepindica al controlador que a este router se le pueden asignar listas de segmentos en lugar de túneles RSVP.pce instantiationes el permiso que permite al controlador crear políticas además de actualizarlas, de modo que una política puede crearse en el controlador en lugar de en el router.- A continuación, la sesión comunica sus capacidades al controlador: stateful PCE, LSP instantiation y SR PCE capability figuran como admitidas.
Extracto de la nota de aplicación conjunta, IP Infusion y Vegvísir Systems, agosto de 2025. Verifique la sintaxis actual en documentation.ipinfusion.com.
! ---- on R3: name the link groups once, then tag interfaces ----
admin-group BLUE 0
admin-group YELLOW 1
!
interface cd0
admin-group BLUE
!
interface cd1
admin-group YELLOW
!
! ---- on the border router R2, which holds the external peering ----
router bgp 65002
bgp router-id 2.2.2.2
neighbor 192.168.123.2 remote-as 101
!
egress-engineering
neighbor 192.168.123.2 peer-node
exit-egress-engineeringQué hace cada línea
admin-groupasocia un nombre a una posición de bit. Etiquete una interfaz y el IGP la anuncia, de modo que el controlador ve la etiqueta sin ninguna sesión adicional.- Usted elige los nombres. Aquí son BLUE y YELLOW, pero en una red real suelen describir el recurso, como un circuito alquilado, una ruta submarina o un anillo de baja latencia.
egress-engineeringypeer-nodeasignan juntos el BGP Peer SID de ese peering. Sin él, una política no tiene forma de nombrar esa salida. Tenga en cuenta que los dos bloques de este panel se configuran en routers distintos.- El router de borde anuncia el peer SID en BGP-LS, ya sea directamente al controlador o al router que ya mantiene la sesión con el controlador, que lo vuelve a anunciar. En ambos casos basta con una declaración de vecino BGP-LS más.
Extracto de la nota de aplicación conjunta, IP Infusion y Vegvísir Systems, agosto de 2025. Verifique la sintaxis actual en documentation.ipinfusion.com.
traffic-eng affinities
affinity-map
name BLUE bit-position 0
name YELLOW bit-position 1
!
affinity-set YELLOW_ONLY
constraint include-all
name YELLOW
!
traffic-eng policies
!
policy R3_R4_YELLOW
headend 3.3.3.3 topology-id 1
endpoint 4.4.4.4 service-loopback 172.16.101.4
priority 7 7
install direct pcep 192.168.123.3
!
candidate-path preference 200
affinity-set YELLOW_ONLY
bandwidth 40 gbpsQué hace cada línea
- El mapa de afinidades da a ambas mitades los mismos nombres para los mismos bits. El bit 1 se llama YELLOW en el router y en el controlador, así que ambos coinciden sin una capa de traducción.
constraint include-allsignifica que cada enlace de la ruta debe llevar la etiqueta.endpointyservice-loopbackconectan juntos un servicio. Cada servicio recibe su propio loopback como next hop, de modo que dos servicios entre el mismo par de routers pueden tomar rutas distintas.priority 7 7establece la prioridad de establecimiento y de retención. Es lo que decide quién cede ancho de banda cuando una política más importante lo necesita.candidate-path preference 200es el intento principal, y añadir una ruta con una preferencia menor describe la alternativa dentro de la misma política.
Extracto de la nota de aplicación conjunta, IP Infusion y Vegvísir Systems, agosto de 2025. La documentación de Traffic Dictator está publicada en vegvisir.ie.
Ingeniería de tráfico: preguntas frecuentes
¿Qué es un controlador SR-TE?
¿Necesito un controlador para ejecutar segment routing?
¿Es obligatorio Traffic Dictator o podemos usar otro controlador?
¿Quién suministra y da soporte a cada mitad de esta solución?
¿Tengo que sustituir mis routers actuales para añadir un controlador SR-TE?
¿Podemos migrar desde RSVP-TE sin reconstruir nuestros servicios?
¿Puede la reserva de ancho de banda seguir el tráfico medido?
¿Se admite la ingeniería de tráfico SRv6 en este diseño?
¿Quiere el laboratorio completo?
Una descarga breve y técnica que va más allá de esta página: la nota de aplicación de segment routing.
Nota de aplicación de Segment Routing
Formulario rápido. Su PDF se abre en una pestaña nueva inmediatamente después de enviarlo.
✓ Abriendo su PDF en una pestaña nueva…
Si no se ha abierto, utilice el enlace de abajo.
Llévelo a una prueba de concepto.
Vegvísir Systems publica Traffic Dictator para evaluación y pruebas de concepto sin licencia, con un límite de 100 políticas, y OcNOS está disponible como máquina virtual. Indíquenos qué tráfico desea dirigir y definiremos el alcance sobre la combinación adecuada, para después dimensionar el despliegue de producción.
¿Desea que nos pongamos en contacto con usted?
Déjenos sus datos y un ingeniero de IP Infusion le explicará cómo sería la ingeniería de tráfico en su red. Solo nos pondremos en contacto con usted si así lo desea.