[ovs-discuss] [OVN] router-preference in non periodic RA

Numan Siddique numans at ovn.org
Mon Jun 1 19:05:27 UTC 2020

Hi Gabriele,

Please see below for some comments.


On Sun, May 31, 2020 at 4:19 PM Gabriele Cerami <gcerami at redhat.com> wrote:

> On 30 May, Gabriele Cerami wrote:
> > The pinctrl thread code seems the right place, the packet is passed to
> > the router logic that builds a response.
> > I was expecting some OPCODE in controller/pinctrl.c:process_packet_in
> > but there's none referring to a RS.
> I think I can partially answer myself. But I still have lots of
> questions.
> This commit from Nov 2017
> https://github.com/ovn-org/ovn/commit/ec5bcc68b34e73b8541f3143dd1f69a8e884cbef
> Introduced the handling of RA in response to RS. So the OPCODE I was
> looking for was ACTION_OPCODE_PUT_ND_RA_OPTS and the function dealing
> with this is pinctrl_handle_put_nd_ra_opts.
> Which seems completely unrelated to the handling of periodic RA
> introduced the same month with commit
> https://github.com/ovn-org/ovn/commit/c04c004efaf64b77460de5338092e642385e582d
> that uses a loop that calls send_ipv6_ras.
OVN handles these 2 things separately
  1. When a VM sendsIPv6 RS packet, OVN needs to respond to it. And for
that there is an
   OVN action - put_nd_ra_opts().

See [1] for how ovn-northd is making use of this action.  The logical flow
looks something like below for example

reg1[0] = put_nd_ra_opts(addr_mode = "slaac", mtu = 1500, prefix =
aef0::/64, slla = ae:01:02:03:04:05);

ovn-controller when parsing this action, prepares the IPv6 Router
Advertisement data (which will be included later when replying
the RA) and stores this data in the "userdata" field of controller action.
The OVN put_nd_ra_opts translates to Openflow controller
action and the controller action supports a field caleld userdata, which is
nothing but a buffer.

So if the match is IPv6 RS packet, ovs-vswitchd sends this packet to
ovn-controller. ovs-vswitch when it sends to ovn-controller,
it will also send the "userdata". This userdata is nothing but the IPv6 RA
data. So pinctrl module just frames an IPv6 RA
packet, includes this userdata and resumes this packet i.e it sends the
packet back to ovs-vswitchd.

If you want to address this, then you should include router-preference in
the put_nd_ra_opts(),
something like

reg1[0] = put_nd_ra_opts(addr_mode = "slaac", mtu = 1500, prefix =
aef0::/64, slla = ae:01:02:03:04:05, router-preference=true);

lib/actions.c when encoding this action should also include this RA option
in the userdata buffer.

2. Since periodic RA is not sent in response to a RS packet, it is sent
periodically in the pinctrl module.

There is no need to mix both these cases.

OVN uses the userdata buffer of controller action a lot. The way
put_nd_ra_opts() implemented is
very similar to OVN dhcp responder. You can refer to this blog post [2] for
more information if you like.

[1] - https://github.com/ovn-org/ovn/blob/master/northd/ovn-northd.c#L9448
[2] - https://numans.blog/2016/08/09/native-dhcp-support-in-ovn/


This explains why many of the RA options are not set when responding to
> a solicitation.
> After studying RFC 4861 especially section 6.2, I have a few questions
> yet:
> 1) why are there two different functions to build RA ? I get the
> different handling, but maybe part of this process could be made common ?
> 2) How closely are RFC followed ? As RFC doesn't take into account a
> centralized control plane, I think some implementation choice may be
> affected as found irrelevant for the use case, but breaking RFC may be a
> risk anyway, in particular:
> - Section 6.2.1 doesn't seem to separate periodic RA from solicited RA:
>   conceptual variable AdvSendAdvertisements enables or disables the RA
>   in general, so it seems if it's enabled for solicited, it should be
>   enabled also periodically. What is the use case for option
>   ipv6_ra_config:send_periodic that separates periodic from solicited ?
> - Section 6.2.6 adds 2 types of intervals beside min/max interval for
>   the periodic RA: 0-MAX_RA_DELAY_TIME for delay on sending solicited
>   RA. MIN_DELAY_BETWEEN_RAS is then used to rate limit RAs. Commit
>   message for the RS handling patch explains well the process involved
>   in sending solicited RA, but I'm not sure if the delay/rate limit is
>   implemented. (And if was excluded for a reason)
> 3) line controller/pinctrl.c:123 says:
> "pinctrl module also periodically sends IPv6 Router Solicitation requests"
> should this say Router Solicitation Replies OR Router Advertisement ?
> If not, why and is it sending periodic Solicitation ? to identify rogue
> routers and problems with network configuration ?
> I would be glad to help with any change that may come out from this
> discussion
> Thanks.
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20200602/bfc564ba/attachment.html>

More information about the discuss mailing list