[RFE] Add TCP/UDP port forwarding extension to L3

Bug #1491317 reported by Gal Sagie on 2015-09-02
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Reedip

Bug Description

I have searched and found many past efforts to implement port forwarding
in Neutron. I have found two incomplete blueprints [1], [2] and an
abandoned patch [3].

There is even a project in Stackforge [4], [5] that claims to implement
this, but the L3 parts in it seems older then current master.

I have recently came across this requirement for various use cases, one
of them is providing feature compliance with Docker port-mapping feature
(for Kuryr), and saving floating IP's space.

There has been many discussions in the past that require this feature,
so i assume there is a demand to make this formal, just a small examples
[6], [7], [8], [9]

The idea in a nutshell is to support port forwarding (TCP/UDP ports) on
the external router leg from the public network to internal ports, so
user can use one Floating IP (the external gateway router interface IP)
and reach different internal ports depending on the port numbers. This
should happen on the network node (and can also be leveraged for
security reasons).

I think that the POC implementation in the Stackforge project shows that
this needs to be implemented inside the L3 parts of the current
reference implementation, it will be hard to maintain something like
that in an external repository. (I also think that the API/DB
extensions should be close to the current L3 reference implementation)

I would like to renew the efforts on this feature and propose a spec for
this to the next release. And of course if any of the people interested
or any of the people that worked on this before want to join the effort,
you are more then welcome to join and comment.

[1] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding
[2] https://blueprints.launchpad.net/neutron/+spec/fip-portforwarding
[3] https://review.openstack.org/#/c/60512/
[4] https://github.com/stackforge/networking-portforwarding
[5] https://review.openstack.org/#/q/port+forwarding,n,z
[6] https://ask.openstack.org/en/question/75190/neutron-port-forwarding-qrouter-vms/
[7] http://www.gossamer-threads.com/lists/openstack/dev/34307
[8] http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-for-router-td46639.html
[9] http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-from-gateway-to-internal-hosts-td32410.html

Some more descriptions:
https://review.openstack.org/#/c/224727/2/specs/mitaka/port_forwarding.rst
https://review.openstack.org/#/q/status:abandoned+project:openstack/neutron+branch:master+topic:bp/router-port-forwarding

Gal Sagie (gal-sagie) on 2015-09-02
Changed in neutron:
assignee: nobody → Gal Sagie (gal-sagie)
tags: added: rfe
description: updated
Henry Gessau (gessau) on 2015-11-24
summary: - Add port fowrading extension to L3
+ [RFE] Add TCP/UDP port forwarding extension to L3
Akihiro Motoki (amotoki) on 2015-11-24
Changed in neutron:
importance: Undecided → Wishlist
status: New → Confirmed

I like Port forwarding don't get me wrong, but (as mentioned in the spec), providing this in a DVR context is challenging if not impossible under current circumstances, and therefore this becomes a hurdle for us if we want to provide a consistent user experience. Furthermore, this spec/feature has received very little attention both from reviewers and submitters, reflecting the fact that perhaps there isn't much appetite in solving this right now. Finally, the container use case presented is interesting, but I would imagine that port-forwarding is not exactly top priority (but I may be mistaken).

For these reasons, and until more clarity can be provided on some of the aspects raised in the spec, I'd say this may end up being deferred.

Changed in neutron:
status: Confirmed → Incomplete
assignee: Gal Sagie (gal-sagie) → nobody
Wenxin Wang (stieizc-33) wrote :

I've came across an environment with a shortage of ipv4 addresses, where port forwarding with fixed ips would really help. It seems from the spec that port forwarding on fixed ips in DVR is easier to implement than forwarding on floating ips (just like the SNAT part on the network node). Maybe this could be done first. I may be wrong, though.

I had no experience with DVR, but it seems from the Networking Guide[1] that port forwarding on floating ips have to be done in the relevant compute node.

Wenxin Wang (stieizc-33) wrote :

Sorry for the extra comment, I forgot to give the reference link.

[1] http://docs.openstack.org/networking-guide/scenario_dvr_ovs.html#architecture

Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
Oleg Ilin (oilyin) on 2016-08-23
Changed in neutron:
assignee: nobody → Oleg Ilin (oilyin)
status: Expired → Incomplete
status: Incomplete → Opinion

This expired because it lacks volunteers both review and development side, and that may fundamentally stem from the fact that no-one thinks it's a high priority use case.

Changed in neutron:
status: Opinion → Incomplete
status: Incomplete → Confirmed

We are not processing RFEs at this point during the release cycles

ilnurgi (ilnurgi87) wrote :

Hello,

I implemented it.

neutron portforwarding-list ...
neutron portforwarding-show ...
neutron portforwarding-create ...
neutron portforwarding-delete ...

I'm ready to contribute this

Oleg Ilin (oilyin) on 2016-08-24
Changed in neutron:
assignee: Oleg Ilin (oilyin) → nobody
assignee: nobody → Oleg Ilin (oilyin)
ilnurgi (ilnurgi87) on 2016-08-24
Changed in neutron:
assignee: Oleg Ilin (oilyin) → ilnurgi (ilnurgi87)

@ilnurgi, you said you 'implemented it'. Do you have patches to refer to? Are you going to revive the spec?

More importantly, who is going to work on the code *and* drive the feature to completion from review side? Is L3 subteam onboard with the idea for Ocata and is willing to trade some other ongoing work to that feature?

Kevin Benton (kevinbenton) wrote :

@Ihar, perhaps comment 8 *is* the implementation. :)

ilnurgi (ilnurgi87) on 2016-11-23
Changed in neutron:
assignee: ilnurgi (ilnurgi87) → nobody

in #11, it looks like we just lost our committer. Again, nice feature, not enough traction.

Changed in neutron:
status: Confirmed → Incomplete
Reedip (reedip-banerjee) wrote :

If possible, can I take it for Pike ?

Changed in neutron:
assignee: nobody → Reedip (reedip-banerjee)
Reedip (reedip-banerjee) on 2017-01-25
description: updated
brenda (tian-mingming) wrote :

Hi, Reedip. I am also intersted in this feature. I have posted a message in mail list, but no response. I don't know why.

Fix proposed to branch: master
Review: https://review.openstack.org/470596

Changed in neutron:
status: Incomplete → In Progress
Changed in neutron:
status: In Progress → Triaged
Kevin Benton (kevinbenton) wrote :

The RFE is approved, but the spec needs to clearly define how this will work with DVR and HA routers. We don't want an implementation that only works with certain types of routers.

tags: added: rfe-approved
removed: rfe
Changed in neutron:
status: Triaged → In Progress
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints