[ovs-dev] OVN: IPv6 Periodic Router Advertisement Plan

Mark Michelson mmichels at redhat.com
Tue Aug 29 20:29:19 UTC 2017


On Tue, Aug 29, 2017 at 3:15 PM Brian Haley <haleyb.dev at gmail.com> wrote:

> Sorry for the slow review, was on PTO.  Comments below.
>
> On 08/22/2017 05:43 PM, Mark Michelson wrote:
> > Hi folks,
> >
> > For a while now, in a "learn the OVN project from scratch" project, I've
> > been investigating what it would take in order to allow for OVN to send
> > periodic router advertisements (RAs) as part of a greater goal of
> rounding
> > out IPv6 support. I've had some discussions about individual parts of
> this
> > with various people, and now I want to come forward with an actual
> proposal
> > of how I envision accomplishing this.
> >
> > First, let's start with what an RA is. It is an ICMPv6 message that a
> > router sends out in order to say "I am a router" to any other nodes on a
> > link. Beyond that, an RA may contain information such as MTU, supported
> > IPv6 prefixes, hop count, and other useful information about the router
> > interface. The RA can be sent for one of two reasons:
> >
> > 1) A host on the link has sent a router solicitation (RS) message, and
> the
> > router is responding directly to that.
> > 2) The router can be configured to periodically send RAs to all nodes on
> > the link.
> >
> > For (1), Numan Siddique currently has a set of patches up for review that
> > adds this support. I am attempting to add (2).
> >
> > My primary goal here is determining how to configure ovn-controllers to
> > know to periodically send RAs, and to ensure they have the necessary
> > information to do so. The rest of this e-mail details how I propose to do
> > that.
> >
> > There is a patch[1] currently up for consideration that adds a new column
> > to the northbound Logical_Router_Port table called ipv6_ra_configs. This
> > currently only has two configurable options:
> > * address_mode
>
> I'm assuming that based on the mode that certain RA flags will be
> enabled?  Maybe this was covered in Numan's change, haven't taken a look
> there.  For example, with stateful the M flag is set.
>

Thanks for the feedback. Numan's change sets the M and O flags based on the
configured ipv6_ra_configs address_mode. If set to "dhcp_stateful", then
the M flag is set. If set to "dhcp_stateless", then the O flag is set. I
plan to do the same thing with the periodic RAs.

>
> > * mtu
> > In order to allow periodic router advertisements, I propose the following
> > options to be added to the ipv6_ra_configs
> > * send_periodic - boolean indicating if periodic RAs should be sent.
> > Defaults to false
> > * max_interval - integer indicating the maximum number of seconds to wait
> > between sending periodic RAs. Defaults to 600 seconds.
> > * max_interval - integer indicating the minimum number of seconds to wait
> > between sending periodic RAs. Defaults to 0.33 * max_interval (200
> seconds
> > if max_interval is set to its default).
>
> For min_interval (typo), I would just follow what the RFC says and not
> only do 0.33 if max_interval is at its default:
>
>      Default: 0.33 * MaxRtrAdvInterval If
>      MaxRtrAdvInterval >= 9 seconds; otherwise, the
>      Default is MaxRtrAdvInterval.
>
> Looks good otherwise.
>

Oops, Sorry about the typo. I'll be sure to follow the RFC for the minimum
calculation.


> -Brian
>
> > This is the minimum requirement. RFC 4861 defines many other
> configuration
> > options that will alter the contents of RAs, but those can be added in a
> > future update if necessary.
> >
> > If someone wishes to periodically send RAs, they can set the
> send_periodic
> > northbound value true and adjust the interval to their liking.
> ovn-northd,
> > upon seeing that the send_periodic is set true, will copy the entirety of
> > the ipv6_ra_configs column into the options column of the corresponding
> > Port_Binding entry of the southbound database. To scope these as IPv6 RA
> > options, the keys in the southbound database will be prepended with
> > ipv6_ra_. So for instance, when copying the "address_mode" from the
> > northbound database, it would become "ipv6_ra_address_mode" in the
> > southbound database. In addition to the contents of the northbound
> > Logical_Router_Port ipv6_ra_configs, ovn-northd will insert data about
> the
> > RAs themselves, such as the network prefixes to be advertised (learned
> from
> > the logical router port's networks) and the source ethernet and IP
> > addresses to use in RAs.
> >
> > Example:
> > I create a logical router port as follows:
> >      ovn-nbctl lrp-add lr0 lr0-p0 00:11:22:33:44:55 2001:db8::1/64
> > I then modify the logical router port's ipv6_ra_configs as follows:
> >      ovn-nbctl set Logical_Router_Port lr0-p0
> > ipv6_ra_config:send_periodic=true
> > When northd runs, it will populate the southbound database's Port_Binding
> > for lr0-p0 as follows:
> >      options: {ipv6_ra_send_periodic=true,
> > ipv6_ra_src_mac=00:11:22:33:44:55, ipv6_ra_src_addr=2001:db8::1,
> > ipv6_ra_prefixes=2001:db8::/64}
> >
> > ovn-controller already has code that determines which datapaths are local
> > to the chassis. With these datapaths found, we can add code to make
> > ovn-controller iterate over the port bindings that pertain to that
> > datapath. If any port bindings have ipv6_ra_send_periodic=true in their
> > options, then the ovn-controller needs to send out periodic RAs.
> >
> > The sending of RAs will closely mirror the method by which ovn-controller
> > currently sends gratuitous ARP packets. That is, a structure will be
> > allocated that contains all the necessary information about what to send
> in
> > the outgoing RA, plus information on when the next RA should be sent out.
> > Handling of when to send out RAs will be handled similarly to gratuitous
> > ARPs as well, except that instead of having a backoff timer, the interval
> > will be recalculated each time based on the configuration.
> >
> > If you've made it this far in the e-mail, then thank you! If you have any
> > suggestions for other methods of doing this or have any questions about
> any
> > part of the proposed process, please let me know.
> >
> > Mark Michelson
> >
> > [1] https://patchwork.ozlabs.org/patch/804391/
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
>


More information about the dev mailing list