Auteur Sujet: IPv6: Facebook lent à charger "packet too big" / PMTU Discovery non activé (Lu 3873 fois)

Bensay · « **le:** 02 février 2016 à 22:32:09 »

Bonsoir à vous les expert de la MTU,

Sur Windows 10, et suite à une bascule récente en double Pile IPV4/IPV6 je rencontre quelques petit soucis concernant Facebook en IPV6 et uniquement lui.

Pour résumé j'ai un serveur Bind sur mon LAN qui est mon unique serveur DNS vers Internet et qui me répond correctement en V4+V6.

La navigation IPV4 & IPV6 ne posent aucun soucis sur l'ensemble des site mais sur Facebook j'ai des problème de page qui ne charge pas ou qui sont très lentes à le faire.
(Impossible de publier un statu , impossible de changer la confidentialité sans rafraîchir le navigateur et encore).
Cela ne ce produit pas quand je crée une zone pour Facebook sur mon Bind9 pour ne répondre que les réponse A en excluant les AAAA.
La résolution DNS V4/V6 de Facebook est correcte cependant.

J'observe cependant des messages de ce type via Wireshark :

&

Changé la MTU en persistent de change absolument rien.

Une idée de ce qui provoque ça ?

Cdt

Bensay

kgersen · « **Réponse #1 le:** 03 février 2016 à 06:42:20 »

as tu le meme probleme avec www.v6.facebook.com ?

Il me semble que facebook fait (faisait?) du geo balancing avec son dns donc ca peut jouer.

ton serveur bind tu y accedes en ipv4 ou ipv6 ? il est resolveur ou il forward a un autre serveur externe ?

si tu mets 2001:4860:4860::8888 (la version ipv6 de 8.8.8.8 ) comme serveur dns pour le poste, facebook fonctionne t'il normalement ?

Le symptôme se produit quelque soit le navigateur utilisé ?

Le navigateur indique quoi pour les pages qui posent probleme (tracing sous F12 par exemple) ?

ta capture correspond a quel flux ?

ca donne quoi sur le serveur bind9:

Code: [Sélectionner]

cat /proc/sys/net/ipv4/tcp_mtu_probing

oui ca fait bc de questions :p

ps: j'ai oublié la plus importante:
tu ne bloques pas les ICMPv6 en entrée sur ton serveur bind et ton PC ? (c'est parce que tu les vois arriver sur 2a01:... qu'elles sont forcement traitées par cette machine)

kgersen · « **Réponse #2 le:** 03 février 2016 à 07:51:59 »

si on analyse ta capture:

ya 2a01:X qui a tenter d'envoyer un paquet tcp 12635->443 (du https donc) a faceb00c::25de de payload 1430 (donc mtu = 1430+40 = 1470)
le serveur faceb00c::25de a repondu: c'est trop gros, il faut utiliser un mtu de 1460. y'a donc 10 de trop.

ce qui est curieux c'est la meme machine qui repond "packet too big" et qui est la destination finale du paquet initial...en general c'est un routeur intermédiaire qui répond "packet too big"... toutefois ca peut se comprendre si faceb00c::25de est un web frontend ou un load balancer qui continu en backend sur un tunnel ou un vxlan par exemple c'est surement le cas ici.

on dirait donc qu'a priori 2a01:X ne traite le "packet too big" recu en retour et n'adapte pas le mtu de ses prochains paquets.

Bensay · « **Réponse #3 le:** 05 février 2016 à 20:20:33 »

Citation de: kgersen le 03 février 2016 à 06:42:20

as tu le meme probleme avec www.v6.facebook.com ?

Je vais tester

Il me semble que facebook fait (faisait?) du geo balancing avec son dns donc ca peut jouer.
En effet je n'y avait pas songer sur le coup

ton serveur bind tu y accedes en ipv4 ou ipv6 ? il est resolveur ou il forward a un autre serveur externe ?
Resolveur

si tu mets 2001:4860:4860::8888 (la version ipv6 de 8.8.8.8 ) comme serveur dns pour le poste, facebook fonctionne t'il normalement ?
A tester et confirmer

