Un contrôleur SR-TE pour routeurs ouverts.
Un routeur choisit le meilleur chemin depuis sa propre position, et pour presque tout ce que vous transportez, c'est la bonne réponse. Trois décisions exigent en revanche une vue de l'ensemble du réseau : réserver de la capacité le long d'un chemin, maintenir deux services sur des liens distincts, et choisir par quel peering un service quitte le réseau. Traffic Dictator, de Vegvísir Systems, calcule ces décisions à partir de la topologie en temps réel et installe les chemins sur les routeurs ouverts d'IP Infusion équipés d'OcNOS.
Ce que vos routeurs font déjà, et ce qu'un contrôleur ajoute.
Les routeurs OcNOS accomplissent déjà beaucoup par eux-mêmes, avec ECMP, la protection locale TI-LFA et des plans Flex-Algo construits dans l'IGP. Un contrôleur n'ajoute que les décisions qui exigent une vue de l'ensemble du réseau. L'étiquette de chaque carte indique quelle moitié fournit la fonction.
Empêcher qu'une panne n'en provoque une autre
TI-LFA précalcule un chemin de réparation local, de sorte que le routeur bascule dessus sans attendre la reconvergence du réseau. Le contrôleur répartit ce reroutage sur les liens disposant de capacité libre, afin que la première panne n'en provoque pas une seconde.
OcNOS + contrôleurPlacer le trafic sensible à la latence sur un chemin court
Flex-Algo construit un plan à faible délai dans l'IGP. Le trading, les médias et le fronthaul mobile le suivent, tandis que tout le reste continue d'emprunter la route la moins coûteuse.
OcNOS seulRéserver de la capacité pour un service vendu
La politique porte une valeur de bande passante. Le contrôleur vérifie la capacité disponible avant d'installer le chemin, et retient la politique si un lien est déjà saturé.
OcNOS + contrôleurUtiliser les liens que vous payez déjà
ECMP remplit déjà vos liens à coût égal. Le contrôleur place des services sur les liens à coût inégal, et transforme ainsi une capacité inutilisée en capacité commercialisable.
OcNOS + contrôleurGarder le secours hors des liens utilisés par le chemin principal
Un groupe disjoint intègre la séparation à la politique : un chemin de protection ne partage jamais de lien avec celui qu'il protège.
OcNOS + contrôleurComment une contrainte saisie devient un label imposé par le routeur.
Dans cette conception, seuls deux protocoles circulent entre les deux moitiés, et comme tous deux sont standard, chaque moitié peut être remplacée indépendamment.
Une liste de segments est un ensemble ordonné de labels. Chaque label désigne un routeur ou un peering, et le routeur de tête les impose au paquet afin qu'il les visite dans l'ordre. Une politique se compose d'un routeur de tête, d'une extrémité et des contraintes qui façonnent la liste entre les deux.
Plan de données et plan de contrôle
Il est livré sous forme de routeur complet, car IP Infusion intègre, valide et assure le support du matériel et d'OcNOS ensemble : la responsabilité du matériel et du logiciel relève ainsi d'un seul fournisseur.
- Fait fonctionner le réseau. IS-IS avec extensions segment routing : les labels, ECMP et le fast reroute TI-LFA s'exécutent tous dans les routeurs eux-mêmes.
- Joue le rôle de routeur de tête. Installe la politique reçue, impose la liste de segments et remonte l'état opérationnel.
- Étiquette les sorties. Alloue un BGP Peer SID pour chaque peering externe, afin que le contrôleur puisse désigner ce peering dans une liste de segments.
Plan de contrôle uniquement
Il est livré sous forme de conteneur Docker, sur un serveur, dans un environnement de virtualisation existant ou sur un routeur capable d'héberger des conteneurs, avec une HTTP API pour l'automatisation.
- Construit le graphe. Les informations Node, Link et Prefix arrivent via BGP-LS et deviennent une topologie en temps réel à laquelle sont associés les segment IDs.
- Gère les contraintes. Sauts explicites, affinités de lien, bande passante, groupes disjoints et peers de sortie sont tous exprimés sous forme de contraintes sur une politique.
- Calcule et installe. Détermine la liste de segments, la transmet au routeur de tête, puis la met à jour lorsque la topologie évolue.
OcNOS peut effectuer une orientation du trafic distribuée à l'aide de mécanismes IGP comme Flex-Algo, tandis qu'un PCE ou un contrôleur externe peut calculer des politiques SR explicites à partir de contraintes à l'échelle du réseau. La bande passante est la contrainte qui exige une vue unique : le segment routing tire son évolutivité de l'absence de signalisation des réservations saut par saut ; le total cumulé de ce que chaque politique a réservé est donc tenu de manière centralisée. Vous fixez cette valeur par politique, et elle ne s'ajuste pas aujourd'hui en fonction du trafic mesuré. RSVP-TE adopte l'approche inverse et signale une réservation à chaque saut.
Quatre étapes mènent de l'activation du segment routing à une politique en service dans le réseau.
Les deux premières sont une configuration initiale unique sur les routeurs. Les deux dernières se répètent pour chaque politique que vous créez.
Activer le segment routing
IS-IS transporte les extensions segment routing sur chaque routeur, avec les extensions d'ingénierie de trafic, de sorte que la bande passante des liens et les admin groups sont également annoncés. Les labels proviennent du segment routing lui-même.
Exporter la topologie vers le contrôleur
Un routeur redistribue la base link-state dans BGP-LS avec distribute bgp-ls et établit un peering avec le contrôleur.
Définir la politique et ses contraintes
Une politique désigne un routeur de tête, une extrémité et les contraintes à respecter. Le contrôleur calcule le chemin à partir de la topologie en temps réel et renvoie une liste de segments, c'est-à-dire la liste des labels que le routeur de tête imposera au paquet.
L'installer, puis la maintenir à jour
Le contrôleur envoie la politique via PCEP, et le routeur de tête confirme qu'elle est active et qu'il achemine le trafic sur celle-ci. Si la topologie change ensuite, la même politique est mise à jour sur place au lieu d'être reconstruite.
Comment chaque contrainte modifie le chemin renvoyé par le contrôleur.
Sélectionnez une contrainte ci-dessous pour voir le chemin et les labels qu'elle produit. Chaque liste de segments et chaque métrique affichées ici proviennent de sorties enregistrées dans le laboratoire commun.
Faites défiler le schéma latéralement pour suivre le chemin
Cinq contraintes et le chemin renvoyé par chacune
- Rester sur les liens bleus, une contrainte d'affinité de lien
- Chemin R3 vers R4. Liste de segments 16004. Métrique agrégée 10, un saut. Chaque lien du chemin doit porter le tag BLUE, et le lien direct de R3 à R4 le porte : un seul segment de nœud suffit. Politique
R3_R4_BLUE,affinity-set BLUE_ONLY. - Rester sur les liens jaunes, une contrainte d'affinité de lien
- Chemin R3 vers R2 vers R4. Liste de segments 16002, 16004. Métrique agrégée 20, deux sauts. Le tag YELLOW est requis sur chaque lien : le lien direct est exclu et le contrôleur passe par R2, sans qu'aucune métrique ne soit modifiée dans le réseau. Politique
R3_R4_YELLOW,affinity-set YELLOW_ONLY. - Réserver 40 Gbps, une contrainte de bande passante
- Chemin R3 vers R2 vers R4. Liste de segments 16002, 16004. Métrique agrégée 20, avec 40 Gbps réservés. Le même chemin, avec de la capacité associée : le contrôleur a vérifié que les deux liens pouvaient transporter 40 Gbps avant toute installation, et a enregistré la réservation dans son propre registre. Politique
R3_R4_YELLOW,bandwidth 40 gbps. - Choisir le peer de sortie, egress peer engineering
- Chemin R3 vers R2 vers AS 101. Liste de segments 16002, 25600. Métrique agrégée 10, un saut plus la sortie. 25600 est le BGP Peer SID que R2 a alloué pour son peering avec AS 101 : la liste de segments se termine donc en désignant une sortie. Politique
R3_R2_EPE. - Cette sortie, sur les liens bleus, affinité plus egress peer engineering
- Chemin R3 vers R1 vers R2 vers AS 101. Liste de segments 16001, 16002, 25600. Métrique agrégée 20, deux sauts plus la sortie. Les deux contraintes à la fois : la sortie reste AS 101, et le chemin qui y mène doit rester sur des liens BLUE, le contrôleur fait donc le détour par R1. Politique
R3_R2_EPE_BLUE,affinity-set BLUE_ONLY.
Chaque liste de segments, métrique et nom de politique présentés ici proviennent de la note d'application commune d'IP Infusion et de Vegvísir. Chacun y figure sous forme de sortie en direct de show traffic-eng policy <name> detail sur le contrôleur. La syntaxe de Traffic Dictator est documentée sur vegvisir.ie/documentation.
Le routeur d'entrée peut choisir par quel peering le paquet sort.
L'ingénierie de trafic s'arrête généralement à votre propre bordure, alors que l'egress peer engineering va un saut plus loin : le routeur d'entrée choisit par quel peering le paquet sort. Lorsque le transit coûte plus cher que le peering, ce choix réduit les coûts.
Un exemple illustrant le mécanisme, pas une mesure de laboratoire.
Quatre routeurs envoient chacun 30 Gbps vers une même destination, répartis sur deux peerings privés de 100 Gbps préférés parce qu'ils coûtent moins cher que le transit. L'un de ces peerings tombe ensuite en panne.
Avec BGP standard, la totalité des 120 Gbps arrive sur le peering restant, et chaque service qui le traverse se dégrade en même temps.
Une contrainte de bande passante amène le contrôleur à n'admettre que ce que le peering peut transporter : trois politiques arrivent sur le peering restant et la quatrième emprunte son deuxième chemin candidat via le transit.
Résultat : une faible dépense de transit, tandis que tout le reste du trafic sur le peering continue de fonctionner.
Chaque peering reçoit son propre label
egress-engineering sur le routeur de bordure alloue un BGP Peer SID pour ce peering et l'annonce, afin que le contrôleur puisse placer une sortie au bas d'une liste de segments.
L'affinité de lien s'applique jusqu'à la bordure
Un BGP Peer SID ne porte aucun attribut de lien : vous attribuez donc une affinité et une bande passante au peer de sortie sur le contrôleur, qui les fait correspondre au SID annoncé.
Utiliser la sortie la plus proche disposant de capacité libre
Une politique avec une extrémité nulle demande la sortie adéquate la plus proche : le contrôleur choisit la sortie qualifiée la plus proche du routeur de tête, et le trafic sort avant de traverser votre backbone.
Fonctionnalité du contrôleur, hors du périmètre de la validation commune : les extrémités nulles nécessitent l'orientation par couleur, alors que le laboratoire commun a utilisé l'orientation par loopback de service tout au long des tests.
Un peering en panne est visible dans l'état de la politique
Lorsque le voisin tombe, le peer SID est retiré et la politique de sortie échoue, et cet échec est signalé dans l'état de la politique.
Ce que le laboratoire commun a testé, et les résultats obtenus.
IP Infusion et Vegvísir Systems ont conçu cette architecture ensemble et l'ont publiée. Le tableau ci-dessous présente chaque fonctionnalité testée, avec le résultat de chaque test.
| Capacité | Méthode de test | Résultat |
|---|---|---|
| Export de topologie | Base IS-IS de niveau 2 redistribuée dans BGP-LS sur un routeur | R3 a exporté 34 éléments d'information link-state : 5 nœuds, 10 liens, 19 préfixes. La table du contrôleur les indiquait comme reçus. |
| Chemin explicite | Sauts stricts nommés dans la politique, plus une réservation de 2 Gbps | Liste de segments [16001, 16002, 16005] installée. |
| Contrainte de bande passante | Une valeur de bande passante portée par le chemin candidat | Une réservation de 2 Gbps sur la politique à chemin explicite a été vérifiée au moment du calcul et enregistrée dans la base du contrôleur, visible sous forme de bande passante non réservée réduite sur chaque lien du chemin. Les politiques d'affinité ont utilisé le même mécanisme à 40 Gbps. |
| Affinité de lien | Deux politiques entre la même paire de routeurs, une par admin group | BLUE a produit [16004] avec la métrique 10, YELLOW a produit [16002, 16004] avec la métrique 20. Mêmes extrémités, chemins différents, aucune métrique modifiée nulle part. |
| Mappage de services | Deux clients L3VPN sur des loopbacks de service distinctes | Chaque VRF a été résolue sur sa propre politique. Un ping dans VRF101 a été capturé sur le routeur de transit et portait les labels de transport et VPN attendus. |
| Diversité de chemins | Deux politiques placées dans le même groupe disjoint | Les deux politiques ont toujours emprunté des liens différents, sans aucune affinité ni aucun chemin explicite configuré. |
| ECMP et anycast SID | Un prefix SID partagé, annoncé par deux routeurs avec le node flag désactivé | Deux listes de segments fusionnées en une seule, ce qui économise de l'espace dans la table de commutation. |
| Egress peer engineering | Un BGP Peer SID alloué pour un peering externe, vers lequel le trafic est orienté | Liste de segments [16002, 25600], le dernier label désignant le peering et non un routeur. L'ajout d'une affinité a produit [16001, 16002, 25600]. |
| Basculement de contrôleur | Contrôleur principal arrêté alors que des politiques lui étaient déléguées | Le routeur a redélégué chaque politique au second contrôleur. Aucun état n'a été synchronisé entre les deux. |
| Perte totale des contrôleurs | Tous les contrôleurs arrêtés | Politiques retirées, routes de service résolues via IS-IS segment routing, next hop inchangé. Les entrées de remplacement étaient installées et actives au moment de la lecture de la table. |
La validation a été réalisée sur une seule plateforme. L'architecture testée repose sur IS-IS, BGP-LS et PCEP standard : la conception est donc transposable, et la prise en charge par plateforme et par version doit être vérifiée dans la liste de compatibilité matérielle et la matrice de fonctionnalités pour l'équipement que vous envisagez.
Ce qui se passe lorsqu'un contrôleur est perdu, et lorsque tous le sont.
Le trafic continue de circuler dans les deux cas. Si un contrôleur est perdu, les routeurs transfèrent leurs politiques vers un autre, et si tous sont perdus, les services reviennent au plus court chemin que l'IGP calculait déjà.
Si un contrôleur est perdu, les routeurs redélèguent eux-mêmes les politiques
Chaque politique est déléguée au contrôleur qui l'a créée, et lorsque ce contrôleur cesse de répondre, le routeur la redélègue à un autre. Comme le mécanisme s'exécute dans le routeur et non entre les contrôleurs, les contrôleurs ne partagent jamais d'état, si bien qu'ajouter un troisième contrôleur ne coûte rien en synchronisation d'état.
Si tous les contrôleurs sont perdus, tout est de nouveau résolu via IS-IS
Les politiques sont retirées et les routes de service sont résolues via IS-IS segment routing. Le next hop BGP reste identique.
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 désigne une entrée SR Policy. Deux services, deux chemins d'ingénierie de trafic différents. Colonnes condensées à partir de la sortie complète 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 désigne une entrée BGP résolue par IS-IS segment routing. Le next hop BGP des routes VPN est inchangé. Ce qui change, c'est la manière dont il est résolu, via IS-IS segment routing au lieu d'une politique, ce qui explique la différence de label sortant et d'interface. Les deux entrées avaient 16 secondes au moment de la lecture de la table. Colonnes condensées à partir de la sortie complète.Côté routeur, la configuration est un IS-IS et un BGP ordinaires, avec un seul bloc PCEP ajouté.
Voici des extraits de la validation commune, annotés. Comme Traffic Dictator utilise une CLI standard du secteur, la configuration du contrôleur est aussi lisible que celle du routeur, de sorte qu'un seul ingénieur peut intervenir sur les deux moitiés.
PCEP Association validée
Il est à état : le contrôleur sait si le routeur a installé la politique et achemine le trafic sur celle-ci, et il nécessite une session par routeur de tête. C'est l'option utilisée lors de la validation commune.
BGP SR-TE Le moins de sessions
Les politiques sont transportées sous forme de routes BGP : elles passent par vos route reflectors existants au lieu de nécessiter une session vers chaque routeur de tête. Sur un grand réseau, c'est la différence entre quelques sessions et des centaines.
! 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-familyCe que fait chaque ligne
distribute bgp-lsconstitue à lui seul l'export : IS-IS transmet sa base à BGP.- Le contrôleur n'est qu'un voisin BGP de plus, dans son propre système autonome.
link-stateest la famille d'adresses qui transporte la topologie. Trois types d'informations y circulent : Node, avec les system IDs et le segment routing global block ; Link, avec la métrique, la bande passante, l'admin group et l'adjacency SID ; et Prefix, avec les préfixes et leurs SID.- Un seul routeur a besoin de cette configuration, car il réannonce la base link-state que l'ensemble du niveau IS-IS lui a déjà transmise.
Extrait de la note d'application commune, IP Infusion et Vegvísir Systems, août 2025. Vérifiez la syntaxe actuelle sur 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.1Ce que fait chaque ligne
segment-routing pcepindique au contrôleur que ce routeur peut recevoir des listes de segments plutôt que des tunnels RSVP.pce instantiationest l'autorisation qui permet au contrôleur de créer des politiques en plus de les mettre à jour, de sorte qu'une politique peut naître sur le contrôleur plutôt que sur le routeur.- La session annonce ensuite ses capacités au contrôleur : stateful PCE, LSP instantiation et SR PCE capability apparaissent toutes comme prises en charge.
Extrait de la note d'application commune, IP Infusion et Vegvísir Systems, août 2025. Vérifiez la syntaxe actuelle sur 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-engineeringCe que fait chaque ligne
admin-groupassocie un nom à une position de bit. Étiquetez une interface et l'IGP l'annonce : le contrôleur voit le tag sans session supplémentaire.- Vous choisissez les noms. Ici, ce sont BLUE et YELLOW, mais dans un réseau réel ils décrivent généralement l'actif, par exemple un circuit loué, un chemin sous-marin ou un anneau à faible latence.
egress-engineeringetpeer-nodeallouent ensemble le BGP Peer SID de ce peering. Sans lui, une politique n'a aucun moyen de désigner cette sortie. Notez que les deux blocs de ce panneau sont configurés sur des routeurs différents.- Le routeur de bordure annonce le peer SID dans BGP-LS, soit directement au contrôleur, soit au routeur qui détient déjà la session avec le contrôleur et qui le réannonce. Dans les deux cas, il s'agit d'une déclaration de voisin BGP-LS supplémentaire.
Extrait de la note d'application commune, IP Infusion et Vegvísir Systems, août 2025. Vérifiez la syntaxe actuelle sur 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 gbpsCe que fait chaque ligne
- L'affinity map donne aux deux moitiés les mêmes noms pour les mêmes bits. Le bit 1 s'appelle YELLOW sur le routeur comme sur le contrôleur : les deux concordent sans couche de traduction.
constraint include-allsignifie que chaque lien du chemin doit porter le tag.endpointetservice-loopbackrattachent ensemble un service. Chaque service reçoit son propre loopback comme next hop, de sorte que deux services entre la même paire de routeurs peuvent emprunter des chemins différents.priority 7 7définit la priorité d'établissement et de maintien. C'est elle qui détermine qui cède de la bande passante lorsqu'une politique plus importante en a besoin.candidate-path preference 200est la tentative principale, et l'ajout d'un chemin avec une préférence inférieure décrit la solution de repli au sein de la même politique.
Extrait de la note d'application commune, IP Infusion et Vegvísir Systems, août 2025. La documentation de Traffic Dictator est publiée sur vegvisir.ie.
L'ingénierie de trafic en questions
Qu'est-ce qu'un contrôleur SR-TE ?
Faut-il un contrôleur pour utiliser le segment routing ?
Traffic Dictator est-il obligatoire, ou pouvons-nous utiliser un autre contrôleur ?
Qui fournit et assure le support de chaque moitié de cette solution ?
Dois-je remplacer mes routeurs existants pour ajouter un contrôleur SR-TE ?
Pouvons-nous migrer depuis RSVP-TE sans reconstruire nos services ?
La réservation de bande passante peut-elle suivre le trafic mesuré ?
L'ingénierie de trafic SRv6 est-elle prise en charge dans cette conception ?
Vous souhaitez le laboratoire complet ?
Un téléchargement court et technique qui va plus loin que cette page : la note d'application segment routing.
Note d'application Segment Routing
Formulaire rapide. Votre PDF s'ouvre dans un nouvel onglet immédiatement après l'envoi.
✓ Ouverture de votre PDF dans un nouvel onglet…
S'il ne s'est pas ouvert, utilisez le lien ci-dessous.
Passez à une preuve de concept.
Vegvísir Systems met Traffic Dictator à disposition pour l'évaluation et les preuves de concept sans licence, dans la limite de 100 politiques, et OcNOS est disponible sous forme de machine virtuelle. Indiquez-nous ce que vous souhaitez orienter : nous définirons le périmètre sur la bonne paire, puis dimensionnerons le déploiement en production.
Souhaitez-vous que nous vous contactions ?
Laissez vos coordonnées et un ingénieur IP Infusion vous présentera ce que l'ingénierie de trafic donnerait sur votre réseau. Nous ne vous contacterons que si vous le souhaitez.