I have a very basic wireguard connection that routes all traffic through a VPN.

[Interface]
PrivateKey = 
Address = 
DNS = 

[Peer]
PublicKey = 
AllowedIPs = 0.0.0.0,::0/0
Endpoint =

I've imported and enabled it with NetworkManager using nmcli connection import type wireguard file $conf. My problem is I have a scheduled process that I would like to _not_ go through the wireguard tunnel, _(ie come from my home IP address)_. And I'd rather not carve out an exception in the wireguard config. The solution I've tried is to setup a network namespace which is linked to eth0. That way I could bypass the wireguard connection with sudo ip netns exec clearnet. But I can't link the namespace directly to eth0 or else everything else looses access to eth0 and the internet in general. This is turning out very convoluted though because I've got to do something like eth0 -> br0 -> veth0 -> veth1 -> ns1

sudo ip netns add clearnet # create namespace
sudo ip link add veth0 type veth peer name veth1 # create veth pair
sudo ip link set veth1 netns clearnet # link the veth1 to the clearnet
sudo ip link add br0 type bridge # create bridge
sudo ip link set eth0 master br0 # connect eth0 to the bridge (lose internet here)
sudo ip link set veth0 master br0 # connect veth0 to the bridge

# turn everything on
sudo ip link set br0 up
sudo ip link set veth0 up
sudo ip netns exec clearnet ip link set veth1 up

nmcli connection up br0 # restore internet

# give the bridge an IP address
sudo ip addr add 192.168.100.1/24 dev br0
sudo ip addr add 192.168.100.1/24 dev veth0

# give the namespace and IP address
sudo ip netns exec ip addr add 192.168.100.2/24 dev veth1

# tell the namespace to route via the bridge's IP
sudo ip netns exec ip route add default via 192.168.100.1

At this point I still don't have internet access via clearnet, much less DNS, and I'm convinced I'm doing this the _hard way_. Something like NetworkManager, systemd (which schedules the process), or docker (which executes the process) should have a short cut. Or is what I'm seeking really this complicated?

To do policy routing, one needs to add a routing table to /etc/iproute2/rt_tables. I was wondering how this gets read. Is it read by the kernel, or is it read by the iproute2 userspace tools?

I've set up an archlinux inside a Oracle Virtual Box. To be able to reach the VM from the LAN I have added a bridge adapter and configured the guest system following the instructions from the Arch Linux Wiki: Network bridge | With iproute2 . I used the following commands to successfully set up the network: ip link add name lan_bridge type bridge ip link set lan_bridge up ip link enp0s8 up ip link set enp0s8 master lan_bridge systemctl start dhcpcd@lan_bridge After those steps I'm able to login into the guest via SSH. Trying to make the changes persistent using: systemctl enable dhcpcd@lan_bridge does not work, though. I'd like systemd to create the exact same setup on startup automatically. Of course I could just paste those commands into a shell script and run it at startup, but I think there should be a proper way to do so. Help is greatly appreciated.

Currently running on Fedora Server 23, I've been searching for the right way to persist commands such as: ip route add default via 10.0.2.1 dev ens32 table EXAMPLE_TABLE ip rule add from 10.1.2.50 lookup EXAMPLE_TABLE prio 1000 either through nmcli (ideally) or through some other, similarly, **sane** way. I've seen examples like lodging it on the *route-ifname* file but that don't seem to execute the default rule correctly. If you run ip route show table EXAMPLE_TABLE after a reboot you'll realize it doesn't stick - at least in my experience. Any insights into this would be lovely, thank you.

The ip-vrf manual reads : >A VRF provides traffic isolation at layer 3 for routing, similar to how a VLAN is used to isolate traffic at layer 2. Fundamentally, a VRF is a separate routing table. At the same time, The iproute2 ip command allows to deal with multiple separate routing tables by using the table keyword. Moreover, Linux network namespaces, which have been popularized by containers, also allow to separate routing tables (and devices, and […]). So what's the difference between VRFs and iproute2's multiple routing tables, and network namespaces ? Are there some things you can do with one and not the other ? Or is that fundamentally the same mechanism with different names ?

