Délai ARP dans le message de diffusion

Question

Supposons que je dispose de l'hôte source H1 (10.1.1.2/24) qui souhaite communiquer avec l'hôte H2 (10.1.1.3/24). Puisque les deux hôtes sont dans le même sous-réseau H1 envoie une diffusion ARP. H2 répond à cette diffusion et finalement H1 reçoit l'adresse MAC H2. Par conséquent, la communication établit. Maintenant, si H2 est en panne, H1 ne recevra pas de réponse ARP de H2. Alors pour quelle durée H1 attendra la réponse ARP? La RFC 826 ne parle pas d'une telle minuterie.

J'ai trouvé dans un forum qu'il est de 5 à 30 secondes. Est-ce correct?

Cordialement, Sudhansu

Answer 1

Dans votre description, vous manquez au moins une chose. La réponse ARP est mise en cache en tant qu'entrée ARP pendant un certain temps. Donc H1 enverra du trafic au blackhole après que H2 soit en panne. Cette période de temps est sélectionnée comme aléatoire nombre entre base_reachable_time/2 et 3*base_reachable_time/2. (Aléatoire est utilisé pour distribuer la demande de différents appareils à temps). Par défaut, base_reachable_time est de 30 secondes.

Après ce temps aléatoire écoulé, H1 essaie de mettre à jour l'entrée ARP. La mise à jour est effectuée par un message unicast (envoi direct à H1 sans aucune diffusion vers le réseau) en envoyant une requête ARP avec l'intervalle retrans_time_ms (1 seconde par défaut). Si ucast_solicit (3 par défaut) a échoué alors que la sonde de diffusion est effectuée.

Si la sonde de diffusion a également échoué (mcast_solicit essaie avec l'intervalle retrans_time_ms), l'entrée ARP est considérée comme incomplète. Au cours de cette vérification, le noyau peut contenir l'envoi de paquets au H2 dans la file d'attente ARP.

Résumant:

• 15-45 secondes écoulées avant l'entrée ARP revalidation
• (3 + 3) * 1000 millisecondes écoulées après sonde est démarré et avant l'entrée ARP considérée non valide.