14:00:36 <liuyulong> #startmeeting neutron_l3
14:00:36 <openstack> Meeting started Wed Jul 15 14:00:36 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:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:39 <openstack> The meeting name has been set to 'neutron_l3'
14:01:47 <liuyulong> hi there
14:02:44 <liuyulong> #topic Announcements
14:03:14 <liuyulong> OK, maybe here are only me. One person meeting. : )
14:03:52 <liuyulong> Our team meeting is going to be changed: I should change the meeting like this:
14:03:56 <liuyulong> https://review.opendev.org/#/c/739780/
14:04:06 <liuyulong> I should change the L3 meeting maybe.
14:04:37 <liuyulong> I will upload a change to the opendev/irc-meetings repo.
14:04:54 <ZhuXiaoYu> :)
14:05:13 <ralonsoh> hi, sorry I'm late
14:05:37 <liuyulong> hi ZhuXiaoYu
14:05:40 <liuyulong> Hi ralonsoh
14:05:48 <liuyulong> OK, I'm not alone now. : )
14:06:17 <liuyulong> Let's go through the bug list.
14:06:31 <liuyulong> #topic Bugs
14:06:33 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015784.html
14:06:39 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015897.html
14:07:13 <liuyulong> Two weeks list for this meeting.
14:08:18 <liuyulong> Most of them has been discussed before.
14:08:24 <liuyulong> First one
14:08:30 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1886116
14:08:30 <openstack> Launchpad bug 1886116 in neutron "slaac no longer works on IPv6 tenant subnets" [Low,Fix released] - Assigned to Brian Haley (brian-haley)
14:09:02 <haleyb> no router == no slaac
14:09:27 <liuyulong> It is not high level now.
14:09:51 <haleyb> that one is actually fixed
14:10:09 <liuyulong> haleyb, yes, it is well documented. : )
14:10:11 <haleyb> fixed in documenting you need a router to have router advertisements
14:11:16 <liuyulong> OK, next
14:11:55 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1886216
14:11:55 <openstack> Launchpad bug 1886216 in neutron "keepalived-state-change does not format correctly the logs" [Low,Confirmed] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:12:56 <liuyulong> ralonsoh, so the bug is only available for stable/stein?
14:14:02 <liuyulong> It should be stein and earlier versions
14:15:42 <liuyulong> So the fix is a workaround.
14:15:45 <ralonsoh> yes, only stein
14:15:53 <ralonsoh> not newer versions
14:17:54 <liuyulong> OK, the result looks good to me.
14:18:18 <liuyulong> Just confirm the bad log format in stable/queens.
14:18:36 <ralonsoh> I should backport this patch up to queens
14:19:16 <liuyulong> OK, next.
14:19:19 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1887148
14:19:19 <openstack> Launchpad bug 1887148 in neutron "Network loop between physical networks with DVR" [High,In progress] - Assigned to Darragh O'Reilly (darragh-oreilly)
14:19:56 <ralonsoh> when is this happening?
14:20:04 <liuyulong> So, it is now doing the revert.
14:20:06 <ralonsoh> when the OVS has no other flows, correct?
14:20:10 <ralonsoh> it is
14:21:10 <liuyulong> Yes, I guess, restart vswitchd and ovs-agent can reproduce the bug when you have multiple physical bridges.
14:21:43 <ralonsoh> can we find a way to, as I commented in the bug, to filter the traffic from phys-brs?
14:22:00 <ralonsoh> and block in if this traffic is going back to other phys-br?
14:22:38 <ralonsoh> I know this is tricky because the traffic is leaving br-int using normal action
14:23:30 <ralonsoh> but the alternative is reverting the previous patch
14:25:09 <liuyulong> Yes, before normal action we should know where the packet should go.
14:25:58 <liuyulong> But the ovs-agent is just Initializing, no ports info, neutron knows nothing.
14:26:15 <ralonsoh> and normal action will broadcast this packet
14:26:41 <ralonsoh> to all bridges except the one this packet is coming
14:26:52 <liuyulong> Yep, basically it works as traditional L2 switch
14:26:59 <liuyulong> Learn and forward, or flood
14:27:53 <liuyulong> Since host(vswitchd) is just started, there is no MAC learned.
14:29:31 <liuyulong> So after the revert, I will have a try to change the dvr related flow priority.
14:30:59 <liuyulong> I'm thinking during the DVR implementation these flows were unexpectedly overridded by dvr functions.
14:31:22 <liuyulong> I will test that.
14:31:50 <liuyulong> OK, next
14:32:22 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1886426
14:32:22 <openstack> Launchpad bug 1886426 in neutron "Neutron sending response to rabbitmq exchange with event type "floatingip.update.end" without updating the status of Floating IP" [Undecided,Incomplete]
14:33:17 <liuyulong> This should a known issue.
14:33:45 <liuyulong> The floating IP status is changing to ACTIVE only when the L3 agent did set it on the interface.
14:35:21 <liuyulong> But before that, the L3 plugin has done DB update (binding fixed_ip_port from None -> one_port_id), so the notification just send with old status value -- DOWN.
14:36:50 <haleyb> i was going to run through a floating ip create and associate, just to see what state it shows in the DB. it's not as if floating IP isn't working
14:37:09 <liuyulong> related code:
14:37:10 <liuyulong> #link https://github.com/openstack/neutron/blob/master/neutron/agent/l3/router_info.py#L403
14:37:16 <liuyulong> #link https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L1355
14:38:54 <liuyulong> haleyb, yes, the status should not be considered for the link status of a floating IP.
14:39:12 <liuyulong> actually there is no such way now.
14:40:08 <haleyb> yes, status active, but is state DOWN? guess the API doc should describe that too
14:41:16 <haleyb> no,  ACTIVE, DOWN and ERROR, either way have to verify
14:42:15 <liuyulong> router admin state can be DOWN, but floating IP status is not changed during this UP->DOWN action (need to confirm). So it looks a bit reliable again.
14:42:38 <liuyulong> Not reliable...
14:44:49 <liuyulong> OK, no more bugs from the deputy list.
14:44:54 <liuyulong> But I have another one.
14:44:57 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1883321
14:44:57 <openstack> Launchpad bug 1883321 in neutron "Neutron OpenvSwitch DVR - connection problem" [High,New] - Assigned to LIU Yulong (dragon889)
14:45:40 <liuyulong> This should be a really long story...
14:47:05 <liuyulong> This should be firstly realted to the egress flooding issue...
14:47:56 <liuyulong> And then, they enabled the "explicitly_egress_direct".
14:48:32 <liuyulong> So looks like the "NORMAL" flow, aka learn and forward, just does not be happy again.
14:49:16 <liuyulong> #link https://review.opendev.org/#/c/738551/
14:49:28 <liuyulong> I'm trying to address the issue in this patch.
14:49:57 <liuyulong> But the bug reporter said it can be seen on openflow security driver too.
14:51:02 <liuyulong> I'm try to reproduce that with openflow security driver, but no issue encountered.
14:51:35 <liuyulong> The issue should be something like this.
14:52:59 <liuyulong> When the VM with floating IP is communiting with out side world, the floating IP gateway MAC (or floating IP physical route IP mac) is learned on the br-int fg-dev.
14:54:17 <liuyulong> But when another VM without floating IP is trying to reach outside world, that MAC will be learned to the patch port (int-br-tun, if the tunnel is enabled, or physical-br-patch-port).
14:55:54 <liuyulong> I will continue the work of this bug.
14:59:54 <liuyulong> But one more thing, from my personal experience, maybe we should reconsider to use the NORMAL flow. I'm not a fan of using it since neutron knows everything.
15:00:27 <liuyulong> OK, time is up.
15:00:32 <liuyulong> Bye guys, thank you
15:00:37 <liuyulong> #endmeeting