Open Stack

In line...

On Jun 25, 2014 2:02 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.

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
> 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/136922fd/attachment.html>