Auteur Sujet: FTTH Free ZMD (10G-EPON): quelques sites IPv4 inaccessibles (IPv6 ok)  (Lu 32560 fois)

0 Membres et 1 Invité sur ce sujet

mephisto1966

  • Abonné Free fibre
  • *
  • Messages: 8
  • Bruges (33)
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #36 le: 03 novembre 2016 à 07:57:46 »
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...  :-\

papa33

  • Abonné Orange Fibre
  • *
  • Messages: 160
  • Gradignan 33
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #37 le: 03 novembre 2016 à 08:16:23 »
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.

klim94

  • Abonné Free fibre
  • *
  • Messages: 405
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #38 le: 03 novembre 2016 à 10:09:06 »
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.

mathieuc

  • Abonné Free fibre
  • *
  • Messages: 29
  • Sucy-en-Brie (94)
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #39 le: 03 novembre 2016 à 10:41:37 »
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

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 170
  • Delta S 10G-EPON sur Les Ulis (91)
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #40 le: 03 novembre 2016 à 10:45:48 »
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


klim94

  • Abonné Free fibre
  • *
  • Messages: 405
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #41 le: 03 novembre 2016 à 10:54:27 »
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

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 170
  • Delta S 10G-EPON sur Les Ulis (91)
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #42 le: 03 novembre 2016 à 10:56:34 »
Donc un MTU normal en ZMD, puisque les jumbo frame sont activées en IPv6, et que le MTU IPv4 est bien de 1500.

klim94

  • Abonné Free fibre
  • *
  • Messages: 405
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #43 le: 03 novembre 2016 à 11:09:59 »
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 ?

mathieuc

  • Abonné Free fibre
  • *
  • Messages: 29
  • Sucy-en-Brie (94)
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #44 le: 03 novembre 2016 à 11:11:56 »
Pour ma part, il y a eu une période pendant laquelle ça semblait fonctionner de nouveau et c'est reparti de plus belle.

klim94

  • Abonné Free fibre
  • *
  • Messages: 405
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #45 le: 03 novembre 2016 à 11:13:16 »
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.

mathieuc

  • Abonné Free fibre
  • *
  • Messages: 29
  • Sucy-en-Brie (94)
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #46 le: 03 novembre 2016 à 11:23:51 »
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.

klim94

  • Abonné Free fibre
  • *
  • Messages: 405
FTTH ZMD quelques sites IPv4 inaccessibles
« Réponse #47 le: 03 novembre 2016 à 11:33:14 »
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