Date: Tue, 10 Mar 2026 05:11:31 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 292319] [network: fibs] traffic comes from the wrong fib in some cases. Message-ID: <bug-292319-227-rNdbW07nmB@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-292319-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292319 William Brown <william@firstyear.id.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|Works As Intended |--- Status|Closed |Open --- Comment #2 from William Brown <william@firstyear.id.au> --- 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. 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 source 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 interface is part of a fib, it should not be able to view the interface state in other fibs. That alone would probably have prevented the issue here. 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 redirect. Alternately, the packet is emitted to the switch which will reflect it back to the host. Thanks for your time, -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-292319-227-rNdbW07nmB>