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

Bug #1911126 reported by LIU Yulong
This bug affects 1 person
Affects Status Importance Assigned to Milestone
In Progress
LIU Yulong

Bug Description

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.


tags: added: l3-dvr-backlog rfe
Miguel Lavalle (minsel)
Changed in neutron:
importance: Undecided → Wishlist
Revision history for this message
LIU Yulong (dragon889) wrote :
Changed in neutron:
assignee: nobody → LIU Yulong (dragon889)
Revision history for this message
Slawek Kaplonski (slaweq) wrote :

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?

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

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

tags: added: rfe-triaged
removed: rfe
Revision history for this message
Rodolfo Alonso (rodolfo-alonso-hernandez) wrote :


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.


Revision history for this message
Miguel Lavalle (minsel) wrote :

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

Revision history for this message
LIU Yulong (dragon889) wrote :

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. : )

Revision history for this message
Slawek Kaplonski (slaweq) wrote :


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.

Revision history for this message
Slawek Kaplonski (slaweq) wrote :

@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 :)

tags: added: rfe-approved
removed: rfe-triaged
Changed in neutron:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron-specs (master)

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers