[RFE][L3] add ability to control router SNAT more granularly

[LIU Yulong]

Neutron router now supports SNAT when the attribute ``enable_snat`` of the gateway is set to True.
This will enable all the VMs which has no binding floating IP to access the public world.

But, generally the DataCenter bandwidths for cloud providers are not free. And some users may want to buy a higher
SNAT bandwidth for one of their VMs, a CIDR, or a subnet.

So for Neutron, it should support these scenarios:
1. enable/disable SNAT once for all (supported, controlled by ``enable_snat``)
2. enable/disable SNAT for one internal IP (of VM)
3. enable/disable SNAT for a range CIDR of IPs
4. enable/disable SNAT for a subnet

For 2., 3. and 4. scenario should have QoS support.

So I would like to add a new mechanism for Neutron to support these:
1. An new API extension to add specific SNAT type
2. An new L3 agent extension to install SNAT iptables rules.

Ideas?

[LIU Yulong (dragon889)]

Spec work:
https://review.opendev.org/c/openstack/neutron-specs/+/770540

[Slawek Kaplonski (slaweq)]

How about using address_groups (https://blueprints.launchpad.net/neutron/+spec/address-groups-in-sg-rules) for that? You don't need all those 4 cases then, just:

1. Enabled for all (like it's now, controlled by enable_snat)
2. Enabled for some IP addresses, confiugred by address group - it can be IP of single VM, subnet's cidr or some other IPs range - this may work only if enable_snat==True

What do You think?

[Slawek Kaplonski (slaweq)]

Ahh, and lets discuss that RFE on the next drivers meeting, which will be 15.01.2021.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hello:

I reviewed the spec and makes sense to have this kind of QoS feature in the code.

But IMO the spec is adding an extra complexity in the L3 agent code (for example, FIPs for groups of addresses), instead of handling the problem from the QoS perspective.

Although this is something that should be tested first, I suggest to use the tc-ct module. That means, the traffic control conntrack module to handle marked traffic. My suggestion is to mark the traffic (an IP or a group of them), mark this traffic a tracked and then apply a different filter in the interface qdisc.

As said, this is just an idea and should be tested first. But this architecture does no need the use of FIPs or additional GWs.

Regards.

[Miguel Lavalle (minsel)]

Yes, I was also a bit confused as to why we need floating IPs. Left comment in the spec

[LIU Yulong (dragon889)]

Thank you for the response.

@Slawek I'm not fimilar with the address group feature, looks like it is a L2 function? And it's related to security group? This RFE here is a L3 request, IMO.

@Rodolfo, @Miguel, for SNAT rules with independently and precisely bandwidth control, the L3 router will need an IP (from public network which is used by router's the external gateway) to set the iptables rules for SNAT. Why here we use floating is because floating IP and its binding QoS policy is the real close thing we need. This ``SNAT`` floating IP can be a service type IP to make the VMs access the public world, the ``service type IP`` will need the physical devices to do the routing configrations. That's all. Maybe I should change the name of the IP to "SNAT IP".

This is not as complicated as you imagine. We have implemented this already locally. : )

[Slawek Kaplonski (slaweq)]

Hi,

On the last drivers meeting we discussed that RFE and we decided to approve it http://eavesdrop.openstack.org/meetings/neutron_drivers/2021/neutron_drivers.2021-01-22-14.01.log.html#l-20
Let's continue discussion about implementation in the review of the spec.

[Slawek Kaplonski (slaweq)]

@Liu: I don't think address group is something L2 related. It was introduced to be used in security group rules but I don't see any reason why it can't be used somewhere else also. It is just group of IP addresses defined as separate resource in the Neutron DB.
Please check that possibility :)

[OpenStack Infra (hudson-openstack)]

Change abandoned by "liuyulong <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron-specs/+/770540
Reason: Restore if someday we want this.