- OpenStack provides network virtualization and automation capabilities through projects like Neutron, Heat, and plugins like Midonet. - Neutron evolved networking in OpenStack to allow pluggable networking models beyond the initial Nova networking. It supports overlay technologies and network automation. - Heat allows you to define infrastructure like servers, networks, and their relationships in templates that can be deployed through the OpenStack API. This provides automation of virtual network deployment. - Plugins like Midonet provide distributed virtual networking models to improve scalability and performance over overlay approaches like OVS. They also allow automation of physical network configuration.

1. Adam Johnson @adjohn
slideshare.com/adjohn
OpenStack Networking and Automation

2. Outline
1
• OpenStack Intro
• Network Virtualization Evolution
• OS Networking History
• OVS Overview
• ML2
• MidoNet Overview
• Automate Virtual Network with Heat
• Automate Physical Networks
• Q&A

3. What is OpenStack?
2

4. Evolution of Network Virtualization
3
Virtual Network
Overlays
Decoupling hardware
and software
• Cloud-ready agility
• Unlimited scalability
• Open, standards-based
• No impact to physical
network
PROACTIVE
SOFTWARE OVERLAY
INNOVATION IN NETWORKING AGILITY
Reactive End-to-End
Requires programming
of flows
• Limited scalability
• Hard to manage
• Impact to
performance
• Still requires tenant
state in physical
network
OPENFLOW
REACTIVE
APPOACH
VLAN configured
on physical switches
• Static
• Manual
• Complex
• Tenant state
maintained in
physical network
Manual End-to-End
VLAN
APPROACH
3

5. 4
Before Neutron: Nova Networking
Nova-Networking was the only networking option in OpenStack prior
to Quantum/Neutron
Still available today as an alternative to Neutron, but will likely be
phased out.
Options Available within nova-networking initially:
• Only Flat
• Flat DHCP
Limitations
• No flexibility with topologies (no 3-tier)
• Tenants can’t create/manage L3 Routers
• Scaling limitations (L2 domain)
• No 3rd party vendors supported
• Complex HA model

6. 5
Nova-network slightly evolves
Introduced VLAN DHCP mode
Improvements:
• L2 Isolation – each project gets a VLAN assigned to it
Limitations
• Need to pre-configure VLANs on physical network.
• Scaling Limitations - VLANs
• No L3
• No 3-tier topologies
• No 3rd party vendors

7. Introducing Neutron
6
OpenStack Networking as a first class Service
• Pluggable Architecture
• Standard API
• Many choices
Plugins Available
• OVS Plugin
• Linux Bridges
• Flat DHCP
• VLAN DHCP
• ML2
• MidoNet
• NSX
• PlumGRID
• Nuage
• Contrail
• Ryu
• …
• Supports Overlay Technology
• More Services (LBaaS, VPNaaS)
• Flexible network topologies

8. 7
OVS Plugin Overview

9. OVS Open Source Plugin
8
Overlay Networking
GRE Tunnels
Uses Open vSwitch Project
Components:
• Neutron OVS Agent
• Neutron DHCP Agent
• Neutron L3 Agent
• IPTables
Neutron Network Node
Neutron-Server + OVS Plugin
L3 Agent DHCP Agent OVS Agent
NAT /
Floating IPs
IP Tables /
Routing
dnsmasq
ovsdb/
vswitchd
Linux Kernel / IP Stack
Compute Node
nova compute
OVS Agent KVM
VM VM
Linux Kernel / IP Stack
ovsdb/
vswitchd
IP
Tables
Compute Node
nova compute
OVS Agent KVM
VM VM
Linux Kernel / IP Stack
ovsdb/
vswitchd
IP
Tables
GRE Tunnels
IP Underlay
WAN
security groups security groups

10. OVS Open Source Plugin
9
OVS Agent - receives tunnel/flow setup info from OVS Plugin, and programs
Open vSwitch to setup tunnels and send traffic through the tunnel
DHCP Agent - Sets up dnsmasq in a namespace per network/subnet and enters
mac/ip into dhcp lease file
L3 Agent – OVS Plugin orchestrates to set up IPTables, Routing, NAT tables
Neutron Network Node
Neutron-Server + OVS Plugin
L3 Agent DHCP Agent OVS Agent
NAT /
Floating IPs
IP Tables /
Routing
dnsmasq
ovsdb/
vswitchd
Linux Kernel / IP Stack
Compute Node
nova compute
OVS Agent KVM
VM VM
Linux Kernel / IP Stack
ovsdb/
vswitchd
IP
Tables
Compute Node
nova compute
OVS Agent KVM
VM VM
Linux Kernel / IP Stack
ovsdb/
vswitchd
IP
Tables
GRE Tunnels
IP Underlay
WAN
security groups security groups

11. Challenges with OVS Plugin
10
Neutron Network Node is a SPOF
Need to use corosync, etc for active/standby failover.
Challenging at Scale
Since there’s a single network node, this becomes a bottleneck fairly quickly.
Inefficient Networking
IPTables, L3 Agent, multiple hops for single flow are causing unnecessary
traffic and added latency on your physical network
Private IP Network
Neutron Server
Neutron Server centrally
responsible network services
like NAT, routing, Load
balancing
Linux Kernel
Open vSwitch
Agent
VM
IP Tables
VM VM

