On Thu, Aug 10, 2017 at 1:14 PM Ben Pfaff <b...@ovn.org> wrote:

> On Thu, Aug 10, 2017 at 02:41:30PM +0000, Mark Michelson wrote:
> > I'm curious about the current behavior when ovn-controller originates a
> > packet and transmits it over a link-local IPv6 multicast address. Will
> the
> > packet be delivered only to nodes on the same chassis, or can the packet
> > also reach on-link nodes on other chassis?
>
> When an OVN logical switch receives an Ethernet broadcast or multicast
> packet from a given port, it forwards it to all of its other logical
> switch ports, regardless of chassis.  There are special cases for ARP
> and IPv6 ND, to avoid forwarding them across chassis for known IP
> addresses.  I don't think that we have any special cases for IPv6
> link-local multicast.  Limiting these within a chassis would probably
> require new mechanisms, because logical flows, by design, do not respect
> physical boundaries.
>
>
Interesting you mention IPv6 ND here. RAs fall under the umbrella of IPv6
ND. So depending on how IPv6 ND is detected, it may be that RAs will be
limited from being sent to other chassis. The interesting bit here is the
"for known IP addresses" part. I'll take a closer look at the flows to see
what that means. If the all-nodes link-local multicast address is one of
these known IP addresses, then things might just work without having to do
much extra.


> > The reason I ask is that I'm working towards expanding OVN's IPv6
> neighbor
> > discovery capabilities, and the first step on that path is being able to
> > send periodic router advertisements (RAs). In a traditional physical
> > network, each interface on a router may send periodic RAs to its
> link-local
> > all-nodes address (ff02::1). This way all on-link nodes receive the RA,
> and
> > the world is a happy place.
> >
> > OVN is not a traditional physical router, though :)
> >
> > With OVN, each hypervisor has an ovn-controller instance running,
> blurring
> > the lines about what exactly constitutes a "router interface". From an
> > ovn-nb point of view, a logical router port constitutes a router
> interface.
> > However, in practice, I'm not sure if this holds true once you get down
> to
> > the ovn-controller level. Let's say that a single link (via a logical
> > switch) is spread across three hypervisors. If the ovn-controller on each
> > of those hypervisors sends an RA to the link-local all-nodes address,
> would
> > that result in nodes on each hypervisor receiving three RAs? Or would
> each
> > node only receive one RA since it only receives the RA from the local
> > ovn-controller?
>
> I believe that this would result in 3x advertisements.
>

That's what I was afraid of. This could end up being a bit spammy if all
ovn-controllers are sending RAs. But as I mentioned earlier, this may
actually be taken care of since RAs are part of IPv6 ND.


>
> > I suspect the answer to this all comes down to how openflow flows get
> > installed on each OVS instance. What I'm curious about is the current
> > behavior of OVN in this regard.
>
> I guess that it would be more efficient for each chassis to individually
> generate these router advertisements and ensure that they do not
> propagate beyond the physical chassis boundary?  I can think of ways to
> do that, especially if ovn-controller were generating them.  This is
> because when ovn-controller generates packets, it can tag them with
> additional metadata that indicate the purpose.  For example, to allow it
> to send a chassis-limited packet, we could implement a new metadata bit
> that suppresses output through tunnels, and ovn-controller could set
> that bit.
>

Cool, thanks for the pointer. If the current IPv6 ND-related rules don't
already do what I need, I'll look into the metadata idea.


>
> > P.S. Someone please tell me if ovs-discuss would have been a more
> suitable
> > list for this question. I figured since it was related to a feature I was
> > developing that this would be the proper list, though.
>
> Seems like a legit dev discussion to me.
>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to