Auteur Sujet: Optimisation MTU (Lu 49949 fois)

Grincheux · « **Réponse #12 le:** 14 août 2011 à 08:39:35 »

Citer

2.1   Statut du lien ADSL :   Connecté
2.2   Etat de la connexion :   Synchronisé
2.3   Dernière synchronisation ADSL :   mercredi 10 août, 20:05:02
2.4   Durée de synchronisation ADSL :   3 jours 11:33:47
2.5   Statut de connexion PPP :   Connecté
2.6   Statut du compte :   OK
2.7   Nom de compte internet :   fti/ceb37d4
2.8   Mode d'authentification PPP :   PAP
2.9   Dernière connexion PPP :   mercredi 10 août, 20:05:06
2.10   Durée de connexion PPP :   3 jours 11:33:43
2.11   Type de protocole PPP :   PPPoE
2.12   Dernière erreur de connexion PPP :
2.13   Date de dernière déconnexion PPP :   mercredi 10 août, 20:04:13
2.14   ATM VP/VC :   8/35
2.15   Mode ADSL :   G992_3_A
2.16   Encapsulation :   LLC
2.17   Latence :   Intlv[LP0]
2.18   Taille maximum de MTU :   1492
2.19   Adresse IP WAN :   90.56.143.231
2.20   Adresse IP du BAS :   90.56.143.1
2.21   Serveur DNS primaire :   80.10.246.1
2.22   Serveur DNS secondaire :   81.253.149.2

Ma livebox

corrector · « **Réponse #13 le:** 14 août 2011 à 09:17:02 »

En fait tout tombe dans un trou noir

SENT (16.0390s) ICMP 192.168.1.10 > 90.56.143.231 Echo request (type=8/code=0) ttl=16 id=2738 iplen=28
RCVD (16.0760s) ICMP 193.253.90.125 > 192.168.1.10 TTL=0 during transit (type=11/code=0) ttl=240 id=21387 iplen=56
SENT (16.8470s) ICMP 192.168.1.10 > 90.56.143.231 Echo request (type=8/code=0) ttl=17 id=51305 iplen=1498
RCVD (16.9010s) ICMP 10.125.196.137 > 192.168.1.10 TTL=0 during transit (type=11/code=0) ttl=239 id=0 iplen=80
SENT (17.8490s) ICMP 192.168.1.10 > 90.56.143.231 Echo request (type=8/code=0) ttl=18 id=51305 iplen=1498
SENT (18.8600s) ICMP 192.168.1.10 > 90.56.143.231 Echo request (type=8/code=0) ttl=19 id=51305 iplen=1498
2ème essai :

SENT (15.9420s) ICMP 192.168.1.10 > 90.56.143.231 Echo request (type=8/code=0) ttl=16 id=9998 iplen=1498
RCVD (16.0050s) ICMP 193.253.90.125 > 192.168.1.10 TTL=0 during transit (type=11/code=0) ttl=240 id=49989 iplen=56
SENT (16.9590s) ICMP 192.168.1.10 > 90.56.143.231 Echo request (type=8/code=0) ttl=17 id=9998 iplen=1498
RCVD (17.0160s) ICMP 10.125.196.137 > 192.168.1.10 TTL=0 during transit (type=11/code=0) ttl=239 id=0 iplen=80
SENT (17.9740s) ICMP 192.168.1.10 > 90.56.143.231 Echo request (type=8/code=0) ttl=18 id=9998 iplen=1498
SENT (18.9880s) ICMP 192.168.1.10 > 90.56.143.231 Echo request (type=8/code=0) ttl=19 id=9998 iplen=1498
SENT (17.0460s) ICMP 192.168.1.10 > 90.56.143.231 Echo request (type=8/code=0) ttl=17 id=2738 iplen=28
RCVD (17.0460s) ICMP 10.125.196.137 > 192.168.1.10 TTL=0 during transit (type=11/code=0) ttl=239 id=0 iplen=74
SENT (20.1140s) ICMP 192.168.1.10 > 90.56.143.231 Echo request (type=8/code=0) ttl=18 id=2738 iplen=28
SENT (21.1290s) ICMP 192.168.1.10 > 90.56.143.231 Echo request (type=8/code=0) ttl=19 id=2738 iplen=28

bizarre.

Grincheux · « **Réponse #14 le:** 14 août 2011 à 09:18:57 »

Est-ce parce que la livebox ne répond pas aux pings ?

corrector · « **Réponse #15 le:** 14 août 2011 à 09:20:34 »

Ça n'aide pas en effet. Je n'ai pas trouvé un seul port ouvert, alors j'ai un peu de mal à tester.

Grincheux · « **Réponse #16 le:** 14 août 2011 à 09:21:57 »

Tu veux que j'en ouvre temporairement un ?

corrector · « **Réponse #17 le:** 14 août 2011 à 09:25:58 »

C'est sûr qu'avec un port TCP qui accepte une connexion ça pourrait aider.

Même une réponse au ping serait un plus.

