OVN:
Open Virtual Network
for Open vSwitch
Russell Bryant (@russellbryant)
Kyle Mestery (@mestery)
Justin Pettit (@Justin_D_Pettit)
Virtual Networking Overview
Provides a logical network abstraction on top of a physical
network
2
VMA VMB
VMC
L-Switch
VM3
HV2
L-Switch
L-Router
L-Switch L-Switch
VM5VM4VM3
VM1 VM2
VM4
VMB VMC VM5
HV1
VM1 VM2 VMA
Physical Logical
What is OVN?
• Open source virtual networking for Open vSwitch (OVS)
• Provides L2/L3 virtual networking
– Logical switches and routers
– Security groups
– L2/L3/L4 ACLs
– Multiple tunnel overlays (Geneve, STT, and VXLAN)
– TOR-based and software-based logical-physical gateways
• Work on same platforms as OVS
– Linux (KVM and Xen)
– Containers
– DPDK
– Hyper-V
• Integration with OpenStack and other CMSs
The Particulars
• Developed by the same community as Open vSwitch
• Vendor-neutral
• Architecture and implementation have all occurred on public
mailing lists
• Developed under the Apache license
4
Goals
• Production-quality
• Straight-forward design
• Scale to thousands of hypervisors (each with many VMs and
containers)
• Improved performance and stability over existing plugin
5
Why OVN is different
• Will not require any additional agents for functionality for
simplified deployment and debugging
• Security groups using new in-kernel conntrack integration
– More secure and faster than other methods
– “Taking Security Groups to Ludicrous Speed with Open vSwitch” at 9:50 on
Thursday
• DPDK-based and hardware-accelerated gateways
– Leverages new OVS DPDK port
– Works with switches from Arista, Brocade, Cumulus, Dell, HP, Juniper, and
Lenovo
6
Why OVN is Important
to OpenStack
Why OVN is Important to OpenStack
● Neutron’s default backend is a custom virtual
networking control plane
● Long term, we feel Neutron is best served
letting a separate project implement the
virtual network control plane
Why OVN is Important to OpenStack
● Migration from OVS backend to OVN is very
natural for Neutron
● Just taking advantage of increasing
functionality in OVS, which is already in use
OpenStack Neutron Platform
● Neutron evolving to be a platform
○ First step: Plugin decomposition
○ Second step: Bringing the plugin and driver
backends under the Neutron tent
○ Third step: Open Source backends mature
● OVN fits into this Neutron Platform model
Neutron Integration with OVN
● ML2 driver for OVN
○ replaces OVS ML2 driver and Neutron’s OVS agent
● Uses Neutron L3 and DHCP agents, but just
until OVN support is ready
Designed to Scale
• Configuration coordinated through databases
• Local controller converts logical flow state into physical flow
state
• Desired state clearly separated from run-time state
• Grouping techniques reduce Cartesian Product issues
12
OVN Architecture
13
ovn-northd
ovs-
vswitchd
ovn-controller
ovsdb-
server
HV-1
ovs-
vswitchd
ovn-controller
ovsdb-
server
HV-n
…
Northbound
DB
Southbound DB
OpenStack/
CMS Plugin
The OVN Databases
• ovn-northbound
– OpenStack/CMS integration point
– High-level, desired state
• Logical ports -> logical switches -> logical routers
• ovn-southbound
– Run-time state
• Location of logical ports
• Location of physical endpoints
• Logical pipeline generated based on configured and run-time state
14
The Daemons
• ovn-northd
– Converts from the high-level northbound DB to the run-time
southbound DB
– Generates logical flows based on high-level configuration
• ovn-controller
– Registers chassis and VIFs to southbound DB
– Converts logical flows into physical flows (ie, VIF UUIDs to OpenFlow
ports)
– Pushes physical configuration to local OVS instance through OVSDB and
OpenFlow
15
An Example
16
Name Ports
LS1 LP1,LP2
Name MAC
LP1 AA
LP2 BB
Name Encap IP
HV1 Geneve 10.0.0.10
HV2 Geneve 10.0.0.11
Name Chassis
LP1 HV1
Datapath Match Action
LS1 eth.dst = AA LP1
LS1 eth.dst = BB LP2
LS1 eth.dst = <broadcast> LP1,LP2
Logical_Switch
Logical_Port
Chassis (ovn-controller)
Bindings (ovn-controller)
Pipeline (ovn-northd)
LP2 Arrives on HV2
17
Name Ports
LS1 LP1,LP2
Name MAC
LP1 AA
LP2 BB
Name Encap IP
HV1 Geneve 10.0.0.10
HV2 Geneve 10.0.0.11
Name Chassis
LP1 HV1
LP2 HV2
Datapath Match Action
LS1 eth.dst = AA LP1
LS1 eth.dst = BB LP2
LS1 eth.dst = <broadcast> LP1,LP2
Logical_Switch
Logical_Port
Chassis (ovn-controller)
Bindings (ovn-controller)
Pipeline (ovn-northd)
Resources
• Architecture described in detail in ovn-architecture (5)
• Configuration is through a number of databases
– OVN Northbound – Interface between CMS and OVN (ovn-nb (5))
– OVN Southbound – Holds the configuration and state of the logical
and physical components (ovn-sb (5))
• Available in the “ovn” branch of the main OVS repo:
– https://github.com/openvswitch/ovs/tree/ovn
18
Status – The EZ Bake Milestone
• From start of coding to first ping: 6 weeks
• Needs more testing, obviously
• Haven’t tried any scale testing
• Features listed on first page should be ready by end of the year
• Expect rapid progress!
19
Neutron with built-in solution
DB
neutron-server
rabbitmq
L3 agentL3 agent
L3 agent
L3 agentL3 agent
DHCP agent
Adv. Services
L3 agentL3 agent
OVS agent
Neutron with OVN (so far)
DB
neutron-server
rabbitmq
L3 agentL3 agent
L3 agent
L3 agentL3 agent
DHCP agent
Adv. Services
ovsdb-server
ovn-northd
ovn-controller
ovn-controllerovn-controller
Neutron with OVN (later this year)
DB
neutron-server
rabbitmq Adv. Services
ovsdb-server
ovn-northd
ovn-controller
ovn-controllerovn-controller
Trying out OVN
Test #1 - ovs-sandbox
$ git clone http://github.com/openvswitch/ovs.git
$ cd ovs
$ git checkout -b ovn origin/ovn
$ ./boot.sh && ./configure && make
$ make sandbox SANDBOXFLAGS=”--ovn”
Test #1 - ovs-sandbox
$ ovn-nbctl lswitch-add sw0
$ ovn-nbctl lport-add sw0 sw0-port1
$ ovn-nbctl lport-add sw0 sw0-port2
$ ovn-nbctl lport-set-macs sw0-port1 00:00:00:00:00:01
$ ovn-nbctl lport-set-macs sw0-port2 00:00:00:00:00:02
$ ovs-vsctl add-port br-int lport1 -- 
set Interface lport1 external_ids:iface-id=sw0-port1
$ ovs-vsctl add-port br-int lport2 -- 
set Interface lport2 external_ids:iface-id=sw0-port2
Test #1 - ovs-sandbox
# Trace OpenFlow flows for a packet from port 1 to 2
$ ovs-appctl ofproto/trace br-int 
in_port=1,dl_src=00:00:00:00:00:01,
dl_dst=00:00:00:00:00:02 -generate
Test #2 - Multi-node DevStack
$ git clone http://git.openstack.org/openstack-
dev/devstack.git
$ git clone http://git.openstack.
org/stackforge/networking-ovn.git
$ cd devstack
… Get local.conf from networking-ovn/devstack/
… local.conf.sample or computenode-local.conf.sample
$ ./stack.sh
More cool stuff that works
● Can be used to create overlay networks for
containers across many hosts
● If OVN backs Neutron, containers in VMs
can be hooked up to virtual networks
managed by Neutron
What’s Next for Core OVN
• Security groups using in-kernel conntrack
• ovn-controller that translates to “vtep” schema to enable
physical gateways
• OVS-DPDK gateway that uses “vtep” schema
• L3 routing and native IP management
• New test framework that allows local build-time testing with
tunnels and arbitrary topologies
• Merge “ovn” into OVS master branch
29
OVN Neutron Integration Future
● L3 service plugin
● security groups
● get tempest CI job passing
● create multi-node CI job
Longer Term
• DPDK datapath
– Move beyond the capabilities of the “vtep” schema to support fail-
over, scale-out, and more stateful services
– Will become a reference for building OVS DPDK applications
• Architecture will allow innovation in the logical network space
– New approaches to networking and security
31
How you can help
• Try it! Test it! Write Code!
• Report bugs and try it at scale
• Core OVN is being developed on ovs-dev mailing list:
– http://openvswitch.org/pipermail/dev/
– #openvswitch on Freenode
• Neutron plugin for OVN is being developed here:
– http://git.openstack.org/stackforge/networking-ovn.git
– openstack-dev mailing list
– #openstack-neutron-ovn on Freenode
32
Thank you!
Russell Bryant (@russellbryant)
Kyle Mestery (@mestery)
Justin Pettit (@Justin_D_Pettit)

