Cas client : méthodologie d’un audit réseau

Contexte

Notre client est confronté à des remontées utilisateurs se plaignant de lenteurs sur différentes applications (un cas classique chez nos clients)

2 applications sont en particulier actuellement en cause :

• Une application métier servant aux demandes d’intervention
• La Téléphonie ToIP, avec en particulier des pertes de qualité de voix, coupures et autres lors de communication, pouvant mettre en cause la QoS.

Les plaintes remontées sur la téléphonie sont principalement sur les postes en SIP.

Il n’existe pas de plaintes en MGCP (La téléphonie est basée sur du SIP, MGCP, RTCP et RTP), mais nous sommes également face à des plaintes de lenteur sur CITRIX et sur certaines applications.

Pourtant, et après une première série d’analyses menées, les liens réseaux concernés ne semblent pas saturés et les serveurs applicatifs semblent ok.

Notre approche : audit réseau

Nous basons l’audit réseau sur 2 sites : un site central et un site distant défini par notre client. Nous utilisons des sondes NPM, ainsi qu’une sonde, appartenant au client et déjà mise en place, utilisant le même miroir que les sondes NPM. Pour objectif de démonstration, nous utilisons également certaines vues d’un autre constructeur sur une volumétrie limitée des flux en sortie du site central.

Notre démarche

Dans la démarche d’audit, la définition des points de capture est essentielle. De là en dépend la qualité des mesures et donc de leur analyse.

Un point d’écoute a donc été activé en entrée du Datacenter du site central puis, une semaine après en sortie sur le site distant.

Ceci nous permet de valider les champs de qualité de service dits DSCP :

• Sur le site Distant : voir els QoS envoyés par le routeur du site central
• Sur le site Distant : voir le réseau interne avec les adresse internes
• Sur le Datacenter : voir la QoS envoyée par le routeur du site distant

Comment en arrive-t-on à une conclusion ?

Grâce à la connaissance approfondie des sondes utilisées et à notre savoir-faire, l’analyse des différents écrans nous donne des informations et nous permet de faire des recommandations extrêmement précises pour chacune des observations suivantes :

Observations

 Aucun problème de réseau bas niveau n’est observé

1/ Une désorganisation des QoS de VoIP et de Citrix est identifiée sur le site central :

• Certains flux VoIP SIP n’ont pas de QoS (dscp=0)
• Idem au niveau du flux data, comme Citrix

Nous recommandons donc la mise à plat des paramétrages QoS Citrix et VoIP/SIP sur tous les routeurs des sites distants.

 Analyse de taille des paquets

2/ Des comportements liés à des manques de ressources sont visibles sur le site central

• La sonde remonte des comportements « 0-window » client et serveur
  • Top des remontées serveurs : XXX.YYY.ZZZ.TTT port ABCDE
  • Certains postes client
  • Pas de 0-windows observé sur le site distant en après midi

Il semblerait que la solution soit l’enrichissement ou le remplacement des éléments en manque de ressource.

3/ Nous observons du Multicast Wireless avec Tunneling 6to4

• La sonde remonte un nombre important de paquets émis par différentes adresses IPs en multicast.
•          Ces remontées contiennent des requêtes ISATAP (6to4)

Pour remédier à ce problème, nous recommandons de :

• Valider et/ou corriger la définition des filtrages de ce multicast
• Valider ou arrêter le tunneling ipv6 en ipv4 (6 to 4)
• Mettre à jour les éléments du réseau 

4/ Une activité IPv6 est visible (sur le site central et le site distant)

Il faudrait valider ou alors couper cette activité.

5/ Enfin, des ralentissements non liés au réseau, côté serveurs frontaux sont observés.

• Pas de souci réseau observé entre utilisateurs et serveurs frontaux
• Les temps sont des latences frontales serveurs. Cela signifie des ralentissements liés
  • Soit au serveur frontal observé
  • Soit dans l’architecture en background et / ou virtuelle

Un audit applicatif est à envisager sur cette application.

Conclusion

Tout le secret d’un bon audit est dans :

• Le choix de l’outil selon les problèmes à identifier
• Le choix des emplacements des écoutes
• Un peu l’interface chaise-écran lors de la lecture des remontées de la sonde

Cet exemple est très classique de nos audits, par rapport à du paramétrages de routeurs, externes au client, souvent sur un IT avec de nombreux sites distants.