Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Jun 2021 08:36:50 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 256681] [route] Incorrect loopback route for aliases IP addresses
Message-ID:  <bug-256681-7501-GVETxf7Mdz@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-256681-7501@https.bugs.freebsd.org/bugzilla/>
References:  <bug-256681-7501@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256681

--- Comment #5 from Zhenlei Huang <zlei.huang@gmail.com> ---
> So in some cases, if the loopback route is disabled and the hardware/logi=
cal interface can not forward those packets destined for local, 'No route t=
o host' should be generated.

Since release/8.1, a new feature 'IFCAP_LINKSTATE' was introduced, see [5] =
and
[6]. If an interface have 'IFCAP_LINKSTATE' capability, then the "link" sta=
te
should be checked before passing those packets to it.

I verified this feature on stable/12 and stable/13. The steps:
1. ifconfig vxlan0 create vxlanid 100 vxlanlocal 10.x.x.x vxlanremote 10.y.=
y.y
2. ifconfig vxlan0 inet 192.0.2.1/24
3. ifconfig vxlan0 inet 192.0.2.2/32 alias
4. netstat -rnWf inet | grep 192.0.2
5. ping -c4 192.0.2.1
6. ping -c4 192.0.2.2
7. route delete 192.0.2.1
8. route delete 192.0.2.2
9. repeat step 4
10. ifconfig vxlan0 down &&=20

If create vxlan0 without vxlanid vxlanlocal and vxlanremote, then the link
state is not ready. If we delete the loopback route to 192.0.2.1 and 192.0.=
2.2,
ping will response with 'No route to host'.


[5]:
https://cgit.freebsd.org/src/commit/sys/netinet/ip_output.c?h=3Dstable/8&id=
=3Dc951da56b4f19a637c7fdf734fc500560a9555de
[6]:
https://cgit.freebsd.org/src/commit/sys?h=3Dstable/8&id=3D94190b3925795b145=
fbd1fbc39df0841ef52f5d5

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-256681-7501-GVETxf7Mdz>