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
* 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).
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
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
