Principes de base
Nous venons de sortir la Cisco DNA TTA (Traffic Telemetry Appliance) pour améliorer encore la visibilité sur les réseaux d’entreprise. Mais alors que nous avons déjà de la télémétrie sur nos routeurs, commutateurs et contrôleurs Wi-Fi, vous vous demandez peut-être à quoi sert cette appliance. Explications…
Commençons par regarder de plus près cette appliance. Elle se connecte généralement en distribution/cœur de réseau et on va rediriger tout le trafic vers cette dernière (SPAN sur le commutateur de distribution/cœur). La sonde va ainsi ingérer tout le trafic, reconnaître les applications via le moteur DPI NBAR2 et faire tourner des algorithmes de performance monitoring pour remonter des Application Response Time (ART), des mesures fines permettant de caractériser comment les applications se comportent sur le réseau et de déterminer d’où viennent les éventuels problèmes de performance rencontrés.
La DNA TTA supporte jusqu’à 20Gbps d’aggregated throughput et jusqu’à 40.000 end-points. Elle envoie les informations collectées à Cisco DNA Center qui va les corréler et offrir de nouvelles mesures à l’administrateur réseau pour enrichir le dashboard Application Assurance.
Application Assurance
Si la sonde est utile pour collecter des mesures, la force de la solution réside bien dans DNA Application Assurance sur Cisco DNA Center. Vous pouvez voir ci-dessous un exemple de dashboard que vous pouvez avoir dans Cisco DNA Center dans Application Assurance. Vous pouvez savoir pour un utilisateur, un site ou bien l’ensemble de votre réseau les différentes applications actuellement utilisées et le volume de données associé (le quantitatif). Vous avez également une note de performance (le qualitatif) de chacune d’entre elles (de 1 à 10), les détails pour chaque application (latence, jitter, loss…) ainsi que diverses informations comme par exemple le champ DSCP observé.
Dans l’exemple ci-dessous vous voyez que la note pour Office365 est mauvaise (2/10) à cause d’une mauvaise latence (près de 400ms) et près de 5% de packet loss. On voit que tout à l’air bon côté client et application. On peut donc raisonnablement penser qu’il y a un problème sur le WAN. Le dashboard nous indique également que le champ DSCP observé est 0 (default – DF) alors qu’on s’attend évidemment à voir une classe AF (Assured Forwarding). Bref, on voit non seulement où est le problème mais aussi la cause probable de celui-ci (mauvais marquage DSCP).
Ce simple exemple montre tout l’intérêt de Application Assurance sur DNA Center : la capacité de comprendre l’expérience utilisateur pour chaque application et répondre à l’éternelle question “Est-ce un problème du réseau ou de l’application ?”
Application Response Time
Ces mesures sont obtenues en analysant finement les flux transitant. Par exemple au moment de l’établissement de la session TCP, le temps entre le paquet SYN et le SYN-ACK est le Server Network Delay (SND – temps réseau pour joindre le serveur). Ce temps est géré par les couches réseau du serveur de destination et reste indépendant de l’application. Une fois la session établie, client et serveur vont s’échanger des paquets. Le temps entre le moment où la sonde voit la demande du client et la réponse du serveur est le Response Time (RT) global. Il intègre à la fois le délai pour joindre le serveur (SND) et le temps pris par l’application. Si l’on soustrait le SND précédemment déterminé au RT, alors on obtient l’Application Delay (AD)
En faisant ce travail sur tous les flux (toutes les applications, tous les clients) alors on peut aisément déterminer des tendances et répondre simplement à la question éternelle : “Est-ce la faute du réseau ou de l’application ?” Peu importe le placement de la sonde, on va faire la différence entre :
- le temps côté client
- le temps vers le serveur (WAN)
- le temps mis par l’application
Et on va bien sûr voir aussi s’il y a des paquets perdus, et s’ils ont été perdus avant ou après la sonde. Pour les flux voix, des analyses fines équivalentes sont faits sur les paquets RTP et permettent de déterminer là aussi si des paquets sont droppés, la gigue, etc. On a une cinquantaine de métriques qui sont calculées avec cet algorithme de performance monitoring qui existe depuis très longtemps !
L’agent perfmon est en effet depuis de nombreuses années sur les routeurs ISR/ASR, et il a fait aussi ses preuves sur la NAM (Network Analysis Module) qui existe depuis assez longtemps. On peut d’ailleurs voir la TTA comme un rebranding de la NAM. Ce qui change n’est pas forcément la sonde, mais bien le moteur d’analyse des données collectées : Cisco DNA Center. Et c’est bien cela qui est puissant : corréler ces métriques applicatives (Application Assurance) à des données de monitoring réseau (Network Assurance) et des end-points (Client Assurance).
Si Josianne se plaint que “c’est lent”, vous pourrez lui répondre :
- qu’à 9H c’était la faute de l’application car le serveur était surchargé
- qu’à 10H l’open space était surchargé entraînant des problématiques de performance sur le Wi-Fi
- qu’à 11H c’était un problème sur le WAN parce que le reste de l’équipe regardait “Motus” en HD et saturait la connexion
Je n’en rajoute pas, vous comprenez que la solution vous permet de faire ce que l’on appelle un triage : vous pouvez très rapidement dédouaner (ou pas !) le réseau d’accès dans une problématique de résolution de problème de performance. Et pour une équipe réseau, tout ça vaut de l’or ! Si vous avez déjà fait du troubleshooting de performance applicative vous savez combien ce triage est compliqué, les équipes applicatives refusant souvent de se pencher sur le problème tant que les admin réseau n’ont pas prouvé par A+B que tout était normal chez eux.
Quand utiliser la DNA TTA ?
Si vous utilisez déjà Cisco DNA Center, vous savez qu’il est possible d’activer “Application Telemetry” sur les commutateurs Catalyst 9000, routeurs ISR/ASR/Cat8000, et contrôleurs Wi-Fi Catalyst 9800. Alors pourquoi rajouter cette appliance ? Le dispositif actuel n’est-il pas déjà suffisant ?
Il faut déjà comprendre que tout le monde ne possède pas un parc 100% compatible DNA. La DNA TTA permet justement d’utiliser Application Assurance même quand le reste du parc n’est pas encore à jour. Évidemment il manquera alors d’autres informations sur les équipements réseau et la connexion des utilisateurs, mais déployer une sonde peut être une première étape en attendant de mettre à jour les équipements du site.
L’autre chose à comprendre, est que l’application de DNA Assurance sur nos équipements active des fonctions qui donnent de la visibilité sur les applications. Mais tous ces équipements ne fournissent pas les mêmes mesures. Aujourd’hui, seuls les routeurs sont capables de fournir le qualitatif (les métriques ART). Les WLC et commutateurs fournissent le quantitatif (qui consomme quelle application et avec quel volume). A l’heure actuelle, il faut donc déployer un routeur sur site pour disposer du maximum de mesures (cela pourra être amené à changer). Si vous gérez vous-mêmes vos routeurs, pas de problèmes : vous l’ajoutez dans l’inventaire de Cisco DNA Center, vous cliquez sur “Enable Application Telemetry” et le tour est joué (pas besoin de la DNA TTA). Si vous n’avez pas de routeur Cisco sur site, ou bien s’il est managé par un opérateur, ou encore s’il est très chargé et que vous ne pouvez pas rajouter de nouvelles features dessus faute de performance, vous serez peut-être alors heureux de déployer la DNA TTA pour collecter les mesures.
J’espère que vous avez compris ici tout le potentiel d’Application Assurance sur Cisco DNA Center, et que vous voyez maintenant comment la DNA TTA s’insère dans l’architecture.
Pour en savoir plus :
- Datasheet de la DNA TTA
- Application Assurance design guide
- Application Health User Guide sur Cisco DNA Center
Authors
1 commentaires
Merci Jérôme pour cet article !