<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Carl,<br>
For the overlap IP, I was thinking about whether we could have a
case where two VMs have the same subnet but belongs to different
network. So if we create policy base on subnet, how will it work. <br>
<br>
Yi<br>
<br>
<div class="moz-cite-prefix">On 6/29/14, 12:43 PM, Carl Baldwin
wrote:<br>
</div>
<blockquote
cite="mid:CALiLy7oX9GjdeUbg+4cbWOjzQ6WJoG6+szZD3tqcdv43y35jVg@mail.gmail.com"
type="cite">
<p dir="ltr">In line...</p>
<p dir="ltr">On Jun 25, 2014 2:02 PM, "Yi Sun" <<a
moz-do-not-send="true" href="mailto:beyounn@gmail.com">beyounn@gmail.com</a>>
wrote:<br>
><br>
> All,<br>
> 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.<br>
><br>
> First some background about the issue:<br>
> 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.<br>
> 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.<br>
><br>
> ---forwarding email---<br>
> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> 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. <br>
> 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). </p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Maybe you (or others) have other ideas?</p>
<p dir="ltr">> 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.</p>
<p dir="ltr">Can you elaborate here?</p>
<p dir="ltr">Carl</p>
<p dir="ltr">><br>
> --- end of forwarding ----<br>
><br>
> YI<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>