Open Stack

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> wrote:

> In line...
>
> On Jun 25, 2014 2:02 PM, "Yi Sun" <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
> > 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
>
>


-- 
Android-x86
http://www.android-x86.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140702/2ec12718/attachment.html>