ping, MTU, TTL, etc... bizzare bizzare

Bart wrote:

Bonjour,

Qui peut m'expliquer ceci:

En cherchant à savoir quel est la MTU de ma connexion (tele2/ADSL avec
PPPoE) j'obtiens des résultats étranges, dépendant de l'adresse
cible, et aussi non reproductibles dans le temps.

Bonsoir,

Vous n'auriez pas le partage de connexion Internet d'activé, pas hazard ???

Le ping avec buffer 1464 qui passe vers google, mais qui rate avec 1465,
c'est normal... 1464 + 28 = 1492, c'est le maximum que sait faire votre
ligne, à cause du protocole PPPoE.

Les messages "Délais d'attente de la demande dépassée" en pinguant
213.103.240.1 (c'est qui ?), au lieu du traditionnel message d'erreur "Les
paquet doit être fragment, mais paramètré DF.", ça me fait furieusement
penser à ça...

Autre chose, pouvez-vous faire le test www.dslreports.com/tweaks ? Quelles
stats cela donne ?

Télé2 par FT, ou par LDCOM ?

--
Herm

Bonsoir,

Vous n'auriez pas le partage de connexion Internet d'activé, pas hazard ???

Le ping avec buffer 1464 qui passe vers google, mais qui rate avec 1465,
c'est normal... 1464 + 28 = 1492, c'est le maximum que sait faire votre
ligne, à cause du protocole PPPoE.

Les messages "Délais d'attente de la demande dépassée" en pinguant
213.103.240.1 (c'est qui ?), au lieu du traditionnel message d'erreur "Les
paquet doit être fragment, mais paramètré DF.", ça me fait furieusement
penser à ça...

Autre chose, pouvez-vous faire le test www.dslreports.com/tweaks ? Quelles
stats cela donne ?

Télé2 par FT, ou par LDCOM ?

Salut,

Je suis aussi chez TELE2 en ADSL128 dégroupé LDCom.
Je n'arrête pas de voir ce truc de MTU. Sous Linux la configuration est
proposé automatiquement à l'installation de la Debian avec un MTU à 1492
je crois. Qu'est-ce que cela change ? D'après ce que j'ai compris c'est
la présence de certain routeur n'acceptant pas des MTU ethernet standard
à 1500 ? Mais que peut-il arriver si on reste en 1500 ?

merci

Résultat test :
http://ny-monitor.dslreports.com/tweak/block:d342af?service=dsl&speed8
&os=win98SE&via=winpoet

Pierre PANTALÉON wrote:

Je suis aussi chez TELE2 en ADSL128 dégroupé LDCom.
Je n'arrête pas de voir ce truc de MTU. Sous Linux la configuration
est proposé automatiquement à l'installation de la Debian avec un MTU
à 1492 je crois. Qu'est-ce que cela change ? D'après ce que j'ai
compris c'est la présence de certain routeur n'acceptant pas des MTU
ethernet standard à 1500 ? Mais que peut-il arriver si on reste en
1500 ?

Bonsoir,

Pour TCP/IP, normalement, pas grand chose. Il y a un mécanisme
d'autodétection de MTU inclu dans le protocole (échange des MSS en option de
TCP lors de l'établissement des connexions), c'est la valeur qui apparaît
via DSLReports. Et... chez vous ça plafonne en réalité à 1440 !

Si ce mécanisme échoue, ou pour les autres protocoles que TCP/IP, il va y
avoir framgentation des paquets :

L'ordinateur émets des paquets à 1500 octets pensant que derrière c'est OK.

Arrivé sur l'interface PPPoE, le pilote dit stop ! Pas plus de 1492 (max du
protocole). Donc IP refait un paquet IP à 1492, et il refait un second
paquet avec le reste (28 octets dont 20 d'en-tête IP) .

Ensuite, si LDCOM fait bien comme France Telecom, les données sont
empaquetées dans un tunnel L2TP au niveau du BAS, apparemment sur Ethernet.
Chez France Telecom, le tunnel permet 1460 octets de données utiles par
paquet, mais selon votre test, on dirait que c'est encore moins chez télé2 !
Bref, le BAS va voir arriver un paquet à 1492 + 8, et voyant que derrière la
limite est à 1440, il va encore fragmenter.

J'ai lu quelque part que les routeurs ne réassemblent jamais les messages,
il n'y a que le destinataire qui le fait. Si l'on suit ce principe, on aura
un paquet à 1440 octets, un autre de 72 octets (20 en-tête IP + 52 utiles),
et un dernier de 28 octets (la première fragmentation).

Le souci est que si un seul des morceaux ne parvient pas à l'arrivée, c'est
tout l'ensemble qui est perdu. IP a le plus grand mal à gérer les pertes de
fragments de paquets...

Essayez de régler votre MTU sur 1400, ça devrait correspondre pile avec 30
cellules ATM et pourrait même améliorer légèrement le débit. En tous les
cas, de préférence, fixez un MTU <= à 1440, ça ne pourra qu'aider votre
connexion.

Résultat test :
http://ny-monitor.dslreports.com/tweak/block:d342af?service=dsl&speed8
&os=win98SE&via=winpoet

Merci pour le lien ! Instructif sur les limites internes de LDCom...

--
Herm

Remy Moulin a écrit:

Bonsoir,

Vous n'auriez pas le partage de connexion Internet d'activé, pas hazard
???

Non. j'ai bien un routeur NAT mais il est hors circuit pour ces tests.

Le ping avec buffer 1464 qui passe vers google, mais qui rate avec 1465,
c'est normal... 1464 + 28 = 1492, c'est le maximum que sait faire votre
ligne, à cause du protocole PPPoE.

Jusque la, je suis d'accord

Les messages "Délais d'attente de la demande dépassée" en pinguant
213.103.240.1 (c'est qui ?),

Le LNS (L2TP Network Serveur), c'est a dire le premier routeur IP quand je
fait un traceroute

au lieu du traditionnel message d'erreur "Les
paquet doit être fragment, mais paramètré DF.", ça me fait furieusement
penser à ça...

Autre chose, pouvez-vous faire le test www.dslreports.com/tweaks ? Quelles
stats cela donne ?

Voila c'est fait:
http://ny-monitor.dslreports.com/tweak/block:494a961?service=dsl&speedQ2&o
s=win98SE&via=winXPpppoe

Télé2 par FT, ou par LDCOM ?

LDCOM

Une question: le MTU à 1440 donné par http://www.dslreport.com/tweaks il l'a
bien sorti de quelque part, mais d'ou ?
Pourquoi je trouve pas ca, moi, avec mes pings ? Si je fait:

ping -f -l 1464 www.dslreports.com
-> Réponse de 209.123.109.175 : octets64 ...

1464+28 = 1492, donc un paquet de 1492 fait l'aller-retour. Alors pourquoi
il me dit 1440, le dslreports ?

Bart

Bart wrote:

Une question: le MTU à 1440 donné par http://www.dslreport.com/tweaks
il l'a bien sorti de quelque part, mais d'ou ?
Pourquoi je trouve pas ca, moi, avec mes pings ?

Eh bien, j'ai le même phénomène que vous, sur ligne FT. Le ping passe bien,
même jusqu'à 1500 (via routeur PPPoA), mais avec un sniffer Ethernet, en
analysant les premières trames échangées de connexions TCP/IP, "quelque
chose" sur le réseau remplace la valeur 1500 par 1460 (chez moi).

C'est cette valeur que remonte dslreports. Il ne fait pas le test du plus
gros ping sans fragmentation.

Ceux qui utilisent Wanadoo sur ligne France Telecom n'ont pas cette limite à
1460, ils peuvent exploiter jusqu'à 1500 sans problème.

La différence ? Etant Club-Internet, ma connexion transite pas les
équipements de France Telecom dans un tunnel L2TP, alors que Wanadoo utilise
les équipements France Telecom en IP "natif".

Une doc trouvée sur Internet indiquait que L2TP est transporté par UDP/IP,
et que ce beau monde avait un entête global de 40 octets.

Comme la liaison EAS (France Telecom) - FAI se fait par Ethernet, et que
c'est le FAI qui "termine" le tunnel, il y a au moins un endroit où le MTU
est limité à 1500 (Ethernet) - 40 (L2TP+UDP+IP).

Puisque ce MTU à 1460 est optimal, que des paquets plus grands sont
forcément fragmentés (d'abord inclus dans le tunnel, puis c'est le paquet
L2TP qui est fragmenté ?), un serveur, entre le BAS et le FAI, force à 1460
(vous : 1440) l'info MTU qui est échangé dans les premiers paquets de toute
connexion TCP/IP.

Si les paquets "utilisateurs" sont d'abord encapsulés dans L2TP, puis que
c'est le protocole L2TP qui se charge de fragmenter, la fragmentation n'est
pas visible pour les paquets utilisateurs. Un paquet UDP/IP ou ICMP/IP
passera dans le tunnel sans fragmentation apparente, alors qu'il a bel et
bien été fragmenté dans le trajet !

Par la surveillance des options MSS des paquets de synchronisation TCP/IP,
on améliore légèrement les débits dans les utilitaires de stats, et on
diminue le traffic dans la liaison BAS-FAI (fragmenter signifie multiplier
par 2 au moins le nombre de paquets L2TP/UDP/IP, 40 (60?) octets d'en-tête
de gaspillés chaque fois !)

Ah, si quelqu'un bossant dans les réseaux internes de ces opérateurs pouvait
donner la bonne explication... Je ne fais que des hypothèses !

--
Herm

Bart wrote:

Une question: le MTU à 1440 donné par http://www.dslreport.com/tweaks
il l'a bien sorti de quelque part, mais d'ou ?
Pourquoi je trouve pas ca, moi, avec mes pings ?

Eh bien, j'ai le même phénomène que vous, sur ligne FT. Le ping passe
bien,

même jusqu'à 1500 (via routeur PPPoA), mais avec un sniffer Ethernet, en
analysant les premières trames échangées de connexions TCP/IP, "quelque
chose" sur le réseau remplace la valeur 1500 par 1460 (chez moi).

C'est cette valeur que remonte dslreports. Il ne fait pas le test du plus
gros ping sans fragmentation.

Ceux qui utilisent Wanadoo sur ligne France Telecom n'ont pas cette limite
à

1460, ils peuvent exploiter jusqu'à 1500 sans problème.

La différence ? Etant Club-Internet, ma connexion transite pas les
équipements de France Telecom dans un tunnel L2TP, alors que Wanadoo
utilise

les équipements France Telecom en IP "natif".

Une doc trouvée sur Internet indiquait que L2TP est transporté par UDP/IP,
et que ce beau monde avait un entête global de 40 octets.

Comme la liaison EAS (France Telecom) - FAI se fait par Ethernet, et que
c'est le FAI qui "termine" le tunnel, il y a au moins un endroit où le MTU
est limité à 1500 (Ethernet) - 40 (L2TP+UDP+IP).

Puisque ce MTU à 1460 est optimal, que des paquets plus grands sont
forcément fragmentés (d'abord inclus dans le tunnel, puis c'est le paquet
L2TP qui est fragmenté ?), un serveur, entre le BAS et le FAI, force à
1460

(vous : 1440) l'info MTU qui est échangé dans les premiers paquets de
toute

connexion TCP/IP.

Si les paquets "utilisateurs" sont d'abord encapsulés dans L2TP, puis que
c'est le protocole L2TP qui se charge de fragmenter, la fragmentation
n'est

pas visible pour les paquets utilisateurs. Un paquet UDP/IP ou ICMP/IP
passera dans le tunnel sans fragmentation apparente, alors qu'il a bel et
bien été fragmenté dans le trajet !

Par la surveillance des options MSS des paquets de synchronisation TCP/IP,
on améliore légèrement les débits dans les utilitaires de stats, et on
diminue le traffic dans la liaison BAS-FAI (fragmenter signifie multiplier
par 2 au moins le nombre de paquets L2TP/UDP/IP, 40 (60?) octets d'en-tête
de gaspillés chaque fois !)

Ah, si quelqu'un bossant dans les réseaux internes de ces opérateurs
pouvait

donner la bonne explication... Je ne fais que des hypothèses !

--
Herm

Oui, tout ca tient la route.

Si le L2TP est bien au-dessus de UDP/IP, on a entre le LNS (coté FAI) et le
BAS:

IP(2) / PPP / L2TP / UDP / IP(1)

Il peut ne pas y avoir fragmentation au niveau IP(2) mais fragmentation au
niveau IP(1), donc le paquet ICMP/IP(2) du ping avec le flag DF est
transmis, mais le LNS envoye quand même des instructions pour recevoir des
paquets plus petits pour éviter la fragmentation dans le tunnel.

Le MTU maximum au niveau IP(2) pour éviter la fragmentation au niveaux IP(1)
serait:
MTU(IP1) : 1500
- IP(1) header: 20 octets (minimum)
- UDP header: 8 octets
- L2TP header 6 octets (minimum)
- PPP header 2 octets
= 1500 - 36 = 1464 maximum.
Si on ajoute à cela quelques octects optionnels on arrive facilement à 40
octets voire plus suivant les configurations.


J'ai relevé quelques lien au passage:

L2TP-over-IP Path MTU Discovery (''L2TPMTU''):
http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-pppext-l2tpmtu-00.txt
Pas très digeste. C'est un draft de 98. Je n'est pas trouvé de RFC officiel
sur le sujet.

http://www.networksorcery.com/enp
voir par exemple http://www.networksorcery.com/enp/protocol/l2tp.htm

Et bien sur, les références:
http://www.faqs.org/rfcs/rfc2661.html (L2TP)
http://www.faqs.org/rfcs/rfc1661.html (PPP)
http://www.faqs.org/rfcs/rfc3437.html (L2TP Extensions for PPP LCP
Negotiation)

J'ai quand même constaté des choses bien curieuses sur mon accès ADSL:

Si je ping n'importe quelle adresse sur internet avec l'option -f (don't
frangment), le comportement du LNS sur le TTL du paquet ICMP sortant (ECHO
REQUEST) dépend de la taille du paquet:
- si taille < ou = 1434+28, soit 1462, le TTL est diminué de 1 en traversant
le LNS (comme pour n'importe quel routeur)
- si taille > 1462, le TTL n' EST PAS diminué de 1.

Je détermine cela un utilisant l'option -i de ping (qui fixe le TTL initiale
du paquet) et bien sur les options -f et -l

Dans le cas d'un paquet entrant (réponse au ping) le comportement du LNS
dépend aussi de la taille du paquet, mais pas de la même manière:
- si taille < ou = 1464, le TTL n' EST PAS diminué en traversant le LNS
- si taille > 1464, le TTL est diminué de 1

Cela signifie qu'il se passe quelque chose pour des tailles de paquets >
1462 dans le cas d'un paquet sortant, et > 1464 pour un paquet rentrant.
Et si ce "quelque chose" était justement ... une fragmentation au niveau
IP(1) dans le tunnel ?

Ca voudrait dire que le MTU sans fragmentation dans le tunnel est: dans un
sens: 1462, dans l'autre sens: 1464.
Soit des overheads de 36 et 38 octets respectivement.

Et si l'effet sur le TTL était justement un "truc" utilisé par le LNS pour
signaler s'il y a fragmentation ou non dans le tunnel ?

L'info MTU échangée lors d'une connection TCP et rapportée par dslreports
n'est sans doute qu'une limite inférieure fixée dans la configuration du LNS
pour évité la fragmentation dans dans le pire cas avec l'overhead maximum,
mais n'est peut-être pas la limite réelle à laquelle se produit la
fragmentation.

Bien sur, tout ca n'est que pure spéculation !


Bart

Essayez de régler votre MTU sur 1400, ça devrait correspondre pile avec 30
cellules ATM et pourrait même améliorer légèrement le débit. En tous les
cas, de préférence, fixez un MTU <= à 1440, ça ne pourra qu'aider votre
connexion.

deuxième lecture enfin je viens de comprendre. Bravo parce que c'est pas
évident à expliquer. Mais en fait le gain est assez faible, en gros une
vingtaine d'octet puisque dans l'exemple en gros on gagne qu'un paquet
au total. Par contre en terme de fiabilité de liaison, on y gagne, à
condition que les liens soit d'assez mauvaise qualité par contre ;-)

Merci pour le lien ! Instructif sur les limites internes de LDCom...

de rien c'est un plaisir ;-)

Bart wrote:

[Remarques TTL]

J'ai essayé moi aussi de voir ce qui ce passe avec le TTL... Mais je ne vois
rien !

Comme je passe par un routeur, il me masque le TTL du réseau ADSL, et
m'affiche en permanence 254 dans les pings ! (255 - 1 hop de liaison
routeur - PC)...

Si un jour je repasse en mode Bridge PPPoE, je referais les tests ;-)

Bizarre en effet... Je ne vois pas pourquoi le TTL serait influencé par le
fait qu'un paquet a dû être encapsulé dans un autre protocole puis scindé en
deux ...

--
Herm

Je me suis enfin décidé a installer in sniffeur (WinDump). Pas si compliqué
finalement. Et j'ai encore découvert des choses:

Tout d'abord, si je ping avec l'option -f (flag DF) certains
serveurs/routeurs conservent le flag DF dans la réponse, mais la plupart
l'enlèvent.
A ce propos, la RFC 792 ne précise pas explicitement s'il faut le garder ou
l'enlever. Existe-t-il une recommendation officielle à ce sujet ? Je n'ai
rien trouvé.

Si le flag DF est conservé, la réponse ne me parvient pas si taille du
paquet IP > 1436+2864
Si le flag DF est enlevé, la réponse me parvient mais elle est fragmentée
(vérifié avec windump)

Donc:
Le MTU dans le sens aller est: 1492
Le MTU dans le sens retour est: 1464

Remarque: a l'aller, il y a surement fragmentation au niveau IP inférieur
sous L2TP entre le BAS et le LNS a partir d'une certaine taille de paquet.
Au retour, la fragmentation au niveau supérieur devrait éviter la
fragmentation au niveaux inférieur.