On recent Linux based operating systems there is no ifconfig and traceroute. Some functionality has been incorporated into the ip utility (see here for examples), but I have not found a replacement for the traceroute command. I know that I can do yum install net-tools or yum install traceroute when I am on CentOS or RHEL but our servers come preinstalled without that command and while we are allowed to sudo certain commands installing additional software is always a problem

I would like to route traffic over usb0 (a cellular modem) when it is available instead of eth0. The ip address for usb0 may change over time. How do I create a route in this scenario since the ip address may change? I tried: ip route add default dev usb0 but when I do this, I am able to ping from usb0 but no longer through eth0. Any thoughts why? Destination Gateway Genmask Flags Metric Ref Use Iface default 172.24.1.1 0.0.0.0 UG 10 0 0 eth0 172.19.200.136 * 255.255.255.252 U 0 0 0 usb0 172.24.1.0 * 255.255.255.0 U 0 0 0 eth0

I would like to delete an alias I created using: ip addr add 192.168.1.1 dev eth0 label eth0:100 without having to know the IP address. Basically, I would like to do ip addr del dev eth0 label eth0.100 which, according to documentation should be valid, but rather gives me: ip: RTNETLINK answers: Operation not supported In the mean time, I worked around using ip addr del $(ip addr list label eth0:100 | awk '{ print $2 }') dev eth0 label eth0.100

I have a VM on a host with bridged networking (hence, with its own MAC address). Both host and VM run CentOS. Their network is managed by simple /etc/sysconfig/network-scripts/ifcfg-enpXsY files. IPv4 works just fine. I have assigned an IPv6 address to the VM (the host also has one) which is routed correctly in the data centre. Most connections use IPv4, however (no DNS AAAA entry for the machine yet, still testing IPv6). When I boot up the VM it has full IPv6 connectivity. However, **after a while IPv6 connectivity stops working** (IPv6 magic?). I have narrowed to problem down to neighbour (ARP/NDISC cache) data: Not working, cannot ping or connect by IPv6 in or out: # ip -6 neighbour fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router STALE Fix/workaround to refresh the cache: # ip -6 neighbour flush dev enp1s2 # ip -6 neighbour (empty, as expected) Then ping6 the host from within the VM to fill the cache: # ping6 2912:1375:23:9a6c::2 PING 2912:1375:23:9a6c::2(2912:1375:23:9a6c::2) 56 data bytes 64 bytes from 2912:1375:23:9a6c::2: icmp_seq=1 ttl=64 time=2.35 ms 64 bytes from 2912:1375:23:9a6c::2: icmp_seq=2 ttl=64 time=0.468 ms ^C # ip -6 neighbour fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router REACHABLE 2912:1375:23:9a6c::2 dev enp1s2 lladdr 08:21:4b:b7:f8:31 DELAY IPv6 neighbour/ARP table restored to validity and connectivity is working in and out! **So my questions are:** 1. Why does the cache become stale? 2. What can I do to avoid it? Of course I could run those commands in a cron job (how often?) but I suppose that cannot really be needed for IPv6 to work in general? PS: I used a script for tests: **The IPv6 stack breaks down about every 20 minutes**. Can that be explained by RFCs?

I want to be able to route GTP-U traffic that arrives to my linux through two different interfaces. However, I want to route it using information inside the tunnel: inner ip addresses. My machine is not generating the GTP-U traffic, just a point in between. Is it possible to route GTP traffic in Linux using route, iptables or a similar approach? All I could find on this topic is and old GitHub repo that it is obsolet for Ubuntu 22 and higher.

I have a host machine and a guest VM. I am running a WireGuard VPN tunnel on the VM and would like to forward all traffic from the host to the VM and eventually through the VPN tunnel. The production setup will be more complex, but for now, I just want to make sure I am configuring the routes correctly on the host. On the host:

# ip route show table all
default via 10.0.0.1 dev enp1s0 table lan
default via 10.1.0.20 dev virbr0 metric 128
default via 10.0.0.1 dev enp1s0 proto dhcp src 10.0.0.100 metric 1024
10.0.0.0/24 dev enp1s0 proto kernel scope link src 10.0.0.100 metric 1024
10.0.0.1 dev enp1s0 proto kernel scope link src 10.0.0.100 metric 1024


