[systemd-devel] systemd networking : problems with bridges

[Andrei Borzenkov]

В Sat, 3 Jan 2015 01:24:48 -0500
Charles Devereaux <systemd at guylhem.net> пишет:

> Hello
> 
> I'm trying to configure systemd networking for a bridge, using v217-stable
> from anongit.freedesktop.org/systemd/systemd-stable
> 
> I mostly have 3 problems:
> 
> 1- 3 - I do not understand how to properly use systemd-networkd-wait-online
> 
> I have one service (establishing the uplink) with:
> After=network-online.target
> 

So if I understand it correctly you want

- configure one interface
- start some program that establishes what you call "uplink". I presume
  it results in one more interface appearing?
- configure new "uplink" interface

Am I right? Could you explain in some more details your setup?
...

> 
> If I try to start it manually, it hangs, even if I specify
> --interface=wlan0 in its service.
>

--interface parameter does not restrict which links are watched -
it simply delays checking their state until all named interfaces are
present.

> I think the reason might be br0, that is seen as "not ready" because of the
> uplink issue:
> 
> $ networkctl status 3
> ● 3: br0
>    Link File: n/a
> Network File: /etc/systemd/network/bridge.network
>         Type: ether
>        State: no-carrier (configuring)
> (...)
> 

Yes, systemd-networkd-online will wait for all known links to become
ready.

> If I manually start the uplink, networkctl is happy (State: routable
> (configured) and systemd-networkd-wait-online works. So it's a catch 21:
> uplink can't start because systemd-networkd-wait-online does not indicate
> success because uplink can't start.
> 
> Is there an option I could use on bridge.network to indicate it shouldn't
> be considered by systemd-network-wait-online (a bit like it ignores the
> loopback interfaces)?
> 

This sounds like broken approach. If I follow your configuration
correctly, br0 is *the* interface that provides your network
connectivity so wait-online should wait until it is up and running.
What is missing here is the ability to express dependency on individual
interfaces. Alternatively support for callouts would help (start
external helper to configure uplink as soon as physical interface is
ready). I do not think either is possible right now.

> 2- Updating the bridge configuration without requesting too many DHCP
> addresses.
> 
> The bridge is properly brought up by systemd-networkd, but I do not see how
> to take it down or how to change some options when say the .netdev file has
> changed (ex: changed the mac address, new dhcp option, etc).
> 
> At the moment, I work around the problem with systemctl stop
> systemd-networkd && systemctl start systemd-network but this cause some
> dhcp weirdness on the other network interfaces using DHCP, with a new IP
> being configured every time.
> 

I think it was discussed and for now it is intentional - you need to
restart networkd to pick configuration changes but networkd will not
wipe clean existing configuration.

> For exemple, after a few tries I currently have:
> 
> $ networkctl status
>        State: routable
>      Address: 192.168.2.44
>               192.168.2.43
>               192.168.2.42
>               192.168.2.41
>               192.168.2.40
>               192.168.2.39
>               192.168.2.38
> (...)
> 
> I'm not sure why it's hogging the DHCP addresses since the corresponding
> .network file is quite simple:
> 
> $ cat wireless.network
> [Match]
> Name=w*
> Virtualization=no
> 
> [Network]
> DHCP=both
> 
> [DHCP]
> UseHostname=false
> 
> Does networkctl supports turning interfaces up/down and restarting them? Is
> it a planned feature?
> 
> If not, I would suggest adding a least a restart feature,  so that the
> interface can be reconfigured in isolation without affecting the DHCP IPs
> of the other interfaces. For bridges, this restart feature could do the
> ifconfig down and brctl delbr.
> 
> It might be good to do the same when systemd-network is restarted, so that
> the new options (ex: cloned mac addres) are applied.
> 
> 3- Acquiring DHCP leases *AND* serving DHCP on br0
> 
> br0 is configured as:
> $ cat bridge.network
> [Match]
> Name=br0
> 
> [Network]
> DHCP=both
> Address=192.168.3.224/28
> DHCPServer=yes
> 
> [DHCP]
> UseHostname=false
> UseDNS=false
> RequestBroadcast=yes
> 
> ap0 is a local access point, bridged to an uplink on br0
> 
> The idea is to have 192.168.3.224 configured and serve DHCP address in the
> /28 (16 addresses) during the uplink confirmation. When the uplink is up,
> it  will provide better addresses and configuration to the clients. With
> the configuration above, the DHCP address offered by the uplink is properly
> seen by networkctl, and configured. It respond to pings.
> 
> The DHCP range is properly used to give IP addresses like 192.168.3.225 to
> clients.
> 
> I tested with a OSX Yosemite client : when the uplink is established, the
> clients get the new lease, yet they still seem to try and use the old one,
> as I can see packets trying to use the local link instead of the uplink :
> ip6tables forward denied: IN=br0 OUT=wlan0 PHYSIN=ap0 MAC=xxxxx
> SRC=192.168.3.225 DST=local-endpoint
> 
> With another OSX Yosemite, only the original lease is acquired (weird)
> 
> Would it be possible to make the DHCPServer release the ip and stop as soon
> as the uplink is up? (which relates to the previous question of being able
> to apply changes to a single interface without affecting the others)
> 

It is up to client to renew address. May be networkd could optionally
set very short lease time to force renewal.