Overview and of OpenStack Quantum with the OpenVSwitch plugin.

1. Network Virtualization with
OpenStack Quantum
Miguel Lavalle
miguel@mlavalle.com
Openstack Quantum Hacker

2. Outline
• Quantum in the OpenStack landscape
• Why Quantum?
• API Overview and the Main Abstraction
• Plugin Architecture
• Demo
• Physical realization: the provider API extension
• Openvswitch plug-in internals
• Setting up a development environment
(DevStack) for Quantum

3. OpenStack overview
OpenStack
Network API
OpenStack
Network API
quantum-
server REST
QQ
uu l3-agent
ee
uu
ee
plugin-agent
Quantu
m
databa
se dhcp-agent
OpenStack
Identity API

4. Why Quantum?

5. Problem #1: No Tenant Control
To move enterprise apps to the cloud,
tenants want to “copy and paste” their
existing data center network topologies:
– Ability to create “multi-tier” networks (e.g.,
web tier, app tier, db tier)
– Control over IP addressing.
– Ability to insert and configure your own
services (e.g., firewall, IPS)
– VPN/Bridge to remote physical hosting or
customer premises (“cloudbursting”).
“You can have any color
as long as its black.“
- Henry Ford about the
Model-T

6. Why Quantum? Reason #1
On-demand Enterprise-Class Networking
• Tenants can:
– Create multiple private L2 networks
– Control IP addressing (bring your own!).
– Monitor basic network status.
– Connect to an upstream router for
external access
• Quantum API extensions provide:
– Advanced control + visibility: Security Build rich
policies, Quality-of-Service, Monitoring + networks,
Troubleshooting. customized to
tenant needs.
– Advanced Network Services: routers,
Firewalls, VPN, IDS, etc.

7. Problem #2: Technology Limitations
• Cloud puts new stresses on networks:
– High-density multi-tenancy, massive scale
●
But VLAN's limit scale
– On demand provisioning
●
But traditional network solutions have interfaces
designed for manual configuration
– Need to place / move workloads where capacity is
●
But network state is tied to a particular location
– Integrate with legacy hosting environments / remote
data centers.
– VM mobility Who needs
– On-demand service insertion private
networks?
• Nova was limited to basic VLAN model + Linux
IPtables.
Trunking all
VLANs is a
great idea!
- Stone Age Man

8. Problem #2: Technology Limitations
• Cloud puts new stresses on networks:
– High-density multi-tenancy, massive scale
●
But VLAN's limit scale
– On demand provisioning
●
But traditional network solutions have interfaces
designed for manual configuration
– Need to place / move workloads where capacity is
●
But network state is tied to a particular location
– Integrate with legacy hosting environments / remote
data centers.
– VM mobility Who needs
– On-demand service insertion private
networks?
• Nova was limited to basic VLAN model + Linux
IPtables.
Trunking all
VLANs is a
great idea!
- Stone Age Man

9. Why Quantum?
#2: Leveraging Advanced Technologies
• New networking technologies are emerging
to try and tackle these challenges.
– Overlay tunneling: VXLAN, NVGRE, STT
– Software-defined Networking (SDN) / OpenFlow
– VPN-based solutions (e.g., E-VPN).
– L2 Fabric solutions: FabricPath, Qfabric, etc.
– [ insert other solution here ]
• Quantum provides a “plugin” mechanism to
enable different technologies (more later). Use advanced
technologies
to reach new
• Choice is a good thing! heights.

10. Quantum Architecture
Generic OpenStack Operator Selected
APIs Backends
Compute API XenServer
Network API Nicira NVP
Tenant
Tools Storage API EMC
(GUI, CLI,
API code)
An eco-system of A generic tenant A “plugin”
tools that API to create and architecture with
leverage the configure “virtual different back-end
Quantum API. networks” “engines”

11. Basic API Abstractions
VM1 VM2 virtual server
Nova 10.0.0.2 10.0.0.3
virtual interface
(VIF)
virtual port
L2 virtual network
Net1
Quantum 10.0.0.0/24
Virtual subnet
“virtual networks” and virtual subnets are fundamentally multi-
tenant, just like virtual servers (e.g., overlapping IP's can be used on
different networks)

12. Quantum Model: Dynamic Network
Creation + Association
TenantA-VM1 TenantA-VM2 TenantA-VM3
10.0.0.3 10.0.0.4 9.0.0.3 9.0.0.4
Router Tenant-A Net1 Tenant-A Net2
10.0.0.0/24 9.0.0.0/24
External Net • Tenant can use API to create many networks.
172.31.0.0/24 • When booting a VM, define which network(s)
it should connect to.
• Can even plug-in instances that provide
more advanced network functionality (e.g.,
routing + NAT).

13. Tenant view vs. physical view
VM VM VM
A1 A2 B1 B2
Net A
Net B
10.0.0.0/24
9.0.0.0/24
Tenant view
Physical view Physical server 1 Physical server 2
VM VM VM
A1 B2 A2 B1
Hypervisor Hypervisor

14. Quantum API Extensions
● Enables innovation in virtual networking
– Tenants can query API to programatically discover supported extensions
– Over time, extensions implemented by many plug-ins can become
“core”
● Add properties on top of existing network/port
abstractions:
– QoS/SLA guarantees / limits
– Security filter policies
– Port statistics / netflow
● New services
– L3 forwarding, ACL's + NAT (“elastic” or “floating” IP's)
– LBaaS

15. Quantum abstraction
summary

16. Network classification
internal
Only fixed Private internal networks Shared internal networks
Ips are
allocated
from there.
external
we can create
floating ips and Private external networks shared external networks
router gateway
on it, They
should be able
to access public
network
Other tenants
Only owner
private tenant can shared besides the
owner tenant
create ports on can create
it. ports on it.

17. Quantum Architecture
Generic OpenStack Operator Selected
APIs Backends
Compute API XenServer
Network API Nicira NVP
Tenant
Tools Storage API EMC
(GUI, CLI,
API code)
An eco-system of A generic tenant A “plugin”
tools that API to create and architecture with
leverage the configure “virtual different back-end
Quantum API. networks” “engines”

18. Quantum Architecture (generic)
API Clients Quantum Backend X
Service
Quantum Physical
API Network
Tenant
Scripts Create-net
.
Horizon
GUI
. Plug-in
. X
Orchestration Create-port Virtual switch
Code
Nova Compute
API
Extensions
Interfaces from Nova
plug into a switch
Uniform API
managed by the
for all
Quantum plug-in.
clients

19. Quantum status Folsom
● First “core” release (October 2012)
– V2 API, with L2 + IP address management
(IPAM)
– Tenant API with Keystone and Horizon
integration
– Updated CLI
– Extensions:
● L3 “routers” with floating IP's
● Provider networks
● Bindings API

20. Demo “physical” set-up
● kvm vm running DevStack
● 2 CPU's
● 6GB of memory
● Network interfaces
– eth0 NAT for DevStack
– eth1 management network 172.16.0.0/16
– eth3 external network 172.31.0.0/24

21. Demo: already set-up
Router Tenant demo
net private
10.0.0.0/24

22. Demo logical set-up
● quantum net-create --tenant_id <tenant-
id> private
● quantum subnet-create --tenant_id
<tenant-id> --ip_version 4 --gateway
10.0.0.1 <net-id> 10.0.0.0/24
● quantum router-create --tenant_id
<tenant-id> router1
● quantum router-interface-add <router-id>
<subnet-id>

23. Demo: already set-up
Router Tenant demo
net private
10.0.0.0/24
External net
172.31.0.0/24

24. Demo logical set-up (cont.)
● quantum net-create nova --
--router:external=True
● quantum subnet-create --ip_version 4
<net-id> 172.31.0.0/24 --
--enable_dhcp=False
● quantum router-gateway-set <router-
id> <ext-net-id>

25. Demo: the end result
TenantA-VM1 TenantA-VM2 TenantA-VM3
10.0.0.3 10.0.0.4 9.0.0.3 9.0.0.4
172.31.0.3
Router Tenant demo Tenant demo
net private net private2
10.0.0.0/24 9.0.0.0/24
External net
172.31.0.0/24

26. Demo commands
● source devstack/openrc
● quantum net-create private2
● quantum subnet-create --ip_version 4
--gateway 9.0.0.1 <net-id> 9.0.0.0/24
● nova boot --image <image-id>
--flavor 1 --nic net-id=<net-id-1>
vm1

27. Demo commands (cont.)
● nova boot --image <image-id> --flavor 1 --nic
net-id=<net-id-1> --nic net-id=<net-id-2> vm2
● nova boot --image <image-id> --flavor 1 --nic
net-id=<net-id-2> vm3
● nova list
● nova get-vnc-console <vm2> novnc
● (In VM2) sudo ifconfig eth1 9.0.0.3 netmask
255.255.255.0 up
● quantum port-list -- --device_id <vm2>

28. Demo commands (cont.)
● quantum floatingip-create nova
● quantum floatingip-associate <fip-id>
<port-id>
● quantum floatingip-show <fip-id>

29. Quantum components
■Quantum server
Implement Quantum API and its
l3-agent extensions
Enforce network model
Quantum • Network, subnet, and port
IP addressing to each port
server & plugin
Plugin
■Plugin agent
agent Run on each compute node
Connect instances to network port
■DHCP agent
In multi-host mode, run on each
DHCP compute node (deferred)
agent Start/stop dhcp server
DB Maintain dhcp configuration
Queue
L3-agent
To implement floating IPs and other L3
features, such as NAT
One per external network
Quantum can share DB service
■Queue
and Queue with other Enhance communication between each
OpenStack stack services components of quantum
■DB – persistent network model

30. Physical realization
network
Physical network Virtual network
Identified by name Model in quantum
Network binding
Tenant network provider network
VLAN
Flat
● GRE and local bindings
have no physical network GRE
● Local bindings are for
DevStack single box local
● Linux bridge plug-in has no
GRE support

31. Provider API Extension
● The provider networking extension allows
administrators to explicitly manage the
relationship between virtual networks and
underlying physical mechanisms
● With this extension, users with admin
privileges see additional provider
attributes on all virtual networks and are
able to specify these attributes
● As of Folsom, supported by the
openvswitch and linuxbridge plugins

32. Provider API Extension: key
terms
● Virtual network: a Quantum L2 segment
● Physical network: a network connecting virtualization hosts and other
network resources
● Tenant network: a virtual network created by/for a tenant. The Tenant is
not aware of how that network is physically realized
● Provider network: a virtual network administratively created to map to a
specific physical network
● VLAN network: a virtual network realized as packets on a physical network
containing 802.1Q headers with a specific VID field value
● Flat network: a virtual network realized as packets on a specific physical
network with no 802.1Q headers
● GRE tunnel: a virtual network realized as packets encapsulated in a GRE
tunnel. The GRE tunnel packets are routed by the compute node hosts, so
GRE tunnels are not associated with a specific physical network

33. Tenant networks realized
with VLAN's (openvswitch)
● Quantum server in controller
(/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini)
– tenant_network_type = vlan
– network_vlan_ranges = physnet1:1000:2999,physnet2:3000:3999
● Bridge configuration in compute nodes: each physical network will
require a bridge
– sudo ovs-vsctl add-br br-eth1
– sudo ovs-vsctl add-port br-eth1 eth1
● Quantum agents in compute nodes
(/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini)
– network_vlan_ranges = physnet1:1000:2999,physnet2: 3000:3999
– bridge_mappings = physnet1:br-eth1,physnet2:br-eth2
● Example of creating a virtual network:
– quantum net-create $tenant_network_name --provider:network_type vlan
--provider:physical_network physnet1 --provider:segmentation_id 1

34. Tenant networks realized
with tunnels (openvswitch)
● Quantum server in controller
(/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini)
– tenant_network_type = gre
– tunnel_id_ranges = 1:1000
● Quantum agents in compute nodes
(/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini)
– enable_tunneling = True
– tunnel_id_ranges = 1:1000
– tunnel_bridge = br-tun
– local_ip = 10.0.0.3
●
Example of creating a virtual network:
– quantum net-create $tenant_network_name --provider:network_type gre
--provider:segmentation_id 1

35. Host A
network A
local Vlan ID 1 network C
local Vlan ID 3
int-br-
eth1-1 patch-tun
br-int patch-port
ve
th int-br-eth1-2
network B
local Vlan ID 2
phy-br- patch-int
eth1-1 phy-br-eth1-2
Physnet1 vSwitch Physnet2 vSwith
br-eth1-1 br-eth1-2 br-tun
GRE
Physical net1 physical net2
vlan ID 1000 host B
Flat
host C
host C

36. External networks and
floating ip's implementation
Vm
10.0.1.5/24 Floating ip
gw: 10.0.1.1/24 fixed port on
fixed ip
Floatingip network
Router interface
In general,
port The port acting
10.0.1.1/24
as router
gw_port
7.0.1.2/24 interface should
Floating ip: have gateway
7.0.1.4/24 address of
subnet
External network internal network
router
external network
vswitch br-ex
eth0
l3_agent
Router is used for VM to access outside
Floating IP is used for outside to access VM

37. Dhcp agent
AMPQ communication
quantum-server
get_active_networks
get_network_info
get_dhcp_port
release_dhcp_port
release_port_fixed_ip
update_lease_expiration
Plugin agent Quantum rest api
(resource CRUD)
get_device_details
update_device_down network_delete tunnel_update port_update
tunnel_sync
q-agent-notifier- q-agent-notifier- q-agent-notifier-
Quantum network-delete_fanout tunnel-update_fanout port-update_fanout
Exchange: topic fanout fanout fanout
q-agent-notifier- q-agent-notifier- q-agent-notifier-
Queue: q-plugin notifications.info network-delete_fanout tunnel-update_fanout port-update_fanout
_{uuid4} _{uuid4} _{uuid4}
Comsumer: quantum-server Dhcp agent Plugin agent

38. Booting a VM

39. DevStack set-up: localrc
● HOST_IP=172.16.0.2
● PUBLIC_INTERFACE=eth1
● FIXED_RANGE=10.0.0.0/24
●
FIXED_NETWORK_SIZE=256
● FLOATING_RANGE=172.31.0.0/24
● disable_service n-net
● enable_service q-svc
● enable_service q-agt
●
enable_service q-dhcp
● enable_service q-l3
● enable_service quantum
● Q_PLUGIN="openvswitch"
● ENABLE_TENANT_TUNNELS=True
●
TENANT_TUNNEL_RANGES=1:100
● ENABLE_TENANT_VLANS=False

40. Thanks!
Questions?
I am looking for a job
Miguel Lavalle
miguel@mlavalle.com
OpenStack Quantum Hacker