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.

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.

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 kernelLe TOS reste bien à 0 tout le long dans mon cas !

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

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.

les problemes sur switch en 4g c'est pareil pour chaque operateur