Re: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On Wed, 05 Sep 2012 23:03:27 +0200, Fabien V. list-fr...@beufa.net wrote: _ping_._ovh_._net_ ? Bonne initiative, mais il manque une entrée pour l'IPv6. Je m'étonne que personne n'ai parlé d'IPv6. Sur toute mes liaisons qui ont un adressage IPv6, je considère que la liaison est HS si les requêtes v6 n'aboutissent pas, et je bascule sur une autre liaison. Il est d'ailleur possible sous Linux, de configurer les interfaces réseaux avec cette condition. Nous raisonnons avec l'idée de l'IPv4 est prioritaire et l'IPv6 optionnel, alors que les systèmes (notamment le DNS), fonctionnent à l'inverse. Nous devons raisonner de la même manière que les systèmes si nous voulons les tester correctement. Pour en revenir au coeur du sujet, l'initiative d'OVH est la bonne. Il faudrait que chaque fournisseur ou hébergeur mette en place une ou plusieurs mires dans son AS. On peut envisager des mires IP par AS (comme pour les Looking Glass BGP) ou par préfixes pour les gros réseau (une mire pour /16 donné par exemple). Ce système permettrait de faire des tests à l'intérieur de son AS entre préfixes, mais aussi entre AS, afin de prévoir différents scénarios de panne (dernier km, perte de transit, blackhole,...). J'encourage fortement les opérateurs (gérant un AS et/ou des préfixes) à mettre en place des mires IPv6 et IPv4, afin que de bonnes pratiques réciproques puissent s'installer en terme de test IP. My 2 cents Solarus --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
Nous raisonnons avec l'idée de l'IPv4 est prioritaire et l'IPv6 optionnel, alors que les systèmes (notamment le DNS), fonctionnent à l'inverse. Nous devons raisonner de la même manière que les systèmes si nous voulons les tester correctement. Pour ma culture personnelle, pourquoi l'ipv6 serait prioritaire sur le DNS ? Sur mes systemes, les requetes DNS se font en ipv6 parceque j'ai configure un resolver ipv6 en premier, sinon ca passerait tout en ipv4 et serait en fallback en ipv6 si jamais ca ne repond pas en v4. Christophe --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On Fri, 7 Sep 2012 11:30:59 +, Christophe HUBERT christophe.hub...@agarik.com wrote: Pour ma culture personnelle, pourquoi l'ipv6 serait prioritaire sur le DNS ? Sur mes systemes, les requetes DNS se font en ipv6 parceque j'ai configure un resolver ipv6 en premier, sinon ca passerait tout en ipv4 et serait en fallback en ipv6 si jamais ca ne repond pas en v4. Christophe Peu importe que ton résolveur soit accessible en IPv4 ou IPv6, ils se comportent exactement de la même manière. Les requêtes DNS vont d'abord chercher un enregistrement (IPv6). Si cet enregistrement n'existe pas, ils prennent l'entrée A (IPv4). Si le existe, ils vont d'abord essayer d'atteindre les IPv6 correspondantes, en cas de panne ils basculent en IPv4. Celà rajoute donc du délai de connexion en cas de panne de l'IPv6, c'est d'ailleurs ce qui rend beaucoup d'acteurs si frileux quand à la transition, mais c'est un autre débat. J'en conclue qu'un lien IPv6 défaillant provoque un fonctionnement dégradé, beaucoup plus difficile à détecter qu'une coupure franche sur un accès IPv4 seul. C'est pour ça que sur des liens dualstack, ils faut tester les deux adressages avec l'IPv6 en premier. Cordialement, Solarus --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
Le 6 septembre 2012 00:39, Steven Le Roux ste...@le-roux.info a écrit : Pour t'exposer ce que j'ai fait pour monitorer des accès internet sur différents accès : sur accès internet où j'ai un proxy sortant, je fais deux checks : - internet_www - internet_dns le check internet_www est un check_http vers www.google.fr le check internet_dns est un check_tcp(53) vers 8.8.4.4 ou 8.8.8.8 Donc tu testes le proxy, l'accès de ton provider, et son transit/peering vers le datacenter le plus proche de google. Ne pourrais-tu pas au moins tester le port 53 vers autre chose que google, et qui soit bien éloigné ? Genre un des serveurs dns du tld d'un pays lointain? Guillaume --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
2012/9/6 Guillaume Leclanche guilla...@leclanche.net: Le 6 septembre 2012 00:39, Steven Le Roux ste...@le-roux.info a écrit : Pour t'exposer ce que j'ai fait pour monitorer des accès internet sur différents accès : sur accès internet où j'ai un proxy sortant, je fais deux checks : - internet_www - internet_dns le check internet_www est un check_http vers www.google.fr le check internet_dns est un check_tcp(53) vers 8.8.4.4 ou 8.8.8.8 Donc tu testes le proxy, l'accès de ton provider, et son transit/peering vers le datacenter le plus proche de google. Ne pourrais-tu pas au moins tester le port 53 vers autre chose que google, et qui soit bien éloigné ? Genre un des serveurs dns du tld d'un pays lointain? Guillaume Ce jeu de règle ne teste que l'accès lui même, d'autres règles sont là pour checker les proxies. On peut bien sûr tester autre chose que ça, mais il y a des limites et on ne va pas mettre un check par peering d'opérateur. C'est juste de l'informatif. -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB ste...@le-roux.info 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
2012/9/5 Stephane Bortzmeyer bortzme...@nic.fr: Je crois que c'est une question qui concerne directement les opérateurs réseau (j'ai cité Free pour les exemples mais cela n'a rien de spécifique à Free). Avis bienvenus. http://www.bortzmeyer.org/que-pinguer.html Tu parles de ping, as-tu envisagé l'echo plus UDP ? e.g. http://www.broadband-forum.org/technical/download/TR-143.pdf Cdlt, sarah --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
Je crois que c'est une question qui concerne directement les
opérateurs réseau (j'ai cité Free pour les exemples mais cela n'a rien
de spécifique à Free). Avis bienvenus.
http://www.bortzmeyer.org/que-pinguer.html
Lorsqu'on met en place une infrastructure de surveillance de serveurs
Internet, il est agaçant de recevoir autant d'alarmes que de serveurs
surveillés, alors que c'était simplement la connectivité Internet de la
sonde de surveillance qui était en panne. Tous les grands logiciels de
surveillance de réseau ont une option pour éviter cela, qui permet de
dire que le test d'un serveur dépend du succès d'un test sur un autre
composant, par exemple le routeur de sortie (si ce dernier est en
panne, il n'y a pas besoin de tester les serveurs et d'alerter si ça
rate). Mais quel composant tester pour déterminer qu'on a un accès
Internet qui marche ?
Avec les logiciels de la famille Nagios comme Icinga, l'option qui
permet d'indiquer la dépendance d'un test envers un autre se nomme
parents. Si on écrit :
define host {
host_name freebox
address 192.168.1.1
}
define host {
host_nameremote-host
parents freebox
...
}
alors on déclare que le test de remote-host
dépend de celui de freebox. Si on est connecté à
l'Internet par ce seul routeur, c'est logique. Si
freebox est injoignable, le reste de l'Internet
l'est aussi.
Mais si freebox fonctionne mais ne route plus
http://bugs.freeplayer.org/task/10258 ? Ou bien si quelque chose
déconne dans le réseau de Free bloquant tout accès à l'extérieur ?
C'est là qu'il est utile de tester autre chose que le premier routeur.
On voudrait en fait tester si on a toujours un accès Internet et
pouvoir écrire :
define host {
host_nameremote-host
parents Internet
...
}
Mais comment faire ce test ? En pinguant des
machines distantes, bien évidemment. Il « suffit » de sélectionner des
machines stables, qui répondent aux paquets
ICMP d'écho, et qui n'ont elles-mêmes que très
peu de pannes. Mais lesquelles choisir ?
Il faut bien voir que ces machines sur l'Internet, ces amers ou mires
http://www.bortzmeyer.org/amer-mire.html (target en anglais) ne
nous appartiennent pas. Si chaque petit réseau local, pour tester sa
connectivité, pingue 192.0.2.1 toutes les trois minutes, et qu'il y a
dix millions de petits réseaux qui le font dans le monde, 192.0.2.1
recevra 50 000 paquets/seconde, ce qui est une charge sérieuse même
pour un gros serveur. (En débit, cela ne fera pas grand'chose car les
paquets de test seront de petite taille. Mais pour les routeurs et les
serveurs, ce n'est pas que le nombre de bits par seconde qui compte,
celui des paquets par seconde est également important, chaque paquet
nécessitant un traitement, indépendemment de sa taille.) Utiliser le
premier serveur qu'on a choisi pour des tests répétitifs, c'est comme
jeter une canette vide par terre : si une seule personne le fait, c'est
juste un peu agaçant, si tout le monde le fait, on détruit
l'environnement. Ce n'est pas parce qu'un service est publiquement
accessible qu'on peut le bombarder de requêtes pour son usage
personnel. Dans le passé, il est déjà arrivé qu'un constructeur
configure (bêtement) ses machines pour utiliser un serveur public sans
autorisation, l'écroulant ainsi sous la charge
http://slashdot.org/story/06/04/07/130209/d-link-firmware-abuses-open-n
tp-servers.
Qu'est-ce que cela nous laisse comme possibilités ? En posant la
question, on obtient des réponses (plus ou moins dans l'ordre
décroissant du nombre de suggestions) :
* 8.8.8.8 (ou, à la rigueur, 8.8.4.4, qui est sans doute moins
sollicité), à savoir Google Public DNS
http://www.bortzmeyer.org/google-dns.html. Un service très fiable,
qui a très peu de chances de tomber en panne. Mais peut-on l'utiliser
ainsi, de manière automatique, dans des tests répétés ? Cela ne figure
certainement pas dans les conditions d'utilisation de ce service, et
Google pourrait donc décider de couper les réponses ICMP écho du jour
au lendemain (ou de mettre en place une limitation de débit).
* www.facebook.com (ou www.google.com) avec l'argument « Si Facebook
est en panne, de toute façon, tout l'Internet est fichu ». Cela pose un
peu les mêmes problèmes que précédemment.
* Pinguer un des serveurs DNS de la racine. Ils marchent en permanence
(c'est sans doute un des composants les plus robustes de l'Internet),
répondent à l'ICMP écho et, n'étant pas gérés dans un but lucratif, on
n'est pas à la merci d'un changement soudain de politique commerciale.
Mais ces serveurs ne sont pas prévus pour un tel test automatisé. Ils y
résisteront, bien sûr, mais est-ce un usage légitime ? Je ne pense pas
et les opérateurs des serveurs racine, interrogés, sont également de
cet avis. Il faut aussi se rappeler qu'il s'agit d'un service
critique : toute perturbation est à éviter.
* Pinguer des équipements du
Re: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
_ping_._ovh_._net_ ?
En tout cas pas mal d'hébergeurs ont un
système similaire, je ne sais pas ce qu'il en des F.A.I.
En revanche,
ta question soulève un autre point, es tu sûr de pinguer le bon host ?
Parce que dans mon cas, je peux te dire de pinguer un site, ce ne sera
pas pour autant le serveur qui délivre (cache ou front end) qui te
répondra mais le load balancer dans le cas d'un virtual server sur des
ports any* ... Bref, le même problème qu'avec l'anycast, mais encore
pire ... (i.e. ton serveur est down mais l'équipement de répartition de
charge répond pour lui !)
Perso, même si c'est pas dans les conditions
d'utilisation, je continuerai à pinguer 8.8.8.8 et 8.8.4.4 pour test ou
n'importe quelle autre IP tant que ca me montre que ca marche niveau
couche basse !
Enfin, sur la différence entre test HTTP / DNS / ICMP,
l'objectif n'est pas du tout le même, mais les deux tests sont à faire
en parallèle. Perso, je monitore tout mon archi perso avec Munin (HTTP
loadtime) et Smokeping (ICMP/HTTP/DNS), ce qui me permet de voir les
pertes de paquets (L2/L3/L4) et les problèmes applis (L5/L6/L7). Je vais
ainsi plus vite dans l'analyse.
---
Fabien
VINCENT
---
Twitter : beufanet
Le
2012-09-05 22:06, Stephane Bortzmeyer a écrit :
Je crois que c'est
une question qui concerne directement les
opérateurs réseau (j'ai cité
Free pour les exemples mais cela n'a rien
de spécifique à Free). Avis
bienvenus.
http://www.bortzmeyer.org/que-pinguer.html [1]
Lorsqu'on met en place une
infrastructure de surveillance de serveurs
Internet, il est agaçant
de recevoir autant d'alarmes que de serveurs
surveillés, alors que
c'était simplement la connectivité Internet de la
sonde de
surveillance qui était en panne. Tous les grands logiciels de
surveillance de réseau ont une option pour éviter cela, qui permet de
dire que le test d'un serveur dépend du succès d'un test sur un autre
composant, par exemple le routeur de sortie (si ce dernier est en
panne, il n'y a pas besoin de tester les serveurs et d'alerter si ça
rate). Mais quel composant tester pour déterminer qu'on a un accès
Internet qui marche ?
Avec les logiciels de la famille Nagios comme
Icinga, l'option qui
permet d'indiquer la dépendance d'un test envers
un autre se nomme
parents. Si on écrit :
define host {
host_name freebox
address 192.168.1.1
}
define host {
host_name remote-host
parents freebox
...
}
alors on déclare
que le test de remote-host
dépend de celui de freebox. Si on est
connecté à
l'Internet par ce seul routeur, c'est logique. Si
freebox
est injoignable, le reste de l'Internet
l'est aussi.
Mais si
freebox fonctionne mais ne route plus
http://bugs.freeplayer.org/task/10258 [2] ? Ou bien si quelque chose
déconne dans le réseau de Free bloquant tout accès à l'extérieur ?
C'est là qu'il est utile de tester autre chose que le premier routeur.
On voudrait en fait tester si on a toujours un accès Internet et
pouvoir écrire :
define host {
host_name remote-host
parents
Internet
...
}
Mais comment faire ce test ? En pinguant des
machines distantes, bien évidemment. Il « suffit » de sélectionner des
machines stables, qui répondent aux paquets
ICMP d'écho, et qui n'ont
elles-mêmes que très
peu de pannes. Mais lesquelles choisir ?
Il
faut bien voir que ces machines sur l'Internet, ces amers ou mires
http://www.bortzmeyer.org/amer-mire.html [3] (target en anglais) ne
nous appartiennent pas. Si chaque petit réseau local, pour tester sa
connectivité, pingue 192.0.2.1 toutes les trois minutes, et qu'il y a
dix millions de petits réseaux qui le font dans le monde, 192.0.2.1
recevra 50 000 paquets/seconde, ce qui est une charge sérieuse même
pour un gros serveur. (En débit, cela ne fera pas grand'chose car les
paquets de test seront de petite taille. Mais pour les routeurs et
les
serveurs, ce n'est pas que le nombre de bits par seconde qui
compte,
celui des paquets par seconde est également important, chaque
paquet
nécessitant un traitement, indépendemment de sa taille.)
Utiliser le
premier serveur qu'on a choisi pour des tests répétitifs,
c'est comme
jeter une canette vide par terre : si une seule personne
le fait, c'est
juste un peu agaçant, si tout le monde le fait, on
détruit
l'environnement. Ce n'est pas parce qu'un service est
publiquement
accessible qu'on peut le bombarder de requêtes pour son
usage
personnel. Dans le passé, il est déjà arrivé qu'un constructeur
configure (bêtement) ses machines pour utiliser un serveur public
sans
autorisation, l'écroulant ainsi sous la charge
http://slashdot.org/story/06/04/07/130209/d-link-firmware-abuses-open-n
[4]
tp-servers.
Qu'est-ce que cela nous laisse comme
possibilités ? En posant la
question, on obtient des réponses (plus
ou moins dans l'ordre
décroissant du nombre de suggestions) :
*
8.8.8.8 (ou, à la rigueur, 8.8.4.4,
Re: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On Wed, Sep 5, 2012, at 22:06, Stephane Bortzmeyer wrote: Lorsqu'on met en place une infrastructure de surveillance de serveurs Internet, il est agaçant de recevoir autant d'alarmes que de serveurs surveillés [...] pour ma part, je pompe en multithread gràce à aria2c plusieurs favicon.ico de serveurs plus ou moins connus avec le logiciel aria2. une seule reponse (même d'un fichier vide) suffit a me dire que je suis connecté... aria2c -i liste.txt -j 45 --stop 13 --file-allocation=none --max-download-limit=1K --use-head=false seul soucis avec certains modeles plus grand public, ceux avec un serveur httpd intégré qui repondent en HTML vous n'êtes pas connecté lorsque la connexion internet est réelement rompue. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On Wed, Sep 5, 2012, at 23:03, Fabien V. wrote: _ping_._ovh_._net_ ? En tout cas pas mal d'hébergeurs ont un système similaire, je ne sais pas ce qu'il en des F.A.I. je complète mon méssage précedent. rien n'empeche de prendre le premier KO des principaux fichiers tests de tests de débits type test-debit.free.fr/image.iso vont t-ils apprécier un téléchargement régulier de données ? ca c'est vraiment une autre histoire... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
Bonjour,
Tester la connectivité à Internet ne me semble pas pour ma part la solution la
plus appropriée. Internet étant structurellement un réseau de réseaux (pour
simplifier), vous pourriez très bien avoir une inaccessibilité partielle de
quelques réseaux qui impliquerait une réponse ICMP pour une partie
seulement de vos serveurs. La perte de joignabilité des autres serveurs me
semble alors devoir être légitimement signalée.
Il me parait plus approprié d'avoir un dépendance du test de chaque serveur au
succès d'au moins un des autres tests. Un seul autre succès dans un même lot de
tests impliquerait une connectivité possible vers l’extérieur et légitimerait
une notification de défaillance de joignabilité (sans
certitude toutefois que la connectivité de l'équipement concerné par le test
soit nécessairement pour autant en défaut).
Autre solution ayant à mon sens un plus grand degrés de fiabilité si on en a
les moyens : que chaque équipement procède lui même à intervalle régulier à un
test de connectivité vers son réseau cible et notifie par un moyen tiers
(SMS, plusieurs serveurs de références sur différents
réseaux/transitaires, etc.), avec une centralisation des notifications via un
outils de supervision pour conserver une vue générale de la situation.
A plus large échelle, ce serait un peu comme si les sondes du RIPE étaient
pourvues d'une SIM, par exemple.
Voila mon modeste point de vue sur vos oeuvres, cordialement, Cédric.
Le 05/09/2012 22:06, Stephane Bortzmeyer a écrit :
Je crois que c'est une question qui concerne directement les
opérateurs réseau (j'ai cité Free pour les exemples mais cela n'a rien
de spécifique à Free). Avis bienvenus.
http://www.bortzmeyer.org/que-pinguer.html
Lorsqu'on met en place une infrastructure de surveillance de serveurs
Internet, il est agaçant de recevoir autant d'alarmes que de serveurs
surveillés, alors que c'était simplement la connectivité Internet de la
sonde de surveillance qui était en panne. Tous les grands logiciels de
surveillance de réseau ont une option pour éviter cela, qui permet de
dire que le test d'un serveur dépend du succès d'un test sur un autre
composant, par exemple le routeur de sortie (si ce dernier est en
panne, il n'y a pas besoin de tester les serveurs et d'alerter si ça
rate). Mais quel composant tester pour déterminer qu'on a un accès
Internet qui marche ?
Avec les logiciels de la famille Nagios comme Icinga, l'option qui
permet d'indiquer la dépendance d'un test envers un autre se nomme
parents. Si on écrit :
define host {
host_name freebox
address 192.168.1.1
}
define host {
host_nameremote-host
parents freebox
...
}
alors on déclare que le test de remote-host
dépend de celui de freebox. Si on est connecté à
l'Internet par ce seul routeur, c'est logique. Si
freebox est injoignable, le reste de l'Internet
l'est aussi.
Mais si freebox fonctionne mais ne route plus
http://bugs.freeplayer.org/task/10258 ? Ou bien si quelque chose
déconne dans le réseau de Free bloquant tout accès à l'extérieur ?
C'est là qu'il est utile de tester autre chose que le premier routeur.
On voudrait en fait tester si on a toujours un accès Internet et
pouvoir écrire :
define host {
host_nameremote-host
parents Internet
...
}
Mais comment faire ce test ? En pinguant des
machines distantes, bien évidemment. Il « suffit » de sélectionner des
machines stables, qui répondent aux paquets
ICMP d'écho, et qui n'ont elles-mêmes que très
peu de pannes. Mais lesquelles choisir ?
Il faut bien voir que ces machines sur l'Internet, ces amers ou mires
http://www.bortzmeyer.org/amer-mire.html (target en anglais) ne
nous appartiennent pas. Si chaque petit réseau local, pour tester sa
connectivité, pingue 192.0.2.1 toutes les trois minutes, et qu'il y a
dix millions de petits réseaux qui le font dans le monde, 192.0.2.1
recevra 50 000 paquets/seconde, ce qui est une charge sérieuse même
pour un gros serveur. (En débit, cela ne fera pas grand'chose car les
paquets de test seront de petite taille. Mais pour les routeurs et les
serveurs, ce n'est pas que le nombre de bits par seconde qui compte,
celui des paquets par seconde est également important, chaque paquet
nécessitant un traitement, indépendemment de sa taille.) Utiliser le
premier serveur qu'on a choisi pour des tests répétitifs, c'est comme
jeter une canette vide par terre : si une seule personne le fait, c'est
juste un peu agaçant, si tout le monde le fait, on détruit
l'environnement. Ce n'est pas parce qu'un service est publiquement
accessible qu'on peut le bombarder de requêtes pour son usage
personnel. Dans le passé, il est déjà arrivé qu'un constructeur
configure (bêtement) ses machines pour utiliser un serveur public sans
autorisation, l'écroulant ainsi sous la charge
Re: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
On 05/09/2012 22:06, Stephane Bortzmeyer wrote: Je crois que c'est une question qui concerne directement les opérateurs réseau (j'ai cité Free pour les exemples mais cela n'a rien de spécifique à Free). Avis bienvenus. Je pense que la réponse est complexe parce que la question n'est pas précise. On veut tester son accès à internet ? Alors on veut tester qu'on arrive bien jusqu'au coeur de son provider, c'est à dire typiquement le premier ou le deuxième hop après la passerelle qu'il nous a fournie (voire même ladite passerelle). Donc première partie de la réponse : assez facile. Au-delà ce qu'on veut tester, grosso modo, c'est notre capacité à joindre toute (n'importe quelle) cible sur internet. Bref on veut tester internet. Et là forcément il n'y a pas de réponse qui tienne en un ping tout simplement parce que si un test binaire unique permettait de tester internet, alors internet ne serait pas internet. Donc secondaire réponse : on peut pas. Et c'est une réponse. Enfin vérifier sa connectivité suppose que la notion de qualité, de neutralité, de stabilité, de latence... soit binaire ? Non vraiment, pour répondre à cette question il va falloir passer en [MISC]. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quelles machines pinguer pour vérifier sa connectivité Internet ?
Pour t'exposer ce que j'ai fait pour monitorer des accès internet sur
différents accès :
sur accès internet où j'ai un proxy sortant, je fais deux checks :
- internet_www
- internet_dns
le check internet_www est un check_http vers www.google.fr
le check internet_dns est un check_tcp(53) vers 8.8.4.4 ou 8.8.8.8
Le but étant de tester le service, j'ai jugé le ping pas représentatif.
Si l'un de ces checks échoue, le cache_peer de DMZ est désactivé ce
qui permet au proxies d'utilisateur de ne plus être dirigé sur ce
proxy dont l'accès internet est défaillant, mais d'être routés
systématiquement vers les autres accès internet.
En retour d'expérience sur ces tests, un seul faux positif dans les 2
dernieres années (pb d'infra chez google, qui avait été rapidement
réparé)
Par contre c'est bien pratique car ça permet de mesurer un peu la
qualité de l'accès internet, et chez certains opérateurs il reste du
boulot...
A+
2012/9/5 Stephane Bortzmeyer bortzme...@nic.fr:
Je crois que c'est une question qui concerne directement les
opérateurs réseau (j'ai cité Free pour les exemples mais cela n'a rien
de spécifique à Free). Avis bienvenus.
http://www.bortzmeyer.org/que-pinguer.html
Lorsqu'on met en place une infrastructure de surveillance de serveurs
Internet, il est agaçant de recevoir autant d'alarmes que de serveurs
surveillés, alors que c'était simplement la connectivité Internet de la
sonde de surveillance qui était en panne. Tous les grands logiciels de
surveillance de réseau ont une option pour éviter cela, qui permet de
dire que le test d'un serveur dépend du succès d'un test sur un autre
composant, par exemple le routeur de sortie (si ce dernier est en
panne, il n'y a pas besoin de tester les serveurs et d'alerter si ça
rate). Mais quel composant tester pour déterminer qu'on a un accès
Internet qui marche ?
Avec les logiciels de la famille Nagios comme Icinga, l'option qui
permet d'indiquer la dépendance d'un test envers un autre se nomme
parents. Si on écrit :
define host {
host_name freebox
address 192.168.1.1
}
define host {
host_nameremote-host
parents freebox
...
}
alors on déclare que le test de remote-host
dépend de celui de freebox. Si on est connecté à
l'Internet par ce seul routeur, c'est logique. Si
freebox est injoignable, le reste de l'Internet
l'est aussi.
Mais si freebox fonctionne mais ne route plus
http://bugs.freeplayer.org/task/10258 ? Ou bien si quelque chose
déconne dans le réseau de Free bloquant tout accès à l'extérieur ?
C'est là qu'il est utile de tester autre chose que le premier routeur.
On voudrait en fait tester si on a toujours un accès Internet et
pouvoir écrire :
define host {
host_nameremote-host
parents Internet
...
}
Mais comment faire ce test ? En pinguant des
machines distantes, bien évidemment. Il « suffit » de sélectionner des
machines stables, qui répondent aux paquets
ICMP d'écho, et qui n'ont elles-mêmes que très
peu de pannes. Mais lesquelles choisir ?
Il faut bien voir que ces machines sur l'Internet, ces amers ou mires
http://www.bortzmeyer.org/amer-mire.html (target en anglais) ne
nous appartiennent pas. Si chaque petit réseau local, pour tester sa
connectivité, pingue 192.0.2.1 toutes les trois minutes, et qu'il y a
dix millions de petits réseaux qui le font dans le monde, 192.0.2.1
recevra 50 000 paquets/seconde, ce qui est une charge sérieuse même
pour un gros serveur. (En débit, cela ne fera pas grand'chose car les
paquets de test seront de petite taille. Mais pour les routeurs et les
serveurs, ce n'est pas que le nombre de bits par seconde qui compte,
celui des paquets par seconde est également important, chaque paquet
nécessitant un traitement, indépendemment de sa taille.) Utiliser le
premier serveur qu'on a choisi pour des tests répétitifs, c'est comme
jeter une canette vide par terre : si une seule personne le fait, c'est
juste un peu agaçant, si tout le monde le fait, on détruit
l'environnement. Ce n'est pas parce qu'un service est publiquement
accessible qu'on peut le bombarder de requêtes pour son usage
personnel. Dans le passé, il est déjà arrivé qu'un constructeur
configure (bêtement) ses machines pour utiliser un serveur public sans
autorisation, l'écroulant ainsi sous la charge
http://slashdot.org/story/06/04/07/130209/d-link-firmware-abuses-open-n
tp-servers.
Qu'est-ce que cela nous laisse comme possibilités ? En posant la
question, on obtient des réponses (plus ou moins dans l'ordre
décroissant du nombre de suggestions) :
* 8.8.8.8 (ou, à la rigueur, 8.8.4.4, qui est sans doute moins
sollicité), à savoir Google Public DNS
http://www.bortzmeyer.org/google-dns.html. Un service très fiable,
qui a très peu de chances de tomber en panne. Mais peut-on l'utiliser
ainsi, de manière automatique, dans des tests répétés ? Cela ne figure
