This was a presentation I gave at the Open Networking Users Group (ONUG), Spring 2014. This talk covers some background on OpenStack and OpenDaylight, walks through Group Based Policy and OpFlex, and ends with a tutorial walk through of installing and using OpenStack with OpenDaylight.

1. OpenStack and
OpenDaylight:
Overview and
Workshop
Kyle Mestery
OpenStack Neutron PTL
OpenDaylight OVSDB Project
Developer
Open vSwitch Committer
Principal Engineer, Cisco
mestery@mestery.com
@mestery

2. What Will I Learn During This Workshop?
• A high level overview of OpenStack Neutron
• A high level overview of OpenDaylight
• A quick overview on Group Based Policy in both projects
• How OpenStack Neutron and OpenDaylight integrate together
• How to bring up a multi-node OpenStack environment
• How to use OpenDaylight for virtual networks with OpenStack
Neutron

3. For Advanced Users
• Feel free to take the image for a spin during my presentation!
• If you hit any issues, we’ve got you covered!
• Hop onto #opendaylight-ovsdb on Freenode
• A fine selection of Open Source engineers will assist you with any questions

4. OpenStack Overview

5. OpenStack: The Open Source Cloud
Platform
Compute (Nova)
Self-service provisioning of virtual
machines through a software API
Object Storage (Swift)
Massively scalable, distributed object
store
Network Service (Neutron)
For tenant created, virtual isolated
networks and subnets, and services
Your Application

6. OpenStack continues to build services which abstract
infrastructure and provide highly scalable utilities through
REST APIs, command tools and user portals
Every 6 month release, new services are added: moving quickly into auto-scaling, app orchestration, and network services
Compute
(VM provisioning)
Networking
(Virtual, Physical)
Storage
(Object)
Identity/Authentication
VM Image Catalog
User/Admin Portal
Metering
(Ceilometer)
Storage
(Block)
Orchestration
(HEAT)
Networking Services
(LB, FW, VPN, IDS..)
API’s - API’s

7. OpenStack Community Releases
(started October 2010 – 6 month release cycle)
Austin – October 2010
• Initial Release
• Compute (dev)
• Object Storage
Bexar– February 2011
• Second Release
• Compute – prod ready
Diablo – September 2011
• First “production-ready” release
• Initial deployments
Essex– April 2012
• Identity, Dashboard
• Quantum incubation
Catus – April 2011
• Multi-hypervisor
• KVM/QEMU, Xen
Folsom – October 2012
• Quantum core
• Cinder block storage
Grizzly– April 2013
• Metering, Orchestration, Bare metal,
LBaaS
Havana – October 2013
• L3 Network services
• (planned)
2011 2012 2013 2014
Icehouse– April 2014
• Stability
• Test coverage gaps

8. Networking in
OpenStack …

9. Neutron Network Service
- OpenStack Design Summit,April 2011
• Compute service (EC2): virtual machines
• Launch instance (image, mem_size, disk)
• Suspend, clone, migrate
• Storage service (S3, EBS): virtual disks
• Store object
• Create/attach block
• Network service (Neutron): virtual networks
• Create/delete private network
• Attach VM to network resource
• Maintain compatibility with Nova networking model
• Work with different networking environments
• Capabilities
• Routing
• IP address management
• Service attachment
App Svr
OS
VM
App Svr
OS
VM
App Svr
OS
VM

10. OpenStack Portal gives each user a view of their own network topology
(vm’s, subnets, routers)
Cisco developed visual interface
for network containers

11. OpenStack Use Cases
– going beyond public cloud service providers
• On premise, private cloud
• Large scale consumer-facing web applications/services
• Media companies
• Storage
• Mobile packet core
• Turn infrastructure into a set of services (FWaaS, LBaaS)
• NFV, elastic network services
• Span multiple data centers and service providers
• Big data analytics with optimized networking
• Bare metal provisioning using a “cloud-like” API

12. OpenStack’s design principle is to be built as a set of loosely coupled, but
related projects developing advanced cloud services
Neutron
networking
Nova
compute
Glance
image
Keystone
security
Incubated
Projects
Horizon
web interface
Swift
storage
• Covers compute, storage and
networking
• Used to build “public” or “private”
clouds
• Each service is driven by community
projects with contributions from many
companies
• Easier for innovation through adding
new services
• Small number of core services – larger
number of associated services

