Bug 112751 - learns IPv6 default route and IP address from its own announcement on wrong interface
Summary: learns IPv6 default route and IP address from its own announcement on wrong i...
Status: RESOLVED INVALID
Alias: None
Product: Networking
Classification: Unclassified
Component: IPV6 (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Hideaki YOSHIFUJI
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-20 20:02 UTC by Marc Haber
Modified: 2016-02-22 18:48 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.4.2
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Marc Haber 2016-02-20 20:02:39 UTC
Hi,

I have a box with an eth0 interface pointing to the Internet. There is a router which sends out router announcements. These are properly learned.

On my boxes' br0, there is a radvd advertising the box itself as a router to the internet, for VMs running on the machine.

accept_ra on eth0 is set to 2, accept_ra on br0 is set to 1.

When the radvd on br0 sends out its announcement, the kernel on the local box sees the announcement and adds a default route, pointing to br0's link local IPv6 address, but with the interface set to eth0. It also adds an IP address for the network visible on br0 to eth0. This makes IPv6 communication kind of hard.

[1/501]mh@fan:~$ ip addr
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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 54:04:a6:82:21:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.182.250/32 brd 192.168.182.250 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.182.29/24 brd 192.168.182.255 scope global dynamic eth0
       valid_lft 13861sec preferred_lft 13861sec
    inet6 2a01:238:4071:328d:5604:a6ff:fe82:2100/64 scope global mngtmpaddr noprefixroute dynamic 
       valid_lft 86101sec preferred_lft 14101sec
    inet6 2a01:238:4071:3282:5604:a6ff:fe82:2100/64 scope global mngtmpaddr noprefixroute dynamic 
       valid_lft 86086sec preferred_lft 14086sec
    inet6 2a01:238:4071:3282::1d:250/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 2a01:238:4071:3282::1d:100/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5604:a6ff:fe82:2100/64 scope link 
       valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c6:f4:98:dc:5e:21 brd ff:ff:ff:ff:ff:ff
    inet 192.168.29.254/24 brd 192.168.29.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 2a01:238:4071:328d::1d:153/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 2a01:238:4071:328d::1d:100/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fec0:0:0:ffff::3/128 scope site
       valid_lft forever preferred_lft forever
    inet6 fec0:0:0:ffff::2/128 scope site
       valid_lft forever preferred_lft forever
    inet6 fec0:0:0:ffff::1/128 scope site
       valid_lft forever preferred_lft forever
    inet6 fe80::c4f4:98ff:fedc:5e21/64 scope link
       valid_lft forever preferred_lft forever
4: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
    link/ether 72:6f:a6:b6:30:e2 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::706f:a6ff:feb6:30e2/64 scope link
       valid_lft forever preferred_lft forever
[2/502]mh@fan:~$ 

The network on eth0 is 2a01:238:4071:3282::/64, the one on br0 is 2a01:238:4071:328d::/64

[6/506]mh@fan:~$ sudo tcpdump -i br0 -npe icmp6
21:01:31.358957 c6:f4:98:dc:5e:21 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 134: fe80::c4f4:98ff:fedc:5e21 > ff02::1: ICMP6, router advertisement, length 80
[5/505]mh@fan:~$ while sleep 2; do date; ip -6 r show default; done              
Sa 20. Feb 21:01:29 CET 2016
default via fe80::1 dev eth0  proto ra  metric 1024  pref medium
Sa 20. Feb 21:01:31 CET 2016
default via fe80::1 dev eth0  proto ra  metric 1024  pref medium
default via fe80::c4f4:98ff:fedc:5e21 dev eth0  proto ra  metric 1024  pref medium

I guess this broke with kernel 4.4.

Greetings
Marc
Comment 1 hannes 2016-02-20 20:40:30 UTC
Did I understood correctly, eth0 is part of br0?
Comment 2 Marc Haber 2016-02-20 20:43:35 UTC
Hi Hannes, no, there is no connection between eth0 and br0. VMs connect to br0, the host routes between eth0 and br0.

[2/502]mh@fan:~$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.c6f498dc5e21       no              dummy0
                                                        vnet0
                                                        vnet1
                                                        vnet2
[3/502]mh@fan:~$

Sorry for being unclear.

Greetings
Marc
Comment 3 Marc Haber 2016-02-22 14:54:25 UTC
The issue seems to be that /proc/sys/net/ipv6/conf/eth0/accept_ra_from_local is 1. This is the case because the default gateway visible on eth0 has the link local address fe80::1 while the local box has also fe80::1 on br0 to be default gateway to its VMs.

This is a bug in accept_ra_from_local.

The kernel should never set a default route on a different interface than the one that an RA was received. The RA comes in on br0, which has accept_ra_from_local 0. Hence, the RA should be ignored.

If /proc/sys/net/ipv6/conf/br0/accept_ra_from_local were 1, the RA should be accepted and the route should be configured on br0, not on eth0.
Comment 4 Marc Haber 2016-02-22 18:48:26 UTC
This is not a kernel issue. systemd 229 decided to handle incoming router announcements itself. And of course, the NIH implementation is flawed.

This issue can be closed. I apologize.

Should I have done things wrong when closing this, its caused by my unfamiliarity with bugzilla.

Note You need to log in before you can comment on or make changes to this bug.