Hello,
I have been testing IPv6 Router Advertisement Default Router
Preference on 5.1X and it seems it is not honoured by the Linux
networking stack. Whenever a new default router preference with a
higher or lower preference value is received, a new default gateway is
added as an ECMP route in the routing table with equal weight. This is
a bit surprising as RFC 4191 Sec. 3.2 mentions that the higher
preference value should be preferred. This part seems to be missing
from the Linux implementation.
The problem has existed apparently for a while, see below discussion
for reference:
https://serverfault.com/questions/768932/can-linux-be-made-to-honour-ipv6-route-advertisement-preferences
I am happy to test any improvements to this, in case someone takes a look.
Thanks!
--
Juhamatti
On 20211118, at 11:35, Juhamatti Kuusisaari [off-list ref] wrote:
Hello,
I have been testing IPv6 Router Advertisement Default Router
Preference on 5.1X and it seems it is not honoured by the Linux
networking stack. Whenever a new default router preference with a
higher or lower preference value is received, a new default gateway is
added as an ECMP route in the routing table with equal weight. This is
a bit surprising as RFC 4191 Sec. 3.2 mentions that the higher
preference value should be preferred. This part seems to be missing
from the Linux implementation.
Do watch out that there are a couple of user space tools (yes, that thing) that think that they have to handle RAs.... and thus one might get conflicts about reasoning between the kernel doing it or that user space daemon thing.
Greets,
Jeroen
On Thu, 18 Nov 2021 at 12:49, Jeroen Massar [off-list ref] wrote:
quoted
On 20211118, at 11:35, Juhamatti Kuusisaari [off-list ref] wrote:
Hello,
I have been testing IPv6 Router Advertisement Default Router
Preference on 5.1X and it seems it is not honoured by the Linux
networking stack. Whenever a new default router preference with a
higher or lower preference value is received, a new default gateway is
added as an ECMP route in the routing table with equal weight. This is
a bit surprising as RFC 4191 Sec. 3.2 mentions that the higher
preference value should be preferred. This part seems to be missing
from the Linux implementation.
Do watch out that there are a couple of user space tools (yes, that thing) that think that they have to handle RAs.... and thus one might get conflicts about reasoning between the kernel doing it or that user space daemon thing.
Thanks for the heads-up. AFAIK, I am not running anything extra in the
user space of the receiving node.
Here are some more details:
1) RA with pref medium is received over enp0s8 from router X at
fe80::a00:27ff:fe90:5a8a:
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp0s8 proto kernel metric 256 pref medium
fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
default via fe80::a00:27ff:fe90:5a8a dev enp0s8 proto ra metric 1024
expires 273sec pref medium
2) RA with pref high is received over enp0s8 from router Y at
fe80::ffff:a00:275e:85ca:
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp0s8 proto kernel metric 256 pref medium
fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
default proto ra metric 1024 expires 276sec pref medium
nexthop via fe80::a00:27ff:fe90:5a8a dev enp0s8 weight 1
nexthop via fe80::ffff:a00:275e:85ca dev enp0s8 weight 1
i.e. the default ends up as an ECMP configuration. I would have
expected it to change to a high preference route via
fe80::ffff:a00:275e:85ca only.
BR,
--
Juhamatti
From: David Ahern <hidden> Date: 2021-11-28 23:13:19
On 11/18/21 3:35 AM, Juhamatti Kuusisaari wrote:
Hello,
I have been testing IPv6 Router Advertisement Default Router
Preference on 5.1X and it seems it is not honoured by the Linux
networking stack. Whenever a new default router preference with a
higher or lower preference value is received, a new default gateway is
added as an ECMP route in the routing table with equal weight. This is
a bit surprising as RFC 4191 Sec. 3.2 mentions that the higher
preference value should be preferred. This part seems to be missing
from the Linux implementation.
The problem has existed apparently for a while, see below discussion
for reference:
https://serverfault.com/questions/768932/can-linux-be-made-to-honour-ipv6-route-advertisement-preferences
I am happy to test any improvements to this, in case someone takes a look.
do you have CONFIG_IPV6_ROUTER_PREF enabled and accept_ra_rtr_pref set
for the device?
Hello,
On Mon, 29 Nov 2021 at 01:11, David Ahern [off-list ref] wrote:
On 11/18/21 3:35 AM, Juhamatti Kuusisaari wrote:
quoted
Hello,
I have been testing IPv6 Router Advertisement Default Router
Preference on 5.1X and it seems it is not honoured by the Linux
networking stack. Whenever a new default router preference with a
higher or lower preference value is received, a new default gateway is
added as an ECMP route in the routing table with equal weight. This is
a bit surprising as RFC 4191 Sec. 3.2 mentions that the higher
preference value should be preferred. This part seems to be missing
from the Linux implementation.
The problem has existed apparently for a while, see below discussion
for reference:
https://serverfault.com/questions/768932/can-linux-be-made-to-honour-ipv6-route-advertisement-preferences
I am happy to test any improvements to this, in case someone takes a look.
do you have CONFIG_IPV6_ROUTER_PREF enabled and accept_ra_rtr_pref set
for the device?
Hello,
On Thu, 18 Nov 2021 at 15:12, Juhamatti Kuusisaari [off-list ref] wrote:
On Thu, 18 Nov 2021 at 12:49, Jeroen Massar [off-list ref] wrote:
quoted
quoted
On 20211118, at 11:35, Juhamatti Kuusisaari [off-list ref] wrote:
Hello,
I have been testing IPv6 Router Advertisement Default Router
Preference on 5.1X and it seems it is not honoured by the Linux
networking stack. Whenever a new default router preference with a
higher or lower preference value is received, a new default gateway is
added as an ECMP route in the routing table with equal weight. This is
a bit surprising as RFC 4191 Sec. 3.2 mentions that the higher
preference value should be preferred. This part seems to be missing
from the Linux implementation.
Do watch out that there are a couple of user space tools (yes, that thing) that think that they have to handle RAs.... and thus one might get conflicts about reasoning between the kernel doing it or that user space daemon thing.
Thanks for the heads-up. AFAIK, I am not running anything extra in the
user space of the receiving node.
Here are some more details:
1) RA with pref medium is received over enp0s8 from router X at
fe80::a00:27ff:fe90:5a8a:
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp0s8 proto kernel metric 256 pref medium
fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
default via fe80::a00:27ff:fe90:5a8a dev enp0s8 proto ra metric 1024
expires 273sec pref medium
2) RA with pref high is received over enp0s8 from router Y at
fe80::ffff:a00:275e:85ca:
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp0s8 proto kernel metric 256 pref medium
fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
default proto ra metric 1024 expires 276sec pref medium
nexthop via fe80::a00:27ff:fe90:5a8a dev enp0s8 weight 1
nexthop via fe80::ffff:a00:275e:85ca dev enp0s8 weight 1
i.e. the default ends up as an ECMP configuration. I would have
expected it to change to a high preference route via
fe80::ffff:a00:275e:85ca only.
The above behaviour does not quite match the code - and indeed, a
userspace tool did take over RAs by default. I disabled it and the
kernel behaviour looks like this:
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp0s8 proto kernel metric 256 pref medium
fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
default via fe80::a00:27ff:fe5e:85ca dev enp0s8 proto ra metric 1024
expires 261sec pref medium
default via fe80::ffff:a00:275e:85ca dev enp0s8 proto ra metric 1024
expires 261sec pref high
To be sure, I verified from ND-kernel logs that this really goes to the kernel.
It still does not look quite right to me. I would have expected, based
on the RFC 4191, that only high pref default is there or that it has
priority by other means. AFAICT, now the routing takes the default
that happens to match the lookup first. Without router preference this
is fine.
Thanks,
--
Juhamatti