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

Ben Pfaff blp at ovn.org
Tue May 15 17:14:26 UTC 2018


On Tue, May 15, 2018 at 05:25:49PM +0530, Numan Siddique wrote:
> 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.

OK, that is a reasonable argument.  Thanks.


More information about the dev mailing list