Vous l’avez compris de mes précédents articles, Segment Routing permet de contrôler finement depuis la source comment les paquets vont transiter sur le réseau. Dans cet article nous allons voir comment nous allons utiliser cette propriété pour optimiser la disponibilité de votre réseau.
Pour comprendre la problématique, focalisons-nous sur la partie gauche de mon lab. J’ai ajouté de quoi tester proprement. Je vous résume le tout dans le petit schéma ci-dessous.
Imaginons que je coupe le lien entre R4 et R2 (par exemple un shut sur l’interface Hu0/1/3 de R4). La convergence sur R4 est quasi immédiate: IS-IS recalcule immédiatement que le meilleur chemin via R3. R4 reroute donc quasi immédiatement 1Gbps de trafic vers R3… Mais ce dernier n’est pas encore prêt: il n’a pas encore reçu les LSA IS-IS lui annonçant que le lien R4-R2 était down. Pour lui la meilleure route pour joindre la destination est R4 (vous aurez noté la metric de 100 sur le lien R3-R1). R3 renvoie donc les paquets vers R4 qui les renvoie vers R3 etc. On a sur un très court moment (quelques dizaines/centaines de millisecondes) une micro-loop qui peut ajouter quelques instabilité sur le réseau. 1Gbps qui boucle, ca charge vite une liaison!
Regardons déjà les tests sur un shut de l’interface R4-R2 sur R4. Je perds 9604 paquets. Comme mon flux est de 1Gbps avec des paquets de 1400B ca me donne environ 100ms de coupure (je vous épargne les calculs, j’ai fait ça à la louche) Ca parait peu mais j’ai un réseau extrêmement petit et simple, sans latence. Sur un réseau plus complexe on peut facilement monter à la seconde.
L’objectif est de définir en amont un chemin alternatif à utiliser immédiatement en cas de perte d’une liaison. Par exemple définir en amont sur R4 ce qu’il faudrait faire en cas de perte de la liaison R4-R2. Ici par exemple il faudrait préciser qu’il faut envoyer le trafic d’abord vers R3 puis sur l’interface Te0/1/0 vers R1. Ensuite R1 saura se débrouiller et router normalement vers R2 (pas besoin de définir tout le chemin non plus).
Définir un chemin? Oui vous m’avez vu venir, c’est là que Segment Routing va être utile. Il suffira de rajouter quelques labels aux paquets dès qu’une panne sera constatée pour forcer les paquets à prendre le chemin alternatif.
Comprenez bien que l’objectif est d’offrir une continuité de service, garanti sans boucles, pendant que l’IGP converge. Plutôt que de tuner votre IS-IS pour avoir une convergence optimale de quelques centaines de millisecondes, vous pouvez le laisser un peu tranquille puisque vous savez que votre trafic n’est pas impacté. La promesse d’une convergence en moins de 50ms sans effort devrait vous séduire.
Certains d’entre vous vont peut-être me dire que tout cela n’est pas nouveau, qu’ils font cela depuis 20 ans avec MPLS-TE fast-reroute. On est bien d’accord là-dessus! Mais dans le cas de MPLS fast-reroute, il est nécessaire de provisionner les chemins de backups sur tous les routeurs avec RSVP qui va signaler les tunels et définir les labels sur tous les routeurs traversés. Rappelez-vous de l’avantage principal de Segment-Routing: les états sont dans les paquets, pas dans les routeurs. On oublie RSVP, on se contente d’apposer les bons labels en amont et on a gagné.
TI-LFA – Transport Independent Loop Free Alternate
C’est le nom de la solution que l’on va utiliser ici pour définir nos chemins de backup:
- LFA – Loop Free Alternate – Un chemin alternatif garanti sans boucle
- TI – Topology Independent – Une solution qui fonctionne pour toutes les topologies
Je vous recommande de regarder ce tutorial sur segment-routing.net pour comprendre dans le détail cette solution. Ici je vais vulgariser les éléments principaux.
Globalement on va utiliser notre topologie IS-IS pour calculer un peu plus que le best path habituel. En s’appuyant sur notre LSDB (notre topologie), il est possible de déterminer pour chaque lien, sur chaque routeur:
- Un domaine P – qui est l’ensemble des routeurs joignables depuis la source sans passer par le lien en échec. Dans notre cas, en cas de perte du lien R4-R2, le routeur R4 peut continuer à joindre le routeur R3. Il ne peut pas joindre R1 car le meilleur chemin depuis R4 pour joindre R1 est de passer par le lien R4-R2 qu’on cherche à éviter (metric 20 contre 110 via R3).
- Un domaine Q – qui est l’ensemble des routeurs joignables depuis le récepteur sans passer par le lien en échec. Dans notre cas, le routeur R2 peut continuer à joindre uniquement R1.
Dans certains cas, il existe un routeur à la fois dans le domaine P et le domaine Q (on parle du PQ-node). il suffit alors d’envoyer nos paquets vers ce routeur et on sait qu’on ne bouclera pas de la source vers ce noeud, ni de ce noeud vers la destination (propriété des domaines P et Q). Malheureusement toutes les topologies ne permettent pas d’avoir ce cas de figure. On ne couvre donc pas 100% des cas de panne.
C’est là qu’on va apprécier TI-LFA, qui marche dans tous les cas de figure. Le principe est que que si un chemin de backup existe, alors on va avoir une connexion directe les domaines P et Q (dans notre cas la liaison R3-R1). Au niveau de R4, un calcul de topologie permet donc de définir un chemin de backup qui consisterait à d’abord envoyer le paquet à R3 (domaine P) puis de forcer sur R3 le paquet à passer sur l’interface R3-R1 qui interconnecte nos domaines P et Q. Et pour forcer nos paquets à prendre un chemin particulier, vous avez compris que Segment Routing va être parfait.
Node SID et Adjacency SID
Forcer le paquet à passer par R3, vous savez faire. On rajoute le label qui correspond au Node SID de R3 (16003 dans mon lab). Pour forcer le paquet à passer sur l’interface R3-R1 on va avoir besoin d’un autre type de SID (Segment IDentifier), les adjacency SIDs, qui correspondent à des adresses IP sur des interfaces. Chaque routeur va localement définir des SIDs pour chaque liaison en plus de son Node SID, et va les annoncer dans l’IGP en plus du Node SID. Si je prends mon lab, R4 connaît ainsi le label que R3 doit recevoir pour forcer le trafic à être routé sur le lien R3-R1 (ce label va shunter tout process de routing: on exécute brutalement l’instruction).
La particularité des Adjacency SID est qu’ils n’ont une existence que locale au noeud sur lequel ils sont définis. Seul R3 pourra exécuter l’instruction de l’Adjacency SID qui correspond à la liaison R3-R1. De ce fait les labels associés ne sont pas programmés dans les LIB (tables de forwarding MPLS) des autres routeurs. Cette existence locale offre un avantage considérable: on se moque éperdument d’avoir les mêmes adjacency SIDs sur des routeurs distincts. Il est possible de définir manuellement les adjacency SIDs sur chaque interface mais compte tenu de la portée locale, on peut tout aussi bien laisser le routeur décider (comportement par défaut).
R3 crée un adjacency SID associé à l’IP 10.0.1.0 (interco vers R1), et l’ajoute dans ses annonces IS-IS. Tous les routeurs du réseau connaissent cet adjacency SID et peuvent l’utiliser. Par exemple ci-dessous on voit ces informations dans la database IS-IS de R4.
Revenons à la pratique
Tout d’abord je modifie un peu mes configurations précédentes pour implémenter TI-LFA (je supprime au passage les configurations MPLS-TE de mon précédent test).
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 fast-reroute per-prefix level-1 all fast-reroute ti-lfa level-1 microloop avoidance segment-routing microloop avoidance rib-update-delay 10000 passive-interface HundredGigE0/1/1 passive-interface Loopback0
Je configure également fast-reroute sur mes interfaces IS-IS.
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 load-interval 30 no negotiation auto cdp enable isis network point-to-point isis fast-reroute protection level-1 isis fast-reroute ti-lfa protection level-1
Si l’on se base sur la théorie, R4 va créer un chemin de backup (ou repair-path pour être plus précis) en utilisant d’abord le NodeSID de R3, puis l’adjacency SID de la liaison R3-R1 et l’appliquer sur toutes les routes qui ont pour next-hop le lien R4-R2.
Vérifions notre forwarding table sur R4 pour voir comment joindre maintenant ma destination derrière R2 (le Spirent)
R4#sh ip cef 10.0.10.129
10.0.10.128/25
nexthop 10.0.1.5 HundredGigE0/1/3
repair: attached-nexthop 10.0.0.1 MPLS-SR-Tunnel1
Vous pouvez voir qu’il y a maintenant un repair path: le MPLS-SR-Tunnel1. Je peux voir tous mes repair-paths sur mon routeur (globalement un path par lien à protéger, donc on va avoir 2 tunnels sur R4).
Je peux voir les détails de mon repair path MP1 (ou MPLS-SR-Tunnel1). Cela consiste à d’abord envoyer le paquet sur l’interface Te0/0/0 (interface de R4 vers R3), et de lui ajouter le label 28 (Adjacency SID R3-R1). Peut-être cherchez vous le Node SID de R3. Pourquoi ne voit-on pas le label 16003? Les plus pointus d’entre vous se rappellent qu’on va appliquer la règle du Penultimate Hop Popping en MPLS, le routeur précédent enlève le label… Et comme R4 est le routeur avant R3 dans la topologie il n’a pas besoin d’ajouter le label 16003. Ainsi le paquet arrive directement vers R3 avec le label 28. Et sur R3 la MPLS forwarding table montre que tout paquet qui arrive avec le label 28 va être forwardé vers R1 (interface Te0/1/0).
En cas de coupure de mon lien R4-R2, mon repair path est immédiatement utilisé.
R4#sh ip cef 10.0.10.129 10.0.10.128/25 nexthop 10.0.0.1 MPLS-SR-Tunnel1
Et après 10 secondes (temps configurable – microloop avoidance rib-update-delay 10000) on considère que l’IGP a eu le temps de converger et l’on reprogramme la CEF pour utiliser le next-hop IGP.
R4#sh ip cef 10.0.10.129 10.0.10.128/25 nexthop 10.0.1.2 TenGigabitEthernet0/0/0
Regardons maintenant comment Segment Routing avec TI-LFA ont amélioré la convergence de mon réseau…
Oui vous avez bien vu: zero paquets perdus! Forcément dans mon test je shut l’interface sur R4 donc on peut immédiatement converger vers le repair path (on n’est pas tributaire de la détection d’une perte de lien). Mais mon exemple illustre bien les aspects théoriques de la technologie TI-LFA. Imaginez sur un plus gros réseau, vous aurez sans trop de difficulté une reprise de service de quelques dizaines de millisecondes.
Conclusion
Ce troisième article montre un avantage certain de Segment Routing sur vos backbones: permettre une disponibilité optimale sans avoir besoin de stresser vos IGP. Segment-Routing nous permet de pré-calculer des chemins alternatifs à utiliser immédiatement en cas de panne, sans pour autant devoir les programmer sur l’ensemble des noeuds du réseau. Ces chemins alternatifs sont calculés automatiquement en tirant profit des IGP utilisés (IS-IS ou OSPF). Vous avez pu découvrir ainsi qu’il existait un autre type de SID: les Adjacency SIDs qui vont être utilisés pour forcer un chemin en court-circuitant le routage. Dans mes prochains articles vous découvrirez encore d’autres possibilités offertes par Segment Routing.
Références
- Configuration Guide Catalyst 8000 – TI-LFA avec OSPFv2
- Configuration Guide Catalyst 8000 – TI-LFA avec IS-IS
Authors
