Bonjour.
La méthodologie pour appréhender la qualité d'un backbone IP, en voila
une question passionnante et je l'espère "pas hors charte".
Le principal problème est de ce sortir du piège classique de
restreindre la qualité d'un backbone aux attendus appris à l'école et
qui ne sont que des conditions non nécessaires et souvent
insuffisantes (différents tests basés sur ICMP comme ceux que tu
décrits).
Pourquoi ?
Simplement et je le redis, parce qu'il n'y a aucune application au
monde utile (ou utilisée si vous préférée) qui fonctionne en ICMP et
que si ces tests pouvaient être signifiants avant (en gros quand les
routeurs et les backbones étaient suffisaments simples pour que l'on
ne joue pas avec eux), aujourd'hui ce n'est plus le cas et en plus
dans un contexte MPLS d'entreprise (j'espère au moins homogènes au
niveau routeurs et règles implémentées).
En tous les cas tu as raison de parler de méthodologie AVANT de parler
de "tools" ... trop souvent on voit venir chez nous des gens déçus de
l'approche trop "contraignante et limitée" des tools, alors que c'est
la méthode qui doit guider pas l'outils. Trop souvent la même méthode
a ammené aux mêmes outils et nous amène dans l'impasse.
Concernant la méthode, tu as en gros deux pistes : (je fais court et
j'essaye d'être bref et j'espère que je ne vais pas engendrer le
premier grand troll de l'année :-) )
- tu pars des CAUSES et tu remontes aux problèmes : par exemple tu
prends des machins qui vont faire des pings partout, quelques
traceroutes à la main, tu te connectes sur tous les routeurs pour
vérifier que le truc qui met à jour les règles / priorités / filtrages
à bien fait son travail et parce que tu es professionnel, tu essayes
sur certains sites d'utiliser quelques applications "à vide" pour voir
si le machin réagit correctement. Ensuite tu rends ton rapport. A ce
stade, sans aller bien loin, il devrait déjà y avoir bcp à dire
(sécurité, qualité des configurations ...). Et tu pars avec le
sentiment d'avoir fait un honorable travail, comme la plupart des gens
qui travaillent comme cela.
- tu définis une méthodologie, propre au sujet (nature du backbone,
nature du risque opérationnel, type d'applications et d'usages,
étendue géographique, où sont les utilisateurs principaux ...).
Ensuite tu définis (je fais bref) un ensemble de "CONSEQUENCES" qui
ont un sens par rapport à ce que tu as vu dans un premier temps et
vont te permettre de faire le lien avec des CAUSES. Par exemple dans
le cas d'un réseau MPLS : le fameux couple applications critiques /
classe de service. Et ensuite tu te mets à observer pragmatiquement
l'ensemble des "conséquences" que tu auras vues pour en déterminer la
QUALITE sous trois axes : disponibilité, performance et intégrité.
Ceci parce que tous les services (les conséquences) ne s'appréhendent
pas de la même façon (un smtp n'a pas les mêmes "tresholds"
qualitatifs que de la voip. Et ensuite tu affines le monitoring
généralisé pour qu'il devienne le plus possible représentatif de
quelque chose de réel pour le client tout en permettant de comprendre
la cause de dysfonctionnement. En fait, c'est une sorte de super phase
"évoluée" de SAA + ping et traceroute à la main MAIS en ne faisant pas
confiance dans les techniques sous jacentes (ce que dit un routeur par
exemple) et en partant de faits avérés.
Les avantages sont très nombreux et il faudrait en débattre peut être
dans une prochaine réunion de visu ? Mais pour moi le plus important
est qu'enfin on arrête de penser que si le réseau va, tout va. Il faut
des systèmes qui permettent de corréler la performance applicative (et
j'y inclus la vidéo et la voix) avec la santé du réseau. Trop souvent
les "audits réseaux", avec des "tools" conduisent a essayer de faire
une bijectivité simple entre ce qui est mesuré et la réalité ... et le
gens de l'IP le savent ... ce n'est pas possible. Un service peut très
bien fonctionner avec des équipements en panne ou un réseau qui
fonctionne mal. Un service peut très bien ne pas fonctionner
(assymétrie de routage, pb de DNS ...) avec tout au vert ... (le
problème est alors la définition du tout)
L'autre avantage consiste aussi est de se poser la vraie question du
BUT. Si ton client te commande cet audit, c'est qu'il a le sentiment
que les choses peuvent être améliorées ou qu'il n'est pas sur que tout
fonctionne bien. Le rassurer n'est pas de lui dire que son opérateur
respecte les classes de services MPLS. C'est de la gaminerie cette
histoire. D'ailleurs l'opérateur peut très bien ne pas respecter ces
classes (bug dans les équipements) et le service être parfaitement
(ou du moins dans une mesure suffisante) rendu. Cette approche trop
souvent vue est au moins aussi stupide que les SLA sur la gigue et la
perte de paquets ... (on peut développer si besoin)
Pour les outils ou plutôt pour les systèmes, j'en connais un, nous y
avons passé quelques années de notre vie, mais cela fait un peu trop
vendeur que de l'expliquer plus :-)
Me contacter en mail si besoin. (jmp + frnog @ witbe dot net)
-----------------------------
Jean-Michel Planche blog:
http://www.jmp.net
Chairman and co-founder Witbe web :
http://www.witbe.net
Follow me
http://www.twitter.com/jmplanche
-------------------------------------------
2.0 Monitoring : relevant End to End monitoring for critical app. and
carrier class services
Le 11 janv. 08 à 00:09, FONTAINE Sebastien [FrameIP] a écrit :
Bonjour,
Je suis en charge d'audit le réseau WAN d'un client final. Ce réseau
WAN est composé de quelques centaines de site avec diverses boucles
locales toutes raccordées sur une offre IPVPN MPLS d'un opérateur.
L'objectif de cet audit doit être un rapport factuel montrant la
qualité réelle du réseau WAN. Les types de compteurs attendus sont
la perte de paquet, le temps de réponse, le jitter, respect des
classes de services …
Avant de commencer, je suis en train de réfléchir sur la
méthodologie et les outils.
Pour les outils, que me conseillez vous ?
Pour la méthodologie, je me dis que couper une boucle locale pour
faire un test d'une heure ne sera pas représentatif de la réalité.
Quand pensez-vous ?
Merci d'avance,
_SebF