13. A special note on
OpenStack Neutron
ML2

14. What is Modular Layer 2 (ML2)?
Neutron ML2 Plugin
Network
OVS LinuxBridge Vendor X Vendor YHyper-V

15. ML2 Use Cases
• Replaces existing monolithic plugins, eases development of new plugins
• Eliminates redundant code
• Reduce development and maintenance effort
• New features
• Top-of-Rack switch control
• Avoid tunnel flooding via L2 population
• Modular Agents
• Heterogeneous deployments
• Specialized hypervisor nodes with distinct network mechanisms
• Integrate *aaS appliances
• Roll new technologies into existing deployments

16. ML2 Architecture Diagram
Neutron Server
ML2 Plugin
Type Manager Mechanism Manager
API Extensions
GRE
TypeDriver
Arista
VLAN
TypeDriver
VXLAN
TypeDriver
Cisco
Nexus
Hyper-V
L2
Population
Linuxbridge
Open
vSwitch
Tail-FNCS

17. OpenDaylight Overview

18. What is OpenDaylight?
OpenDaylight is an Open Source Software project under the Linux Foundation with the goal of
furthering the adoption and innovation of Software Defined Networking (SDN) through the creation of
a common industry supported platform
Code Acceptance Community
To create a robust, extensible,
open source code base that covers
the major common components
required to build an SDN solution
To get broad industry acceptance
amongst vendors and users
• Using OpenDaylight code
directly or through vendor
products
•Vendors using OpenDaylight
code as part of commercial
products
To have a thriving and growing
technical community contributing
to the code base, using the code in
commercial products, and adding
value above, below and around.

19. *
What is OpenDaylight building?
*

20. Base Network Service Functions
Management
GUI/CLI
Controller Platform
Southbound Interfaces
& Protocol Plugins
OpenDaylight APIs (REST)
DOVE Mgr
Data Plane Elements
(Virtual Switches,
Physical Device Interfaces)
Service Abstraction Layer (SAL)
(plug-in mgr., capability abstractions, flow programming, inventory, …)
OpenFlow
1.0 1.3
LISP
Topology Mgr Stats Mgr Switch Mgr Host Tracker
Shortest Path
Forwarding
VTN Coordinator
Affinity
Service
Network Applications Orchestration
& Services
OpenStack
Neutron
OpenFlow Enabled Devices
VTN Manager
VTN: Virtual Tenant Network
DOVE: Distributed Overlay Virtual Ethernet
DDoS: Distributed Denial Of Service
LISP: Locator/Identifier Separation Protocol
OVSDB: Open vSwitch DataBase Protocol
BGP: Border Gateway Protocol
PCEP: Path Computation Element Communication Protocol
SNMP: Simple Network Management Protocol
LISP Service
NETCONF BGP-LS
Additional Virtual & Physical Devices
Hydrogen Release (Jan 2014)
SNMP
DDoS Protection
Open vSwitches
OVSDB PCEP
OpenStack Service
Network
Config

21. Base Network Service Functions
Management
GUI/CLI
Controller Platform
Southbound Interfaces
& Protocol Plugins
OpenDaylight APIs (REST)
Data Plane Elements
(Virtual Switches,
Physical Device Interfaces)
Service Abstraction Layer (SAL)
(plug-in mgr., capability abstractions, flow programming, inventory, …)
OpenFlow
1.0 1.3
Topology Mgr Stats
Mgr
Switch Mgr Host
Tracker
Shortest Path
Forwarding
Network Applications Orchestration
& Services
OpenFlow Enabled Devices
VTN: Virtual Tenant Network
DOVE: Distributed Overlay Virtual Ethernet
DDoS: Distributed Denial Of Service
LISP: Locator/Identifier Separation Protocol
OVSDB: Open vSwitch DataBase Protocol
BGP: Border Gateway Protocol
PCEP: Path Computation Element Communication Protocol
SNMP: Simple Network Management Protocol
NETCONF
Additional Virtual & Physical
Devices
Base Edition
Open vSwitches
Network
Config