Ovn vancouver

  • 1.
    OVN: Open Virtual Network forOpen vSwitch Russell Bryant (@russellbryant) Kyle Mestery (@mestery) Justin Pettit (@Justin_D_Pettit)
  • 2.
    Virtual Networking Overview Providesa logical network abstraction on top of a physical network 2 VMA VMB VMC L-Switch VM3 HV2 L-Switch L-Router L-Switch L-Switch VM5VM4VM3 VM1 VM2 VM4 VMB VMC VM5 HV1 VM1 VM2 VMA Physical Logical
  • 3.
    What is OVN? •Open source virtual networking for Open vSwitch (OVS) • Provides L2/L3 virtual networking – Logical switches and routers – Security groups – L2/L3/L4 ACLs – Multiple tunnel overlays (Geneve, STT, and VXLAN) – TOR-based and software-based logical-physical gateways • Work on same platforms as OVS – Linux (KVM and Xen) – Containers – DPDK – Hyper-V • Integration with OpenStack and other CMSs
  • 4.
    The Particulars • Developedby the same community as Open vSwitch • Vendor-neutral • Architecture and implementation have all occurred on public mailing lists • Developed under the Apache license 4
  • 5.
    Goals • Production-quality • Straight-forwarddesign • Scale to thousands of hypervisors (each with many VMs and containers) • Improved performance and stability over existing plugin 5
  • 6.
    Why OVN isdifferent • Will not require any additional agents for functionality for simplified deployment and debugging • Security groups using new in-kernel conntrack integration – More secure and faster than other methods – “Taking Security Groups to Ludicrous Speed with Open vSwitch” at 9:50 on Thursday • DPDK-based and hardware-accelerated gateways – Leverages new OVS DPDK port – Works with switches from Arista, Brocade, Cumulus, Dell, HP, Juniper, and Lenovo 6
  • 7.
    Why OVN isImportant to OpenStack
  • 8.
    Why OVN isImportant to OpenStack ● Neutron’s default backend is a custom virtual networking control plane ● Long term, we feel Neutron is best served letting a separate project implement the virtual network control plane
  • 9.
    Why OVN isImportant to OpenStack ● Migration from OVS backend to OVN is very natural for Neutron ● Just taking advantage of increasing functionality in OVS, which is already in use
  • 10.
    OpenStack Neutron Platform ●Neutron evolving to be a platform ○ First step: Plugin decomposition ○ Second step: Bringing the plugin and driver backends under the Neutron tent ○ Third step: Open Source backends mature ● OVN fits into this Neutron Platform model
  • 11.
    Neutron Integration withOVN ● ML2 driver for OVN ○ replaces OVS ML2 driver and Neutron’s OVS agent ● Uses Neutron L3 and DHCP agents, but just until OVN support is ready
  • 12.
    Designed to Scale •Configuration coordinated through databases • Local controller converts logical flow state into physical flow state • Desired state clearly separated from run-time state • Grouping techniques reduce Cartesian Product issues 12
  • 13.
  • 14.
    The OVN Databases •ovn-northbound – OpenStack/CMS integration point – High-level, desired state • Logical ports -> logical switches -> logical routers • ovn-southbound – Run-time state • Location of logical ports • Location of physical endpoints • Logical pipeline generated based on configured and run-time state 14
  • 15.
    The Daemons • ovn-northd –Converts from the high-level northbound DB to the run-time southbound DB – Generates logical flows based on high-level configuration • ovn-controller – Registers chassis and VIFs to southbound DB – Converts logical flows into physical flows (ie, VIF UUIDs to OpenFlow ports) – Pushes physical configuration to local OVS instance through OVSDB and OpenFlow 15
  • 16.
    An Example 16 Name Ports LS1LP1,LP2 Name MAC LP1 AA LP2 BB Name Encap IP HV1 Geneve 10.0.0.10 HV2 Geneve 10.0.0.11 Name Chassis LP1 HV1 Datapath Match Action LS1 eth.dst = AA LP1 LS1 eth.dst = BB LP2 LS1 eth.dst = <broadcast> LP1,LP2 Logical_Switch Logical_Port Chassis (ovn-controller) Bindings (ovn-controller) Pipeline (ovn-northd)
  • 17.
    LP2 Arrives onHV2 17 Name Ports LS1 LP1,LP2 Name MAC LP1 AA LP2 BB Name Encap IP HV1 Geneve 10.0.0.10 HV2 Geneve 10.0.0.11 Name Chassis LP1 HV1 LP2 HV2 Datapath Match Action LS1 eth.dst = AA LP1 LS1 eth.dst = BB LP2 LS1 eth.dst = <broadcast> LP1,LP2 Logical_Switch Logical_Port Chassis (ovn-controller) Bindings (ovn-controller) Pipeline (ovn-northd)
  • 18.
    Resources • Architecture describedin detail in ovn-architecture (5) • Configuration is through a number of databases – OVN Northbound – Interface between CMS and OVN (ovn-nb (5)) – OVN Southbound – Holds the configuration and state of the logical and physical components (ovn-sb (5)) • Available in the “ovn” branch of the main OVS repo: – https://github.com/openvswitch/ovs/tree/ovn 18
  • 19.
    Status – TheEZ Bake Milestone • From start of coding to first ping: 6 weeks • Needs more testing, obviously • Haven’t tried any scale testing • Features listed on first page should be ready by end of the year • Expect rapid progress! 19
  • 20.
    Neutron with built-insolution DB neutron-server rabbitmq L3 agentL3 agent L3 agent L3 agentL3 agent DHCP agent Adv. Services L3 agentL3 agent OVS agent
  • 21.
    Neutron with OVN(so far) DB neutron-server rabbitmq L3 agentL3 agent L3 agent L3 agentL3 agent DHCP agent Adv. Services ovsdb-server ovn-northd ovn-controller ovn-controllerovn-controller
  • 22.
    Neutron with OVN(later this year) DB neutron-server rabbitmq Adv. Services ovsdb-server ovn-northd ovn-controller ovn-controllerovn-controller
  • 23.
  • 24.
    Test #1 -ovs-sandbox $ git clone http://github.com/openvswitch/ovs.git $ cd ovs $ git checkout -b ovn origin/ovn $ ./boot.sh && ./configure && make $ make sandbox SANDBOXFLAGS=”--ovn”
  • 25.
    Test #1 -ovs-sandbox $ ovn-nbctl lswitch-add sw0 $ ovn-nbctl lport-add sw0 sw0-port1 $ ovn-nbctl lport-add sw0 sw0-port2 $ ovn-nbctl lport-set-macs sw0-port1 00:00:00:00:00:01 $ ovn-nbctl lport-set-macs sw0-port2 00:00:00:00:00:02 $ ovs-vsctl add-port br-int lport1 -- set Interface lport1 external_ids:iface-id=sw0-port1 $ ovs-vsctl add-port br-int lport2 -- set Interface lport2 external_ids:iface-id=sw0-port2
  • 26.
    Test #1 -ovs-sandbox # Trace OpenFlow flows for a packet from port 1 to 2 $ ovs-appctl ofproto/trace br-int in_port=1,dl_src=00:00:00:00:00:01, dl_dst=00:00:00:00:00:02 -generate
  • 27.
    Test #2 -Multi-node DevStack $ git clone http://git.openstack.org/openstack- dev/devstack.git $ git clone http://git.openstack. org/stackforge/networking-ovn.git $ cd devstack … Get local.conf from networking-ovn/devstack/ … local.conf.sample or computenode-local.conf.sample $ ./stack.sh
  • 28.
    More cool stuffthat works ● Can be used to create overlay networks for containers across many hosts ● If OVN backs Neutron, containers in VMs can be hooked up to virtual networks managed by Neutron
  • 29.
    What’s Next forCore OVN • Security groups using in-kernel conntrack • ovn-controller that translates to “vtep” schema to enable physical gateways • OVS-DPDK gateway that uses “vtep” schema • L3 routing and native IP management • New test framework that allows local build-time testing with tunnels and arbitrary topologies • Merge “ovn” into OVS master branch 29
  • 30.
    OVN Neutron IntegrationFuture ● L3 service plugin ● security groups ● get tempest CI job passing ● create multi-node CI job
  • 31.
    Longer Term • DPDKdatapath – Move beyond the capabilities of the “vtep” schema to support fail- over, scale-out, and more stateful services – Will become a reference for building OVS DPDK applications • Architecture will allow innovation in the logical network space – New approaches to networking and security 31
  • 32.
    How you canhelp • Try it! Test it! Write Code! • Report bugs and try it at scale • Core OVN is being developed on ovs-dev mailing list: – http://openvswitch.org/pipermail/dev/ – #openvswitch on Freenode • Neutron plugin for OVN is being developed here: – http://git.openstack.org/stackforge/networking-ovn.git – openstack-dev mailing list – #openstack-neutron-ovn on Freenode 32
  • 33.
    Thank you! Russell Bryant(@russellbryant) Kyle Mestery (@mestery) Justin Pettit (@Justin_D_Pettit)