14:00:46 <liuyulong> #startmeeting neutron_l3
14:00:47 <openstack> Meeting started Wed Dec 16 14:00:46 2020 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:51 <openstack> The meeting name has been set to 'neutron_l3'
14:00:58 <lajoskatona> Hi
14:01:03 <liuyulong> Hi
14:02:19 <rubasov> hi
14:02:25 <liuyulong> No announcement from me, so let's go througth the bug directly.
14:02:41 <liuyulong> #topic Bugs
14:04:00 <liuyulong> We have 3 lists
14:04:09 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019154.html
14:04:16 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019414.html
14:04:22 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019244.html
14:04:47 <haleyb> hi
14:05:31 <liuyulong> First one:
14:05:59 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1906375
14:06:01 <openstack> Launchpad bug 1906375 in neutron "[L3] router HA port concurrently deleting" [Low,In progress] - Assigned to LIU Yulong (dragon889)
14:06:08 <liuyulong> It was reported by me.
14:06:26 <liuyulong> During a local testing procedure, I found this exception.
14:06:56 <liuyulong> Basically it has no harm to the neutron, but raised some noise LOGs during the test.
14:07:08 <slaweq> hi
14:07:28 <liuyulong> I've summitted the patch: https://review.opendev.org/c/openstack/neutron/+/764913
14:07:31 <liuyulong> slaweq, Hi
14:07:49 <slaweq> I have another meeting in same time but I will be lurking here
14:08:05 <liuyulong> The patch just catch the port not exist related error, but left all other exceptions raised as it is.
14:08:28 <liuyulong> It is simple.
14:09:13 <slaweq> liuyulong: what about oleg's comment?
14:09:21 <slaweq> are You going to add debug message there?
14:10:19 <liuyulong> Yes, I saw that. The code is same to the code in l3_hamode_db, there is no log.
14:10:31 <liuyulong> So if you guys insist, I will add it.
14:11:10 <slaweq> for me it's fine, if such log would be useful we can add it in both places in follow-up patch
14:11:18 <liuyulong> https://github.com/openstack/neutron/blob/master/neutron/db/l3_hamode_db.py#L721-L729
14:12:55 <liuyulong> OK, next one
14:12:57 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1907175
14:12:58 <openstack> Launchpad bug 1907175 in neutron " intermittently ALL VM's floating IP connection is disconnected, and can be reconnected after 5-6 minutes " [Undecided,New]
14:13:23 <liuyulong> I've looked at this bug these days.
14:14:14 <slaweq> for me this one looks more like some ovs bug maybe
14:14:17 <liuyulong> This is, IMO, not pretty sure, a kernel bug of the bond mode 4.
14:14:25 <slaweq> as they said that it is fixed when they restart openvswitch
14:14:33 <slaweq> or kernel bug
14:14:37 <slaweq> but not neutron issue really
14:15:03 <liuyulong> I have a kernel patch which is trying to fix that, but it really similar to this. My case is bond mode 6.
14:15:11 <liuyulong> Wait a minute...
14:17:50 <liuyulong> #link https://marc.info/?l=linux-netdev&m=160430387811073&w=2
14:18:34 <liuyulong> There are some information about the topology in this kernel patch.
14:19:37 <liuyulong> The main issue is because the slave NIC is trying to send the IPv6 related traffic with run mac which make the physical world failed to find the way back.
14:21:11 <liuyulong> The LP bug reportor said they use the spine-leaf in their DC as well.
14:21:33 <liuyulong> So maybe they can try to find the issue in such way.
14:23:16 <liuyulong> tcpdump the slave NIC to see if it will send some packets out, and monitor the MAC table in the switch to see if the learnt entry is refrshed to disturb the traffic.
14:25:16 <liuyulong> This is really a relly complicated issue, my suggestion for the user is to invite their switch manufacturer to work together to find out the real issue.
14:26:06 <liuyulong> Sometimes, the switch forwarding protocol may be different in implementation which will result some unexcepted behavior.
14:29:42 <liuyulong> OK, no comments.
14:29:43 <liuyulong> Next one
14:29:46 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1905295
14:29:48 <openstack> Launchpad bug 1905295 in neutron "[RFE] Allow multiple external gateways on a router" [Wishlist,New] - Assigned to Bence Romsics (bence-romsics)
14:30:20 <liuyulong> In Last L3 meeting and last driver meeting, this had beed disscussed.
14:30:32 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1905295/comments/9
14:30:50 <liuyulong> Bence had replied a long comment. : )
14:33:10 <rubasov> I hope I made some progress with the alternative we discussed
14:33:33 <liuyulong> So my response can be: if you do not need floating IP, but you want multiple external interface. You may do it like this.
14:34:03 <liuyulong> Change your mind of that "external network" to "provider network" which should be a common use.
14:34:33 <liuyulong> So if you have multiple "provider network", then you can create VMs on it. And as many interface as you want.
14:35:27 <rubasov> I guess I would have the provider networks as external, not putting VMs directly on them
14:36:37 <liuyulong> The external network are basically for L3 floating IP(NAT) which is for neutron to support some product in users' view, aka Elastic Public IP.
14:36:43 <rubasov> the change in neutron-dynamic-routing seems way simpler than making multiple external gw-s possible in neutron
14:37:45 <rubasov> I think I will explore what exaclty that change in neutron-dynamic-routing would be
14:37:51 <liuyulong> Yes, you can do that, but external network is sometimes not visible to common user.
14:38:12 <rubasov> but overall I like this alternative
14:38:31 <rubasov> looks like it spares us from some significant amount of work
14:39:01 <lajoskatona> Just a question here: for me it seems strange (perhasp doc issue) that we can add external net to router as interface which is more "internal"
14:39:11 <liuyulong> Cool, it's glad to see that we do not need to involve changing all L3 related stuff.
14:39:17 <lajoskatona> So perhaps it is just how I understand the API doc
14:39:58 <liuyulong> But can be done in some magic actions.
14:40:12 <rubasov> if the neutron team agrees I'd definitely like to propose a change to the api-ref clearing this up
14:40:13 <liuyulong> lajoskatona, you can consider the external network is a common one.
14:40:41 <liuyulong> lajoskatona, so it has subnets, then it can be attach to a router.
14:41:18 <lajoskatona> liuyulong: ok, it's really good
14:41:21 <liuyulong> lajoskatona, but is is currently not available for common user, it is admin only action.
14:41:46 <lajoskatona> liuyulong: yeah, that's fair, as it is more an infrastructure thing
14:41:52 <rubasov> (that api-ref piece blocked my thinking about this alternative for quite some time)
14:43:42 <liuyulong> rubasov, my thougth is not to use the name "external network" in such case. Because the code has many "external_xxx", "external_yyy". My suggestion is to use "provider network".
14:44:29 <liuyulong> And the deployment guide in doc.openstack.org for neutron, has a provider network only option.
14:44:52 <rubasov> technically it's a decision done years ago I guess, the network already has an attribute called "external"
14:46:14 <liuyulong> #link https://docs.openstack.org/install-guide/launch-instance-networks-provider.html
14:46:23 <rubasov> though I'm not sure if that's bit is used anywhere when attaching a subnet of the external=true network as a router interface
14:46:38 <liuyulong> And there is a routed provider networks guide:
14:46:40 <liuyulong> #link https://docs.openstack.org/neutron/victoria/admin/config-routed-networks.html
14:47:13 <liuyulong> Totally no floating IP concept in these guide.
14:47:32 <liuyulong> rubasov, my idea is not to attach a network's subnet with  external=true.
14:48:15 <liuyulong> I remember there are some bugs related to such action...
14:48:48 <liuyulong> Some routers added external gateway to the network. Some added the subnet.
14:49:04 <rubasov> but then what is the meaning of that external bit, if I shoud set it to False on a network that's actually external?
14:49:40 <liuyulong> IMO, it really not a good option which may case the DVR, routing table wich some unexcepted hehaviors.
14:50:15 <liuyulong> rubasov, remember the L3 toplogy
14:50:42 <liuyulong> rubasov, user's network needs to go through the "Router" then to the external network.
14:51:03 <liuyulong> rubasov, the external gateway of a router is the leg to the outsider world.
14:52:20 <rubasov> that's exactly my point in my LP comment, that the API today allows an external net's subnet as a router interface
14:52:23 <lajoskatona> but this is only a flag (for the user/admin) on the API or really makes something different on the backend?
14:52:39 <rubasov> so can that be my router's north leg instead of the router gw?
14:55:00 <liuyulong> rubasov, you can, but just routing, no NAT. And again, in order to make things clear, we should can such network as "provider network" to distinguish the concepts.
14:55:04 <rubasov> lajoskatona: that's a very good question which is hard to very hard to answer by grepping through the code
14:55:54 <liuyulong> lajoskatona, same answer. No NAT, but only routing in the backend.
14:56:36 <lajoskatona> ok thanks
14:56:51 <lajoskatona> that's enough for me
14:56:56 <rubasov> ok, I think we are on the same page
14:58:06 <liuyulong> OK, thanks then, no bugs from me now.
14:58:32 <liuyulong> We still have 2 mins.
14:58:36 <liuyulong> #topic On demand agenda
14:58:54 <liuyulong> One min now.
14:59:02 <liuyulong> Any thing we need to take care?
14:59:10 <lajoskatona> liuyulong: https://review.opendev.org/c/openstack/neutron-specs/+/767337
14:59:33 <lajoskatona> liuyulong: this is (draft) spec for bfd support, if you could check it would be really helpful
14:59:48 <liuyulong> Got it, I will review it recent days.
14:59:51 <lajoskatona> of course others' comments as well really helpful
14:59:57 <lajoskatona> thanks
15:00:24 <liuyulong> OK time is up.
15:00:29 <liuyulong> #endmeeting