Certains l’auront peut-être remarqué je suis assez “WAN” en ce moment 🙂 Tellement de nouveautés, ça motive à jouer un peu! Voici un petit test de Performance Routing version 3 (PfRv3) que j’avais présenté succinctement dans cet article. Pour monitorer tout ça je vais utiliser ici LiveAction.
Vous pourrez voir dans la suite de ce post la simplicité de configuration de PfRv3, et comment l’ensemble peut être supervisé efficacement avec LiveAction, un outil de management spécialisé pour le WAN (flow monitoring, performance, routage…)
Matériels et logiciels utilisés
- ASR 1001 en 3.13S
- Cisco 2951 en 15.4(3)M
- LiveAction version 4.1.3
- Un outil maison pour générer des pertes de paquet et de la latence
Configuration initiale
Je démarre avec une configuration IWAN “type” où chaque site dispose d’une connexion MPLS-VPN fournie par un opérateur ainsi que d’une connexion Internet. Les 2 sites de mon test sont interconnectés via 2 DMVPN construits au-dessus de chaque type de connexion. J’ai configuré sur chaque routeur d’accès les 2 interfaces suivantes:
- Tunnel 0 – DMVPN sur MPLS-VPN
- Tunnel 1 – DMVPN sur Internet
J’ai configuré EIGRP avec un delay largement supérieur sur le tunnel 1 (Internet) afin de privilégier la connexion MPLS-VPN et de n’utiliser Internet qu’en backup. Voici un screenshot de LiveAction. On peut voir les flux Best Effort en bleu ciel et mon flux video (DSCP AF41) en fushia transiter par le même tunnel.
Configuration PfRv3
Je vais dans la suite du lab configurer PfRv3 pour optimiser tout cela:
- M’assurer que les flux vidéo transitent en priorité sur le MPLS-VPN et soient re-routés sur l’Internet quand la performance n’est plus au rendez-vous
- Répartir le reste du trafic de manière à ce que les liaisons soient utilisées de manière équivalente
Configuration ASR 1001
domain LAB
vrf default
border
source-interface Loopback0
master local
password CISCO
master hub
source-interface Loopback0
site-prefixes prefix-list CAMPUS
password CISCO
load-balance
enterprise-prefix prefix-list LAB
collector A.B.C.D port 2055
class VIDEO sequence 1
match dscp af41 policy real-time-video
path-preference MPLS fallback INET
!
interface Tunnel0
domain LAB path MPLS
!
interface Tunnel1
domain LAB path INET
Configuration C2951
domain SHOWROOM vrf default border source-interface Loopback0 master local password CISCO master branch source-interface Loopback0 site-prefixes prefix-list BRANCH password CISCO hub 10.190.110.8 collector A.B.C.D port 2055
Quelques explications
L’ASR 1001 a les fonctions de “Border Router” et “Master Hub”. Je ne rappelle pas ici toute la technologie PfRv3, vous trouverez ce qu’il faut en référence. On note cependant les points suivants:
- Toutes les règles d’optimisation sont définies uniquement sur le master hub (ASR1001). Ces règles sont poussées sur les autres routeurs. Cela change de PfRv2 où il fallait configurer toutes les règles sur tous les sites.
- Il faut tout de même un Master Controller (MC) sur chaque site. La configuration du MC sur un site distant est très simple puisqu’il suffit de déclarer le master hub. Tous les routeurs des sites distants ont ainsi une même configuration basique.
- Dans mon test les fonctions Border Router (BR) et Master Controller (MC) sont configurées sur le même routeur (les 2 éléments communiquent directement). Il est possible de configurer ces fonctions sur des routeurs distincts. Cela permet notamment d’avoir plusieurs routeurs d’accès par site pilotés par un même Master Controller (les BR executant les ordres du MC)
- Les interfaces sur le site principal sont placées dans des “path” ici MPLS (MPLS-VPN) et INET (Internet). Nul besoin de configurer les “path” sur les sites distants ces derniers vont les découvrir automatiquement.
- Il est nécessaire sur chaque site de définir les préfixes gérés localement (site-prefixes prefix-list) ainsi que de définir sur le master hub les préfixes de l’entreprise (enterprise-prefix prefix-list)
- On peut travailler dans des VRF avec des règles d’optimisation distinctes par VRF. Ici je reste dans la global (default)
- On remarque la règle qui permet de router le trafic AF41 (vidéo) en priorité sur le MPLS et en backup sur le lien INET (j’utilise des critères de performance embarqués dans PfRv3: inutile de spécifier latence, jitter, loss… On a configuré les règles pour les applications usuelles.
- Le reste du trafic est réparti sur les différents liens (CLI load-balance). Notez que les liaisons n’ont pas forcément la même capacité. PfRv3 va s’adapter à la capacité de chaque liaison dans l’algorithme de répartition de charge.
Premières vérifications
On peut regarder le statut du master sur chaque site. Ici sur le site distant. On voit que le statut est UP, que le minimum requirement est “Met” et que les interfaces
C2951#sh domain LAB master status
*** Domain MC Status ***
Master VRF: Global
Instance Type: Branch
Instance id: 0
Operational status: Up
..
Minimum Requirement: Met
Borders:
IP address: A.B.C.D
Connection status: CONNECTED (Last Updated 2d00h ago )
Interfaces configured:
Name: Tunnel1 | type: external | Service Provider: INET | Status: UP
Number of default Channels: 1
Name: Tunnel0 | type: external | Service Provider: MPLS | Status: UP
Number of default Channels: 1
Tunnel if: Tunnel2
On va également pouvoir regarder les classes de trafic découvertes automatiquement, ainsi que les chemins utilisées par chaque classe de trafic. On voit ici que le trafic AF41 utilise bien le lien MPLS et que les autres classes sont réparties sur les liens INET et MPLS pour équilibrer la charge.
ASR1001#sh domain LAB master traffic-classes summary APP - APPLICATION, TC-ID - TRAFFIC-CLASS-ID, APP-ID - APPLICATION-ID SP - SERVICE PROVIDER, PC = PRIMARY CHANNEL ID, BC - BACKUP CHANNEL ID, BR - BORDER, EXIT - WAN INTERFACE UC - UNCONTROLLED, PE - PICK-EXIT, CN - CONTROLLED, UK - UNKNOWN Dst-Site-Pfx Dst-Site-Id APP DSCP TC-ID APP-ID State SP PC/BC BR/EXIT 10.191.7.0/24 10.190.110.1N/A cs3 76 N/A CN MPLS 49/48 10.190.110.8/Tunnel0 10.191.7.0/24 10.190.110.1N/A default 73 N/A CN INET 39/41 10.190.110.8/Tunnel1 10.191.7.0/24 10.190.110.1N/A af41 71 N/A CN MPLS 43/42 10.190.110.8/Tunnel0 ...
Management PfRv3 avec LiveAction
Je vous épargne l’installation hyper simplifiée de LiveAction (un serveur qui s’installe sur Windows ou Linux, et un client pour Windows ainsi que pour mon Mac). Une fois PfRv3 déployé on note que les flux AF41 restent bien sur le lien MPLS. En revanche les flux Best Effort ont été reroutés sur le lien Internet.
Notez que dans ce cas précis le trafic Best Effort n’est plus du tout routé sur le lien MPLS. Je n’ai pas assez de flux Best Effort dans mon lab et leur débit n’excède pas le trafic vidéo. Aussi PfRv3 continue de router ces flux sur le lien Internet. Si j’avais eu beaucoup plus de trafic Best Effort on aurait observé des flux Best Effort sur les 2 liens pour équilibrer la charge des liaisons.
Vous ne me croyez pas? Si je supprime le trafic vidéo on voit bien que le trafic Best-Effort est immédiatement load-balancé sur les liaisons.
Dernier test, je rajoute des pertes de paquets (environ 10%) et de la latence (800ms!) sur la liaison MPLS. On voit que le trafic vidéo est immédiatement rerouté (convergence entre 1 et 5 secondes observée dans mon lab) et le trafic Best Effort est lui aussi rerouté pour équilibrer la charge.
LiveAction collecte également les décisions de re-routage de PfRv3. Je ne vais pas m’étendre sur ce sujet ici. Juste un petit screenshot dans lequel vous pouvez observer le reroutage du flux vidéo ainsi que des flux Best Effort. Vous ne le voyez pas ici mais on peut voir la performance des flux et les raisons de chaque reroutage. N’hésitez pas à regarder la vidéo en référence pour plus d’information. Vous pouvez également tester gratuitement l’outil pendant quelques jours.
Conclusion
Que retenir? C’est simple, ça marche et on a un outil de management léger pour visualiser ce qui se passe sur le “WAN Intelligent”. J’espère vous avoir donné envie de jouer un peu. N’hésitez pas à me contacter si vous êtes intéressé afin que je vous aide à mettre le pied à l’étrier.
Références
Si cet article vous a donné envie regardez cette vidéo de démo LiveACtion / PfR avec davantage de détails sur les fonctionnalités de LiveAction:
@JeromeDurand
Authors
