A look at the project’s progression from Nova-Network to Neutron and Beyond. We will recall the early stages of Nova-Networking and how the functionality evolved to what is Neutron networking today. We will discuss previous default Neutron plugin implementation issues and current solutions with the now open-source SDN solution, MidoNet.

1. So
What’s
the
Deal
with
Neutron?
OpenStack
MeetUp
January
2015

2. Agenda
▪ Network
VirtualizaEon
Requirements
▪ EvoluEon
of
Neutron
Networking
▪ Open
Source
Network
SoluEons
▪ Quiz!
1

3. 2
Network Virtualization
Requirements

4. What is Network Virtualization (NV)?
3
Taking logical (virtual) networks
and services, and decoupling
them from the underlying network
hardware.
Well suited for highly virtualized
environments.
Any Application
Virtual Networks
MidoNet
VirtualizaEon
PlaOorm
Logical
L2
Existing Network Hardware
Any Cloud Management Platform
Distributed
Firewall
service
Distributed
Load
Balancer
ser
Logical
L3
Distributed
VPN
Service
KVM, ESXi, Xen LXC

5. Requirements for NV
4
Requirements
4
Tenant/Project A
Network A1
VM1 VM3
Network A2
VM5
Tenant/Project B
Network B1
VM2 VM4
uplink
Provider Virtual
Router (L3)
Tenant A
Virtual Router
Tenant B
Virtual Router
VM6
Virtual L2
Switch B1
Virtual L2
Switch A1
Virtual L2
Switch A2
TenantB office
Tenant B
VPN Router
Office
Network

6. Requirements for NV
5
Requirements
5
Tenant/Project A
Network A1
VM1 VM3
Network A2
VM5
Tenant/Project B
Network B1
VM2 VM4
uplink
Provider Virtual
Router (L3)
Tenant A
Virtual Router
Tenant B
Virtual Router
VM6
Virtual L2
Switch B1
Virtual L2
Switch A1
Virtual L2
Switch A2
TenantB office
Tenant B
VPN Router
Office
Network
Isolated tenant
networks
(virtual data center)

7. Requirements for NV
6
Requirements
6
Tenant/Project A
Network A1
VM1 VM3
Network A2
VM5
Tenant/Project B
Network B1
VM2 VM4
uplink
Provider Virtual
Router (L3)
Tenant A
Virtual Router
Tenant B
Virtual Router
VM6
Virtual L2
Switch B1
Virtual L2
Switch A1
Virtual L2
Switch A2
TenantB office
Tenant B
VPN Router
Office
Network
L3 Isolation
(similar to VPC and VRF)

8. Requirements for NV
7
Requirements
7
Tenant/Project A
Network A1
VM1 VM3
Network A2
VM5
Tenant/Project B
Network B1
VM2 VM4
uplink
Provider Virtual
Router (L3)
Tenant A
Virtual Router
Tenant B
Virtual Router
VM6
Virtual L2
Switch B1
Virtual L2
Switch A1
Virtual L2
Switch A2
TenantB office
Tenant B
VPN Router
Office
Network
Fault-tolerant devices and links
Redundant, optimized, and
fault tolerant paths to to/
from external networks
(e.g. via eBGP)

9. Requirements for NV
8
8
Tenant/Project A
Network A1
VM1 VM3
Network A2
VM5
Tenant/Project B
Network B1
VM2 VM4
uplink
Provider Virtual
Router (L3)
Tenant A
Virtual Router
Tenant B
Virtual Router
VM6
Virtual L2
Switch B1
Virtual L2
Switch A1
Virtual L2
Switch A2
TenantB office
Tenant B
VPN Router
Office
Network
Fault-tolerant devices and links
Fault tolerant
devices and links

10. Requirements for NV
9
Device-agnostic networking services:
• Load Balancing
• Firewalls
• Stateful NAT
• VPN
Networks and services must be fault
tolerant and scalable

11. Requirements for NV
10
Single pane of glass to manage it all.

12. Bonus Requirements for NV
11
Integration with cloud or
virtualization management
systems.
Optimize network by exploiting
management configuration.
Single virtual hop for networking
services
Fully distributed control plane
(ARP, DHCP, ICMP)

13. Checklist for Network Virtualization
12
q Multi-tenancy
q Scalable, fault-tolerant devices
(or device-agnostic network
services).
q L2 isolation
q L3 routing isolation
• VPC
• Like VRF (virtual routing
and fwd-ing)
q Scalable gateways
q Scalable control plane
• ARP, DHCP, ICMP
q Floating/Elastic Ips
q Stateful NAT
• Port masquerading
• DNAT
q ACLs
q Stateful (L4) Firewalls
• Security Groups
q Load Balancing with health checks
q Single Pane of Glass (API, CLI, GUI)
q Integration with management platforms
• OpenStack, CloudStack
• vSphere, RHEV, System Center
q Decoupled from Physical Network

