[openstack-dev] About DVR limit

joehuang joehuang at huawei.com
Fri Jan 16 02:21:16 UTC 2015


Hi, Swami,

The use case for central south-north mode: 1) All compute nodes not connecting to external network directly 2) FIP/SNAT/VPN function  will be done centrally on hardware router.

New questions about “We were even initially planning to distribute the SNAT”

Do you mean: 1) Dynamic routing will be implemented before that, 2 ) Full distributed SNAT or only provide multi-SNAT network nodes

Best Regards
Chaoyi Huang ( Joe Huang )


From: Vasudevan, Swaminathan (PNB Roseville) [mailto:swaminathan.vasudevan at hp.com]
Sent: Friday, January 16, 2015 12:56 AM
To: joehuang; 龚永生
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: Re:RE: [openstack-dev] About DVR limit

Hi Joehuang,
Thanks for your input and description of the problem.
What you are stating is just have DVR functionality for East-West traffic and all North-South traffic should go through the Centralized Router.
The North-South distributed reduces the burden in the Centralized Node. We eventually need to get away from the centralized node model.
I am not sure why there would be a use case to go back to the centralized model.

We were even initially planning to distribute the SNAT, but we just left it there centralized just to support the legacy services such as VPN.
Once we have service insertion and service chaining then we can distribute the SNAT functionality.

If you have a use case and willing to work on it and contribute code upstream, please let me know.

Thanks
Swami

From: joehuang [mailto:joehuang at huawei.com]
Sent: Wednesday, January 14, 2015 7:07 PM
To: 龚永生; Vasudevan, Swaminathan (PNB Roseville)
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: Re:RE: [openstack-dev] About DVR limit

Hello,

Yongseng, correct, your description is much more concise, we need a configuration:

east-west, DVR
south-north, legacy mode.

Best Regards
Chaoyi Huang ( Joe Huang )

From: 龚永生 [mailto:gong.yongsheng at 99cloud.net]
Sent: Thursday, January 15, 2015 10:18 AM
To: Vasudevan, Swaminathan (PNB Roseville)
Cc: joehuang; OpenStack Development Mailing List (not for usage questions)
Subject: Re:RE: [openstack-dev] About DVR limit


Hi, Swami, Joehuang,
in dvr compute nodes, it is 1:1 NAT FIP, means the floatingip for VM, and  it is in the namespace of qrouter-xxxx.
but in dvr_snat node, it is 1:N NAT IP, it is for neutron router, and for the VMs which have no 1:1 FIP, implemented in namesapce snat-xxx.

Joehuang's case can be implemented in legacy mode, I.E. non DVR,
but for the east-west traffic, we should consider the DVR, So I think there is a case:
east-west, DVR
south-north, legacy mode.


Thanks
yong sheng gong


在 2015-01-14 13:40:32,"Vasudevan, Swaminathan (PNB Roseville)" <swaminathan.vasudevan at hp.com<mailto:swaminathan.vasudevan at hp.com>> 写道:
Hi Joehuang,
FIP today as of Juno can be both in centralized node (dvr_snat) and distributed “dvr” compute nodes.
Thanks
Swami

From: joehuang [mailto:joehuang at huawei.com<mailto:joehuang at huawei.com>]
Sent: Tuesday, January 13, 2015 7:49 PM
To: OpenStack Development Mailing List (not for usage questions); 龚永生
Cc: Vasudevan, Swaminathan (PNB Roseville)
Subject: RE: [openstack-dev] About DVR limit

Hi, Swami,

I would like to know whether the FIP under DVR could be configured to distributed mode or central mode in Kilo, not find relevant information from http://specs.openstack.org/openstack/neutron-specs/.

For example, it will be helpful for following FIP use cases: 1) FIP will be addressed centrally by dedicated hardware 2) not all compute nodes have public address.

Best Regards
Chaoyi Huang ( Joe Huang )

From: Stamina than Valued an [mailto:souminathan at yahoo.com]
Sent: Wednesday, January 14, 2015 11:05 AM
To: 龚永生
Cc: swaminathan.vasudevan at hp.com<mailto:swaminathan.vasudevan at hp.com>; openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] About DVR limit

Hi yong Zheng,
Yes your understanding is right.
We only support ovs driver.
Regarding HA and multi network support, it will be available in kilo.

Public address consumption for north south traffic for compute node is also true. But to address this issue we do have a proposal that is worked out by the l3 sub team.

I hope this clarifies your doubts.

Please let me know if I can help you with anything else.

Thanks
Swami

Sent from my iPad

On Jan 13, 2015, at 6:01 PM, 龚永生 <gong.yongsheng at 99cloud.net<mailto:gong.yongsheng at 99cloud.net>> wrote:
Hi,
 I am yong sheng gong, I want to know if the DVR has these limits besides the documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html:

1. one subnet can be connected to DVR router only once, which is confirmed by BP https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr-multigateway
2. one network cannot have more than one subnet connecting to DVR routers


So the DVR limits the neutron model to:
one network has just one subnet, and one subnet cannot connect to more than one DVR routers.


ps.
req and limits documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html::
 DVR requirements

*        You must use the ML2 plug-in for Open VSwitch (OVS) to enable DVR.

*        Be sure that your firewall or security groups allows UDP traffic over the VLAN, GRE, or VXLAN port to pass between the compute hosts.

 DVR limitations

*        Distributed virtual router configurations work with the Open vSwitch Modular Layer 2 driver only for Juno.

*        In order to enable true north-south bandwidth between hypervisors (compute nodes), you must use public IP addresses for every compute node and enable floating IPs.

*        For now, based on the current neutron design and architecture, DHCP cannot become distributed across compute nodes.

thanks,
Yong sheng gong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/6027f55e/attachment.html>


More information about the OpenStack-dev mailing list