Effectuez la découverte de MTU de chemin sans vous fier aux erreurs ICMP, qui ne sont souvent pas fournies.
Ce programme effectue la découverte MTU du chemin de couche de paquetage comme décrit dans la RFC 4821, qui constitue un moyen plus fiable de détecter la taille de la MTU en présence de trous noirs ICMP.
Si les connexions TCP ajustent automatiquement la taille du MTU au fil du temps en fonction de divers indicateurs (performances du réseau, perte de paquets, messages d'erreur ICMP, ...), ce n'est pas le cas des protocoles sans connexion.
Lorsque les performances sont essentielles, le débit , la fragmentation des paquets et la fiabilité des routes sont trois indicateurs clés à analyser afin d'optimiser les performances des flux. Étant donné que la fiabilité des routes ne dépend pas toujours de nous, nous devons nous efforcer de maximiser le débit sans procéder à une fragmentation des paquets , ce qui peut gravement dégrader les performances [1] .
La proposition originale pour la découverte de MTU de chemin reposait sur les paquets ICMP Fragmentation Needed
à livrer lorsqu'un paquet IPv4 avec le champ Ne pas fragmenter défini était trop volumineux pour être propagé. Malheureusement, certains routeurs ne génèrent pas ce type d’erreurs mais choisissent plutôt d’ignorer silencieusement les gros paquets. Un client n'a aucun moyen de déterminer la cause de la perte de paquets.
Étant donné que tous les hôtes sont obligés de prendre en charge les requêtes ICMP_ECHO, nous pouvons exploiter le fait que les messages ICMP acceptent une quantité arbitraire de données et envoient des paquets de différentes tailles à notre serveur. Si nous activons le champ Don't Fragment dans le paquet IPv4 et écoutons une réponse, nous attendons de facto un ACK (sous la forme d'un paquet ICMP_ECHOREPLY) confirmant que cette taille de MTU est valide.
Il ne reste plus qu'à effectuer une recherche binaire par rapport à la taille des paquets afin de trouver la taille MTU maximale supportée par cette route.
En mode ICMP, certaines requêtes ICMP_ECHO de différentes tailles sont générées.
ICMP Fragmentation Needed
), cette taille de MTU est déclarée invalide et le seuil est abaissé.La seule exigence du mode ICMP est que l'hôte doit être capable de répondre aux messages ping.
Le même algorithme s'applique aux paquets UDP, mais vous devez exécuter un serveur ( udp_server.py ) sur votre hôte de réception afin de renvoyer des messages d'accusé de réception.
Ce programme devrait fonctionner correctement sur la plupart des distributions Linux et OSX.
gcc -Wall -Wextra mtu_discovery.c mtu.c -o plpmtu
Il ne doit pas signaler les avertissements/erreurs. Si tel est le cas, veuillez ouvrir un problème.
Si vous souhaitez exécuter en mode ICMP, tapez :
sudo ./plpmtu -p icmp -s <server-ipaddr>
Si vous souhaitez plutôt exécuter le mode UDP :
sudo ./plpmtu -p udp -s <server-ipaddr:port>
Des droits d'administrateur sont requis pour utiliser les sockets bruts.
Spécificateur | Description |
---|---|
-p {icmp/udp} | Sélectionnez dans quel mode fonctionner. |
-s <adresse[:port]> | Spécifiez l'adresse du serveur. Si vous utilisez le mode UDP, vous devez également spécifier le port de destination en ajoutant ':port' (par exemple -s 8.8.8.8:12345 ) |
-l <adresse:port> | Facultatif. Sélectionnez à quelle adresse lier (); utilisé en mode UDP ; pourrait être supprimé. |
-t <délai> | Facultatif. Sélectionnez le temps maximum d'attente d'une réponse du serveur, la valeur par défaut est 1 seconde ; le temps est exprimé en millisecondes. |
-r <max-reqs> | Facultatif. Sélectionnez le nombre maximum de tentatives infructueuses nécessaires pour déclarer une taille MTU invalide. La valeur par défaut est 3 tentatives. |
sudo ./plpmtu -p icmp -s 184.12.26.131
Effectuez la découverte MTU (mode ICMP) avec 184.12.26.131.
sudo ./plpmtu -p udp -s 184.12.26.131:24000 -t 1500 -r 5
Effectuez la découverte MTU (mode UDP) avec 184.12.26.131 sur le port 24000. Si une réponse n'est pas reçue dans un délai de 1,5 seconde 5 fois de suite, réduisez le seuil MTU.