14:00:55 <liuyulong> #startmeeting neutron_l3
14:00:56 <openstack> Meeting started Wed May 19 14:00:55 2021 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:59 <openstack> The meeting name has been set to 'neutron_l3'
14:01:07 <liuyulong> Hi there
14:01:10 <liuyulong> Long time no see.
14:04:01 <lajoskatona> Hi
14:04:37 <liuyulong> hi there
14:04:38 <liuyulong> #topic Bugs
14:05:06 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1922923
14:05:06 <openstack> Launchpad bug 1922923 in neutron "OVS port issue" [Medium,New]
14:06:10 <liuyulong> I just change the bug title to "[L3] arp issue in router namespace in compute node"
14:06:36 <liuyulong> according to the logs by the bug reportor.
14:07:44 <lajoskatona> +1
14:07:57 <liuyulong> There is MAC inconsistent between the action of arp entry delation: " (10.10.13.195) at fa:16:3e:c5:b9:23 [ether] PERM on qr-4affa6db-67" and "(10.10.13.195) at fa:16:3e:a4:76:8c [ether] on qr-4affa6db-67"
14:09:00 <liuyulong> I have no idea about this, never meet such issue...
14:09:22 <slaweq> hi
14:09:25 <slaweq> sorry for being late
14:09:33 <slaweq> I have another meeting in same time
14:10:29 <liuyulong> So, I just request the reportor to add more actions from the begining of the issue, such as booting VM, creating router and so on.
14:10:32 <liuyulong> slaweq, hi
14:10:57 <liuyulong> OK, next one
14:10:59 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1925498
14:10:59 <openstack> Launchpad bug 1925498 in neutron "SNAT is not working" [High,New]
14:11:36 <liuyulong> This is a centralized router of Linux Bridge driver.
14:11:58 <liuyulong> I just have one question, is the "enable_snat" set to True?
14:12:36 <slaweq> that's good question indeed :)
14:13:03 <liuyulong> But we can see there is a SNAT rule, don't know if there is something missing because of this enable_snat. "-A neutron-l3-agent-snat -o qg-33922118-c1 -j SNAT --to-source X.X.X.X --random-fully"
14:13:52 <liuyulong> LB driver is new to me honestly. :)
14:14:54 <liuyulong> Next one
14:14:57 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1925368
14:14:57 <openstack> Launchpad bug 1925368 in neutron "[L3] Router GW can be removed with routes defined" [Low,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:15:41 <liuyulong> It has a patch here: https://review.opendev.org/c/openstack/neutron/+/789929
14:17:44 <liuyulong> I just left a comment on the patch for the statement of "in other words, all
14:17:45 <liuyulong> route nexthops IP addresses should belong to one gateway subnet CIDR.".
14:18:04 <liuyulong> This should be an optional condition.
14:18:21 <liuyulong> We can still add route like this "to 8.8.8.8 via 1.1.1.1", none of these IPs is belong to Neutron router gateway or router subnets.
14:19:56 <lajoskatona> We discussed this yesterday's team meeting: http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-3/%23openstack-meeting-3.2021-05-18.log.html#t2021-05-18T14:33:05
14:20:11 <lajoskatona> perhaps the discussion there can be useful
14:21:39 <liuyulong> Yes, so the commit message should be updated as well.
14:22:28 <liuyulong> OK, next one
14:22:31 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1926531
14:22:31 <openstack> Launchpad bug 1926531 in neutron "SNAT namespace prematurely created then deleted on hosts, resulting in removal of RFP/FPR link to FIP namespace" [Undecided,New]
14:23:04 <liuyulong> I know this issue
14:23:40 <liuyulong> The main backgound of this bug is because the "dvr_snat" node is aslo the compute node.
14:24:52 <liuyulong> If a router scheduled to this dvr_snat mode host, and there are floating IPs of VMs also running in this node.
14:26:35 <liuyulong> The router delete  action, the CLI can be "openstack network agent remove router <agent_id> <router_id>", will cause the L3 agent do a "process_delete" procedure.
14:27:05 <liuyulong> The bad effect is the call trace of the deletion will finally hit this line:
14:27:57 <liuyulong> https://github.com/openstack/neutron/blob/master/neutron/agent/l3/dvr_local_router.py#L608
14:28:19 <liuyulong> It is in "external_gateway_removed".
14:28:52 <liuyulong> So all floating IPs of this router will not work in this node anymore.
14:29:32 <liuyulong> Because we delete the critical devices between qrouter-namespace and fip-namespace.
14:31:25 <liuyulong> As I said before, I'm not a fan for running DVR fuctions with mixed compute and dvr_snat.
14:31:41 <haleyb> me either
14:32:16 <liuyulong> This will drag a really long bug history...
14:33:07 <lajoskatona> Can't we document it? I mean like don't do this.... or.....
14:33:22 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/666991/13/releasenotes/notes/accepted_egress_direct-cc23873e213c6919.yaml
14:33:32 <liuyulong> I think some clue about this can be found here.
14:33:44 <liuyulong> But anyway, I will take over this bug, it should be simple to fix.
14:37:19 <liuyulong> lajoskatona, I will add some note in the fix.
14:37:30 <liuyulong> It should be needed.
14:37:55 <liuyulong> The story should be very long...
14:38:00 <liuyulong> OK, next one
14:38:02 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1916428
14:38:02 <openstack> Launchpad bug 1916428 in neutron "dibbler tool for dhcpv6 is concluded" [Wishlist,Confirmed]
14:38:40 <liuyulong> Seems that we still have no solution about this.
14:39:34 <liuyulong> The maintainer of the dibbler suggests the project "Kea".
14:40:06 <liuyulong> Has anyone tried？
14:40:27 <lajoskatona> no
14:40:35 <haleyb> i have not
14:41:16 <liuyulong> #link https://gitlab.isc.org/isc-projects/kea/-/commits/master
14:41:35 <liuyulong> It looks a really active project.
14:43:53 <liuyulong> I did not find the licence of this new project.
14:44:04 <lajoskatona> yes and not a onemanproject seemingly
14:46:35 <liuyulong> haleyb, dibbler is used to notify the physical routers the IPv6 prefix. right?
14:47:03 <haleyb> liuyulong: it's used to get the prefix from the physical routers
14:47:45 <lajoskatona> From https://www.isc.org/kea/ : "Kea is open source, shared under MPL2.0 licensing."
14:47:50 <haleyb> the result is when they hand-out the prefix the router is learned
14:48:10 <haleyb> what is MPL2.0?
14:48:16 <lajoskatona> no idea :-)
14:48:17 <liuyulong> OK, I'm not fimilar with dibbler procedure, because we did not use it in production envrionment.
14:48:22 <lajoskatona> need a lawyer....
14:48:51 <liuyulong> #link https://www.mozilla.org/en-US/MPL/2.0/
14:52:31 <liuyulong> If the dibbler procedure is simple, maybe we can directly implement by ovs-agent (a local controller) and flows like distributed DHCP now. :)
14:53:28 <haleyb> OVN actually added support for PD, but it's not configured in neutron, but i thought it also used dibbler
14:53:45 <haleyb> or maybe not, it's been a while
14:54:03 <haleyb> it is listed in the "gaps" document
14:56:22 <liuyulong> Alright, if there is a chance we can say goodbye to an external process, I will raise both hands in favor. :)
14:57:54 <liuyulong> OK, no more bugs.
14:57:57 <liuyulong> #topic On demand agenda
14:59:29 <lajoskatona> There's a thread regarding BGP, BFD and BGPVPN:
14:59:29 <lajoskatona> http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022446.html
15:00:06 <liuyulong> Got it, a really long story. :)
15:00:20 <liuyulong> OK, I think we should end here.
15:00:24 <liuyulong> Thank you guys.
15:00:30 <liuyulong> #endmeeting