So, do you mean that we need a better way to control snat ip address? I think it make sense, but maybe simple attribute extension can solve part problem, no need to separate it at this time. For example, add a snat-ip field in the route, like fip.
However if multiple snat ip is needed, and control which tenant ip is served by each snat ip, separate plugin may be needed. Sent from my iPad On 2014-11-6, at 下午6:21, Germy Lure <germy.l...@gmail.com> wrote: > Hi Carl and Akilesh, > > Thank you for your response and explanation. > My manager tells me that enterprises usually use several IP addresses and > ports for AT while Neutron just use external gateway port fixed IP for SNAT. > I found that if I extended the SNAT attributes, the L3 plugin will be very > complex. So I must tolerate this to provider more useful SNAT feature which > is really what customer needs. > I think as a separated service, SNAT will be easier to do this or even it can > support those scenarios. > We known that VPNaaS and FwaaS dependent on L3 route service but not AT which > also dependents on L3. From this point, L2 is the core of network service and > L3 is the core of other advanced services. ML3 is coming. > Besides, It's strange that L3's API contains a field called "snat_enable". > Isn't it? > > BR, > Germy > > On Wed, Nov 5, 2014 at 5:37 PM, Akilesh K <akilesh1...@gmail.com> wrote: > @Germy Lure, > I cannot give you a direct answer as I am not a developer. > > But let me point out that openstack can make use of many agents for l3 and > above and not just neutron-l3-agent. You may even create your own agent. > > The 'neutron-l3-agent' works that way just to keep things simple. One point > to consider is that Tenants may share same network space. So it becomes > necessary to tie a router which belongs to a tenant to the tenant's security > groups. If you try to distribute routing and firewall service you might end > up making it too complicated. > > > On Wed, Nov 5, 2014 at 2:40 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: > I don't think I know the precise answer to your question. My best guess is > that floating ips were one of the initial core L3 features implemented before > other advanced services existed. Implementing them in this way may have been > the path of least resistance at the time. > > Are you suggesting a change? What change? What advantages would your change > bring? Do you see something fundamentally wrong with the current approach? > Does it have some deficiency that you can point out? Basically, we need a > suggested modification with some good justification to spend time making that > modification. > > Carl > > Hi, > > Address Translation(FIP, snat and dnat) looks like an advanced service. Why > it is integrated into L3 router? Actually, this is not how it's done in > practice. They are usually provided by Firewall device but not router. > > What's the design concept? > > Thanks&Regards, > Germy > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
