Auteur Sujet: Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia  (Lu 6212 fois)

0 Membres et 1 Invité sur ce sujet

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 804
  • 73
Salut,

Je viens ici pour résumer un problème que je peux observer depuis mon passage sur offre Bbox ADSL (par intérêt technique, pour les autres utilisateurs concernés et éventuellement en voie de résolution de celui-ci ;)).
Ce qui suit a été déduit par conversation étayée avec le support du CDN concerné et par observation.


Le dysfonctionnement
L'établissement d'une connexion TCP avec n'importe quel serveur cache du réseau Fastly, depuis ma connexion Bouygues, échoue de manière aléatoire, environ la moitié du temps.

Fastly est un réseau CDN qui par lequel passe par exemple le trafic de :
  • Imgur (le plus gros hébergeur d'images de la planète)
  • Le serveur de téléchargement Github (pas le frontal web)
  • Wikia
  • Plusieurs journaux anglophones importants...
Le problème est donc significatif et entrave par exemple la récupération de logiciels depuis le dépôt de ma distribution (AUR) ou une navigation fluide (sans avoir à rafraîchir x fois une page) sur les sites concernés.


L'analyse réseau
Une capture réseau aux deux fins permet de comprendre clairement le problème : le paquet SYN est transmis correctement, le SYN-ACK bien reçu, mais de manière aléatoire, le ACK se perd en étant routé vers le mauvais cache (un cache différent), ce qui se caractérise d'un renvoi d'un RST de sa part et la réception de retransmissions du bon cache.

La raison est la suivante : le routeur de Telia qui prend en charge ce trafic utilise un hash pour identifier une connexion TCP unique, et l'utiliser pour faire correspondre de manière constante une connexion à un cache en sortie, de manière à répartir de manière égale le trafic en fonction.
Le terme spécialisé associé étant ECMP (Equal-cost multi-path routing).

La base du problème est que le routeur de Telia ne se limite pas à une tuple "(IP src, IP dst, port src, port dst, protocol)" pour générer ce hash : il intègre aussi d'autres éléments de l'en-tête TCP/IP, dont le champ IP DSCP, servant à la priorisation du trafic.
Or, le dysfonctionnement est causé par le fait que le champ DSCP n'est pas stable entre le paquet SYN et les paquets qui suivent : il est modifié par le terminal Bbox ou les équipements Bouygues (je ne sais pas tout à fait encore), où il est mis respectivement à 0 et à 2 (soit 8 si on parle plutôt en termes de champ ToS).


Impact global
Il semblerait que le problème impacte environ 6 % du trafic total sur la plage 176.128.0.0/12 (qui est large et inclut sûrement également du trafic mobile).

Plusieurs hypothèses pourraient expliquer cette localisation partielle du problème : soit le passage par un point particulier du réseau, soit l'affectation de la QoS à par exemple certaines plages par des équipements intermédiaires, soit un comportement particulier des différents modèles de box (partie logicielle ou matérielle). Je suis sur un modèle F@st 5330b avec firmware à jour (10.2.4).

Je n'ai pas actuellement une vue suffisante sur le réseau ou le parc abonnés Bouygues pour faire des déductions supplèmentaires.

J'ai pu noter la présence de quelques références au champ DSCP dans le firmware de la box (en supposant dans un premier qu'elles soient davantage relatives aux services telles que la téléphonie), sans que celles visibles ne paraissent être très utiles sans nécessiter une interprétation de certains pilotes ou binaires opaques. Voici la sortie d'un grep :

