https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291100
Zhenlei Huang <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Zhenlei Huang <[email protected]> --- (In reply to Achilles Gaikwad from comment #0) > ## issue: > The current 20-minute ARP cache timeout, while appropriate for traditional > stable > network environments (Like on-prem systems), causes connectivity issues in > modern > cloud environments. It is not common that in on prem the IP pool gets recycled > quickly within 20 minutes. Where as in cloud environments - > 1. Short-lived instances: Client systems may operate for less than 20 minutes > before > termination, the IP address that the virtual machines held will be reused by > other > virtual machines. > 2. Due to [1] when IP addresses are quickly reassigned to new virtual > machines, the > OS continues attempting to communicate with the cached (now stale) MAC address > instead of performing a fresh ARP resolution until 20 minutes. When the IP address is assigned to new a VM's interface, the VM will broadcast ARP request to detect duplicated IP, ``` # jexec 2 tcpdump -envvvi epair1a tcpdump: listening on epair1a, link-type EN10MB (Ethernet), snapshot length 262144 bytes 10:15:36.179644 58:9c:fc:10:7c:d3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.1.99 tell 172.16.1.99, length 28 ``` and the neighbors can update their ARP cache entry to reflect the new IP-to-MAC mapping, ``` # tail -n1 /var/log/messages Nov 20 10:15:36 kernel: arp: 172.16.1.99 moved from 58:9c:fc:10:ff:3c to 58:9c:fc:10:7c:d3 on epair0a ``` So it does not matter how long the ARP entry lifetime is. Do you have troubles that the ARP cache entries are stale ? -- You are receiving this mail because: You are the assignee for the bug.
