Et si on reparlait de MTU

Support Debian
#1

Salut,
Il y a tout et son contraire sur le sujet.
Je suis chez SFR et sur l’interface SFRBOX il y a ça:
Protocole Mix (PPPoE + DHCP)

Essayant d’utiliser ce post http://www.bortzmeyer.org/mtu-et-mss-sont-dans-un-reseau.html
j’arrive à ça:

[code]@desktop:~$ sudo ifconfig -a
[sudo
eth0 Link encap:Ethernet HWaddr
inet adr:192.168.1.24 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::216:ecff:fe9f:839a/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1482 Metric:1
RX packets:4352 errors:0 dropped:0 overruns:0 frame:0
TX packets:3340 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:5692436 (5.4 MiB) TX bytes:288249 (281.4 KiB)
Interruption:20

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:86 errors:0 dropped:0 overruns:0 frame:0
TX packets:86 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:23560 (23.0 KiB) TX bytes:23560 (23.0 KiB)

@desktop:~$ ping -s 1454 www.sfr.fr
PING www.sfr.fr (80.125.163.172) 1454(1482) bytes of data.
1462 bytes from 80.125.163.172: icmp_seq=1 ttl=246 time=50.0 ms
1462 bytes from 80.125.163.172: icmp_seq=2 ttl=246 time=61.4 ms
1462 bytes from 80.125.163.172: icmp_seq=3 ttl=246 time=46.2 ms
1462 bytes from 80.125.163.172: icmp_seq=4 ttl=246 time=47.6 ms
1462 bytes from 80.125.163.172: icmp_seq=5 ttl=246 time=48.5 ms
1462 bytes from 80.125.163.172: icmp_seq=6 ttl=246 time=45.4 ms
1462 bytes from 80.125.163.172: icmp_seq=7 ttl=246 time=45.9 ms
1462 bytes from 80.125.163.172: icmp_seq=8 ttl=246 time=46.4 ms
^C
— www.sfr.fr ping statistics —
8 packets transmitted, 8 received, 0% packet loss, time 7010ms
rtt min/avg/max/mdev = 45.460/48.975/61.442/4.926 ms
@desktop:~$ ping -s 1455 www.sfr.fr
PING www.sfr.fr (80.125.163.172) 1455(1483) bytes of data.
^C
— www.sfr.fr ping statistics —
7 packets transmitted, 0 received, 100% packet loss, time 5999ms

[/code]

Alors ma valeur 1454+28= 1482 pour MTU a-t-elle du sens?
Qu’en pense M Pascal Hambourg qui est cité dans la page susdite?

#2

Quel est le but de la manoeuvre ? Est-ce pour compenser un dysfonctionnement constaté ?

Ouh ! Ça nous rajeunit pas, cette page.

#3

De toutes les manières, si c’est pour trouver la MTU, il faut configurer l’option Don’t Fragment (DF) des en-têtes IP à 1.

Par exemple :

[code]~$ ping -n -c 2 -M do -s 1428 www.perdu.com
PING www.perdu.com (208.97.177.124) from 217.128.214.xxx : 1428(1456) bytes of data.
1436 bytes from 208.97.177.124: icmp_req=1 ttl=51 time=121 ms
1436 bytes from 208.97.177.124: icmp_req=2 ttl=51 time=120 ms

— www.perdu.com ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 120.982/121.454/121.927/0.587 ms[/code]

[code]~$ ping -n -c 2 -M do -s 1429 www.perdu.com
PING www.perdu.com (208.97.177.124) from 217.128.214.xxx : 1429(1457) bytes of data.
From 217.128.214.xxx icmp_seq=1 Frag needed and DF set (mtu = 1456)
From 217.128.214.xxx icmp_seq=1 Frag needed and DF set (mtu = 1456)

— www.perdu.com ping statistics —
0 packets transmitted, 0 received, +2 errors[/code]

–
AnonymousCoward

#4

A priori pour PPPoE MTU doit être de 1492.
http://www.speedguide.net/analyzer.php

#5

C’était vrai.

La RFC 4638 est passée par là, où l’on peut spécifier une option “PPP-Max-Payload” au niveau de PPPoE pour avoir une MTU/MRU plus importante que 1492 octets.

Mais le paquet pppoe de Debian contient en fait le logiciel rp_pppoe, qui ne gère pas cette option / cette RFC.
Il existe au moins 5 autres logiciels utilisables sous linux pour faire du PPPoE mais j’avoue ne pas les avoir testé.

J’ai déjà rencontré cette option en production sur le réseau d’un des principaux FAI français. Et elle s’est d’ailleurs révélée assez problématique.

–
AnonymousCoward

#6

Cela concerne le lien PPPoE. Pas forcément les machines qui envoient des paquets à travers. Par des mécanismes comme la fragmentation ou Path MTU Discovery, en principe TCP/IP sait très bien gérer le passage par des liens de MTU différents sans qu’il soit nécessaire que toutes les machines du monde connectées à internet adoptent la plus petite MTU qui existe sur le net.

Donc je répète ma question : quel est le but de la manoeuvre ?

A condition que les deux côtés (client et concentrateur PPPoE) 1- le supportent et 2- en tiennent réellement compte (contrairement à certains BAS à ce qu’on m’a rapporté, peut-être du FAI auquel tu fais allusion).

Aucune importance, généralement on n’utilise pas le client userland du paquet pppoe mais le module intégré au noyau. J’ignore si le module du noyau supporte l’option.

De toute façon, cela ne concerne que l’équipement qui termine la connexion PPPoE, donc ici la box.

#7

Le but c’est de simplement faire au mieux pour la connexion internet du PC en Ethernet sous Debian Jessie connecté a une box SFR
Pourquoi y a t il une limite à 1454 bytes + 8 soit 1462 bytes ?

[code]root@desktop:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr
inet adr:192.168.1.24 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::216:ecff:fe9f:839a/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:89 errors:0 dropped:0 overruns:0 frame:0
TX packets:115 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:11459 (11.1 KiB) TX bytes:43041 (42.0 KiB)
Interruption:20

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:103 errors:0 dropped:0 overruns:0 frame:0
TX packets:103 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:24912 (24.3 KiB) TX bytes:24912 (24.3 KiB)

root@desktop:~# ping -s 1454 www.sfr.fr
PING www.sfr.fr (80.125.163.172) 1454(1482) bytes of data.
1462 bytes from 80.125.163.172: icmp_seq=1 ttl=246 time=48.8 ms
1462 bytes from 80.125.163.172: icmp_seq=2 ttl=246 time=46.0 ms
1462 bytes from 80.125.163.172: icmp_seq=3 ttl=246 time=46.6 ms
1462 bytes from 80.125.163.172: icmp_seq=4 ttl=246 time=50.4 ms
1462 bytes from 80.125.163.172: icmp_seq=5 ttl=246 time=60.4 ms
1462 bytes from 80.125.163.172: icmp_seq=6 ttl=246 time=45.6 ms
1462 bytes from 80.125.163.172: icmp_seq=7 ttl=246 time=49.5 ms
1462 bytes from 80.125.163.172: icmp_seq=8 ttl=246 time=47.3 ms
1462 bytes from 80.125.163.172: icmp_seq=9 ttl=246 time=53.1 ms
1462 bytes from 80.125.163.172: icmp_seq=10 ttl=246 time=47.3 ms
1462 bytes from 80.125.163.172: icmp_seq=11 ttl=246 time=46.7 ms
^C
— www.sfr.fr ping statistics —
11 packets transmitted, 11 received, 0% packet loss, time 10015ms
rtt min/avg/max/mdev = 45.629/49.289/60.414/4.113 ms
root@desktop:~# ping -s 1455 www.sfr.fr
PING www.sfr.fr (80.125.163.172) 1455(1483) bytes of data.
^C
— www.sfr.fr ping statistics —
9 packets transmitted, 0 received, 100% packet loss, time 8064ms[/code]

#8

bonjour

dans les paramètres de ma box orange il y a écrit:

[code]bonjour.
le mtu semble géré par la box;chez moi dans les paramètres de la livebox il y a écrit:

[code]informations système

3.1
statut de la connexion Internet
connecté
3.2
nom d'utilisateur
xxxxxxxxxx
3.3
dernière connexion
3 décembre 2015, 08 h 42 m
3.4
durée de la connexion
01 j 08 h 43 m 21 s
3.5
type du protocol
ppp
3.6
code d'erreur de la dernière connexion
ERROR_NONE
3.7
date de la dernière connexion
3.8
ATM VP/VC ou VLAN
8/35
3.9
taille MTU
1492
3.10
adresse IPv4 WAN
xxxxxxxxxx
3.12
adresse IP du DNSv4 primaire
80.10.246.3
3.13
adresse IP du DNSv4 secondaire
81.253.149.1[/code]

[/code]

taille mtu=1492

#9

En complément de réponse à AnonymousCoward :
Je n’ai rien trouvé dans le module pppoe du noyau, mais dans le plugin rp-pppoe de pppd (paquet Debian ppp), qui utilise le module du noyau pppoe :
http://git.ozlabs.org/?p=ppp.git;a=commit;h=fd1dcdf758418f040da3ed801ab001b5e46854e7

[quote]rp-pppoe: allow MTU to be increased up to 1500

The ethernet data limit on rp-pppoe has been increased to 1508 to allow an MTU of 1500 to be used. To prevent problems the interface MTU is checked and used to lower the configured MTU/MRU.

If MIN(MTU/MRU) is > 1492, PPP-Max-Payload is added to PADI and PADR. If PPP-Max-Payload is received in PADO or PADS, it will be used to lower the configured MTU/MRU as required.

The MTU/MRU settings are stored and reloaded whenever a connection is made, to allow for the peer or interface MTU/MRU to increase if used with persist option.

Conforming to RFC4638, if no PPP-Max-Payload is received, the negotiated MRU will be limited to 1492.[/quote]
Ce changement a été introduit dans la version 2.4.6 de pppd qui est incluse dans Debian Jessie. L’ancienne stable Wheezy contient par contre la version 2.4.5 qui n’inclut pas encore ce changement.

#10

oui ma box SFR est en mode routeur donc c’est elle qui prends le dessus sur les réglages que je peux faire dans Debian

#11

[quote=“PascalHambourg”]En complément de réponse à AnonymousCoward :
Je n’ai rien trouvé dans le module pppoe du noyau, mais dans le plugin rp-pppoe de pppd (paquet Debian ppp), qui utilise le module du noyau pppoe :
http://git.ozlabs.org/?p=ppp.git;a=commit;h=fd1dcdf758418f040da3ed801ab001b5e46854e7
…
Ce changement a été introduit dans la version 2.4.6 de pppd qui est incluse dans Debian Jessie. L’ancienne stable Wheezy contient par contre la version 2.4.5 qui n’inclut pas encore ce changement.[/quote]Merci pour l’info ! :smiley:

–
AnonymousCoward

#12

[quote=“grandtoubab”][code]…
root@desktop:~# ping -s 1454 www.sfr.fr
PING www.sfr.fr (80.125.163.172) 1454(1482) bytes of data.
1462 bytes from 80.125.163.172: icmp_seq=1 ttl=246 time=48.8 ms
1462 bytes from 80.125.163.172: icmp_seq=2 ttl=246 time=46.0 ms
…
^C
— www.sfr.fr ping statistics —
11 packets transmitted, 11 received, 0% packet loss, time 10015ms
rtt min/avg/max/mdev = 45.629/49.289/60.414/4.113 ms

root@desktop:~# ping -s 1455 www.sfr.fr
PING www.sfr.fr (80.125.163.172) 1455(1483) bytes of data.
^C
— www.sfr.fr ping statistics —
9 packets transmitted, 0 received, 100% packet loss, time 8064ms[/code][/quote]Au vu de cela, tu peux probablement imposer une MTU de 1482 octets (les bytes, je ne connais pas) sur l’interface réseau eth0 de ta machine.

C’est une solution ignoble pour un problème qui n’est pas de ta faute. Et c’est potentiellement à faire sur toutes les machines de chez toi à moins d’intercaler un routeur. Mais cela devrait marcher.

[quote=“grandtoubab”]Pourquoi y a t il une limite à 1454 bytes + 8 soit 1462 bytes ?[/quote]La limite est de 1482 octets. Quand on fait un ping, on ajoute la taille d’un entête ICMP standard de 8 octets plus la taille d’un entête IP standard de 20 octets. Soit 28 octets à ajouter.
D’ailleurs, dans tes tests avec ping, la commande t’indique bien la valeur 1482 entre parenthèses.

Pourquoi ton accès possède cette MTU un peu basse ? Il n’y a que SFR qui puisse te répondre.

Eventuellement, réessaye les commandes ping mais avec l’option -M do et regarde si tu reçois des messages “Frag needed and DF set”.
Auparavant, assures-toi que tu n’as pas de filtrage du protocole ICMP au niveau du pare-feu de ta machine.

–
AnonymousCoward

#13

ma box orange indique un mtu de 1492 mais “/sbin/ifconfig -a” indique un mtu de 1500,alors comment faut il comprendre tout ça?

#14

ma box orange indique un mtu de 1492 mais “/sbin/ifconfig -a” indique un mtu de 1500,alors comment faut il comprendre tout ça?[/quote]
1500 c’est la valeur de ton interface dans le PC mais ta box Orange impose 1492,

#15

ma box orange indique un mtu de 1492 mais “/sbin/ifconfig -a” indique un mtu de 1500,alors comment faut il comprendre tout ça?[/quote]
1500 c’est la valeur de ton interface dans le PC mais ta box Orange impose 1492,[/quote]

merci pour la réponse,c’est plus clair maintenant.