# ip rule
0:      from all lookup local
32764:  from 10.1.0.0/24 lookup lan
32766:  from all lookup main
32767:  from all lookup default

# ip route get 1.1.1.1
1.1.1.1 via 10.1.0.20 dev virbr0 src 10.1.0.1 uid 0
    cache

# traceroute 1.1.1.1
1 _gateway (10.0.0.1) ...
...

So it appears that the result of ip route get 1.1.1.1 does not agree with the actual route chosen when I use traceroute 1.1.1.1. What might be the cause of this? --- **EDIT** It turns out ping 1.1.1.1 was quite helpful because I noticed the message "Redirect Host(New nexthop: 10.1.0.1)". This is part of IP that I was not familiar with, but apparently gateways will try to be efficient and send ICMP messages if there is a more direct route. The working configuration:

# ip route show table all
default via 10.0.0.1 dev enp1s0 table lan
10.0.0.1 dev enp1s0 table lan scope link
default via 10.1.0.20 dev virbr0 metric 128
default via 10.0.0.1 dev enp1s0 proto dhcp src 10.0.0.100 metric 1024
10.0.0.0/24 dev enp1s0 proto kernel scope link src 10.0.0.100 metric 1024
10.0.0.1 dev enp1s0 proto dhcp scope link src 10.0.0.100 metric 1024
10.1.0.0/24 dev virbr0 proto kernel scope link src 10.1.0.1

So it looks like the missing components were:

10.0.0.1 dev enp1s0 table lan scope link
10.1.0.0/24 dev virbr0 proto kernel scope link src 10.1.0.1

Although I'm still not sure why packets were routed to wrong gateway instead of being returned as unroutable. --- **EDIT 2** The configuration mistake was having ip rule add from 10.1.0.0/24 table lan instead of ip rule from 10.1.0.20 table lan. Because the host has the IP address 10.1.0.1 which is in 10.1.0.0/24, packets sent from the host were hitting that table. Still unsure of why 10.0.0.1 was not reported by ip route get. Maybe I needed to use ip route get from 10.0.0.100 to 1.1.1.1?

Thank you in advance for your attention to my question and your help. I have a rather specific task. I need to set up an IPIP tunnel between two Docker containers located on different physical servers. The network type for the containers is bridge. The IP of the first physical server (cluster01): 10.130.0.10 The IP of the second physical server (cluster02): 10.129.0.16 I created the ipip0 interface in the first container:

3: ipip0@NONE:  mtu 1430 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 172.21.0.2 peer 10.129.0.16
    inet 10.3.0.1/24 scope global ipip0
       valid_lft forever preferred_lft forever
    inet6 fe80::5efe:ac15:2/64 scope link 
       valid_lft forever preferred_lft forever

In the second container:

3: ipip0@NONE:  mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 172.23.0.3 peer 10.130.0.10
    inet 10.3.0.2/24 scope global ipip0
       valid_lft forever preferred_lft forever
    inet6 fe80::5efe:ac17:3/64 scope link 
       valid_lft forever preferred_lft forever

Next, I set up DNAT on both servers for packets with protocol 4 (IPIP): On cluster01: iptables -t nat -I PREROUTING -p 4 -d 10.130.0.10 -j DNAT --to-destination 172.21.0.2 On cluster02: iptables -t nat -I PREROUTING -p 4 -d 10.129.0.16 -j DNAT --to-destination 172.23.0.3 172.21.0.2 and 172.23.0.3 are the IPs of the Docker containers. When I try to ping from the first container to the second, there is no response:

bash-5.1# ping 10.3.0.2
PING 10.3.0.2 (10.3.0.2): 56 data bytes
^C
--- 10.3.0.2 ping statistics ---
94 packets transmitted, 0 packets received, 100% packet loss

However, on cluster02, I can see IPIP packets:

