Qu'est ce qui rend nécessaire un changement de MTU ?

Le
Olivier
--f4030435d08cad83bf0560204159
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bonjour,

J'ai constaté il y quelques semaines sur un serveur distant sous Jessi=
e,
que mes connexions SSH et commandes scp étaient inexplicablement
perturbées: affichage bloqué dès que les données affich=
ées dépassaient un
certain volume.

Après recherches, il s'avère qu'en valorisant à 1472, le MTU=
(par une
commande "ifconfig eth0 mtu up"), les conséquences du problème on=
t disparu
(plus d'affichage SSH tronqué, scp OK).

J'aimerai comprendre ce qui s'est passé et ce qui a, en apparence, du
moins, rendu nécessaire ce changement de MTU.


Mon installation comprend:
Serveur Jessie <- Eth --> Commutateur

Le commutateur a l'adresse 192.168.1.231.
Depuis le serveur, j'avais:
ping -M do -s 1472 192.168.1.231 100% de réussite
ping -M do -s 1473 192.168.1.231 100% d'échec


Après une discussion très sommaire, avec le support du commutateu=
r, j'ai
compris:

A. que l'interface du serveur pouvait avoir un MTU différent de celui =
de
l'interface du commutateur, du moment que la valeur était inférie=
ure ou
égale.

B. que l'interface du commutateur est actuellement configurée avec un =
MTU
de 1500.

Mes questions sont:

1. Que pensez-vous de A ?

2. Pour quelle raison, ai-je un échec avec un "ping à 1473" ? Si=
j'en
crois l'interface du switch, je devrais pouvoir monter jusqu'à 1500, n=
on ?

3. Qui a déjà eu à modifier en urgence, soudainement, un tel=
paramètre ?
Dans quelles circonstances ?

Slts

--f4030435d08cad83bf0560204159
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div><div><div><div><div>Bonjour,<br><br></div>J&#39;ai co=
nstaté il y quelques semaines sur un serveur distant sous Jessie, que =
mes connexions SSH  et commandes scp étaient inexplicablement per=
turbées: affichage bloqué dès que les données affich=
es dépassaient un certain volume.<br><br></div>Après recherche=
s, il s&#39;avère qu&#39;en valorisant à 1472, le MTU (par une co=
mmande &quot;ifconfig eth0 mtu up&quot;), les conséquences du probl=
me ont disparu (plus d&#39;affichage SSH tronqué, scp OK).<br><br><=
/div>J&#39;aimerai comprendre ce qui s&#39;est passé et ce qui a, en a=
pparence, du moins, rendu nécessaire ce changement de MTU.<br><br><br>=
</div>Mon installation comprend:<br>Serveur Jessie &lt;- Eth --&gt; C=
ommutateur<br><br></div><div>Le commutateur a l&#39;adresse 192.168.1.231.<=
br></div><div>Depuis le serveur, j&#39;avais:<br></div><div>ping -M do -s 1=
472 192.168.1.231         =
      100% de réussite<br>ping -M do -s 14=
73 192.168.1.231         =
      100% d&#39;échec <br></div><div><br>=
<br></div><div>Après une discussion très sommaire, avec le suppor=
t du commutateur, j&#39;ai compris:<br></div><div><br>A. que l&#39;interfac=
e du serveur pouvait avoir un MTU différent de celui de l&#39;interfac=
e du commutateur, du moment que la valeur était inférieure ou =
gale.<br><br></div><div>B. que l&#39;interface du commutateur est actuel=
lement configurée avec un MTU de 1500.<br><br></div><div>Mes questions=
sont:<br><br></div><div>1. Que pensez-vous de A ?<br><br></div><div>2. Pou=
r quelle raison, ai-je un échec  avec un &quot;ping à 1473&q=
uot; ? Si j&#39;en crois l&#39;interface du switch, je devrais pouvoir mont=
er jusqu&#39;à 1500, non ?<br><br></div><div>3. Qui a déjà e=
u à modifier en urgence, soudainement, un tel paramètre ? Dans qu=
elles circonstances ?<br><br></div><div>Slts<br></div><div><br></div></div>

--f4030435d08cad83bf0560204159--
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #26455616
Le 12/12/2017 à 09:15, Olivier a écrit :
Après recherches, il s'avère qu'en valorisant à 1472, le MTU (par une
commande "ifconfig eth0 mtu up"), les conséquences du problème ont disparu
(plus d'affichage SSH tronqué, scp OK).
J'aimerai comprendre ce qui s'est passé et ce qui a, en apparence, du
moins, rendu nécessaire ce changement de MTU.

Un changement de MTU (diminution) le long du chemin et une mauvaise
gestion de la fragmentation et des messages ICMP "destination
unreachable - fragmentation needed but DF (don't fragmet flag) set".
Lorsqu'un routeur reçoit un paquet IPv4 qu'il doit router par une
interface de MTU inférieure à la taille du paquet, doit :
- si le paquet a le flag DF à 0, fragmenter le paquet et envoyer les
fragments par l'interface ;
- si le paquet a le flag DF à 1, écarter le paquet et renvoyer un
message d'erreur ICMP "destination unreachable - fragmentation needed
but DF set" annonçant la taille maximum à l'adresse source du paquet.
Les problèmes possibles sont nombreux :
- Le routeur écarte les paquets trop gros mais n'envoie pas de messages
ICMP, ou l'équipement où a lieu la baisse de MTU n'est pas un routeur
(exemple : concentrateur d'accès PPPoE ADSL qui n'est qu'un relais entre
un tunnel PPPoE et un tunnel L2TP).
- Les messages d'erreur ICMP sont filtrés en chemin par un firewall ou
ignorés par l'émetteur du paquet initial.
- les fragments sont filtrés en chemin par un firewall.
Les VPN et autres tunnels sont de gros pourvoyeurs de baisse de MTU
et/ou de fragmentation car l'encapsulation augmente la taille des paquets.
Publicité
Poster une réponse
Anonyme