From nobody Thu Nov 20 23:38:08 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dCFCN1CBGz6J6mC for ; Thu, 20 Nov 2025 23:38:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dCFCN0YNkz4Mpm for ; Thu, 20 Nov 2025 23:38:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763681888; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8rp8Ks2B3Z/kPnSvTWN9He8IlLb/wCPRqvJDLp1mr7o=; b=eCeFTMfPLaLnA1LnSVoeiOO3pjiPp2MPgLincj0x1aXp0Md7hB833S4mGBEY67EmVcNNpZ 9RgTz4/qP8Lf9wxa/vtLyVm4i/4Wa2MnkVhhoKwhuCd8jUV8b1pPZbZwo8TP+6i/MMBI7u c+dgSh3JVdqdsee6w6EyC8pBlmemgmp5haMiJRusrYHHiF0IHyXJSp4FUVnOJz+dtxMKCP F+Q7+PQrIBVLNf5uTS7OiwhOXObRFfZy+loo5bZM62OZGHhAeomtV+g8Fw//OdiY22nehp km0ZO8BwKU4qRbEmaypSXvsZGnZdjXPH/EK2JjuduH/v1Cj87BOZsj5mexjttg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763681888; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8rp8Ks2B3Z/kPnSvTWN9He8IlLb/wCPRqvJDLp1mr7o=; b=rtzQpjE1yiVuA72/jraf6A888UCpePCJFGnXbZtJGJmjFXw2DLSJaHd2Uuv/0SbLsCBJzW ZVWn8V3HaG2JgNcNhZBr5RLnzladauEwv9vWhf1zRWx/IVn6KMLLAGPpFCoTdzr8Prdih6 Y6hjflxciHus5QvGS7Mhibya3SujMT1OsmxvdPQMVcp1SnocA/vkQAptoXV8YUxGA8QR5D mvs+aPNK3x1XWoOYa7jqNK+7iiXd7s+hr2LYPyYbi9Od/5UR4Wp3thbNg2SG9c9/9i+es1 AkpvTkWIrS43ZP2yJ5ifRRjZLWpFzAu/YtdNwKE5H/GNdAgRHwBvXick36cTpw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763681888; a=rsa-sha256; cv=none; b=TbwsOVW2n5DOLo0J8OBYF1FjdurI7f2731UNpC2fbG4rnGViEZfYHh+zTtDQRNwrT5MPEq TmVrsu9X+3gAWIx0sK8VKZO5rjC5liKl1C1H3ay5pYRJFGiEn3frtE7ivNEYZqjDPjSm97 xzgh6bX4xqjc4aNRJsVZFNxCNnembVqTK5UKflTqFiHbv7SCdF/2cS/4C6YHu/X9CkJ02F Ct1hfBFTJu+Q/p78dRvhYWHS0ctby5oLigF7FnSyhZx1tW5MuPPYPW3Qq+qNNfMlcI4TDt KrklOy4hxbIh2JOf1CtGkcvM1i3JVbYybRqeR+symvzckHA/jlyo2jVT8fKLqQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4dCFCM6zQ2zn8m for ; Thu, 20 Nov 2025 23:38:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 5AKNc7ZY089371 for ; Thu, 20 Nov 2025 23:38:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 5AKNc7iO089370 for net@FreeBSD.org; Thu, 20 Nov 2025 23:38:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 291100] Reduce ARP cache time from 20 minutes to 60 seconds Date: Thu, 20 Nov 2025 23:38:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 16.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: achillesgaikwad@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D291100 --- Comment #4 from Achilles Gaikwad --- (In reply to Zhenlei Huang from comment #3) >When the IP address is assigned to new a VM's interface, the VM will broad= cast ARP request to detect duplicated IP, >and the neighbors can update their ARP cache entry to reflect the new IP-t= o-MAC mapping, >So it does not matter how long the ARP entry lifetime is. Yes, if an IP address that is re-assigned from VM1 to VM2, a gratuitous ARP will be sent by VM2. The problem I am trying to solve is not that of IP reassignment from one interface to another interface, but that when a VM2 boots and picks an IP t= hat was previously used by VM1 - VM2 does not send a GARP. If I create several other VMs they do not send a GARP on their boot either. >From my testing, when a VM boots, regardless of if it is using an IP address used by a different VM in past, it does not send out a GARP packet. >Do you have troubles that the ARP cache entries are stale ? Yes, ARP entries being stale are a problem here. Example,=20 In an AWS cloud environment - I created a NFS server on my FreeBSD system, = and then created several NFS clients to exhaust the IPs in my subnet. 1. Create an NFS server on FreeBSD, and start a packet capture. 2. Create NFS clients and mount the NFS share on them, my subnet had ~26 fr= ee IPs so I created ~26 NFS clients. 3. Delete all the NFS clients after verifying that they've successfully mou= nted the nfs share 4. Create 26 clients again, and attempt NFS mount on them ## Packet capture analysis shows that=20 1. A GARP request is not sent by a VM if hypervisor if an IP address is _mo= ved_ from one VM to another VM. 2. My VM `172.31.150.4` boots. 3. There is no ARP request sent by the VM during its boot. VM doesn't know = if that IP was used by someone else. 4. My NFS server=C2=A0`12:49:76:66:25:e9` asks for the mac address of my NF= S client `172.31.150.4` and gets a reply in frame `128` 5. Frames `129`, `130` show a successful handshake while talking to `12:e3:82:23:c1:7b` my NFS client. ``` $ tshark -ntad -r ~/Downloads/freebsd_arp.pcap -Y "(ip.addr =3D=3D 172.31.1= 50.4 and tcp.port =3D=3D 111) or (arp.src.proto_ipv4 =3D=3D 172.31.150.4)" | head=20 126 2025-11-20 16:15:20.451216 172.31.150.4 =E2=86=92 172.31.150.24 TCP 12:e3:82:23:c1:7b 12:49:76:66:25:e9 38872 =E2=86=92 111 [SYN] Seq=3D0 Win= =3D62727 Len=3D0 MSS=3D8961 SACK_PERM TSval=3D638822548 TSecr=3D0 WS=3D128 128 2025-11-20 16:15:20.451254 0.000038 12:e3:82:23:c1:7b =E2=86=92 12:49= :76:66:25:e9 ARP 12:e3:82:23:c1:7b 12:49:76:66:25:e9 172.31.150.4 is at 12:e3:82:23:c1:7b 129 2025-11-20 16:15:20.451262 0.000008 172.31.150.24 =E2=86=92 172.31.15= 0.4 TCP 12:49:76:66:25:e9 12:e3:82:23:c1:7b 111 =E2=86=92 38872 [SYN, ACK] Seq=3D0 = Ack=3D1 Win=3D65535 Len=3D0 MSS=3D8961 WS=3D64 SACK_PERM TSval=3D847652929 TSecr=3D= 638822548 130 2025-11-20 16:15:20.451457 0.000195 172.31.150.4 =E2=86=92 172.31.150= .24 TCP 12:e3:82:23:c1:7b 12:49:76:66:25:e9 38872 =E2=86=92 111 [ACK] Seq=3D1 Ack= =3D1 Win=3D62848 Len=3D0 TSval=3D638822549 TSecr=3D847652929 131 2025-11-20 16:15:20.451577 0.000120 172.31.150.4 =E2=86=92 172.31.150= .24 Portmap 12:e3:82:23:c1:7b 12:49:76:66:25:e9 V2 GETPORT Call NFS(100003) V:3 TCP ``` 6. I terminate `172.31.150.4`. The IP address is free'd up. 7. I spin up a new VM, and free IP `172.31.150.4` is assigned to my new VM, lets call this VM2. 8. There are no gARP packets between frame `169` and `1661` as the IP was n= ot moved, it was just reused from the pool of available IPs. ``` $ tshark -ntad -r ~/Downloads/freebsd_arp.pcap -Y "(ip.addr =3D=3D 172.31.1= 50.4 and tcp.port =3D=3D 111) or (arp.src.proto_ipv4 =3D=3D 172.31.150.4)" | head=20 ... 169 2025-11-20 16:15:20.590482 0.000224 172.31.150.4 =E2=86=92 172.31.150= .24 TCP 12:e3:82:23:c1:7b 12:49:76:66:25:e9 38874 =E2=86=92 111 [ACK] Seq=3D110 Ack= =3D34 Win=3D62848 Len=3D0 TSval=3D638822688 TSecr=3D3403520806 1661 2025-11-20 16:18:48.198831 207.608349 172.31.150.4 =E2=86=92 172.31.1= 50.24 TCP 12:fd:55:e8:b6:a9 12:49:76:66:25:e9 36578 =E2=86=92 111 [SYN] Seq=3D0 Win= =3D62727 Len=3D0 MSS=3D8961 SACK_PERM TSval=3D512935728 TSecr=3D0 WS=3D128 1662 2025-11-20 16:18:48.198842 0.000011 172.31.150.24 =E2=86=92 172.31.15= 0.4 TCP 12:49:76:66:25:e9 12:e3:82:23:c1:7b 111 =E2=86=92 36578 [SYN, ACK] Seq=3D0 = Ack=3D1 Win=3D65535 Len=3D0 MSS=3D8961 WS=3D64 SACK_PERM TSval=3D4022057017 TSecr= =3D512935728 1704 2025-11-20 16:18:49.221276 1.022434 172.31.150.24 =E2=86=92 172.31.15= 0.4 TCP 12:49:76:66:25:e9 12:e3:82:23:c1:7b [TCP Retransmission] 111 =E2=86=92 3657= 8 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D65535 Len=3D0 MSS=3D8961 WS=3D64 SACK_PERM TSval=3D40= 22058040 TSecr=3D512935728 1706 2025-11-20 16:18:49.266915 0.045639 172.31.150.4 =E2=86=92 172.31.150= .24 TCP 12:fd:55:e8:b6:a9 12:49:76:66:25:e9 [TCP Retransmission] 36578 =E2=86=92 11= 1 [SYN] Seq=3D0 Win=3D62727 Len=3D0 MSS=3D8961 SACK_PERM TSval=3D512936797 TSecr=3D= 0 WS=3D128 1707 2025-11-20 16:18:49.266927 0.000012 172.31.150.24 =E2=86=92 172.31.15= 0.4 TCP 12:49:76:66:25:e9 12:e3:82:23:c1:7b [TCP Retransmission] 111 =E2=86=92 3657= 8 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D65535 Len=3D0 MSS=3D8961 WS=3D64 SACK_PERM TSval=3D40= 22058086 TSecr=3D512936797 1746 2025-11-20 16:18:50.278090 1.011163 172.31.150.24 =E2=86=92 172.31.15= 0.4 TCP 12:49:76:66:25:e9 12:e3:82:23:c1:7b [TCP Retransmission] 111 =E2=86=92 3657= 8 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D65535 Len=3D0 MSS=3D8961 WS=3D64 SACK_PERM TSval=3D40= 22059097 TSecr=3D512936797 1777 2025-11-20 16:18:51.346919 1.068829 172.31.150.4 =E2=86=92 172.31.150= .24 TCP 12:fd:55:e8:b6:a9 12:49:76:66:25:e9 [TCP Retransmission] 36578 =E2=86=92 11= 1 [SYN] Seq=3D0 Win=3D62727 Len=3D0 MSS=3D8961 SACK_PERM TSval=3D512938877 TSecr=3D= 0 WS=3D128 ``` 9. VM2 tries to mount the NFS share and start a tcp communication in `1661`= .=20 The packet comes in from MAC address `12:fd:55:e8:b6:a9` who is the new owner of this IP. Our previous owner was `12:e3:82:23:c1:7b` 10. FreeBSD has a stale entry for upto 20 minutes that is still pointing towards `12:e3:82:23:c1:7b`, so in frame `1662` we see the SYN+ACK is actua= lly going to previous owner of the IP `12:e3:82:23:c1:7b` and not `12:fd:55:e8:b6:a9` 11. We observe that client never gets the SYN,ACK so it keeps retransmitting the SYN pkt. Sever keeps sending the SYN,ACK to the wrong MAC address. Therefore, what was historically OK to have an ARP cache time of 20 minutes= , is not suitable for dynamic cloud environments where systems can be short live= d. I therefore propose to set the ARP cache timeout from 1200s to 60s similar to what GNU/Linux does. I hope this helps. --=20 You are receiving this mail because: You are the assignee for the bug.=