cluster02:~# tcpdump -i any -nn proto 4
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
15:38:07.255829 eth0  In  IP 10.130.0.10 > 10.129.0.16: IP 10.3.0.1 > 10.3.0.2: ICMP echo request, id 56, seq 0, length 64
15:38:08.255317 eth0  In  IP 10.130.0.10 > 10.129.0.16: IP 10.3.0.1 > 10.3.0.2: ICMP echo request, id 56, seq 1, length 64
15:38:09.255415 eth0  In  IP 10.130.0.10 > 10.129.0.16: IP 10.3.0.1 > 10.3.0.2: ICMP echo request, id 56, seq 2, length 64
15:38:10.255605 eth0  In  IP 10.130.0.10 > 10.129.0.16: IP 10.3.0.1 > 10.3.0.2: ICMP echo request, id 56, seq 3, length 64

However, there are no packets visible in the second container through tcpdump:

# tcpdump -i any -nn not tcp
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

The packets from the iptables rule on cluster02 are not captured:

cluster02:~# iptables -t nat -L PREROUTING -n -v
Chain PREROUTING (policy ACCEPT 432 packets, 20869 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       4    --  *      *       0.0.0.0/0            10.129.0.16          to:172.23.0.3
  999 54889 DOCKER     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Both servers are running Ubuntu 24.04 /proc/sys/net/ipv4/ip_forward is set to 1 Firewall is disabled with the command ufw disable What I have tried: 1) Adding the rule iptables -t raw -A PREROUTING -p 4 -d 10.129.0.16 -j NOTRACK 2) Marking packets and doing policy routing

iptables -t mangle -I PREROUTING -p 4 -d 10.129.0.16 -j MARK --set-mark 1
echo "100 ipip_route" >> /etc/iproute2/rt_tables
ip rule add fwmark 1 table ipip_route
ip route add default dev docker0 table ipip_route

But at least the packets are captured by the rule:

cluster02:~# iptables -t mangle -L PREROUTING -n -v
Chain PREROUTING (policy ACCEPT 5714 packets, 538K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  386 40144 MARK       4    --  *      *       0.0.0.0/0            10.129.0.16          MARK set 0x1

This didn't help – the packets still don't reach the second Docker container.

Just can't work out what the command is; hopefully simple for someone who knows. Debian 12 with two uplinks: wlan0 is the main connection but is quite unreliable and hp is 4G failover. I want one host (which doesn't use much data) to always use hp.

# Create a new route table.
$ sudo echo "2 solar" >>/etc/iproute2/rt_tables

# Set the default route on the new table.
$ sudo ip route add default dev hp table solar

# Route traffic from a specific host to the new table.
$ sudo ip rule add from 192.168.0.60 table solar

$ ip route show table solar
default dev hp scope link

That route show seems wrong -- the default is there but not the rule for the host. After a while -- I guess it takes some time to become effective -- the host loses its Internet connection. To undo it all:

sudo ip route flush table solar
sudo sed -i '/solar/s/^/#/' /etc/iproute2/rt_tables

I guess that ip rule add from... is wrong but I can't see what to do instead.

When I check the routing table I get following information: root@vmi24:/home/user# ip route default via 194.104.212.225 dev eth0 onlink 194.104.212.224/27 via 194.104.212.225 dev eth0 When I want to add a route to 10.0.0.0/24 via 194.104.212.226 (which is part of the directly connected 194.104.212.224/27 network, I get following error: root@vmi24:/home/user# ip route add 10.0.0.0/24 via 194.104.212.226 Error: Nexthop has invalid gateway. Another strange issue is that if I delete the default gateway, I cannot add it again because the add command for the default gateway fails with the same "Nexthop has invalid gateway" error. I am using Debian 10 on a hosted VM. When I try this on a KALI based machine have no issue adding a static route. I am running out of options, as this phenomenon prevents me from activating an openvpn (it fails inserting the /32 route to the openvpn server via the directly connected gateway on the eth0 interface What do I fail to see? What do I overlook? I have found many problems with next-hop documented but most if not all are due to not directly connected or unreachable next-hops.

I'm using a fresh minimal Ubuntu server 24.04.1 LTS install. I run these commands as root to set up networking and do some experiments:

apt install netcat-traditional

ip netns add ns1
ip netns add ns2

ip link add my_veth1 type veth peer name my_veth2

ip link set my_veth1 up netns ns1
ip link set my_veth2 up netns ns2

ip -n ns1 address add 1.2.3.4 dev my_veth1
ip -n ns1 route add 2.3.4.0/24 dev my_veth1

ip netns exec ns2 nc -u -l -p 8080

