Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Fonctionnalités ICMP

RÉSUMÉ Utilisez les fonctionnalités ICMP (Internet Control Message Protocol) pour diagnostiquer les problèmes réseau et vérifier l’accessibilité des équipements.

Utilisez l’Explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.

Messages de redirection de protocole

La redirection ICMP, également connue sous le nom de redirection de protocole, est un mécanisme utilisé par les commutateurs et les routeurs pour transmettre les informations de routage aux hôtes. Les périphériques utilisent des messages de redirection de protocole pour informer les hôtes de la même liaison de données du meilleur itinéraire disponible pour une destination donnée.

Comprendre les messages de redirection de protocole

Les messages de redirection de protocole informent un hôte de mettre à jour ses informations de routage et d’envoyer des paquets sur une autre route. Supposons qu’un hôte tente d’envoyer un paquet de données via un commutateur S1 et que S1 envoie le paquet de données à un autre commutateur, S2. Supposons également qu’un chemin direct de l’hôte vers S2 soit disponible (c’est-à-dire que l’hôte et S2 se trouvent sur le même segment Ethernet). S1 envoie ensuite un message de redirection de protocole pour informer l’hôte que le meilleur itinéraire pour la destination est l’itinéraire direct vers S2. L’hôte doit alors envoyer les paquets directement à S2 au lieu de les envoyer via S1. S2 envoie toujours le paquet d’origine qu’il a reçu de S1 à la destination prévue.

Reportez-vous aux RFC-1122 et RFC-4861 pour plus de détails sur la redirection de protocole.

Note:
  • Les commutateurs n’envoient pas de messages de redirection de protocole si le paquet de données contient des informations de routage.

  • Tous les commutateurs EX Series prennent en charge l’envoi de messages de redirection de protocole pour le trafic IPv4 et IPv6.

Désactiver les messages de redirection de protocole

Par défaut, les appareils envoient des messages de redirection de protocole pour le trafic IPv4 et IPv6. Pour des raisons de sécurité, vous pouvez désactiver l’envoi de messages de redirection de protocole à l’appareil.

Pour désactiver les messages de redirection de protocole pour l’ensemble de l’appareil, incluez l’instruction no-redirects or no-redirects-ipv6 au niveau de la [edit system] hiérarchie.

  • Pour le trafic IPv4 :

  • Pour le trafic IPv6 :

Pour réactiver l’envoi de messages de redirection sur l’appareil, supprimez l’instruction (pour le trafic IPv4) ou l’instruction no-redirects (pour le no-redirects-ipv6 trafic IPv6) de la configuration.

Pour désactiver les messages de redirection de protocole par interface, incluez l’instruction no-redirects au niveau de la [edit interfaces interface-name unit logical-unit-number family family] hiérarchie.

  • Pour le trafic IPv4 :

  • Pour le trafic IPv6 :

Pings

Les pings utilisent ICMP. Un ping réussi se produit lorsqu’un périphérique envoie une demande d’écho ICMP à une cible et que la cible répond par une réponse d’écho ICMP. Cependant, il peut arriver que vous ne souhaitiez pas que votre appareil réponde aux requêtes ping.

Désactiver la réponse du moteur de routage aux paquets ping multicast

Par défaut, le moteur de routage répond aux demandes d’écho ICMP envoyées aux adresses de groupe multicast. En configurant le moteur de routage pour ignorer les paquets ping multicast, vous pouvez empêcher les personnes non autorisées de découvrir la liste des périphériques PE (Provider Edge) dans le réseau.

Pour empêcher le moteur de routage de répondre à ces demandes d’écho ICMP, incluez l’instruction no-multicast-echo au niveau de la [edit system] hiérarchie :

Désactiver le signalement de l’adresse IP et des horodatages dans les réponses Ping

Lorsque vous émettez la ping commande avec l’option record-route , le moteur de routage affiche le chemin des paquets de demande d’écho ICMP et les horodatages dans les réponses d’écho ICMP par défaut. En configurant les no-ping-record-route options et no-ping-timestamp , vous pouvez empêcher les personnes non autorisées de découvrir des informations sur le périphérique PE (Provider Edge) et son adresse de bouclage.

Vous pouvez configurer le moteur de routage pour désactiver le paramètre de l’option record-route dans l’en-tête IP des paquets de demande ping. La désactivation de l’option record-route empêche le moteur de routage d’enregistrer et d’afficher le chemin des paquets de demande d’écho ICMP dans la réponse.

Pour configurer le moteur de routage afin de désactiver le paramètre de l’option record route , incluez l’instruction no-ping-record-route au niveau de la [edit system] hiérarchie :

Pour désactiver la création de rapports d’horodatage dans les réponses d’écho ICMP, incluez l’option no-ping-time-stamp au niveau de la [edit system] hiérarchie :

Messages d’extinction de la source

Lorsqu’un périphérique reçoit un trop grand nombre de datagrammes indésirables, il peut envoyer un message d’extinction de source à l’appareil d’origine. Le message d’extinction source signale à l’appareil d’origine de réduire la quantité de trafic qu’il envoie.

Par défaut, l’appareil réagit aux messages d’extinction de source ICMP. Pour ignorer les messages d’extinction de source ICMP, incluez l’instruction au no-source-quench niveau de la [edit system internet-options] hiérarchie :

Pour cesser d’ignorer les messages d’extinction de source ICMP, utilisez l’instruction source-quench suivante :

Expiration de la durée de vie (TTL)

La durée de vie (TTL) d’un en-tête de paquet détermine la durée de transmission du paquet sur le réseau. La valeur TTL diminue à chaque équipement (ou saut) traversé par le paquet. Lorsqu’un équipement reçoit un paquet dont la valeur TTL est égale à 0, il le rejette. Le message d’expiration de la TTL est envoyé à l’aide d’ICMP.

