Deployments of OpenStack in private cloud environments poses a set of requirements in the network architecture that are often completely different from those of a public cloud. Even though multi-tenancy is still a key requirement, in private clouds interconnecting between cloud applications at scale needs to be achieved in several different ways. This presentation outlines several requirements on what enterprises expect from an overlay network solution, and on what type of applications they like to run on top of an OpenStack deployment. It also describes how the interaction with an existing IP address management solution is done, and how a policy based engine could help to provide the agility enterprises are expecting from a Enterprise cloud deployment. Other relevant links: * youtube: https://www.youtube.com/watch?v=yPpsTJdIsfo * https://openstacksummitnovember2014paris.sched.org/event/204695473dd59a61eae2b4623669aede

1. Copyright 2013 Alcatel-Lucent. All rights reserved.
CONFIDENTIAL - SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW
PROPRIETARY – USE PURSUANT TO COMPANY INSTRUCTION
Nuage Networks
Jonas Vermeulen EMEA Product Management Nuage Networks
Nuage Networks
Neutron Networking in Private Clouds

2. Similarities with Public Cloud Environment
The owner
Optimizes for low cost (servers, hv, automation,…)
Measures usage and charges
The user
Requires APIs, portals, agility
Wants to be isolated  “VPC”
Is constantly comparing offers on the market: internal vs external
Enterprises like the flexibility + cost structure
But need it private – Information Protection, Control, Compliancy,…

3. Private Cloud – Technically the same ?
Users/Owners also have advanced technical requirements
Per-Tenant Scale
Lots and lots of applications communicating with each other
# subnets being factor higher
Managing Security groups
Supporting “legacy” applications
Integrate with existing Environment
Preserve roles of existing departments
How else to convince business units to use this new cloud??

4. Case 1 – Per-Tenant Scale
The default internet model for Isolated Applications = Amazon VPC
Mostly web apps
Own address space
Floating IP to go outside, with Security Groups as first level of protection
Implementation in OpenStack
Front End
Business logic
Front End
Business logic
Front End
Business logic
Internet
Tenant x
Tenant y
Tenant z
Network Node

5. Case 1 – Per-Tenant Scale
Enterprise Applications
Lots of them, with lots of Interaction
Applications have connections to a “management” network and to the “internet”/”intranet”
Enterprise network desires
Fully isolate lifecycle phases – dev/QA/…
Isolate individual applications to users
Use unique (IPv4) addressing
Have up to 10.000+ VMs / 1000+ subnets behind a distributed router
Management
Internet/Intranet
Dev
QA
Prod

6. Case 1 – Per-Tenant Scale
Solution A: Applications isolated with tenants + External networks (FIP) for inter-app
(-) Meaning of a Floating IP in a private context?
(-) Floating IPs are routed through the Network
IceHouse / Juno (L3 Fabric) – via NN
(-) Multiple Floating IP subnets
Solution B: Applications isolated with tenants + Shared networks
Routing across shared networks in a separate customized tenant router
(-) Shared Networks visible/accessible to all tenants
(-) Scale across 10.000+ VMs / 1000+ subnets
Business logic
Business logic
Ext Router
Network Node
Shared
Tenant x
Tenant y

7. Case 1 – Per-Tenant Scale
With Nuage Networks: Applications isolated with tenants
Networks are mapped to tenants of choice
Routing in distributed fashion within a lifecycle domain
Exit points via dynamic or static routing
Business logic
Business logic
Distr. RouterForDev
Mapping
Shared
Public
Tenant x
Tenant y

8. Case 1 – Per-Tenant Scale
Enterprise requirements for enforcing Security
1.vPort Oriented – AWS Equivalent (eg. Windows <-> AD ; Web <-> App)
Possible Today: using Security Groups
Scale of 10K x 10K VMs
vPort x vPort = vPort2 x (Calculations + Messages + …)
2.Tenant/Network/Subnet Oriented (Project 1 <-> Project 2, Subnet 1 <-> Subnet 2)
Enterprises are looking for more advanced solutions

