[Bug 256681] [route] Incorrect loopback route for aliases IP addresses

From: <bugzilla-noreply_at_freebsd.org>
Date: Sat, 19 Jun 2021 18:02:01 +0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256681

--- Comment #4 from Zhenlei Huang <zlei.huang_at_gmail.com> ---
(In reply to Rodney W. Grimes from comment #3)
Comparing to stable/12 and stable/11, I call the route is "expected".

Spent hours to repeat this on previous releases.

Prior to FreeBSD 8.0, upon adding IP address to interface, only the on-link
prefix route will be created. As for /32 aliases, the prefix route is /32. For
output routine, ip_output() will consult rtalloc() to "generate" the loopback
route for local IP address and use it.

>From FreeBSD 8.0 to FreeBSD 12.2, the on-link prefix route will be created, as
well as the loopback route for local IP address. See [1]. 

>From FreeBSD 13.0 and onward, due to significant rework of routing subsystem,
route for the /32 aliases is treated specially. See [2].

I reviewed the design of loopback route. If I understand correctly, the
loopback route short cut the out path of packets those are destined for local,
it directly forward it to local and bypass the physical interface. See [3].

So in some cases, if the loopback route is disabled and the hardware/logical
interface can not forward those packets destined for local, 'No route to host'
should be generated.

PS, there is a 'net.link.ether.inet.useloopback' sysctl tunable, it is default
on, and  controls whether installing a loopback route or not. This tunable
existed at least since 4.11 and was removed from stable/11. See [4].


[1]:
https://cgit.freebsd.org/src/commit/sys/netinet/in.c?h=stable/8&id=ebc90701ac6c1f814c5bd6f3e19f0113ebe06156
[2]: https://reviews.freebsd.org/D28668
[3]: https://cgit.freebsd.org/src/tree/sys/netinet/if_ether.c?h=stable/4#n109
[4]:
https://cgit.freebsd.org/src/commit/sys/netinet/if_ether.c?h=stable/11&id=b1b9dcae46803ae79255a9994584cb03d2a77048

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Sat Jun 19 2021 - 18:02:01 UTC

Original text of this message