On Mon 20 Feb 2023 at 09:59:20 (+0700), Max Nikulin wrote:
> On 19/02/2023 23:35, Christoph Brinkhaus wrote:
> > Am Sun, Feb 19, 2023 at 05:21:47PM +0100 schrieb Geert Stappers:
> > > Having installed package openvswitch-switch and doing `ip route` I do get
> > > 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
> >
> > Please have a look at https://wiki.debian.org/Avahi.
>
> I hope, somebody with more knowledge of related technology will correct me.
>
> I find it confusing that the wiki page neither mentions avahi-autoipd
> nor has a link explaining interaction of avahi and avahi-autoipd.
>
> My impression is that the purpose if Avahi is discovery of services in
> multicast network segment and publishing services available on the
> host where avahi daemon is running to make them available for other
> computers. Its scope is .local host names. IP address may be received
> from centralized DHCP server.
>
> 169.254.x.y addresses are link local (IPv4LL) and usually appears when
> IP address is not configured and an attempt to get it through DHCP
> fails. Such addresses may be configured by avahi-autoipd, unsure
> concerning systemd(-networkd?).
>
> So to avoid 169.254.x.y addresses, it necessary to disable link local
> addressed (avahi-autoipd). My guess is that Avahi as service discovery
> tool may still work when usual (static or DHCP) IP address is
> configured.
>
> Perhaps to get rid of 169.254.x.y addresses, it is enough to properly
> configure network interface, either to ensure that DHCP server is
> available or to assign a static address. After that you may forget
> about existence of avahi-autoipd.
I would agree with pretty well all of that. I'd just add a few points.
Having a 169.254.0.0 route, like the one posted here, shouldn't cause
any ill-effects if other routes exist, as in for example:
$ ip r
default via 192.168.1.1 dev wlp2s4
169.254.0.0/16 dev wlp2s4 scope link metric 1000
192.168.1.0/24 dev wlp2s4 proto kernel scope link src 192.168.1.10
$
That machine has no 169.254.x.y address configured either:
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 00:98:76:54:32:10 brd ff:ff:ff:ff:ff:ff
3: wlp2s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP group default qlen 1000
link/ether 00:0e:12:34:56:78 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global dynamic wlp2s4
valid_lft 80846sec preferred_lft 80846sec
inet6 fe80::20e:12ff:fe34:5678/64 scope link
valid_lft forever preferred_lft forever
$
I don't recall ever seeing a 169.254.0.0 route generated in the
absence of avahi-autoipd.
I use avahi-daemon for driverless printing on systems that have
no 169.254.… addresses, routes, etc. The entire LAN is given its
IP addresses by a DHCP server in my primary router.
Cheers,
David.
