Auteur Sujet: Plus de serveur Bouygues sur nPerf (Lu 8197 fois)

vivien · « **Réponse #12 le:** 03 janvier 2019 à 09:36:34 »

Merci hwti,

Ce sont ces lignes dans /var/lib/dpkg/info/nperf-server.prerm qui bloquaient la désinstallation.
En les commentant, c'est bon.

Code: [Sélectionner]

# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.

# Automatically added by dh_installinit
if [ -x "/etc/init.d/nperf-server" ] || [ -e "/etc/init/nperf-server.conf" ]; then
        invoke-rc.d nperf-server stop || exit $?
fi
# End automatically added section

/etc/init.d/nperf-server existe bien mais il me semble qu'il n'est pas utilisé et que c'est /etc/systemd/system/multi-user.target.wants/nperf-server.service qui permet le lancement

hwti · « **Réponse #13 le:** 03 janvier 2019 à 09:52:49 »

Si c'est un service systemd natif, je comprends.
Mais systemd sait aussi gérer les initscripts suffisemment standards, et dans ce cas la commande service fonctionne aussi, et compte tenu de https://manpages.debian.org/unstable/init-system-helpers/invoke-rc.d.8.en.html je suppose que invoke.rc.d fait de même.

vivien · « **Réponse #14 le:** 03 janvier 2019 à 10:40:38 »

nperf-server fonctionne bien après installation :

# systemctl status nperf-server
● nperf-server.service - nPerfServer
Loaded: loaded (/lib/systemd/system/nperf-server.service; disabled; vendor preset: enabled)
Active: inactive (dead)

# systemctl enable nperf-server
Synchronizing state of nperf-server.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable nperf-server

# systemctl status nperf-server
● nperf-server.service - nPerfServer
Loaded: loaded (/lib/systemd/system/nperf-server.service; enabled; vendor preset: enabled)
Active: inactive (dead)

# systemctl start nperf-server

