[RFE][floatingip port_forwarding] Add port ranges

Bug #1885921 reported by Pedro Henrique Pereira Martins
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Wishlist
Pedro Henrique Pereira Martins

Bug Description

Problem Description
=================

Currently, if a user wants to create NAT rules that cover multiple ports, he/she needs to create them one by one, which is cumbersome in some use cases. Having said that, we suggest changing the Floating IP port forwarding API to allow the use of port ranges to create NAT rules. The changes are presented as follows

Proposed Change
===============

### API JSON

We propose to extend the current floating IP port forwarding API to handle a range of ports instead of a one-to-one mapping. We have different alternatives to implement such a feature. We can change the JSON the API receives, adding new attributes, such as `internal_port_range` or `internal_port_beg` and `internal_port_end`, or we can just send a String in the attribute `internal_port` such as `80-83` and the same to the `external_port`.

For example:

Current JSON :

{
  "port_forwarding": {
    "protocol": "tcp",
    "internal_ip_address": "172.16.0.7",
    "internal_port": 80,
    "internal_port_id": "b67a7746-dc69-45b4-9b84-bb229fe198a0",
    "external_port": 8080,
    "description": "desc"
  }
}

Adding new attributes :

{
  "port_forwarding": {
    "protocol": "tcp",
    "internal_ip_address": "172.16.0.7",
    "internal_port_beg": 80,
    "internal_port_end": 83,
    "internal_port_id": "b67a7746-dc69-45b4-9b84-bb229fe198a0",
    "external_port_beg": 8080,
    "external_port_end": 8083,
    "description": "desc"
  }
}

Or, the alternative, changing the content of the attributes:

{
  "port_forwarding": {
    "protocol": "tcp",
    "internal_ip_address": "172.16.0.7",
    "internal_port": "80-83",
    "internal_port_id": "b67a7746-dc69-45b4-9b84-bb229fe198a0",
    "external_port": "8080-8083"
    "description": "desc"
  }
}

We believe that the last JSON format is the best one; because it generates fewer changes in the API usage and is simple for the user to understand and use. Therefore, these are the changes we are proposing to be implemented.

### Database persistence

Besides the JSON (rest API), we will need to change the way that the application persists the port forwarding rules in the database. We have two different alternatives to change the database schema.

Using the current database schema sample:

+-----------------------------------+-----------------------+-----------------------+
| id______________________| A1_____________| B4_____________|
+-----------------------------------+-----------------------+-----------------------+
| floatingip_id____________| C2_____________| C2______________|
+-----------------------------------+-----------------------+-----------------------+
| external_port___________| 80_____________| 81______________|
+-----------------------------------+-----------------------+-----------------------+
| internal_neutron_port_id | D3_____________| D3_____________|
+-----------------------------------+-----------------------+-----------------------+
| protocol________________| tcp____________| tcp_____________|
+-----------------------------------+-----------------------+-----------------------+
| socket__________________| 172.16.0.7:8080 | 172.16.0.7:8081 |
+-----------------------------------+-----------------------+-----------------------+

The above DB dump shows the scenario of a user creating a floatingip port forwarding rules with the port ranges 80-81 mapping into a VM ports range 8080-8081. Using this method, we will delegate all the responsibility of maintaining the ranges to the application level since the ports range is not specified in the DB schema.

On a different approach, we can work using an extended database schema:

+-----------------------------------+-----------------+
| id______________________| A1_________|
+-----------------------------------+-----------------+
| floatingip_id____________| C2_________|
+-----------------------------------+-----------------+
| external_port___________| 80-81______|
+-----------------------------------+-----------------+
| internal_neutron_port_id | D3_________|
+-----------------------------------+-----------------+
| protocol________________| tcp________|
+-----------------------------------+-----------------+
| internal_ip_address______| 172.16.0.7 _|
+-----------------------------------+-----------------+
| internal_port____________| 8080-8081 |
+-----------------------------------+-----------------+

Using the above proposal, we will reduce the number of entries in the database to represent a port range; therefore, we will remove from the application level the responsibility to find and join all the sequential ports in a floatingip id rule. However, the application has to handle ports collision.

We think that the last alternative for the DB schema changes suits better the context we have in Neutron, because we can easily see an entry in the DB table and identify the ports that this rule uses.

### Validations

Here follows a summary of all of the validation executed by the system:

    - Only N(external port[s]) to N (internal port[s]) are allowed or N(external port[s]) to 1 (internal port). Therefore, all of the other combinations (1-N, N-M, M-N) are not allowed and will generate an error

    - When defining a port(s) range, the ports in this range cannot be already in use by any other port forwarding rule for the same floating IP and protocol

    - A valid port is a number between 1 and 65535. All other cases will generate an error. Even though “0” is a valid port, we will not allow its use as it is reserved.

    - The notation to define a port range is the following: <port_range_begin>[-<port_range_end>]; anything that does not match this definition will generate an error.

