Re: Probleme de MTU

トップ ページ

このメッセージに返信
著者: malet jean-luc alias cityhunter
日付:  
To: Jérôme Kieffer
CC: guilde
題目: Re: Probleme de MTU
Jérôme Kieffer a écrit :

>Le Thu, 01 Sep 2005 20:23:27 +0200
>JLM aka cityhunter <jlm_devel@???> a écrit:
>
>
>
>>Jérôme Kieffer wrote:
>>
>>
>>
>>>Salut,
>>>sur un de mes routeur, le lien à un MTU de 1460 au lieu de 1500.
>>>Visiblement ce MTU est négocié, ce qui fait planter les machines qui
>>>doivent être routées :
>>>
>>>19:23:30.663018 IP routeur > windows: icmp 556: mail.tele2.fr
>>>unreachable - need to frag (mtu 1460) q19:23:41.827878 IP windows.1311
>>>
>>>
>>>
>>>
>>>>mail.tele2.fr.smtp: . 0:1460(1460) ack 1 win 65249 19:23:41.827985 IP routeur > windows: icmp 556: mail.tele2.fr unreachable - need to frag (mtu 1460)
>>>>
>>>>
>>>>
>>>>
>>>Question : faut il mieux essayer de modifier le MTU de toutes les
>>>machines du reseau (avec le serveur DHCP ?) ou est ce que c'est au
>>>kernel de fragmenter les paquets ?
>>>
>>>Merci & A++
>>>
>>>
>>>
>>>
>>>
>>c' est amusant..... t'utiliserai pas pppoa? par hazard....
>>
>>
>
>si c'est une carte PCI, donc ATM et je trouve normal d'utiliser le PPPoa
>

l'atm ne semble pas une solution viable sous linux.... de toute manière
que tu utilise du pppoa ou pppoe tu sais pourquoi le mtu change par
rapport au mtu 1500? ben parceque 1500-1460=40=overhead introduit par le
pppoa.
1500-1492=8=overhead introduit par pppoe....
faut se méfier des fausse bonnes idée introduite par la pub.... pppa
introduit le concept de "qualité de service" par réservation de la BP
mais cela a un coup.... surtout que la qualité de service..... passé
l'AP de ton provider... ben pouf à la poubelle....
passe en pppoe cela t'emerdera moins....
de toute manière TOUT les équipement adsl sont ATM.... hors 80% des
utilisateurs utilisent pppoe... faut bien voir cela, si ATM/pppoa n'est
pas/peu utilisé c'est peut être parceque tout le monde a eu le mm pb que
toi... en plus les "pppox" ne sont que de l'encapsulation : pppox ajoute
au paquet entrant une entête, puis transmet à destination du
périphérique (pci ou ethernet) qui enlève l'entête (là je suis pas sur,
je pense mm que non, l'entête reste), rajoute la sienne (ca c'est sûr)
et transmet en face.... donc utiliser du pppoe ou du pppoa c'est pareil
mis a part que pppoe essaie d'envoyer à la couche ethernet et pppoa à la
couche atm.... si ton périph supporte les deux l'un ou l'autre c'est
blanc bonnet et bonnet blanc sauf que pppoa cela marche pas avec le nat....

>
>ce que j'ai pas apprécié, c'est qut tele2 baisse le MTU comme cela,
>sans prévenir.
>

le MTU devais déjà être comme cela, mais tu ne t'en étais pas rendu
comptre.... on a mis 4 mois avant de s'appercevoir que certains sites ne
marchaient pas.... tout le reste semblait ok

>
>
>Pour info, l'option :
>option interface-mtu 1460;
>de dhcpd fonctionne bien .... mais elle ne fonctionnera pas si tele2
>passe a 1450.
>

c'est bien le pb..... si tu veux être sur t'as qu'à mettre interface-mtu
100 et là cela marchera sans doute toujours..... mais tu pénalise tout
ton réseau local....
bref essaie pppoe si tu peux (si ton driver le permet) cela t'emmerdera
moins.....

>
>La fragmentation des paquets est sans doute plus "bullet-proof" meme si
>elle dégrade probablement les perfs.
>

le pb c'est que la fragmentation des packets ne semblent pas fonctionner
avec ATM/pppoa (je ne sais pas pourquoi....) il y a un pb avec ceci
de toute manière le paquet est fractionné que ce soit en pppoe ou pppoa
: un packet arrive du réseau local (mtu 1500) passage dans les
différente couches réseau, envoi à pppoe, coupage de packet au passage
pour pouvoir faire tenir son en-tête (passage au mtu 1492) puis envoie
sur ethernet (de nouveau mtu1500) la différence entre les 2mtu te montre
l'overhead du protocole
@+
JL

(au passage un overhead de 40 contre 8 c'est quand mm 5 fois plus.....
quite à ne pas avoir de qualité de service [concept stupide vu le
fonctionnement du net], qui, de toute manière tu n'aura pas, je préfère
éviter de gaspiller 5 fois plus de BP....