Open Stack

Yes, it's an issue if there is a large subnet (performance issues due to broadcast as well as resource issues due to number of MACs on the subnet, etc. - the severity would depend on the scale+size).  Or use L3 agents/ overlay / etc. - which may have its own performance issues depending on your scale.

Several folks have come up with their own solutions.  In some form or other, you could implement rack-aware networking.  You may want to look at the following design summit proposal as well as the blueprint.

http://summit.openstack.org/cfp/details/294
https://blueprints.launchpad.net/neutron/+spec/network-tagging

If you were able to use multiple subnets and then select a network based on the scheduled HV then that would solve the problem.  The above mentioned blueprint addresses this I believe.

- manish

From: sylecn <sylecn at gmail.com<mailto:sylecn at gmail.com>>
Date: Wednesday, April 23, 2014 12:37 AM
To: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: [Openstack-operators] Do you recommend large subnets in provider network?

Hi all,

I'm building a private cloud using flat provider network. For the private network, I'm facing a choice between using a big subnet and multiple small subnets. I am seeking for advice.

I have a 10.21.176.0/22<http://10.21.176.0/22> network, which contains about 1024 IPs. If I declare this as a big subnet, will I get performance problems for broadcast packets, DHCP assignment, bad ping latency and the like?

What is your subnet size? Is there a practical maximum subnet size?


--

YY Inc. is hiring openstack and python developers. Interested? Check http://www.nsbeta.info/jobs

--
Thanks,
Yuanle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140424/2629c373/attachment.html>