22. Base Network Service Functions
Management
GUI/CLI
Controller Platform
Southbound Interfaces
& Protocol Plugins
OpenDaylight APIs (REST)
Data Plane Elements
(Virtual Switches,
Physical Device Interfaces)
Service Abstraction Layer (SAL)
(plug-in mgr., capability abstractions, flow programming, inventory, …)
OpenFlow
1.0 1.3
LISP
Topology Mgr Stats
Mgr
Switch Mgr Host
Tracker
Shortest Path
Forwarding
Affinity
Service
Network Applications Orchestration
& Services
OpenFlow Enabled Devices
VTN: Virtual Tenant Network
DOVE: Distributed Overlay Virtual Ethernet
DDoS: Distributed Denial Of Service
LISP: Locator/Identifier Separation Protocol
OVSDB: Open vSwitch DataBase Protocol
BGP: Border Gateway Protocol
PCEP: Path Computation Element Communication Protocol
SNMP: Simple Network Management Protocol
LISP Service
NETCONF BGP-LS
Additional Virtual & Physical
Devices
Service Provider Edition
SNMP
DDoS Protection
Open vSwitches
PCEP
Network
Config

23. Base Network Service Functions
Management
GUI/CLI
Controller Platform
Southbound Interfaces
& Protocol Plugins
OpenDaylight APIs (REST)
DOVE Mgr
Data Plane Elements
(Virtual Switches,
Physical Device Interfaces)
Service Abstraction Layer (SAL)
(plug-in mgr., capability abstractions, flow programming, inventory, …)
OpenFlow
1.0 1.3
Topology Mgr Stats Mgr Switch Mgr Host Tracker
Shortest Path
Forwarding
VTN Coordinator
Affinity
Service
Network Applications Orchestration
& Services
OpenStack
Neutron
OpenFlow Enabled Devices
VTN Manager
VTN: Virtual Tenant Network
DOVE: Distributed Overlay Virtual Ethernet
DDoS: Distributed Denial Of Service
LISP: Locator/Identifier Separation Protocol
OVSDB: Open vSwitch DataBase Protocol
BGP: Border Gateway Protocol
PCEP: Path Computation Element Communication Protocol
SNMP: Simple Network Management Protocol
NETCONF
Additional Virtual & Physical Devices
Virtualization Edition
DDoS Protection
Open vSwitches
OVSDB
OpenStack Service
Network
Config

24. OpenStack
Neutron
Integration
with
OpenDaylight

25. OpenStack Integration: Status
• ML2 Driver available in Icehouse release!
• Supports VXLAN and GRE tunnel networks
• devstack support merged upstream
• Run OpenDaylight as a top-level service in devstack!
• OpenStack Neutron API Service available now in OpenDaylight
o provides Neutron API handling for multiple implementations
• Initial ML2 plugin focused on core Neutron functionality
o Still uses Neutron [DHCP, L3] agents

26. OpenStack/OpenDaylight Integration
Neutron Node
Compute Node
OpenDaylight Node
Network Node
Neutron Server
ML2 Plugin w/
OpenDaylight Driver
OpenDaylight Server
Neutron API Service
OVSDB Plugin
OVS
VM1 VM2
OVS
L3 Agent DHCP
Agent
REST API
RPC
OpenFlow &
OVSDB

27. OpenStack Integration: Next Steps
• Updates planned for Helium and Juno:
• VIF plugging changes for stability improvements
• Notify from ODL to MechanismDriver once ODL has setup the port on the host
• Security groups implemented using OpenFlow rules
• L3 routing handled by OpenDaylight
• Removes the need for the L3 agent
• Additional refinements and bug fixes

28. OpenVSwitch
OVSDB Protocol Library
Bidirectional JSON-RPC Library
Netty.io
Configuration
Service
Inventory
Service
API Driven SAL (ADSAL)
OpenFlow 1.0 Plugin
OpenFlow 1.0 Library
Connection
Service
Flow
Programmer
java.nio.socket
Model Driven SAL (MDSAL)
Inventory
Service
Connection
Service
Flow
Programmer
OpenFlow 1.3 Plugin
OpenFlow 1.3 Library
Netty io
OVSDB South-bound Plugin OpenFlow 1.0 SB Plugin OpenFlow 1.3 SB Plugin
Controller
Neutron
ML2 Plug-In
OpenDaylight NorthBound API Layer - REST APIs
OpenDaylight Neutron REST-API
OVSDB Neutron Application
OpenFlow 1.0

29. Quick
Overview of
Group Based
Policy