14. Evolution of Network Virtualization
13
INNOVATION
IN
NETWORKING
AGILITY
VLAN configured
on physical switches
• Static
• Manual
• Complex
• Tenant state
maintained in
physical network
Manual End-to-End
VLAN
APPROACH
13

15. Using VLANs for NV
14
q Multi-tenancy
q Scalable, fault-tolerant devices
(or device-agnostic network
services).
ü L2 isolation
q L3 routing isolation
• VPC
• Like VRF (virtual routing
and fwd-ing)
q Scalable gateways
q Scalable control plane
• ARP, DHCP, ICMP
q Floating/Elastic IPs
q Stateful NAT
• Port masquerading
• DNAT
q ACLs
q Stateful (L4) Firewalls
• Security Groups
q Load Balancing with health checks
q Single Pane of Glass (API, CLI, GUI)
q Integration with management platforms
• OpenStack, CloudStack
• vSphere, RHEV, System Center
q Decoupled from Physical Network

16. Evolution of Network Virtualization
15
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
15

17. What is OpenFlow?
16
A communication protocol that gives access to the forwarding
plane of a network switch over the network.

18. What is OpenFlow?
17
A centralized remote controller
decides the path of packets
through the switches

19. Using OpenFlow for NV
18
ü Multi-tenancy
q Scalable, fault-tolerant devices
(or device-agnostic network
services).
ü L2 isolation
△ L3 routing isolation
• VPC
• Like VRF (virtual routing
and fwd-ing)
q Scalable gateways
q Scalable control plane
• ARP, DHCP, ICMP
q Floating/Elastic IPs
q Stateful NAT
• Port masquerading
• DNAT
q ACLs
q Stateful (L4) Firewalls
• Security Groups
q Load Balancing with health checks
△ Single Pane of Glass (API, CLI, GUI)
△ Integration with management platforms
• OpenStack, CloudStack
• vSphere, RHEV, System Center
q Decoupled from Physical Network

20. Evolution of Network Virtualization
19
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
19

21. 20
How do overlays achieve
real network
virtualization?

22. 21
Encapsulation and Tunneling
Provides isolation

23. 22
Stateless core. Stateful edge.

24. 23
Network processing at the edge
Decoupled from the physical network

25. 24
Virtual network changes don’t affect
the physical network

26. 25
Single virtual hop network services
avoid “traffic trombones”

27. 26
Centralized state and control for
maximum agility

28. 27
Scalable, fault tolerant gateways to
external networks

29. Using Overlays for NV
28
ü Multi-tenancy
ü Scalable, fault-tolerant devices
(or device-agnostic network
services).
ü L2 isolation
ü L3 routing isolation
• VPC
• Like VRF (virtual routing
and fwd-ing)
ü Scalable Gateways
ü Scalable control plane
• ARP, DHCP, ICMP
ü Floating/Elastic IPs
ü Stateful NAT
• Port masquerading
• DNAT
ü ACLs
ü Stateful (L4) Firewalls
• Security Groups
ü Load Balancing with health checks
ü Single Pane of Glass (API, CLI, GUI)
ü Integration with management platforms
• OpenStack, CloudStack
• vSphere, RHEV, System Center
ü Decoupled from Physical Network

30. 29
Sounds great, but when
will it be a reality?

31. Network Virtualization Overlays Today
30

32. OpenStack
31

33. What
is
OpenStack?
32

