Adam Johnson @adjohnslideshare.com/adjohn

OpenStack Networking and Automation

Outline

2

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

What is OpenStack?

3

Evolution of Network Virtualization

4

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

OPENFLOWREACTIVE APPOACH

VLAN configured on physical switches

• Static• Manual• Complex• Tenant state

maintained in physical network

Manual End-to-End

VLAN APPROACH

4

5

Before Neutron: Nova NetworkingNova-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

Nova-network slightly evolvesIntroduced 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

Introducing Neutron

7

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

OVS Plugin Overview

OVS Open Source Plugin

9

Overlay NetworkingGRE TunnelsUses Open vSwitch Project

Components:• Neutron OVS Agent• Neutron DHCP Agent• Neutron L3 Agent• IPTables

OVS Open Source Plugin

10

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

Challenges with OVS Plugin

11

Neutron Network Node is a SPOFNeed to use corosync, etc for active/standby failover.

Challenging at ScaleSince there’s a single network node, this becomes a bottleneck fairly quickly.

Inefficient NetworkingIPTables, L3 Agent, multiple hops for single flow are causing unnecessary traffic and added latency on your physical network

12

ML2 Plugin Architecture

Modular Layer 2 (ML2)

13

Mix and Match Networking PluginsPreviously, plugins were monolithic

Driver ModelImplement network types and mechanismsMultiple mechanisms can be used simultaneously to access different ports across the network.

LimitationsNot everything is pluggable yet (started with just L2)

14

Example 3rd Party Plugin

15

v

Any Application

MidoNet Network Virtualization Platform

Logical L2

Any Network Hardware

Any Cloud Management Platform

LogicalFirewall

Logical Layer 4Load Balancer

Logical L3

LogicalNAT

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

21

Automating the Virtual Network

Heat Orchestration

22

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

{ "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

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

Create a “Stack” in CLI or Horizon

26

Automate the Physical Network

27

Cumulus Linux on White box Switches

Q&A

28

Thank YouAdam Johnson

@adjohnslideshare.com/adjohn

29