Virtual Networking for OVS - Trinath Somanchi - Senior Technical Lead - 2, NXP Inda

1. OVN – Virtual Networking for OVS
OVN - 101

2. Agenda
• Introduction – What is OVN ? Why its different?
• Openstack Neutron with OVN
• OVN architecture – DB schema and Utilities
• OVN – ACL and L3 Design
• OVN L2 – Deep dive – Example
• OVN Limitations

3. Introduction
“Open vSwitch is the most popular choice of virtual switch in OpenStack deployments. To
make OVS more effective in these environments, we believe the logical next step is to
augment the low-level switching capabilities with a lightweight control plane that provides
native support for common virtual networking abstractions.”
- OVN, uses a protocol called OVSDB (Open vSwitch Database), which is an open protocol defined in
RFC 7047 and has been used up until now as a management protocol to configure OVS.

4. What is OVN?
• Opensource Virtual Networking for 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
• Integration with Openstack and other CMS.

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.
• DPDK-based and hardware-accelerated gateways.
• Leverages new OVS DPDK port.
• Works with switches from Arista, Brocade, Cumulus, Dell, HP, Juniper, and
Lenovo

6. Openstack Neutron with OVN
• ML2 driver for OVN.
• Replaces OVS ML2 driver and Neutron’s OVS agent.
• Speaks OVSDB to configure OVN via its Northbound database.
• Only run Neutron API server – No other agents.
• No RabbitMQ ( except for notifications to ceilometer and other stuff).
• OVN DHCP agent (TODO)

7. Openstack Neutron with OVN - Overview
Neutron
DB
Neutron Server ovsdb-server
rabbitmq
ovn-northd
ovn-controller
neutron-*aas

8. OVN – Architecture
Openstack CMS (Neutron-Server)
OVN North bound DB
OVN – Northd
(daemon)
OVN South bound DB
ovn-controller
ovsdb-server ovs-vswitchd
ovn-controller
ovsdb-server ovs-vswitchd
openflowOVSDBOVSDB
openflow
OVSDB
OVSDB
OVSDB
Hypervisor 1 Hypervisor N
ovn-northd
Translate between the logical network elements configured by the CMS to the Northbound DB and
model them to the Southbound DB tables, which holds the physical/infrastructure bindings and the
logical flows which enable the logical connectivity.
Service Plugins
L3 Service Plugin OVN
ML2 Mechanism Driver
OVN Mech. Driver

9. OVN – Databases – Northbound DB
• Two clients
• CMS which translate its own notion of logical networking configuration into the OVN model (Openstack
Neutron for example, it translate neutron networks/ports/security groups into logical switches/logical
ports/ACL's).
• ovn-northd daemon, which translate this DB into the Southbound DB model.
• Describes the logical network in conventional network concepts with only virtual elements and the
connectivity between them.
• Like., logical switches, logical ports that connect to these switches and logical routers which connects between different
logical switches.
• Also ACL's which we can attach to logical switches and configure them for specific logical ports.
• Communication between the ovn-northd and the CMS is bidirectional.
• ovn-northd can update the CMS when a port operational status is up, indicating all needed hooks and configuration took
place (This is useful in the Neutron case as Neutron needs to indicate to Nova when a port is ready after deploying a VM).
CMS – Cloud Management System (here, Openstack)
OVN North bound DB

10. OVN – Databases – Southbound DB
• Data Classification
• Physical Network: Information about the chassis nodes in the system. This contains all the information
necessary to wire the overlay, such as IP addresses, supported tunnel types, and security keys.
• Logical Network: the topology of logical switches and routers, ACLs, firewall rules, and everything
needed to describe how packets traverse a logical network, represented as logical datapath flows.
• Bindings: The current placement of logical components (such as VMs and vifs) onto chassis and the
bindings between logical ports and MACs.
• The ovn-northd daemon populate the logical datapath flows, while the ovn-controller (OVN agent
in the hypervisor) populate the physical elements and the bindings.
• ovn-controller uses the DB information and connects to the local OpenVSwitch as an Openflow
controller to actually configure the needed flows for correct connectivity and also as an OVSDB
manager to read the local configurations.
OVN South bound DB

11. OVN – Database schema
ovn_nb :: OVN Northbound database schema
name (str)
ports (set of logical_ports)
acls (set of acls)
logical_switch
name (str)
type (str)
options (str-str)
parent_name (str)
tag (int 1-4095)
up (bool – port state)
enabled (bool – port state)
addresses (str)
port_security (str)
logical_port
priority (int 1-32767)
direction (str to-lport or
from-lport)
match (str)
action (str – allow-
rejected, drop, allow,
reject)
log (bool)
acl
name (str)
ports (str set of logical_router_ports)
default_gw (str)
logical_router
name (str)
network (str)
mac (str)
enabled (bool)
peer (attachment of LRP)
logical_router_port
Each of the tables in this database contains a special
column, named external_ids. This column has the
same form and purpose each place it appears.

12. OVN – Database schema
ovn-sb :: OVN Southbound database schema
name (str)
encaps (set of 1 or more
encaps)
vtep_logical_switches (set
of str)
chassis
Logical_datapath
(datapath_binding)
pipeline (str, ingress-
egress)
table_id (int 0-15)
priority (int 0-65,535)
match (str)
actions (str)
stage_name (str)
logical_flow
tunnel_key (int 1-
16,777,215)
logical_switch (nb-relation)
logical_router (nb-relation)
datapath_binding
type (str, one of stt, geneve or vxlan)
options (str-str)
ip (str, ipv4 addr of encap tep)
encap
datapath (datapath_binding)
tunnel_key (int, 32768-65535)
name (str)
ports (set of 1 or more weak
reference to Port_Bindings)
multicast_group
Each of the tables in this database contains a special column, named external_ids. This
column has the same form and purpose each place it appears.
datapath (datapath_binding)
logical_port (str)
chassis (str chassis)
tunnel_key (int, 1-32768)
mac (str)
type (str)
port_binding

13. OVN – Utilities
• ovn-nb - OVN_Northbound database schema
• This database is the interface between OVN and the cloud management system (CMS), such as OpenStack,
running above it. The CMS produces almost all of the contents of the database. The ovn-northd program
monitors the database contents, transforms it, and stores it into the OVN_Southbound database.
• ovn-sb - OVN_Southbound database schema
• This database holds logical and physical configuration and state for the Open Virtual Network (OVN) system
to support virtual network abstraction.
• ovn-nbctl - Open Virtual Network northbound db management utility
• This utility can be used to manage the OVN northbound database.
• ovn-sbctl - utility for querying and configuring OVN_Southbound database.
• ovn-northd - Open Virtual Network central control daemon
• Responsible for translating the high-level OVN configuration into logical configuration consumable by
daemons such as ovn-controller. It translates the logical network configuration in terms of conventional
network concepts, taken from the OVN Northbound Database, into logical datapath flows in
the OVN Southbound Database below it.
• ovn-controller - Open Virtual Network local controller
• ovn-controller-vtep - Open Virtual Network local controller for vtep enabled physical switches.

14. OVN – Security Groups
• Existing way
• Requires extra linux bridge and
vEth pair per VM.
• Uses Iptables.
• Using OVN ACLs
• Uses kernel conntrack module
directly from OVS.
• Design benefits.
• No complicated pipeline.
• Faster* -- Fewer hops and veth ports.VM VM
Linux
Bridge
Linux
Bridge
OVS (br-int)
eth eth
tap tap
veth
veth veth
veth
VM VM
OVS (br-int)
eth eth
tap tap

15. OVN – L3 design
• Neutron L3 Agent – Current design
• Agent based.
• Used the Linux IP stack and iptables.
• Forwarding.
• NAT.
• Overlapping IP address support using namespaces
• OVN L3 design
• Native support for IPv4 and IPv6.
• Distributed.
• ARP/ND suppression.
• Flow caching improves performance.
• Without OVN: multiple per-packet routing layers.
• With OVN: cache sets dest mac, decrements TTL.
• No use of Neutron L3 agent

16. OVN L2 – Deep dive
• Multi node Openstack Setup with OVN plugin.
• 3 VM’s
• one in the controller node (VM1) and
• two in the other compute node (VM2 and VM3)
• All connected to the “private” network.
Network Topology
OVN recognizes, two nodes on Chassis with Geneve tunnel
Between them, it's important to note that the tunnel was
created only when VM’s from the same logical network were
actually deployed in the two nodes.
Tunnel port created on br-int.
Router namespace creation remains unaffected.
The OVN Southbound DB Binding table has entries that link
between the logical elements configured in the Northbound
DB and their location in the physical infrastructure.

17. OVN L2 – Deep dive
Flow tables at each Node:
Table 0 - Network classification and incoming tunnel traffic dispatching.
Table 16 - Ingress Port Security (This table blocks broadcast/multicast src addresses and
also logical VLANs as they are not yet supported)
Table 17 - Destination lookup, broadcast, multicast and unicast handling (and unknown
MACs)
Table 18 – ACL (not implemented)
Table 19 - Egress Port Security
Table 64 - Output table (Logical to Physical or Local - last step in the pipeline which now
need to send the packet to the correct port (local or over a tunnel to other compute
node))

18. OVN – an example – On HV1
Name Ports
LS1 LP1, LP2
Name MAC
LP1 AA11
LP2 BB22
Chassis Name Encap IP address
HV1 Geneve* 10.0.0.10
HV2 Geneve* 10.0.0.11
Datapath Match Action
LS1 eth.dst = AA11 LP1
LS1 eth.dst = BB22 LP2
LS1 eth.dst = <broadcast> LP1, LP2
Logical switch
Logical port
Chassis (ovn-controller)
Bindings (ovn-controller)
Pipeline (ovn-northd)
Logical Port Name Chassis Name
LP1 HV1
*Geneve: Generic Network Virtualization Encapsulation

19. OVN – an example – LP2 arrives on HV2
Name Ports
LS1 LP1, LP2
Name MAC
LP1 AA11
LP2 BB22
Chassis Name Encap IP address
HV1 Geneve 10.0.0.10
HV2 Geneve 10.0.0.11
Datapath Match Action
LS1 eth.dst = AA11 LP1
LS1 eth.dst = BB22 LP2
LS1 eth.dst = <broadcast> LP1, LP2
Logical switch
Logical port
Chassis (ovn-controller)
Bindings (ovn-controller)
Pipeline (ovn-northd)
` Chassis Name
LP1 HV1
LP2 HV2

20. OVN - Limitations
• HA/Redundancy
• ovsdb-server is not distributed, which means you cannot have a cluster or redundancy/high
availability to your instance which has a critical job in the process.
• Scale
• since ovsdb-server is not distributed it also does not support load sharing, this means that all
controllers connect to the same instance and hence can introduce bottlenecks on busy
setups, this doesn't scale up well.
• Different environments might have different requirements
• Different users might need different solutions for DB distribution in regards to latency /
configuration changes / resource availability to run the control plane software / SLA regarding
configuration loses and so on, this approach means that ovsdb-implementation must support
all possible use cases.
• Locked-In Solution
• User/Cloud admin is locked to a single solution implementation which is not necessary
related to network virtualization

21. References & more reading
• http://docs.openstack.org/developer/networking-ovn/readme.html
• http://galsagie.github.io/tags/#OVN
• http://benpfaff.org/~blp/dist-docs/ovn-architecture.7.html
• https://wiki.opnfv.org/_media/ovn-opnfv-summit2015.pdf
• http://openvswitch.org/support/slides/OVN_Tokyo.pdf
• http://openvswitch.org/pipermail/discuss/2015-
November/019317.html
• http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-
November/006641.html

22. Happy Switching … 