Auteur Sujet: Free FTTH ZMD: Port 443 non accessible (cause MTU trop faible) (Lu 35706 fois)

Fuli10 · « **Réponse #48 le:** 03 mars 2016 à 16:11:32 »

Oui, mais le problème de MTU ressemble fortement au problème que j'avais (perte de connexions) en ayant mal configuré le RA de mon routeur qui envoyait une MTU de 1500 (alors que c'est 1480 en 6rd).
Il faut juste inverser le problème entre IPv4 et IPv6: on dirait que le serveur DHCP IPv4, ou que le client IPv4 ne prend pas/mal en compte la nouvelle MTU. Et si en plus la box n'envoie pas de code d'erreur "MTU too big", on est marron.

« **Réponse #49 le:** 03 mars 2016 à 22:27:00 »

Citation de: Fuli10 le 03 mars 2016 à 14:47:51

Ensuite, par expérience malheureuse en IPv6, j'avais constaté à un moment que le 6rd de Free n'envoyait pas d'ICMP 'MTU too big' quand le client était configuré avec une MTU IPv6 de 1500 et que j'envoyai un gros ping, comme s'il considérait que par défaut le client a la bonne MTU.

Je viens de tester et j'observe l'inverse.

rani · « **Réponse #50 le:** 08 mars 2016 à 09:35:19 »

Citation de: alain_p le 03 mars 2016 à 15:51:39

En 6rd, le MTU IPv6 est de 1480. Il est encapsulé dans un IPv4 qui lui a un MTU de 1500.

En ZMD, la mtu es à 1500 que ça soit en v4 ou en v6. On supporte les jumbo.

Par contre, y a un soucis (lire bug) sur certains ONU qui prennent pas correctement leur conf pour
accepter les jumbo qui est apparu suite à une modif mi-février (ce qui pose donc des pbs en v4).
Y a eu une correction la nuit dernière mais on voit encore quelques cas => on va voir avec le constructeur.

Optrolight · « **Réponse #51 le:** 08 mars 2016 à 09:58:45 »

Merci pour l'éclaircissement

hwti · « **Réponse #52 le:** 08 mars 2016 à 10:19:38 »

Ça explique effectivement pourquoi les premiers tests par cyberjuls ne montraient pas le problème, et pourquoi il n'y avait pas d'ICMP : les paquets étaient perdus entre la Freebox et l'ONU.

Est-ce que les jumbo frames sont supportées côté LAN ? Est-ce que ça pourrait permettre une MTU supérieure à 1500, au moins entre deux freenautes ZMD, mais peut-être avec certains serveurs (Internet2) ?

alain_p · « **Réponse #53 le:** 08 mars 2016 à 11:43:59 »

Citation de: rani le 08 mars 2016 à 09:35:19

En ZMD, la mtu es à 1500 que ça soit en v4 ou en v6. On supporte les jumbo.

Je suis étonné que le MTU soit de 1500 aussi bien en v4 qu'en v6, car l'en-tête IPv6 est quand même de 40 octets, contre 20 en IPv4, donc il y a quand même 20 octets de plus pour l'IPv6 ? A moins de prendre sur la partie data, peut-être le fameux MSS (Maximum Segment Size), en IPv6 ?

underground78 · « **Réponse #54 le:** 08 mars 2016 à 11:49:51 »

Ça veut juste dire que le réseau est capable de transporter des paquets d'une taille supérieure à 1500. C'est les fameuses "jumbo frames" dont parle Rani.

alain_p · « **Réponse #55 le:** 08 mars 2016 à 12:10:58 »

Les jumbo frames demandent de changer le MTU (9000 par exemple), donc je ne pense pas que cela soit par défaut ?

underground78 · « **Réponse #56 le:** 08 mars 2016 à 12:21:19 »

Ben c'est transparent pour l'utilisateur à priori. Si tu envoies un paquet IPv4 de taille 1500 à la box, il est empaqueté dans un paquet IPv6 dont la taille dépasse 1500 mais ça ne pose pas de problème parce que le réseau de Free est en fait capable d'accepter des paquets plus gros.

thenico · « **Réponse #57 le:** 08 mars 2016 à 12:31:14 »

Citation de: alain_p le 08 mars 2016 à 12:10:58

Les jumbo frames demandent de changer le MTU (9000 par exemple), donc je ne pense pas que cela soit par défaut ?

Tu peut avoir un MTU de 9k sur eth0 et de 1500 sur eth1.
Il faut juste faire attention à la taille des paquets destiné aux hôte derrière eth1.

kgersen · « **Réponse #58 le:** 08 mars 2016 à 13:19:15 »

oui c'est donc

WAN: mtu 9000 via ce qu'il appele l'ONU, ce qu'on appelle plus habituellement dans ces forums un ONT
LAN: mtu 1500 usuel

