https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=298809
Bug ID: 298809
Summary: route add -net ... gw -ifp <iface> silently ignores
the explicit interface and binds the route to an
unrelated loopback interface, causing a routing loop
Product: Base System
Version: 15.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Created attachment 275066
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=275066&action=edit
script to set up sample environment
Summary: route add -net ... gw -ifp <iface> silently ignores the explicit
interface and binds the route to an unrelated loopback interface, causing a
routing loop
Product: Base System · Component: kern · Version: 15.1-RELEASE-p3
Environment:
FreeBSD 15.1-RELEASE-p3 amd64 (GENERIC)
Non-default FIB (fib 2) in use via multi-fib routing; host has no fib 0
configuration to compare against
Point-to-point /32 link between the host and a bhyve/jail guest over a
bridge(4) + epair(4) pair
lo2 is a separate cloned loopback carrying unrelated local host routes
(10.0.2.126, .129, .130) used successfully by other jails — ruling out lo2
itself being misconfigured
Setup:
bridge21: inet 100.65.1.21/32 (host side, member epair1a), fib 2
guest side: 100.65.1.22/32 (via epair1b)
Confirmed working: ping -S 100.65.1.21 100.65.1.22 succeeds
Goal: route 10.0.2.248/29 (a subnet behind the guest) via gateway 100.65.1.22
Steps to reproduce:
route add -net 10.0.2.248/29 100.65.1.22 -ifp bridge21
netstat -4ran
ping 10.0.2.248
Expected: Route's Netif is bridge21, as explicitly specified with -ifp. Ping
reaches the gateway or times out normally.
Actual: netstat -4ran shows the route's Netif as lo2, despite -ifp bridge21
being passed explicitly. Pinging a destination behind the gateway produces a
self-inflicted routing loop: the host repeatedly receives "Redirect Host (New
addr: 100.65.1.22)" from itself (source and destination both belonging to the
host), with TTL decrementing on each iteration, ultimately terminating in "Time
to live exceeded." See attached packet capture output — same packet ID
reappears ~64 times with TTL counting down from 0x40 to 0x01 before expiring.
Notes:
Gateway reachability confirmed independently: ping -S 100.65.1.21 100.65.1.22
succeeds.
-ifa 100.65.1.21 tried in combination with -ifp bridge21; same result.
lo2 is otherwise functioning correctly — it hosts unrelated local address
routes actively used by other jails on this system, so this isn't a case of a
broken loopback interface generally.
Possibly related to bug 285422 ("IPv4 source address selection is broken (with
loopbacks)"), which shows a similar loopback fallback, but under different
conditions (default route to an IPv6 link-local gateway on an interface with no
IPv4 address). This report's outgoing interface has a valid IPv4 address and is
passed explicitly via -ifp, so this may reflect a related but distinct code
path, or a deeper root cause shared by both.
--
You are receiving this mail because:
You are the assignee for the bug.