This is the change we are proposing to be implemented.

Tags: rfe-approved
Changed in neutron:
assignee: nobody → Pedro Henrique Pereira Martins (pedrohpmartins)
Hongbin Lu (hongbin.lu)
Changed in neutron:
importance: Undecided → Wishlist
Revision history for this message
Slawek Kaplonski (slaweq) wrote :

Hi,

I would like to discuss it on next Neutron drivers meeting which will be on Friday: http://eavesdrop.openstack.org/#Neutron_drivers_Meeting - so it would be great if You could join there if there would be any additional questions. But RFE should be discussed even if You will not be able to attend this meeting.

Revision history for this message
Akihiro Motoki (amotoki) wrote :

Generally it makes sense to me.

I have a question:
You mentioned "N(external port[s]) to 1 (internal port)" is allowed. How does it work?
I think one external port is mapped to one internal port, but I might be missing something.

The following are comments from me.

Regarding the API, I would like to know opinions from others.
The first one matches what we have in the security group rule API.
The latter is also acceptable I think.

Regrading the DB schema, I think we need to have the DB schema which allows to generate an API response (same as in an API request).

Revision history for this message
Akihiro Motoki (amotoki) wrote :

One more thing I forgot to ask.
What is a real usecase to use a consecutive port range?
I don't think it is common to use a consecutive port range of listened ports.

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

We decided to approve the RFE on the drivers meeting. Now we would like to see spec with detailed info about API and DB changes to be able to discuss details of the future implementation there.

tags: added: rfe-approved
removed: rfe
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron-specs (master)

Fix proposed to branch: master
Review: https://review.opendev.org/739549

Changed in neutron:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/798961

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron-lib (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-lib/+/811456

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron-lib (master)

Reviewed: https://review.opendev.org/c/openstack/neutron-lib/+/811456
Committed: https://opendev.org/openstack/neutron-lib/commit/e686f3d0d36a519a2efe80e4273749e08c80e521
Submitter: "Zuul (22348)"
Branch: master

commit e686f3d0d36a519a2efe80e4273749e08c80e521
Author: Pedro Henrique Pereira Martins <email address hidden>
Date: Tue Sep 28 14:15:41 2021 -0300

    Add default values in port forwarding port ranges definitions

    Also, add a new common type 'PortRanges' to validate port
    ranges fields to the specific format PORT_RANGE:PORT_RANGE.

    Implements: blueprint floatingips-portforwarding-ranges
    Related-Bug: #1885921
    Change-Id: Idd257d6e64ef43ccf7afabd30003986628b0d25a

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron-lib (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-lib/+/832338

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron-lib (master)

Reviewed: https://review.opendev.org/c/openstack/neutron-lib/+/832338
Committed: https://opendev.org/openstack/neutron-lib/commit/1dde6c24b777a86eb1a562a4ee2ca5019ac1e08a
Submitter: "Zuul (22348)"
Branch: master

commit 1dde6c24b777a86eb1a562a4ee2ca5019ac1e08a
Author: Pedro Henrique <email address hidden>
Date: Mon Mar 7 11:56:18 2022 -0300

    Add custom range parameters on port_range validator

    To maintain the behavior of port forwarding
    validations that denies the port number 0 when
    creating a new port forwarding rule for floating
    IPs, we will need to extend the
    'validate_port_range_or_none' validator to allow
    us to define the acceptable port ranges when
    validating a value.

    This patch is one of a series of patches
    to implement floating ip port forwarding with
    port ranges.

    The specification is defined in:
    https://github.com/openstack/neutron-specs/blob/master/specs/wallaby/port-forwarding-port-ranges.rst

    Change-Id: I0e11885e15616509942d60fbced3ff8e14cac654
    Implements: blueprint floatingips-portforwarding-ranges
    Related-Bug: #1885921

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (master)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/798961
Committed: https://opendev.org/openstack/neutron/commit/b271c82d10b588d94c3278640a8f144fa55ac65a
Submitter: "Zuul (22348)"
Branch: master

commit b271c82d10b588d94c3278640a8f144fa55ac65a
Author: Pedro Martins <email address hidden>
Date: Sat Aug 24 18:54:17 2019 -0300

    Extend database to support portforwardings with port range

    This patch is the second of a series of patches
    to implement floating ip port forwarding with
    port ranges.

    The specification is defined in:
    https://github.com/openstack/neutron-specs/blob/master/specs/wallaby/port-forwarding-port-ranges.rst

    Implements: blueprint floatingips-portforwarding-ranges
    Related-Bug: #1885921
    Change-Id: I43e0b669096df865f37c74ddbd050b3b177fd5e5

Changed in neutron:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.