> Bonjour. Lu Jean-Michel,
> 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). Biensur, c'est justement l'objet de mon mail, je ne veux pas finir avec un ping -t tracer en RDDTools. Je cherche plus des produits qui se base sur de paquets séquencés et comptés. Après on peut aller jusqu'au flux, mais il faut définir le besoin réel avant. > - 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 ...). OK > 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. Je ne comprend pas. Dans mon cas l'objectif est de mesurer la qualité du réseau et pas de rechercher un problème. Voila les compteurs que je vois dans tes catégories, es tu d'accord et en vois tu d'autre ? > disponibilité, Perte de paquet Temps de réponse suppérieur à valeur acceptable > performance Temps de réponse Jitter > intégrité Je ne vois pas > 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. Je pense que la cause, si elle a lieu rentre dans une seconde partie. Je verrais plutot de bien définir l'attente et la présentation des compteurs afin, comme tu le dis, qu'ils soient représentatif de l'attente cliente. > Mais pour moi > le plus important est qu'enfin on arrête de penser que si le > réseau va, tout va. Entièrement d'accord, mais tu sera aussi pour entendre qu'il est bien de qualifier un réseau avant le déploiement d'une application critique. > 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. Oui exactement, c'est bien la limite que je veux trouver entre l'outil de lingne de commande et l'applicatif à 10 M€ Merci @+ _SebF --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