$ grep -rFi dscp
Fichier binaire bin/tr069 correspondant
Fichier binaire bin/diag_bin correspondant
Fichier binaire bin/ethswctl correspondant
Fichier binaire bin/tcpdump correspondant
Fichier binaire bin/vlanctl correspondant
Fichier binaire bin/ip_ping_diag_bin correspondant
Fichier binaire bin/ip correspondant
Fichier binaire bin/traceroute_diag_bin correspondant
Fichier binaire lib/libphone.so correspondant
Fichier binaire lib/modules/2.6.30/extra/bcmvlan.ko correspondant
Fichier binaire lib/modules/2.6.30/extra/bcm_enet.ko correspondant
Fichier binaire lib/iptables/libxt_dscp.so correspondant
Fichier binaire lib/iptables/libxt_DSCP.so correspondant
Fichier binaire lib/libmodel.so correspondant
Fichier binaire lib/private/libethswctl.so correspondant
Fichier binaire lib/private/libbmdpkgsrc.so correspondant
Fichier binaire lib/private/libmdm.so correspondant
Fichier binaire lib/private/libbmdshell.so correspondant
Fichier binaire lib/private/libvlanctl.so correspondant
Fichier binaire lib/private/libcms_core.so correspondant
Fichier binaire lib/private/libbmdapi.so correspondant
Fichier binaire lib/private/libcms_dal.so correspondant
Fichier binaire lib/private/libcms_core.id0 correspondant
Fichier binaire lib/tr069plugins.so correspondant
Fichier binaire usr/bin/nuttcp correspondant
Fichier binaire usr/bin/phoneapp correspondant
etc/bewan/config.default/tr069.xml:          <DSCPCoupled type="boolean" writable="no" noActNotify="yes" implemented="yes" libraryName="tr069plugins.so"/>
etc/bewan/config.default/tr069.xml:            <DSCPMark type="unsignedInt" writable="yes" implemented="yes" prefixName="VoiceProfileSIP" libraryName="tr069plugins.so"/>
etc/bewan/config.default/tr069.xml:            <DSCPMark type="unsignedInt" writable="yes" implemented="yes" prefixName="VoiceProfileMGCP" libraryName="tr069plugins.so"/>
etc/bewan/config.default/tr069.xml:            <DSCPMark type="unsignedInt" writable="yes" implemented="yes" libraryName="tr069plugins.so"/>
etc/bewan/config.default/tr069.xml:      <DSCP type="unsignedInt" writable="yes" action="yes" implemented="yes" libraryName="tr069plugins.so"/>
etc/bewan/config.default/tr069.xml:      <DSCP type="unsignedInt" writable="yes" action="yes" implemented="yes" libraryName="tr069plugins.so"/>
etc/bewan/config.default/tr069.xml:      <DSCP type="unsignedInt" writable="yes" implemented="yes" libraryName="tr069plugins.so"/>
etc/bewan/config.default/tr069.xml:      <DSCP type="unsignedInt" writable="yes" implemented="yes" libraryName="tr069plugins.so"/>
etc/bewan/config.default/tr069.xml:          <DSCP type="unsignedInt" array="no" writable="yes" implemented="yes" libraryName="tr069plugins.so"/>
etc/bewan/config.default/tr069.xml:          <DSCPExclude type="boolean" array="no" writable="yes" implemented="yes" libraryName="tr069plugins.so"/>
etc/bewan/config.default/tr069.xml:        <DSCPCheck type="int" writable="yes" implemented="yes" libraryName="tr069plugins.so"/>
etc/bewan/config.default/tr069.xml:        <DSCPMark type="int" writable="yes" implemented="yes" libraryName="tr069plugins.so"/>
etc/bewan/config.default/router.xml:      <DSCPMark type="int" writable="1" values="0:63" onchange="/etc/bewan/init.d/tr069" merged_from="tr069/BEWAN/router.xml">0</DSCPMark>
etc/bewan/config.default/router.xml:    <DefaultDSCPMark type="int" writable="1" onchange="/etc/bewan/init.d/qos" withparam="1" merged_from="base_qos/BEWAN/router.xml">0</DefaultDSCPMark>
etc/bewan/config.default/router.xml:          <DSCPCheck type="int" writable="1" onchange="gen-qos-classify" withparam="0" merged_from="bytel_bboxd/BEWAN/router.xml"/>
etc/bewan/config.default/router.xml:          <DSCPMark type="int" writable="1" onchange="gen-qos-classify" withparam="0" merged_from="bytel_bboxd/BEWAN/router.xml"/>
etc/bewan/config.default/router.xml:      <DSCPMark type="int" writable="1" values="0:63" onchange="/etc/bbox/scripts/voip_sighup" merged_from="bytel_phoneapp/BEWAN/router.xml">0</DSCPMark>
etc/bewan/config.default/router.xml:      <DSCPMark type="int" writable="1" values="0:63" onchange="/etc/bbox/scripts/voip_sighup" merged_from="bytel_phoneapp/BEWAN/router.xml">0</DSCPMark>

