Regarding of user case of this feature, are you referring E-W traffic or N-S traffic?
On Wed, Jun 25, 2014 at 4:00 PM, Yi Sun <[email protected]> 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. > 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). > 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. > > --- end of forwarding ---- > > YI > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
