On Tue, May 15, 2018 at 05:25:49PM +0530, Numan Siddique wrote: > On Mon, May 14, 2018 at 11:58 PM, Ben Pfaff <[email protected]> wrote: > > > On Mon, May 14, 2018 at 11:23:11PM +0530, Numan Siddique wrote: > > > On Mon, May 14, 2018, 10:44 PM Ben Pfaff <[email protected]> wrote: > > > > > > > On Fri, May 11, 2018 at 04:08:00PM +0530, [email protected] wrote: > > > > > From: Numan Siddique <[email protected]> > > > > > > > > > > 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 <[email protected]> > > > > > Acked-by: Mark Michelson <[email protected]> > > > > > > > > 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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