Il serait peut-être de mentionner que la plage IP dans laquelle je me trouve mentionne toujours "origin: AS12844" (bien que je sois routé complètement par les équipements du réseau fixe (AS5410) et qu'il ne devrait pas y avoir de différence d'interconnexion). Dans l'hypothèse où des équipements de bordure appliqueraient des mécanismes en fonction de l'appartenance historique de cette plage.
Cependant, il semblerait que du trafic DSL soit présent dans les deux cas de figure observés.


Les possibilités de résolution
Fastly est revenu vers Telia pour aborder le problème, mais il est peu probable que l'investissement visant à modifier logiciellement/matériellement les routeurs pour que la politique de hashage des en-têtes diffère soit pris, en sachant que ce comportement ne paraît pas explicitement normativé ou prohibé quelque part.

=> L'issue la plus potentielle serait donc que le mécanisme de QoS chez Bouygues soit modifié pour corriger ce comportement inconstant, une fois sa localisation claire repérée.

(Alternativement, peut-être que l'emprunt délibéré d'un autre transitaire pourrait y changer quelque chose ?)


Voilà, si quelqu'un veut plus de précisions j'ai des traces et tout... Si vous êtes aussi chez Bouygues en DSL je veux bien connaître si ça vous affecte ou non + votre plage IP + votre modèle+firmware de box.
« Modifié: 10 mars 2016 à 13:37:52 par Marin »

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 804
  • 73
Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia
« Réponse #1 le: 19 mars 2016 à 19:13:13 »
Quelqu'un aurait un contact pour faire remonter ?

thibault64

  • Expert
  • Abonné Bbox fibre
  • *
  • Messages: 363
  • FTTH 1Gbps/700Mbps - Albi (81)
Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia
« Réponse #2 le: 19 mars 2016 à 19:52:27 »
Bah si ça concerne le réseau IP de Bouygues Télécom (de près ou de loin, dsl j'ai lu rapidement) essaye de voir avec Boris de Bouygues Télécom sur le forum.

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia
« Réponse #3 le: 19 mars 2016 à 20:55:08 »
Faudrait aussi regarder le dscp à la sortie du réseau Bouygues: s'il est modifié en interne, il devrait être remis à 0 en sortie. Sinon c'est mal.

s3phy

  • Abonné FreeMobile
  • *
  • Messages: 375
  • St Laurent des Hommes (24)
Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia
« Réponse #4 le: 20 mars 2016 à 06:54:42 »
Voilà, si quelqu'un veut plus de précisions j'ai des traces et tout... Si vous êtes aussi chez Bouygues en DSL je veux bien connaître si ça vous affecte ou non + votre plage IP + votre modèle+firmware de box.
Je suis dans 176.146.77.64/26 (dégroupage total Bouygues, réseau en propre, en Gironde)
Bbox Ubee TVW620.I
Firmware 10.2.0

Aucun soucis constaté, et pourtant je suis plutôt consommateur d'imgur (je passe beaucoup trop de temps sur reddit ::) )


EDIT :
Or, le dysfonctionnement est causé par le fait que le champ DSCP n'est pas stable entre le paquet SYN et les paquets qui suivent : il est modifié par le terminal Bbox ou les équipements Bouygues (je ne sais pas tout à fait encore), où il est mis respectivement à 0 et à 2 (soit 8 si on parle plutôt en termes de champ ToS).
Pour essayer de t'aider, je viens d'observer le trafic entrant sur mon dédié chez OVH, depuis ma connexion chez moi. Ça fait beaucoup de changements par rapport à ce que tu vérifies (pas Telia, pas Fastly) mais si ça peut aider…
Source et destination sont des machines sous Debian. À domicile je suis derrière ma Bbox en mode routeur. La capture est faite côté serveur dédié.
J'ai fait une simple requête HTTP pour voir le TCP handshake avec tcpdump. Je me suis permis d'anonymiser les hostnames.
$ sudo tcpdump -vvv tcp port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
07:03:32.395194 IP (tos 0x0, ttl 55, id 31931, offset 0, flags [DF], proto TCP (6), length 60)
    bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830 > mon.dedie.chez.ovh.http: Flags [S], cksum 0x85fb (correct), seq 4178697637, win 29200, options [mss 1460,sackOK,TS val 499998 ecr 0,nop,wscale 7], length 0
07:03:32.395340 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    mon.dedie.chez.ovh.http > bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830: Flags [S.], cksum 0x348f (incorrect -> 0x014c), seq 3215042843, ack 4178697638, win 28960, options [mss 1460,sackOK,TS val 685700082 ecr 499998,nop,wscale 7], length 0
07:03:32.428616 IP (tos 0x0, ttl 55, id 31932, offset 0, flags [DF], proto TCP (6), length 52)
    bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830 > mon.dedie.chez.ovh.http: Flags [.], cksum 0xa04a (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 500007 ecr 685700082], length 0
07:03:32.431719 IP (tos 0x0, ttl 55, id 31933, offset 0, flags [DF], proto TCP (6), length 161)
    bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830 > mon.dedie.chez.ovh.http: Flags [P.], cksum 0x7107 (correct), seq 1:110, ack 1, win 229, options [nop,nop,TS val 500007 ecr 685700082], length 109
07:03:32.431822 IP (tos 0x0, ttl 64, id 23270, offset 0, flags [DF], proto TCP (6), length 52)
    mon.dedie.chez.ovh.http > bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830: Flags [.], cksum 0x3487 (incorrect -> 0x9fd6), seq 1, ack 110, win 227, options [nop,nop,TS val 685700091 ecr 500007], length 0
07:03:32.432047 IP (tos 0x0, ttl 64, id 23271, offset 0, flags [DF], proto TCP (6), length 413)
    mon.dedie.chez.ovh.http > bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830: Flags [P.], cksum 0x35f0 (incorrect -> 0x1ec3), seq 1:362, ack 110, win 227, options [nop,nop,TS val 685700091 ecr 500007], length 361
07:03:32.465568 IP (tos 0x0, ttl 55, id 31934, offset 0, flags [DF], proto TCP (6), length 52)
    bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830 > mon.dedie.chez.ovh.http: Flags [.], cksum 0x9e5a (correct), seq 110, ack 362, win 237, options [nop,nop,TS val 500016 ecr 685700091], length 0
07:03:32.467733 IP (tos 0x0, ttl 55, id 31935, offset 0, flags [DF], proto TCP (6), length 157)
    bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830 > mon.dedie.chez.ovh.http: Flags [P.], cksum 0x5dc1 (correct), seq 110:215, ack 362, win 237, options [nop,nop,TS val 500016 ecr 685700091], length 105
07:03:32.468241 IP (tos 0x0, ttl 64, id 23272, offset 0, flags [DF], proto TCP (6), length 680)
    mon.dedie.chez.ovh.http > bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830: Flags [P.], cksum 0x36fb (incorrect -> 0x6f38), seq 362:990, ack 215, win 227, options [nop,nop,TS val 685700100 ecr 500016], length 628
07:03:32.503395 IP (tos 0x0, ttl 55, id 31936, offset 0, flags [DF], proto TCP (6), length 52)
    bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830 > mon.dedie.chez.ovh.http: Flags [F.], cksum 0x9b60 (correct), seq 215, ack 990, win 247, options [nop,nop,TS val 500025 ecr 685700100], length 0
07:03:32.503611 IP (tos 0x0, ttl 64, id 23273, offset 0, flags [DF], proto TCP (6), length 52)
    mon.dedie.chez.ovh.http > bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830: Flags [F.], cksum 0x3487 (incorrect -> 0x9b6a), seq 990, ack 216, win 227, options [nop,nop,TS val 685700109 ecr 500025], length 0
07:03:32.536588 IP (tos 0x0, ttl 55, id 31937, offset 0, flags [DF], proto TCP (6), length 52)
    bft33-h01-176-146-77-xxx.dsl.sta.abo.bbox.fr.41830 > mon.dedie.chez.ovh.http: Flags [.], cksum 0x9b4d (correct), seq 216, ack 991, win 247, options [nop,nop,TS val 500034 ecr 685700109], length 0
^C
12 packets captured
13 packets received by filter
0 packets dropped by kernel
Le TOS reste bien à 0 tout le long dans mon cas !
« Modifié: 20 mars 2016 à 07:16:46 par s3phy »

Boris de Bouygues Telecom

  • AS5410 Expert Bouygues Telecom
  • Abonné Bbox fibre
  • *
  • Messages: 2 763
  • Technopôle de Bouygues Telecom sur Meudon (92)
Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia
« Réponse #5 le: 20 mars 2016 à 09:28:03 »
Faudrait aussi regarder le dscp à la sortie du réseau Bouygues: s'il est modifié en interne, il devrait être remis à 0 en sortie. Sinon c'est mal.

Le DSPC est à 10 pour l'intégralité des flux sortant du réseau fixe Bouygues Telecom sur les ports TCP 80 / TCP 443 (paquets SYN, comme les suivants, qu'ils soient des paquets de données ou des paquets d'acquittements). Pour le réseau mobile, je vais vérifier, mais cela devrait être aussi le cas.

Marin, avez-vous la possibilité de faire une capture derrière Telia ?

Généralement tous les opérateurs commencent par réinitialiser le champ DSCP des paquets reçus en peering / transit. Il est en effet difficile de faire confiance à un flux venant de l'internet et chaque opérateur à sa propre stratégie sur les paquets DSCP.

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 804
  • 73
Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia
« Réponse #6 le: 20 mars 2016 à 10:06:45 »
Aucun soucis constaté, et pourtant je suis plutôt consommateur d'imgur (je passe beaucoup trop de temps sur reddit ::) )

EDIT : Pour essayer de t'aider, je viens d'observer le trafic entrant sur mon dédié chez OVH, depuis ma connexion chez moi.

Merci pour les tests. Après réflexion, ça ne m'étonnerait pas que :
  • Le problème puisse être localisé au niveau de la 5330b (différence de chipset / firmware)
  • OVH mette le DSCP à 0 à l'entrée de son réseau (je n'ai pas de dédié pour tester).

