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/
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Répondre à