34. OpenStack
Releases
33
Release schedule: time-based scheme with major release ~ every 6 months
Codenames are alphabetical:
• Austin: The first design summit took place in Austin, TX
• Bexar: The second design summit took place in San Antonio, TX (Bexar county).
• Cactus: Cactus is a city in Texas
• Diablo: Diablo is a city in the bay area near Santa Clara, CA
• Essex: Essex is a city near Boston, MA
• Folsom: Folsom is a city near San Francisco, CA
• Grizzly: Grizzly is an element of the state flag of California (design summit takes
place in San Diego, CA)
• Havana: Havana is an unincorporated community in Oregon
• Icehouse: Ice House is a street in Hong Kong
• Juno: Juno is a locality in Georgia
• Kilo: Paris (Sèvres, actually, but that's close enough) is home to the Kilogram,
the only remaining SI unit tied to an artifact

35. 34
Before
Neutron:
Nova
Networking
• Nova-Networking was the only option in OpenStack prior to Quantum/Neutron
• Original project from A release
• No IPv6 in first release but eventually introduced
• Still available today as an alternative to Neutron, but will 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

36. 35
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

37. 36
Nova-­‐network
slightly
evolves
C & D Releases had two general categories:
• Flat Networking
• VLAN Networking
Limitations
• Need to pre-configure VLANs on physical network
• Scaling Limitations - VLANs
• No L3
• No 3-tier topologies
• No 3rd party vendors

38. Quantum
37
OpenStack Networking branches out of the Nova project
• Tech Preview of Quantum appeared in D release
• Brought ability to have a multi-tiered network, with isolated network
segments for various applications or customers
• Quantum-server allowed for Python daemon to expose the OpenStack
Networking API and passes requests to 3rd party plugins
• Officially released in Folsom Release

39. Introducing Neutron
38
• Pluggable Architecture
• Standard API
• Many choices
Plugins Available
• MidoNet
• OVS Plugin
• Linux Bridges
• Flat DHCP
• VLAN DHCP
• ML2
• More Services (LBaaS, VPNaaS)
• Flexible network topologies
• NSX
• Plumgrid
• Nuage
• Contrail
• Ryu
• Name Change from Quantum to Neutron was announced in April 2013
• Legal Agreement to phase out code name “Quantum” due to
trademark of Quantum Corporation
OpenStack Networking as a First Class Service

40. Evolution of Neutron
39
Release
Name
Release
Date
Included
Components
AusEn
21
October
2010
Nova,
Swi]
Bexar
3
February
2011
Nova,
Glance,
Swi]
Cactus
15
April
2011
Nova,
Glance,
Swi]
Diablo
22
September
2011
Nova,
Glance,
Swi]
Essex
5
April
2012
Nova,
Glance,
Swi],
Horizon,
Keystone
Folsom
27
September
2012
Nova,
Glance,
Swi],
Horizon,
Keystone,
Quantum,
Cinder
Grizzly
4
April
2013
Nova,
Glance,
Swi],
Horizon,
Keystone,
Quantum,
Cinder
Havana
17
October
2013
Nova,
Glance,
Swi],
Horizon,
Keystone,
Neutron,
Cinder
Icehouse
April
2014
Nova,
Glance,
Swi],
Horizon,
Keystone,
Neutron,
Cinder
Juno
October
2014
Nova,
Glance,
Swi],
Horizon,
Keystone,
Neutron,
Cinder,
Heat,
Trove,
Sahara

41. Latest
Neutron
Features
40
Havana Release Brought:
• LBaaS: shipped an updated API and HAProxy driver support
• VPNaaS: supports IPSec and L3 agent ships with an OpenSwan driver
• FWaaS: enables tenant to configure security at the edge and on VIFs
• New ML2 plugin: supports local, flat, VLAN, GRE and VXLAN network
types via a type drivers and different mechanism drivers
Icehouse Release:
• New vendor plugins, LBaaS drivers and VPNaaS drivers
• OVS plugin and Linux Bridge plugin are deprecated: The ML2 plugin
combines OVS and Linux Bridge support into one plugin
• Neutron team has extended support for legacy Quantum configuration
file options for one more release

42. Latest
Neutron
Features
41
Juno Features:
• DVR functionality: Define API to create and deploy DVRs to improve the
performance
• Group-based Policy Abstractions for Neutron: API extensions for easier
consumption of the networking resources by separate organizations and
management systems
• IPv6 advancements:
• Add RADVD to namespace to handle RAs
• SLAAC
• Stateful and stateless DHCP for IPv6
• LBaaS new API driver and object model improvement for complex cases
• Quotas extension support in MidoNet plugin
• Incubator system:
• Instead of only using the summit for developing new features,
features can be developed and gestate over time

43. Upcoming
Neutron
Features
42
Expectations for Kilo:
• Neutron Core and Vendor Code decompositions
• Remove bottlenecks from contribution process
• Allows vendors to develop and control their own code at their own pace
• Allows different levels of engagement in Neutron community
• Promotes lightweight plugins and drivers with external libraries for
backend implementations
• Allow Floating IP to be specified
• Agent child process status
• ARP spoof filtering using ebtables
• Conntrack Zones support
• DHCP Service LoadBalancing Support and Options for IPv4 and IPv6
• New Iptables driver to improve performance of IptablesManager and reduce
complexity of IptablesFirewall and IptablesManager relations
• LBaaS Layer 7 Rules and TLS Specification
• MTU Selection and advertisement

44. 43
OVS Plugin Overview

45. 44
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
OVS
Open
Source
Plugin

46. 45
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
Challenges
with
OVS
Plugin

47. 46
MidoNet Overview

