[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