Open Stack

Carl,
For the overlap IP, I was thinking about whether we could have a case 
where two VMs have the same subnet but belongs to different network. So 
if we create policy base on subnet, how will it work.

Yi

On 6/29/14, 12:43 PM, Carl Baldwin 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
> 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/20140702/95918d60/attachment.html>