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

2015-11-17 Thread Martin Pitt 
Ritesh Raj Sarraf [2015-11-14 15:18 +0530]:
> > > IPForward=yes
> > 
> > I believe this is the problem. Because we do not enable iptables
> > support in networkd, then it cannot set this flag.

This should be unrelated. This is a sysctl, not iptables.

> I am not sure on how this works in systemd-networkd, but from the
> manpage, it states that this switch is important. And that it is
> important irrespective of the standard means through which we've all
> been enabling IP Forwarding in Linux so far.

Note that this has been changed/fixed in the upcoming 228. networkd
now does not disable forwarding any more if/when IPForward= is not
given, but merely enables it when it's explicitly set to "yes".
Otherwise the kernel default now applies again, which means that tools
which enable it globally will work again.

I brought this up a while ago on the ML:

  
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2015-October/008997.html

but I'm glad that we now don't have to do this any more as 228 will
fix this more sensibly.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

2015-11-17 Thread Ritesh Raj Sarraf 
Thanks Martin.

For the issue in itself, it now looks like something specific to
systemd.

I'll see if I can take it up with upstream devs.


Thanks,
Ritesh


On Tue, 2015-11-17 at 17:44 +0100, Martin Pitt wrote:
> Ritesh Raj Sarraf [2015-11-14 15:18 +0530]:
> > > > IPForward=yes
> > > 
> > > I believe this is the problem. Because we do not enable iptables
> > > support in networkd, then it cannot set this flag.
> 
> This should be unrelated. This is a sysctl, not iptables.
> 
> > I am not sure on how this works in systemd-networkd, but from the
> > manpage, it states that this switch is important. And that it is
> > important irrespective of the standard means through which we've
> > all
> > been enabling IP Forwarding in Linux so far.
> 
> Note that this has been changed/fixed in the upcoming 228. networkd
> now does not disable forwarding any more if/when IPForward= is not
> given, but merely enables it when it's explicitly set to "yes".
> Otherwise the kernel default now applies again, which means that
> tools
> which enable it globally will work again.
> 
> I brought this up a while ago on the ML:
> 
>   http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/20
> 15-October/008997.html
> 
> but I'm glad that we now don't have to do this any more as 228 will
> fix this more sensibly.
> 
> Martin
> 
-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



signature.asc
Description: This is a digitally signed message part
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

2015-11-14 Thread Ritesh Raj Sarraf 
On Sat, 2015-11-14 at 15:18 +0530, Ritesh Raj Sarraf wrote:
> That said, it still does not work. And the odd part is, networking is
> only broken for IPv4.

From within the container, this reporting from networkctl is
interesting.


It states:

root@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
root@deb-template:~# networkctl status -a
● 1: lo
   Link File: n/a
Network File: n/a
Type: loopback
   State: carrier (unmanaged)
 MTU: 65536
 Address: 127.0.0.1
  ::1

● 2: host0
   Link File: n/a
Network File: /lib/systemd/network/80-container-host0.network
Type: ether
   State: routable (configured)
  HW Address: c6:8a:3c:ae:02:52
 MTU: 1500
 Address: 172.16.221.159
  169.254.190.70
  fe80::c48a:3cff:feae:252
 Gateway: 172.16.20.1
root@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 ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms

root@deb-template:~#


I am not sure how it determines the "routable" status. The default
gateway is 172.16.20.1, which is not pingable.

 
-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



signature.asc
Description: This is a digitally signed message part
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

2015-11-14 Thread Ritesh Raj Sarraf 
Hello Felipe,


On Thu, 2015-11-12 at 10:02 -0300, Felipe Sateler wrote:
> rrs@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 am not sure on how this works in systemd-networkd, but from the
manpage, it states that this switch is important. And that it is
important irrespective of the standard means through which we've all
been enabling IP Forwarding in Linux so far.

As I mentioned in the bug report, my intent is to replace my legacy
setup with systemd-networkd. So the current bridge setup (lxcbr0)
already has all the routing/forwarding setup in place. In fact, while
exploring systemd-n, I adapted the setup to also include sysbr0.

That said, it still does not work. And the odd part is, networking is
only broken for IPv4.


> 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.
> 

It is enabled in /proc for the host kernel already.

rrs@chutzpah:~$ cat /proc/sys/net/ipv4/conf/sysbr0/forwarding 
1
15:10 ♒♒♒   ☺    


> > 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@chutzpah:~$ ssh fe80::c48a:3cff:feae:252%5
> > rrs@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
> > 

Given that the interface does get a DHCP lease, I am inclined to think
it may be a systemd bug, or a Debian specific change.

That was the reason why I thought of filing it with us first.

What do you guys think? Should I take it up with Lennart ?


> > 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).
> 

We should still file the bug report as a Feature Request. iptables will
stay for some time. It would be good to have nftables by default, but
assuming that iptables is obsolete, is not going to happen any time
soon.

I think upstream had a similar view about /var/lib/machines/, where in
they chose btrfs only. Which led to users with ext4, with almost no
functionality. Please see: https://github.com/systemd/systemd/issues/13
08 for details. It is confirmed as a feature request.