Marin, avez-vous la possibilité de faire une capture derrière Telia ?

Je vous colle ce qui a été dit en détail à ce sujet par le support Fastly :

Par mail :
One of my colleagues was able to capture a few tcpdumps on our FRA caches from the curls you were running; from these we were able to confirm our initial suspicions. The SYN would come in without a negotiated DSCP field; however, on the SYN/ACK, we noticed that the value had changed (0x00 versus 0x08 in one example we found). This resulted in it hashing to a different cache and the 3 way handshake failing.

Via IRC :
to be clear, the issue is caused by the fact that something in the path is setting the DSCP bits for your SYN different from the rest of the conversation
your SYNs have DSCP value 0 set while everything else we receive has the value 8
[...]
while responding to your ticket earlier today, i ran some tests to get a concept of how widespread your issue is
time sudo tcpdump -nnvvi any -c 100 'src net 176.128.0.0/12 and (ip[1] != 0x00) and (tcp[tcpflags] == 0x02)'
time sudo tcpdump -nnvvi any -c 100 'src net 176.128.0.0/12 and (ip[1] == 0x00) and (tcp[tcpflags] == 0x02)'
the first one will capture syn packets from your network with DSCP bits set and the second will capture syn packets without DSCP (value 0 specifically)
i captured 100 packets in 9 seconds for the first test
but it took 2 minutes and 30 seconds to find 100 packets for the second
(your syns had 0, the second condition)
so you're in the 6th percentile or so
[...]
8 is the value of the old-style ToS field, the value in DSCP terms is 2


La décorrélation des résultats ci-dessus entre abonnés fixes et mobiles n'est pas certaine, vu la création de plages DSL et câble en ex-plages mobiles ces dernières années, et le fait qu'il semble parfois y avoir des abonnés DSL sans reverse DNS ou traceroute qui aille jusqu'au DSLAM (ce n'est pas mon cas).
J'ai interrogé mon interlocuteur à ce sujet :
most of them are missing reverse dns entries, but four of the ones i just captuered do have dns, and they are all DSL
(syn dscp 0)
although, i see "dsl" in the reverse dns for the hosts that have non-zero dscp as well
could be broken rdns

