La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Bouygues Telecom => 
Incidents Bouygues => Discussion démarrée par: Perchut le 09 juillet 2017 à 18:52:03
-
J'up ce sujet.
[ Le sujet initial est ici : https://lafibre.info/incidents-ftth/connexion-tres-lente-ce-soir/msg457531/#msg457531 ]
Pertes de paquets à gogo ce soir...
C:\Users\Gregoire>ping lafibre.info -t
Envoi d’une requête 'ping' sur lafibre.info [46.227.16.8] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Réponse de 46.227.16.8 : octets=32 temps=18 ms TTL=59
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 46.227.16.8 : octets=32 temps=22 ms TTL=59
Réponse de 46.227.16.8 : octets=32 temps=17 ms TTL=59
Délai d’attente de la demande dépassé.
Réponse de 46.227.16.8 : octets=32 temps=21 ms TTL=59
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 46.227.16.8 : octets=32 temps=20 ms TTL=59
Réponse de 46.227.16.8 : octets=32 temps=17 ms TTL=59
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 46.227.16.8 : octets=32 temps=20 ms TTL=59
Réponse de 46.227.16.8 : octets=32 temps=22 ms TTL=59
Réponse de 46.227.16.8 : octets=32 temps=16 ms TTL=59
Réponse de 46.227.16.8 : octets=32 temps=17 ms TTL=59
Réponse de 46.227.16.8 : octets=32 temps=22 ms TTL=59
Délai d’attente de la demande dépassé.
Réponse de 46.227.16.8 : octets=32 temps=20 ms TTL=59
Réponse de 46.227.16.8 : octets=32 temps=19 ms TTL=59
Réponse de 46.227.16.8 : octets=32 temps=18 ms TTL=59
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 46.227.16.8 : octets=32 temps=19 ms TTL=59
Délai d’attente de la demande dépassé.
Réponse de 46.227.16.8 : octets=32 temps=29 ms TTL=59
Réponse de 46.227.16.8 : octets=32 temps=31 ms TTL=59
Réponse de 46.227.16.8 : octets=32 temps=33 ms TTL=59
Délai d’attente de la demande dépassé.
Réponse de 46.227.16.8 : octets=32 temps=33 ms TTL=59
Délai d’attente de la demande dépassé.
Réponse de 46.227.16.8 : octets=32 temps=18 ms TTL=59
Statistiques Ping pour 46.227.16.8:
Paquets : envoyés = 35, reçus = 20, perdus = 15 (perte 42%),
Durée approximative des boucles en millisecondes :
Minimum = 16ms, Maximum = 33ms, Moyenne = 21ms
Ctrl+C
^C
C:\Users\Gregoire>ping www.google.fr -t
Envoi d’une requête 'ping' sur www.google.fr [216.58.205.3] avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 216.58.205.3 : octets=32 temps=14 ms TTL=55
Réponse de 216.58.205.3 : octets=32 temps=12 ms TTL=55
Réponse de 216.58.205.3 : octets=32 temps=13 ms TTL=55
Délai d’attente de la demande dépassé.
Réponse de 216.58.205.3 : octets=32 temps=12 ms TTL=55
Réponse de 216.58.205.3 : octets=32 temps=14 ms TTL=55
Réponse de 216.58.205.3 : octets=32 temps=14 ms TTL=55
Réponse de 216.58.205.3 : octets=32 temps=11 ms TTL=55
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 216.58.205.3 : octets=32 temps=12 ms TTL=55
Réponse de 216.58.205.3 : octets=32 temps=11 ms TTL=55
Délai d’attente de la demande dépassé.
Réponse de 216.58.205.3 : octets=32 temps=11 ms TTL=55
Réponse de 216.58.205.3 : octets=32 temps=12 ms TTL=55
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 216.58.205.3 : octets=32 temps=15 ms TTL=55
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 216.58.205.3 : octets=32 temps=15 ms TTL=55
Délai d’attente de la demande dépassé.
Statistiques Ping pour 216.58.205.3:
Paquets : envoyés = 32, reçus = 13, perdus = 19 (perte 59%),
Durée approximative des boucles en millisecondes :
Minimum = 11ms, Maximum = 15ms, Moyenne = 12ms
Ctrl+C
(http://reho.st/self/4bee9a6240e2aa4114a2b8b3985f9e487b6c0605.png)
On est reparti comme cet hiver ?
-
Paris 18, pareil depuis leur "maintenance" dans la nuit du 6 au 7 Juillet.
-
acontios est aussi touché sur Paris 14 : https://twitter.com/acontios_net/status/884114798400688128
une autre personne sur Issy : https://twitter.com/JymKhana/status/884116230617149440
-
Bonsoir !
Le 6 juillet à 20 h, j'ai reçu le SMS suivant :
Info Bbox : Une opération de maintenance technique a lieu dans votre quartier pour l'amélioration de la fibre durant la prochaine nuit du 6 au 7 juillet entre 23h et 7h. Des interruptions de services peuvent se produire. En cas de problème demain, redémarrez l'ensemble de vos équipements (y compris le petit boitier optique blanc). Nous vous invitons à appeler le 614 en cas de problème persistant.
Dans la nuit du 6 au 7 juillet, j'ai effectivement perdu la connexion à internet vers 1 h du matin. Précision : les voyants de la Bbox sont restés au blanc. Je n'ai pas tergiversé et j'ai sorti mon routeur 4G pour la fin de la soirée.
Depuis le matin du 7 juillet j'ai de nouveau accès à internet, mais j'ai des débits anormalement bas et instables.
Je viens de passer 30 min avec le service technique de Bouygues Telecom, qui m'a fait réinitialiser la Bbox, a réinitialisé l'ONT, a fait quelque chose concernant les débits, sans résultat, puis a fini par déclencher l'intervention d'un technicien "au niveau de ma ligne". Délai annoncé : 10 à 15 jours.
____
Je viens ici pour assouvir ma curiosité, car je ne comprends pas ce qui peut se passer. Je ne comprends pas ce qui après une opération de maintenance technique peut provoquer une baisse significative de débit, mais pas une coupure.
Et surtout ce qui peut faire que j'ai des résultats très différents d'un outil de mesure à un autre :
Speedtest.net Beta (HTML5) : en réception, 40 Mb/s maximum jusqu'à l'appel au service technique, depuis le débit croit de 20 Mb/s en début de test à 150 Mb/s en fin de test. En émission j'ai presque 250 Mb/s
Test de débit nPerf sur testdebit.info : 140 Mb/s en réception, 75 Mb/s en émission
curl sur un fichier de 100 Mo via testdebit.info : 1500 ko/s
iperf3 sur différents serveurs publics d'iperf.fr : quelques Ko la 1re seconde, 0 les suivantes (voir ci-dessous)
% iperf3 -c bouygues.testdebit.info -R
Connecting to host bouygues.testdebit.info, port 5201
Reverse mode, remote host bouygues.testdebit.info is sending
[ 4] local 192.168.1.1 port 42310 connected to 89.84.127.53 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 9.90 KBytes 81.0 Kbits/sec
[ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec
[ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec____
Et une remarque aux représentants de Bouygues Telecom : c'est très agaçant que le service technique lance systématiquement une réinitialisation du routeur ou du décodeur lorsque le problème provient de toute évidence du réseau et non des terminaux. Selon mon expérience, ça n'a jamais rien résolu, et j'ai pourtant affaire au service technique au moins une fois par trimestre pour le décodeur TV.
Aujourd'hui quand mon interlocutrice m'a annoncé qu'elle allait remettre à zéro mon routeur, je lui ai demandé de ne pas le faire, mais elle m'a répondu qu'elle ne pouvait pas accéder aux outils de diagnostic sans le faire.
Je lui ai alors demandé d'attendre quelques minutes que je me connecte à l'interface de gestion de la Bbox pour sauvegarder ma configuration (essentiellement baux DHCP fixes pour mes 25 terminaux). Bien qu'elle m'ait assuré ne rien avoir lancé de son côté, la Bbox avait déjà été réinitialisée une première fois (sans coupure de la connexion).
Il y aurait une réinitialisation automatique et silencieuse dès le début de la procédure de diagnostic ?
-
En effet c'est tout bonnement inutilisable :-(
-
Donc pareil pour moi (message annonçant l'opération de "maintenance" (Paris 18)), le smokeping de Vivien sur mon IP parle de lui-même :
https://lafibre.info/dns/smokeping.cgi?target=BouyguesTelecom.yrousse (https://lafibre.info/dns/smokeping.cgi?target=BouyguesTelecom.yrousse)
Un mtr depuis une Dedi (DC2) sur mon IP me montre 66% de perte.
Un carnage et l'impact est sévère sur toute activité (et pas que sur les perfs des benchmarks).
-
Funfact :
Paris 20 > RAS https://lafibre.info/dns/smokeping.cgi?target=BouyguesTelecom.paris2
Puteaux (92) > RAS https://lafibre.info/dns/smokeping.cgi?target=BouyguesTelecom.paul92
Alfortville (94) > RAS https://lafibre.info/dns/smokeping.cgi?target=BouyguesTelecom.benoitm76
Et chez Perchut ça semble "réparé" depuis 19H > https://lafibre.info/dns/smokeping.cgi?target=BouyguesTelecom.perchut
-
Bah oui, typique d'un problème sur un lien ou un routeur backbone. Seul certaines destinations sont concernées (celles passant par le lien ou equipement qui sature ou qui déconne)
-
L'orage est passé (vu la météo sur Paris, il fallait que je la fasse… Désolé.) chez moi. 5 heures pénibles, dont plus de 2 heures de quasi impossibilité d'atteindre mes Dedibox.
Vivement demain soir…
J'espère que Boris pourra nous regarder ça, car comme en témoignait Romain, passer par le support client d'un FAI, c'est une expérience pénible…
Ci-dessous mon smokeping depuis lafibre.info.
-
Je confirme, idem chez moi depuis à peu près les mêmes heures.
A mon avis, leur maintenance n'a pas dû se passer comme prévu, et du coup leur réseau fonctionne depuis en dégradé, et sature aux heures de pointes.
En tout cas, l'incident semblait assez généralisé, vu ce qu'on a pu lire sur twitter: Le traffic Bytel<>OVH semblait largement bas, sur leur weathermap:
https://twitter.com/marcoplaut/status/884163625308626944
-
Je confirme, idem chez moi depuis à peu près les mêmes heures.
A mon avis, leur maintenance n'a pas dû se passer comme prévu, et du coup leur réseau fonctionne depuis en dégradé, et sature aux heures de pointes.
Yep. Et tu te souviendras peut-être que j'avais (maladroitement) commencer à couiner sur Twitter quant au lien entre les réseaux bbox <> online, il y a 10 jours.
Petite pensée émue (ou agacé, c'est selon...) envers les techs qui ont fait une maintenance sans doute destinée à corriger un problème de saturation (déjà sensible) et qui se retrouve avec une dégradation sévère chaque soir, depuis leur intervention.
-
Bon, j'ai fait mon client final consciencieux et j'ai fait ouvrir un ticket… Compte tenu des infos collectées à cette étape et du niveau technique de la personne au SC (qui fût fort aimable au demeurant), ça ne va servir pratiquement à rien. J'ai au moins pu la convaincre de ne pas se focaliser sur la notion de problème local/ligne physique.
Bref, par principe, problème = ticket.
Et je croise les doigts pour qu'un ingé Bouygues nous lise et qu'il puisse réagir à ce que ses outils de monitoring doivent déjà lui "hurler": ça merdouille ici et là. ;) #Boris
-
Bonjour,
Nos équipes investiguent sur l'incident.
Merci pour vos remontées.
Cordialement,
Boris de Bouygues Telecom.
-
Merci :-)
-
Ouais, vous, vous avez des pertes de paquets alors que pendant ce temps là je fais le tour de la France (et pas en vélo). :'(
-
Oh bah t'en fais pas, ta situation est bien plus enviable que la leur !
-
Les équipes ont identifiées un bug qui a été corrigé à 17h40.
Si il n'y a pas de double incident, tout devrait bien se passer ce soir.
Je confirme, idem chez moi depuis à peu près les mêmes heures.
A mon avis, leur maintenance n'a pas dû se passer comme prévu, et du coup leur réseau fonctionne depuis en dégradé, et sature aux heures de pointes.
En tout cas, l'incident semblait assez généralisé, vu ce qu'on a pu lire sur twitter: Le traffic Bytel<>OVH semblait largement bas, sur leur weathermap:
https://twitter.com/marcoplaut/status/884163625308626944
L'incident impacte une petite partie des clients FTTH raccordés sur le BSR de Nanterre, c'est donc limité.
Le tweet de Marc-Antoine PLAUT dit "Oui la weathermap ovh est parlante: soit c'est vraiment surdimensionné par rapport aux autres FAI soit y'a problème!"
Je vous conforme que nous avons de la capacité disponible avec OVH. Le trafic hier soir était supérieur aux autres jours de la semaine (le pic de trafic hebdomadaire est le dimanche soir ou le lundi soir)
Voici le graphique du lien OVH en question :
-
Le tweet de Marc-Antoine PLAUT dit "Oui la weathermap ovh est parlante: soit c'est vraiment surdimensionné par rapport aux autres FAI soit y'a problème!"
La réponse avait été donnée sinon dans le fil : https://twitter.com/Alo_is/status/884304305771171841
La map de Paris est pas à jour. C'est celle Europe la bonne. Y'a un 100G entre OVH et Bouygues.
-
Pour notre culture, quel etait le bug ?
Et toujours pour notre culture, BSR et CBR ca veut dire quoi pour vous ? :-)
-
Chez Bouygues Telecom comme chez de nombreux grands opérateurs, nous sommes avec une architecture P / PE.
rpt => Routeur PE de collecte du peering / transit (exemple dans un traceroute : rpt02-th2)
bsr => Routeur PE de collecte des flux de nos clients (exemple dans un traceroute : bsr02-th2)
cbr => Routeur P avec pour unique fonction de routeur les flux entre les différents PE (exemple dans un traceroute : cbr01-ntr)
-
Les équipes ont identifiées un bug qui a été corrigé à 17h40.
Si il n'y a pas de double incident, tout devrait bien se passer ce soir.
Boris, c'est mieux si j'appelle pour fermer explicitement le ticket fait auprès du SC ou je laisse le rapprochement se faire au niveau du SI du Customer Care?
En tous cas, pour le moment (19h20), ça semble bien se passer de mon coté. Merci!
-
BSR = Bootstrap Router (selon Google)
CBR = Converged Broadband Router
RPT = Routeur Peering Transit (une supposition, je n'ai rien trouvé sur Google)
Bouygues Telecom a une architecture classique P / PE :
- Les BSR et les RPT sont des routeur PE (Provider Edge Router = routeur de bordure du réseau, connecté aux clients pour les BSR ou aux peering pour les RPT)
- Les CBR sont des routeur P (Provider Router = routeur de cœur de réseau qui fait principalement du transit.)
Ce schéma de davidb dans le sujet P router Bypass (https://lafibre.info/bgp/p-router-bypass/) pourrait convenir : CBR en rouge, BSR en bleu et RPT en vert
(https://lafibre.info/images/routeur/201505_p_router_bypass_3.png)
-
Bonjour !
Malgré plusieurs redémarrages, j'ai toujours des problèmes de débit :
(https://pic.nperf.com/r/152350270-R2GRxEwy.png)
J'ai des débits en dents de scie en BitTorrent (voir pièce-jointe).
Suis-je le seul ? Que puis-je faire ?
-
Bonjour Romain,
L'incident qui a suscité l'ouverture de ce sujet n'est très probablement responsable de ton souci de performance.
Autant que je puisse le constater de mon coté, la perte importante de paquets constatée début juillet est de l'histoire ancienne.
Et ton benchmark en soi ne dit pas grand chose. Je t'invite à réaliser d'autres tests vers d'autres destinations et de privilègier des outils un peu plus fins (mtr, iperf…). Et sans doute, d'ouvrir un nouveau sujet dédié à ton souci. ;)
-
Pour notre culture, quel etait le bug ?
Dans le LAG en question (agrégation de plusieurs ports 10 Gb/s pour la collecte de plusieurs NRO) la répartition du trafic (bonding (https://lafibre.info/iperf/gs108t-nc360t-n5550-load-balancing-33mbs/msg51905/#msg51905)) n'était plus réalisée correctement pour les clients qui avaient eu l'opération de maintenance : tous ces clients se retrouvaient sur le même lien 10 Gb/s.
-
Merci de l'explication. Forcèment, ca n'aide pas si le LAG ne fait pas son boulot correctement :-)
Et pour pousser la curiosité un peu plus loin: Il est supposé écouler combien de traffic aux heures de pointes, ce lien ? :-)
-
Bonjour Romain,
L'incident qui a suscité l'ouverture de ce sujet n'est très probablement responsable de ton souci de performance.
Autant que je puisse le constater de mon coté, la perte importante de paquets constatée début juillet est de l'histoire ancienne.
Et ton benchmark en soi ne dit pas grand chose. Je t'invite à réaliser d'autres tests vers d'autres destinations et de privilègier des outils un peu plus fins (mtr, iperf…). Et sans doute, d'ouvrir un nouveau sujet dédié à ton souci. ;)
Salut Yann !
C'est probablement lié puisque le début de mes ennuis coïncide avec la maintenance, comme indiqué dans ce précédent message (https://lafibre.info/incidents-ftth/pertes-de-paquet-suite-maintenance-du-06072017/msg457533/#msg457533).
Mais s'il faut créer un fil dédié, qu'un modo n'hésite pas à extraire mes derniers messages ! :)
-
Salut Yann !
C'est probablement lié puisque le début de mes ennuis coïncide avec la maintenance, comme indiqué dans ce précédent message (https://lafibre.info/incidents-ftth/pertes-de-paquet-suite-maintenance-du-06072017/msg457533/#msg457533).
Mais s'il faut créer un fil dédié, qu'un modo n'hésite pas à extraire mes derniers messages ! :)
Autant pour moi…
Essaie de faire quelques mtr/iperf pour voir si perds des paquets sur des destinations particulières. Et quelques wget/curl sur des fichiers de tests hébergés sur testdebit.info ou équivalent chez OVH et Online, par exemple. Les benchmarks web-fancy, c'est "meh"...