Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization Overlay

Cloud NetworkingOpenStack Day Korea

February 5th, 2015

Agenda

What is Driving Network Change

Cloud Network Requirements

Why Not Traditional Networking

Network Virtualization Overlays

Neutron?

MidoNet

1

Forces are Reshaping Networking…

Big Web Cloud Computing

Big Data

Customer Focus – $ / Node & Port

Azure

Mobile

2

IoT and Big

Data

Networking is Experiencing Rapid Change

Services and applications are moving to the Cloud; workloads are moving to a virtualization environment; DevOps networking adoption

Hardware is commoditized; many players delivering high-throughput switching at extremely low prices

Open Source and Service Orientation supports flexibility, innovation, vendor agnostic design, self-service, shorter

development times and faster time to market

Cloud

ComputingWhite-box

Hardware

IoT and Big Data impact networks requiring distributed datacenters and agility to enable

real-time event responses

Open

Source and

Service

Orientation

4

Cloud Networking Requirements

Network Virtualization Requirements

•Speed of Provisioning

•Scale

•Multi-tenancy

•Performance

•Elasticity

•Simplicity of Deployment

•Security

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

Tenant BVirtual Router

VM6

Virtual L2 Switch B1

Virtual L2 Switch A1


TenantB office

Tenant BVPN Router

Office Network

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

Isolated tenant

networks

(virtual data center)

Requirements for NV

8

Requirements

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

L3 Isolation

(similar to VPC and VRF)

Requirements for NV

9

Requirements

9

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

1010

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

11

Device-agnostic networking services:

• Load Balancing

• Firewalls

• Stateful NAT

• VPN

Networks and services must be fault

tolerant and scalable

Requirements for NV

12

Single pane of glass to manage it all.

Bonus Requirements for NV

13

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

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

Why Traditional Networking Doesn’t Work

•For example

•VLANs for L2 isolation

•VRFs for L3 isolation

•Not Designed For Speedy Provisioning

•Not Designed For Scale

•Consider virtual endpoints

•Not Designed For Multi-tenancy

•Services are not elastic

15

16

Network Virtualization Overlays

17

Encapsulation and Tunneling

Provides isolation

18

Stateless core. Stateful edge.

Clos Fabric

19From Cumulus Networks

20

Network processing at the edge

Decoupled from the physical network

21

Virtual network changes don’t affect

the physical network

22

Single virtual hop network services

avoid “traffic trombones”

23

Centralized state and control for

maximum agility

24

Scalable, fault tolerant gateways to

external networks

Using NV Overlays for Cloud Network

25

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, Docker

Decoupled from Physical Network

Network Virtualization Overlays Today

26

27

Can’t I just use Neutron?

Neutron

•Default Implementation Is Not Scalable

•L4 services (NAT) are still bottlenecks

•Using namespaces

•Agents have serious fault tolerance issues

•DHCP, MetaData, DNS

•Fundamentally hard to fix

28

29

MidoNet

30

MidoNet Network Virtualization Platform

Logical L2 Switching - L2 isolation and path optimization with distributed virtual switchingInterconnect with VLAN enabled network via L2 Gateway

Logical L3 Routing – L3 isolation and routing between virtual networksNo 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 tunnelingProvides 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 4Load Balancer

VxLAN/GRE

Any Hypervisor

Logical L2 Logical L3 NAT

MidoNet/

Neutron API

NAT – Provides Dynamic NAT, Port masquerading

MidoNet

31

Logical Topology

MidoNet Solution

15

Private IP Network

MN

MN

MN

Internet

BGP Multi

Homing

Physical Topology

MN VM

VM

MN VM

VM

MN VM

VM

BGP To ISP3

BGP To ISP2

BGP To ISP1

vPort

Provider Virtual Router

Tenant A

Virtual Router

Tenant B Virtual Router

Virtual

Switch A1

Virtual Switch A2

Virtual

Switch B1

vPort

vPort

vPort

vPort

vPort

Network State Database

MN MN MN

Tunnel

Architecture Overview

33

MidoNet Flow Processing

Flow Processing at the Edge

•Ingress Simulation

•State Propagation

•Tunneling

•Egress

34

35

Mid

oN

et

Gate

way

Yo

ur E

xis

ting

Infra

stru

ctu

re

Provider Router

TenantRouter

TenantNetwork

192.168.5.2 192.168.5.3

Subnet 192.168.5.0/24

Address: 192.168.5.1Allow incoming tcp/22

NAT 192.168.5.2 <-> 112.140.32.94

VM to VM Communication

Mid

oN

et

Gate

way

Yo

ur E

xis

ting

Infra

stru

ctu

re

Now MidoNet can create a VXLAN tunnel between the required nodes, and send the packet on its way

36

VXLAN Tunnel

37

Under the Hood

Distributed StateOn-demand

state

propagation

Virtual Networking at the Edge

Leverage ZK

RPC over TCP

Distributed State- VM sends first packet

- Kernel flow miss occurs; queues packet for

processing via Netlink

- MidoNet receives Netlink message for processing


user space

kernel space

Distributed State


user space

kernel space

MidoNet agent may query the

NSDB; then

- Locally processes packet

(virtual layer simulation)

- Installs local flow (drop/mod/fwd)


user space

kernel space

Possible actions on flow table entry match:

- Set src/dst MAC to routerMAC/dstMAC

- Modify TTL

- Encapsulation with GRE or VXLAN + IP.

Key or ID tells dest host the destination vPort.


Packet is delivered with overlay networking.

Destination host owns vport, identified by the

GRE key or VxLAN VNI.

Control Protocol Handling

•Agent traps ARP, DHCP, MetaData

•Locally Reply

•DNS coming soon

43

44

Bridge physical and virtual networks

more efficiently

MidoNet VTEP Gateway

45

MidoNet VTEP Gateway

46

47

Break through performance barriers

of software networking

40Gb VxLAN Offloading: virtualized environments require highthroughput 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

OpenStack Integration

5

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

MidoNet Plugin

Open Source

•MidoNet was Open Sourced in November 2014

•www.midonet.org

•www.github.com/midonet/

•OpenStack and Docker need a high quality Open Source NVO solution!

50

http://www.midonet.org

http://www.github.com/midonet/

51

What’s Next?

Network Operating System

•Linux is everywhere

•ONIE & Cumulus Linux

•We can run our software on it!

•Fabric Monitoring and Control

•Resource Monitoring

•Traffic Engineering

•ECMP enhancement

52

53

Get more out of the physical network.

Cannot ignore the physical network

54

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

55

Get more intelligence out of your network

Big Data

56

NOS centralizes information on

your network

We can start taking advantage of

this information

- Security

- Compliance

- Optimizing Networks

57

It’s Open Source

http://www.midonet.org

Check out our blog:http://blog.midonet.org

Follow us on Twitter:@midonet

http://blog.midokura.com/2014/06/midonet-advantage/

58

Thank You

59

Distributed Flow State

Distributed Flow-State

60

• MidoNet’s distributed architecture enables statefulnetwork functions at the edge

• Given the forward and return flows could have several ingress and egress nodes, “interested sets” get hints

• Advantages include:

• Lower latency to process flows

• Independence from a centralized transaction, like a database query


61

• For a new ingress flow, perform flow computation when flow state is created and store locally

• Prior to packet forwarding, the ingress node determines the interested set and then pushes the flow state


62

• Flow state is leveraged by flow computation and tunnel encapsulation

• Flow states are pushed between agents using Tunnel packets with special tunnel key values indicating “flow state”


63

• “Fire and forget” flow state propagation allows the “interested set” nodes to be informed without packet delay

• As ymmetrical data flow paths are easily handled given the flow state is propagated to the “interested set” of nodes

Stateful port groups

64

• Create port-group for the stateful ingress port group

midonet-cli> port-group create name SPG stateful true

• Add the ports to be load balanced e.g. all uplinks on Provider Router

midonet> port-group pgroup0 add member port router0:port0

midonet> port-group pgroup0 add member port router0:port1

Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization Overlay

Software

Transcript of Midokura OpenStack Day Korea Talk: MidoNet Open Source Network Virtualization Overlay