Open Stack

On 08/28/2015 02:53 PM, Germy Lure wrote:
> Hi all,
>
> I have two points.
> a. For the problem in this thread, my suggestion is to introduce new 
> concepts to replace the existing firewall and SG.
> Perhaps you have found the overlap between firewall and SG. It's 
> trouble for user to select.
> So the new concepts are edge-firewall for N/S traffic and Distributed 
> firewall for W/E traffic. The former is similar to the existing 
> firewall but without E/W controlling and deployed on those nodes 
> connect with external world. The latter controls E/W traffic such as 
> subnet to subnet, VM to VM and subnet to VM and will be deployed on 
> compute nodes.
>
> We can attach firewall rules to VM port implicitly, especially the DVR 
> is disabled. I think it's difficult for a user to do that explicitly 
> while there are hundreds VMs.
>
> b. For the problems like this.
> From recent mailing list, we can see so many problems introduced by 
> DVR. Such as VPNaaS, floating-IP and FWaaS co-existing with DVR, etc..
> Then, stackers, I don't know what's the standard or outgoing check of 
> releasing a feature in community. But can we make or add some 
> provisions or something else in order to avoid conflict between features?
>
> Forgive my poor English
> BR,
> Germy
>
> On Thu, Aug 27, 2015 at 11:44 PM, Mickey Spiegel <emspiege at us.ibm.com 
> <mailto:emspiege at us.ibm.com>> wrote:
>
>     Bump
>
>     The FWaaS team would really like some feedback from the DVR side.
>
>     Mickey
>
>     -----Mickey Spiegel/San Jose/IBM wrote: -----
>     To: openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>
>     From: Mickey Spiegel/San Jose/IBM
>     Date: 08/19/2015 09:45AM
>     Subject: [fwaas][dvr] FWaaS with DVR
>
>     Currently, FWaaS behaves differently with DVR, applying to only
>     north/south traffic, whereas FWaaS on routers in network nodes
>     applies to both north/south and east/west traffic. There is a
>     compatibility issue due to the asymmetric design of L3 forwarding
>     in DVR, which breaks the connection tracking that FWaaS currently
>     relies on.
>
>     I started an etherpad where I hope the community can discuss the
>     problem, collect multiple possible solutions, and eventually try
>     to reach consensus about how to move forward:
>     https://etherpad.openstack.org/p/FWaaS_with_DVR
>
>     I listed every possible solution that I can think of as a starting
>     point. I am somewhat new to OpenStack and FWaaS, so please correct
>     anything that I might have misrepresented.
>
>     Please add more possible solutions and comment on the possible
>     solutions already listed.
>
>     Mickey
>
>
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
      I agree that FWaas is overlap with security group,  and many my 
colleagues who try to use neutron api always ask me a question, what is 
the difference between
security group and FWaaS?  I try to explain, FWaas is not only 
responsible security for E/W traffic but also  responsible for N/S 
traffic, and security group is definitely
used to security E/W traffic.
      Now in kilo release, DVR is the related mature feature in neutron, 
but it isn't compatible with FWaaS, in DVR deployment, personally, i 
think FWaaS only takes care
of N/S traffic that is reasonable, and security group takes care of E/W 
traffic.

denghui
Br


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150830/08f516a5/attachment.html>