Re: Remove route '169.254.0.0/16 dev ovs-system'
Hi.
On Sun, Feb 26, 2023 at 03:14:22PM +0100, Geert Stappers wrote:
> Hi.
>
> On Sun, Feb 26, 2023 at 04:01:06PM +0300, Reco wrote:
> > On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote:
> > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired
> > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: IAID cb:93:09:25
> > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: adding address fe80::56b2:83e1:5ceb:9d50
> > > ...
> > > Feb 24 22:24:16 trancilo dhcpcd[1175]: ovs-system: soliciting a DHCP lease
> > > ...
> > > Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL address
> > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address 169.254.201.7
> > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to 169.254.0.0/16
> >
> > Let's try a straightforward approach for starters:
> >
> > echo denyinterfaces ovs-system >> /etc/dhcpcd.conf
>
>
> Yes, now no more route 169.254.0.0/16 for device ovs-system.
>
> And for the record:
> * Package avahi-autoipd left removed
> * Service avahi-daemon left disabled
> * Socket avahi-daemon left disabled
These have nothing to do with your problem.
dhcpcd is the source of your problem, in a way.
dhcpcd can run as a systemwide daemon, which tries to obtain DHCP lease
on any network interface barring "lo".
In stock configuration, dhcpcd will add IPv4LL (169.254/16) IP on a
interface if it fails to obtain a lease after 60 second timeout (IIRC).
And obviously you have no DHCP server on "ovs-system" :)
Debian's packaging of dhcpcd should prevent the daemon to obtain DHCP
lease on any interface that's listed in /etc/network/interfaces, but:
1) OVS bridge should not be listed there, it's dynamic by nature.
2) You're using Network Manager, so it's totally possible that you have
an empty /etc/network/interfaces, or no such file at all.
Long story short, consider running "systemctl mask dhcpcd" unless you
need dhcpcd to work in a way described above.
Another possible workaround is to add "noipv4ll" to dhcpcd.conf, but
this could break something else in your setup.
Reco
Reply to: