Open Stack

The east/west case is the only case with this asymmetric routing problem
being discussed.  However, the north/south case might still be interesting
from a FWaaS perspective.  The fact that the router is distributed in
pieces may affect it depending on the firewall implementation.

Carl
On Jun 28, 2014 10:27 PM, "Richard Woo" <richardwoo2003 at gmail.com> wrote:

> 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 <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.
>> 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
>> 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/20140629/5d7a8ce3/attachment.html>