<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Salut,<br>
<br>
Le 12/11/2011 14:54, Jocelyn Delalande a écrit :
<blockquote cite="mid:4EBE7AB0.4060605@etu.utc.fr" type="cite">Salut,
<br>
<blockquote type="cite">Avec la fragmentation des paquets il ne
devrait plus y avoir de
<br>
problème de MTU/MSS entre le client et serveur, théoriquement
devrait
<br>
même accepter
<br>
un MTU > 1500 (a tester).
<br>
</blockquote>
<br>
<br>
Prenons un cas concret, un programme veut transmettre via TCP 2000
octets sur une interface TUN
<br>
<br>
<br>
1) Cas avec une MTU volontairement plus faible (ex: 1400) sur
l'interface TUN (sans frag. de la part de linkagreg) :
<br>
<br>
- TCP découpe les données en 2 segments et les passe à la couche
IP ;
<br>
- les 2 paquets sont lus par l'application de tunnel et sont
injectés dans le tunnel UDP, la pile réseau rajoute tous ses
headers (UDP+IP+MAC);
<br>
- vu qu'on a choisi une MTU volontairement plus faible pour le
tun, lorsque la pile réseau envoie ces paquets encapsulés via
l'interface physique, ils ne sont pas redécoupés une fois de plus.
2 trames seulement sortent par l'interface réseau
<br>
<br>
<br>
2) Cas où linkagreg gère la fragmentation et où l'on laisse la MTU
du tun à 1500
<br>
<br>
- TCP découpe son flux le paquets en 2 segments et les passe à la
couche IP ;
<br>
- les 2 paquets sont lus par l'application de tunnel, le premier
est découpé en 2. Les 3 paquets obtenus sont injectés dans le
tunnel UDP, la pile réseau rajoute tous ses headers (UDP+IP+MAC);
<br>
- la non plus, vu que le tunnel gère la fragmentation, aucune
fragmentation supplémentaire n'est faite pour transmettre le
paquet sur l'interface physique.
<br>
<br>
Ce dont je ne suis pas convaincu là c'est que pour moi
<br>
- si on set la MTU du tun/tap correctement, on transmet 2 paquets
<br>
- si on utilise de la fragmentation, on transmet 3 paquets, et on
ajoute un délai/coût de traitement/source d'erreurs.
<br>
<br>
On peut y voir une question de vitesse (on splite les gros paquets
pour les envoyer en parallèle). Ceci-dit entre ça et faire la
répartition paquet/paquet, je ne suis pas persuadé que le bénéfice
soit énorme, et je suppose qu'il est négatif lorsque le lien est
chargé ou qu'il y a des écarts de latence entre les deux liens.<br>
</blockquote>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8">
<title></title>
<meta name="GENERATOR" content="LibreOffice 3.4 (Linux)">
<style type="text/css">
<!--
@page { margin: 2cm }
P { margin-bottom: 0.21cm }
--></style>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8">
<title></title>
<meta name="GENERATOR" content="LibreOffice 3.4 (Linux)">
<style type="text/css">
<!--
@page { margin: 2cm }
P { margin-bottom: 0.21cm }
--></style>tu as raison pour TCP.<br>
<br>
Sur notre réseau aujourd'hui les 5 liens ppp montés sur la Gateway
ont une MTU de 1462 alors que tout le reste du réseau local a une
MTU de 1500 (valeur par défaut des routeurs et poste des adhérents),
et avec la mise en place d'un tunnel sans fragmentation je vais
encore devoir réduire cette MTU, j'ai peur que certaines
applications qui n'utilisent pas TCP se retrouvent avec des
problèmes de MTU.<br>
<br>
alix:~# ip link | grep ppp
<br>
83: ppp2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1462
qdisc htb state UNKNOWN qlen 3
<br>
link/ppp
<br>
124: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1462
qdisc htb state UNKNOWN qlen 3
<br>
link/ppp
<br>
144: ppp4: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1462
qdisc htb state UNKNOWN qlen 3
<br>
link/ppp
<br>
153: ppp3: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1462
qdisc htb state UNKNOWN qlen 3
<br>
link/ppp
<br>
155: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1462
qdisc htb state UNKNOWN qlen 3
<br>
link/ppp
<br>
<br>
Un autre avantage aussi de la fragmentation c'est que l'on diminue
le temps de latence des gros paquets.<br>
<br>
alix:~# ping -s 1400 -I ppp4 <a class="moz-txt-link-abbreviated" href="http://www.fdn.fr">www.fdn.fr</a>
<br>
PING yoda.fdn.fr (80.67.169.18) from 80.67.176.237 ppp4: 1400(1428)
bytes of data.
<br>
1408 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=1 ttl=61
time=64.8 ms
<br>
1408 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=2 ttl=61
time=63.2 ms
<br>
1408 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=3 ttl=61
time=63.6 ms
<br>
1408 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=4 ttl=61
time=63.1 ms
<br>
<br>
alix:~#
<br>
alix:~# ping -s 700 -I ppp4 <a class="moz-txt-link-abbreviated" href="http://www.fdn.fr">www.fdn.fr</a>
<br>
PING yoda.fdn.fr (80.67.169.18) from 80.67.176.237 ppp4: 700(728)
bytes of data.
<br>
708 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=1 ttl=61
time=56.2 ms
<br>
708 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=2 ttl=61
time=55.8 ms
<br>
708 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=3 ttl=61
time=55.6 ms
<br>
708 bytes from yoda.fdn.fr (80.67.169.18): icmp_seq=4 ttl=61
time=56.3 ms
<br>
<br>
L’inconvénient c'est que l'on diminue un peu le débit max des liens.<br>
<br>
Je verrai bien lors des tests, j'ai prévu que la fragmentation des
paquets soit une option activable/désactivable.<br>
<br>
A+<br>
Fernando<br>
<br>
<blockquote cite="mid:4EBE7AB0.4060605@etu.utc.fr" type="cite">
<br>
Je ne demande qu'à être convaincu ceci-dit, quelque-chose
m'échappe sûrement :-)
<br>
<br>
Bonne journée,
<br>
<br>
Jocelyn
<br>
<br>
<blockquote type="cite">
<br>
Exemple:
<br>
1) coté serveur le "network Kernel" écrit un paquet de 1500
octets sur
<br>
l'interface tun/tap créé par linkagreg,
<br>
2) linkagreg lit ce paquet de 1500 octets le divise en 2
<br>
(2*(750+header linkagreg)) et les transmets a travers 2 tunnel
UDP a
<br>
l'appli linkagreg coté client.
<br>
3) coté client linkagreg reçoit 2 paquets de 750 octets + header
<br>
linkagreg, il ré-assemble ces 2 paquets en un paquet de 1500
octet et
<br>
l’écrit sur l'interface tun/tap qu'il a créé.
<br>
</blockquote>
<br>
Quel est le bénéfice réel de couper tous les paquets en 2 ?
<br>
<br>
<blockquote type="cite">
<br>
Coté client et serveur le "network Kernel" pense avoir à faire à
une
<br>
interface de 1500 octets de MTU (comme pour une interface
ethernet).
<br>
<br>
<a class="moz-txt-link-freetext" href="http://irp.nain-t.net/doku.php/140pppoe:070_mtu_mss_etc">http://irp.nain-t.net/doku.php/140pppoe:070_mtu_mss_etc</a>
<br>
</blockquote>
Bon lien, merci :) Ok pour le PMTU qui se foire dans la plupart
des cas à cause du filtrage d'ICMP. J'avais oublié ce point.
<br>
<br>
<br>
<blockquote type="cite">
<br>
Fernando
<br>
<br>
<blockquote type="cite">
<br>
<br>
Jocelyn
<br>
<br>
<br>
<blockquote type="cite">
<br>
<br>
si vous voulez essayer, voila comment je l'utilise:
<br>
<br>
##############################
<br>
# VM Serveur eth0= 192.168.1.1
<br>
##############################
<br>
*./linkagreg -s -d -i tun10&
<br>
ip addr add 10.0.0.1/24 dev tun10
<br>
ip link set up dev tun10*
<br>
<br>
##############################
<br>
# VM Client eth0=192.168.1.2
<br>
# eth1=192.168.1.3
<br>
# ouverture de 2 tunnel UDP:
<br>
# 192.168.1.2<--> 192.168.1.1
<br>
# 192.168.1.3<--> 192.168.1.1
<br>
##############################
<br>
*./linkagreg -c 192.168.1.1 -f 192.168.1.2,192.168.1.3 -d -i
tun10&
<br>
ip addr add 10.0.0.2/24 dev tun10
<br>
ip link set up dev tun10
<br>
*
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>