12. 11
ML2 Plugin Architecture

13. Modular Layer 2 (ML2)
12
Mix and Match Networking Plugins
Previously, plugins were monolithic
Driver Model
Implement network types and mechanisms
Multiple mechanisms can be used simultaneously to access different ports
across the network.
Limitations
Not everything is pluggable yet (started with just L2)

14. 13
Example 3rd Party Plugin

15. 14
v
Any Application
MidoNet Network Virtualization Platform
Logical L2
Any Network Hardware
Any Cloud Management Platform
Logical
Firewall
Logical Layer 4
Load Balancer
Logical L3
Logical
NAT
Any Hypervisor
Logical Switching – Layer 2 over Layer 3,
decoupled from the physical network
Logical Routing – Routing between virtual
networks without exiting the software
container
Logical Firewall – Distributed Firewall,
Kernel Integrated, High Performance
Logical Layer 4 Load Balancer –
Application Load Balancing in software
Logical Network Address Translation –
Powerful chains/rules for more control
MidoNet API – RESTful API for integration
into any Cloud Management Platform
MidoNet Network Virtualization Platform

16. Private IP Network
Network State Database
Internet
MidoNet Agents act as
distributed controller
MidoNet Distributed Model
Network State Database
Network State Database
Linux Kernel
MidoNet Agent
VMVM VM
Linux Kernel
MidoNet Agent
VMVM VM
Active Gateway
Active Gateway
Active Gateways
Distributed scale out
Gateways
Logical Network
topology stored in
distributed database
MidoNet Agent removes
need for Service Nodes and
IPTables

17. Private IP Network
Neutron Server
Neutron Server centrally
responsible network services
like NAT, routing, Load
balancing
Linux Kernel
Open vSwitch
Agent
VM
IP Tables
VM VM

18. Private IP Network
Network State Database
MidoNet Agent programs the
Kernel to provide services like
security groups, routing, load
balancing, and floating IPs
Linux Kernel
VMVM VM
MidoNet’s Distributed Edge Model
MidoNet
Agent

19. Private IP Network
SDN Controller
Active Gateway Standby Gateway
Internet
Linux Kernel
Open vSwitch
Agent
VM
IP Tables
All outgoing flows travel
through the active gateway
node.
VM VM
Linux Kernel
Open vSwitch
Agent
VM
IP Tables
VM VM
Active/Standby GW Model

20. Private IP Network
Active Gateway 1
Active Gateway 2
Internet
Linux Kernel
Open vSwitch
Agent
VM
IP Tables
Outgoing and Incoming flows
balanced across MidoNet
Distributed Gateways
VM VM
Linux Kernel
Open vSwitch
Agent
VM
IP Tables
VM VM
Active Gateway 3
Network State Database
Network State Database
Network State Database
Fully Distributed GW Model

21. 20
Automating the Virtual
Network

22. Heat Orchestration
21
Introduced in Grizzly, usable in Havana
What is it?
Allows you to pre-define a set of compute, network, storage requirements to
provide a specific service and deploy it with ease.
Compatible with CloudFormations
How it works:
• Template describes the infrastructure of a cloud app
• Can be version controlled, diffed
• Human Readable
• Can Describe
• Servers, FIPs, Volumes, Sec Groups, Users, Networks, etc
• Can Specify Relationships: volume connects to server
• Heat turns template into API calls
• Integrates easily with config management like Chef, Puppet, etc.

23. 22
{
"AWSTemplateFormatVersion" : "2010-09-09",
"Description" : "Sample Heat template that
spins up multiple instances and a private
network (JSON)",
"Resources" : {
"heat_network_01" : {
"Type" : "OS::Neutron::Net",
"Properties" : {
"name" : "heat-network-01"
}
},
"heat_subnet_01" : {
"Type" : "OS::Neutron::Subnet",
"Properties" : {
"name" : "heat-subnet-01",
"cidr" : "10.10.10.0/24",
"dns_nameservers" : ["172.16.1.11",
"172.16.1.6"],
"enable_dhcp" : "True",
"gateway_ip" : "10.10.10.254",
"network_id" : { "Ref" :
"heat_network_01" }
}
},
Example Snippet (Cloud Formation Template)
"heat_router_01" : {
"Type" : "OS::Neutron::Router",
"Properties" : {
"admin_state_up" : "True",
"name" : "heat-router-01"
}
},

24. 23
HOT (Heat Orchestration Template) Example
heat_template_version: 2013-05-23
description: Simple template to
deploy a single compute instance
resources:
my_instance:
type: OS::Nova::Server
properties:
key_name: my_key
image: F18-x86_64-cfntools
flavor: m1.small

25. 24
Create a “Stack” in CLI or Horizon

26. 25
Automate the Physical
Network

27. 26
Cumulus Linux on White box Switches

28. Q&A
27

29. Thank You
Adam Johnson
@adjohn
slideshare.com/adjohn
28