Dans mon précédent article, j’expliquais les fondamentaux de Segment-Routing. Peut-être certains d’entre vous se demandent encore à quoi cela peut servir. Soyez un peu patients vous n’allez pas être déçus… mais allons y doucement. Dans cet article je vais montrer un cas simple d’utilisation pour détourner le trafic de sa route normale (fournie par l’IGP).
Je continue d’utiliser le même lab que précédemment, avec les mêmes règles d’adressage. N’hésitez pas à le relire si ce n’est pas clair pour vous.
Dans ce test je vais m’appuyer sur la VRF TEST-110. Mon infrastructure core (routeurs R1 à R14) est configurée avec le protocole BGP et le support de la SAFI VPNV4 unicast. Les routeurs R1 et vR11 sont route-reflectors. Pour ceux qui sont un peu perdus, cela signifie que tous les routeurs du backbone vont avoir des peerings IBGP avec R1 et R11. Ces derniers vont relayer les routes sur le coeur.
Dans mon infrastructure, SITE-1-LAN envoie 2 préfixes IPv4 (10.0.110.0/30 et 10.0.110.64/30) à R4 en EBGP (VPNV4 unicast VRF TEST-110). Note: la commande tapée cei-dessous est “show bgp vpnv4 unicast vrf TEST-110 neighbors 10.0.110.1 advertised-routes”
Ces routes sont reçues par R4, annoncées en BGP sur le backbone via les route-reflectors. A l’autre extrémité, R14 annonce ces routes à SITE-2-LAN (vous noterez le next-hop qui est la loopback0 de R4).
De la même manière SITE-2-LAN envoie les préfixes IPv4 (10.0.110.4/30 et 10.0.110.68/30) qui sont reçus par R14, relayées par les route-reflectors vers R4, qui les annonce à SITE-1-LAN.
Si je regarde R4, je vois que pour joindre 10.0.110.69 (adresse annoncée par SITE-2-LAN), le label apposé est 16014, qui correspond au Node SID de R14 (10.0.0.14 étant le next-hop BGP de 10.0.110.68/30).
R4#sh ip cef vrf TEST-110 10.0.110.69 10.0.110.68/30 nexthop 10.0.1.5 HundredGigE0/1/3 label [16014|16014](ptr:0x79701B080058)-(local:16014) 23
De la même manière, sur R14, je vois que pour joindre 10.0.110.65 (adresse annoncée par SITE-1-LAN), le label apposé est 16004, qui correspond au Node SID de R4 (10.0.0.4 étant le next-hop BGP de 10.0.110.64/30).
R14#sh ip cef vrf TEST-110 10.0.110.65 10.0.110.64/30 nexthop 10.0.1.16 TenGigabitEthernet0/0/0 label [16004|16004](ptr:0x79E6D01EA330)-(local:16004) 17
Aussi très naturellement, un traceroute entre SITE-1-LAN et SITE-2-LAN empruntera le chemin R4-R2-R12-R14. Notez bien que les routeurs d’extrémité dans cet exemple ne sont connectés que sur les routeur du bas (R4 et R14). On remerciera les fonctions MPLS OAM qui permettent de retourner les labels dans la trace, décidément très pratique pour troubleshooter.
SITE-1-LAN#traceroute vrf TEST-110 10.0.110.69 source 10.0.110.65 Type escape sequence to abort. Tracing the route to 10.0.110.69 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.110.1 1 msec 0 msec 0 msec 2 10.0.1.5 [MPLS: Labels 16014/23 Exp 0] 0 msec 1 msec 1 msec 3 10.0.1.11 [MPLS: Labels 16014/23 Exp 0] 1 msec 0 msec 1 msec 4 10.0.110.5 [MPLS: Label 23 Exp 0] 1 msec 1 msec 0 msec 5 10.0.110.6 1 msec * 1 msec
A ce stade je rajoute 100ms de latence dans chaque sens sur la liaison R2-R12, sur le chemin des paquets. L’IGP ne converge pas sur la latence (nous verrons cela dans les prochains articles) aussi la performance est impactée. J’observe maintenant un RTT de 200ms.
SITE-1-LAN#ping vrf TEST-110 10.0.110.69 source 10.0.110.65 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.110.69, timeout is 2 seconds: Packet sent with a source address of 10.0.110.65 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 200/200/201 ms
Un nouveau traceroute montre clairement le chemin R2-R12 incriminé.
SITE-1-LAN#traceroute vrf TEST-110 10.0.110.69 source 10.0.110.65 Type escape sequence to abort. Tracing the route to 10.0.110.69 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.110.1 0 msec 0 msec 1 msec 2 10.0.1.5 [MPLS: Labels 16014/23 Exp 0] 201 msec 201 msec 200 msec 3 10.0.1.11 [MPLS: Labels 16014/23 Exp 0] 200 msec 201 msec 201 msec 4 10.0.110.5 [MPLS: Label 23 Exp 0] 201 msec 201 msec 200 msec 5 10.0.110.6 201 msec * 201 msec
Une première policy
Dans cet article je vais faire une règle simple pour statiquement forcer le trafic à prendre une route alternative R4-R2-R1-R11-R12-R14.
Il existe plusieurs méthodes pour faire cela. Ici je vais choisir de créer une interface Tunnel 110 de type MPLS-TE sur R4 et R14, avec la description complète du chemin à emprunter. Ci-dessous l’exemple sur R4.
interface Tunnel110 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 10.0.0.14 tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 1 explicit name R2-R1-R11-R12 segment-routing ! ip explicit-path name R2-R1-R11-R12 enable index 1 next-label 16002 index 2 next-label 16001 index 3 next-label 16011 index 4 next-label 16012 index 5 next-label 16014
Je dois aussi muscler un peu ma configuration IS-IS par rapport à mon précédent article.
router isis 1 net 49.0000.0000.0004.00 router-id Loopback0 metric-style wide segment-routing mpls passive-interface Loopback0 mpls traffic-eng router-id Loopback0 mpls traffic-eng level-1
Vous aurez noté la configuration “autoroute announce” dans mon tunnel 110. Cela permet automatiquement de remplacer le chemin IGP par le chemin indiqué par le tunnel, et ainsi d’attirer tout le trafic qui a pour next-hop 10.0.0.14 dans le tunnel. Je vérifie que mon tunnel est up. On peut voir la liste des labels configurés.
Je peux regarder la CEF sur R4 en demandant tous les détails internes. Je peux voir toute la chaîne de labels qui vont être appliqués. Si vous avez les yeux affutés vous constaterez que le label 16002 n’est pas ajouté malgré la configuration. Normalement à ce stade vous devriez avoir la réponse. Allez je vous donne un indice: le PHP. R2 étant directement connecté, R4 ne doit pas mettre le label 16004 mais simplement envoyer le paquet sur l’interface vers R4 (Hu0/1/3)
Si je ping à nouveau, je vois que me performance est bien meilleure:
SITE-1-LAN#ping vrf TEST-110 10.0.110.69 source 10.0.110.65 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.110.69, timeout is 2 seconds: Packet sent with a source address of 10.0.110.65 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Et on peut vérifier le chemin emprunté avec un traceroute qui me confirme que les bons labels sont appliqués.
SITE-1-LAN#traceroute vrf TEST-110 10.0.110.69 source 10.0.110.65 Type escape sequence to abort. Tracing the route to 10.0.110.69 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.110.1 1 msec 0 msec 0 msec 2 10.0.1.5 [MPLS: Labels 16001/16011/16012/16014/0/23 Exp 0] 1 msec 1 msec 1 msec 3 10.0.1.6 [MPLS: Labels 0/16011/16012/16014/0/23 Exp 0] 2 msec 1 msec 1 msec 4 10.0.1.9 [MPLS: Labels 0/16012/16014/0/23 Exp 0] 1 msec 1 msec 1 msec 5 10.0.1.13 [MPLS: Labels 0/16014/0/23 Exp 0] 1 msec 1 msec 1 msec 6 10.0.110.5 [MPLS: Labels 0/0/23 Exp 0] 1 msec 1 msec 1 msec 7 10.0.110.6 1 msec * 1 msec
Optimisons un peu…
Au lieu de forcer tout le chemin, je vais juste modifier mon tunnel 110 pour forcer le passage sur le lien R1-R11. Inutile d’indiquer que je souhaite passer par R2 ou par R12. Le gros avantage de cette approche est que je vais pouvoir utiliser tous les chemins disponibles de R4 à R1, puis de R11 à R14. Le support d’ECMP y compris pour le traffic engineering est une propriété très agréable de Segment-Routing.
Je change le chemin pour mon tunnel 110 sur R4 et R14 (je montre les modifications de R4 ci-dessous).
ip explicit-path name R1-R11 enable index 1 next-label 16001 index 2 next-label 16011 index 3 next-label 16014 ! interface Tunnel110 tunnel mpls traffic-eng path-option 1 explicit name R1-R11 segment-routing
Je vérifie que mon tunnel est up et que le chemin est le bon.
R4#sh mpls traffic-eng tunnels segment-routing | s Oper|Path Info Admin: up Oper: up Path: valid Signalling: connected Segment-Routing Path Info (isis level-1) Segment0[Node]: 10.0.0.1, Label: 16001 Segment1[Node]: 10.0.0.11, Label: 16011 Segment2[Node]: 10.0.0.14, Label: 16014
Je peux voir dans mon traceroute que moins de labels sont appliqués (seuls les labels des Node SIDs de R1 et R11 sont ajoutés). Mon ingénierie de trafic me permet d’éviter le lien avec une forte latence.
SITE-1-LAN#traceroute vrf TEST-110 10.0.110.69 source 10.0.110.65 Type escape sequence to abort. Tracing the route to 10.0.110.69 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.110.1 0 msec 0 msec 0 msec 2 10.0.1.5 [MPLS: Labels 16001/16011/16014/0/23 Exp 0] 2 msec 1 msec 2 msec 3 10.0.1.6 [MPLS: Labels 0/16011/16014/0/23 Exp 0] 1 msec 1 msec 1 msec 4 10.0.1.9 [MPLS: Labels 0/16014/0/23 Exp 0] 1 msec 1 msec 1 msec 5 10.0.1.13 [MPLS: Labels 16014/0/23 Exp 0] 1 msec 1 msec 1 msec 6 10.0.110.5 [MPLS: Labels 0/0/23 Exp 0] 1 msec 1 msec 1 msec 7 10.0.110.6 1 msec * 1 msec
Il n’est pas simple de confirmer l’ECMP sur un traceroute. Aussi je vais vérifier sur R4 que toutes les options de routage vers R1 (premier saut spécifié) sont utilisées.
Histoire d’en avoir le coeur net, j’envoie 1Gbps de trafic entre SITE-1-LAN et SITE-2-LAN. Pour avoir un load balancing efficace j’élargis un peu mes préfixes des 2 côtés (je passe de /30 à /29). Avec 4 hosts simulés de chaque côté et un test “many to many” j’ai suffisamment de flux pour observer un partage de charge efficace entre les liens R4-R2 et R4-R3.
R4#sh int te 0/0/0 | i output rate 30 second output rate 496994000 bits/sec, 44010 packets/sec R4#sh int hu 0/1/3 | i output rate 30 second output rate 497018000 bits/sec, 44020 packets/sec
Conclusion
Ce premier test a permis de mettre en avant comment Segment-Routing permettait assez simplement de contrôler de manière fine comment router les données sur le réseau sans créer d’états sur les routeurs. Le simple fait de rajouter les labels adéquats en entrée du réseau suffit à maîtriser le chemin. Contrairement à MPLS-TE dans le passé, nul besoin de signaler les tunnels avec RSVP: on diminue le nombre d’états et du coup on améliore le scale et on simplifie grandement. Toutes les configurations ici étaient statiques: j’ai défini moi-même les chemins à emprunter… Si cela peut rendre quelques services on peut se douter qu’on va devoir trouver mieux pour supporter le facteur d’échelle. Dans mes prochains articles on va passer à la vitesse supérieure et voir comment Segment-Routing va pouvoir décupler les capacités de notre infrastructure.
Références
Authors