s3phy

  • Abonné FreeMobile
  • *
  • Messages: 375
  • St Laurent des Hommes (24)
Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia
« Réponse #7 le: 20 mars 2016 à 12:52:16 »
La décorrélation des résultats ci-dessus entre abonnés fixes et mobiles n'est pas certaine, vu la création de plages DSL et câble en ex-plages mobiles ces dernières années, et le fait qu'il semble parfois y avoir des abonnés DSL sans reverse DNS ou traceroute qui aille jusqu'au DSLAM (ce n'est pas mon cas).
Bien que 176.128.0.0/10 soit attribué à Bouygues Mobile AS12844, je n'ai jamais vu de client mobile dessus. À chaque fois que j'ai vu passer des adresses IP dans cette plage, c'était des connexions fixes. J'ai aussi 2 Bbox Nomad (hotspot 3G/4G), je sors systématiquement sur une adresse IP dans 80.215.0.0/16, jamais sur une adresse de 176.128.0.0/10. Bon ces informations pèsent peu : ce n'est basé que sur ce que j'ai moi-même observé ! Mais de mon point de vue : 176.128.0.0/10 est (majoritairement/exclusivement ?) utilisé pour des connexions fixes.

(Aussi je te vois parler de 176.128.0.0/12 : l'adresse de ma connexion ADSL n'est pas dedans ! Je suis dans le /12 suivant… d'ailleurs d'où sors ce /12 ? La plage attribuée à Bouygues est /10)

Concernant le reverse DNS, sur ma connexion ADSL, je n'en avais pas pendant les premiers mois, donc je ne serais pas surpris de savoir que d'autres clients Bbox fixe n'en ont pas.

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 804
  • 73
Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia
« Réponse #8 le: 26 mars 2016 à 21:59:25 »
Un autre service populaire actuellement qui est impacté par la problème, c'est Periscope.

Environ 6 % du trafic, ça fait quand même dans les 150 000 clients sur le fixe impactés potentiellement avec ce qu'a BT sur le fixe (en admettant qu'il n'y ait pas de biais liés aux circonstances concernées, bon il y en a certainement) ?

Bah si ça concerne le réseau IP de Bouygues Télécom (de près ou de loin, dsl j'ai lu rapidement) essaye de voir avec Boris de Bouygues Télécom sur le forum.

Je l'ai fait avant de créer ce sujet (en incluant au passage ma conversation avec le support CDN et divers éléments de diagnostic), je n'ai pas obtenu de réponse mais je conçois tout à fait qu'il puisse ne pas toujours avoir envie de faire du support client.

Je remarque que Bouygues ne semble pas avoir d'adresse noc@opérateur contrairement à d'autres mais juste abuse_box@ et peering@. J'imagine que cette dernière n'est pas disposée à traiter le problème en sachant que celui-ci concerne sûrement l'ingénierie des box (et/ou le réseau de collecte) ?

Les choix sur l'assistance mail sont aussi très limités, on ne peut la contacter que dans un nombre restreint de cas de figure, autrement il faut passer par la hotline téléphonique. Le problème c'est que les rapports traceroute passent mal sur le support voix.

jesus2099

  • Abonné SFR THD (câble)
  • *
  • Messages: 4
Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia
« Réponse #9 le: 30 janvier 2020 à 07:36:49 »
Bonjour Marin.
Je n'ai pas de box Bouygues.
J'ai un abonnement mobile Bouygues B&YOU.
Les sites suivants sont régulièrement aléatoirement introuvables (1 ou 2 fois par jour) :

- github.com
- duckduckgo.com
- ogone.fr (paiements carte bleue, utilisé notamment par la Fnac.fr)

Il y a sûrement d'autres cas mais pas dans les sites que je visite régulièrement.

Il me suffit de trouver un accès Wi-Fi quelconque pour que ça fonctionne, donc Le problème est vraiment chez Bouygues.
Je crois aussi qu'il y a un problème permanent avec certains serveurs Nintendo car impossible de partager ma data par Wi-Fi avec ma Nintendo Switch (elle accède très bien au réseau mais pas à ses serveurs).

griselidi

  • Abonné Free fibre
  • *
  • Messages: 934
  • le cannet 06
Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia
« Réponse #10 le: 30 janvier 2020 à 12:33:38 »
les problemes sur switch en 4g c'est pareil pour chaque operateur

jesus2099

  • Abonné SFR THD (câble)
  • *
  • Messages: 4
Problème réseau Bouygues Telecom => Fastly (Imgur, Github...) via Telia
« Réponse #11 le: 30 janvier 2020 à 13:03:00 »
Ah oui merci pour la Switch, c'est hors sujet effectivement parce-que c'est permanent et en plus il me semble que ça marchait avec mon téléphone Windows (j'ai Android maintenant).
« Modifié: 31 janvier 2020 à 07:25:48 par jesus2099 »