[systemd-devel] systemd-networkd bridge not renewing DHCP lease

Tue Jul 29 05:12:07 PDT 2014

Hello,

I run an Archlinux home server connected to a netgear home router. I use 
a bridge because among other things, the server does KVM virtualization. 
My problem is that once the DHCP lease on br0 expires, it is not renewed.

Here's `ip a` before and after br0 loses the ip. You can see the 
"valid_lft 42sec" just before the IP is lost. The lease appears to be 
valid for 24 hours.

-------------before---------------
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
group default
     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: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
master br0 state UP group default qlen 1000
     link/ether bc:5f:f4:90:23:85 brd ff:ff:ff:ff:ff:ff
     inet6 fe80::be5f:f4ff:fe90:2385/64 scope link
        valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state 
UP group default
     link/ether b6:29:d8:20:20:11 brd ff:ff:ff:ff:ff:ff
     inet 192.168.1.33/24 brd 192.168.1.255 scope global dynamic br0
        valid_lft 42sec preferred_lft 42sec
     inet6 fe80::b429:d8ff:fe20:2011/64 scope link
        valid_lft forever preferred_lft forever
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
master br0 state UNKNOWN group default qlen 500
     link/ether fe:54:00:55:09:68 brd ff:ff:ff:ff:ff:ff
     inet6 fe80::fc54:ff:fe55:968/64 scope link
        valid_lft forever preferred_lft forever
-------------after---------------
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
group default
     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: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
master br0 state UP group default qlen 1000
     link/ether bc:5f:f4:90:23:85 brd ff:ff:ff:ff:ff:ff
     inet6 fe80::be5f:f4ff:fe90:2385/64 scope link
        valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state 
UP group default
     link/ether b6:29:d8:20:20:11 brd ff:ff:ff:ff:ff:ff
     inet6 fe80::b429:d8ff:fe20:2011/64 scope link
        valid_lft forever preferred_lft forever
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
master br0 state UNKNOWN group default qlen 500
     link/ether fe:54:00:55:09:68 brd ff:ff:ff:ff:ff:ff
     inet6 fe80::fc54:ff:fe55:968/64 scope link
        valid_lft forever preferred_lft forever
----------------------------------

Below are the relevant configs.

/etc/systemd/network/bridge-data.netdev:
----------------------------------
[NetDev]
Name=br0
Kind=bridge
----------------------------------

/etc/systemd/network/bridge-data.network:
----------------------------------
[Match]
Name=br0

[Network]
DHCP=yes
----------------------------------

/etc/systemd/network/enterprise.network:
----------------------------------
[Match]
Name=en*

[Network]
Bridge=br0
----------------------------------

I've enabled DEBUG logging for systemd-networkd, but it's not giving me 
anything useful. Here's what I see at the moment the IP is lost (at 
17:44:49) with some context:

----------------------------------
Jul 23 17:39:02 enterprise systemd-networkd[25474]: DHCPv6 CLIENT: Next 
retransmission in 1min 48.764460s
Jul 23 17:40:51 enterprise systemd-networkd[25474]: DHCPv6 CLIENT: Sent 
SOLICIT
Jul 23 17:40:51 enterprise systemd-networkd[25474]: DHCPv6 CLIENT: Next 
retransmission in 1min 55.518924s
Jul 23 17:42:47 enterprise systemd-networkd[25474]: DHCPv6 CLIENT: Sent 
SOLICIT
Jul 23 17:42:47 enterprise systemd-networkd[25474]: DHCPv6 CLIENT: Next 
retransmission in 2min 4.769016s
Jul 23 17:44:49 enterprise systemd-networkd[25474]: br0             : 
removed address: 192.168.1.33/24
Jul 23 17:44:52 enterprise systemd-networkd[25474]: DHCPv6 CLIENT: Sent 
SOLICIT
Jul 23 17:44:52 enterprise systemd-networkd[25474]: DHCPv6 CLIENT: Next 
retransmission in 1min 51.959760s
Jul 23 17:46:44 enterprise systemd-networkd[25474]: DHCPv6 CLIENT: Sent 
SOLICIT
Jul 23 17:46:44 enterprise systemd-networkd[25474]: DHCPv6 CLIENT: Next 
retransmission in 2min 5.687352s
Jul 23 17:48:49 enterprise systemd-networkd[25474]: DHCPv6 CLIENT: Sent 
SOLICIT
----------------------------------

As you can see, it just says "br0: removed address:" and that's it. 
Every now and then (less than once a day) there will be something like this:

----------------------------------
Jul 25 10:11:25 enterprise systemd-networkd[19106]: DHCPv6 CLIENT: Sent 
SOLICIT
Jul 25 10:11:25 enterprise systemd-networkd[19106]: DHCPv6 CLIENT: Next 
retransmission in 1min 57.978432s
Jul 25 10:12:31 enterprise systemd-networkd[19106]: DHCP CLIENT 
(0x461b140f): REQUEST (rebinding)
Jul 25 10:12:31 enterprise systemd-networkd[19106]: DHCP CLIENT 
(0x461b140f): NAK
Jul 25 10:12:31 enterprise systemd-networkd[19106]: DHCP CLIENT 
(0x461b140f): STOPPED: No lease
Jul 25 10:12:31 enterprise systemd-networkd[19106]: br0             : IP 
address in use.
Jul 25 10:13:23 enterprise systemd-networkd[19106]: DHCPv6 CLIENT: Sent 
SOLICIT
Jul 25 10:13:23 enterprise systemd-networkd[19106]: DHCPv6 CLIENT: Next 
retransmission in 2min 1.184604s
----------------------------------

but it doesn't seem to have any negative effect and it's probably 
unrelated to the problem.

I also don't see anything in dmesg. Other machines on the network are 
unaffected so I doubt it has anything to do with the router.

It's a Realtek onboard RTL8111/8168/8411 adaptor and Linux uses the 
r8169 driver automatically. I'm aware that there's a dedicated r8168 
driver by realtek, but I'm using the same mainboard (same revision) with 
Arch in another machine (without a bridge) and I never had any problems. 
Hence, I doubt that the r8169 driver is the problem but I will try using 
it on occasion. (You can imagine that debugging this problem is a pain 
because I always have to wait 24h to see if a change had any effect...)

This is systemd 215 built on Jul. 8.

Thanks,
Carol