OpenStack Day in Korea 2015 -Track 3-6 Archiectural Overview of the Open Source Dan Mihai Dumitriu - Midokura

1. From Nova Network to Neutron and Beyond:
A Look at OpenStack Networking
OpenStack Day Korea
February 5th, 2015

2. Agenda
 Network Virtualization Requirements
 OpenStack and the Evolution of
Neutron Networking
 Midokura Use Cases and Futures for
NV
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 Virtualization Platform
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
 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

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
 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

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
 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

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 method 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
Austin 21 October 2010 Nova, Swift
Bexar 3 February 2011 Nova, Glance, Swift
Cactus 15 April 2011 Nova, Glance, Swift
Diablo 22 September 2011 Nova, Glance, Swift
Essex 5 April 2012 Nova, Glance, Swift, Horizon,
Keystone
Folsom 27 September 2012 Nova, Glance, Swift, Horizon,
Keystone, Quantum, Cinder
Grizzly 4 April 2013 Nova, Glance, Swift, Horizon,
Keystone, Quantum, Cinder
Havana 17 October 2013 Nova, Glance, Swift, Horizon,
Keystone, Neutron, Cinder
Icehouse April 2014 Nova, Glance, Swift, Horizon,
Keystone, Neutron, Cinder

41. Latest Neutron Features
40
Havana Release Brought:
• LBaaS: shipped an updated API and HAProxy driver support
• VPNaaS: VPN API supports IPSec and L3 agent ships with an
OpenSwan driver
• FWaaS: enables tenant to configure security at the edge via the
firewall API and on the VIF via the security group API
• New plug-in Modular Layer 2 (ML2): 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. Upcoming Neutron Features
41
Expectations for Juno:
• Provide Distributed Virtual Routing (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,
• 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. 42
MidoNet Overview

44. 43
MidoNet Network Virtualization Platform
Logical L2 Switching - L2 isolation and path optimization with distributed
virtual switching
Interconnect with VLAN enabled network via L2 Gateway
Logical L3 Routing – L3 isolation and routing between virtual networks
No need to exit the software 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 application load balancing in
software form - no need for hardware based firewalls
VxLAN/GRE – Provides VxLAN and GRE tunneling
Provides L2 connectivity across L3 transport. This is useful when L2 fabric
doesn’t reach all the way from the racks hosting the VMs to the physical L2
segment of interest.
MidoNet/Neutron API– Alignment with OpenStack Neutron’s API for
integration into compatible cloud management software
v
Any Application
MidoNet Network Virtualization Platform
Any Network Hardware
OpenStack/Cloud Management System
Distributed
Firewall
Layer 4
Load Balancer
VxLAN/GRE
Any Hypervisor
Logical L2 Logical L3 NAT
MidoNe
t/
Neutron
API
NAT – Provides Dynamic NAT, Port masquerading

45. OpenStack Integration
5
Easy integration with OpenStack:
MidoNet provides a plugin for Neutron.
MidoNet Plugin

46. Architecture Overview

47. Do it BiggerDo it Faster
Value
Agility
Provide rapid
provisioning of isolated
network infrastructure for
labs and devops.
Logical Network
Provisioning
Automated
Provisioning
Isolated
Sandboxes
Control
Network admins can
better secure, control &
view network traffic.
Single Pane of
Glass OpsTools
Enhanced
Security
Enable
Compliance
Do it Better
IaaS
Cloud
Build multi-tenant
clouds with visibility
into usage.
Tenant
Control
Metering
Automated
Self Service
Performance
Improve network
performance using edge
overlay & complementary
technologies.
Single Hop Virtual
Networking
VXLAN Hardware
Gateway
Massive
performance
with 40Gb
Support
Scale
Add virtual network infra
& services simply &
resiliently without
hardware & bottlenecks.
Distributed
Logical
Networking
FW, LB, L2/3, NAT
Limitless “VLANs”
Scale out L3
Gateway
Bridge legacy
VLANs
IPv6
Solution for
OpenStack
Networking
Use MN to overcome
limitations of Neutron for
OpenStack users.
Replaces OVS
Plugin
Use Cases

48. 47
So what’s next for
Network Virtualization?

49. 48
Get more out of the physical
network.

50. 49
Network Virtualization
decouples the logical
network from the
physical network.

51. NVOs can’t ignore the physical network
50
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
- Traffic Engineering

52. 51
Get more intelligence out of your network

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

54. 53
Bridge physical and virtual
networks more efficiently

55. Midokura VTEP Solution
54
MidoNet MidoNet
Virtual
Any Cloud Management Platform
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

56. 55
Break through performance barriers
of software networking

57. 40Gb VxLAN Offloading: virtualized environments require high
throughput infrastructure
• Integration with Mellanox provides 40 Gbps
saturation
• VxLAN offloading improves CPU utilization 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 software
Performance

58. 57
Q&A

59. 58
MidoNet Advantages
Check out our blog:
http://blog.midokura.com/
http://blog.midonet.org
Follow us on Twitter:
@midokura
@midonet

60. Thank You
59