Vous pouvez configurer votre équipement pour qu’il utilise une adresse IPv4 comme adresse source pour les messages d’erreur d’expiration de durée de vie (TTL) ICMP. Cela signifie que vous pouvez configurer l’adresse de bouclage en tant qu’adresse source en réponse aux paquets d’erreur ICMP. Cette opération est utile lorsque vous ne pouvez pas utiliser l’adresse de l’appareil à des fins de traceroute, car vous avez des adresses IPv4 en double dans votre réseau.

L’adresse source doit être une adresse IPv4. Pour spécifier l’adresse source, utilisez l’option au niveau de ttl-expired-source-address source-address la [edit system icmp (System)] hiérarchie :

Cette configuration s’applique uniquement aux messages d’expiration de la durée de vie ICMP. D’autres messages de réponse d’erreur ICMP continuent d’utiliser l’adresse de l’interface entrante comme adresse source.

Limite de débit du trafic ICMP

Pour limiter la vitesse à laquelle les messages ICMPv4 ou ICMPv6 peuvent être générés par le moteur de routage et envoyés au moteur de routage, incluez l’instruction de limitation de débit appropriée au niveau de la [edit system internet-options] hiérarchie.

  • Pour IPv4 :

  • Pour IPv6 :

Messages d’erreur ICMP de limite de débit

Par défaut, les messages d’erreur ICMP pour les paquets IPv4 et IPv6 non expirés par TTL sont générés à raison de 1 paquet par seconde (pps). Vous pouvez ajuster ce débit à une valeur qui, selon vous, fournit suffisamment d’informations pour votre réseau sans provoquer d’encombrement du réseau.

Note:

Pour les paquets IPv4 ou IPv6 ayant expiré par TTL, le débit des messages d’erreur ICMP n’est pas configurable. Il est fixé à 500 pps.

Pourquoi limiter le débit des messages d’erreur ICMPv4 et ICMPv6 ?

Un exemple de cas d’utilisation pour ajuster la limite de débit est un centre de données fournissant des services Web. Supposons que ce centre de données comporte de nombreux serveurs sur le réseau qui utilisent des trames jumbo avec une MTU de 9 100 octets lorsqu’ils communiquent avec des hôtes via Internet. Ces autres hôtes nécessitent une MTU de 1500 octets. À moins que la taille maximale de segment (MSS) ne soit appliquée des deux côtés de la connexion, un serveur peut répondre avec un paquet trop volumineux pour être transmis sur Internet sans être fragmenté lorsqu’il atteint le routeur de périphérie dans le centre de données.

Étant donné que les implémentations TCP/IP ont souvent la découverte MTU de chemin activée par défaut avec le dont-fragment bit défini sur 1, un périphérique de transit abandonnera un paquet trop volumineux plutôt que de le fragmenter. L’appareil renvoie un message d’erreur ICMP indiquant que la destination n’était pas accessible car le paquet était trop volumineux. Le message indique également la MTU requise à l’endroit où l’erreur s’est produite. L’hôte émetteur doit ajuster le MSS d’envoi pour cette connexion et renvoyer les données en paquets de plus petite taille pour éviter le problème de fragmentation.

Avec des vitesses d’interface de cur élevées, la limite de débit par défaut de 1 pps pour les messages d’erreur peut ne pas être suffisante pour avertir tous les hôtes lorsqu’il y a beaucoup d’hôtes sur le réseau qui ont besoin de ce service. Par conséquent, les paquets sortants sont abandonnés silencieusement. Cette action peut déclencher des retransmissions ou des comportements d’interruption supplémentaires, en fonction du volume de demandes traitées par le routeur de périphérie du centre de données sur chaque interface centrale.

Dans ce cas, vous pouvez augmenter la limite de débit pour permettre à un volume plus élevé de paquets surdimensionnés d’atteindre les hôtes émetteurs. (L’ajout d’interfaces orientées vers le cur peut également aider à résoudre le problème.)

Comment limiter le débit des messages d’erreur ICMPv4 et ICMPv6

Bien que vous configuriez la limite de débit au niveau de la hiérarchie, il ne s’agit pas d’une limite à l’échelle [edit chassis] du châssis. Au lieu de cela, la limite de débit s’applique par famille d’interfaces. Cela signifie, par exemple, que plusieurs interfaces physiques configurées avec family inet peuvent générer simultanément les messages d’erreur ICMP à la vitesse configurée.

Note:

Cette limite de débit ne s’applique qu’au trafic d’une durée de 10 secondes ou plus. La limite de débit n’est pas appliquée au trafic dont la durée est plus courte, par exemple 5 secondes ou 9 secondes.

  • Pour configurer la limite de débit pour ICMPv4, utilisez l’instruction icmp suivante :

    À partir de la version 19.1R1 de Junos OS, le débit maximal est passé de 50 pps à 1000 pps.

  • Pour configurer la limite de débit pour ICMPv6, utilisez l’instruction icmp6 suivante :

Vous devez également tenir compte du fait que la valeur limite de débit peut interagir avec votre configuration de protection DDoS. La valeur de bande passante par défaut pour les paquets exceptionnels qui dépassent la MTU est de 250 pps. La protection DDoS signale une violation lorsque le nombre de paquets dépasse cette valeur. Si vous définissez une limite de débit supérieure à la valeur de bande passante actuelle mtu-exceeded , vous devez configurer la valeur de bande passante pour qu’elle corresponde à la limite de débit.

Par exemple, supposons que vous définissiez la limite de débit ICMP à 300 pps :

Vous devez configurer la protection mtu-exceeded bandwidth DDoS pour qu’elle corresponde à cette valeur.