what's the deal with neutron?

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

Agenda

▪  Network VirtualizaEon Requirements

▪  EvoluEon of Neutron Networking

▪  Open Source Network SoluEons

▪  Quiz!

1

2

Network Virtualization Requirements

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

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 AVirtual Router

Tenant BVirtual Router

VM6

Virtual L2 Switch B1

Virtual L2 Switch A1


TenantB office

Tenant BVPN Router

Office Network

Requirements for NV

5

Requirements

5

Tenant/Project A

Network A1

VM1 VM3

Network A2

VM5

Tenant/Project B

Network B1

VM2 VM4

uplink




VM6




TenantB office

Tenant BVPN Router

Office Network

Isolated tenant networks

(virtual data center)

Requirements for NV

6

Requirements

6

Tenant/Project A

Network A1

VM1 VM3

Network A2

VM5

Tenant/Project B

Network B1

VM2 VM4

uplink




VM6




TenantB office

Tenant BVPN Router

Office Network

L3 Isolation (similar to VPC and VRF)

Requirements for NV

7

Requirements

7

Tenant/Project A

Network A1

VM1 VM3

Network A2

VM5

Tenant/Project B

Network B1

VM2 VM4

uplink




VM6




TenantB office

Tenant BVPN Router

Office Network

Fault-tolerant devices and links

Redundant, optimized, and fault tolerant paths to to/from external networks (e.g. via eBGP)

Requirements for NV

8 8

Tenant/Project A

Network A1

VM1 VM3

Network A2

VM5

Tenant/Project B

Network B1

VM2 VM4

uplink




VM6




TenantB office

Tenant BVPN Router

Office Network

Fault-tolerant devices and links

Fault tolerant devices and links

Requirements for NV

9

Device-agnostic networking services: •  Load Balancing •  Firewalls •  Stateful NAT •  VPN

Networks and services must be fault tolerant and scalable

Requirements for NV

10

Single pane of glass to manage it all.

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)

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

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

Using VLANs for NV

14

q  Multi-tenancy q  Scalable, fault-tolerant devices


ü  L2 isolation q  L3 routing isolation



•  ARP, DHCP, ICMP q  Floating/Elastic IPs



•  Security Groups q  Load Balancing with health checks q  Single Pane of Glass (API, CLI, GUI) q  Integration with management platforms




15


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




Manual End-to-End

VLAN APPROACH

15

What is OpenFlow?

16

A communication protocol that gives access to the forwarding plane of a network switch over the network.

What is OpenFlow?

17

A centralized remote controller decides the path of packets through the switches

Using OpenFlow for NV

18

ü  Multi-tenancy q  Scalable, fault-tolerant devices


ü  L2 isolation △  L3 routing isolation



•  ARP, DHCP, ICMP q  Floating/Elastic IPs



•  Security Groups q  Load Balancing with health checks △  Single Pane of Glass (API, CLI, GUI) △  Integration with management platforms




19

Virtual Network Overlays

Decoupling hardware and software •  Cloud-ready agility •  Unlimited scalability •  Open, standards-based •  No impact to physical

network

PROACTIVE SOFTWARE OVERLAY


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




Manual End-to-End

VLAN APPROACH

19

20

How do overlays achieve real network

virtualization?

21

Encapsulation and Tunneling Provides isolation

22

Stateless core. Stateful edge.

23

Network processing at the edge

Decoupled from the physical network

24

Virtual network changes don’t affect the physical network

25

Single virtual hop network services avoid “traffic trombones”

26

Centralized state and control for maximum agility

27

Scalable, fault tolerant gateways to external networks

Using Overlays for NV

28

ü  Multi-tenancy ü  Scalable, fault-tolerant devices


ü  L2 isolation ü  L3 routing isolation


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


ü  Decoupled from Physical Network

29

Sounds great, but when will it be a reality?

Network Virtualization Overlays Today

30

OpenStack

31

What is OpenStack?

32

OpenStack Releases

33

Release schedule: time-based scheme with major release ~ every 6 monthsCodenames 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

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

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

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

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

Introducing Neutron

38

•  Pluggable Architecture •  Standard API •  Many choices

Plugins Available •  MidoNet•  OVS Plugin •  Linux Bridges •  Flat DHCP •  VLAN DHCP•  ML2

•  Supports Overlay Technology

•  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

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

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

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

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

43

OVS Plugin Overview

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

45

Neutron Network Node is a SPOFNeed 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

46

MidoNet Overview

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

OpenStack IntegraEon

5

Easy integraEon with OpenStack: MidoNet provides a plugin for Neutron.

Neutron MidoNet Plugin

Architecture Overview

50

Neutron Network Node is a SPOFNeed 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

51

MidoNet Distributed Model

52

Centralized Controller Model

53

MidoNet Distributed Model

54

AcEve/Standby GW Model

55

Fully Distributed GW Model

56

So what’s next for Network Virtualization?

57

Get more out of the physical network.

58

Network Virtualization decouples the logical

network from the physical network.

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

60

Get more intelligence out of your network

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

62

Bridge physical and virtual networks more efficiently

Midokura VTEP Solution

63

MidoNet MidoNet

Virtu

al

Any Cloud Management PlaLorm

MidoNet Network State Database

VM VM VM VM VM VM

IP Fabric

Server Storage Services P

hysi

cal

VM VM

VTEP

OVSDBc

VxLAN Tunnel

Physical Connection

OVSDB

TCP/IP

Key

OVSDBs

64

Break through performance barriers of software networking

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

Open Source So]ware

66

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

Who are the members?

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

70

MidoNet Advantages

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

Thank You

Midokura Enterprise MidoNet www.midokura.com Follow us on Twitter: @midokura @midonet @_techcet_

MidoNet www.midonet.org

what's the deal with neutron?

Technology

scalable requirements

links requirements

network virtualization

vrf requirements

ebgp requirements

bonus requirements

logical virtual networks

q multitenancy q scalable