Je ne suis pas vendeur chez Firebrick. Peut-etre une idee a explorer :D Leur LNS fait un LCP ping (un ping au niveau L2TP, donc pas affecte par la banade passante utilise par le client) et retourne les resultat. De maniere reguliere A&AISP (les meme gens) remontent vers BT des problemes de capacites qu'ils n'arrivent pas a voir eux-meme ...
Lisez ce blog pour sourire et comprendre comment c'est utile. http://revk.www.me.uk/2012/06/can-bt-run-back-haul-network.html Thomas On 12 Jun 2012, at 10:21, Sebastien Lumineau wrote: > Bonjour, > > Nous monitorons les bandes passantes d'environ 400 liens xDSL. Le principe > est le suivant: > > - on charge le lien artificiellement pendant 10 secondes > - on interroge en snmp la passerelle pour connaitre le nb d'octets qui > ont transité par l'interface wan durant ce laps de temps > - on en déduit la bande passante du lien à cette instant > - on fait cette mesure chaque heure > - les résultats sont remontées dans une base Posgres qui permet de nous > sortir un graphe pour l'accès xDSL > > Voici un log type du script bash qui fait ça: > > Jun 11 16:15:02 monitor_debit v.1.4[8236]: Gateway: Cisco 878 (SDSL) at > xxx.xxx.xxx.57 > Jun 11 16:15:02 mesure_debit[8236]: Using > http://xxx.xxx.xxx.43/DEBITEST.bigbig for bandwidth test > Jun 11 16:15:02 mesure_debit[8236]: Using > http://xxx.xxx.xxx.12/DEBITEST.bigbig for bandwidth test > Jun 11 16:15:02 mesure_debit[8236]: Stream wget --quiet --cache=off > --output-document /dev/null http://xxx.xxx.xxx.43/DEBITEST.bigbig started > (pid=8302) > Jun 11 16:15:02 mesure_debit[8236]: Stream wget --quiet --cache=off > --output-document /dev/null http://xxx.xxx.xxx.12/DEBITEST.bigbig started > (pid=8304) > Jun 11 16:15:02 mesure_debit[8236]: Waiting 5 seconds before probing router... > Jun 11 16:15:08 mesure_debit[8236]: Router xxx.xxx.xxx.57 first probe at > 16:15:08... ok > Jun 11 16:15:08 mesure_debit[8236]: Waiting 10 seconds before stopping load > streams... > Jun 11 16:15:18 mesure_debit[8236]: Router xxx.xxx.xxx.57 second probe at > 16:15:18: ok > Jun 11 16:15:18 mesure_debit[8236]: Stream 1 stopped > Jun 11 16:15:18 mesure_debit[8236]: Stream 2 stopped > Jun 11 16:15:18 monitor_debit v.1.4[8236]: Bandwidth download test done > (108300 B/s) > > Comme l'interrogation se fait sur l'interface WAN de la gateway, on > sait que l'on capture tout le trafic (contrairement à ce que l'on a > quand on fait une mesure depuis une station où une partie du trafic > peut nous échapper). Quand le modem xDSL ne répond pas au snmp (genre > une livebox nouvelle génération pas sympa), on interroge la patte wan > du firewall (=celui qui héberge le script); en général on préfère > interroger le modem car il peut nous arriver d'avoir 2 firewalls pour > un même accès DSL. Mais quand le firewall est tout seul, c'est pareil. > > Ca marche bien et le chargement du lien 1 fois par heure est indolore > pour les utilisateurs. > > Parallèlement nous avons un graphe CACTI qui nous donne la charge du lien. > > Graphe de bande passante + graphe de charge => on est en mesure de > savoir s'il y a des lenteurs parce que le lien est saturé ou si c'est > parce que la bande passante n'est pas conforme. > > Sebastien > > ----- En réponse au message suivant ----- > > Date: lundi 11 juin 2012, 15h50 > De: Baudin Maxime <maxime.bau...@ac-rennes.fr> > Sujet: [FRnOG] [TECH] Monitoring / métrologie de centaines de liens ADSL > >> Bonjour, >> >> Nous cherchons un moyen intelligent de monitorer des liens ADSL et surtout >> un moyen d'avoir de l'information sur la qualité/saturation de chaque liens. >> Le volume est de l'ordre de 300 à 600 liaisons (issues de n'importe quel >> opérateur a priori). >> >> J'explique peut-être un peu plus : >> >> J'ai, disons, un peu plus de 300 sites distants et un site principal >> >> Le site principal fournit du service numérique aux sites distants >> (Essentiellement des applications via un portail WEB) >> Le site principal a une connexion Gigabit loin d'être saturée. >> >> Les sites distants ont 1 ou 2 liens ADSL, avec des abonnements de type >> particuliers. Chaque site distant est autonome dans le choix de l'opérateur >> et du contrat qu'il souscrit (c'est comme ça, nous pouvons ergoter toute la >> nuit, c'est...comme ça). >> >> Par contre, le/les routeurs ADSL sont en mode bridge et la/les IP opérateurs >> arrivent sur un équipement réseau dont nous sommes propriétaire et que nous >> pouvons administrer et monitorer (ils supportent SNMPv3, nous ne l'avons pas >> activé pour le moment) >> >> Maintenant, nous aimerions avoir de la visibilité sur la qualité/saturation >> de chaque ligne. L'idée est de pouvoir affiner notre pré-diagnostique >> lorsqu'un site se plaint de lenteurs (par exemple), mais également de >> coupures ou autres problèmes imprévus. >> >> -> Nous travaillons sur la mesure de performance sur la chaine applicative >> dans le datacenter mais nous manquons cruellement d'informations sur ce qui >> est hors de ce périmètre. >> -> Nous envoyons des agents sur place à l'aveugle, ce qui est toujours >> désagréable pour eux. >> -> De même, nos gars ont l'impression de perdre leur temps pour un >> déplacement consistant parfois à lancer un simple "speedmeter" >> >> >> Notre supervision actuelle comprend un nagios en mode binaire : le site >> distant répond / ou pas. >> >> Auriez-vous une idée de la façon de mieux quantifier la qualité (relative) >> d'un lien ? en journée ? sur un abonnement qui, si je comprend bien, n'a >> aucune garantie de débit ? >> Nous pourrions grapher les débits et, constater une saturation lorsqu'un >> graphe est "plat", indépendamment du débit constaté ? En ce cas comment >> remonter une alerte ? >> Mettre en place un "speedmater like", régulier, pour notre infrastructure >> est-il, par exemple, une idée à creuser ? -> le problème est que c'est une >> mesure échantillonnée, qui a en plus un impact direct sur la saturation de >> la ligne. >> >> Bien entendu se posera la question de lier ce monitoring à un outils >> permettant d'avoir des vues claires, pour notre équipe de helpdesk par >> exemple et nos équipes de terrain également. >> >> Je fais donc appel à votre expérience pour m'ouvrir les yeux >> >> Cordialement, >> Maxime >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >
signature.asc
Description: Message signed with OpenPGP using GPGMail