Le symptôme se produit quelque soit le navigateur utilisé ?
Oui sur Chrome + Firefox à minima

Le navigateur indique quoi pour les pages qui posent probleme (tracing sous F12 par exemple) ?

Il faut que je reproduise pour te dire

ta capture correspond a quel flux ?

Reload du fil d’actualités

ca donne quoi sur le serveur bind9:
Code: [Sélectionner]
cat /proc/sys/net/ipv4/tcp_mtu_probing
cat /proc/sys/net/ipv4/tcp_mtu_probing
0

oui ca fait bc de questions :p
Mais j'y répond avec plaisir merci à toi

ps: j'ai oublié la plus importante:
tu ne bloques pas les ICMPv6 en entrée sur ton serveur bind et ton PC ? (c'est parce que tu les vois arriver sur 2a01:... qu'elles sont forcement traitées par cette machine)

J'ai bien peur que l'ICMP v6 soit filtré par défaut sur les hôte du Lan mais pas sur la box en effet

Citation de: kgersen le 03 février 2016 à 07:51:59

si on analyse ta capture:

ya 2a01:X qui a tenter d'envoyer un paquet tcp 12635->443 (du https donc) a faceb00c::25de de payload 1430 (donc mtu = 1430+40 = 1470)
le serveur faceb00c::25de a repondu: c'est trop gros, il faut utiliser un mtu de 1460. y'a donc 10 de trop.
Correct

ce qui est curieux c'est la meme machine qui repond "packet too big" et qui est la destination finale du paquet initial...en general c'est un routeur intermédiaire qui répond "packet too big"... toutefois ca peut se comprendre si faceb00c::25de est un web frontend ou un load balancer qui continu en backend sur un tunnel ou un vxlan par exemple c'est surement le cas ici.

on dirait donc qu'a priori 2a01:X ne traite le "packet too big" recu en retour et n'adapte pas le mtu de ses prochains paquets.

En effet , il semble que PMTU Discovery ne soit pas activé par défaut sur Windows 10 (et les autres ??)

En créant manuelle la clé suivante http://www.pctools.com/guides/registry/detail/888/ pour TcpIP + TcpIPV6 le problème ne semble plus être présent (plus de message "Paquet Too Big")

Une navigation confortable sauf à certains moment pour l'upload d'image à la publication avec des surprises de ce genre :

Bref un beau méli mélo pas simple à @Debug

Mais je ne perd pas espoir.

Cdt

Bensay

kgersen · « **Réponse #4 le:** 05 février 2016 à 21:05:08 »

ton guide http://www.pctools.com/guides/registry/detail/888/ date de 2002 ....a eviter!

curieux que tu doive toucher la base de registre de W10. Par defaut W10 gere bien ca.

la clé en question est expliquée ici: https://technet.microsoft.com/en-us/library/cc957539.aspx
on n'a besoin de la créer que pour la mettre a 0, par défaut elle est a 1 donc c'est activé.
quand on la met a 0, les paquets prennent la taille minimal tout le temps ce qui n'est pas terrible, surtout en IPv4.

Le plus simple pour savoir si les "Paquet Too Big" sont traités est d'essayer d'ouvrir cette page: http://mtu1280.test-ipv6.com/ip/?size=1600
si y'a pas d'erreur et un gros de bloc de texte c'est que ca marche.

Bensay · « **Réponse #5 le:** 05 février 2016 à 22:44:14 »

Citation de: kgersen le 05 février 2016 à 21:05:08

Le plus simple pour savoir si les "Paquet Too Big" sont traités est d'essayer d'ouvrir cette page: http://mtu1280.test-ipv6.com/ip/?size=1600
si y'a pas d'erreur et un gros de bloc de texte c'est que ca marche.

Visiblement c'est le cas avec valeur à 1 ou 0,

une idée de si un reboot est néccésaire entre les changements ?

Plus d'impact sur FB / pour le moment/ par contre les "Ignored Unknow Record" m'intrigue.

Cdt

Bensay