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 <c...@ecbaldwin.net> wrote: > In line... > > On Jun 25, 2014 2:02 PM, "Yi Sun" <beyo...@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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev