Bug#814566: networkd >= 229-1 starts assigning IPv6 addresses/ routes to lower bridge members

[Stefan Lippers-Hollmann]

Hi

On 2016-02-13, Stefan Lippers-Hollmann wrote:
> On 2016-02-13, Stefan Lippers-Hollmann wrote:
[...]
> Apparently I can work around this problem by explicitly disabling
> IPv6AcceptRouterAdvertisements for enp2s0 and enp4s0:
[...]
> $ ip -6 r
> 2001:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
> fd01:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
> fe80::/64 dev br0  proto kernel  metric 256  pref medium
> fe80::/64 dev br1  proto kernel  metric 256  pref medium
> fe80::/64 dev enp2s0  proto kernel  metric 256  pref medium
> fe80::/64 dev enp4s0  proto kernel  metric 256  pref medium
> default via fe80::92f6:52ff:fef6:c88 dev br0  proto ra  metric 1024  pref medium

No, this doesn't actually work - after a couple of minutes the IPv6
addresses and route 'bleed over' to the second bridge (no, there isn't
any connection between br0 and br1, neither any forwarding configured).

$ ip -6 r
2001:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
2001:470:1234:10::/64 dev br1  proto ra  metric 1024  pref medium
fd01:470:1234:10::/64 dev br0  proto ra  metric 1024  pref medium
fd01:470:1234:10::/64 dev br1  proto ra  metric 1024  pref medium
fe80::/64 dev br0  proto kernel  metric 256  pref medium
fe80::/64 dev br1  proto kernel  metric 256  pref medium
fe80::/64 dev enp2s0  proto kernel  metric 256  pref medium
fe80::/64 dev enp4s0  proto kernel  metric 256  pref medium
default via fe80::92f6:52ff:fef6:c88 dev br0  proto ra  metric 1024  pref medium
default via fe80::92f6:52ff:fef6:c88 dev br1  proto ra  metric 1024  pref medium

$ ip a
4: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:08:54:57:18:2c brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.20/24 brd 192.168.20.255 scope global br1
       valid_lft forever preferred_lft forever
    inet6 fd01:470:1234:10:208:54ff:fe57:182c/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 2001:470:1234:10:208:54ff:fe57:182c/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::208:54ff:fe57:182c/64 scope link 
       valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 94:de:80:02:ca:42 brd ff:ff:ff:ff:ff:ff
    inet 10.10.20.0/8 brd 10.255.255.255 scope global dynamic br0
       valid_lft 39154sec preferred_lft 39154sec
    inet6 fd01:470:1234:10::f14/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fd01:470:1234:10:b81a:c792:6be1:c1f8/64 scope global temporary dynamic 
       valid_lft 600756sec preferred_lft 81756sec
    inet6 fd01:470:1234:10:96de:80ff:fe02:ca42/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 2001:470:1234:10:b81a:c792:6be1:c1f8/64 scope global temporary dynamic 
       valid_lft 600756sec preferred_lft 81756sec
    inet6 2001:470:1234:10:96de:80ff:fe02:ca42/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::96de:80ff:fe02:ca42/64 scope link 
       valid_lft forever preferred_lft forever

There is no apparent reason why br1 should have any IPv6 assigned (other 
than fe80::/64). Reverting back to src:systemd 228-6 is so far the only
option to fix my IPv6 connectivity (at least on systems with more than
one bridge configured).

Interesting enough, extending /etc/systemd/network/60-br1.network with
IPv6AcceptRouterAdvertisements=no prevents br0 from getting an IPv6
address as well (unless I systemctl restart systemd-networkd.service,
then it suddenly gets one).

Regards
	Stefan Lippers-Hollmann

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20160213/a917f3db/attachment-0002.sig>