Cisco France Blog

J’ai testé pour vous: PfRv3 supervisé par LiveAction

5 min read



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.

PfRv3-2

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.

PfRv3-1

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.

PfRv3-2

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.

PfRv3-2bis

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.

PfRv3-4bis

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.

PfRv3-4

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

Jerome Durand

Technical Solutions Architect

Laisser un commentaire