30. What is Group Based Policy?
• GBP introduces the notion of groups of endpoints and policy
abstractions governing communication between these groups
• Northbound API which accepts abstract policy based on application
requirements
• Multiple southbound implementations for programming network elements
• GBP is a project in both OpenStack Neutron and OpenDaylight
• Incubated project in ODL
• BP accepted for Juno in OpenStack Neutron

31. Group Based Policy Goals
• Fundamentally change how applications interface with the network
• Instead of dealing with network constructs (networks, subnets, ports, routes),
applications can deal with their intent in a declarative manner
• Provide application oriented interfaces to OpenStack Neutron and
OpenDaylight
• Provide a simpler interface and abstractions for applications
• Allow for easier consumption of resources by applications

33. OpFlex Overview
What exactly is OpFlex?
• The OpFlex Architecture Provides a distributed control system based
on a declarative policy information model.
• An incubated project in OpenDaylight consisting of three things: The
OpFlex protocol, the OpFlex SB plugin, and the OpFlex Policy Agent.

34. OpenDaylight OpFlex Architecture

35. Group Based Policy in the Open Source
Community
Group Policy API1
2
3
OpFlex Agent
Group Policy API
OpFlex Southbound Plugin
Contributors
Contributors
Contributors
Group Based Policy
Information Model
OpFlex Agent
Framework

36. How to get involved …
https://wiki.opendaylight.org/view/OpFlex:Main
https://wiki.opendaylight.org/view/Group_Policy:Main
#opendaylight-opflex on Freenode
#opendaylight-group-policy on Freenode

37. Workshop
Walkthrough

38. What You Will Need
• OpenDaylight Virtualization Edition with OVSDB
• Can be in a VM or on your laptop directly
• Download Link
• Two or more OpenStack Nodes
• One node running control software and optionally compute services
• One or more compute nodes

39. Logistics
• The Fedora20 VM has the following information:
• Users:
• root/password
• odl/odl
• Setup for DHCP for the image itself.

40. Boot Your VM Images
• Boot the VM which you will run OpenDaylight inside of.
• Optionally bring-up OpenDaylight on your laptop natively.
• This will work in either scenario.
• Verify IP addresses on your VMs (may require reboots).
• This should be done for all VMs.
• This may change once you import the OVF file.

41. OpenStack VM Setup
• Copy the VM image twice:
• Once for control and once for compute
• On both nodes:
• Update your networking
• The setup assumes eth0 as a NAT interface for external access, and eth1 on a private host
only network for communication between the nodes.
• On the control node:
• Login as odl/odl
• Copy local.conf.control to devstack/local.conf
• Edit devstack/local.conf and change IP addresses
• On the compute node:
• Login as odl/odl
• Copy local.conf.compute to devstack/local.conf
• Edit devstack/local.conf and change IP addresses

42. Browse to your ODL Window over HTTP

43. Boot Up Your OpenStack Instances
• Control Node:
• cd devstack
• ./stack.sh
• Compute Node:
• cd devstack
• ./stack.sh
• If you hit issues …
• Troubleshooting guide at the end of this slide deck

44. Your devstack
will look like
this

45. Login to Horizon (go to the IP of your
control node)

46. Login as
(admin/ad
min) to see
the Horizon
Dashboard

47. Spinup a
VM

48. Spinup a
VM
(cont.)

49. Instance is now booted

50. Repeat process for a second VM

51. Checkout OpenDaylight Web GUI

52. Ping test between VMs

53. Thank You!

54. Troubleshooting
The following slides all provide some general troubleshooting advice for the image
provided on the USB keys and available for download here:
https://wiki.opendaylight.org/images/HostedFiles/Fedora20_ODL_OpenStack.zip

55. Common Problems
• Remove devstack/local.conf before stacking
• Copy in local.conf.[control,compute] fresh
• Edit as appropriate
• Problem: OVS not running after reboot
• Solution: sudo systemctl restart openvswitch
• Make sure you have a default GW configured correctly
• Possible solution: sudo route add default gw 192.168.1.1
• There are two interfaces on the guest VM
• If you run into issues, bring down eth1
• Edit /etc/sysconfig/network-scripts/ifcfg-eth1

56. Volume problems
A volume group called stack-volumes already exists.
• Two solutions:
• Restack
• ./unstack.sh
• ./stack.sh
• Delete the volume file and remove the VG
• sudo rm -rf /opt/stack/data/stack-volumes-backing-file
• sudo vgchange -a n stack-volumes && sudo vgremove stack-volumes