[openstack-dev] DVR and FWaaS integration

Yi Sun beyounn at gmail.com
Tue Jul 8 04:13:54 UTC 2014


Vivek,
I will try to join the DVR meeting. Since it conflicts with one of my 
other meeting (from my real job), I may join late or may not be able to 
join at all. If I missed it, please see if you can join FWaaS meeting at 
Wed 11:30AM PST  on openstack-meeting-3. Otherwise, a separated meeting 
is still preferred

Thanks
Yi

On 7/4/14, 12:23 AM, Narasimhan, Vivekanandan wrote:
>
> Hi Yi,
>
> Swami will be available from this week.
>
> Will it be possible for you to join the regular DVR Meeting (Wed 8AM 
> PST) next week and we can slot that to discuss this.
>
> I see that FwaaS is of much value for E/W traffic (which has 
> challenges), but for me it looks easier to implement the same in N/S 
> with the
>
> current DVR architecture, but there might be less takers on that.
>
> --
>
> Thanks,
>
> Vivek
>
> *From:*Yi Sun [mailto:beyounn at gmail.com]
> *Sent:* Thursday, July 03, 2014 11:50 AM
> *To:* openstack-dev at lists.openstack.org
> *Subject:* Re: [openstack-dev] DVR and FWaaS integration
>
> The NS FW will be on a centralized node for sure. For the DVR + FWaaS 
> solution is really for EW traffic. If you are interested on the topic, 
> please propose your preferred meeting time and join the meeting so 
> that we can discuss about it.
>
> Yi
>
> On 7/2/14, 7:05 PM, joehuang wrote:
>
>     Hello,
>
>     It's hard to integrate DVR and FWaaS. My proposal is to split the
>     FWaaS into two parts: one part is for east-west FWaaS, this part
>     could be done on DVR side, and make it become distributed manner.
>     The other part is for north-south part, this part could be done on
>     Network Node side, that means work in central manner. After the
>     split, north-south FWaaS could be implemented by software or
>     hardware, meanwhile, east-west FWaaS is better to implemented by
>     software with its distribution nature.
>
>     Chaoyi Huang ( Joe Huang )
>
>     OpenStack Solution Architect
>
>     IT Product Line
>
>     Tel: 0086 755-28423202 Cell: 0086 158 118 117 96 Email:
>     joehuang at huawei.com <mailto:joehuang at huawei.com>
>
>     Huawei Area B2-3-D018S Bantian, Longgang District,Shenzhen 518129,
>     P.R.China
>
>     *???**:*Yi Sun [mailto:beyounn at gmail.com]
>     *????:* 2014?7?3? 4:42
>     *???:* OpenStack Development Mailing List (not for usage questions)
>     *??:* Kyle Mestery (kmestery); Rajeev; Gary Duan; Carl (OpenStack
>     Neutron)
>     *??:* Re: [openstack-dev] DVR and FWaaS integration
>
>     All,
>
>     After talk to Carl and FWaaS team , Both sides suggested to call a
>     meeting to discuss about this topic in deeper detail. I heard that
>     Swami is traveling this week. So I guess the earliest time we can
>     have a meeting is sometime next week. I will be out of town on
>     monday, so any day after Monday should work for me. We can do
>     either IRC, google hang out, GMT or even a face to face.
>
>     For anyone interested, please propose your preferred time.
>
>     Thanks
>
>     Yi
>
>     On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin <carl at ecbaldwin.net
>     <mailto:carl at ecbaldwin.net>> wrote:
>
>     In line...
>
>     On Jun 25, 2014 2:02 PM, "Yi Sun" <beyounn at gmail.com
>     <mailto:beyounn at gmail.com>> wrote:
>     >
>     > All,
>     > During last summit, we were talking about the integration issues
>     between DVR and FWaaS. After the summit, I had one IRC meeting
>     with DVR team. But after that meeting I was tight up with my work
>     and did not get time to continue to follow up the issue. To not
>     slow down the discussion, I'm forwarding out the email that I sent
>     out as the follow up to the IRC meeting here, so that whoever may
>     be interested on the topic can continue to discuss about it.
>     >
>     > First some background about the issue:
>     > In the normal case, FW and router are running together inside
>     the same box so that FW can get route and NAT information from the
>     router component. And in order to have FW to function correctly,
>     FW needs to see the both directions of the traffic.
>     > DVR is designed in an asymmetric way that each DVR only sees one
>     leg of the traffic. If we build FW on top of DVR, then FW
>     functionality will be broken. We need to find a good method to
>     have FW to work with DVR.
>     >
>     > ---forwarding email---
>     >  During the IRC meeting, we think that we could force the
>     traffic to the FW before DVR. Vivek had more detail; He thinks
>     that since the br-int knowns whether a packet is routed or
>     switched, it is possible for the br-int to forward traffic to FW
>     before it forwards to DVR. The whole forwarding process can be
>     operated as part of service-chain operation. And there could be a
>     FWaaS driver that understands the DVR configuration to setup OVS
>     flows on the br-int.
>
>     I'm not sure what this solution would look like. I'll have to get
>     the details from Vivek.  It seems like this would effectively
>     centralize the traffic that we worked so hard to decentralize.
>
>     It did cause me to wonder about something:  would it be possible
>     to reign the symmetry to the traffic by directing any response
>     traffic back to the DVR component which handled the request
>     traffic?  I guess this would require running conntrack on the
>     target side to track and identify return traffic.  I'm not sure
>     how this would be inserted into the data path yet.  This is a
>     half-baked idea here.
>
>     > The concern is that normally firewall and router are integrated
>     together so that firewall can make right decision based on the
>     routing result. But what we are suggesting is to split the
>     firewall and router into two separated components, hence there
>     could be issues. For example, FW will not be able to get enough
>     information to setup zone. Normally Zone contains a group of
>     interfaces that can be used in the firewall policy to enforce the
>     direction of the policy. If we forward traffic to firewall before
>     DVR, then we can only create policy based on subnets not the
>     interface.
>     > Also, I'm not sure if we have ever planed to support SNAT on the
>     DVR, but if we do, then it depends on at which point we forward
>     traffic to the FW, the subnet may not even work for us anymore
>     (even DNAT could have problem too).
>
>     I agree that splitting the firewall from routing presents some
>     problems that may be difficult to overcome.  I don't know how it
>     would be done while maintaining the benefits of DVR.
>
>     Another half-baked idea:  could multi-primary state replication be
>     used between DVR components to enable firewall operation?  Maybe
>     work on the HA router blueprint -- which is long overdue to be
>     merged Btw -- could be leveraged.  The number of DVR "pieces"
>     could easily far exceed that of active firewall components
>     normally used in such a configuration so there could be a major
>     scaling problem.  I'm really just thinking out loud here.
>
>     Maybe you (or others) have other ideas?
>
>     > Another thing that I may have to get detail is that how we
>     handle the overlap subnet, it seems that the new namespaces are
>     required.
>
>     Can you elaborate here?
>
>     Carl
>
>     >
>     > --- end of forwarding ----
>     >
>     > YI
>     >
>     >
>
>     > _______________________________________________
>     > OpenStack-dev mailing list
>     > OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>     -- 
>     Android-x86
>     http://www.android-x86.org
>
>
>
>
>     _______________________________________________
>
>     OpenStack-dev mailing list
>
>     OpenStack-dev at lists.openstack.org  <mailto:OpenStack-dev at lists.openstack.org>
>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140707/40fab091/attachment.html>


More information about the OpenStack-dev mailing list