Designed for IT professionals looking to expand their OpenStack Networking knowledge, “Navigating OpenStack Networking” is a comprehensive and fast-paced session which provides an overview of OpenStack Networking, its history, its predecessor (Nova Networks), its components and then dives deep into the architecture, its features and plugin model and its role in building an OpenStack Cloud.

1. Navigating OpenStack Networking:
Nova-networks, Neutron & Services
Valentina Alaria - PLUMgrid

2. • OpenStack Community Member
• Work with OpenStack users deploying
OpenStack Clouds @scale
• OpenStack Networking education &
evangelization
• How to contact and follow me
v@plumgrid.com
@valealaria
About Me
2

3. OpenStack
• Controls large pools of compute, storage, and networking resources
• Managed through API & dashboard that give administrators control
and empower users to provision their own resources

4. Road to Cloud Networking
#1
DEPLOYMENT
ROADBLOCK
75
Open
Tickets
4
Months
Delay
#1
DEPLOYMENT
ENABLER
0
Open
Tickets
0
Weeks
Delay

5. 5
Production
Pilot
Proof of Concept
• Provable Isolation
• Performance & Scale
• High Availability
• Extensibility
• Hardened Code
• Operational Tools
Choose the Right Architecture

6. OpenStack
Networking:
The Journey

7. • Networking functionality embedded within Nova
(Compute)
• Development lessen after introduction of Neutron
• Still no clear migration path from nova-networks to
Neutron
Where it all started: Nova-networks

8. • VM interfaces are bridged - Ok for “full-trust” or single-tenant
• No multi-tenancy, L2 isolation, overlapping IP address spaces support
• L3 first-hop routing is either provided by physical networking devices (flat model) or
by OpenStack L3 Service (flat-DHCP model)
“flat” networking model (nova-networks)
8

9. • VLAN/tenant network to provide multi-tenancy, L2 isolation, overlapping IP Address
spaces support
• Configuration of VLAN via Neutron where available
• L3 first-hop routing is either provided by physical networking devices or by
OpenStack L3 Service
“VLAN-based” networking model
(nova-networks/Neutron)
9

10. • A staggering 24% of production deployments still use
nova-networks
• Looking for a clear migration path and simplification
From nova-networks to Neutron
10
http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up

11. • Started with the Folsom release
• Provide Network as a Service
• Provide Operator & Tenants ability to
create and offer rich network topologies
and configure advanced policies
• Offer a technology agnostic layer while
enabling vendor extensions
• Support for advanced services
Why Neutron?
Compute Storage
Network

12. • REST APIs to manage network connections for
resources managed by other OpenStack Services (e.g.
Nova)
• Technology Agnostic (framework based on “plug-ins”)
• Multi-tenancy: Isolation, Abstraction, full control over
virtual networks
• Modular Design: API specifies service, vendor provides
its implementation. Extensions for vendor-specific
features.
What is Neutron?
12

13. OpenStack Neutron Architecture Components
Neutron Server
Core APIs API Extensions
Plugins

14. Neutron Plugin Hierarchy
Core Service
Plugins
Monolithic ML2 LBaaS FWaaS

15. What Neutron is NOT
• Neutron does NOT implement the networks, but rather
is the front-end to the component that does create and
implement the rich network functionalities
– When integrated with an SDN solution, it will “pass through”
OpenStack Networking API calls to the SDN Controller. The SDN
solution will then “build the actual networks”.
– When integrated with OVS and a Network node solution*….
*this is what many people call “running Neutron” (inaccurately)

16. What can users do with Neutron?
Create multi-tenant
networks with private IP
space
Connect workloads to
each network
Interconnect networks
with routers
Provide external
connectivity (e.g.
Internet) to workloads

17. • Multi-tenancy achieved by “overlaying” MAC-in-IP ‘Tunnels’ onto the physical switch
fabric
• Encapsulation header convey tenant network ID for isolation and overlapping IP
Address
• Software layers to implement routing / switching operations within and across tenant
networks
“overlay-based” networking model (Neutron only)
17

