Open Stack

I think the best general way to view networking in cloud is WAN vs Cloud
Lan.

There's almost always an edge routing env for your cloud environments (
whether they be by region or by policy or by tim is an angry dude and you
don't touch his instances ).

Everything beyond that edge is a WAN problem and can be handled in fairly
traditional ways... of course that's over simplifying things like BGP
passing into your cloud's lan env.  Or multihoming the edge router for that
cloud env to multiple networks ( god help you if there is spanning tree
involved ).

Honestly, I'd still use that demarcation though.  It helps split the issue
into manageable chunks.

-Matt

On Mon, Oct 3, 2016 at 11:59 AM, Chris Marino <chris at romana.io> wrote:

> This can also be done with IPv4 address as well. Not quite the flexibility
> that comes with v6, but workable for all but the very largest environments.
>
> This is the approach that is embodied in the Romana (http://romana.io/) project
> (I am part of this effort).
>
> If you run all your OpenStack VMs on a 10/8 provider network, you can
> carve up the address space for projects, subnets, etc. You can NAT to your
> existing network, or push host routes to the VMs that need access (a
> feature that has not yet been implemented).
>
> CM
> ᐧ
>
> On Mon, Oct 3, 2016 at 8:20 AM, Jonathan Proulx <jon at csail.mit.edu> wrote:
>
>> On Sat, Oct 01, 2016 at 11:47:56AM -0600, Curtis wrote:
>> :On Fri, Sep 30, 2016 at 8:15 AM, Jonathan Proulx <jon at csail.mit.edu>
>> wrote:
>> :>
>> :> Starting to think refactoring my SDN world (currently just neutron
>> :> ml2/ovs inside OpenStack) in preparation for maybe finally lighting up
>> :> that second Region I've been threatening for the past year...
>> :>
>> :> Networking is always the hardest design challeng.  Has anyone seen my
>> :> unicorn?  I dream of something the first works with neutron of course
>> :> but also can extend the same network features to hardware out side
>> :> openstack and into random public cloud infrastructures through VM
>> and/or
>> :> containerised gateways.  Also I don't want to hire a whole networking
>> :> team to run it.
>> :>
>> :> I'm fairly certain this is still fantasy though I've heard various
>> :> vendors promise the earth and stars but I'd love to hear if anyone is
>> :> actually getting close to this in production systems and if so what
>> :> your experience has been like.
>> :>
>> :
>> :Do you want to have tenants be able to connect their openstack
>> :networks to another public clouds network using some kind of API? If
>> :so, what are your tenant networks? vlans? vxlan?
>>
>> Yes, I do  want to have tenants be able to connect their openstack
>> networks to another public clouds network using some kind of API.
>>
>> Since this is under consideration as part of a new region I haven't
>> implemented anything yet (current region is GRE but willing to cut
>> that off as 'legacy' epecially as we're trying to wind down the DC it
>> lives in).  So at this point all possibilites are on the table.
>>
>> My main question is "is anyone actually doing this" with a follow up
>> of "if so how?"
>>
>> Thanks,
>> -Jon
>>
>> :Thanks,
>> :Curtis.
>> :
>> :> -Jon
>> :>
>> :> --
>> :>
>> :> _______________________________________________
>> :> OpenStack-operators mailing list
>> :> OpenStack-operators at lists.openstack.org
>> :> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
>> k-operators
>> :
>> :
>> :
>> :--
>> :Blog: serverascode.com
>>
>> --
>>
>> _______________________________________________
>> 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/20161003/359b0f75/attachment.html>