14:00:58 <liuyulong> #startmeeting neutron_l3
14:00:59 <openstack> Meeting started Wed Apr  1 14:00:58 2020 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:03 <openstack> The meeting name has been set to 'neutron_l3'
14:01:10 <slaweq> hi
14:01:15 <liuyulong> hi
14:01:15 <doreilly> hi
14:01:26 <ganso> hello
14:01:44 <liuyulong> hello
14:01:51 <liuyulong> OK, let's start
14:01:52 <liuyulong> #topic Announcements
14:02:37 <liuyulong> The team announcements:
14:02:39 <liuyulong> #link http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-03-30-21.00.log.html#l-11
14:04:07 <lajoskatona> o-
14:04:11 <lajoskatona> o/
14:05:24 <liuyulong> Sorry, bad network connection...
14:05:49 <liuyulong> Please add your topic on this link for our virtual PTG
14:05:51 <liuyulong> #link https://etherpad.openstack.org/p/neutron-victoria-ptg
14:07:45 <liuyulong> And hope you guys well in the near future. Protect yourself in safety.
14:07:56 <liuyulong> OK, no more announcement from me then.
14:08:08 <liuyulong> let's move on.
14:08:12 <liuyulong> #topic Bugs
14:08:37 <liuyulong> First one
14:08:47 <liuyulong> #link https://launchpad.net/bugs/1866445
14:08:49 <openstack> Launchpad bug 1866445 in neutron "br-int bridge in one compute can't learn MAC addresses of VMs in other compute nodes" [Medium,In progress] - Assigned to Li YaJie (yjmango)
14:09:26 <liuyulong> We have 2 potential fixes of this:
14:09:28 <liuyulong> #link https://review.opendev.org/#/c/712640/
14:09:38 <liuyulong> #link https://review.opendev.org/#/c/715419/
14:10:40 <liuyulong> We have talked about this bug about 3 weeks ago
14:11:10 <liuyulong> According to the comments of the bug, there are some uses case related to L3 router, so let's review it again.
14:11:50 <liuyulong> doreilly, may I have the detail about the comments of flooding for the case "not connect router".
14:12:32 <doreilly> yes. If the subnet is not connected to a dvr router, there is flooding
14:12:36 <liuyulong> doreilly, you are Darragh O'Reilly, right?
14:12:41 <doreilly> yes
14:13:17 <liuyulong> You could describe the case like this
14:13:20 <liuyulong> """ * For example L2 flooding, vm1(sub1, host1), vm2(sub1, host1), vm3(sub1, host2).
14:13:20 <liuyulong> Ping from vm1 to vm3, the vm2 can also grab packets. """
14:13:57 <doreilly> ok
14:14:24 <doreilly> say sub1 is not attached to a dvr router
14:14:39 <liuyulong> That's the case Li Yajie pasted.
14:14:43 <doreilly> and you ping from vm1 to vm3
14:15:17 <doreilly> then vm2 will see the return pings
14:15:20 <liuyulong> VM2 can dump the ping packet?
14:15:38 <liuyulong> OK
14:15:56 <doreilly> yes
14:16:34 <liuyulong> What's the security group driver?
14:16:56 <doreilly> iptables_hybrid
14:17:24 <liuyulong> Have you try this fix: https://review.opendev.org/#/c/712640/
14:17:42 <liuyulong> ^ yes, it's my bad, I just missed that driver check.
14:18:40 <doreilly> yes - this is my problem with https://review.opendev.org/#/c/712640
14:20:50 <doreilly> BTW - the patch works when the subnet is connected to a dvr router
14:21:24 <liuyulong> So, the reply ping packet hits the NORMAL in table=60 on br-int (host1)?
14:21:39 <doreilly> yes
14:23:57 <liuyulong> I'm confusing why it not hit the flow "actions=strip_vlan,output:"tap39966dd7-41""...
14:24:21 <liuyulong> Tunnel bridge does not add the local vlan to the packet?
14:24:38 <doreilly> what table and priority is that?
14:26:13 <liuyulong> table=60 priority=20, with the fix of https://review.opendev.org/#/c/666991/
14:26:29 <liuyulong> The patch "Add accepted egress direct flow"
14:27:30 <liuyulong> It increased the priority from 4 to 20.
14:28:07 <doreilly> I think that flow will only exist if the subnet is attached to a dvr router - but I need to check
14:28:33 <liuyulong> The whole flow is "priority=20,dl_vlan=3,dl_dst=fa:16:3e:30:96:da actions=strip_vlan,output:"tap39966dd7-41""
14:29:25 <liuyulong> doreilly, sure, thank you
14:30:02 <doreilly> yes - it comes from install_dvr_to_src_mac() - which is only dvr
14:30:43 <liuyulong> So, anyway, this patch https://review.opendev.org/#/c/712640/ is simple, and it should be required for iptables_hybrid.
14:31:25 <liuyulong> Patch https://review.opendev.org/#/c/715419/ could also be applied for us to fix such no-subnet cases.
14:32:30 <doreilly> but explicitly_egress_direct=true should not cause flooding if dvr is not used?
14:32:34 <liuyulong> doreilly, for patch https://review.opendev.org/#/c/715419/, it is a bit complicated, so if it is possible to narrow down the code in such output flow.
14:33:23 <liuyulong> doreilly, this is a bit different, the fix is for "egress".
14:33:40 <liuyulong> This flooding is now "ingress" flooding.
14:34:06 <liuyulong> From the perspective of virtual machine
14:34:38 <doreilly> I'm still trying to understand https://review.opendev.org/#/c/666991/ - I think it's quite complicated.
14:35:31 <liuyulong> doreilly, yes, it is. Neutron has many use cases. It was trying to cover those.
14:35:54 <liuyulong> For instance, openflow firewall, enable firewall, and iptables firewall (I just missed).
14:36:37 <doreilly> ok - I understand.
14:36:41 <liuyulong> And more complicated things are mixed compute node and network node and HA router gateway MACs.
14:37:51 <liuyulong> doreilly, are you the co-author of https://review.opendev.org/#/c/715419/ ?
14:38:03 <doreilly> okay. If you think https://review.opendev.org/#/c/712640 is the right way - I'm okay with that.
14:38:45 <liuyulong> 712640 is needed for non-openflow firewall cases.
14:39:01 <liuyulong> 715419 can be used to handle this "ingress" flood case.
14:39:35 <liuyulong> IMO, no conflict
14:40:02 <doreilly> okay
14:41:23 <liuyulong> doreilly, alright then, thank you for attending the meeting, we can continue the discuss in the gerrit or the LP bug.
14:41:40 <doreilly> no problem. and thank you
14:42:10 <liuyulong> Next bug
14:42:16 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1869354
14:42:16 <openstack> Launchpad bug 1869354 in neutron "FIP isn't properly created for octavia loadbalancers" [Undecided,Invalid]
14:42:41 <liuyulong> The bug has a clue that restart all agents can fix the issue.
14:43:31 <liuyulong> So, it is not reproducible, then next one
14:44:07 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1869887
14:44:08 <openstack> Launchpad bug 1869887 in neutron "L3 DVR ARP population gets incorrect MAC address in some cases" [Undecided,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:45:28 <liuyulong> The patch has been uploaded https://review.opendev.org/#/c/716302/
14:46:40 <liuyulong> It makes sense to me.
14:47:01 <slaweq> thx
14:47:23 <liuyulong> We meet some cases like the ports are created under the router, but real use of the port is only for IP address.
14:47:43 <liuyulong> The mac sometimes is not the port allocated MAC.
14:48:30 <slaweq> octavia is doing that for example
14:48:55 <liuyulong> So the gateway will not try to send ARP for the right one which causes the link unreachable.
14:50:16 <liuyulong> So, one more thing is we should add a note for this change in case there are some unknown usage.
14:51:07 <slaweq> liuyulong: what note You have in mind? Release note?
14:51:46 <liuyulong> And add tips for the users, if you want the arp entry in your router namespace, you should make your ports bound.
14:51:56 <liuyulong> slaweq, yes, release note
14:52:18 <slaweq> hmm, ok, I can add some
14:53:22 <liuyulong> OK, no more bugs from me then.
14:53:35 <slaweq> I opened one new today
14:53:37 <slaweq> https://bugs.launchpad.net/neutron/+bug/1870114
14:53:39 <openstack> Launchpad bug 1870114 in neutron "Trunk subports aren't treated as dvr serviced ports" [Medium,New] - Assigned to Slawek Kaplonski (slaweq)
14:54:18 <slaweq> I think that fix for it will be easy, as we should probably add trunk subports to dvr serviced ports list, together with compute, dhcp and loadbalancer ports
14:54:33 <slaweq> I'm checking that now locally and I will send patch hopefully today
14:55:33 <liuyulong> slaweq, cool, nice catch
14:56:00 <slaweq> thx
14:56:48 <liuyulong> OK, time is running out.
14:56:58 <liuyulong> let's move on.
14:57:02 <liuyulong> #topic OVN_L3
14:57:39 <liuyulong> I found a small devstack problem for OVN.
14:57:55 <liuyulong> When I test this https://review.opendev.org/#/c/705660/
14:58:47 <liuyulong> I have 5 nodes, 1 for OVN db only, 2 for compute nodes, and 2 for gateway nodes.
14:59:21 <liuyulong> So for that ovn DB node, the local.conf I just remove the "enable_service ovn-controller". It only has "enable_service ovn-northd".
15:00:32 <liuyulong> Then the OVS will not be configured properly, there was some error log like "ovsdb service" not found.
15:00:51 <liuyulong> Time is up....
15:01:00 <liuyulong> Let's end here.
15:01:07 <liuyulong> #endmeeting