-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



signature.asc
Description: This is a digitally signed message part
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

2015-11-14 Thread Ritesh Raj Sarraf 
On Thu, 2015-11-12 at 10:02 -0300, Felipe Sateler wrote:
> 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.

I think this part, to an extent is taken care of. There were reports
upstream about it. And the messaging has been tuned accordingly.

root@deb-template:~# systemctl status systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service;
enabled; vendor preset: enabled)
   Active: active (running) since Sat 2015-11-14 15:28:29 IST; 38s ago
 Docs: man:systemd-networkd.service(8)
 Main PID: 281 (systemd-network)
   Status: "Processing requests..."
   CGroup: /machine.slice/systemd-nspawn@digikam.service/system.slice/s
ystemd-networkd.service
   └─281 /lib/systemd/systemd-networkd

Nov 14 15:28:28 deb-template systemd[1]: Stopped Network Service.
Nov 14 15:28:28 deb-template systemd[1]: Starting Network Service...
Nov 14 15:28:29 deb-template systemd-networkd[281]: host0: Cannot
configure IPv4 forwarding for interface host0: Read-only file system
Nov 14 15:28:29 deb-template systemd-networkd[281]: Enumeration
completed
Nov 14 15:28:29 deb-template systemd[1]: Started Network Service.
Nov 14 15:28:29 deb-template systemd-networkd[281]: host0: DHCPv4
address 172.16.221.159/16 via 172.16.20.1
Nov 14 15:28:35 deb-template systemd-networkd[281]: host0: Configured


The "cannot configure IPv4." is now a warning message.

https://github.com/systemd/systemd/pull/495/files


-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



signature.asc
Description: This is a digitally signed message part
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

2015-11-14 Thread Ritesh Raj Sarraf 
On Sat, 2015-11-14 at 15:27 +0530, Ritesh Raj Sarraf wrote:
> 
> I am not sure how it determines the "routable" status. The default
> gateway is 172.16.20.1, which is not pingable.

The same setup, now bound to the traditional bridge, is working.

root@deb-template:~# networkctl status
●  State: routable
 Address: 172.16.10.174 on host0
  169.254.190.70 on host0
  fe80::c48a:3cff:feae:252 on host0
 Gateway: 172.16.10.1 on host0
 DNS: 172.16.10.1
root@deb-template:~# apt-get update
Get:1 http://ftp.debian.org unstable InRelease [256 kB]
Get:2 http://ftp.debian.org experimental InRelease [187 kB]
Get:3 http://ftp.debian.org unstable/main amd64 Packages/DiffIndex
[7,876 B]
Get:4 http://ftp.debian.org unstable/contrib amd64 Packages/DiffIndex
[7,681 B]
Get:5 http://ftp.debian.org unstable/non-free amd64 Packages/DiffIndex
[6,025 B]
Get:6 http://ftp.debian.org unstable/contrib Translation-en/DiffIndex
[2,023 B]
Get:7 http://ftp.debian.org unstable/main Translation-en/DiffIndex
[7,876 B]
Get:8 http://ftp.debian.org unstable/non-free Translation-en/DiffIndex
[3,403 B]
Get:9 http://ftp.debian.org experimental/main amd64 Packages/DiffIndex
[7,819 B]
Get:10 http://ftp.debian.org experimental/contrib amd64
Packages/DiffIndex [1,195 B]
Get:11 http://ftp.debian.org experimental/non-free amd64
Packages/DiffIndex [1,195 B]
Get:12 http://ftp.debian.org experimental/contrib Translation-
en/DiffIndex [919 B]
Get:13 http://ftp.debian.org experimental/main Translation-en/DiffIndex 
[7,819 B]



-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



signature.asc
Description: This is a digitally signed message part
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

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

2015-11-12 Thread Felipe Sateler 
On 12 November 2015 at 04:09, Ritesh Raj Sarraf  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@chutzpah:~$ brctl show
> bridge name bridge id   STP enabled interfac
> es
> lxcbr0  8000.   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@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@chutzpah:~$ ssh fe80::c48a:3cff:feae:252%5
> rrs@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@deb-template:~$ ip a
> 1: lo:  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@if6:  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@deb-template:~$
>
>
> The Container did get the IPv4 address but is not pingable either way
>
> rrs@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@chutzpah:~$ ssh 172.16.221.159
> ssh: connect to host 172.16.221.159 port 22: No route to host
> 12:15 ♒♒♒☹  => 255
>
>
> root@deb-template:~# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse
> Iface
> 0.0.0.0 172.16.20.1 0.0.0.0 UG1024   00
> host0
> 0.0.0.0 0.0.0.0 0.0.0.0 U 2048   00
> host0
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0  00
> host0
> 172.16.0.0  0.0.0.0 255.255.0.0 U 0  00
> host0
> 172.16.20.1 0.0.0.0 255.255.255.255 UH1024   00
> host0
>
> root@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@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