J'ai vérifié en pinguant un autre connecté ADSL chez tele2 que je recois
bien un message ICMP "fragmentation needed..." de son LNS avec une taille >
1464.
J'ai vérifié aussi que le TTL de sa réponse dépend de la taille du paquet
echo reply (c'est à dire pas diminué de 1 en traversant le LNS si taille >
1462) donc même phénomène que pour les paquets emis de chez moi.

Enfin, si j'intercale mon routeur NAT, il ne me transmet pas les paquets
echo reply fraqmentés qu'il recoit ! D'ou le black-hole quelque soit le
serveur/routeur pingué avec des tailles de paquets > 1464, même sans le flag
DF !
Serait-il incapable de recevoir le moindre paquet fragmenté ? Si c'est ca,
quelle daube ce routeur ! Ca expliquerait des problèmes que j'ai eu avec lui
en utilisant VPN/Ipsec pour me connecter au boulot. (pb pour accèder à des
fichiers via netbios, pb sur certaines pages web avec des images gif, ...)
Ces pb, je les ai d'ailleurs résolus en abaissant le MTU de la connexion
VPN. Maintenant, ca marche nickel, même avec le routeur NAT.

Voila voila ... Certains doivent se demander pourquoi je me casse la tête
avec toutes ces c...ries. C'es vrai, on a pas besoin de tout ca pour surfer
en paix. J'aime bien comprendre comment ca marche, c'est tout.

Bart

J'ai essayé moi aussi de voir ce qui ce passe avec le TTL... Mais je ne
vois

rien !

Comme je passe par un routeur, il me masque le TTL du réseau ADSL, et
m'affiche en permanence 254 dans les pings ! (255 - 1 hop de liaison
routeur - PC)...

Je confirme:

Essai de ping sur un abonné club-internet sur le même LNS que vous:
- paquet sortant (de club-internet): TTL pas modifié par LNS si taille >
1462

Si ping avec taille > 1464 -> black-hole. (pas de réponse ni message
"fragmentation needed"du LNS). Donc peut-etre qu'il n'y a pas de
fragmentation apparente pour vous pour les paquets > 1464, à la différence
de télé2. Je ne peux pas le vérifier d'ici.