La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Incidents Free => Discussion démarrée par: papa33 le 02 novembre 2016 à 16:52:22
-
Bonjour,
certains sites sont inaccessibles depuis quelques dizaines de minutes en ce qui me concerne. Exemple : Cdiscount. Cela ne semble pas venir du site.
Egalement, identification impossible sur Amazon (ERR_EMPTY_RESPONSE avec google-chrome), même si la page d'accueil du site s'affiche.
D'autres personnes dans la même situation?
(FTTH ZMD Gradignan)
Merci par avance.
-
Marche bien chez moi en tout cas (non Free depuis cette connexion)
-
Pas de soucis non plus sur de l'adsl Orange (test sur cdiscount)
-
Pas de soucis non plus, testé sur cddiscount et identification amazon, sur une connexion Free VDSL.
-
Merci pour vos retours. Quelqu'un en FTTH ZMD chez Free (encore mieux dans le secteur) pour que je sois sûr?
Bon ça ne vient pas de mon ordi non plus, puisque c'est la même chose sur celui de ma femme (mon ordi est connecté directement en ethernet à la Freebox, celui de ma femme en wi-fi).
Je tenterai un redémarrage de la Freebox quand plus personne ne sera en train de jouer en ligne dans cette maison...(donc tard).
-
Free en ZMD utilise le 10G-EPON avec le 4rd, donc l'IPv6 natif, et l'IPV4 encapsulé dans la trame IPv6, donc oui, il peut y avoir des particularités en ZMD. Un témoignage de quelqu'un en ZMD (plus de 10.000 maintenant) serait donc utile.
-
Même soucis ici, FTTH ZMD, IPv6 + IPv4 full stack, ce qui est marrant c'est que la connection vers mon VPN (Suède) fonctionne très bien et que tout est accessible quand je passe par celui ci.
ping vers deviation.com avec mon IP Free: Délai d'attente dépassée (mais j'arrive laborieusement à charger le site quand même)
ping vers deviation.com derrière le VPN: pas de soucis
J'accède à cdiscount.com, par contre aliexpress.com ne charge pas (pas de soucis si je me connecte derrière le VPN).
-
Et si tu fais un traceroute, qu'est-ce que ça donne ?
-
(http://i.imgur.com/mEz9a9g.png)
(au moins imgur fonctionne :p)
-
étrange, ça sort bien du réseau de Free, au moins dans ce sens.
(au moins imgur fonctionne :p)
Mais utiliser l'uploader intégré du forum reste une meilleure solution :)
-
Désolé, l'habitude ...
-
[hugues@atlantis:~] mtr deviation.com -rbwc1
Start: Wed Nov 2 18:44:42 2016
HOST: atlantis.milkywan.xyz Loss% Snt Last Avg Best Wrst StDev
1. AS4565 neptune.milkywan.xyz (10.0.0.1) 0.0% 1 2.6 2.6 2.6 2.6 0.0
2. AS4565 gw.lyn-dea.milkywan.xyz (10.1.0.2) 0.0% 1 116.2 116.2 116.2 116.2 0.0
3. AS24904 core01-toq.dea.kwaoo.net (178.250.208.94) 0.0% 1 128.0 128.0 128.0 128.0 0.0
4. AS32345 core2.th2.kwaoo.net (172.16.101.2) 0.0% 1 73.5 73.5 73.5 73.5 0.0
5. AS32345 border2-th2.kwaoo.net (172.16.101.13) 0.0% 1 121.1 121.1 121.1 121.1 0.0
6. AS1299 prs-b5-link.telia.net (62.115.147.190) 0.0% 1 71.8 71.8 71.8 71.8 0.0
7. AS1299 prs-bb3-link.telia.net (213.155.131.52) 0.0% 1 75.5 75.5 75.5 75.5 0.0
8. AS1299 nyk-bb1-link.telia.net (80.91.251.96) 0.0% 1 187.6 187.6 187.6 187.6 0.0
9. AS1299 dls-b21-link.telia.net (62.115.137.49) 0.0% 1 201.6 201.6 201.6 201.6 0.0
10. AS1299 tierpoint-ic-310923-dls-b21.c.telia.net (213.248.71.138) 0.0% 1 189.0 189.0 189.0 189.0 0.0
11. AS30496 207.210.229.6 0.0% 1 245.5 245.5 245.5 245.5 0.0
12. AS36024 174.136.31.218 0.0% 1 286.2 286.2 286.2 286.2 0.0
13. AS36024 dallas120.arvixeshared.com (143.95.251.180) 0.0% 1 276.2 276.2 276.2 276.2 0.0
De mon coté, le traceroute aboutit, du tien, il manque le dernier Hop, je trouve ça louche.
-
oui, le même tracert, mais derrière le VPN:
-
Traceroute en utilisant Cogent, pour être au plus proche de Free :
$ mtr -bzrwc100 deviation.com
Start: Wed Nov 2 18:49:13 2016
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1. AS43142 portevlan.adeli.biz (46.227.16.1) 0.0% 100 7.3 2.2 0.2 39.0 4.8
2. AS174 gi0-0-0-16.219.agr12.lys01.atlas.cogentco.com (149.6.118.241) 0.0% 100 9.4 9.5 9.3 10.1 0.0
3. AS174 te0-0-1-6.rcr21.lys01.atlas.cogentco.com (130.117.2.33) 0.0% 100 8.9 9.0 8.8 9.6 0.0
4. AS174 be2471.ccr41.par01.atlas.cogentco.com (130.117.49.37) 0.0% 100 9.4 9.1 8.9 10.7 0.2
5. AS174 be2746.ccr41.jfk02.atlas.cogentco.com (154.54.29.117) 0.0% 100 82.2 82.1 81.8 83.8 0.3
6. AS174 be2806.ccr41.dca01.atlas.cogentco.com (154.54.40.106) 0.0% 100 88.3 88.2 87.9 88.5 0.0
7. AS174 be2112.ccr41.atl01.atlas.cogentco.com (154.54.7.158) 0.0% 100 98.7 98.5 98.4 99.5 0.0
8. AS174 be2687.ccr21.iah01.atlas.cogentco.com (154.54.28.70) 0.0% 100 112.7 112.9 112.6 113.5 0.0
9. AS174 be2441.ccr21.dfw01.atlas.cogentco.com (154.54.41.66) 0.0% 100 118.0 118.0 117.9 118.6 0.0
10. AS174 be2560.rcr21.b010621-0.dfw01.atlas.cogentco.com (154.54.5.238) 0.0% 100 118.7 118.9 118.6 123.7 0.4
11. AS174 38.122.58.34 0.0% 100 125.6 118.4 117.8 135.2 2.3
12. AS36024 207.210.229.6 0.0% 100 118.5 118.4 118.2 120.2 0.3
13. AS36024 174.136.31.218 0.0% 100 130.2 125.1 118.0 271.9 23.0
14. AS36024 dallas120.arvixeshared.com (143.95.251.180) 1.0% 100 118.1 118.1 118.0 119.0 0.0
-
Et depuis une connexion ADSL de Free :
hugues@vm-debian:~$ mtr deviation.com -rbwc1
Start: Wed Nov 2 18:51:22 2016
HOST: vm-debian Loss% Snt Last Avg Best Wrst StDev
1. AS4565 jupiter.milkywan.xyz (10.0.0.6) 0.0% 1 0.7 0.7 0.7 0.7 0.0
2. AS4565 gw.lyn-free2.milkywan.xyz (10.1.1.2) 0.0% 1 1.1 1.1 1.1 1.1 0.0
3. AS??? rtr-free2.milkywan.xyz (192.168.0.254) 0.0% 1 4.8 4.8 4.8 4.8 0.0
4. AS12322 cxr69-5.nra.fbx.proxad.net (82.227.132.254) 0.0% 1 26.8 26.8 26.8 26.8 0.0
5. AS12322 lyon-crs8.intf.routers.proxad.net (213.228.21.254) 0.0% 1 28.6 28.6 28.6 28.6 0.0
6. AS??? p11-crs16-1-be1118.intf.routers.proxad.net (194.149.163.57) 0.0% 1 39.4 39.4 39.4 39.4 0.0
7. AS??? th2-9k-3-be1001.intf.routers.proxad.net (194.149.162.86) 0.0% 1 34.9 34.9 34.9 34.9 0.0
8. AS174 be4204.ccr21.par04.atlas.cogentco.com (149.11.115.13) 0.0% 1 85.3 85.3 85.3 85.3 0.0
9. AS174 be12309.ccr42.par01.atlas.cogentco.com (154.54.39.65) 0.0% 1 39.1 39.1 39.1 39.1 0.0
10. AS174 be2747.ccr42.jfk02.atlas.cogentco.com (154.54.31.189) 0.0% 1 104.8 104.8 104.8 104.8 0.0
11. AS174 be2807.ccr42.dca01.atlas.cogentco.com (154.54.40.110) 0.0% 1 112.5 112.5 112.5 112.5 0.0
12. AS174 be2113.ccr42.atl01.atlas.cogentco.com (154.54.24.222) 0.0% 1 126.4 126.4 126.4 126.4 0.0
13. AS174 be2690.ccr22.iah01.atlas.cogentco.com (154.54.28.130) 0.0% 1 135.5 135.5 135.5 135.5 0.0
14. AS174 be2443.ccr22.dfw01.atlas.cogentco.com (154.54.44.230) 0.0% 1 142.9 142.9 142.9 142.9 0.0
15. AS174 be2561.rcr21.b010621-0.dfw01.atlas.cogentco.com (154.54.6.74) 0.0% 1 142.1 142.1 142.1 142.1 0.0
16. AS174 38.122.58.34 0.0% 1 140.5 140.5 140.5 140.5 0.0
17. AS30496 207.210.229.6 0.0% 1 194.9 194.9 194.9 194.9 0.0
18. AS30496 174.136.31.218 0.0% 1 191.3 191.3 191.3 191.3 0.0
19. AS36024 dallas120.arvixeshared.com (143.95.251.180) 0.0% 1 191.7 191.7 191.7 191.7 0.0
-
deviation.com, cddiscount.com, amazon.com... ne semblent avoir que des adresses IPv4. Cela donne quoi un traceroute sur google.fr, qui lui a une adresse IPv6 ?
-
Pas de soucis vers google.com (ipv6 activée).
speedtest.net charge la page, mais l'applet Flash mets un temps anormalement long à charger, et le test de down s'est arrêté avant la fin (~700Mbps, normal, puis arrêté à 5% de la fin ...).
-
mmh, et si tu coupe IPv6 ( :-[ ), il se passe quoi ?
-
speedtest.net a des adresses en IPv6... La page flash, je ne suis pas sûr. Je suis redirigé vers beta.speedtest.net, qui lui ne semble pas avoir d'adresse IPv6.
-
mmh, et si tu coupe IPv6 ( :-[ ), il se passe quoi ?
Tu tiens une piste, si je repasse en IPv4 le ping vers google.com prends 50-75% de perte ... plus de soucis une fois revenu en IPv6
-
Les différentes pages de test de connectivité disponibles sur https://ip.lafibre.info/connectivite.php fonctionnent chez toi ? (pas la peine de tester celles qui sont en IPv4+IPv6 ou IPv6 uniquement)
-
Après Google c'est pas forcèment un bon exemple comme il y a régulièrement des saturations.
Je vois bien un soucis de MTU sinon.
-
Tu tiens une piste, si je repasse en IPv4 le ping vers google.com prends 50-75% de perte ... plus de soucis une fois revenu en IPv6
Nop, c'est super courant chez Free ça... :/
-
Je vois bien un soucis de MTU sinon.
Bof, un traceroute ne passe pas, alors que c'est des tout petits paquets :/
-
Les différentes pages de test de connectivité disponibles sur https://ip.lafibre.info/connectivite.php fonctionnent chez toi ? (pas la peine de tester celles qui sont en IPv4+IPv6 ou IPv6 uniquement)
Pas vraiment, et c'est de pire en pire, il y a encore quelques minutes j'accédais au forum (lafibre.info) sans soucis, mais ça deviens de plus en plus galère, obligé de recharger 10x :-\
edit: il y a du mieux par moment, bon à priori je suis pas le seul, en attendant que ça s'améliore je vais utiliser le VPN ...
-
Et en IPv6 cela fonctionne par contre ?
-
Oui, les tests IPv6 only passent bien.
-
Hello !
Même problème sur la commune de Mérignac en ZMD.
C'est inutilisable de mon côté, les pages ne chargent pas, ou alors c'est très lent ...
Le speedtest.net n'est même pas arrivé à la fin du test, j'ai eu une erreur avant.
ping 8.8.8.8
Envoi d’une requête 'Ping' 8.8.8.8 avec 32 octets de données :
Délai d’attente de la demande dépassé.
Réponse de 8.8.8.8 : octets=32 temps=9 ms TTL=60
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Statistiques Ping pour 8.8.8.8:
Paquets : envoyés = 4, reçus = 1, perdus = 3 (perte 75%),
Durée approximative des boucles en millisecondes :
Minimum = 9ms, Maximum = 9ms, Moyenne = 9ms
tracert 8.8.8.8
Détermination de l’itinéraire vers google-public-dns-a.google.com [8.8.8.8]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms FREEBOX [192.168.1.254]
2 12 ms 15 ms 15 ms 194.149.164.50
3 9 ms 9 ms 9 ms bzn-crs16-2-be1005.routers.proxad.net [78.254.249.77]
4 15 ms * 16 ms 72.14.211.26
5 * * * Délai d’attente de la demande dépassé.
6 * * 9 ms 66.249.94.207
7 * * * Délai d’attente de la demande dépassé.
8 * 9 ms 9 ms google-public-dns-a.google.com [8.8.8.8]
Itinéraire déterminé.
-
Merci, je me sens moins seul 8)
Il semble que l'auteur du thread soit du département aussi, le problème semble être localisé par chez nous.
-
Pour résumer, tous les sites sont impactés en IPv4 ou seulement certains ?
Note : jmr76 il semblerait que tu consultes le forum en IPv4 et non en IPv6.
-
Même problème à Houilles (78). Certains sites ne se chargent pas et ce phénomène est récurrent en ZMD (confirmé par la hotline Free).
-
Pour résumer, tous les sites sont impactés en IPv4 ou seulement certains ?
Note : jmr76 il semblerait que tu consultes le forum en IPv4 et non en IPv6.
Oui je suis en IPv4 (adresse ip full stack), l'IPv6 est désactivé sur mon PC.
-
Pour résumer, tous les sites sont impactés en IPv4 ou seulement certains ?
ça semble généralisé, pas ou peu de réponses au ping sur les IPv4, pour le chargement des sites ça dépends, labanquepostale.fr passe bien, aliexpress.com et paypal.fr bof, rcgroups.com accès impossible pour le moment.
edit: tout ça depuis la fin de l'après midi, j'étais sur internet le reste de la journée sans soucis.
-
jmr76 : Rien n’apparaît d'anormal en pingant ton IP - le problème est donc plus loin (ce n'est pas ta box qui répond à l'IPv4, mais l'équipement Free qui met les données dans IPv6)
$ mtr -zrwc100 82.64.0.xxx
Start: Wed Nov 2 21:33:55 2016
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1. AS43142 portevlan.adeli.biz 0.0% 100 0.3 1.2 0.2 37.6 4.8
2. AS29075 sw1-le9lyon-ge-1-4.ix-customers-le9lyon.ielo.net 0.0% 100 1.6 3.1 1.2 23.4 3.9
3. AS29075 te-2-3-frpar01-a9k1.rt.ielo.net 0.0% 100 9.8 9.8 9.4 17.2 0.7
4. AS29075 pni-free.th2-prs.fr.rt.ielo.net 0.0% 100 9.6 9.6 9.5 13.1 0.4
5. AS??? bzn-crs16-2-be1011.intf.routers.proxad.net 0.0% 100 9.8 13.6 9.7 17.8 2.4
6. AS??? ? ? 100.0 100
7. AS??? ? ? 100.0 100
8. AS??? ? ? 100.0 100
9. AS??? ? ? 100.0 100
10. AS12322 lns-bzn-20-82-64-0-xxx.adsl.proxad.net 0.0% 100 18.1 18.2 17.9 21.3 0.4
-
Ce n'est pas tout à fait généralisé en fait, je ping l'adresse de connection de mon serveur VPN (IPv4) sans soucis par exemple.
-
Le problème n'est toujours pas résolu ce matin de mon côté, ça commence à faire long >:(
Par contre speedtest OK.
-
Bonjour à tous,
Je viens de m'inscrire sur le forum pour vous indiquer que je rencontre les mêmes symptômes sur la commune de Bruges (33) en ZMD. A savoir des problèmes de connexion récurrents sauf lorsque je passe en VPN où la connexion est nickel. Les problèmes datent bien d'hier également.
Bonne journée ;)
PS : ça semble quand même localisé sur le 33 (Gironde) et même sur la métropole Bordelaise... :-\
-
Gradignan, Mérignac, Bruges, en effet on fait le tour de la rocade là...
Mais il y avait quand même un témoignage du 78 dans le même sens également.
-
Bonjour,
Je comprends mieux le message de ma voisine hier soir ... elle a le même souci et j'ai testé chez moi aussi ce matin avant de partir et pareil, en ipv4 c'est au petit bonheur la chance.
Nous sommes sur Sucy (94) ; elle en ip partagée et moi en ip full stack.
Je ne suis pas chez moi mais je peux tester depuis un rpy connecté si besoin.
-
Depuis hier soir je rencontre le même problème. Je me sens moins seul du coup.
A noter que ce problème s'est déjà produit il y a environ un mois en soirée. Le lendemain matin tout fonctionnait de nouveau.
NB : connexion sur Sucy en IP Full stack
-
Cela ressemble bien à un problème général en ZMD, en IPv4. Je serais assez partisan de vérifier la taille du MTU, comme le suggérais underground78, même si comme le dit Hugues, dans un traceroute, la taille des paquets est petite. Il y a différentes méthodes pour cela. Sous windows, on peut utiliser netsh pour afficher la table en cache des destinations déjà parcourues :
C:>netsh interface ipv4 show destinationcache | more
Interface 1 : Loopback Pseudo-Interface 1
PMTU Adresse de destination Adresse de saut suivant
---- --------------------------------------------- -------------------------
1500 127.0.0.1 127.0.0.1
1500 239.255.255.250 239.255.255.250
Interface 2 : Ethernet
PMTU Adresse de destination Adresse de saut suivant
---- --------------------------------------------- -------------------------
1500 13.107.3.128 192.168.0.254
1500 37.59.243.53 192.168.0.254
1500 40.77.226.220 192.168.0.254
....
Donc le Path MU (PMTU) est de 1500 sur ces destinations. On peut faire la même chose en IPv6.
On peut aussi envoyer un ping en spécifiant la longueur du paquet et en empêchant de fractionner, le plus long qui passe indique le MTU, après quelques calculs d'en-tête :
C:>ping -l 1472 -f 212.27.48.10
Envoi d’une requête 'Ping' 212.27.48.10 avec 1472 octets de données :
Réponse de 212.27.48.10 : octets=1472 temps=28 ms TTL=58
Réponse de 212.27.48.10 : octets=1472 temps=28 ms TTL=58
Réponse de 212.27.48.10 : octets=1472 temps=31 ms TTL=58
Statistiques Ping pour 212.27.48.10:
Paquets : envoyés = 3, reçus = 3, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 28ms, Maximum = 31ms, Moyenne = 29ms
-l spécifie le longueur du paquet, -f empêche de fractionner. 1472 passe, pas 1473. Il faut compter 20 octets d'en-tête IPv4, plus 8 pour l'ICMP, donc 1472+20+8 = 1500, le MTU est de 1500 en IPv4. Là, on a le MTU à l'instant du ping, et pas il y a quelques heures ou jours, avec l'historique.
Sous linux, on peut utiliser la commande tracepath
$ tracepath lafibre.info
1?: [LOCALHOST] pmtu 1500
1: 192.168.0.254 21.585ms
1: 192.168.0.254 21.777ms
2: arp91-4-78-235-182-254.fbx.proxad.net 33.000ms
3: 213.228.23.254 18.600ms
4: p11-crs16-1-be1114.intf.routers.proxad.net 20.407ms
5: th2-9k-3-be1001.intf.routers.proxad.net 18.428ms
6: ge1-17-cr2.th2-prs.fr.rt.ielo.net 22.852ms
7: te-3-1-frlyo01-c6k1.rt.ielo.net 27.772ms
8: adeli1.ix-customers-le9lyon.ielo.net 28.878ms
9: lafibre.info 37.823ms reached
Resume: pmtu 1500 hops 9 back 9
-
Je ne suis pas chez moi donc je ne sais pas si le problème est toujours là mais voici le résultat depuis chez moi quand même (ip full stack)
$ tracepath lafibre.info
1?: [LOCALHOST] pmtu 1500
1: 192.168.0.254 1.004ms
1: 192.168.0.254 0.863ms
2: 194.149.164.50 10.781ms
3: th2-9k-3-be1000.intf.routers.proxad.net 3.712ms
4: ge1-17-cr2.th2-prs.fr.rt.ielo.net 4.112ms
5: te-3-1-frlyo01-c6k1.rt.ielo.net 11.471ms
6: adeli1.ix-customers-le9lyon.ielo.net 83.077ms
7: lafibre.info 13.791ms reached
Resume: pmtu 1500 hops 7 back 58
-
Donc un MTU normal en ZMD, puisque les jumbo frame sont activées en IPv6, et que le MTU IPv4 est bien de 1500.
-
La voisine qui avait aussi le souci hier me signale qu'actuellement les sites, qui marchaient pas hier, fonctionnent correctement.
Le souci est-il résolu ?
D'autres confirment ?
-
Pour ma part, il y a eu une période pendant laquelle ça semblait fonctionner de nouveau et c'est reparti de plus belle.
-
Pour ma part, il y a eu une période pendant laquelle ça semblait fonctionner de nouveau et c'est reparti de plus belle.
Tu as un site où ça déconne ? Jpeux lui faire tester.
-
A priori ça fonctionne de nouveau. J'essayais d'accéder à des sites d'info high-tech français et par exemple zdnet.fr ne passait pas du tout.
Tu as un site où ça déconne ? Jpeux lui faire tester.
-
Alain, je viens d'essayer un tracepath sur www.zdnet.fr, comme Mathieu disait que c'était un des sites qui posent/posaient problème.
Voici ce que j'obtiens ; je ne sais pas ce que c'est le "asymm"
$ tracepath www.zdnet.fr
1?: [LOCALHOST] pmtu 1500
1: 192.168.0.254 0.922ms
1: 192.168.0.254 0.861ms
2: 194.149.164.50 10.955ms
3: th2-9k-3-be1000.intf.routers.proxad.net 3.614ms
4: free-pni2.xe3-0-0.th2.par.as8218.eu 3.986ms asymm 7
5: et-1-0-0.tcr2.th2.par.core.as8218.eu 4.029ms asymm 8
6: oxalide-gw5.tcr2.th2.par.cust.as8218.eu 12.207ms asymm 9
7: not.updated.oxalide.net 5.032ms asymm 10
8: no reply
9: ...
Un ping depuis une ADSL dégroupée
Envoi d'une requête 'ping' sur www.zdnet.fr [146.185.42.33] avec 32 octets de données :
Réponse de 146.185.42.33 : octets=32 temps=42 ms TTL=55
Réponse de 146.185.42.33 : octets=32 temps=43 ms TTL=55
Réponse de 146.185.42.33 : octets=32 temps=44 ms TTL=55
Réponse de 146.185.42.33 : octets=32 temps=43 ms TTL=55
Statistiques Ping pour 146.185.42.33:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 42ms, Maximum = 44ms, Moyenne = 43ms
Un ping en même temps depuis la connexion fibre full stack :
$ ping www.zdnet.fr
PING www.zdnet.fr (146.185.42.33) 56(84) bytes of data.
^C
--- www.zdnet.fr ping statistics ---
97 packets transmitted, 0 received, 100% packet loss, time 96005ms
-
A priori asymm veut dire 'asymmetric', c'est à dire que le chemin entre l'aller et le retour a été différents, et le nombre indiqué montre le nombre de sauts qui ont été différents. Cela peut arriver quand un lien est congestionné et un autre chemin emprunté.
Voir :
https://answers.launchpad.net/ubuntu/+source/gnome-nettool/+question/7682
et la page de man :
$ man tracepath | grep asymm
2: dust.inr.ac.ru asymm 1 0.390ms pmtu 1480
RTT. Additionally, it can show Path MTU, when it changes. If the path is asymmetric or the probe finishes before it reach
information is not reliable. F.e. the third line shows asymmetry of 1, it is because the first probe with TTL of 2 was
asymmetric.
Donc il semble y avoir des soucis sur le chemin vers zdnet. Un routage asymétrique, en général, ce n'est pas très bon, et cela explique probablement les problèmes. D'ailleurs, tu n'atteins pas le site.
-
Je me rends compte que j'ai également ce problème sur ZDNET. Le problème est toujours présent ce midi :(
-
Toujours pas mieux ici non plus :'(
Bon, ça ne fait que 2 semaines à peine que j'ai la fibre, avec un peu de chance le VDSL n'a pas été coupé encore, je vais essayer de rebrancher le cordon téléphonique et débrancher la fibre pour le moment ...
-
En général, quand la fibre a été activée, la ligne cuivre est désactivée. Tu verras bien. Je voyais justement un sujet ce matin, où, suite à des problèmes sur la connexion fibre en ZMD, la ligne cuivre avait été maintenue.
-
A noter : l'espace abonné est inaccessible également en ce qui me concerne...
-
Le problème persiste 24h plus tard sur Houilles (78). Après plusieurs appels au 3244, pas tous sur un ton chaleureux ainsi que de multiples tests aucune évolution et pas vraiment de solution concrète proposée par la hotline (je cite "votre problème est spécial") mis à part une soit disant investigation auprès du service concerné à laquelle je ne crois plus vu la récurrence de l'anomalie depuis des mois.
J'ai donc un peu de mal à rester optimiste car depuis mon inscription à la fibre Free en zone ZMD (Avril 2016) je rencontre ce problème d'accès à certains sites web. Lorsque cela se produit cela peut durer entre 4h et 3 jours. Et donc effectivement ce sont des sites comme Cdiscount, Macg.co, Onedrive.com, l'upload sur iCloud mais paradoxalement Speedtest fonctionne tout comme Facebook, Apple.com, etc, etc... La liste des sites non accessibles comme accessibles n'est évidement pas exhaustive.
EDIT : petite précision, Free m'a demandé de désactiver l'ipv6. C'est pire... En l'occurence sur Apple.com qui en ipv4 ne charge plus. Ce n'est qu'un exemple.
-
Retour à la normale pour moi!
-
Légère amélioration de mon coté aussi, je peux me connecter à l'espace abonné alors que ce n'était plus possible non plus.
Ping vers deviation.com toujours KO mais navigation possible, pareil pour aliexpress.com
Depuis la première fois depuis hier soir j'ai pu compléter un speedtest (bon, 1 sur 3 a foiré quand même ...), il semble que mon up soit passé de 350 à 200 Mbps, ils sont peu être en train de (re)configurer des choses ?
edit: up repassé au dessus des 300.
-
Pareil ici, la navigation est OK sur les sites qui coinçaient encore à midi. Alors on se demande bien ce qui s'est passé... :)
-
Probablement un soucis sur les équipements qui gèrent l'IPv4 en ZMD ?
-
D'autres ont des soucis en IPv6, apparemment de routage. Voir jfdomo, mais il n'y a pas que lui (vu sur free-reseau) :
https://lafibre.info/free-espace-technique/perte-ipv6-depuis-le-13-octobre-2016-a-14h/
-
Quelques messages ont été perdus ici, notamment un où je disais que j'allais voir si Optrolight était d'accord pour faire remonter l'info via ces canaux "alternatifs". Il se trouve qu'il ne m'avait pas attendu et qu'il a déjà signalé le problème à son contact. :)
-
Quelques messages ont été perdus ici, notamment un où je disais que j'allais voir si Optrolight était d'accord pour faire remonter l'info via ces canaux "alternatifs". Il se trouve qu'il ne m'avait pas attendu et qu'il a déjà signalé le problème à son contact. :)
Merci encore !
Effectivement j'ai constaté quelques difficultés sur le forum et un backup datant d'hier :P
-
Le backup date de ce matin 9h45, le disque dur a rendu l'âme (https://lafibre.info/evolution/panne-disque-dur/msg386600/#msg386600).
-
Le backup date de ce matin 9h45, le disque dur a rendu l'âme (https://lafibre.info/evolution/panne-disque-dur/msg386600/#msg386600).
Ha mer.. :-\
-
bonjour
je ne sais pas si c'est la bonne rubrique, mais j'aurais voulu avoir plus d'information sur IPV6 car j'ai suivi ce tuto http://aide.ma-freebox.fr/ipv6.html pour ma freebox evolution mais malheureusement ça change rien lorsque je vais sur http://ipv6.dinhosting.fr/ pour faire le test il est indiqué "Vous êtes connecté en IPv4"
Savez vous d'ou viens le problème ?
pour infos j'ai une freebox evolution connecté en adsl, un pc sous windows 7 64bit avec connection ethernet
bonne soiréee
-
Tu as redémarré ta freebox ? En bas de cette page est indiqué si tu es en IPv6 ou en IPv4. Par exemple, pour moi qui suis aussi avec une freebox revolution, et l'IPv6 activé (je suis en VDSL2), il est indiqué :
"Vous utilisez IPv6 (Félicitations!) avec le port TCP 50074 "
En ZMD, comme tu as peut-être pu le noter sur ce sujet, l'IPv6 est pas défaut, et l'IPv4 est transporté dans des trames IPv6. Mais sur ton LAN, il faut à la fois que l'IPv6 soit activé sur la box et dans ton interface, et bien sûr que tu n'aies pas désactivé le protocole IPv6 sur ton PC.
-
oui j'ai redémarré a plusieurs reprises et j'ai bien activé sur mon compte free ainsi que dans le freebox OS. et en bas de cette page moi j'ai "Vous utilisez IPv4 avec le port TCP 49965".
Par contre si je décoche le protocole ipv4 présent dans les paramètre de ma carte réseau je me retrouve sans connexion internet
il n'existe pas un tuto pour vérifié les paramétre de mon pc car sur ma carte j'ai bien les 2 protocole ipv4 et ipv6 d'activé
Tu as redémarré ta freebox ? En bas de cette page est indiqué si tu es en IPv6 ou en IPv4. Par exemple, pour moi qui suis aussi avec une freebox revolution, et l'IPv6 activé (je suis en VDSL2), il est indiqué :
"Vous utilisez IPv6 (Félicitations!) avec le port TCP 50074 "
En ZMD, comme tu as peut-être pu le noter sur ce sujet, l'IPv6 est pas défaut, et l'IPv4 est transporté dans des trames IPv6. Mais sur ton LAN, il faut à la fois que l'IPv6 soit activé sur la box et dans ton interface, et bien sûr que tu n'aies pas désactivé le protocole IPv6 sur ton PC.
-
c'est bon je suis en IPV6 je sais pas si c'est le faite d'être passé par le forum :) mais cette fois ça marche c'est un peu bizarre. ou peut etre un long délai d'actualisation sur les services de free
-
Bonjour Je déterre ce post pour vous dire que j'ai le même symptôme depuis hier soir sur Saran 45.
Ameli, icloud impossible d'accès et twitter ça fonctionne ou ça ne fonctionne pas. Et l'accès à mon espace abonné free impossible.
Bonne journée
-
J'ai un autre cas qui m'a contacté pour ce même problème sur twitter.
Parmi les choses qui ne fonctionnent pas en IPv4, il y a :
- 8.8.8.8 (DNSGoogle)
- Adeli : http://ip.lafibre.info/ ne remonte qu'une IPv4 et impossible d'afficher http://ipv4.lafibre.info/ (page IPv4 only)
- OVH : https://lea-linux.org/ qui est en IPv4 only ne répond pas
Le problème est présent aussi bien avec Windows 10 que Linux (autrement dit ce n'est pas un pb soft sur son PC).
-
J'ai un autre cas qui m'a contacté pour ce même problème sur twitter.
Parmi les choses qui ne fonctionnent pas en IPv4, il y a :
- 8.8.8.8 (DNSGoogle)
- Adeli (http://ip.lafibre.info/ ne remonte qu'une IPv4 et impossible d'afficher http://ipv4.lafibre.info/ (page IPv4 only)
- OVH (https://lea-linux.org/ qui est en IPv4 only ne répond pas)
Le problème est présent aussi bien avec Windows 10 que Linux (autrement dit ce n'est pas un pb soft sur son PC).
Ok donc pas le seul j'ai mis un message sur twitter et j'en ai un autre aussi et donc on ait 2 en ip full
-
même soucis ici depuis hier soir et le problème semble empirer, je viens de me connecter en partageant la connexion 4G du smartphone, sinon la plupart des sites sont inaccessibles (lafibre.info compris)
-
lafibre.info est disponible en IPv6, donc si le problème ne touche que IPv4, vous devriez avoir accès au forum.
-
même soucis ici depuis hier soir et le problème semble empirer, je viens de me connecter en partageant la connexion 4G du smartphone, sinon la plupart des sites sont inaccessibles (lafibre.info compris)
Bjr tu es sur quel région ?
-
Bordeaux Mérignac, FTTH ZMD
-
Bordeaux Mérignac, FTTH ZMD
Moi Sur Saran 45 en FTTH ZMD aussi en IP FAll-stack
-
lafibre.info est disponible en IPv6, donc si le problème ne touche que IPv4, vous devriez avoir accès au forum.
oui désolé, ça fonctionne en ipv6
je viens de tester un ping, ça fonctionne sur l'ipv6, pas sur la v4 non plus
-
j'ai l'impression de ne plus avoir d'ipv4 du tout en fait, whatismyip.com et autres me répondent
Your IPv4 is: Not Detected
-
j'ai l'impression de ne plus avoir d'ipv4 du tout en fait, whatismyip.com et autres me répondent
Your IPv4 is: Not Detected
Ah je n'y ai pas penser
Je testerai ce soir
Tu es sur une ip full-stack ? Et moi tout à l'heure sur l'appli freebox ça a fonctionner et d'un coup plus rien.
Tu es chez freemobile ?
-
full stack et free mobile oui (qui fonctionne et qui n'est qu'en ipv4 de toute façon), mais je vois pas le rapport ;)
-
full stack et free mobile oui (qui fonctionne et qui n'est qu'en ipv4 de toute façon), mais je vois pas le rapport ;)
En faite c’est déjà l’ip full que l’on a en commun qui a sûrement un souci et pour l’appli freebox tu arrive à te connecter à ta box ? Et c’est pour savoir si oui ou non comme ça après on peut dire que ça vient d’eux
-
Plus d'IPv4 aussi
IP full stack, depuis je dirais 20 minutes, dans le 93.
-
Plus d'IPv4 aussi
IP full stack, depuis je dirais 20 minutes, dans le 93.
Ok donc ça ce généralise
-
Hello ! Je suis la personne qui a contacte Vivien sur Twitter avec le même problème.
Les ping en ipv4 fonctionnent sur certains sites d'autre non.
Exemple : Nextinpact.com fonctionne mais 8.8.8.8 HS.
Cependant avec un VPN, (NordVPN) aucun soucis.
Ipv4 sur Poitiers (86tou)
J'ai un collègue qui a le même problème sur Tours (37) mais lui n'a plus rien du tous (synchro ok mais pas de service)
-
Salut donc on ait pas tous du même coin
-
Ce genre de carte valent ce qu'elle valent, mais, il y a clairement quelque chose qui se generalise: https://downdetector.fr/statut/free/
et pour NextInpact.com
Pinging nextinpact.com [45.60.132.203] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 45.60.132.203:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
-
A strasbourg plus d'accès à mon serveur non plus ...
Panne nationale j'ai l'impression
-
Ce genre de carte valent ce qu'elle valent, mais, il y a clairement quelque chose qui se generalise: https://downdetector.fr/statut/free/
Ah super pas penser à aller dessus
Merci
-
A strasbourg plus d'accès à mon serveur non plus ...
Panne nationale j'ai l'impression
Toi aussi et dans le même cas que nous en ipfull stack
-
Même souci sur Bordeaux Talence.
Hier soir seulement quelques sites ne fonctionnait pas en ipv4 (github, huffpost) et la ce matin plus d'ipv4 du tout. Je pouvais au moins passer par un VPN hier pour contourner le problem mais là c'est mort pour de bon.
-
Idem chez moi dans le 69, ipv6 only ...
-
Même souci sur Bordeaux Talence.
Hier soir seulement quelques sites ne fonctionnait pas en ipv4 (github, huffpost) et la ce matin plus d'ipv4 du tout. Je pouvais au moins passer par un VPN hier pour contourner le problem mais là c'est mort pour de bon.
oui début hier soir j'ai bien l'impression que c'est les miggrations de cette nuit ipv4 vers ipv6 qui beug
-
IPv4 de retour ici! pour le moment.
-
IPv4 de retour ici! pour le moment.
ou ça ? moi ça a vite fait d'arrivé et de repartir
-
c'est revenu ici aussi :)
-
c'est revenu ici aussi :)
oui c'est pareil ça l'air d'être ok aussi de mon coté mais j'attend de voir si ça dure
-
Je confirme, j'arrive a ping 8.8.8.8
-
Je confirme, j'arrive a ping 8.8.8.8
Moi j'y arrivais mais arrivais tu a aller dans ton espace abonné free ?
-
Oui sans problème.
-
Oui sans problème.
moi je n'y arrivais pas et maintenant c'est ok
-
En general quand tu arrives pas a acceder a certains sites cest un pb de DNS, ca arrive de temps en temps chez free, en vrai essaye de le forcer à 8.8.8.8 et ca devrait rouler tt seul
-
Hello,
Je suis à Toulouse en 10G-EPON aussi, avec IPv4 Full Stack. Ma Freebox Delta ne répond plus au ping depuis près d'une heure et demie.
Concrètement, TOUS les pings vers les sites Internet en IPv4 échouent, et seuls ceux en IPv6 fonctionnent (ce forum fonctionne, Google / Gmail / Facebook / Free aussi, pas Twitter et beaucoup d'autres).
Pour la Freebox tout est OK, l'heure est affichée, c'est loin d'être la première fois que ça se produit hélas. Impossible de signaler ce genre d'incidents car l'outil de diagnostic ne trouve aucun souci (sic) et c'est toujours en dehors des horaires de l'assistance (sinon c'est pas drôle). C'est souvent les nuits (quelle idée de travailler à cette heure-là aussi ! ^^), sans doute des maintenances, mais j'avais jamais vu ça chez Orange par exemple...
Vous en pensez quoi ?
Merci ;)
-
Elle est en mode bridge par hasard ?
-
Essaye de voir si deja tu arrives a ping 8.8.8.8 ou 8.8.4.4, et sinon comme dit florian regarde la config de ta box ^^
-
Elle est en mode bridge par hasard ?
Pas du tout.
Essaye de voir si deja tu arrives a ping 8.8.8.8 ou 8.8.4.4, et sinon comme dit florian regarde la config de ta box ^^
AUCUN ping vers une IPv4 ne fonctionnait, dont 8.8.8.8...
De plus c'était un incident national chez Free car des abonnés en ADSL ou vDSL étaient concernés ailleurs qu'à Toulouse, dans le Tarn, dans le Loiret, etc etc.
La coupure a duré exactement 2h27...