[ovs-dev] [PATCH v4] ovn: Set proper Neighbour Adv flag when replying for NS request for router IP

Numan Siddique nusiddiq at redhat.com
Tue May 15 11:55:49 UTC 2018


On Mon, May 14, 2018 at 11:58 PM, Ben Pfaff <blp at ovn.org> wrote:

> On Mon, May 14, 2018 at 11:23:11PM +0530, Numan Siddique wrote:
> > On Mon, May 14, 2018, 10:44 PM Ben Pfaff <blp at ovn.org> wrote:
> >
> > > On Fri, May 11, 2018 at 04:08:00PM +0530, nusiddiq at redhat.com wrote:
> > > > From: Numan Siddique <nusiddiq at redhat.com>
> > > >
> > > > Presently when a VM's IPv6 stack sends a Neighbor Solicitation
> request
> > > for its
> > > > router IP, (mostly when the ND cache entry for the router is in STALE
> > > state)
> > > > ovn-controller responds with a Neighbor Adv packet (using the action
> > > nd_na).
> > > > But it doesn't set 'ND_RSO_ROUTER' in the RSO flags (please see
> RFC4861
> > > page 23).
> > > > Because of which, the VM deletes the default route. The default route
> > > gets added
> > > > again when the next RA is received (but would again gets deleted if
> its
> > > sends
> > > > NS request). And this results in disruption of IPv6 traffic.
> > > >
> > > > This patch addresses this issue by adding a new action 'nd_na_router'
> > > which is
> > > > same as 'nd_na' but it sets the 'ND_RSO_ROUTER' in the RSO flags.
> > > ovn-northd
> > > > uses this action. A new action is added instead of modifying the
> > > existing 'nd_na'
> > > > action. This is because
> > > >   - We cannot set the RSO flags in the "nd_na { ..actions .. }"
> > > >   - It would be ugly to have something like nd_na { router_flags,
> > > ...actions .. }
> > > >
> > > > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1567735
> > > > Signed-off-by: Numan Siddique <nusiddiq at redhat.com>
> > > > Acked-by: Mark Michelson <mmichels at redhat.com>
> > >
> > > Thanks, applied to master.
> > >
> >
> > Thank you Ben for the review and applying the patch.
> >
> > Can this be applied to branch 2.9 as well ? I resolved conflicts and
> > submitted the patch for
> > branch 2.9 - https://patchwork.ozlabs.org/patch/913165/
>
> Usually, I think of upgrades within a given series like 2.9.x as being
> simple and lightweight.  If we apply this to branch-2.9, though, an
> upgrade from 2.9.0 to 2.9. will take as much care as an upgrade from
> 2.8.x to 2.9.x, because the upgrades to each node have to be carefully
> ordered.  Is that desirable?
>

I did some testing. The problem comes when northd is upgraded from 2.9.0 to
2.9.x before ovn-controller.

Till ovn-controller is upgraded we will be seeing  the below error messages
since ovn-controller can't parse the action nd_na_router

****
2018-05-15T11:43:27.240Z|00038|lflow|WARN|error parsing actions
"put_nd(inport, ip6.src, nd.sll); nd_na_router { eth.src =
00:00:00:00:ff:01; ip6.src = aef0::; nd.target = aef0::; nd.tll =
00:00:00:00:ff:01; outport = inport; flags.loopback = 1; output; };":
Syntax error at `nd_na_router' expecting action.
****

With ovn-northd 2.9.0 and ovn-controller 2.9.0, IPv6 functionality is
broken. With ovn-northd 2.9.1 and ovn-controller 2.9.0, IPv6 functionality
would be broken until ovn-controller is upgraded to 2.9.1.

It is desirable If the user/admin upgrades ovn-controllers first and then
ovn-northd.  But if the order is reversed, I don't see any issue since IPv6
functionality is broken any way.

Thanks
Numan


More information about the dev mailing list