L’hypothèse serait que le LAG à 8 liens qui fonctionnent dans le sens client => Internet et 7 liens dans le sens Internet => client. Un lien serait dans un état où les paquets sont tous supprimés dans le sens internet => client, mais où le signal est suffisant pour ne pas le faire tomber ou électronique de contrôle est défectueuse.

Sinon, j'ai confirmation par ma femme qui est sur iPhone, qu'elle est aussi impactée. Elle accusait l'iPhone et regrettait son Samsung (elle vient de migrer d'Android à iPhone à la demande de son employeur). Elle me dit que de nombreux sites n'arrivent pas à se charger.

Une fois le VPN monté, je n'ai plus de problème, mais je peut avoir des problèmes pour le monter :


Pour les ports sources testés hier soir, précisons que c'est toujours les mêmes ports si je vais sur le même serveur avec le même port source, même port destination, même IPv4 source et même IPv4 destination. Si je change un paramètre de l'équation, les ports HS ne sont plus les mêmes.

Par contre, contrairement à toi, j'accède à tous les sites et ne ressens jamais ce que tu décris (nombreux sites qui n'arrivent pas à charger).

K-L, je me demande si l’occurrence de perte de paquet sur certains ports serait faible dans ton cas que dans celles qui me sont remontées.

Plus j'avance, plus je vois que les cas avec des fortes pertes de paquets sont localisés sur la TDR de Vitry-sur-Seine, avec des dizaines de cas :


Un exemple : https://twitter.com/jcorioland/status/1380422584983031808

J'ai de bonnes nouvelles de mon contact SFR.

Symbol, tu es bien sur la bonne piste avec ce message :

Je vote pour un LAG entre deux routeurs dont un lien serait 💩 dans un sens (la distribution des paquets utilisant un hash sur au moins headers layers 3+4 ; quand le paquet tombe sur la mauvaise interface il part à la 🗑).

L'incident a été résolut il y deux heures et impactait bien la TDR de Vitry-sur-Seine (cf carte de couverture postée au dessus)


Pour le cas de K-L, SFR me dit que "c’est visiblement un autre problème. La ligne de l’abonné est visiblement très dégradée et il faudrait qu’il commence par contacter le service client afin de faire une analyse de sa ligne."

Si ton expérience utilisateur est ok, c'est le principal.

J'imagine que sur Rami, l'outil interne, elle devait être orange ou rouge.

Le SNR des canaux descendant est bon ?

Le plus important c'est le SNR (ration du signal sur le bruit). 40dB, c'est très bon

Voici les valeurs de référence pour le SNR (rapport signal/bruit) :

	Nominal	Toléré	Dégradé
SNR canaux descendants modulation QAM256	>= 31dB	entre 28 et 31 dB	< 28 dB
SNR canaux descendants modulation 64QAM	>= 24 dB	entre 23 et 24 dB	< 23 dB
SNR canaux montants modulation 16QAM	>= 21 dB	entre 19 et 21 dB	< 19 dB
SNR canaux montants modulation QPSK	>= 15 dB	entre 13 et 15 dB	< 13 dB

La puissance des 2 remontants est pas trop élevée ?

(Je n'ai pas les valeurs de référence, mais j'ai compris que 46 dBmV c'est trop élevé).

Un lien serait dans un état où les paquets sont tous supprimés dans le sens internet => client, mais où le signal est suffisant pour ne pas le faire tomber ou électronique de contrôle est défectueuse.

Les LAGs utilisent classiquement LACP pour vérifier la bidirectionnalité de chaque membre du LAG (et comme on n'a pas vu plusieurs IPs au même hop dans les traceroutes UDP, ce serait plutôt un LAG que plusieurs liens parallèles en ECMP). Donc:

• l'électronique n'est pas le sujet
• le niveau du signal n'est un sujet que dans la mesure où un lien perdrait beaucoup de paquets dans un sens mais pas assez pour que le LACP tombe

Le plus probable est naturellement un problème sur un des deux routeurs :le LACP – trafic de contrôle – passe très bien, mais les flux à forwarder sont droppés ou rate-limités pour des causes logicielles (bug dans le software aboutissant à une mauvaise programmation du hardware, notamment dans des «race conditions»).