OpenStack Networking

2. Game on!!!
Why… What…
Nuts n Bolts
Use Cases

4. Technology Limitations
Cloud stresses networks like never before:
• High-density multi-tenancy
• Massive scale
• Strict uptime requirements.
• Legacy hosting / remote data centers.
• Price pressure
• VM mobility
Nova provides only basic technologies:
• VLANs alone for multitenancy
• Simple Linux Bridge
• No QoS, ACLs, or monitoring
• “network” node -> SPOF

5. No Tenant Control
Rich enterprise network topologies:
• “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 sites
Nova provides no tenant control:
• No way to control topology.
• Cloud assigns IP prefixes + addresses.
• No generic service insertion.

6. In a n u t s h e l l …
Workloads
Enterprise
Networks
Multitenancy
Ondemand

7. Seriously, why Quantum?
• New networking technologies:
 SDN / OpenFlow
 Overlay Tunneling – VXLAN, NVGRE, SIT
 Fabric Solution – FabricPath, Qfabric etc.
• ‘plugin’ mechanism via Quantum API.
• Additional Control:
 Security & Compliance
 QoS + Monitoring + Troubleshooting
 Advanced Services – FW, IDS/IPS, VPN, …

8. Quantum
Quantum is an OpenStack core project to provide network connectivity as a service
between interface devices (e.g: vNICs) managed by other OpenStack services (e.g: Nova)
Provides a “building block” for sophisticated cloud network topologies
- @danwendlandt
Nova Quantum
*-as-a-Service Compute Networking
API Abstractions ‘virtual servers’ – Disk, CPU, ‘virtual network’ – L2 segment.
Memory, NICs ‘virtual port’ – connecting to
virtual networks.
Interactions ‘virtual images’ from Glance Virtual ports are linked to
vNICs on virtual servers
Back-end technologies KVM, XEN, HyperV, ESX OVS, CISCO, Nicira
API extensibility Keypairs, volumes, instance QoS, port statistics, security
operations groups etc.

9. Nuts n Bolts
Abstractions
• Network – An isolated L2 segment, analogous to VLAN in the physical networking
world.
• Subnet – A block of v4 or v6 IP addresses and associated configuration state.
• Port – A connection point for attaching a single device, such as the NIC of a virtual
server
Components
• quantum-server – Python daemon that exposes the Quantum API and passes user
requests to the configured Quantum plugin for additional processing.
• Plugin agent (quantum-*-agent) – Runs on each hypervisor to perform local vswitch
configuration. Agent to be run depends on which plugin you are using, as some plugins
do not require an agent.
• dhcp agent (quantum-dhcp-agent) – Provides DHCP services to tenant networks. This
agent is the same across all plugins.
• l3 agent (quantum-l3-agent) – Provides L3/NAT forwarding to provide external network
access for VMs on tenant networks. This agent is the same across all plugins.

11. Architecture
Credits: @danwendlandt

12. OpenStack with Quantum
Credits: @taturiello

13. nova-
network Quantum
Who should use Quantum
• Need & Requirements
• “Early Adopters”
• Since Folsom, widespread adoption

14. Plugins
It's the component where the 'virtual networking' magic happens.
Same behaviour from Quantum API regardless of plugin employed.

15. Use Cases
Single Flat Network Multiple Flat Network Mixed Flat & Private Network
Provider Router with Private Networks Per-Tenant Router with Private Networks
Source: Quantum Admin Guide – http://docs.openstack.org

16. Advanced Services
 Topology defines logical model for connectivity at L2/L3
 “advanced network service” can be regarded as a “network
application” running on top of this logical platform providing a
particular L4 to L7 network service
 ‘service’ is to Quantum as ‘flavor’ is to Compute.
 Modes of interaction:
• Ignore what lies beneath Service just assumes something
provides the required connectivity
• Use Quantum Service runs independently of Quantum, but uses
its API to configure its own resources
• Be a part of Quantum The service runs within the Quantum
process spaces and is part of its logical model
 Quantum’s plugin approach
 Back end implementation of a routers could be capable of providing a
range of services
• L3 fwd, Ext GW, VPN access, Load Balancing, Firewall, etc.
 Same kind of service could even be provided by different driver

17. Whatz in Grizzly?
• Metadata improvements
• Simplified phy n/w conf, overlapping IP addres
• Multiple network nodes running L3-agents and DHCP-agents
• Security groups
• L3-L4 packet filtering for security policies to protect virtual machines.
• Backward compatible with Nova-API
• Additional features (not in Nova):
• IPv6 and IPv4 support
• Inbound + Outbound filtering
• Load-balancing-as-a-Service (LBaaS)
• Full load balancing API model + pluggable framework
• Basic implementation based on HAproxy
• New Plugins supported
• Big Switch, Brocade, Hyper-V, Plum Grid, Midonet
• Additional Improvements to Existing Plugins
• Nicira NVP Plugin: Quality-of-Service, L2-Gateways, Port-Security.
• Ryu: support for OVS tunneling.
• Seamless upgrade from Folsom to Grizzly
• Horizon GUI support for Routers + Loadbalancers

18. Thanks!
Questions/Comments?
Kiran Murari
kiranmurari@gmail.com
Twitter: @kiranmurari
http://www/slideshare.net/kiranmurari
Images used in this presentation are from public domain and their creators hold the respective rights.
LOGOS used in this presentation are the registered trademarks of respective companies and Organizations.