48. 47
MidoNet
Network
VirtualizaEon
PlaOorm
Logical
L2
Switching
-­‐
L2
isolaEon
and
path
opEmizaEon
with
distributed
virtual
switching
Interconnect
with
VLAN
enabled
network
via
L2
Gateway
Logical
L3
RouEng
–
L3
isolaEon
and
rouEng
between
virtual
networks
No
need
to
exit
the
so]ware
container
-­‐
no
hardware
required
Distributed
Firewall
–
Provides
ACLs,
high
performance
kernel
integrated
firewall
via
a
flexible
rule
chain
system
Logical
Layer
4
Load
Balancer
–
Provides
applicaEon
load
balancing
in
so]ware
form
-­‐
no
need
for
hardware
based
firewalls
VxLAN/GRE
–
Provides
VxLAN
and
GRE
tunneling
Provides
L2
connecEvity
across
L3
transport.
This
is
useful
when
L2
fabric
doesn’t
reach
all
the
way
from
the
racks
hosEng
the
VMs
to
the
physical
L2
segment
of
interest.
MidoNet/Neutron
API–
Alignment
with
OpenStack
Neutron’s
API
for
integraEon
into
compaEble
cloud
management
so]ware
v
Any Application
MidoNet
Network
VirtualizaEon
PlaOorm
Any Network Hardware
OpenStack/Cloud Management System
Distributed
Firewall
Layer
4
Load
Balancer
VxLAN/GRE
Any Hypervisor
Logical
L2
Logical
L3
NAT
MidoNet
/
Neutron
API
NAT
–
Provides
Dynamic
NAT,
Port
masquerading

49. OpenStack
IntegraEon
5
Easy
integraEon
with
OpenStack:
MidoNet
provides
a
plugin
for
Neutron.
Neutron MidoNet Plugin

50. Architecture
Overview

51. 50
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
Challenges
with
OVS
Plugin

52. 51
MidoNet
Distributed
Model

53. 52
Centralized
Controller
Model

54. 53
MidoNet
Distributed
Model

55. 54
AcEve/Standby
GW
Model

56. 55
Fully
Distributed
GW
Model

57. 56
So what’s next for
Network Virtualization?

58. 57
Get more out of the physical network.

59. 58
Network Virtualization
decouples the logical
network from the physical
network.

60. NVOs can’t ignore the physical network
59
Dynamic changes to logical
network are not dependent on the
physical network configuration.
Sharing state to and from the
physical network can be
supplementary.
- Monitoring
- Coordination
- Traffic Engineering

61. 60
Get more intelligence out of your network

62. NVOs provide a wealth of information
61
NVOs centralize information on
your network
We can start taking advantage of
this information
- Security
- Compliance
- Optimizing Networks

63. 62
Bridge physical and virtual networks
more efficiently

64. Midokura VTEP Solution
63
MidoNet MidoNet
Virtual
Any
Cloud
Management
PlaLorm
MidoNet
Network
State
Database
VM VM VM VM VM VM
IP Fabric
Server
Storage
Services
Physical
VM VM
VTEP
OVSDBc
VxLAN Tunnel
Physical Connection
OVSDB
TCP/IP
Key
OVSDBs

65. 64
Break through performance barriers
of software networking

66. 40Gb
VxLAN
Offloading:
virtualized
environments
require
high
throughput
infrastructure
• IntegraEon
with
Mellanox
provides
40
Gbps
saturaEon
• VxLAN
offloading
improves
CPU
uElizaEon
levels
• Scale
with
performance
through
HW
interconnect
• Increase
throughput
with
offloading
where
no
offloading
would
otherwise
have
flat
results
• High
bandwidth
can
now
be
achieved
in
so]ware
Performance

67. Open
Source
So]ware
66

68. MidoNet Unleashed
• Apache 2 Licensed
• Build a truly open and
neutral community of users
and vendors
• Heavily focused on
providing a networking
solution that functions well
for production environments
• Available since OpenStack
Paris at midonet.org
67

69. Who are the members?

70. How can you contribute to MidoNet?
69
• Check out the website:
www.midonet.org
• Join the MidoNet community! Wiki, Jenkins, Gerrit,
Ask, IRC, ML, Github
• Packages are available; easy to install with MidoStack
• Sign Legal to Contribute
• Midokurians on hand to support community

71. 70
MidoNet
Advantages
Check
out
our
blog:
hjp://blog.midokura.com/
Follow
us
on
Twijer:
@midokura
@midonet

72. Thank You
Midokura Enterprise
MidoNet
www.midokura.com
Follow us on Twitter:
@midokura
@midonet
@_techcet_
MidoNet
www.midonet.org