Re: Remove route '169.254.0.0/16 dev ovs-system'
Hi.
On Sun, Feb 26, 2023 at 05:25:09PM +0300, Reco wrote:
> On Sun, Feb 26, 2023 at 03:14:22PM +0100, Geert Stappers wrote:
> > 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:
} } } } } Have you tried `journalctl --boot`?
> > > > 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
As done / adviced earlier in this thread.
> These have nothing to do with your problem.
> dhcpcd is the source of your problem, in a way.
OK, so I checked. And yes, it is true that adding
'denyinterfaces ovs-system ovsbr0' to /etc/dhcpcd.conf
does prevent "route 169.254.0.0/16 dev ovs-system"
and "route 169.254.0.0/16 dev ovsbr0"
> 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.
>
I have no /etc/network/interfaces.d/ovs-system,
my /etc/network/interfaces.d/ovsbr0 has
auto ovsbr0
iface ovsbr0 inet static
address 172.24.6.2/24
And there was "route 169.254.0.0/16 dev ovsbr0".
I only reported, until now, only about dev ovs-system.
Thing I trying to say:
Having device in /etc/network/interfaces did
not prevent the unwanted route.
(Meanwhile solved with denyinterface in /etc/dhcpcd.conf)
> Long story short, consider running "systemctl mask dhcpcd" unless you
> need dhcpcd to work in a way described above.
The laptop does need to have DHCP client.
> Another possible workaround is to add "noipv4ll" to dhcpcd.conf,
Not tried.
> but this could break something else in your setup.
Yes "could break", but I don't know what ...
(I'm mostly on computer networks that do have
DHCP and DNServers (I can't tell first hand
the benefits of IPv4LL addresses))
> Reco
Groeten
Geert Stappers
--
Silence is hard to parse
Reply to: