Advanced OpenStack Networking

Advanced
OpenStack
Networking
Moatasem ELMOGY
Content
Chapter.1 Introducing Software-Defined Networking
Chapter.2 OpenStack Component – Neutron
Orange Restricted
Content
SDN Introduction
OpenFlow Basics
Introducing Open vSwitch
Orange Restricted
Introducing Software-Defined Networking
SDN Introduction
Before Starting explaining Neutron, let’s have a quick look at SDN:
Orange Restricted
SDN Introduction
Controller
Control plane
• Distributed protocols used
• OSPF, STP, etc.
Control plane • Populates the data plane with forward entries
• Distributed protocols used
• OSPF, STP, etc.
• Populates the data plane with forward entries
Internal API OPENFLOW

Internal API
Data plane
• Hardware specific
• Bound by ASIC/TCAM limits in physical devices
Data plane
• Hardware specific
• Bound by ASIC/TCAM limits in physical devices
Orange Restricted
SDN Introduction
Network Virtualization is
an “SDN Application”
Orange Restricted
SDN Introduction
Orange Restricted
SDN Introduction
Network virtualization is:
• A fully isolated environment:
 Q: Could two tenants decide to use the same RFC 1918 private IP space?
• Physical network location independent:
 Q: Can two VMs be on the same L2 logical network, while in different physical L2 networks?
 Q: Can a VM migrate without disrupting its security policies, packet counters, or flow state?
• Physical network state independent:
 Q: Do physical devices need to be updated when a new network/workloads is provisioned?
 Q: If a physical device died and was replaced, would application be impacted?
• Network virtualization is NOT:
 Running network functionality in a VM (e.g., Router or Load-- ‐balancer VM)
Orange Restricted
Content
SDN Introduction
OpenFlow Basics
Orange Restricted
OpenFlow Basics
Rule Action Stats
Packet + byte counters
1. Forward packet to zero or more ports

2. Encapsulate and forward to controller
3. Send to normal processing pipeline
4. Modify Fields
5. Any extensions you add!
Switch VLAN VLAN MAC MAC Eth IP Src IP Dst IP ToS IP Prot L4 L4
Port ID PCP src dst type s-port d-port
10
Orange Restricted
OpenFlow Basics
11
Orange Restricted
OpenFlow Basics
12
Orange Restricted
Content
SDN Introduction
OpenFlow Basics
13
Orange Restricted
Introducing OVS - What is Virtual Switch?
Hypervisor
Virtual Network
vNIC L2
VM VM VM
VIF
Virtual Switch
NIC as vSwitch’s uplink port
Physical Switch
Data Flow
14
Orange Restricted
Introducing OVS - Why Open vSwitch?
• Full L2-L4 matching capability

• Just a L2 device • ACL's, Qos, Bonding
• No complexity • OpenFlow Controller
• Simple forwarding • Distributed vSwitches
• Mobility of state
• Responding to network dynamics
15
Orange Restricted
Introducing OVS
16
Orange Restricted
Introducing OVS – The Main Components
ovsdb-tool
Management
ovs-dpctl ovs-ofctl ovs-vsctl
ovs-vswitchd ovsdb-server user
OVS Kernal Module Kernel
17
Orange Restricted
Introducing OVS – The Main Components
ovs-ofctl ovsdb-tool
Management
ovs-dpctl ovs-vsctl
OpenFlow
DB operation
upcall
Save changes
reinject ovs-vswitchd Apply changes ovsdb-server user
netlink
OVS Kernal Module Kernel
Flow Table
From NetDevice To NetDevice

18
Orange Restricted
Introducing OVS – Forwarding Flow
ovs-vswitchd
user
Kernel
From Net Device OVS Kernal Module BRIDGE Kernal
Module
First Packet
subsequent Packets
19
Orange Restricted
Texte avec illustration
Demo Time
20
Orange Restricted
Content
Networking before Neutron
Why Neutron?
Neutron Basics
Position of Neutron in OpenStack
Neutron Architecture
Neutron Architecture – with OVS
Neutron Architecture – with OVN
Traffic Flow
DVR
21
Orange Restricted
OpenStack Component – Neutron
Nova-Networking
22
Orange Restricted
Content
Why Neutron?
Neutron Basics
Traffic Flow
DVR
23
Orange Restricted
Why Neutron?
Networking was sub-component of Nova, so why having an extra component?
Two Key problems:
Limited Technology No tenant control
You can have any color as long as it is black!

VLANs are Great!
Henry Ford about the Model T
Stone Age Man
24
Orange Restricted
What is Neutron?
• Provides REST APIs to manage network connections for the resources managed
by other OpenStack Services (e.g. Nova)
• Technology Agnostic: (framework based on “plug-ins”) to allow a variety of
backend providers
• Multi-tenancy: Isolation, Abstraction, full control over virtual networks
• Modular Design: API specifies service, vendor provides its implementation.
Extensions for vendor-specific features.
• Exposes vendor-specific network virtualization and SDN technologies
• Standalone Service : It is not exclusive to OpenStack. Neutron is an
autonomous service
25
Orange Restricted
Content
Why Neutron?
Neutron Basics
Traffic Flow
DVR
26
Orange Restricted
Neutron Basics
Neutron Basics (by analogy to Nova)
Nova Neutron
*-as-a-service Compute Network
Core API abstractions Virtual Servers: Virtual Networks: a basic

represents a host with L2 segement.
CPU, memory, disk and Virtual ports: attachment
NICs point for devise connecting
to virtual networks
Support different back-end virt-drivers for KVM, Plugins for ML2, OVS,
technologies XenServer, Hyper-v, Ryu, cisco UCS, Linux
VMWare ESX bridge, Nicira NVP …
API extensibility for new or Keypairs, instance rescue, QoS, port statistics,
back-end specific features volumes, etc. security groups, etc.
27
Orange Restricted
Neutron Basics
Network connectivity as a service
Neutron management object Logical network control for tenants

Tenant view VS administrator view
With the development of Neutron project, a variety of L2 to L4 network services, such as LBaaS, VPNaaS,
FWaaS, have been extended based on basic services.
28
Orange Restricted
Content
Why Neutron?
Neutron Basics
Traffic Flow
DVR
29
Orange Restricted
30
Orange Restricted
Content
Why Neutron?
Neutron Basics
Neutron Architecture – Plugin concept
Traffic Flow
DVR
31
Orange Restricted
Neutron Architecture - Plugin Concept
REST API
Neutron-server
Neutron Agents
Neutron Plugin Message Queue
RPC RPC
SQL SQL
Database
32
Orange Restricted
REST API
Neutron Agents
Neutron-server DHCP agent

Neutron Core Neutron API
API extensions
L3-Agent
Message Queue
Core Plugin Service Plugin RPC RPC
L2-Agent
Adv service
Agent
SQL
SQL
Database
33
Orange Restricted
• Maps abstraction to implementation on the Network (Overlay

e.g. NSX or physical Network)
• Makes all decisions about *how* a network is to be
Neutron Plugin implemented
• Can provide additional features through API extensions.
Core Plugin Service Plugin • Extensions can either be generic (e.g. L3 Router / NAT), or
Vendor Specific
• Implements • Implements
Neutron Core API Neutron API
 IPAM extensions
 DB Access  Layer 3 (Router)
 Layer 2 (Switch)  Firewall
 Load Balancer
 VPN
34
Orange Restricted
Modular Plugins
Mechanism
Drivers
Drivers
Type
35
Orange Restricted
Content
Why Neutron?
Neutron Basics
Traffic Flow
DVR
36
Orange Restricted
REST API
Neutron Agents
Neutron-server DHCP agent

Neutron Core
API L3-Agent
Message Queue
ML2
RPC RPC OVS-Agent
Plugin/OVS
Adv service
Agent
SQL
SQL
Database
37
Orange Restricted
Neutron-OVS-plugin-Agent Neutron-OVS-plugin-Agent
Neutron-L3-Agent
Neutron-
Neutron-DHCP-Agent server
ML2 plugin
Neutron-*-Agent
Network node controller node

Compute node
38
Orange Restricted
39
Orange Restricted
40
Orange Restricted
41
Orange Restricted
Neutron Architecture – OVS – Security Group Design
• Required linux bridge and veth pair per VM

• Uses iptables
42
Orange Restricted
Demo Time
43
Orange Restricted
Content
Why Neutron?
Neutron Basics
Traffic Flow
DVR
44
Orange Restricted
Introduction to OVN. What and why?
What is OVN? Why OVN is different?
• Opensource Virtual Networking for OVS. • Will not require any additional agents for functionality
• Provides L2/L3 virtual Networking • for simplified deployment and debugging.
• Security groups using new in-kernel conntrack integration.
• Logical Switches and Routers. • More secure and faster than other methods.
• Security groups • OVN eliminates the need for Linux bridges, dnsmasq
instances, and namespaces.
• L2/L3/L4 ACLs • OVN has around 71% to 79.8% higher performance than OVS
• Multiple tunnel overlays (Geneve, STT and VxLAN)
• Work on same platforms as OVS
• Linux (KVM and XEN).
• Containers
• Speaks OVSDB to configure OVN via its Northbound
database. Results for Nova VM Creation time with OVN:
45
Orange Restricted
ovn-northd
OVN-controller
OVN-controller
OVN-controller
Neutron plugin OVSDB OVSDB
ovsdb-server OVN-controller
ML2
OVN-controller
Plugin/OVN
RPC
Message Queue neutron-*aaS
RPC
46
Orange Restricted
OVN ML2 Plugin
OVSDB
OVN Northbound DB
OVSDB
OVN-northd
OVSDB
OVN Southbound DB
OVSDB OVSDB
OVN-controller OVN-controller
openflow OVSDB
openflow OVSDB
OVS- ovsdb- OVS- ovsdb-

vswitchd server vswitchd server
47
Hypervisor 1 Hypervisor n
Orange Restricted
Neutron Architecture – OVN – Databases
OVN northbound DB OVN southbound DB
receives information about the logical network the center of the entire system.
configuration from the Neutron plug-in.
The database contains three types of data:

translates the logical network configuration into • Physical Network
logical data path flows and stores them in the • Logical Network
OVN Southbound Database. • Binding
It has two clients, the Neutron plug-in and It has two clients, ovn-northd and the ovn-
ovn-northd controller services
48
Orange Restricted
Neutron Architecture – OVN
49
Orange Restricted
Neutron Architecture – OVN – Security Group Design
• Uses kernel conntrack module directly from OVS

• Design benefits
• No complicated pipeline
• Faster-Fewer hops and veth ports
50
Orange Restricted
Neutron Architecture – OVN – DHCP and DNS Design
DHCP
• OVN implements DHCPv4 support, which removes the need for a DHCP agent.
• Virtual networks no longer require a DHCP namespace or a dnsmasq process.
• DHCPv4 options are configured on each compute node running ovn-controller. This means
that DHCP support is fully distributed.
• DHCP requests from the instances are also handled by ovn-controller.
• The database creates a new entry when a subnet is created. The ovn-northd service adds
the logical flows for each logical port where DHCP options are defined.
DNS
•Native implementation. Since the version 2.8 OVN contains a built-in DNS implementation
51
Orange Restricted
Neutron Architecture – OVN – L2 and L3 Desgin
Layer 3 (Routing)
• Native support for IPv4 and IPv6
• Distributed
• Flow caching improves performance
• Without OVN: multiple per-packet routing layers
• With OVN: cache sets dest mac, decrements TTL
• No L3 agent
Layer-2 (switching)
• Native implementation. Replaces the conventional Open vSwitch (OVS) agent.
52
Orange Restricted
Demo Time
53
Orange Restricted
Content
Why Neutron?
Neutron Basics
Traffic Flow
DVR
54
Orange Restricted
Neutron Architecture – OVS – Traffic Flow
Case 1: North-south for instances
55
Orange Restricted
Case 2: East-west for instances on

different networks
56
Orange Restricted
Case 3: East-west for instances on the

same network
57
Orange Restricted
Neutron Architecture – OVN – Logical Flows
58
Orange Restricted
Content
Why Neutron?
Neutron Basics
Traffic Flow
DVR
59
Orange Restricted
DVR
Legacy Routing in With DVR

Neutron
60
Orange Restricted
DVR-Traffic Flow
61
Orange Restricted
Reference
• https://docs.openstack.org
• Networking Guide Red Hat OpenStack Platform 16.0 | Red Hat Customer Portal
• https://www.openvswitch.org/
• OpenStack Networking by Yves Fauser
• Inside the Architecture of Neutron by Mark McClain
• OpenStack Neutron & Software Defined Networks (SDN) by Iñaki Pascual
• Intro to OpenStack Quantum by Dan Wendlandt
• Neutron L2 and L3 agents by Carl Baldwin, Rossella Sblendido
62
Orange Restricted
Thanks
Moatasem ELMOGY

Advanced OpenStack Networking

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced OpenStack Networking

Uploaded by

Copyright:

Available Formats

Advanced

Internal API OPENFLOW

Rule Action Stats

Packet + byte counters

1. Forward packet to zero or more ports

NIC as vSwitch’s uplink port

• Full L2-L4 matching capability

ovs-vswitchd ovsdb-server user

OVS Kernal Module Kernel

OVS Kernal Module Kernel

From NetDevice To NetDevice

Networking was sub-component of Nova, so why having an extra component?

Two Key problems:

Limited Technology No tenant control

You can have any color as long as it is black!

Neutron Basics (by analogy to Nova)

*-as-a-service Compute Network

Core API abstractions Virtual Servers: Virtual Networks: a basic

Network connectivity as a service

Neutron management object Logical network control for tenants

Neutron-server DHCP agent

• Maps abstraction to implementation on the Network (Overlay

Neutron-server DHCP agent

Network node controller node

• Required linux bridge and veth pair per VM

What is OVN? Why OVN is different?

OVS- ovsdb- OVS- ovsdb-

OVN northbound DB OVN southbound DB

The database contains three types of data:

• Uses kernel conntrack module directly from OVS

Case 1: North-south for instances

Case 2: East-west for instances on

Case 3: East-west for instances on the

Legacy Routing in With DVR

You might also like