Open Stack

On Tue, Sep 1, 2015 at 11:59 PM, Gal Sagie <gal.sagie at gmail.com> wrote:
> Hello All,
>
> I have searched and found many past efforts to implement port forwarding in
> Neutron.

I have heard a few express a desire for this use case a few times in
the past without gaining much traction.  Your summary here seems to
show that this continues to come up.  I would be interested in seeing
this move forward.

> 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 looked at this stack forge project.  It looks like files copied out
of neutron and modified as an alternative to proposing a patch set to
neutron.

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

I think both of these could be compelling use cases.

> 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'm sure someone will ask how this works with DVR.  It should be
implemented so that it works with a DVR router but it will be
implemented in the central part of the router.  Ideally, DVR and
legacy routers work the same in this regard and a single bit of code
will implement it for both.  If this isn't the case, I think that is a
problem with our current code structure.

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

Agreed.

> I would like to renew the efforts on this feature and propose a RFE and a
> spec for this to the
> next release, any comments/ideas/thoughts are welcome.
> 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.

I have added this to the agenda for the Neutron drivers meeting.  When
the team starts to turn its eye toward Mitaka, we'll discuss it.
Hopefully that will be soon as I'm started to think about it already.

I'd like to see how the API for this will look.  I don't think we'll
need more detail that that for now.

Carl

> [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
>
>