Maurice0
-
Compteur de contenus
10 -
Inscription
-
Dernière visite
Type de contenu
Profils
Forums
Calendrier
Messages posté(e)s par Maurice0
-
-
J'ai refait un test hier soir, en indiquant temporairement au système de gestion du réservoir ntp.org que mon serveur pouvait recevoir 100 fois plus de requêtes NTP par unité de temps. En IPv4 comme en IPv6 (les deux en même temps) je suis arrivé à un trafic fluctuant entre cent et deux cents mille paquets par heure (ce qui reste loin des pics à un million de paquets par heure observés en octobre 2018) et 80 % de la bande passante utilisée en upload.... le download était équivalent en bande passante mais loin de saturer (car liaison ADSL, donc Asymétrique).
Le tests similaires que je faisais avant conduisaient à une coupure de connectivité au bout de 5 mn max (plus de routage vers mon IP publique au sein du réseau Free). Là j'ai pu laisser tourner pendant quasiment deux bonnes heures sans dysfonctionnement côté Free ! Côté serveur, c'est du pipi de chat : processus ntpd qui ne consomme que 1,3 % du CPU (sur une seul coeur qui plus est), I/O ridicules pour un carte Ethernet giga (et elle tourne en 100 Mbit/s seulement à cause de la freebox, ce qui reste largement suffisant vu le débit ADSL). En téléchargeant un gros fichier en même temps, je peux remplir le débit descendant et toujours pas de souci, ... pas de baisse de performances visible par rapport à d'habitude (en tenant compte du trafic NTP), pas de perte de connectivité ! Ouf !
En somme le problème semble résolu ! 😄
j'espère que ce n'est pas que temporaire. Au passage, je dis merci à je ne sais pas qui chez Free, si c'est une modification faite exprès.
Si le mécanisme qui me posait problème était là pour protéger les utilisateurs des dénis de service distribués (vraisemblablement l'ajout temporaire d'un /32 vers un trou noir (next-hop vers null0) si trop d'IP différentes en provenance d'Internet émettent vers une IP publique de Free pendant un temps donné) , je trouve que le remède est pire que le mal... mais bon, c'est probablement pas la cause du problème que j'avais (?)
-
à priori oui, IPv4 et IPv6 fixes non partagée (liaison ADSL).
En tous les cas rien n'indique dans http://mafreebox.free.fr une notion de partage.
Et ça serait nouveau car il n'y a pas si longtemps (2 ans) j'utilisais la freebox en mode "modem" (mon PC portait directement l'IPv4 publique - pas de NAT réalisé par la freebox donc).
-
u
Il y a 12 heures, mecano91 a dit :La prioritisation des flux le qos n'est pas un filtrage il ne voit pas du tout se qui n'est transporté il ne fait que maintenir une niveau correct pour certains flux et n'est donc pas concerné par la neutralité du Web contrairement à se que faisait SFR par exemple avec ses dns menteurs =>
"La qualité de service (QDS) ou quality of service (QoS) est la capacité à véhiculer dans de bonnes conditions un type de trafic donné, en termes de disponibilité, débit, délais de transmission, gigue, taux de perte de paquet "
https://fr.m.wikipedia.org/wiki/Qualit%C3%A9_de_service#:~:text=La%20qualit%C3%A9%20de%20service%20(QDS,taux%20de%20perte%20de%20paquets%E2%80%A6
Envoyé de mon MI 9 en utilisant Tapatalk
S'il s'agissait de QoS je n'aurais pas une absence de paquets reçu et vu le peu de paquets par seconde la QoS n'aurait aucune raison de se mettre en eouvre vu qu'il n'y a pas de congestion.
Pire un traceroute depuis un autre opérateur à destination de mon IP montre que le second saut chez free est différent de celui que j'observe quand tout fonctionne bien. le routage au sein du réseau Free semble donc modifié et défaillant.
-
Il y a 4 heures, Franck Toudoux a dit :
Ça, vous n'en savez rien. Vous hébergez un serveur NTP via votre IP publique.
Celui peut très bien subir du déni de service.si je subissais un déni de service, je recevrait des paquets même beaucoup plus que d'habitude. Or là je ne reçois plus rien.
avec un traceroute je peux toutefois voir que je peux joindre le premier routeur de Free au delà de l'ADSL, mais rien au delà, et depuis Internet à destination de mon IP publique, j'arrive jusqu'au réseau Free, puis plus rien au sein du réseau free.
A noter que je peux régler le volume de requêtes NTP qui arrivent sur mon serveur via les outils du pool NTP. Pendant plus de 5 ans tout a fonctionné sans problème à un débit de 100 Mbit/s (ce qui induit 3 paquets par seconde environ, et ma liaison ADSL nest pas saturée). J'ai pu observer des pic avec plus de 1 million de requêtes en une heure (oui, un déni de service) sans que ça ne pose problème ni au serveur ni à la bande passante disponible en ADSL.
depuis janvier dès que je dépasse 4 paquets par second (ce qui est ridiculement faible) au bout de 5 à 7 mn mon accès internet est coupé.
C'est reproductible.
-
Au motif du non respect de la neutralité du réseau
D'une part je ne subis aucune attaque, d'autre part je n'ai pas souscrit ni autorisé ce "service" au regard des CGV.
D'autre part, le fait que Free désactive mon IP "pour me protéger'" est pire qu'une attaque DDOS puisque je perds complètement l'accès à Internet.
Je suis pénalisé dans mon utilisation du service que je paye à Free alors que je suis loin de saturer mon lien ADSL, que je respecte les usages et ne nuit à personne (bien au contraire)
trouvez-vous ça défendable ?
-
Bonjour je viens de faire la corrélation avec le serveur NTP public que j"héberge. Quand le nombre, quand le nombre d'IP qui l’interrogent dépasse un certain seuil pendant trop longtemps (même si la bande passante résultant reste ridicule), ça déclenche la coupure décrite ci-dessus. Ce n'est donc pas global, ni même lié à une région, mais propre à une adresse IP publique.
Étonnement je n'ai rien vu de ce type de dispositif et ses conséquences pour l'utilisateur dans les conditions générale de vente contractées avec Free...
-
Bonjour,
depuis début d'année je subis des déconnexions pendant une heure de temps à autres. Je peux alors toujours pinguer la freebox, et le saut au delà (DSLAM ou routeur je ne sais pas), mais je n'ai plus aucun accès Internet (la téléphonie la TV fonctionnent toujours). Dans cette situation en utilisant un autre fournisseur d'accès, tenter de joindre ma Freebox montre que les flux (traceroute) s'arrêtent à l'entrée du réseau Free.
je viens de faire la corrélation avec un serveur NTP public que j'héberge. Les demandes sont fluctuantes et ces coupures d'une heure survienne lors de pics de charges (beaucoup d'IP différentes mais peu de bande passante utilisée, je suis très loin de saturer la ligne ADSL).
D'où ma question : est-ce que Free dispose d'un système qui dans certaines conditions redirige temporairement le trafic à destination d'une IP publique de freebox vers un outil d'analyse ou plutôt de filtrage ? Si oui, peut-on le faire désactiver ? Si non, doit-je poursuivre free pour non respect des conditions de vente ? (les CGV ne mentionnent aucun filtrage)
merci pour toute réponse
Maurice
-
Erreur d'analyse : le second traceroute qui échoue n'indique pas un problème sur le routeur d'Orléans mais sur le dernier routeur à répondre à savoir
194.149.171.193... qui est le premier équipement de Free. En gros ce routeur n'a pas la connaissance du subnet plus spécifique contenant l'adresse IP publique de ma freebox (ce qui doit impacter au moins 512 freebox à ce moment là pour ce subnet), et rien n'indique que les lacunes dans les informations de routage sur ce noeud soient limitées à un seul subnet, le problème est donc potentiellement plus étendu.
Dans la situation où tout fonctionne comme là maintenant, le traceroute vers l'IP publique de ma freebox via la clef4G indique un autre chemin, juste après le réseau Bouygues Telecom, les flux ne transitent plus par le routeur qui posait problème ci-dessus mais pas 194.149.166.21 avant d'arriver au routeur d'Orléans plus au DSLAM/routeur de Saran dont je dépends, puis enfin ma freebox (notée XXXX ci-dessous):
venus | ~ >traceroute -s 192.168.8.100 -z 100 XXXXXXX traceroute to XXXXX (XXXXXX), 30 hops max, 60 byte packets 1 clef4G.systeme-solaire.espace (192.168.8.1) 23.059 ms 23.049 ms 32.944 ms 2 * * * 3 * * * 4 * * * 5 212.195.60.0 (212.195.60.0) 41.273 ms 40.351 ms 45.344 ms 6 be41.cbr01-ntr.net.bbox.fr (212.194.171.132) 51.429 ms 64.091 ms 63.034 ms 7 62.34.2.52 (62.34.2.52) 49.470 ms 50.308 ms 56.411 ms 8 free-bouygtel-peering-10g.club-internet.fr (194.117.192.10) 46.054 ms 46.295 ms 51.832 ms 9 194.149.166.21 (194.149.166.21) 44.281 ms 44.331 ms 69.431 ms 10 orleans-9k-1-be1001.intf.routers.proxad.net (194.149.161.190) 64.524 ms 48.309 ms 48.311 ms 11 213.228.10.133 (213.228.10.133) 44.345 ms 45.126 ms 64.432 ms 12 XXXXXXX (XXXXXX) 100.099 ms 77.739 ms 77.737 msIl s'agit donc manifestement d'un problème de convergence au niveau du réseau Free... un heure pour converger, c'est juste énorme !
ce qui m'étonne toujours c'est que ça ne gêne personne d'autre, ni des clients comme moi, et encore moins des administrateur réseau qui devraient voir que le temps de convergence est si long...
merci de tout retour d'info si vous observer aussi ce type de problème
-
Bonjour,
Depuis début 2020 je constate des pertes de connectivité IP de temps en temps pendant une heure environ. Un premier diagnostique (détails ci-dessous) met hors de cause la freebox et la liaison ADSL, y compris le premier routeur Free au delà de celle-ci. Mon souci c'est que ça devient de plus en plus fréquent. Quant à demander de l'aide au support Free, c'est d'expérience une perte de temps, dès que le réseau retombe en marche, le problème est dit "résolu" tout va bien, au revoir madame, d'autant plus que le problème quand il se produit ne concerne que l'accès Internet, la téléphonie et la TV fonctionnent bien !
Pour contourner ce problème j'ai acheté une clef 4G et un abonnement via Bouygues Telecom (opérateur différent, car chat échaudé craint l'eau froide), ce qui m'a permis de télétravailler correctement et d'y voir un peu plus clair sur la cause probable de ces pannes. Ce qui m'étonne c'est que ça n'impacterait que moi (?)... ou alors on met ça sur le dos d'Internet alors que manifestement c'est un problème chez Free, voici pourquoi j'en viens à cette conclusion :
en cas d'absence de connectivité IP, j'observe ceci :
venus | ~ >traceroute -n -s 192.168.0.3 www.free.fr traceroute to www.free.fr (212.27.48.10), 30 hops max, 60 byte packets 1 192.168.0.254 1.050 ms 1.336 ms 1.862 ms 2 82.231.235.254 20.445 ms 21.158 ms 21.981 ms 3 * * * 4 * * * [...]l'interface 192.168.0.3 est celle de ma machine vers la Freebox, maintenant que j'ai une clef 4G en secours, je peux choisir par où sortir.
Donc déjà, ma liaison ADSL entre la Freebox (192.168.0.254) et sar45-1-82-231-235-254.fbx.proxad.net (82.231.235.254) qui est soit le DSLAM soit le routeur juste après, fonctionne bien. Pourtant pas d'accès Internet quelque soit la destination (ici www.free.fr, mais c'est le même résultat vers www.google.com par exemple : le ping échoue)
Hypothèse 1 : Peut-être que le DSLAM/routeur de Saran n'accède pas à Internet ? Essayons de le joindre via la clef 4G :
venus | ~ >traceroute 82.231.235.254 traceroute to 82.231.235.254 (82.231.235.254), 30 hops max, 60 byte packets 1 clef4G.systeme-solaire.espace (192.168.8.1) 44.009 ms 43.970 ms 43.955 ms 2 10.125.12.239 (10.125.12.239) 73.763 ms 76.915 ms 76.901 ms 3 10.125.14.34 (10.125.14.34) 80.148 ms 80.133 ms 80.117 ms 4 10.125.14.154 (10.125.14.154) 80.242 ms 80.471 ms 80.189 ms 5 212.194.172.216 (212.194.172.216) 80.037 ms 80.162 ms 80.010 ms 6 212.194.171.222 (212.194.171.222) 81.693 ms 36.318 ms 36.294 ms 7 62.34.2.54 (62.34.2.54) 52.463 ms 41.459 ms 42.450 ms 8 free-bouygtel-peering-10g.club-internet.fr (194.117.192.10) 42.404 ms 38.582 ms 49.840 ms 9 194.149.171.193 (194.149.171.193) 50.040 ms 49.814 ms 49.802 ms 10 orleans-9k-1-be1001.intf.routers.proxad.net (194.149.161.190) 50.004 ms 49.993 ms 49.982 ms 11 sar45-1-82-231-235-254.fbx.proxad.net (82.231.235.254) 42.141 ms 54.967 ms venus | ~ >Ben non, tout marche (dans cette situation de panne, la route par défaut de ma machine passe par la clef 4G, pas besoin de préciser l'interface de sortie avec l'option -s comme précédemment). Donc tout paquet émis via ma Freebox arrive bien sur le DSLAM/routeur (sinon le premier traceroute ne fonctionnerait pas). Comme la table de routage de ce dernier est manifestement bien achalandée (sinon le second traceroute ne fonctionnerait pas non plus), les paquets issus de ma machine via la Freebox sont bien transmis vers leur destination sur Internet.
Est-ce donc alors les flux dans l'autre sens, en provenance d'Internet donc, qui n'arrivent pas jusqu'à ma Freebox ? Testons via la Clef 4G la connectivité, non plus vers le DSLAM, mais vers l'IP publique portée par ma Freebox (qui d'ailleurs n'est qu'à un saut après ce DSLAM ou routeur) :
venus | ~ >traceroute XXXXXXX traceroute to XXXXX (XXXXXX), 30 hops max, 60 byte packets 1 clef4G.systeme-solaire.espace (192.168.8.1) 15.401 ms 15.354 ms 15.337 ms 2 10.125.12.239 (10.125.12.239) 58.029 ms 75.468 ms 75.456 ms 3 10.125.14.34 (10.125.14.34) 75.443 ms 75.418 ms 75.406 ms 4 10.125.14.154 (10.125.14.154) 78.672 ms 78.660 ms 78.777 ms 5 212.194.172.216 (212.194.172.216) 78.636 ms 78.625 ms 78.599 ms 6 212.194.171.222 (212.194.171.222) 78.681 ms 63.141 ms 63.203 ms 7 62.34.2.54 (62.34.2.54) 63.189 ms 57.166 ms 67.470 ms 8 free-bouygtel-peering-10g.club-internet.fr (194.117.192.10) 67.447 ms 67.434 ms 67.422 ms 9 194.149.171.193 (194.149.171.193) 67.410 ms 51.231 ms 66.443 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * C-c C-cEffectivement, ça ne passe pas. Mais là où c'est intéressant c'est que le dernier saut à répondre (194.149.171.193) appartient à Free :
venus | ~ >whois 194.149.171.193 | grep address address: 8, rue de la Ville L'eveque address: 75008 address: Paris address: FRANCE address: Free SAS / ProXad address: 8, rue de la Ville L'Eveque address: 75008 ParisOn est donc bien sur un problème interne au réseau Free (ProXad). On peut constater que le préfixe utilisés par Free qui contiennent l'IP publique de ma freebox est bien diffusés sur Internet via BGP, sinon le traceroute via ma clef4G n'irait pas jusqu'à un équipement Free.
Enfin, vu le traceroute qui fonctionne à destination du DSLAM on peut même localiser plus précisément le segment du réseau qui ne fonctionne pas chez Free :
10 orleans-9k-1-be1001.intf.routers.proxad.net (194.149.161.190) 50.004 ms 49.993 ms 49.982 ms 11 sar45-1-82-231-235-254.fbx.proxad.net (82.231.235.254) 42.141 ms 54.967 ms 12 <ma freebox>
Autrement dit, le routeur d'Orléans (194.149.161.190) de temps à autres ne sait pas comment joindre ma Freebox : sa table de routage est alors incomplète. Est-elle saturée ? Est-ce un problème de boucle de routage transitoire en cas de convergence réseau ? J'en sais rien, mais il y a manifestement un problème sur le routeur d'Orléans.
D'où ma question : je ne suis probablement pas le seul à subir ce type de dysfonctionnement dans l'agglomération d'Orléans : Problème de perte d'accès Internet (TV et téléphonie OK) et qui en générale dure environ une heure, survient une à deux fois dans la même journée, rarement plus, avec des périodes calmes de plusieurs jours ?
merci pour vos retours
est-ce que free filtre le traffic ?
dans Services ADSL / VDSL (Cuivre)
Posté(e)
bon bah, mauvaise nouvelle j'ai re-testé hier et en moins de 5 mn, je n'avais plus aucune connectivité IP (un traceroute s'arrête un saut au delà du DSLAM) et en provenance d'internet, un traceroute s'arrête à l'entré du réseau de free... :-(