Vivek,
I will try to join the DVR meeting. Since it conflicts with one of my
other meeting (from my real job), I may join late or may not be able to
join at all. If I missed it, please see if you can join FWaaS meeting at
Wed 11:30AM PST on openstack-meeting-3. Otherwise, a separated meeting
is still preferred
Thanks
Yi
On 7/4/14, 12:23 AM, Narasimhan, Vivekanandan wrote:
Hi Yi,
Swami will be available from this week.
Will it be possible for you to join the regular DVR Meeting (Wed 8AM
PST) next week and we can slot that to discuss this.
I see that FwaaS is of much value for E/W traffic (which has
challenges), but for me it looks easier to implement the same in N/S
with the
current DVR architecture, but there might be less takers on that.
--
Thanks,
Vivek
*From:*Yi Sun [mailto:beyo...@gmail.com]
*Sent:* Thursday, July 03, 2014 11:50 AM
*To:* openstack-dev@lists.openstack.org
*Subject:* Re: [openstack-dev] DVR and FWaaS integration
The NS FW will be on a centralized node for sure. For the DVR + FWaaS
solution is really for EW traffic. If you are interested on the topic,
please propose your preferred meeting time and join the meeting so
that we can discuss about it.
Yi
On 7/2/14, 7:05 PM, joehuang wrote:
Hello,
It's hard to integrate DVR and FWaaS. My proposal is to split the
FWaaS into two parts: one part is for east-west FWaaS, this part
could be done on DVR side, and make it become distributed manner.
The other part is for north-south part, this part could be done on
Network Node side, that means work in central manner. After the
split, north-south FWaaS could be implemented by software or
hardware, meanwhile, east-west FWaaS is better to implemented by
software with its distribution nature.
Chaoyi Huang ( Joe Huang )
OpenStack Solution Architect
IT Product Line
Tel: 0086 755-28423202 Cell: 0086 158 118 117 96 Email:
joehu...@huawei.com <mailto:joehu...@huawei.com>
Huawei Area B2-3-D018S Bantian, Longgang District,Shenzhen 518129,
P.R.China
*???**:*Yi Sun [mailto:beyo...@gmail.com]
*????:* 2014?7?3? 4:42
*???:* OpenStack Development Mailing List (not for usage questions)
*??:* Kyle Mestery (kmestery); Rajeev; Gary Duan; Carl (OpenStack
Neutron)
*??:* Re: [openstack-dev] DVR and FWaaS integration
All,
After talk to Carl and FWaaS team , Both sides suggested to call a
meeting to discuss about this topic in deeper detail. I heard that
Swami is traveling this week. So I guess the earliest time we can
have a meeting is sometime next week. I will be out of town on
monday, so any day after Monday should work for me. We can do
either IRC, google hang out, GMT or even a face to face.
For anyone interested, please propose your preferred time.
Thanks
Yi
On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin <c...@ecbaldwin.net
<mailto:c...@ecbaldwin.net>> wrote:
In line...
On Jun 25, 2014 2:02 PM, "Yi Sun" <beyo...@gmail.com
<mailto:beyo...@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Android-x86
http://www.android-x86.org
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
