Open Stack

The operators that were asking for the spec were using private IP space and
that is probably going to be the most common use case for routed networks.
Splitting a /21 up across the entire data center isn't really something you
would want to do because you would run out of IPs quickly like you
mentioned.

The use case routed networks is almost exactly like your Romana project.
For example, you have a large chunk of IPs (e.g. 10.0.0.0/16) and you've
setup the infrastructure so each rack gets a /23 with the ToR as the
gateway which would buy you 509 VMs across 128 racks.



On May 22, 2017 2:53 PM, "Chris Marino" <chris at romana.io> wrote:

Thanks Jon, very helpful.

I think a more common use case for provider networks (in enterprise, AFAIK)
is that they'd have a small number of /20 or /21 networks (VLANs) that they
would trunk to all hosts. The /21s are part of the larger datacenter
network with segment firewalls and access to other datacenter resources (no
NAT). Each functional area would get their own network (i.e. QA, Prod, Dev,
Test, etc.) but users would have access to only certain networks.

For various reasons, they're moving to spine/leaf L3 networks and they want
to use the same provider network CIDRs with the new L3 network. While
technically this is covered by the use case described in the spec,
splitting a /21 into segments (i.e.one for each rack/ToRs) severely limits
the scheduler (since each rack only get a part of the whole /21).

This can be solved with route advertisement/distribution and/or IPAM
coordination w/Nova, but this isn't possible today. Which brings me back to
my earlier question, how useful are routed provider network?

CM
ᐧ

On Mon, May 22, 2017 at 1:08 PM, Jonathan Proulx <jon at csail.mit.edu> wrote:

>
> Not sure if this is what you're looking for but...
>
> For my private cloud in research environment we have a public provider
> network available to all projects.
>
> This is externally routed and has basically been in the same config
> since Folsom (currently we're upto Mitaka).  It provides public ipv4
> addresses. DHCP is done in neutron (of course) the lower portion of
> the allocated subnet is excluded from the dynamic range.  We allow
> users to register DNS names in this range (through pre-exisiting
> custom, external IPAM tools) and to specify the fixed ip address when
> launching VMs.
>
> This network typically has 1k VMs running. We've assigned a /18 to
> which is obviously overkill.
>
> A few projects also have provider networks plumbed in to bridge they
> legacy physical networks into OpenStack.  For these there's no dynamic
> range and users must specify fixed ip, these are generally considered
> "a bad idea" and were used to facilitate dumping VMs from old Xen
> infrastructures into OpenStack with minimal changes.
>
> These are old patterns I wouldn't necessarily suggest anyone
> replicate, but they are the truth of my world...
>
> -Jon
>
> On Mon, May 22, 2017 at 12:47:01PM -0700, Chris Marino wrote:
> :Hello operators, I will be talking about the new routed provider network
> :<https://docs.openstack.org/ocata/networking-guide/config-r
> outed-networks.html>
> :features in OpenStack at a Meetup
> :<https://www.meetup.com/openstack/events/239889735/>next week and would
> :like to get a better sense of how provider networks are currently being
> :used and if anyone has deployed routed provider networks?
> :
> :A typical L2 provider network is deployed as VLANs to every host. But
> :curious to know how how many hosts or VMs an operator would allow on this
> :network before you wanted to split into segments? Would you split hosts
> :between VLANs, or trunk the VLANs to all hosts? How do you handle
> :scheduling VMs across two provider networks?
> :
> :If you were to go with L3 provider networks, would it be L3 to the ToR, or
> :L3 to the host?
> :
> :Are the new routed provider network features useful in their current form?
> :
> :Any experience you can share would be very helpful.
> :CM
> :
> :
> :ᐧ
>
> :_______________________________________________
> :OpenStack-operators mailing list
> :OpenStack-operators at lists.openstack.org
> :http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> --
>


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170523/711b3b4f/attachment.html>