La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
ADSL / VDSL => Discussion démarrée par: P4rkeR le 14 octobre 2015 à 21:14:38
-
Bonjour,
Depuis début septembre, je remarque de soudaines pertes de paquets sur ma ligne ASDL.
J'ai alors fait quelques diagnostiques et me suis apercus que ces pertes de paquets provienne d'un routeur Free :
bzn-crs16-2-be1009.intf.routers.proxad.net qui a pour ip pour l'instant :
http://whatismyipaddress.com/ip/194.149.161.9
La plateforme téléphonique parisienne des techniciens m'a confirmé que mon diagnotisque était bon, c'est à dire que ce relais subit environ 1.5% de perte de paquets.
Pour autant, ils m'ont confirmé que les pertes n'étaient pas assez importantes pour que l'envie leur prennent de résoudre le problème et qu'ils n'avaient pas assez recus de plaintes a propos de ce relais....
Ce relais est sur le traceroute de quasiment toutes les IPs que l'ont veut ''pinger''.
Free ne me laisse plus le choix de rendre ce problème public.
N'hesitez pas a appeller le 3244 pour leur dire que vous aussi vous avez remarqué ce problème, et qu'il impacte réellement vos services de type Teamspeak, Skype, Jeux en ligne, Poker en ligne etc etc...
Merci a vous !
EDIT :
Je viens de refaire un MTR a l'instant sur une petite minute.
Meme probleme sur un autre relais, plus de 2% de perte de paquets :
bzn-crs16-2-be1005.routers.proxad.net
http://whatismyipaddress.com/ip/78.254.249.77
-
C'est étonnant car généralement les pertes, c'est au moment du pic de consommation, si un lien sature et pas 24h/24.
Je t'ai crée un graphe SmokePing de ta ligne : https://lafibre.info/dns/smokeping.cgi?target=Free.ADSL
Cela va permettre de mieux comprendre le pb.
-
Je viens de refaire un MTR a l'instant sur une petite minute.
Meme probleme sur un autre relais, plus de 2% de perte de paquets :
bzn-crs16-2-be1005.routers.proxad.net
http://whatismyipaddress.com/ip/78.254.249.77
-
Voici le MTR depuis la serveur lafibre.info, qui montre une absence de perte sur le backbone et un peu de perte sur le lien ADSL (probablement des CRC)
(https://lafibre.info/images/free_debit/201510_mtr_p4rker.png)
-
Nous ne passons pas vraiment par les même relais ::)
Et comme je l'ai dis précédemment même Free reconnait ces pertes de paquets....
-
Les interface ne sont pas les mêmes dans un sens et dans un autre (dans un routeur tu as une entrée et un sortie et dans un sens c'est l'ip de sorte qui t'est renvoyé et dans l’autre cas l'IP d'entrée)
Attention, un routeur qui ne répond pas a tous les paquets ICMP, ce n'est pas grave, c'est une protection contre un DDOS su routeur car les paquets ICMP remontent au CPU.
Ce qu'il faut c'est que le routeur route des paquets sans les perdre : si derrière un routeur qui perd des paquets tu as 0,0% de perte, il a fait son travail.
N’hésites pas a poster un mtr complet (vers lafibre.info par exemple) pour que je puisse analyser les pertes.
-
Je laisse tourner MTR encore une petite heure, je te poste le screenshot dans la foulee.
-
Vu le niveau de précision de MTR dans les pertes avec un seul chiffre après la virgule pour le pourcentage de perte, ce n'est pas la peine de faire plus de 2000 ping.
J'ai laissé tourner mon MTR et le 0,1% est devenu ,0% de perte à 2000 ping, ce qui signifie qu'un seul paquet sur 2500 à été perdu vers ton IP.
-
Sans vouloir paraitre parano, je trouve les pertes plutôt faibles depuis mon post bizarrement.....
-
Allez, je vous fait un petit compte rendu de la nuit de mon MTR.
Cette nuit a été plutôt clèmente sur les pertes de paquets, mais quand même 0,2% de perte de paquet sur chaque routeur proxad ( Free ) sur plus de 33000 paquets alors que l'on était en pleine nuit :
Je vous laisse imaginer en heure de pointe. 8)
(http://s15.postimg.org/aqwsvdcyj/Capture_d_e_cran_2015_10_15_a_07_30_48.png)
-
Et combien de pertes à la fin sur le dernier saut ?
Car petit rappel, comme disait vivien : qu'un routeur n'ait pas envie de répondre aux requêtes ICMP ne l'empêche pas de faire correctement son travail.
-
3.1%.
Le MTR de cette nuit a été fait en direction de google.fr.
J'ai relancé un MTR vers coinhouse.io qui passe par les même routeurs, on va voir ce que cela donne.
-
Donc 0.1/0.2% de pertes sur les routeurs du backbone pour 3.1% au final, le problème n'est surement pas sur les-dits routeurs !
-
Nico :
La plateforme téléphonique parisienne des techniciens m'a confirmé que mon diagnostique était bon, c'est à dire que ce relais subit environ 1.5% de perte de paquets.
Pour autant, ils m'ont confirmé que les pertes n'étaient pas assez importantes pour que l'envie leur prennent de résoudre le problème et qu'ils n'avaient pas assez reçus de plaintes a propos de ce relais....
Ce relais est sur le traceroute de quasiment toutes les IPs que l'ont veut ''pinger''.
A savoir que quand le conseiller a fait ces tests, il était 14h45 en pleine semaine.
Je n'ai pas envie de casser du sucre gratuitement sur le dos de Free.
-
Tu me pardonneras d'avoir un peu "passé" l'épisode du SAV téléphonique, on a tellement entendu tout et son contraire (je ne vise pas forcement que Free ici)...
-
Je ne sais pas si je te pardonne, je pense que je vais signaler ton post au modérateur ;)
-
Il faudrait publier un MTR complet avec la destination finale. Je préfère autre chose que Google, vu que Free a des pb de saturation le soir vers Google (source (https://lafibre.info/peering-google/debits-youtube-cest-de-pire-en-pire/msg260102/#msg260102)).
Par exemple lafibre.info qui utilise IELO, qui a du paid peering avec Free.
Ne t’inquiète pas ton IP n’apparaît pas, c'est dans l'autre sens qu'elle apparaît et tu as vu je l'ai caché)
-
Je te posterai un MTR complet mais pas vers lafibre.info car comme par hasard le traceroute m'indique que les paquets ne transitent pas par les routeurs qui posent problème.
En tout cas, merci pour votre implication !
-
Dans ce cas là publie deux mtr : un vers une destination a problème et l'autre vers lafibre.info
Si tu as autre chose que google en destination problématique, cela serait bien.
-
Je te prépare ca !
C'est la première fois de ma vie que je croise les doigts pour qu'il y ait des pertes de paquets ::)
-
P4rkeR m'a transmis un MTR qui est parfait.
On a des pertes de paquets sur le premier saut (192.168.0.254) a hauteur de 0,9%
On a des pertes de paquets sur le second saut a hauteur de 51,3%
Aucune perte de paquet sur le reste du traceroute.
C'est donc parfait. Les routeurs ont routés 100% des paquets sans rien perdre. Par contre, certains n'ont pas répondu a tous les ping qui leur sont adressés, c'est une fonctionnement normal comme je l'ai expliqué vu qu'un paquet routé en hardware ne remonte pas au CPU mais un ping ICMP oui.
-
D'accord merci de m'avoir rassurer a ce niveau la Vivien !
Je n’hésiterai plus a poster mes MTR complets dorénavant ;)
Mais cela n'explique toujours pas les pertes de paquets sur les routeurs proxad.
-
Mais cela n'explique toujours pas les pertes de paquets sur les routeurs proxad.
Je m'excuse, je n'ai lu qu'en diagonale le thread, mais ça serait pas simplement du ICMP rate limiting ? Comme l'a suggéré Nico plus haut
https://www.linode.com/docs/networking/diagnostics/diagnosing-network-issues-with-mtr#icmp-rate-limiting
Ça donne des trucs comme ça dans un mtr :
(regarder les hops 6 et 7)
EDIT : bon ça m'apprendra à lire en diagonale, Vivien en parlait déjà page précédente ::)
-
Mais cela n'explique toujours pas les pertes de paquets sur les routeurs proxad.
Si, ça les expliquent parfaitement. Les routeurs n'ont pas à s'embêter à répondre à tous les paquets ICMP car ce n'est pas leur travail. Le problème que tu as soulevé n'en est donc pas un et poster une traceroute partielle n'a aucun sens pour diagnostiquer un problème.
-
Quand le SC PARISIEN dit qu'il a des pertes de paquets de l'ordre de 1.5% sur son routeur et que je le constate aussi, c'est qu'il y a bien un problème quelque part non ???
Si vous pensez réellement qu'un routeur n'est pas la pas relayer des requêtes ICMP alors quel est l’intérêt de votre SmokePing dans ce cas la ?
EDIT :
(https://lafibre.info/smokeping/Free/ADSL/p4rker_last_172800.png)
-
Quand le SC PARISIEN dit qu'il a des pertes de paquets de l'ordre de 1.5% sur son routeur et que je le constate aussi, c'est qu'il y a bien un problème quelque part non ???
Qu'est-ce qui te fait dire que tu le constates réellement ? Pour l'instant la conclusion c'était plutôt que le routeur a un comportement à priori tout à fait normal, à savoir router les paquets plutôt que répondre à des pings qui ne sont en rien critiques.
Je doute que le service client "classique" sache réellement de quoi il retourne et en pratique leur réponse n'était pas totalement fausse, il n'y a effectivement rien de particulier à faire à propos de ce routeur.
Si vous pensez réellement qu'un routeur n'est pas la pas relayer des requêtes ICMP alors quel est l’intérêt de votre SmokePing dans ce cas la ?
Tu peux quand même voir s'il y a des paquets qui ne sont pas arrivés à destination, ce qui est différent d'avoir un "accusé de réception" de chaque routeur sur le chemin (pour le dire vite).
-
et que je le constate aussi,
Sauf que pour l'instant, tu n'as montré aucune trace complète qui indique la présence d'un quelconque problème technique. Montre-en une, et elle sera très bien prise en compte.
Pour l'instant, tout ce qui a été vu, ce sont des pertes au niveau d'un routeur, mais pas ou moins au niveau du routeur suivant => cela veut juste dire que le routeur limite volontairement l'envoi de messages ICMP « TTL expiré », mais qu'il routerait techniquement bien les paquets de données (et pour preuve, ces pertes affichées ne se répercutent pas plus loin).
Ce ne constitue donc techniquement pas l'indicateur d'un problème technique. Juste d'une configuration normale et répandue.
Quand le SC PARISIEN dit
Les agents SAV de tous les gros FAI (y compris Free) sont largement sous-formés pour la plupart, et c'est juste du savoir commun de dire ça. Faire de « le SAV me l'a dit » un argument d'autorité est un contre-sens particulièrement fort lorsqu'en plus les éléments techniques tendent (jusqu'à là) vers le contraire.
-
Alors comment on diagnostique les pertes de paquets ? Et a quel niveau elles se trouvent ?
Et on ne m'a toujours pas répondu a propos de l’utilité du SmokePing qui utilise des requete ICMP a propos....
-
Si un routeur perd 1.5% des paquets alors tous les routeurs d'après lui ont au minimum les mêmes pertes..
Or la le mrt dit juste que le routeur n'a pas répondu à 1.5 % des requêtes ping. Si les routeurs et surtout le client final répond à 100% c'est qu'il n'y a eu aucune perte.
-
Si vous pensez réellement qu'un routeur n'est pas la pas relayer des requêtes ICMP alors quel est l’intérêt de votre SmokePing dans ce cas la ?
C'est ta box qui répond là, non ? Elle a surement plus que ça à faire que les Cisco CRS de Free ;).
Un SmokePing reste une aide au diagnostique (qui montre ici que "tout marche bien" on dirait).
-
Alors comment on diagnostique les pertes de paquets ? Et a quel niveau elles se trouvent ?
Si il y a vraiment des pertes de paquet, ça se voit sur toute la chaîne qui suit dans le traceroute. C'est en soit relativement logique non ? Genre le paquet est perdu au niveau du CRS mais réapparaît par magie plus loin ?
-
alors que lui même le reconnait.
On a déjà vu le service client Free répondre à côté de la plaque, donc on se méfie (exemple récent https://lafibre.info/free-la-fibre/ftth-excluvisite-orange/ )
Avoir un ping qui passe de 300ms a 9ms entre deux paquets sur la meme route est tout a fait normal.
Si on parle des réponses au ping d'un routeur sur ton parcours, oui, ça peut être tout à fait normal à cause du ICMP rate limit !
Si vous pensez réellement qu'un routeur n'est pas la pas relayer des requêtes ICMP
Il est bien là pour RELAYER (et pas que l'ICMP mais tout ce qui peut s'encapsuler dans un paquet IP !) mais pas pour RÉPONDRE à de l'ICMP ;)
alors quel est l’intérêt de votre SmokePing dans ce cas la ?
Avoir un support graphique facilement lisible du ping et du packetloss dans le temps.
Un exemple de routeur causant du packetloss ça donnerait ça dans un mtr :
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2(exemple pris sur https://www.linode.com/docs/networking/diagnostics/diagnosing-network-issues-with-mtr )
Là on voit bien que après le 3ème hop, tous les autres ont du packet loss. On peut supposer qu'il y a donc bien un problème avec ce routeur... Mais c'est même pas sûr : la route inverse peut être totalement différente et le problème pourrait être de ce côté là ;)
(et je me fais griller par tout le monde le temps de répondre ::) )
-
Alors comment on diagnostique les pertes de paquets ? Et a quel niveau elles se trouvent ?
Les résultats d'un mtr complet (comme celui que tu as transmis à vivien) en heure de pointe, alors que les pertes se produisent (et si elles se produisent réellement, elles doivent se produire également au niveau du dernier saut, celui de ta box).
Et on ne m'a toujours pas répondu a propos de l’utilité du SmokePing qui utilise des requete ICMP a propos....
Le smokeping en question est effectué sur ta Freebox, pas sur un routeur du réseau national. Les Freebox ne limitent pas l'envoi de paquets ICMP de type « TTL expiré », ni de type « réponse au ping » (qui sont par ailleurs deux choses différentes). Pour les autres smokeping, cela dépend également du routeur concerné.
-
[Provocations gratuites retirées]
Je suis obliger d’utiliser un VPN pour jouer sans avoir des rollbacks et des montée de ping.
Je paye un VPN 10$ / mois en plus de mes 37€ / mois pour jouer tranquilou.
-
C'est pour ça que je suis obliger d’utiliser un VPN pour jouer sans avoir des rollbacks et des montée de ping.
Si tu as ça, c'est plus probablement dû à une saturation de l'interconnexion avec le fournisseur des serveurs de jeux en question, dans quel cas c'est vers ceux-ci qu'il faut effectuer des tests (et montrer le résultat complet). Ensuite, le diagnostic pourra aller plus loin.
-
C'est pour ça que je suis obliger d’utiliser un VPN pour jouer sans avoir des rollbacks et des montée de ping.
Ça me ferait plus penser à un soucis de peering côté Free ces symptômes là. Free est un coupable notoire dans la catégorie peering saturé ::)
D'ailleurs si c'était réellement du packet loss causé par les routeurs, ton VPN serait certainement aussi impacté !
-
En fait on n'a pas dit qu'il n'y avait pas de problème. Juste que ce que tu nous présentes n'est pas un indicateur de la présence de problèmes.
-
En fait on n'a pas dit qu'il n'y avait pas de problème. Juste que ce que tu nous présentes n'est pas un indicateur de la présence de problèmes.
Ba aider moi a le faire....
-
On essaie, tu dis avoir des pertes de paquets du coup vivien "surveille" ton accès avec un smokeping qui ne révèle pour l'instant rien.
Si tu as des soucis en jeu, essaie de noter l'IP du serveur et de lancer un mtr dessus.
Après c'est peut-être pas des pertes de paquet, ça pourrait être une latence qui varie beaucoup (gigue) à cause d'une interco saturée.
-
Ba aider moi a le faire....
Tu fais un mtr vers l'adresse IP du serveur du jeu en période où le problème se produit, et tu postes la sortie en entier.
Si tu ne connais pas l'adresse IP du serveur du jeu, tu peux la voir avec Wireshark : https://lafibre.info/tutoriels/realiser-une-capture-wireshark-pas-a-pas/
-
Fait un mrt le soir vers ton serveur de jeux qui "rament".
On verra surement soit le ping monté en flèche soit des paquets perdus sur tous le trajet.
Cf l'exemple avec google montré plus haut.
-
Si le problème se trouvait sur un routeur free proche de chez toi le VPN ne changerait rien puisque tu passerais probablement par le même routeur avec ton vpn..
Si ca marche avec un vpn et pas la connexion directe c'est un problème de peering généralement.
-
Merci a vous tous pour cette masse de réponse.
WireShark a l'air d’être un outils très intéressant.
Je reviendrai vers vous, lorsque j'aurai des diagnostiques fiables.
-
Dans ton cas et au vu des éléments transmis , il me semble qu'il n'y a pas de problème de perte de paquet sur le réseau Free.
Par contre si tu parle des liens vers l'Internet (Transit, Peering), il est connu que de nombreux liens saturent (Free, Netflix, les transitaires qui permet de joindre les destination à l'international) mais c'est bien différent.
C'est connu et même assumé par Xavier Niel :
Xavier Niel à interviewé hier soir par le nouvel observateur. A la question sur les ralentissement sur Youtube, Xavier Niel conseil d'aller sur Dailymotion : "j'invite les gens qui ont des problèmes avec YouTube de s'apercevoir que sur Dailymotion souvent il y a les mêmes vidéos."
(https://lafibre.info/images/free/201201_xavier_niel.jpg)
Le nouvel observateur : En dehors du mobile, les abonnés Free sont victimes de ralentissements récurrents lors de leur connexion à YouTube. Qu'en est-il ?
Xavier Niel : Effectivement, il y a un problème. Les tuyaux entre Google et nous sont pleins à certaines heures, et chacun se repoussent la responsabilité de rajouter des tuyaux. C'est un problème classique qui arrive partout, mais plus souvent avec Google. En comparaison, le trafic avec Dailymotion -avec qui tout se passe bien- ne pose pas de problème. Donc j'invite les gens qui ont des problèmes avec YouTube de s'apercevoir que sur Dailymotion souvent il y a les mêmes vidéos. J'espère que la solution arrivera sous peu.
-
Et que se passe-t-il quand ces routes saturent ? ::)
-
Des pertes de paquets, montées de ping ou baisses de débit à l'interconnexion entre le réseau Free et le réseau tiers. Le routeur que tu as montré et qui fonctionnait probablement très bien était un routeur situé à l'intérieur du réseau Free.
-
à préciser, des pertes de paquets à partir d'un routeur jusqu'à la destination finale ...
enfin on parlera lorsqu'il y aura un MTR complet.
-
Bon rien a voir avec le sujet principal mais je suis repasser en mode fastpath car j'ai compris que le probleme ne venait pas de la et j'ai des meilleurs resultats au niveau du debit :
En mode normal :
(https://www.speedtest.net/result/4745964563.png)
En mode fastpath :
(https://www.speedtest.net/result/4750336390.png)
(https://lafibre.info/smokeping/Free/ADSL/p4rker_last_172800.png)
Le probleme de Free et du jeux en ligne est en fait la route qu'il nous fait emprunter.
J'ai pour ca un logiciel WTFast qui permet d'emprunter une autre route de me faire gagner 50ms. Il me permet aussi de faire des reports complets sur mes sessions de jeux.
Je les ai mis les fichiers en piece jointe.
On peut remarquer qui n'y a plus une seule perte de paquet sur bzn-crs16-2-be1009.intf.routers.proxad.net par exemple !! Ce qui est une super nouvelle, car avant ce logiciel m'indiquer des pertes de paquets sur ce routeur la. Je ne sais pas si ce sont ces fameux paquets ICMP...
Dommage de devoir utiliser un logiciel payant pour pouvoir emprunter une route qui a un temps de réponse largement inferieur.
-
J'ai pour ca un logiciel WTFast qui permet d'emprunter une autre route
C'est très exactement un VPN, bundlé avec 3 outils de diagnostic bling-bling et une sorte de bullshit-marketing décérébré, ou je n'y comprends rien ?
Un logiciel pour « emprunter une autre route » vers une même cible c'est tout simplement impossible, sauf à envoyer un superespion à ultra-haut débit dans les datacenters des différents FAI pour installer une backdoor sur les routeurs de bordure qui ferait emprunter une interconnexion spéciale aux adresses IP privilégiées.
-
Je t'assure que ce logiciel me fait emprunter une autre route....
Sinon comment expliquer ces résultats ?
Sans le logiciel sur le serveur de jeux je ping a 75ms environ, et avec le logiciel d'activer sur le même serveur je suis a 25ms.
Et autre question, pourquoi ai-je un meilleur débit en mode normal qu'en mode fastpath ?
C'est très exactement un VPN, bundlé avec 3 outils de diagnostic bling-bling et une sorte de bullshit-marketing décérébré, ou je n'y comprends rien ?
A chaque fois que je poste quelque chose, j'ai l'impression de tout faire de travers, et d'utiliser des outils de merde.
Depuis quand un traceroute et un graph de transmission de donnée est bling bling ? Les resultats sont la, il n'y a rien de ''décérébré'' la dedans.
Et si c'etait un VPN il ne me ferait pas passer par bzn-crs16-2-be1009.intf.routers.proxad.net ( Enfin je crois en être quasiment sur ) car lors de mes traceroute avec un VPN Mullvad ou FlyVPN par exemple, les routeurs proxad n'y sont plus figure.
-
Sinon comment expliquer ces résultats ?
Sans le logiciel sur le serveur de jeux je ping a 75ms environ, et avec le logiciel d'activer sur le même serveur je suis a 25ms.
Sans le VPN, tu as : latence due à l'ADSL + latence due au transport entre le DSLAM et le point d'interconnexion Free + latence due à la saturation entre Free et le transitaire permettant de joindre le jeu (important) + latence due au transport entre le point d'interconnexion et l'hébergeur du jeu.
Avec le VPN, tu as : latence due à l'ADSL + latence due au transport entre le DSLAM et le point d'interconnexion Free + latence due au transport entre le point d'interconnexion et le fournisseur VPN + latence due au transport entre le fournisseur VPN et l'hébergeur du jeu.
C'est la partie en gras qui peut rendre le ping supérieur dans la configuration sans VPN.
Et autre question, pourquoi ai-je un meilleur débit en mode normal qu'en mode fastpath ?
Le mode "fastpath" est, par définition, un profil qui privilégie la latence sur le débit. Plusieurs paramètres peuvent rentrer en compte dans la définition d'un profil *DSL : ici, une marge de bruit faible, la correction d'erreurs réduite.
Depuis quand un traceroute et un graph de transmission de donnée est bling bling ? Les resultats sont la, il n'y a rien de ''décérébré'' la dedans.
Sujets : l'interface et surtout le marketing (https://www.wtfast.com/) autour.
Et si c'etait un VPN il ne me ferait pas passer par bzn-crs16-2-be1009.intf.routers.proxad.net ( je crois )
C'est le chemin entre toi et le VPN qui est affiché, pas entre le VPN et le serveur de jeu.
-
Sur le principe Marin n'a pas tort, c'est juste un VPN enrobé de truc pour faire joli qui permet surement de te le vendre plus cher que le dernier que j'ai vu à $25 à vie.
-
Et moi quand est ce que j'ai raison sur le fond ? ???
C'est a dire qu'il n'est pas normal de devoir payer un VPN ''bling bling'' ou pas, pour avoir un temps de latence plus faible ......
-
Change de FAI. Passe chez Bouygues Telecom, tu feras des économies et tu bénéficiera probablement d'un meilleur peering.
-
cette societe 'possede plus de serveur qui font office de relais que free
Elle possède une meilleure interconnexion tu veux dire, en langage technique ? C'est effectivement un des intérêts premiers d'un VPN.
Et moi quand est ce que j'ai raison sur le fond ? ???
C'est a dire qu'il n'est pas normal de devoir payer un VPN ''bling bling'' ou pas, pour avoir un temps de latence plus faible ......
Personne n'a contesté ça. Mis à part Free, qui dégrade délibérèment le service de ses propres clients depuis des années dans le but de servir ses propres intérêts commerciaux, comme expliqué dans le message cité plus haut (https://lafibre.info/free-adsl/perte-de-paquet-sur-un-routeur-free/msg266606/#msg266606) par vivien (la situation a été généralisée et a tourné en status quo depuis).
-
Et moi quand est ce que j'ai raison sur le fond ? ???
C'est a dire qu'il n'est pas normal de devoir payer un VPN ''bling bling'' ou pas, pour avoir un temps de latence plus faible ......
Personne n'a dit que c'était normal mais pour l'instant tu n'as pas encore montré de traceroute sans VPN qui permettrait de mieux voir où se situe le problème exactement.
-
Change de FAI. Passe chez Bouygues Telecom, tu feras des économies et tu bénéficiera probablement d'un meilleur peering.
Un amis qui est chez Bouygues et qui habite sur Nantes a encore de plus gros probleme de latence sur les même serveurs de jeux ou teamspeak lorsque chez moi tout va bien au même moment.
Donc cela ne vient pas du serveur de jeux, mais de la route qui est emprunte pour y arriver.
Personne n'a dit que c'était normal mais pour l'instant tu n'as pas encore montré de traceroute sans VPN qui permettrait de mieux voir où se situe le problème exactement.
Le probleme est que quand je fais un traceroute on me dit que ce sont des paquets ICMP, et qu'il est donc normal qu'il ne soit pas relayer par le routeur proxad.
Je commence a en avoir un peu marre que ''tout le monde'' ici soit dans le rejet de la réalité.
-
Demande sur les forum pour les serveurs de jeu que tu utilises. ;)
Tu te feras une meilleure idée.
-
Elle possède une meilleure interconnexion tu veux dire, en langage technique ? C'est effectivement un des intérêts premiers d'un VPN.
Ce n'est pas un VPN classique car il te trouve le serveur relai qui te donne le meilleur temps de reponse sur le serveur de Jeux.
Mullvad, FlyVPN, HMA etc... n'ont qu'un seul objectif et de cacher qui tu es sur ta destination pas d'avoir un meilleur temps de reponse.
Pour preuve voila les logs que ce logiciel te sort :
[18:27:33] csgo.exe (14760) - *.*.*.135:27031 UDP matching AutoSelect rule : using GPN fr9:3724
[18:27:33] csgo.exe (14760) - *.*.*.135:27031 UDP open through GPN fr9:3724
[19:03:02] csgo.exe (14760) - *.*.*.40:27005 UDP matching Local Connections rule : direct connection
[19:03:11] csgo.exe (14760) - *.*.*.22:27062 UDP matching AutoSelect rule : using uk11>uk6 GPN chain
[19:03:11] csgo.exe (14760) - *.*.*.22:27062 UDP open through uk11>uk6 GPN chain
[19:03:14] csgo.exe (14760) - *.*.*.182:27051 UDP matching AutoSelect rule : using uk11>uk6 GPN chain
[19:03:17] csgo.exe (14760) - *.*.*.164:27018 UDP matching AutoSelect rule : using uk11>uk6 GPN chain
[19:03:17] csgo.exe (14760) - *.*.*.182:27051 UDP open through uk11>uk6 GPN chain
[19:03:17] csgo.exe (14760) - *.*.*.182:27051 UDP close, 25 bytes sent, 137 bytes received, lifetime <1 sec
[19:03:18] csgo.exe (14760) - *.*.*.164:27018 UDP open through uk11>uk6 GPN chain
[19:03:18] csgo.exe (14760) - *.*.*.182:27039 UDP matching AutoSelect rule : using GPN fr9:3724
[19:03:18] csgo.exe (14760) - *.*.*.182:27039 UDP open through GPN fr9:3724
[19:03:28] csgo.exe (14760) - *.*.*.181:27071 UDP matching AutoSelect rule : using uk11>uk6 GPN chain
[19:03:28] csgo.exe (14760) - *.*.*.181:27071 UDP open through uk11>uk6 GPN chain
[19:03:33] csgo.exe (14760) - *.*.*.182:27039 UDP matching AutoSelect rule : using GPN fr9:3724
[19:03:34] csgo.exe (14760) - *.*.*.182:27039 UDP matching AutoSelect rule : using GPN fr9:3724
[19:03:34] csgo.exe (14760) - *.*.*.182:27039 UDP open through GPN fr9:3724
[19:03:36] csgo.exe (14760) - *.*.*.182:27039 UDP open through GPN fr9:3724
[19:03:36] csgo.exe (14760) - *.*.*.182:27039 UDP close, 25 bytes sent, 131 bytes received, lifetime 00:02
[19:03:36] csgo.exe (14760) - *.*.*.182:27039 UDP close, 25 bytes sent, 131 bytes received, lifetime 00:02
[19:07:21] csgo.exe (14760) - *.*.*.135:27031 UDP close (timeout), 16544538 bytes (15.7 MB) sent, 42029533 bytes (40.0 MB) received, lifetime 39:48
[19:08:12] csgo.exe (14760) - *.*.*.22:27062 UDP close (timeout), 25 bytes sent, 137 bytes received, lifetime 05:01
[19:08:18] csgo.exe (14760) - *.*.*.164:27018 UDP close (timeout), 25 bytes sent, 137 bytes received, lifetime 05:00
[19:08:29] csgo.exe (14760) - *.*.*.181:27071 UDP close (timeout), 25 bytes sent, 137 bytes received, lifetime 05:01
[19:42:20] csgo.exe (14760) - *.*.*.182:27039 UDP close (process end), 17641235 bytes (16.8 MB) sent, 46221011 bytes (44.0 MB) received, lifetime 39:02
Il est sans cesse en train de tester ces relais/serveurs pour obtenir le meilleur temps de réponse sur le serveur de jeux et uniquement sur ton jeux. Mon IP ne change pas lorsque je me balade sur Internet par exemple alors que j'utilise ce logiciel. Ce n'est un VPN classique. Je t'invite donc a trouver ce service ailleurs...
-
Un amis qui est chez Bouygues et qui habite sur Nantes a encore de plus gros probleme de latence sur les même serveurs de jeux ou teamspeak lorsque chez moi tout va bien au même moment.
Donc cela ne vient pas du serveur de jeux, mais de la route qui est emprunte pour y arriver.
Tu devrais indiquer l IP du serveur il y a une personne qui s'occupe du réseau Bouygues sur le forum..
Le probleme est que quand je fais un traceroute on me dit que ce sont des paquets ICMP, et qu'il est donc normal qu'il ne soit pas relayer par le routeur proxad.
Je commence a en avoir un peu marre que ''tout le monde'' ici soit dans le rejet de la réalité.
Si ça te fait plaisir de penser que des pertes sur un routeur intermédiaire impacte le résultat final on te laisse le penser...
Pour un test simple fait un traceroute vers ovh.com
Tu verras que tu as 100% de pertes... mais pourtant le site marche bien.
-
Tu devrais indiquer l IP du serveur il y a une personne qui s'occupe du réseau Bouygues sur le forum..Si ça te fait plaisir de penser que des pertes sur un routeur intermédiaire impacte le résultat final on te laisse le penser...
J'arrive déjà pas a m'en sortir avec mon problème ici alors je vais laisser mon ami se débrouiller seul.
Et vu comment je me sens accuser d’être novice et en gros de me faire couiller par des société bling bling malhonnête, je ne vais pas lui recommander ce forum dans ces conditions.
Pour un test simple fait un traceroute vers ovh.com
Tu verras que tu as 100% de pertes... mais pourtant le site marche bien.
C'est bien ce que je dis plus haut, un traceroute n'a donc aucune valeur. Je l'ai bien compris et assimiler merci.
-
Tu lui indiques ce que tu veux.. mais le problème est que depuis le début il y a des morceaux de traceroutes / d'ip / des conclusions hâtives.
Si ton ami donne l'ip la personne en charge du reseau chez Bouygues saura dire oui on a un souci avec ce réseau ou non le problème est ailleurs...
-
Tu lui indiques ce que tu veux.. mais le problème est que depuis le début il y a des morceaux de traceroutes / d'ip / des conclusions hâtives.
Si ton ami donne l'ip la personne en charge du reseau chez Bouygues saura dire oui on a un souci avec ce réseau ou non le problème est ailleurs...
très bien, je lui conseillerai de le faire. Merci.
-
N'hésite pas à partager l'IP d'un ou des serveur(s) qui pose(nt) problème qu'on regarde depuis d'autres FAIs. Mais la réputation de Free le précède et il y a des chances que le soucis soit sur l'accès à Internet (légèrement moins aisé que l'accès à l'Intranet Free).
Après pour résoudre ça, à part râler au SC (mais bon, pour un serveur de jeu quand tu vois le nombre d'années avec des soucis sur YT...) et changer de FAIs, pas de solution miracle. Ou payer un VPN, et il y a surement aussi efficace et moins cher mais après c'est à toi de choisir.
-
N'hésite pas à partager l'IP d'un ou des serveur(s) qui pose(nt) problème qu'on regarde depuis d'autres FAIs.
Et éventuellement qu'on voit où ça a l'air de coincer pour Free (avec quel transitaire par exemple).
Plus tu arrives à préciser le problème, plus il y a de chance que tu aies une réponse précise de Free. Après la probabilité que tu aies une réponse reste très faible, si tu ne veux pas changer de FAI alors il ne te reste que le VPN (celui que tu utilises actuellement ou un autre).
-
Je suis dégoûté, je viens de passer un quart d'heure à rédiger une grosse réponse et j'ai réussi à la perdre à cause d'un misclick... >:(
Bref pour le coup flemme de tout retaper, je vais résumer rapidement. Marin, eruditus et buddy t'ont déjà répondu très justement pour beaucoup de points (même si tu n'aime pas parfois le ton de leurs réponses :) )
WTFast est bien une sorte de wrapper de VPN, qui ne tunnelise que le trafic des jeux.
Quand tu utilises un VPN ("complet" disons), tu ne vois plus les routeurs entre toi et le serveur de VPN dans des traceroute, mais ils sont bien présents. Une fois déconnecté d'un VPN, fais un traceroute vers l'adresse d'un de ces serveurs de VPN, tu vas voir tous les routeurs de Free (et de ses transitaires) que tu traverse. Comme ce que t'affiche WTFast.
Tu parlais de perte de paquets au début. Quand tu nous montre ton screenshot WTFast, je vois en bas à droite une liste qui ressemble à s'y méprendre à un mtr. C'est là que tu voyais les pertes de paquets ?
Est-ce que c'était UNIQUEMENT au niveau de la ligne concernant ce routeur ? Si c'est ça, c'est bien du ICMP rate limit au niveau de ce routeur, comme disait Vivien dès la première page. Strictement aucun impact sur la qualité de ton accès internet.
Ou au contraire est-ce que les pertes de paquets se voyaient aussi sur les lignes en dessous ? Si les pertes de paquet se répercutaient sur les lignes suivantes, LÀ c'était bien des pertes de paquet causées par ce routeur, comme ce que je t'expliquais page 4 : https://lafibre.info/free-adsl/perte-de-paquet-sur-un-routeur-free/msg266567/#msg266567
Le probleme est que quand je fais un traceroute on me dit que ce sont des paquets ICMP, et qu'il est donc normal qu'il ne soit pas relayer par le routeur proxad.
Comme je te répondais page 4, ils sont bien RELAYÉS par les routeurs, mais les routeurs eux-mêmes n'y RÉPONDENT pas systématiquement, et c'est un fonctionnement normal.
C'est bien ce que je dis plus haut, un traceroute n'a donc aucune valeur. Je l'ai bien compris et assimiler merci.
Mais non ! Cela permet de remarquer des pertes de paquet, et grâce à ça on est en train de se rendre compte que ce n'est pas le soucis que tu as :) Ça n'a pas aucune valeur !
Au final je vois qu'on en revient à un problème classique avec Free : la saturation avec ses transitaires/ses peerings. C'est connu chez Free depuis plus de 2 ans, Free a décidé de maintenir le statut quo à ce niveau là. Si ça impacte ton utilisation courante de ta connexion internet, la seule vraie solution c'est d'aller voir ailleurs ! Ou d'accepter de payer, en plus de ta connexion internet, un VPN (ou un abonnement WTFast c'est la même chose, voir mieux, pour ton utilisation !) pour palier aux défauts de Free.
-
WTFast n'est pas un VPN.
Il ne crypte pas la connexion, il permet juste d'emprunter une route différente.
Le protocole ICMP (Internet Control Message Protocol) est un protocole qui permet de gérer les informations relatives aux erreurs aux machines connectées. Etant donné le peu de contrôles que le protocole IP réalise, il permet non pas de corriger ces erreurs mais de faire part de ces erreurs aux protocoles des couches voisines. Ainsi, le protocole ICMP est utilisé par tous les routeurs, qui l'utilisent pour signaler une erreur (appelé Delivery Problem).
Voici un MTR vers google.fr.
-
Voici un MTR sur une minute vers la fibre.info.
Regarder les pings....
-
Tout est normal vers lafibre.info mais vers google.fr on voit bien l'habituelle saturation qui est connue depuis au moins 3 ans (elle a déjà été pire).
-
La majorité du ping pourri est entre ta box et ton PC...
Ping à 50 ms en moyenne...
Connecte toi via un câble ethernet
-
En effet, j'avais pas fait attention à ça. Par contre j'observe des pertes de paquets dans les mêmes proportions vers google.fr depuis ma connexion en ethernet donc il est peu probable que cette partie du problème soit liée au wifi.
-
Un MTR vers coinhouse.io --> 37.187.144.52 -> serveur OVH Fr
-
Rien de remarquable ici, les pertes sont faibles. Par contre je ne vois pas trop où tu veux en venir, à priori il ne s'agit pas vraiment d'une IP qui t'intéresse. Pourquoi tu ne fais pas de traceroute vers un serveur du jeu problématique ?
-
Puis tu as toujours des packets loss entre ton PC et ta box... donc difficle de conclure grand chose.
-
Rien de remarquable ici, les pertes sont faibles. Par contre je ne vois pas trop où tu veux en venir, à priori il ne s'agit pas vraiment d'une IP qui t'intéresse. Pourquoi tu ne fais pas de traceroute vers un serveur du jeu problématique ?
Que ce soit une IP qui m'intéresse ou pas, ce qu'il m'intéresse c'est de prouver qu'il continue à avoir des pertes sur bzn-crs16-2-be1009.intf.routers.proxad.net.
Grace a ce MTR vers une IP française OVH, on ne peut plus me répondre que c'est a cause de la route vers Google, Youtube ou encore vers mon serveur de jeux qui est saturée. ::)
Nous pouvons donc tous ensemble conclure que ce que le SC Parisien de Free et moi même avons constater ( revenir a mon tout premier post ) :
Il y a des pertes anormales de paquets sur ce routeur !
-
Que ce soit une IP qui m'intéresse ou pas, ce qu'il m'intéresse c'est de prouver qu'il continue à avoir des pertes sur bzn-crs16-2-be1009.intf.routers.proxad.net.
Grace a ce MTR vers une IP française OVH, on ne peut plus me répondre que c'est a cause de la route vers Google, Youtube ou encore vers mon serveur de jeux qui est saturée. ::)
Nous pouvons donc tous ensemble conclure que ce que le SC Parisien de Free et moi même avons constater ( revenir a mon tout premier post ) :
Il y a des pertes anormales de paquets sur ce routeur !
Les 0.8% de perte sur bzn-crs16-2-be1009.intf.routers.proxad.net ne veulent rien dire du tout dans le cas présent. Ce qui compte c'est qu'à la fin tu as seulement 0.1% de paquets perdus sur la destination finale. La valeur est moins élevée ce qui permet d'être sûr que les pertes ne sont pas causées par bzn-crs16-2-be1009.intf.routers.proxad.net. Si le routeur perdait vraiment les paquets alors les pertes sur la destination finale devrait être au moins égales à 0.8%. Les pertes vues par le traceroute s'explique juste par le fait que par moment le routeur en question décide de ne pas honorer les paquets ICMP.
Si tu regardes à nouveau le traceroute vers Google, tu vas voir que les pertes deviennent massives à l'interface entre le réseau de Free et de Google et restent à un niveau élevé jusqu'à la fin ce qui montre que les paquets sont réellement perdus. Ce traceroute là montre clairement une saturation du peering avec Google mais je peux t'assurer qu'il n'y a rien de bizarre avec bzn-crs16-2-be1009.intf.routers.proxad.net.
Est-ce que tu comprends ce que j'essaie de t'expliquer ? Je veux bien croire que ça ne soit pas évident donc je peux essayer d'être plus clair si besoin.
Au lieu de pointer du doigts mon 0.2% de perte de paquets ICMP en local
Pourquoi est-ce que tu te connectes pas en filaire ? Ça éviterait que le WiFi interfère.
-
Je viens de saisir ce que tu m'expliques !
Merci ! En gros, il n'y a que 0.1% de paquets réellement perdu ?
Et ces 0.1% peuvent venir de ma box si je comprend bien ?
Je faisait mes tests sur le mon MacBook Pro mais comme celui-ci ne possède pas de câble Ethernet...
Je vais faire dorénavant mes MTR sur de l'ethernet depuis mon poste fixe.
Je viens de deja de lancer un MTR qui a l'air tres bon vers coinhouse.io :
http://p4rker.free.fr/coinhouse-17-10-15-23-07.HTML
Mes MTRs seront desormais sortis en version HTML en plus c'est plus pratique pour moi !
Edit :
Effectivement un MTR vers chez google.fr est une autre histoire, on s'en rend compte en 60 secondes chrono :
http://p4rker.free.fr/google-fr-17-10-15-23-11.HTML
Et aucune perte sur le routeur que j'accuse !
-
Ouaip c'est bien ça sauf que 0.1% viennent plutôt du WiFi que de la box en elle-même.
Si tu trouves l'adresse ip du serveur de jeu tu pourras voir où les choses commencent à dérailler.
-
Sauf erreur il y a un truc bizarre avec la sortie donnée par WinMTR, les pourcentages n'ont pas l'air juste (comme s'ils avaient été arrondis à l'entier supérieur...).
-
Sauf erreur il y a un truc bizarre avec la sortie donnée par WinMTR, les pourcentages n'ont pas l'air juste (comme s'ils avaient été arrondis à l'entier supérieur...).
C'est vrai que le développeur aurait pu faire un petit effort a ce niveau la, mais bon l’outil fait le job quand même.
Niveau résultats sur bzn-crs16-2-be1009.intf.routers.proxad.net
100 × 57989 ÷ 58007 ≈ 99,968969262
100 - 99,968969262 = 0.03% de pertes.
58007 - 57898 = 18 pertes de paquets sur quasiment 60.000 paquets.
-
Voila un MTR vers un serveur CS:GO [146.66.159.95] qui merde si je n'utilise pas mon outils WTFast :
http://p4rker.free.fr/csgo1-18-33.HTML
-
La fin du traceroute me laisse perplexe je dois dire... Je comprends pas trop ce que 192.168.131.30 et 192.168.131.3 font là. Normalement 192.168.0.0/16 est un bloc d'adresses réservées aux réseaux privés.
Sinon le début du traceroute montre que tu passes par l'interconnexion entre Free et l'Amsterdam Internet Exchange avant d'entrer sur le réseau de Valve qui est aussi interconnecté à l'AMS-IX. Visiblement tout à l'air normal jusque là.
-
Sur ce nouveaux MTR, on note que la destination ne répond pas au ping (c'est son droit)
On note que l'on arrive sur les routeurs de valve sans perte de paquet et un ping correct, donc tout se passe bien.
Attention, les saturations les plus fortes liées au peering / transit sont le dimanche soir vers 22h00.
donc le fait que tout se passe bien en ce moment ne permet pas de dire que le peering est correctement dimensionné, vu q'on n'est pas au pic du trafic.
-
Donc cela veut dire que le Traceroute réalisé par WTFast que j'ai poste ici (https://lafibre.info/free-adsl/perte-de-paquet-sur-un-routeur-free/msg266996/#msg266996) n'utilise pas des paquets ICMP ?
Ou rien a voir ?
-
Voici un MTR sur une plus longue durée sur un serveur de jeux steam, Counter-Strike.
http://p4rker.free.fr/csgo2-20-39.HTML
-
P4rkeR, tout semble bon dans ton traceroute : ping ok et pas de perte de paquet.
Cela serait bien de donner l'IP du serveur en question surtout quand il y a un pb, pour qu'on puisse avec des tests depuis d'autres réseaux bien identifier le problème.
-
Ok merci vivien.
L'ip en question est 146.66.159.95.
Je la noterai directement dans les documents HTML que je publierai dorénavant.
-
La fin du traceroute me laisse perplexe je dois dire... Je comprends pas trop ce que 192.168.131.30 et 192.168.131.3 font là. Normalement 192.168.0.0/16 est un bloc d'adresses réservées aux réseaux privés.
Salut,
rien n’empêche d'utiliser des adresses privées à l'intérieur d'un réseau. En l'occurence sur le réseau Valve.
Si tu fais un traceroute en partant de chez Orange, tu verras des routeurs en 10.0.0.0/8 ;) Ils sont injoignables depuis l'extérieur mais vu que ce sont des routeurs intermédiaires sur le réseau ORange (ou Valve) on s'en moque.
@parker: j'essayais de t'aider mais à force de te réexpliquer 50 fois la même chose je pensais que c'était acquis ...mais sujet clos pour moi.
-
Ah oui tiens, je n'y avais jamais pensé... Pourtant je n'ai jamais été choqué par les adresses privées au départ du traceroute.
-
C'est quand même pas propre.
-
C'est quand même pas propre.
Boarf, moi ça me choque pas. Ce ne sont pas des machines vouées à communiquer elles mêmes avec l'extérieur. Pourquoi utiliser une ressource devenue rare ?
-
Parce qu'elles communiquent parfois avec l'extérieur et qu'on reçoit des paquets provenants d'adresse IP privées sur Internet.
Je comprends le problème de rareté, mais Orange?
-
Je viens de supprimer les échanges peu courtois.
P4rkeR, s'est spontanèment excusé, ce qui est rare sur un forum.
Merci à tous (et à corrector en particulier) de ne plus revenir sur l'incident.
-
WTFast n'est pas un VPN.
Il ne crypte pas la connexion, il permet juste d'emprunter une route différente.
Donc c'est un tunnel qui n'est pas chiffré (on ne devrait pas dire crypté), mais c'est un tunnel tout comme un VPN.
C'est pour ça qu'on te parle de VPN, le principe de base est le même, l'effet sur le routage est le même.