14:01:15 <liuyulong> #startmeeting neutron_l3
14:01:17 <openstack> Meeting started Wed Dec  2 14:01:15 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:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:20 <openstack> The meeting name has been set to 'neutron_l3'
14:01:39 <liuyulong> long time no see
14:03:46 <liuyulong> Seems this will be another one persone meeting...
14:04:27 <liuyulong> No announcement from me today, let's scan the bug list.
14:04:35 <liuyulong> #topic Bugs
14:04:58 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018782.html
14:05:02 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-November/019032.html
14:05:08 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-November/019119.html
14:05:16 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019154.html
14:05:52 <liuyulong> First one:
14:05:53 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1903433
14:05:55 <openstack> Launchpad bug 1903433 in neutron "The duplicate route in l3 router namespace results in North-South traffic breaking" [Medium,In progress] - Assigned to yangjianfeng (yangjianfeng)
14:06:44 <liuyulong> The patch is done here：
14:06:47 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/761829/
14:07:06 <liuyulong> Just start another recheck for it.
14:09:57 <liuyulong> The input CIDR overlapping status will be checked between external subnet and user internal subnet. The unit test cases are really good to verify this.
14:11:03 <liuyulong> Next
14:11:04 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1904564
14:11:06 <openstack> Launchpad bug 1904564 in neutron "GRE tunnels over IPv6 are created in wrong way" [High,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:12:31 <liuyulong> I've not used gre for tunnels in our local cloud, but this is a valid bug.
14:14:04 <liuyulong> More like a ovs-agent mis-configuration, it's worthy to fix IMO.
14:15:03 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1904436
14:15:05 <openstack> Launchpad bug 1904436 in neutron ""gateway" option is not honored when creating a subnet with subnet pool" [Wishlist,New]
14:16:23 <liuyulong> Our IPv6 subnets are created from a subnet pool, but we have not see such issue. I will check this in my local deployment.
14:17:30 <liuyulong> But I wonder which IP the router internal gateway will set finally.
14:17:44 <liuyulong> I will keep an eye on that.
14:18:58 <liuyulong> Next one
14:18:59 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1905295
14:19:02 <openstack> Launchpad bug 1905295 in neutron "[RFE] Allow multiple external gateways on a router" [Wishlist,New] - Assigned to Bence Romsics (bence-romsics)
14:20:30 <rubasov> hi liuyulong
14:20:39 <liuyulong> This is a quite big proposal.
14:20:41 <liuyulong> hi
14:20:54 <rubasov> I saw you mentioned this
14:20:59 <liuyulong> Yes
14:21:21 <liuyulong> I saw the comments in the LP bug.
14:21:52 <rubasov> I'm also bit a afraid this could be big, that's why I would like to limit the scope as much as possible
14:22:48 <liuyulong> OK, so maybe we need some details on how to accomplish the traffic from VM to outside world, and vice versa.
14:23:12 <rubasov> by the way, does the use case make sense to you?
14:24:19 <liuyulong> I'm not sure. I think we need some details about the "multiple external gateways".
14:24:47 <liuyulong> What will this multiple external gateways use for?
14:25:16 <rubasov> basically I'd like to model a bgp+ecmp router
14:25:55 <liuyulong> The multiple external gateways are independent of each other? Or it will work together to do north-south traffic?
14:26:39 <rubasov> their faults are independent, but traffic is balanced by ecmp
14:28:33 <liuyulong> So, the router has multiple external gateways connected to multiple physical router in one single host?
14:29:04 <rubasov> yes, it does
14:29:37 <liuyulong> Or the router will be scheduled to multiple hosts, each scheduled instance has different external gateway to different physical router?
14:29:50 <rubasov> I was trying to draw it in the RFE, but launchpad ate my ascii art
14:30:02 <rubasov> but this etherpad has a better drawing
14:30:06 <rubasov> https://etherpad.opendev.org/p/neutron-multiple-external-gateways
14:30:31 <rubasov> (I just used this to prepare the RFE, nothing new there, but the drawing is better)
14:31:14 <liuyulong> Openning...
14:32:41 <rubasov> lines 28-48
14:32:42 <liuyulong> Alright, if it is the first topology. Why not add all NICs to one bond to achive the high availibility?
14:33:31 <liuyulong> And beyond that, the fault scope is still in one single host no matter how many external gateways.
14:34:19 <rubasov> I believe the people who came up with this design in my company don't like LACP recovery times in some situations
14:34:22 <liuyulong> That means if the host is done, the entire traffic will go done (if you have HA, the failover will happen).
14:34:28 <liuyulong> s/done/down
14:35:23 <rubasov> and some cases I believe they want ECMP not just between the 4 routers, but down to the compute host
14:37:21 <liuyulong> In such situation, I will suggest user to enable the DVR : )
14:37:24 <lajoskatona> Hi
14:37:29 <liuyulong> #link https://github.com/gotostack/shanghai_ptg/blob/master/shanghai_neutron_ptg_topics_liuyulong.pdf
14:38:02 <liuyulong> In shanghai PTG, I'd raised a ACTIVE-ACTIVE mode for router in a DNAT nodes.
14:39:34 <liuyulong> That proposal will also use ECMP for the floating IPs routes.
14:40:10 <rubasov> regarding dvr, in telco we so far did not have much success selling that, the people in my company very much prefer dedicated hw networking equipment
14:40:39 <liuyulong> lajoskatona, hi
14:41:39 <liuyulong> rubasov, yes that could be true, the users sometimes require some dedicated hosts for netwoking because of some security concern.
14:42:00 <lajoskatona> liuyulong: Hi
14:42:09 <rubasov> and they'd like to model that design in neutron api
14:43:16 <liuyulong> Allow me to elaborate the ACTIVE-ACTIVE DNAT topology,.
14:43:22 <rubasov> sure
14:43:59 <liuyulong> When the user try to access one floating IP, the upstream physical router will have multiple next hop IP which direct to some scheduled Router namespace.
14:44:45 <liuyulong> And in each router namespace, the iptables rules, route rules will work as centriliazed routers do.
14:45:52 <rubasov> okay, so southbound traffic is over ecmp
14:45:57 <rubasov> right?
14:46:00 <liuyulong> And in the compute node, when the packet is back to the outside world
14:46:32 <liuyulong> the ovs-agent will add some port group which is also something like ecmp to send the return packet back to the router namespace.
14:46:52 <liuyulong> Due to all these traffic we take care are L3 only,
14:47:18 <liuyulong> so the taffic can be send back to any router namespace no matter the hash rule is.
14:47:22 <liuyulong> rubasov, yes
14:47:48 <rubasov> so northbound traffic is over LAG, maybe MLAG
14:48:16 <rubasov> I believe my people favor ECMP over MLAG for some reason
14:48:35 <rubasov> but I will need to go back to them to better understand their reasons for this
14:49:28 <liuyulong> Hmmm, actually we do not care about the underlay topoloy.
14:50:34 <liuyulong> In neutron's view, we can only assume there are some neutron virtual Routers and one Upstream physical router.
14:50:55 <liuyulong> The upstream physical router has multiple path to a single distination.
14:51:45 <liuyulong> We do not care about how many fabric the hosts are connected to the upstream router.
14:53:49 <rubasov> but don't I have to represent the links in my previous picture in lines 31-35 as neutron nets (used as external gw-s)?
14:54:38 <rubasov> I don't see how could I represent that as 1 neutron network
14:55:51 <liuyulong> So this ACTIVE-ACTIVE DNAT topology is what you want?
14:56:40 <liuyulong> If so, in the picture, you can just remove R4, and link R2 to R1, R1', R1'' etc.
14:56:54 <liuyulong> Sorry
14:57:09 <liuyulong> In the picture, you can just remove R4 and R2, and link R3 to R1, R1', R1'' etc.
14:57:50 <liuyulong> The R1, R1', R1'' mean one single neutron router has multiple scheduled instance in different host.
14:58:02 <liuyulong> All these R1 instances are ACTIVE.
14:58:11 <rubasov> I'm far from sure I fully understand the active-active, I will try to better understand your slides
14:58:39 <liuyulong> They work together to surve the north-south traffice.
14:58:51 <liuyulong> s/traffic
14:58:55 <liuyulong> OK
15:00:00 <rubasov> but thank you for the questions, it helps to better formulate the use case (and see if it's valid)
15:00:36 <liuyulong> #link https://m.pgb-fc.com/docs/en-us/netscaler/media/ns-cluster-ecmp-topology.png
15:00:59 <liuyulong> Ignore all the IPs/protocls/words in this picture.
15:01:32 <liuyulong> Something like that.
15:02:03 <liuyulong> ok, time is up
15:02:17 <liuyulong> #endmeeting