# systemctl status nperf-server
● nperf-server.service - nPerfServer
Loaded: loaded (/lib/systemd/system/nperf-server.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-01-03 10:33:29 CET; 2s ago
Process: 3932 ExecStart=/etc/init.d/nperf-server start-systemd (code=exited, status=0/SUCCESS)
Process: 3856 ExecStartPre=/etc/init.d/nperf-server initnet (code=exited, status=0/SUCCESS)
Main PID: 3946 (nPerfServer)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/nperf-server.service
└─3946 /usr/bin/nPerfServer -x --pidfile=/var/lib/nperf-server/nPerfServer.pid -p 8081 -t 8443 --uuidfile=/var/lib/nper

janv. 03 10:33:29 nperf2-ntr nPerfServer[3946]: Could not redirect STDERR to /dev/null, not critical
janv. 03 10:33:29 nperf2-ntr nPerfServer[3946]: INFO: Starting nPerfServer 2.1.7 2018-12-21 ...
janv. 03 10:33:29 nperf2-ntr nPerfServer[3946]: INFO: Analyzing system...
janv. 03 10:33:29 nperf2-ntr systemd[1]: Started nPerfServer.
janv. 03 10:33:29 nperf2-ntr nPerfServer[3946]: INFO: > CPU name: Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz
janv. 03 10:33:29 nperf2-ntr nPerfServer[3946]: INFO: > CPU cores: 8
janv. 03 10:33:29 nperf2-ntr nPerfServer[3946]: INFO: > Thread capacity detected: 8
janv. 03 10:33:29 nperf2-ntr nPerfServer[3946]: INFO: > Memory size: 32766148
janv. 03 10:33:29 nperf2-ntr nPerfServer[3946]: INFO: CERT-UPDATE > Initiating HTTPS request to ws.nperf.com ...
janv. 03 10:33:29 nperf2-ntr nPerfServer[3946]: INFO: CERT-UPDATE > Current TLS Certificate is up-to-date! (Hash:ff98a5a66904d84b2

Je vous dit dès que c'est de retour sur la carte.

hwti · « **Réponse #15 le:** 03 janvier 2019 à 11:06:12 »

Donc il y a un service systemd natif (/lib/systemd/system/nperf-server.service), qui se sert du script d'init SysV de manière particulière ("/etc/init.d/nperf-server initnet" et "/etc/init.d/nperf-server start-systemd").

Le "/lib/systemd/systemd-sysv-install enable nperf-server" active le script SysV, mais il n'est pas utilisé directement pour autant (il n'est pas invoqué avec start), sauf à déinstaller systemd (ce qui n'est pas possible).

vivien · « **Réponse #16 le:** 03 janvier 2019 à 11:58:04 »

Le serveur de Anycast de Bouygues est de retour sur la carte.
=> https://fr-bouygues-massy-01-40g.nperf.net/
Les serveurs de Paris / Lyon / Aix-en-Provence / Lille / Bordeaux sont tous fonctionnels sur les ports 80 (http), 443 (https), 8081 (http) et 8443 (https) en IPv4 comme en IPv6.

Je m’attaque à celui d'Ikoula.

vivien · « **Réponse #17 le:** 03 janvier 2019 à 15:52:33 »

Le serveur nPerf d'Ikoula est en ligne.

Le test web utilise uniquement le port 8443 en https, le serveur n'est visible que si ce port n'est pas bloqué (en entreprise il peut être bloqué)

hwti · « **Réponse #18 le:** 01 mai 2019 à 00:28:49 »

Les serveurs Bouygues ont disparu de nPerf et Speedtest.

fr-bouygues-massy-01-40g.nperf.net => 89.84.1.226 : ne répond pas
bouygues.testdebit.info, paris.testdebit.info, ... : OK
http://massy.testdebit.info/ : erreur 403

vivien · « **Réponse #19 le:** 01 mai 2019 à 13:07:22 »

Merci de l'alerte.

Je voyais bien de gros problèmes depuis le 30 avril 6h00 du matin, sans identifier la cause.

Le problème ne concerne que IPv6 : Un filtre a visiblement été mis en place pour limiter l'IPv6 au réseau Bouygues Telecom (+ Adeli !)

Tous les serveurs Bouygues sont impactés, sauf un seul : fr.archive.ubuntu.com le serveur qui distribue les mises à jour pour Ubunutu et ses dérivés (j'avais été contacté pour ce serveur qui génère beaucoup de trafic IPv6)

Ce qui ne fonctionne plus :
- nPerf
- Speedtest d'Ookla
- IPv6-Test

Ce qui fonctionne toujours parfaitement :
- Les tests de débit QoSi sur Android/ iOS (4GMark, DébiTest 60, KiCapte, Tu Captes ?, Gigalis, NetgMark...) : Ces tests forcent l’utilisation de l'IPv4 et n'ont pas de support de l'IPv6

Ce qui fonctionne uniquement en IPv4 :
- tous les tests de débit via des fichiers ou iPerf3 (sauf sur le serveur iPerf3 de Lyon, j'ai envoyé un mail hier soir sur cette problématique qui est distincte de la perte d'IPv6)

Exemple de traceroute :

Depuis Adeli, c'est OK:
$ mtr -zrwc100 bouygues.testdebit.info Start: Wed May 1 12:47:36 2019 HOST: lafibre Loss% Snt Last Avg Best Wrst StDev 1. AS43142 bgp1.adeli.biz 0.0% 100 408.4 52.0 0.2 2466. 301.8 2. AS5410 2001:860:bbe1:10::1 0.0% 100 1.5 1.5 1.4 1.9 0.0 3. AS5410 2001:860:bbe0:109::2 0.0% 100 2.1 2.0 1.9 2.3 0.0 4. AS5410 2001:860:b211:5200::64 0.0% 100 1.9 2.0 1.9 2.1 0.0 5. AS5410 2001:860:deff:1000::2 0.0% 100 1.5 1.4 1.4 1.6 0.0

Depuis OVH : on est bloqué en entrée du réseau Bouygues Telecom
$ mtr -zrwc100 bouygues.testdebit.info Start: 2019-05-01T12:47:29+0200 HOST: ovh Loss% Snt Last Avg Best Wrst StDev 1. AS16276 _gateway 0.0% 100 0.3 0.3 0.2 0.7 0.1 2. AS??? fc00::1 0.0% 100 0.4 0.4 0.2 0.9 0.1 3. AS16276 2001:41d0:0:1:3::a5bf 0.0% 100 0.6 0.5 0.4 0.9 0.1 4. AS16276 2001:41d0:0:1:3::a3ec 0.0% 100 0.6 0.6 0.4 1.8 0.2 5. AS16276 2001:41d0:0:1:3::a3c4 0.0% 100 0.6 0.6 0.4 0.8 0.1 6. AS16276 2001:41d0:0:50::1:9306 0.0% 100 1.2 1.2 1.0 1.6 0.1 7. AS16276 2001:41d0:0:50::5:4c 0.0% 100 0.5 0.6 0.4 1.3 0.1 8. AS??? ? ? 100.0 100 9. AS16276 be100-1106.gsw-1-a9.fr.eu 94.0% 100 9.9 9.5 9.2 9.9 0.2 10. AS16276 be100-2.th2-1-a9.fr.eu 86.0% 100 9.8 9.8 9.5 10.1 0.2 11. AS??? ? ? 100.0 100

Depuis Ikoula : on est bloqué en entrée du réseau Bouygues Telecom
$ mtr -zrwc100 bouygues.testdebit.info Start: Wed May 1 12:47:43 2019 HOST: ikoula Loss% Snt Last Avg Best Wrst StDev 1. AS21409 2a00:c70:1:213:246:63:0:1 26.0% 100 0.8 12.5 0.4 524.3 65.6 2. AS174 ikoula.demarc.cogentco.com 0.0% 100 1.2 29.7 0.9 401.0 83.3 3. AS21409 2a00:c70::1:16 0.0% 100 1.0 14.7 0.9 385.7 61.5 4. AS1200 2001:7f8:1::a502:1409:1 0.0% 100 4.5 21.6 4.3 458.8 68.6 5. AS??? 10gigabitethernet-2-2.par2.he.net 0.0% 100 3.9 6.0 3.8 25.3 4.8 6. AS??? ? ? 100.0 100

Depuis K-Net : on est bloqué en entrée du réseau Bouygues Telecom
$ mtr -zrwc100 bouygues.testdebit.info Start: 2019-05-01T12:47:38+0200 HOST: k-net Loss% Snt Last Avg Best Wrst StDev 1. AS24904 rt-01-th2.kwaoo.net 0.0% 100 0.6 0.7 0.6 5.8 0.5 2. AS1299 prs-b5-link.telia.net 0.0% 100 0.7 1.3 0.6 31.3 3.5 3. AS??? ? ? 100.0 100

Je vais envoyer un mail à Bouygues Telecom mais cela risque de durer plusieurs jours : il n'y a pas de solution simple, il est probable que la solution soit de changer de plages IPv6.

kgersen · « **Réponse #20 le:** 01 mai 2019 à 14:48:43 »

Ce n'est pas rassurant ce manque de "maîtrise" d'IPv6 par Bouygues...

vivien · « **Réponse #21 le:** 01 mai 2019 à 15:25:28 »

Je suppose que les plages IPv6 utilisées sont dans des plages IPv6 d’infrastructure Bouygues Telecom donc non joignable depuis Internet.

Soit il faut adapter le filtre, avec une exception comme pour 2001:860:f70a::2 (Ubuntu) soit il faut changer d'IPv6.

hwti · « **Réponse #22 le:** 01 mai 2019 à 15:59:28 »

Donc nPerf/Speedtest ont enlevé les serveurs car ils ne répondent plus en IPv6.

Mais pourquoi est-ce que les ports TCP 80/443/8443 ne répondent pas sur fr-bouygues-massy-01-40g.nperf.net en IPv4 ?
Le serveur répond au ping pourtant, et envoie bien des ICMP connexion refused sur les ports fermés.

vivien · « **Réponse #23 le:** 01 mai 2019 à 16:20:47 »

La date du 30 avril 6h00 du matin correspond au serveur de Lille.

Je vois que nPerf a été coupé plus tôt, cf graphe ci-dessous.

Il semblait pourtant up :

Code: [Sélectionner]

mai 01 11:33:47 nperf2-ntr nPerfServer[2072]: INFO: ALIVE-REPORT > Initiating HTTPS request to ws.nperf.com ...
mai 01 11:33:47 nperf2-ntr nPerfServer[2072]: INFO: ALIVE-REPORT > Received 200 OK.
mai 01 12:33:47 nperf2-ntr nPerfServer[2072]: INFO: ALIVE-REPORT > Initiating HTTPS request to ws.nperf.com ...
mai 01 12:33:47 nperf2-ntr nPerfServer[2072]: INFO: ALIVE-REPORT > Received 200 OK.
mai 01 13:33:47 nperf2-ntr nPerfServer[2072]: INFO: ALIVE-REPORT > Initiating HTTPS request to ws.nperf.com ...
mai 01 13:33:47 nperf2-ntr nPerfServer[2072]: INFO: ALIVE-REPORT > Received 200 OK.
mai 01 14:33:47 nperf2-ntr nPerfServer[2072]: INFO: ALIVE-REPORT > Initiating HTTPS request to ws.nperf.com ...
mai 01 14:33:48 nperf2-ntr nPerfServer[2072]: INFO: ALIVE-REPORT > Received 200 OK.
mai 01 15:33:48 nperf2-ntr nPerfServer[2072]: INFO: ALIVE-REPORT > Initiating HTTPS request to ws.nperf.com ...
mai 01 15:33:48 nperf2-ntr nPerfServer[2072]: INFO: ALIVE-REPORT > Received 200 OK.

J'ai redémarré le serveur, et il répond maintenant en IPv4 (ce qui ne sert à rien vu qu'il est désactivé)
=> https://fr-bouygues-massy-01-40g.nperf.net/