diff mbox series

[net,1/2] ipv6: create multicast route with RTPROT_KERNEL

Message ID 20210115184209.78611-2-mcroce@linux.microsoft.com (mailing list archive)
State Accepted
Commit a826b04303a40d52439aa141035fca5654ccaccd
Delegated to: Netdev Maintainers
Headers show
Series ipv6: fixes for the multicast routes | expand

Checks

Context Check Description
netdev/cover_letter success Link
netdev/fixes_present fail Series targets non-next tree, but doesn't contain any Fixes tags
netdev/patch_count success Link
netdev/tree_selection success Clearly marked for net
netdev/subject_prefix success Link
netdev/cc_maintainers success CCed 4 of 4 maintainers
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 7 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/header_inline success Link
netdev/stable success Stable not CCed

Commit Message

Matteo Croce Jan. 15, 2021, 6:42 p.m. UTC
From: Matteo Croce <mcroce@microsoft.com>

The ff00::/8 multicast route is created without specifying the fc_protocol
field, so the default RTPROT_BOOT value is used:

  $ ip -6 -d route
  unicast ::1 dev lo proto kernel scope global metric 256 pref medium
  unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium
  unicast ff00::/8 dev eth0 proto boot scope global metric 256 pref medium

As the documentation says, this value identifies routes installed during
boot, but the route is created when interface is set up.
Change the value to RTPROT_KERNEL which is a better value.

Signed-off-by: Matteo Croce <mcroce@microsoft.com>
---
 net/ipv6/addrconf.c | 1 +
 1 file changed, 1 insertion(+)

Comments

David Ahern Jan. 16, 2021, 4:36 a.m. UTC | #1
On 1/15/21 11:42 AM, Matteo Croce wrote:
> From: Matteo Croce <mcroce@microsoft.com>
> 
> The ff00::/8 multicast route is created without specifying the fc_protocol
> field, so the default RTPROT_BOOT value is used:
> 
>   $ ip -6 -d route
>   unicast ::1 dev lo proto kernel scope global metric 256 pref medium
>   unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium
>   unicast ff00::/8 dev eth0 proto boot scope global metric 256 pref medium
> 
> As the documentation says, this value identifies routes installed during
> boot, but the route is created when interface is set up.
> Change the value to RTPROT_KERNEL which is a better value.
> 
> Signed-off-by: Matteo Croce <mcroce@microsoft.com>
> ---
>  net/ipv6/addrconf.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index eff2cacd5209..19bf6822911c 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -2469,6 +2469,7 @@ static void addrconf_add_mroute(struct net_device *dev)
>  		.fc_flags = RTF_UP,
>  		.fc_type = RTN_UNICAST,
>  		.fc_nlinfo.nl_net = dev_net(dev),
> +		.fc_protocol = RTPROT_KERNEL,
>  	};
>  
>  	ipv6_addr_set(&cfg.fc_dst, htonl(0xFF000000), 0, 0, 0);
> 


What's the motivation for changing this? ie., what s/w cares that it is
kernel vs boot?
Matteo Croce Jan. 16, 2021, 12:17 p.m. UTC | #2
On Sat, Jan 16, 2021 at 5:36 AM David Ahern <dsahern@gmail.com> wrote:
>
> On 1/15/21 11:42 AM, Matteo Croce wrote:
> > From: Matteo Croce <mcroce@microsoft.com>
> >
> > The ff00::/8 multicast route is created without specifying the fc_protocol
> > field, so the default RTPROT_BOOT value is used:
> >
> >   $ ip -6 -d route
> >   unicast ::1 dev lo proto kernel scope global metric 256 pref medium
> >   unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium
> >   unicast ff00::/8 dev eth0 proto boot scope global metric 256 pref medium
> >
> > As the documentation says, this value identifies routes installed during
> > boot, but the route is created when interface is set up.
> > Change the value to RTPROT_KERNEL which is a better value.
> >
> > Signed-off-by: Matteo Croce <mcroce@microsoft.com>
> > ---
> >  net/ipv6/addrconf.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> > index eff2cacd5209..19bf6822911c 100644
> > --- a/net/ipv6/addrconf.c
> > +++ b/net/ipv6/addrconf.c
> > @@ -2469,6 +2469,7 @@ static void addrconf_add_mroute(struct net_device *dev)
> >               .fc_flags = RTF_UP,
> >               .fc_type = RTN_UNICAST,
> >               .fc_nlinfo.nl_net = dev_net(dev),
> > +             .fc_protocol = RTPROT_KERNEL,
> >       };
> >
> >       ipv6_addr_set(&cfg.fc_dst, htonl(0xFF000000), 0, 0, 0);
> >
>
>
> What's the motivation for changing this? ie., what s/w cares that it is
> kernel vs boot?

A practical example: systemd-networkd explicitly ignores routes with
kernel flag[1]. Having a different flag leads the daemon to remove the
route sooner or later.

[1] https://github.com/systemd/systemd/blob/0b81225e5791f660506f7db0ab88078cf296b771/src/network/networkd-routing-policy-rule.c#L675-L677
diff mbox series

Patch

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index eff2cacd5209..19bf6822911c 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2469,6 +2469,7 @@  static void addrconf_add_mroute(struct net_device *dev)
 		.fc_flags = RTF_UP,
 		.fc_type = RTN_UNICAST,
 		.fc_nlinfo.nl_net = dev_net(dev),
+		.fc_protocol = RTPROT_KERNEL,
 	};
 
 	ipv6_addr_set(&cfg.fc_dst, htonl(0xFF000000), 0, 0, 0);