9. Case 2 – Supporting legacy applications
Apps running only on VMWare
Multicast applications
Voice / Storage applications
QoS : Trust / Override
Rate-Limits
Local breakout to proxy
Sending /Receiving L3 Multicast (eg Video)
Combining fabric + overlay
Hypervisor
Hypervisor
Hypervisor
SrvGroup1 - ESXi
Hypervisor
Hypervisor
Hypervisor
DC1
SrvGroup2 - KVM

10. Case 3 – Integration in existing environments
Enterprises rely heavily on Existing DHCP / DNS installations
IP@ Allocation by IPAM, DHCP relay in fabric
Immediate DNS registration
DHCP
IP Fabric
DNS

11. IP Fabric
Case 3 – Integration in existing environments
OpenStack
Neutron
HV
VM
Tenant1
Br-int
VM
NIC
Tenant2
VM
Br-tun
Neutron DHCP Agent (Tenant 2)
Current
DHCP / DNS with OpenStack
IP@ Allocation by Neutron
DHCP -> dnsmasq at network node
DNS -> OpenStack Designate ?
Enterprises rely heavily on Existing DHCP / DNS installations
IP@ Allocation by IPAM, DHCP relay in fabric
Immediate DNS registration

12. IP Fabric
Case 3 – Integration in existing environments
OpenStack
DHCP
Neutron
HV
VM
Tenant1
Br-int
VM
NIC
DNS
Tenant2
VM
Br-tun
Neutron
DHCP Agent
(Tenant 2)
Current
DHCP / DNS with OpenStack
IP@ Allocation by Neutron
DHCP -> dnsmasq at network node
DNS -> OpenStack Designate ?
Enterprises rely heavily on Existing DHCP / DNS installations
IP@ Allocation by IPAM, DHCP relay in fabric
Immediate DNS registration

13. IP Fabric
Case 3 – Integration in existing environments
OpenStack
DHCP
Neutron
HV
VM
Tenant1
Br-int
VM
NIC
DNS
Tenant2
VM
Br-tun
Neutron
L3 Agent
(Tenant 2)
3. DHCP Relay
1.Subnet Sync
2.IP@ Alloc
DHCP Relay
DHCP / DNS with OpenStack
IP@ Allocation by Neutron
DHCP -> dnsmasq at network node
DNS -> OpenStack Designate ?
Enterprises rely heavily on Existing DHCP / DNS installations
IP@ Allocation by IPAM
DHCP/DNS by IPAM, with relay in fabric

14. IP Fabric
Case 3 – Integration in existing environments
OpenStack
DHCP
Neutron
HV
VM
Tenant1
Br-int
VM
DHCP Relay
NIC
DNS
Tenant2
VM
Br-tun
Neutron L3 Agent (Tenant 2)
3. DHCP Relay
1.Subnet Sync
2.IP@ Alloc
DHCP / DNS with OpenStack
IP@ Allocation by Neutron
DHCP -> dnsmasq at network node
DNS -> OpenStack Designate ?
Enterprises rely heavily on Existing DHCP / DNS installations
IP@ Allocation by IPAM
DHCP/DNS by IPAM, with relay in fabric

15. Case 4 – Roles of existing departments
Cloud = “Fast, Fast, Fast…” (BMW OpenStack Summit – 2/11)
However…
Enterprise change process prevents agility, speed
Separation of responsibilities across operational teams
Apps – deploying on provided infrastructure
Network – Allocating subnet ranges
Security – Users + ACLs
Compute – Infrastructure
…
Apps
Security
Compute
Network
Go for evolution or revolution ?

16. Case 4 – Roles of existing departments
Today in OpenStack:
Create member roles in keystone
Edit /etc/<project>/policy.json to restrict actions
Assign members to roles
Remains a chain of activities = status-quo

17. Case 4 – Roles of existing departments
Today in OpenStack:
Create member roles in keystone
Edit /etc/<project>/policy.json to restrict actions
Assign members to roles
What has been done in Nuage :
Templated design
Includes/excludes subnet allocations
Includes/excludes ACL/QoS policies
Pre-approved , Design-once/Deploy-multiple times
 Permission model to match organization structure
Remains a chain of activities = status-quo

18. THANK YOU Let’s work together to address Advanced Private Cloud needs !