18. How about
extensibility,
scale &
performance
?

19. Your data plane matters … A LOT
vSwitches
Distributed vSwitches
vRouters
Distributed topologies
Extensible data plane

20. Inside a Compute Node - Example
20
Compute Node
Kernel
Ethmgmt
vSwitch Kernel Module
Tenant VMs
VM VM VM
User
Vif
vSwitch
User Space
Component

21. Neutron Reference Implementation (1)
Neutron
Server
Queue
L3-Agent
(FW & NAT)
L3-Agent
(FW & NAT)L3-Agent
L2 Agent
DHCP Agent
DHCP Agent
Adv. Services
DB

22. Neutron Reference Implementation (2)
Neutron
ML2/OVS
plugin
VM
Network Nodes
VM VM
VM
VM VM VM
VM VM
VM VM VM
VM VM
VM
VMVM VM
Nova Glance Swift Cinde
r
L3 Agent
FWaaS
Agent
LBaaS
Agent
Agent
Agent
Agent
Agent
Agent
Agent
DHCP
Agent
Services
Neutron
Framework
Placement of these
components is critical;
They are in data path
and become bottlenecks
Advanced Services run
on dedicated nodes.
Limited HA.
Creation of new tenants
requires careful sizing of
components to maintain
performance level
VM traffic flow can be handled in
kernel, in local user space or in
network nodes with different
performance level

23. Agents-less Implementation (1)
Neutron
Server
Controller
DB Data Planes
Data Planes
Data Planes

24. Neutron
Plugin
VM
Tenant Networks
Distributed Data Plane
Controller
VM VM
VM
VM VM VM
VM VM
VM VM VM
VM VM
VM
VMVM VM
Nova Glance Swift Cinde
r
3rd party
Virtual Network Functions
Control Plane
No Traffic Bottlenecks
VM to VM optimized packet
flow due to distributed VNFs –
Eliminating bottlenecks
Scale out Performance
automatically scale out as more
servers are deployed
No Single Point of Failure
All VNF control planes are
fully redundant
Robust Control Plane
Controller Cluster is deployed
in management rack –
stronger security & optimal
performance
Agents-less Implementation (2)

25. How about
high
availability?

26. High Availability Model?
PHYSICAL
INFRASTRUCTURE
VIEW
VIRTUAL
INFRASTRUCTURE
VIEW
Overlay Network
TENANT
NETWORKS
• Reliable Hardware
• Redundant Components
• Non-stop services
• Rapid Failure Detection
• Rapid Convergence

27. Highly Available Networks for OpenStack
• Must Operate in Active/Active configuration
• Self Healing
• Scalable
SELF HEALING
NETWORK
CONTROLLER
• Data plane should continue to function in the event of a complete
control plane outage
• In Service Software Upgrade of new or existing Network Functions
NON-STOP
FORWARDING
• Gateways should be deployed in Active/Active mode
• No manual intervention should be required in the event of failure
ACTIVE/ACTIVE
VTEP GATEWAY
• Handled by CMS but Network layer needs to integrate seamlessly
• Network state should be recreated upon failure or migration event
• Rapid Detection and Convergence
CMS FAILURE
MODEL
INTEGRATION
1
2
3
4

28. High Availability Model
PHYSICAL
INFRASTRUCTURE
VIEW
VIRTUAL
INFRASTRUCTURE
VIEW
TENANT
NETWORKS
• Connectivity
• Rapid Failure Detection
• Rapid Convergence
• Reliable Controller
• Self Healing
• Non-stop Forwarding
• Rapid Failure Detection
• Rapid Convergence
Overlay Network

29. What next?

30. Building Confidence in OpenStack Networking
30
PLUMgrid Ignition
v@plumgrid.co
m

31. Q&A

32. Thank you!