Il n'y a que de l'IPv6 qui sort coté WAN de la Freebox: soit a 1500 si c'est du trafic IPv6 normal, soit a 1520 si c'est du 4rd (de l'ipv6 qui transporte de l'Ipv4).

IPv4: PC (1500) -- lan (1500) -- Freebox (1520) -- ONU -- réseau IPv6 Free (1520) -- Gateway 4rd (1500) -- réseau IPv4 Free (1500) --- Internet v4
IPv6: PC (1500) -- lan (1500) -- Freebox (1500) -- ONU -- réseau IPv6 Free (1500) -- Internet v6

(j'ai mis 1520 au 'pif' ca peut être plus ou moins, je n'ai pas fait le calcul de la valeur exacte, cf doc du 4rd pour avoir la valeur exacte).

Le mtu 9000 possible n'est jamais utilisé au max (pour le moment et sous réserve), il sert juste pour éviter la fragmentation d'IPv4. Les paquets de taille >1500 ne transitent que sur le "domaine 4rd" de Free donc entre des équipements contrôlés par Free.

Fuli10 · « **Réponse #59 le:** 08 mars 2016 à 15:24:01 »

Citation de: corrector le 03 mars 2016 à 22:27:00

Je viens de tester et j'observe l'inverse.

Autant pour moi

, je viens de retester et j'ai compris le problème de MTU que j'avais: le firewall qui bloquait l'ICMP retourné.
Au passage j'ai fais d'autres tests et je suis tombé sur cette conclusion: certain serveurs n'autorisent tout simplement pas la fragmentation en ipv6, alors que d'autres oui.
Typiquement:

Code: [Sélectionner]

:~$ sudo ping6  -s 1433 ipv6.google.com
PING ipv6.google.com(par10s21-in-x0e.1e100.net) 1433 data bytes
^C
--- ipv6.google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2009ms
$ sudo ping6  -s 1433 www.subnetonline.com
PING www.subnetonline.com(2a02:348:82:cb69::1) 1433 data bytes
1441 bytes from 2a02:348:82:cb69::1: icmp_seq=1 ttl=57 time=29.7 ms
1441 bytes from 2a02:348:82:cb69::1: icmp_seq=2 ttl=57 time=29.2 ms
^C
--- www.subnetonline.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 29.209/29.470/29.732/0.312 ms

Oui à la fin de la fragmentation !

Edit:
Un dernier test MTU pour la route maintenant que je suis chaud:
Sur PC derrière un routeur, je ping la freebox (IP = mafreebox6.freebox.fr):

Code: [Sélectionner]

$ ping6 -M do -s 1433 fd0f:ee:b0::1
PING fd0f:ee:b0::1(fd0f:ee:b0::1) 1433 data bytes
1441 bytes from fd0f:ee:b0::1: icmp_seq=1 ttl=63 time=1.17 ms
1441 bytes from fd0f:ee:b0::1: icmp_seq=2 ttl=63 time=0.986 ms
1441 bytes from fd0f:ee:b0::1: icmp_seq=3 ttl=63 time=1.03 ms
1441 bytes from fd0f:ee:b0::1: icmp_seq=4 ttl=63 time=0.979 ms
^C
--- fd0f:ee:b0::1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.979/1.042/1.174/0.081 ms

Sur le routeur, un tcpdump sur l'interface wan montre:

Code: [Sélectionner]

$ sudo tcpdump -nai eth0 ip6 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:50:48.212663 IP6 2a01:xx::xx > fd0f:ee:b0::1: ICMP6, echo request, seq 1, length 1441
16:50:48.213012 IP6 fd0f:ee:b0::1 > 2a01:xx::xx: frag (0|1432) ICMP6, echo reply, seq 1, length 1432
16:50:48.213070 IP6 fd0f:ee:b0::1 > 2a01:xx::xx: frag (1432|9)

Il s'agit du premier paquet de la séquence du ping.
En gros:
- la box répond bien à un paquet lui étant destiné, même si le paquet est trop grand par rapport à sa MTU (1480)
- la réponse est fragmentée (soit !)
- ce qui en soit n'est pas choquant, la MTU de l'interface en IPv6 devant être forcé à 1480 je suppose par son ravd interne
- mais à AUCUN moment je n'ai eu un ICMP too big => ça ce n'est pas normal
Le même tcpdump sur ping trop grand vers un serveur internet qui l'accepte (www.subnetonline.com) montre bien que la freebox retourne un "ICMP6, packet too big", mais quelle fragmente bien le request car je vois également les fragments de reply arriver.
A mon avis, quand on accède à une IPv6 de la Freebox avec un paquet trop grand:
- soit la freebox doit retourner un ICMP too big en plus de ses fragments
- soit elle doit être capable de répondre sans fragmenter
Voila, c'est à mon avis un petit bug qui va être vite corrigé.