60 secondes
vous pouvez le vérifier avec :
cat /proc/sys/net/ipv4/neigh/ethX/gc_stale_time
et changez-le avec
echo timeout > /proc/sys/net/ipv4/neigh/ethX/gc_stale_time
timeout est une nouvelle valeur
Je reconnais qu'au moment où j'écris ceci, c'est une question vieille de trois ans. Mais je suis tombé sur cette question en faisant des recherches sur le même sujet, et en corroborant la réponse de watchmansky (https://serverfault.com/a/684381/188907), j'en ai appris un peu plus sur la situation, du moins telle qu'elle existe aujourd'hui.
Selon https://linux.die.net/man/7/arp, le paramètre
gc_stale_time
affecte la fréquence à laquelle le cache ARP est vérifié pour les entrées obsolètes. (Ou déchets collectés , d'où le "gc_" au début du nom du paramètre.)
Pendant ce temps, la valeur
base_reachable_time_ms
contrôle en fait la durée de validité d'une entrée de cache ARP et sa valeur par défaut est de 30 000 millisecondes. Mais chaque nouvelle entrée de cache ARP recevra en fait une valeur de durée de vie définie au hasard quelque part entre base_reachable_time_ms / 2 and 3*base_reachable_time_ms / 2 *.
Cela signifie que chaque nouvelle entrée ARP mise en cache aura un délai de démarrage entre 15 et 45 secondes, à moins que la valeur de base_reachable_time_ms est modifié.
Cela suppose que la valeur actuelle du délai d'expiration d'une entrée ARP mise en cache est validée avant utilisation et que le taux de récupération de place n'influence pas la validité effective des entrées de cache.
(*Confirmé en lisant le code sur https://elixir.bootlin.com/linux/v4.17.11/source/net/core/neighbor.c#L115)