Bug#804832: systemd-networkd fails to configure IPv4 Bridge Network

[Felipe Sateler]

On 12 November 2015 at 04:09, Ritesh Raj Sarraf <rrs at researchut.com> wrote:
> Package: systemd
> Version: 227-2
> Severity: normal
>
> With the new systemd-networkd support, my intent is to explore the
> possiblity of moving away from my old bridge setup, to the new setup
> provided by systemd-networkd.
>
>
> My old setup was:
>
> rrs at chutzpah:~$ brctl show
> bridge name     bridge id               STP enabled     interfac
> es
> lxcbr0          8000.000000000000       no
> sysbr0          8000.bac48a59e054       no              vb-
> digikam
> 12:09 ♒♒♒   ☺
>
>
> As you can see, lxcbr0 is the old seutp. On which, I've enabled the IP
> Forwarding and NAT rules. When that interface is used with VMs and
> Containers as a bridge, IPv4 networking works fine.
>
>
> With systemd, I created a similar setup with sysbr0. Defined it as a
> Bridge device and am running a (systemd internal) DHCP server on it.
>
>
> rrs at chutzpah:~$ cat /etc/systemd/network/localBridge.network
> [Match]
> Name=sysbr0
>
> [Network]
> DHCPServer=yes
> IPForward=yes

I believe this is the problem. Because we do not enable iptables
support in networkd, then it cannot set this flag.

I'd love to have iptables support enabled, but upstream wants to
switch to nftables at some point. Switch costs are lower if there was
never any support as there is nothing we can break.

However, I think networkd should emit a warning if a directive is not
acted upon due to configure switches.

You could try enabling ip forwarding manually on the sysbr0 interface
to see if that works.

> Address=172.16.20.1
> 12:12 ♒♒♒   ☺
>
>
> In the container, the network does get an IPv4 DHCP address. But it
> does not
> work. Interestingly the IPv6 network is working fine.
>
> rrs at chutzpah:~$ ssh fe80::c48a:3cff:feae:252%5
> rrs at fe80::c48a:3cff:feae:252%5's password:
>
> The programs included with the Debian GNU/Linux system are free
> software;
> the exact distribution terms for each program are described in the
> individual files in /usr/share/doc/*/copyright.
>
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> permitted by applicable law.
> Last login: Thu Nov 12 11:58:37 2015 from
> fe80::b8c4:8aff:fe59:e054%host0
>
> rrs at deb-template:~$ ip a
> 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: host0 at if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP group default qlen 1000
>     link/ether c6:8a:3c:ae:02:52 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>     inet 169.254.190.70/16 brd 169.254.255.255 scope link host0
>        valid_lft forever preferred_lft forever
>     inet 172.16.221.159/16 brd 172.16.255.255 scope global dynamic
> host0
>        valid_lft 2539sec preferred_lft 2539sec
>     inet6 fe80::c48a:3cff:feae:252/64 scope link
>        valid_lft forever preferred_lft forever
> rrs at deb-template:~$
>
>
> The Container did get the IPv4 address but is not pingable either way
>
> rrs at chutzpah:~$ ping 172.16.221.159
> PING 172.16.221.159 (172.16.221.159) 56(84) bytes of data.
> >From 172.16.10.1 icmp_seq=1 Destination Host Unreachable
> >From 172.16.10.1 icmp_seq=2 Destination Host Unreachable
> >From 172.16.10.1 icmp_seq=3 Destination Host Unreachable
> >From 172.16.10.1 icmp_seq=4 Destination Host Unreachable
> >From 172.16.10.1 icmp_seq=5 Destination Host Unreachable
> >From 172.16.10.1 icmp_seq=6 Destination Host Unreachable
> ^C
>
> --- 172.16.221.159 ping statistics ---
> 7 packets transmitted, 0 received, +6 errors, 100% packet loss, time
> 6031ms
> pipe 3
> 12:15 ♒♒♒    ☹  => 1
>
> rrs at chutzpah:~$ ssh 172.16.221.159
> ssh: connect to host 172.16.221.159 port 22: No route to host
> 12:15 ♒♒♒    ☹  => 255
>
>
> root at deb-template:~# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 0.0.0.0         172.16.20.1     0.0.0.0         UG    1024   0        0
> host0
> 0.0.0.0         0.0.0.0         0.0.0.0         U     2048   0        0
> host0
> 169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0
> host0
> 172.16.0.0      0.0.0.0         255.255.0.0     U     0      0        0
> host0
> 172.16.20.1     0.0.0.0         255.255.255.255 UH    1024   0        0
> host0
>
> root at deb-template:~# networkctl status
> ●      State: routable
>      Address: 172.16.221.159 on host0
>               169.254.190.70 on host0
>               fe80::c48a:3cff:feae:252 on host0
>      Gateway: 172.16.20.1 on host0
>
> My guess is that networkctl is giving the routable status because the
> IPv6 network is working.
>
> root at deb-template:~# ping 172.16.20.1
> PING 172.16.20.1 (172.16.20.1) 56(84) bytes of data.
> ^C
> --- 172.16.20.1 ping statistics ---
> 8 packets transmitted, 0 received, 100% packet loss, time 7056ms
>
>
>
> I think this is a systemd specific problem. I think there are some bug
> reports related to similar symptoms. But before filing upstream, I
> wanted to check with you guys first.

So, I think there are two bugs. One downstream (iptables support is
disabled), and one upstream (networkd should complain loudly when
ipforwarding/masquerading is set and iptables support is not enabled).


-- 

Saludos,
Felipe Sateler