Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140629/09699748/attachment.html>