Hi Germy, Yes i understand now. What you request is an enahncment to the API to be able to assing these port forwarding rules in bulks per subnet. I will make sure to mention this in the spec that i am writing for this.
Thanks! Gal. On Tue, Sep 8, 2015 at 10:33 AM, Germy Lure <[email protected]> wrote: > Hi Gal, > > Thank you for your explanation. > As you mentioned, PF is a way of reusing floating IP to access several > Neutron ports. I agree with your point of view completely. > Let me extend your example to explain where I was going. > T1 has 20 subnets behind a router, and one of them is 10.0.0.0/24 named > s1. There are 100 VMs named VM1~VM100 in the subnet s1 and T1 wants to > update the same file(or something else) in those VMs. Let's have a look how > will T1 do it. > > T1 invokes Neutron API to create a port-mapping for VM1(Maybe that will be > did by operator) > For example : 172.20.20.10:4001 => 10.0.0.1:80 > And then T1 does the update task via 172.20.20.10:4001. > > Now for the VM2,VM3,...VM100, T1 must repeat the steps above with > different ports. And T1 must clean those records(100 records in DB) after > accessing. That's badly, I think. > Note that T1 still has 19 subnets to be dealt with. That's a nightmare to > T1. > To PaaS, SaaS, that also is a big trouble. > > So, can we do it like this? > T1 invokes Neutron API one time for s1(not VM1), and Neutron setups a > group of port-mapping relation. For example: > 172.20.20.10:4001 => 10.0.0.1:80 > 172.20.20.10:4002 => 10.0.0.2:80 > 172.20.20.10:4003 => 10.0.0.3:80 > ...... ...... > 172.20.20.10:4100 => 10.0.0.100:80 > Now T1 just needs focus on his/her business work not PF. > > We just store one record in Neutron DB for such one time API invoking. For > the single VM scene, we can specific private IP range instead of subnet. > For example, 10.0.0.1 to 10.0.0.3. The mapped ports(like 4001,4002...) can > be returned in the response body, for example, 4001 to 4003, also can just > return a base number(4000) and upper layer rework it. For example, 4000+1, > where 1 is the last number in the private IP address of VM1. > > Forgive my poor E. > Hope that's clear enough and i am happy to discuss it further if necessary. > > Germy > > > On Tue, Sep 8, 2015 at 1:58 PM, Gal Sagie <[email protected]> wrote: > >> Hi Germy, >> >> Port forwarding the way i see it, is a way of reusing the same floating >> ip to access several different Neutron ports (VM's , Containers) >> So for example if we have floating IP 172.20.20.10 , we can assign >> 172.20.20.10:4001 to VM1 and 172.20.20.10:4002 to VM2 (which are behind >> that same router >> which has an external gw). >> The user use the same IP but according to the tcp/udp port Neutron >> performs mapping in the virtual router namespace to the private IP and >> possibly to a different port >> that is running on that instance for example port 80 >> >> So for example if we have two VM's with private IP's 10.0.0.1 and >> 10.0.0.2 and we have a floating ip assigned to the router of 172.20.20.10 >> with port forwarding we can build the following mapping: >> >> 172.20.20.10:4001 => 10.0.0.1:80 >> 172.20.20.10:4002 => 10.0.0.2:80 >> >> And this is only from the Neutron API, this feature is usefull when you >> offer PaaS, SaaS and have an automated framework that calls the API >> to allocate these "client ports" >> >> I am not sure why you think the operator will need to ssh the instances, >> the operator just needs to build the mapping of <floating_ip, port> to the >> instance private IP. >> Of course keep in mind that we didnt yet discuss full API details but its >> going to be something like that (at least the way i see it) >> >> Hope thats explains it. >> >> Gal. >> >> On Mon, Sep 7, 2015 at 5:21 AM, Germy Lure <[email protected]> wrote: >> >>> Hi Gal, >>> >>> I'm sorry for my poor English. Let me try again. >>> >>> What operator wants to access is several related instances, instead of >>> only one or one by one. The use case is periodical check and maintain. >>> RELATED means instance maybe in one subnet, or one network, or one host. >>> The host's scene is similar to access the docker on the host as you >>> mentioned before. >>> >>> Via what you mentioned of API, user must ssh an instance and then invoke >>> API to update the IP address and port, or even create a new PF to access >>> another one. It will be a nightmare to a VPC operator who owns so many >>> instances. >>> >>> In a word, I think the "inside_addr" should be "subnet" or "host". >>> >>> Hope this is clear enough. >>> >>> Germy >>> >>> On Sun, Sep 6, 2015 at 1:05 PM, Gal Sagie <[email protected]> wrote: >>> >>>> Hi Germy, >>>> >>>> I am not sure i understand what you mean, can you please explain it >>>> further? >>>> >>>> Thanks >>>> Gal. >>>> >>>> On Sun, Sep 6, 2015 at 5:39 AM, Germy Lure <[email protected]> >>>> wrote: >>>> >>>>> Hi, Gal >>>>> >>>>> Thank you for bringing this up. But I have some suggestions for the >>>>> API. >>>>> >>>>> An operator or some other component wants to reach several VMs related >>>>> NOT only one or one by one. Here, RELATED means that the VMs are in one >>>>> subnet or network or a host(similar to reaching dockers on a host). >>>>> >>>>> Via the API you mentioned, user must ssh one VM and update even delete >>>>> and add PF to ssh another. To a VPC(with 20 subnets?) admin, it's totally >>>>> a >>>>> nightmare. >>>>> >>>>> Germy >>>>> >>>>> >>>>> On Wed, Sep 2, 2015 at 1:59 PM, Gal Sagie <[email protected]> wrote: >>>>> >>>>>> Hello All, >>>>>> >>>>>> 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 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. >>>>>> >>>>>> Thanks >>>>>> Gal. >>>>>> >>>>>> [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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> __________________________________________________________________________ >>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>> Unsubscribe: >>>>>> [email protected]?subject:unsubscribe >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> [email protected]?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best Regards , >>>> >>>> The G. >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Best Regards , >> >> The G. >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best Regards , The G.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