then I run this from another terminal:

ip netns exec ns1 nc -u 2.3.4.5 8080  ns2 my_veth2 gives the same output

So I tried creating the ARP table entry manually...

sh ip -n ns1 neighbour add 2.3.4.5 dev my_veth1 lladdr $(ip netns exec ns2 cat /sys/class/net/my_veth2/address)

And now apparently the UDP packet is being sent

$ ip netns exec ns1 tcpdump -l -i my_veth1 00:24:15.164245 IP 1.2.3.4.36170 > 2.3.4.5.8080: UDP, length 39

> ns2 my_veth2 gives the same output

However, the first terminal that has the UDP netcat server running still doesn't output anything. Why?

---

**EDIT 3:** After doing all of the above, I tried assigning an IP address to my_veth2:

sh ip -n ns2 address add 2.3.4.5 dev my_veth2

And now, when I send the UDP packet, I get this error in the terminal that is running netcat in listen mode:

sh no connection : Network is unreachable ``` Why? I mean, of course the network is unreachable, but that shouldn't stop the server from receiving and displaying UDP packets. In fact, that error is only displayed when it receives the UDP packet. So even if it knows that it can't answer, it should be able to receive and display the message, right?

I'm using a fresh minimal Ubuntu server 24.04.1 LTS install. I run these commands as root to set up networking and do some experiments: > If you have seen [this post](https://unix.stackexchange.com/q/787076/203214) , it's the same setup but with the ip address 2.3.4.5 assigned to my_veth2 and the routing table entry 1.2.3.0/24 to make sure data can be sent and received from each network namespace.

# Terminal 1

apt install -y netcat-traditional tcpdump

ip netns add ns1
ip netns add ns2

ip link add my_veth1 type veth peer name my_veth2

ip link set my_veth1 up netns ns1
ip link set my_veth2 up netns ns2

ip -n ns1 address add 1.2.3.4 dev my_veth1
ip -n ns1 route add 2.3.4.0/24 dev my_veth1
ip -n ns2 address add 2.3.4.5 dev my_veth2
ip -n ns2 route add 1.2.3.0/24 dev my_veth2

ip netns exec ns2 nc -l -p 8080

then I open 2 more terminals to run tcpdump in each network namespace:

# Terminal 2
ip netns exec ns1 tcpdump -i my_veth1

# Terminal 3
ip netns exec ns2 tcpdump -i my_veth2

then I open one more last terminal to send data to the netcat server in ns2 from ns1:

# Terminal 4
ip netns exec ns1 nc 2.3.4.5 8080 <<< 'Hello world from network namespace ns1'

Results: * The message sent from Terminal 4 is printed in Terminal 1, as expected. * No packets are being shown in either tcpdump. **WHY?**

I run this command:

ip link add dev proof_of_concept_virtual_network_interface type veth

and I get this error message:

Error: Attribute failed policy validation.

The error is not descriptive or helpful whatsoever.

This question is a follow-up on https://unix.stackexchange.com/q/312435 . When the system already received routing advertisements and configured itself for the new routes: How can I view them as they are configured, using the ip command?

I'm trying to run socat forward ttyACM0 into UDP. It works with command.

socat UDP-LISTEN:14550,fork,reuseaddr FILE:/dev/ttyACM0,b57600,raw

Problem is, I need to access socat via ip address, which is inside netns. I tried to enter this command:

ip netns exec int socat UDP-LISTEN:14550,fork,reuseaddr FILE:/dev/ttyACM0,b57600,raw

, which displays error:

2024/10/10 14:14:37 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:38 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:39 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:40 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:41 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:42 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:43 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:44 socat E write(5, 0x1d54000, 44): Connection refused
2024/10/10 14:14:45 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:46 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:47 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:48 socat E write(5, 0x1d54000, 40): Connection refused
2024/10/10 14:14:49 socat E read(5, 0x1d54000, 8192): Connection refused
2024/10/10 14:14:50 socat E read(5, 0x1d54000, 8192): Connection refused

How to properly run socat inside netns?

I'm currently investigating a strange network issue. Consider the following IPv6 Router Advertisement (note the **prefix lifetimes**, 5400 and 2700, respectively.):

$ rdisc6 -1 wlan0
Soliciting ff02::2 (ff02::2) on wlan0...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :          Yes
Stateful other conf.      :          Yes
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :      3600000 (0x0036ee80) milliseconds
Retransmit time           :  unspecified (0x00000000)
 Recursive DNS server     : 2a02:####:####:####:f2af:85ff:fe11:70d
  DNS server lifetime     :          300 (0x0000012c) seconds
 Prefix                   : 2a02:####:####:####::/64
  On-link                 :          Yes
  Autonomous address conf.:          Yes
  Valid time              :         5400 (0x00001518) seconds
  Pref. time              :         2700 (0x00000a8c) seconds
 Route                    : 2a02:####:####:####::/62
  Route preference        :       medium
  Route lifetime          :         5400 (0x00001518) seconds
 Route                    : ::/0
  Route preference        :       medium
  Route lifetime          :         1800 (0x00000708) seconds
 Source link-layer address: ##:##:##:##:##:##
 from fe80::f2af:85ff:fe11:70d

I have observed that the lifetimes reported for one particular address are sometimes slightly *higher* than the values in the router advertisement. inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 (...) valid_lft 5401sec preferred_lft 2701sec (This output is handcrafted. I cannot get a live capture right now because of the network issue I'm ultimately trying to solve, but it is representative of how the lifetimes can be **a second or so higher** than the RA value.) Why would that be? I'm currently considering whether this is a possible bug in the network stack that is used in Debian (12), because I'm also observing the following: This is a router advertisement with both prefix lifetimes set to 0, and as far as I understand, this is not an error, but the router is deliberately trying to invalidate that prefix.

$ rdisc6 -1 wlan0
Soliciting ff02::2 (ff02::2) on wlan0...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :          Yes
Stateful other conf.      :          Yes
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :      3600000 (0x0036ee80) milliseconds
Retransmit time           :  unspecified (0x00000000)
 Recursive DNS server     : 2a02:####:####:####:f2af:85ff:fe11:70d
  DNS server lifetime     :          300 (0x0000012c) seconds
 Prefix                   : 2a02:####:####:####::/64
  On-link                 :          Yes
  Autonomous address conf.:          Yes
  Valid time              :            0 (0x00000000) seconds
  Pref. time              :            0 (0x00000000) seconds
 Route                    : ::/0
  Route preference        :       medium
  Route lifetime          :         1800 (0x00000708) seconds
 Source link-layer address: ##:##:##:##:##:##
 from fe80::f2af:85ff:fe11:70d

In this case, the preferred_lft reported by ip address *also* varies by 1 second (while the valid_lft just seems to tick down normally from 5400s in real-time). In practice, when I spam ip address, preferred_lft periodically toggles between 1s and 0s. Furthermore, ip monitor outputs this about every few seconds:

2: wlan0    inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global dynamic noprefixroute
       valid_lft 4916sec preferred_lft 1sec
2: wlan0    inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global deprecated dynamic noprefixroute
       valid_lft 4915sec preferred_lft 0sec
2: wlan0    inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global dynamic noprefixroute
       valid_lft 4913sec preferred_lft 1sec
2: wlan0    inet6 2a02:####:####:####:2f89:f9d2:504f:595d/64 scope global deprecated dynamic noprefixroute
       valid_lft 4912sec preferred_lft 0sec
(and so on)

This also causes severe /var/log/syslog spam:

2023-12-19T19:22:15.143458+01:00 ... avahi-daemon: Registering new address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.*.
2023-12-19T19:22:16.181261+01:00 ... avahi-daemon: Withdrawing address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.
2023-12-19T19:22:18.011506+01:00 ... avahi-daemon: Registering new address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.*.
2023-12-19T19:22:19.240632+01:00 ... avahi-daemon: Withdrawing address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.
(and so on)

This behavior is certainly unwanted. The arbitrary addition of a small value to the preferred lifetime in the router advertisement could explain this partly. I was able to observe this on Debian 12 and Raspberry Pi OS. I was **not** able to observe this on Arch Linux and Lubuntu. Tested on 3 different devices. *However, tests may not be conclusive* because I cannot control my router, and it does not always send the same router advertisements, and I do not have an isolated test environment.