J’ai testé… Segment Routing pour découper un réseau
Dans un précédent article, j’ai montré comment Segment Routing pouvait permettre de réaliser une ingénierie de trafic basique. Dans mon exemple j’avais créé mon tunnel manuellement: on comprend bien que cela n’est pas très réaliste à grande échelle. Nous allons voir dans cet article comment faire une ingénierie de trafic plus pertinente en utilisant Flex-Algo et On-Demand Next-hop (ODN). Ne paniquez pas, je vais vous expliquer tout cela simplement! Un grand merci à mon collègue Loïc Roque pour ses relectures et précieux conseils.
Partons d’un besoin assez courant, le découpage d’un réseau en plusieurs plans disjoints (aka Network slicing). L’objectif est de pouvoir router certaines catégories de trafic sur des plans spécifiques (un sous-ensemble de liens/routeurs).
Je vais utiliser le même lab que dans mes précédents articles. Il est composé de routeurs Catalyst 8500 avec IOS-XE 17.12.1a.
Mon objectif va être de découper ce réseau en 2: un plan avec tous les liens du haut (le plan 128, vous allez comprendre pourquoi bientôt), et l’autre avec tous les liens du bas (le plan 129). Concrètement cela revient à créer ces 2 topologies à partir de mon infrastructure globale.
Créer des plans complètement disjoints va pouvoir être intéressant quand on va vouloir fournir des services redondés qui empruntent des chemins complètements distincts, sans pour autant créer 2 infrastructures différentes.
Flex-algo, votre meilleur ami
Pour créer un plan, vous allez pouvoir utiliser flex-algo. Cela consiste tout d’abord à définir une topologie spécifique au sein de votre IGP. Dans mon exemple, je vais configurer les flex-algo 128 et 129 dans IS-IS (les plans de 0 à 127 sont réservés). Les routeurs R1 et R11 ne sont configurés qu’avec le plan 128, et les routeurs R2 et R12 uniquement avec le flex-algo 129. Les autres routeurs (R3, R4, R13 et R14) sont configurés avec à la fois les flex-algo 128 et 129.
Voici un exemple de la configuration de R4 (avec les 2 flex-algo). Je vous laisse deviner la configuration d’un routeur avec un seul plan. Pour simplifier j’ai supprimé les configurations relatives à TI-LFA et les tunnels TE statiques (voir précédents articles).
router isis 1
net 49.0000.0000.0004.00
router-id Loopback0
metric-style wide
distribute link-state
segment-routing mpls
segment-routing prefix-sid-map advertise-local
affinity-map PLAN128 bit-position 1
affinity-map PLAN129 bit-position 2
flex-algo 128
advertise-definition
affinity
exclude-any
name PLAN129
exit-fa-affinity-attr
!
!
flex-algo 129
advertise-definition
affinity
exclude-any
name PLAN128
exit-fa-affinity-attr
!
!
passive-interface Loopback0
Dans mon exemple j’ai aussi ajouté des affinity-map (que je n’utilise pas ici). L’idée est de pouvoir associer une interface à une affinity-map, ce qui peut avoir pour effet de l’inclure ou la retirer d’un plan. Dans mon exemple, si jamais je place une interface dans l’affinity-map PLAN128, alors elle sera retirée de la topologie flex-algo 129. Voici par exemple comment j’aurais pu marquer l’interface R4-R2 (sur R4).
interface HundredGigE0/1/3 description PAR-R2 mtu 9100 ip address 10.0.1.4 255.255.255.254 ip mtu 9000 ip router isis 1 no negotiation auto isis affinity flex-algo name PLAN129
Cela a pour effet de créer des topologies spécifiques. Prenons le temps de les vérifier. Tout d’abord regardons sur R4 la topologie globale (flex-algo 0). Je vois tous les noeuds de la topologie et des ECMP pour joindre R1, R11 et R13 (j’ai en effet plusieurs routes avec la meme metric).
Si je regarde la topologie du flex-algo 128, je n’ai plus les noeuds R2 et R12 qui ne sont pas inclus dans le plan. Tous mes next-hops sont R3 car c’est le seul chemin disponible.
Si je regarde la topologie du flex-algo 129, je n’ai plus les noeuds R1 et R11 qui ne sont pas inclus dans le plan. Tous mes next-hops sont R2 à l’exception de R3 qui reste joignable directement.
Flex-algo me permet donc de définir des topologis spécifiques. Voyons maintenant comment nous allons les utiliser…
Vous avez dit Segment Routing ?
Vous aviez deviné? Bravo! Il faut maintenant configurer des Node SIDs spécifiques pour nos différents flex-algo. Chaque loopback va être associée à plusieurs Node SIDs (un par flex-algo). Ci-dessous la confuration de R4.
segment-routing mpls ! set-attributes address-family ipv4 sr-label-preferred explicit-null exit-address-family ! global-block 16000 23999 ! connected-prefix-sid-map address-family ipv4 10.0.0.4/32 index 4 range 1 exit-address-family address-family ipv4 algorithm 128 10.0.0.4/32 index 804 range 1 exit-address-family address-family ipv4 algorithm 129 10.0.0.4/32 index 904 range 1 exit-address-family
Le Node SID 804 deviendra le label 16804, le Node SID 904 deviendra le label 16904 etc. selon l’explication faite dans mon premier article. Je peux sur chaque routeur voir tous les Node SID pour les différents flex-algo. Ci-dessous les SID sur R4.
Les labels associés sont programmés dans ma LIB (aka MPLS forwarding-table). Je peux sur R4 voir les labels 16013, 16813 et 16913 qui correspondent respectivement au Node SID de R13 pour les flex-algo 0, 128 et 129. Pour le plan 0, j’ai bien 2 outgoing interfaces. Pour le plan 128, c’est l’interface vers R3 qui est utilisée. Pour le plan 129 c’est l’interface vers R2 (voir diagramme plus haut).
Utiliser les plans créés
A ce stade, tout est prêt niveau dataplane: mes labels sont programmés et prêts à être utilisés. Il reste maintenant à créer les règles d’ingénierie de trafic pour transporter les données sur un plan.
Automated Steering
Automated Steering va me permettre de définir mon ingénierie de trafic en fonction d’un attribut des routes BGP: l’extended community “color”. On va pouvoir configurer cet attribut au niveau du PE via une simple route-map. Cet attribut étant transitif, on peut aussi imaginer le configurer sur le CE pour laisser un site décider de la manière dont il souhaite que son trafic soit forwardé. C’est d’ailleurs ce modèle un peu moins habituel que je vais appliquer dans mon lab.
Sur SITE-1-LAN et SITE-2-LAN je crée une route-map très basique pour appliquer la color 128 pour toutes les routes envoyées vers R4 et R14. Je vous épargne toute la configuration BGP.
route-map SET-COLOR-128 permit 10 match ip address prefix-list ANY set extcommunity color 128
Je peux vérifier que mes routes sont bien colorées (voir “Color:128” dans l’extrait de la table BGP)
Je crée sur R4 une règle d’ingénierie de trafic pour automatiquement utiliser le flex-algo 128 pour les routes avec la color 128 reçues depuis R14. Notez que si color et flex-algo ont dans mon lab le même numéro, ce sont 2 éléments indépendants.
segment-routing traffic-eng
policy USE-128-R14
color 128 end-point 10.0.0.14
candidate-paths
preference 200
constraints
segments
dataplane mpls
algorithm 128
!
!
dynamic
!
!
!
Je peux voir qu’une fois configurée ma policy est fonctionnelle sur R4. Le label 16814 est associé à ma policy. Il correspond au Node SID de R14 dans le flex-algo 128. Ce label 16814 sera automatiquement appliqué par R4 pour tout le trafic à destination des routes avec la color 128 émise depuis R14. On parle d’Automated Steering.
Je réalise évidemment la même chose sur R14 (pour le next-hop R4) pour garantir que le flux retour passer également par le plan 128. Je lance depuis SITE-1-LAN un traceroute vers SITE-2-LAN, depuis des IP qui sont dans les routes avec la color 128.
SITE-1-LAN#trace vrf TEST-110 10.0.110.73 source 10.0.110.65 numeric Type escape sequence to abort. Tracing the route to 10.0.110.73 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.110.1 0 msec 1 msec 0 msec 2 10.0.1.2 [MPLS: Labels 16814/25 Exp 0] 2 msec 1 msec 1 msec 3 10.0.1.1 [MPLS: Labels 16814/25 Exp 0] 1 msec 1 msec 1 msec 4 10.0.1.9 [MPLS: Labels 16814/25 Exp 0] 1 msec 1 msec 1 msec 5 10.0.1.15 [MPLS: Labels 16814/25 Exp 0] 1 msec 1 msec 1 msec 6 10.0.110.5 [MPLS: Labels 0/25 Exp 0] 1 msec 1 msec 1 msec 7 10.0.110.6 1 msec * 1 msec
Je vois bien le trafic passer sur mon plan 128 avec le label escompté, le chemin emprunté est R4 – R3 – R1 – R11 – R13 – R14 (je vous laisse compter les sauts et vérifier les IP dans le schéma initial pour les plus sceptiques d’entre vous).
Je pourrais à ce stade continuer l’exercice et faire des policies pour mes 2 colors 128 et 129 pour tous les next-hop BGP possibles mais cela serait un peu fastidieux. On-Demand Next-Hop va m’aider à simplifier tout cela. A ce stade je supprime la policy ci-dessus de ma configuration.
ODN – On-Demand Next-Hop
On-Demand Next-Hop va en quelque sorte me permettre de définir un “template” qui va être appelé automatiquement quand des routes seront reçues avec une certaine color. Inutile de spécifier le next-hop BGP, la policy sera créée automatiquement dès qu’une route BGP colorée sera reçue.
Je vais créer mes policies on-demand pour associer la color 128 au flex-algo 128, et la color 129 au flex-algo 129 (à nouveau si dans mon lab color et flex-algo ont le même numéro, ce sont des éléments complètement indépendants).
segment-routing traffic-eng
!
on-demand color 128
authorize
candidate-paths
preference 100
constraints
segments
dataplane mpls
algorithm 128
!
!
dynamic
!
!
!
!
on-demand color 129
authorize
candidate-paths
preference 100
constraints
segments
dataplane mpls
algorithm 129
!
!
dynamic
!
!
!
!
Aussitôt les routes reçues, les policies sont créées. La route de SITE-2-LAN est reçue sur R14 avec la color 128. Aussi R4 crée la policy associée aux next-hop R14 et à la couleur 128. Vous noterez là aussi le label 16814 qui correspond au NodeSID de R14 dans le plan 128.
De même, la route de SITE-1-LAN est reçue sur R4 avec la color 128. R14 crée donc la policy associée aux next-hop R4 et à la couleur 128. Ici on notera l’application du label 16804 qui correspond au NodeSID de R4 dans le plan 128.
Vous noterez également que j’ai utilisé ici une preference de 100 pour ODN alors que j’avais une préférence de 200 dans ma policy précédente (supprimée à ce stade). Si je l’avais laissée en place, elle aurait été préférée à ma policy ODN. Cela peut être très pratique pour créer des exceptions à ODN.
Je change maintenant la couleur de mes routes en appliquant la couleur 129. Je vous donne la route-map ci-dessous et vous épargne à nouveau l’application dans la configuration BGP.
route-map SET-COLOR-129 permit 10 match ip address prefix-list ANY set extcommunity color 129
On peut voir sur R4 qu’il n’y a plus de policy associée à la couleur 128, et qu’il y a maintenant une policy pour la color 129 (avec le label tiré du flex-algo 129). On voit le label 16914 utilisé (Node SID de R14 dans le flex-algo 129).
Un nouveau traceroute montre que j’emprunte maintenant le plan 129 et donc le chemin R4 – R2 – R12 – R14. Vous noterez les 200ms de RTT car j’ai laissé la latence entre R2 et R12 configurée dans un précédent article.
SITE-1-LAN#trace vrf TEST-110 10.0.110.73 source 10.0.110.65 numeric Type escape sequence to abort. Tracing the route to 10.0.110.73 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.110.1 0 msec 1 msec 1 msec 2 10.0.1.5 [MPLS: Labels 16914/25 Exp 0] 201 msec 201 msec 201 msec 3 10.0.1.11 [MPLS: Labels 16914/25 Exp 0] 201 msec 201 msec 201 msec 4 10.0.110.5 [MPLS: Labels 0/25 Exp 0] 201 msec 201 msec 200 msec 5 10.0.110.6 201 msec * 201 msec
Conclusion
Supporter le facteur d’échelle, c’est le propre de Segment Routing. On a vu dans mes précédents articles que l’on pouvait spécifier des chemins sans avoir à créer des états sur les équipements réseau (bye-bye RSVP!). On a pu voir maintenant que l’on pouvait également simplement définir des topologies et les exploiter directement via les protocoles de routage et des policies simples. Le combo flex-algo + ODN doit être votre premier réflexe dès que vous vous lancer dans l’ingénierie de trafic. Essayez d’éviter au maximum les configurations statiques qui ne seront dans tous les cas plus tenables quand le réseau ou les usages deviendront plus importants. Je ne vous ai pas encore tout dit… la suite dans mon prochain article!
Références
- Flex-algo configuration guide sur Catalyst 8000
- ODN – On Demand Next-hop configuration guide sur Catalyst 8000
- Totorial flex-algo sur Segment-routing.net