Grincheux · « **Réponse #18 le:** 14 août 2011 à 09:29:17 »

Le port 23450 est ouvert et la livebox répond au ping

corrector · « **Réponse #19 le:** 14 août 2011 à 09:35:20 »

C'est difficile à voir avec :
nmap -sT -sU -p 23450 90.56.143.231

Starting Nmap 5.51 ( http://nmap.org ) at 2011-08-14 09:33 Paris, Madrid (heure d'ÚtÚ)
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.94 seconds

et avec :
nmap -P0 -sT -sU -p 23450 90.56.143.231

Starting Nmap 5.51 ( http://nmap.org ) at 2011-08-14 09:33 Paris, Madrid (heure d'ÚtÚ)
Nmap scan report for ADijon-156-1-112-231.w90-56.abo.wanadoo.fr (90.56.143.231)
Host is up.
PORT STATE SERVICE
23450/tcp filtered unknown
23450/udp open|filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 4.99 seconds

vivien · « **Réponse #20 le:** 14 août 2011 à 09:56:08 »

J'ai déplacé les messages dans un post a part.

Je vous arrête tous les deux : le réglage de la MTU n'est plus nécessaire avec les box d'aujourd'hui : c'est elle qui font le travail.

Le PC se connecte su un serveur. Le PC a les réglages par défaut : MTU = 1500.
IPv4 a un en-tête de 20 octets. (cf IPv4)
TCP a un en-tête de 20 octets (cf TCP)
Le PC va donc dans le paquet [SYN] de connexion indiquer une MSS (Maximum Segemt Size) de 1460

La box elle ait qu'elle utilise PPPoE qui réduit la MTU de 8 octets (cf PPP)
Elle va modifier a la volée la valeur de la MSS dans le paquet [SYN] et va la passer a 1452

Le réseau lui transporte le flux en L2TP (pour la collecte de trafic). L2TP prend 40 octets d'en-tête. Le réseau va lui aussi a son trour modifier le paquet [SYN] pour mettre une mss à 1420.

Le serveur reçoit le paquet [SYN] et voit que le client ne supporte pas des paquet > 1420, il se limite donc a cette taille.
Dans sa réponse au [SYN], le paquet [SYN, ACK], il pré"cise que lui supporte une MSS de 1460. De nouveau le réseau va modifier cette valeur à 1420 avant l'entrée dans le L2TP.

La box voit passer le paquet, une MSS de 1420 est compatible avec PPPoE donc elle ne change rien et laisse la valeur 1420. SI il n'y a pas de L2TP (cas dun abonné qui est en PPPoE sur son réseau), elle va recevoire une MSS de 1460 qu'elle va passer à 1452.

Il ne sera nécessaire de fragmenter auun paquet car l'éméteur et le récepteur ne vont pas s'échanger des paquet au dessus de la taille limite.

Conclusion : L'optimisation MTU n'est plus nécessaire pour l'ADSL depuis plusieurs années. Il reste nécessaire avec des connexion 2G et 3G.

corrector · « **Réponse #21 le:** 14 août 2011 à 10:29:36 »

Super, et ça marche aussi avec TCP dans IP dans IP?
TCP dans 6in4?
TCP dans GRE?
TCP dans IPsec?
UDP?

Régler la MTU à la main n'est pas nécessaire parce que c'est automatique :

netsh interface ipv6 show interface

Idx Mét MTU État Nom
--- --- ----- ----------- -------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
9 25 1480 connected wifi

La MTU a été automatiquement réglée à 1480 parce que la Freebox et Windows Vista fonctionnent correctement ensemble.

Grincheux · « **Réponse #22 le:** 15 août 2011 à 07:27:16 »

Voici ce que j'ai relevé sur ma machine :

Citer

Microsoft Windows [version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Tous droits réservés.

C:\Users\Grincheux>netsh interface ipv6 show interface

Idx Mét MTU État Nom
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
11 50 1280 disconnected isatap.{3C0AE8E6-FE33-486F-B808-8D26585B390C}
14 50 1280 connected Teredo Tunneling Pseudo-Interface
25 30 1500 connected Pont réseau

C:\Users\Grincheux>netsh interface ipv4 show interface

Idx Mét MTU État Nom
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
25 30 1500 connected Pont réseau

C:\Users\Grincheux>

Peux-tu commenter, cela risque de m'aider à comprendre

Merci

corrector · « **Réponse #23 le:** 15 août 2011 à 22:50:42 »

En IPv4, depuis ta machine, le MTU est de 1500. (Pour IPv6 je ne sais pas quelle interface tu utilises. Il faudrait faire "netsh interface ipv6 show addresses" et "netsh interface ipv6 show route" pour le savoir.)

Pour le MTU, dans "netsh interface ipv4 show destinationcache", quelle PMTU est indiquée pour la plupart des adresses? (ne pas poster le destinationcache ici, parce que ça ne nous ... regarde pas!)

Auteur Sujet: Optimisation MTU (Lu 49949 fois)

corrector

corrector

corrector

corrector

corrector

corrector