From nobody Tue Mar 10 05:11:31 2026 X-Original-To: bugs@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 4fVMRl1hY9z6VcPs for ; Tue, 10 Mar 2026 05:11:31 +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" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fVMRl0xsdz3NGm for ; Tue, 10 Mar 2026 05:11:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1773119491; 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=kEOlJ/mb4CED8DRrNnx6+4uWhk1j6acUlLUspLB/Ez0=; b=TvcsLocHo5O37vw2pxzZ7e4XF4OSJPut+knS+PwrEx1QAXNQmpAizSBzTGTIJheH4VKptP e+X0v4Shl+ztWBdR6i9q6xw4pCRiU/SWd2h/juvnnLDK7HvRKDdb4byHGN7uurPY2iRI+8 QBxJWNkRH3YeRStKwJGzxlzgOMeNKyi5L48sq3rTXPPLkMt91GBnZGVSWgRkV2lEVLHUSH rdIYAs7ftXbrnGXBZh2l9XmyyUAXf7EzM1ZG/0P0m3R/CmM23wW+KlQQ90vrp0hJyNjDXQ VJDTLu/uYs5SntIYskI6T0Isjc5+ABQSZCUbtxgJ6afMbDSRek6Mr+nMtzJ5tw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1773119491; a=rsa-sha256; cv=none; b=YE8m1xgbbA18jOY0mO+JjrP8JLnY0ELOlBkns1QmN5ZjSxVK9Yf5wi9MIPwRgL8yVIPm6H 0kixyp68iopeHtR7d4FsyAx+HkP0QRg5e2+XMJ+dJMtmfkvv2HbecG+y4n5rUaEYyYaS8v ryKoIoy+tHDzL9BA8rl+NxZ09KHAasRbU91bHk4bpwQHcWJO2tQu9HVMmP142R+YkypO2q kzJA2iWlN/GaXKYbOO9Kghhp4XcvizlcBi32xEqWlviBc34Z0KwNb894N7OJE0fA3Q6wCZ KSL3188lvlcyBd+eGXmeVuCTgKqI/Z8Zzn2zxiFu+DZt7fIzNcqbbhW0wkUStg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1773119491; 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=kEOlJ/mb4CED8DRrNnx6+4uWhk1j6acUlLUspLB/Ez0=; b=ssyFFQLNGOeyVJZ579aEwbIzBNBgrPzaNm8eChf1ISTad7TEAtTR3T1rXCwVOl6Fp2ONCx 5Kfm8viuIxqgP1xpOdwXMkloOt2j/CTkgFrKWP/oMe5BjVYBgAITjAdz09fRL5ieMa8aXc D7xhtji8FzP9c5WcljnturM9Xp+Fu7ejm8vMYXpRJAQufHnBDYfuiT3JNqeOZ87LyjosjK Sk+MK+Vhn2rqnSOb0MMSQnH//65ZB9ERqPvKg2LfgsZgRNUExWR3k1XMlxCOOZ8bhATr7F 4t3+c8Hj87vGXioZeBjo2z9apIdHlZDFsgwUeuqBwI6lRQV95AcE/9yO/SscmA== 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 4fVMRl0GwLzy5p for ; Tue, 10 Mar 2026 05:11:31 +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 62A5BUlE064698 for ; Tue, 10 Mar 2026 05:11:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 62A5BUCp064697 for bugs@FreeBSD.org; Tue, 10 Mar 2026 05:11:30 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: bugs@FreeBSD.org Subject: [Bug 292319] [network: fibs] traffic comes from the wrong fib in some cases. Date: Tue, 10 Mar 2026 05:11:31 +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: 15.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: william@firstyear.id.au X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D292319 William Brown changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|Works As Intended |--- Status|Closed |Open --- Comment #2 from William Brown --- I do actually think this is a bug. My understanding is that "two fibs" should be equivalent to "two separate machines" from a routing table perspective. They are isolated networking "islands", and this is how I understand it from other implementations. We send the ping: 13:28:08.139450 IP 172.24.17.26 > 10.144.53.53: ICMP echo request, id 7657,= seq 0, length 64 Logically this flows from 172.24.17.26 (vtnet5 fib 5) to 172.24.17.1, then = back to 172.24.17.24 (vtnet1 fib 1) and onward via 10.149.242.42 (via tun5 fib 1) Then we get a redirect, which as you note, is completely valid: 13:41:43.442440 IP 172.24.17.1 > 172.24.17.26: ICMP redirect 10.149.242.42 = to host 172.24.17.24, length 92 Since 10.149.242.42 (via tun5 fib 1) is routed via 172.24.17.24 (vtnet1 fib= 1) then it is valid to inform 172.24.17.26 (vtnet5 fib 5) that it can directly communicate via that path.=20 But then we see: 13:28:09.167377 IP 10.149.242.42 > 10.144.53.53: ICMP echo request, id 968,= seq 1, length 64 FreeBSD is resolving correctly that it is in possession of all three IP's 10.149.242.42, 172.24.17.24 and 172.24.17.26. So then the "shortest path" becomes emitting the traffic from 10.149.242.42 as 10/8 is part of fib 1's routing table. However, the echo requests are sent out of vtnet5 (fib 5) but from the sour= ce address 10.149.242.42. If they were correctly sent from tun5 (fib 1) then it wouldn't be a problem. I believe this is the bug - that the redirect causes= the traffic to be emitted incorrectly from this interface. Secondary to this, it does seem wrong that fibs will "cross streams" in this way - if an interfac= e is part of a fib, it should not be able to view the interface state in other f= ibs. That alone would probably have prevented the issue here.=20 I would expect that if anything - the redirect should cause 172.24.17.26 (vtnet5 fib 5) to emit the ICMP echo request, then send it via loopback to 172.24.17.24 (vtnet1 fib 1), as this is the path denoted by the ICMP redire= ct. Alternately, the packet is emitted to the switch which will reflect it back= to the host.=20 Thanks for your time, --=20 You are receiving this mail because: You are the assignee for the bug.=