Performance Routing – Plus simple et plus performant en version 3

4 min read

Jerome Durand

La dernière release IOS de nos routeurs d’accès 15.4(3)M (3.13S en IOS-XE) a apporté comme toujours son lot de nouveautés! Je tenterai un résumé prochainement mais concentrons nous pour le moment sur ce qui est probablement une des avancées les plus importantes: la sortie tant attendue de la 3ème version de Performance Routing (PfR). Si je devais résumer: on fait mieux et on simplifie! 2 bonnes raisons pour se pencher un peu plus sur le sujet…

PfR c’est quoi ?

PfR signifie Performance Routing. C’est la solution Cisco, intégrée sur les routeurs d’accès d’entreprise (89x, 19xx, 29xx, 39xx, 44xx et ASR 10xx) qui permet de router selon la performance des liens (en temps réel) et non en fonction de critères “statiques” tels que des poids arbitrairement configurés sur des liens. Prenons un exemple tout simple: vous avez 2 liaisons entre vos sites. OSPF vous dit de prendre la première mais on observe subitement 500ms de latence sur celle-ci et une augmentation de la gigue. Ce n’est pas OSPF qui changera le routage pour s’adapter à la situation pour garantir le bon fonctionnement des applications voix/vidéo… PfR est justement là pour cela. Autre exemple vous avez 2 liaisons à 10Mbps. Vous voulez que le trafic sorte équitablement par les 2 liaisons afin d’utiliser le maximum de la capacité disponible (20 Mbps). Là aussi PfR vous aidera grandement.

PfR prend depuis quelques années beaucoup d’importance car c’est une composante indispensable pour les réseaux WAN hybrides. Un réseau WAN hybride est pour rappel un réseau WAN sur lequel un accès Internet est ajouté sur les sites distants en plus d’un accès VPN traditionnel (les plus joueurs remplaceront même l’accès VPN par 2 connexions Internet!) La solution Cisco pour le WAN hybride s’appelle IWAN (Intelligent WAN). PfR s’intègre dans la solution IWAN pour router au mieux les applications sur les divers liens disponibles (MPLS VPN, IPsec sur Internet…) afin de garantir la performances de ces dernières.

PfRv3 – quoi de neuf ?

Beaucoup d’éléments ont évolué. Le succès de PfRv2 a montré qu’il était nécessaire de faire évoluer la solution pour s’adapter à certains cas de figure. On a travaillé sur la simplification, la scalabilité, la convergence et l’ajout de fonctionnalités. On a également travaillé sur l’intégration dans notre architecture IWAN.

Simplicité

Côté configuration/provisioning, c’est une révolution. PfRv2 avait déjà pas mal simplifié les choses grâce à “target discovery” mais il restait nécessaire de configurer les règles d’optimisation sur chaque site. Cela n’était pas forcément compliqué (des copier/coller) mais cela pouvait être assez pénible. Avec PfRv3 le provisioning est fait uniquement sur le site “Hub” qui pousse les configurations PfR sur chaque site distant. Il devient donc beaucoup plus simple de rajouter un nouveau site, de modifier les règles d’optimisation etc.

On simplifie aussi avec des règles d’optimisation pré-définies pour la voix, la vidéo, etc. Plus besoin de spécifier tous les paramètres d’optimisation. On s’est en effet rendu compte que la plupart des clients avaient des besoins similaires et se posaient les mêmes questions: on a donc fait le travail.

Un autre détail qui montre la maturité de la solution (je rappelle ici que l’histoire de PfR a commencé en l’an 2000 avec une solution appelée OER a l’époque) est que l’on a supprimé le mode “monitor”. Ce mode permettait d’activer PfR sans optimiser le routage. En gros PfR se contentait de dire: “moi, je n’aurais pas fait comme ça!” Si l’idée pouvait paraître séduisante dans une stratégie de migration vers PfR on s’est aperçu que cela n’était ni utilisé ni utile.

Scalabilité et convergence

Aujourd’hui on annonce un support de 2000 sites (contre 500 sites en PfRv2). Il semble que l’on puisse aller largement au-delà mais les tests actuels validés ont été faits avec 2000 sites. Ce qui a permis d’augmenter la scalabilité est l’abandon des mesures IP SLA pour aller vers les “smart probes”. Un peu d’explication: pour accélérer la détection de problèmes réseau, PfRv2 utilisait des sondes IP SLA. IP SLA est la solution de mesure active intégrée depuis bien longtemps dans nos routeurs. En gros un ping amélioré qui permet de calculer le taux de pertes de paquets, la latence, la gigue et bien plus encore. IP SLA marche très bien mais peut être gourmand en CPU, notamment si vous voulez lancer des mesures vers 500 sites et pour une dizaine de champs DSCP par site, et ce via plusieurs chemins! Il a fallu changer un peu la donne.

Une nouvelle solution appelée “smart probing” a été conçue pour améliorer la scalabilité. Au lieu de se baser sur des mesures actives on se base maintenant sur le trafic réel des applications. Le routeur distant (à l’opposé du WAN) observe le trafic entrant et détermine ainsi la qualité de la liaison (par exemple en analysant les séquences TCP etc…) Ce dernier compare la qualité ainsi mesurée à celle requise (configurée au niveau PfR) et va envoyer un message TCA (Threshold Crossing Alert) au routeur à l’entrée du WAN quand la qualité n’est plus respectée. Dès réception du message TCA l’optimisation de routage peut avoir lieu. Comme les applications ne causent pas tout le temps on injecte si nécessaire des petits paquets “smart probes” pour s’assurer que l’on a bien en continu et en temps réel les statistiques pour chaque type de trafic.

Cette méthode de mesure a permis également de diminuer le temps de convergence et l’on peut maintenant basculer en 2 secondes. Certes les puristes du fast-reroute habitués à raisonner sur une base de 50ms trouveront peut-être le temps long mais je rappelle que l’on parle ici d’un reroutage sur base d’une dégradation des performances sur un lien WAN (par exemple un VPN IPsec sur l’internet) et non de la perte simple d’un lien optique sur un coeur de réseau! Il faut un minimum de temps pour constater la dégradation et éviter d’innombrables reroutages. Difficile donc de faire plus court.

Ce qu’il faut retenir? On simplifie avec un unique monitoring passif et cela nous permet de gagner en scalabilité et en temps de convergence.

Fonctionnalités

Ici je vais me contenter d’aborder 2 évolutions majeures qui étaient demandées par de nombreux clients:

On supporte maintenant les VRF et l’on peut avoir des critères d’optimisation différenciés sur chacune d’entre elle.
On peut optimiser par application grâce à l’intégration de NBAR2 (notre moteur DPI intégré). Pour résumer il est possible maintenant de faire une règle d’optimisation pour le trafic Sharepoint et une autre pour tout ce qui est Torrent.

Une base saine pour les futurs développements

Les développeurs ont également pas mal oeuvré pour rendre le code toujours plus intégrable dans la solution IWAN globale. IPv6 devrait arriver prochainement, ainsi que des avancées en matière d’interaction avec la QoS et DMVPN. Autant de raison pour continuer à suivre le sujet. Je compte pour ma part organiser un webinar reseauxblog sur le sujet. Stay tuned!