J’ai testé… Segment Routing pour optimiser la latence
Je vais reprendre dans cet article le même lab que dans mon article précédent. J’ai la possibilité de modifier la latence sur le lien R2-R12 (meilleur chemin IGP pour connecter SITE-1-LAN à SITE-2-LAN).
Dans mes précédents articles j’ai montré que Segment Routing pouvait permettre de réaliser simplement de l’ingénierie de trafic. Dans cet article je vais expliquer comment on peut simplement choisir le chemin qui offre la meilleure latence, et ce en réutilisant les concepts déjà vus précédemment.
Mesurer la performance des liaisons
C’est la première étape… On ne peut optimiser que ce que l’on mesure! On va utiliser le protocole TWAMP (détails de l’implémentation donnés ici). Je vais devoir ajouter cette configuration sur tous mes liens. Attention à bien faire la configuration sur les 2 extrémités de chaque liaison. Tout lien qui n’est pas correctement mesuré ne pourra pas être pris en compte par d’éventuelles optimisations. Voici un exemple de configuration sur R2. Notez que j’ai également configuré les mesures de pertes de paquets que je n’utiliserai pas dans ce lab.
performance-measurement interface HundredGigE0/1/3 delay-measurement loss-measurement ! ! interface TenGigabitEthernet0/0/0 delay-measurement loss-measurement ! ! interface TenGigabitEthernet0/0/2 delay-measurement loss-measurement ! ! delay-profile interfaces advertisement accelerated threshold 30 ! ! !
Une fois ces configurations en place, je peux connaître les caractéristiques de performance d’une liaison. Par exemple regardons les détails sur la liaison R2-R12 pour laquelle j’ai configuré une latence de 100ms dans chaque sens.
Vous noterez que la latence est exprimée en microsecondes. On est précis ici! Je vous épargne ici tous les détails (moyennes, fréquences…) et leur customisation possible. Nous allons voir maintenant comment utiliser cette latence dans le calcul du meilleur chemin.
Flex-algo, encore et encore…
Dans mon exemple précédent, flex-algo se basait sur une métrique IGP pour créer des plans (après avoir retiré éventuellement des noeuds/liens). Mais on peut tout aussi bien demander à flex-algo d’utiliser le délai comme métrique. Je crée le flex-algo 130 sur tous mes routeurs pour créer une topologie basée sur la latence des liaisons. Exemple sur R2.
router isis 1 net 49.0000.0000.0002.00 router-id Loopback0 metric-style wide distribute link-state segment-routing mpls segment-routing prefix-sid-map advertise-local ! flex-algo 130 advertise-definition metric-type delay
J’ai supprimé les algo 128 et 129 de mon article précédent dans cet extrait de configuration mais je pourrais tout aussi bien les laisser. Je peux visualiser ma topologie IS-IS de l’algorithme 130 sur R2 et voir les plus courts chemins en fonction du délai. La latence étant forte sur le lien direct R2-R12, on peut constater que R1 est systématiquement privilégié pour joindre R11, R12, R13 et R14.
Segment-Routing, encore et encore…
J’espère que vous l’aviez vu venir! On va maintenant configurer sur tous les routeurs le Node SID pour l’algorithme 130. Dans mon lab je configure le Node SID 1004 sur R4, 1014 sur R14, 1002 sur R2 etc. Je pense que vous avez compris le principe.
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 130 10.0.0.4/32 index 1004 range 1 exit-address-family
Les Node SIDs sont annoncés par IS-IS. Je peux voir sur R4 les Node SIDs de tous les routeurs pour le flex-algo 130.
Les labels MPLS associés sont installés dans la LIB (aka MPLS forwarding table). Je vous épargne cette étape expliquée dans l’article précédent. Et maintenant, nous allons voir comment utiliser tout cela…
Automated Steering et ODN, encore et encore…
Pour ceux qui ont lu mon article précédent vous avez compris le truc je suppose. Je vais créer un “template” on-demand, pour forcer l’utilisation du flex-algo 130 pour joindre toutes les routes BGP qui ont la color 130.
segment-routing traffic-eng
!
on-demand color 130
authorize
candidate-paths
preference 100
constraints
segments
dataplane mpls
algorithm 130
!
!
dynamic
!
Je n’ai plus qu’à marquer mes routes BGP avec la color 130 et les policies vont automatiquement s’instancier.
On peut voir que cette policy va ajouter le label 17014 qui correspond au Node SID 1014 de R14 pour le flex-algo 130. Ce label permettra d’utiliser le chemin qui offre la meilleure latence.
Un traceroute entre SITE-1-LAN et SITE-2-LAN (pour des IP incluses dans mes routes avec la color 130) montre que le chemin utilisé évite le lien R2-R12 qui a une mauvaise latence. Le chemin emprunté ici est R4-R2-R1-R11-R13-R14. On peut voir aussi que le label 17014 est bien ajouté ce qui confirme que ma policy est bien appliquée.
Low latency par application…
Précédemment, j’ai associé une route entière à mon flex-algo 130 low-latency. Dans cet exemple on va voir comment on peut aller un peu plus loin et uniquement utiliser le flex-algo 130 pour le trafic marqué en DSCP 46. Pour cela je vais configurer une policy “per-flow”.
Ici je vais créer un nouveau “template” ODN pour une nouvelle color 131. Ce template va déterminer des actions différentes selon les flux. Pour la forwarding-class 7, je vais appeler la color 130. Pour la forwarding class 0 je vais utiliser le plus court chemin selon la table de routage standard (RIB).
segment-routing traffic-eng
on-demand color 131
authorize
candidate-paths
preference 100
per-flow
forward-class 0 rib
forward-class 7 color 130
J’applique maintenant la color 131 pour les routes BGP pour lesquelles je souhaite avoir cette policy. Je change donc ma route-map sur SITE-1-LAN et SITE-2-LAN. Je rappelle d’ailleurs que si dans mon lab j’applique les colors sur mes routeurs “clients”, cela serait fait plus habituellement sur le PE. Je vous épargne la route-map et la configuration BGP, référez-vous aux précédents articles si ce n’est pas clair.
Et dernière étape, il faut placer mes paquets DSCP 46 dans une forwarding class 7 et laisser les autres dans une forwarding class 0. Je fais tout cela avec des configurations classiques de class-map / policy-map (attention à bien utiliser le type epbr).
class-map match-all REALTIME match dscp ef ! policy-map type epbr QOS-ODN class REALTIME set forward-class 7 class class-default set forward-class 0 ! interface TenGigabitEthernet0/0/2.110 description TEST-110 SR TE encapsulation dot1Q 110 vrf forwarding TEST-110 ip address 10.0.110.1 255.255.255.252 service-policy type epbr input QOS-ODN
Une fois les routes reçues avec la color 131, je peux voir la policy instanciée à partir de mon “template ODN”.
Des pings depuis SITE-1-LAN vers SITE-2-LAN (entre IP incluses dans des routes avec la color 131) montrent le comportement différent selon le DSCP utilisé. Le RTT reste de 200ms pour le trafic non EF, car il est routé selon la RIB (IGP). Par contre le RTT est quasi nul pour le trafic en DSCP 46 routé par le chemin low-latency.
Conclusion
Vous avez pu voir ici à quel point Segment-Routing était une fondation solide. En réutilisant les mêmes concepts que dans mes précédents articles j’ai pu cette fois optimiser les performances du réseau et ce pour certains types de trafic uniquement. Notez que j’ai utilisé un champ DSCP mais sur Catalyst 8000, disposant du moteur de reconnaissance applicative NBAR2 j’aurais tout aussi bien pu optimiser une application spécifique. Merci à nouveau à Loïc Roque pour son aide et sa relecture.
Références
Tags:1 commentaires
Merci pour ses explications riche d'enseignement