OVN – Virtual Networking for OVS

OVN - 101

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

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.

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.

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

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)

Openstack Neutron with OVN - Overview

Neutron DB

Neutron Server ovsdb-server

rabbitmq

ovn-northd

ovn-controller

neutron-*aas

OVN – ArchitectureOpenstack 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

openflowOVSDBOVSDBopenflow

OVSDB

OVSDB

OVSDB

OVSDBOVSDB

Hypervisor 1 Hypervisor N

ovn-northdTranslate 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 PluginsL3 Service Plugin OVN

ML2 Mechanism DriverOVN Mech. Driver

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

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

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.

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

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.

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

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

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 wereactually 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 NorthboundDB and their location in the physical infrastructure.

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 SecurityTable 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))

OVN – an example – On HV1

Name PortsLS1 LP1, LP2

Name MACLP1 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 NameLP1 HV1

*Geneve: Generic Network Virtualization Encapsulation

OVN – an example – LP2 arrives on HV2Name PortsLS1 LP1, LP2

Name MACLP1 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 NameLP1 HV1

LP2 HV2

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

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.ht

ml• http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-November/

006641.html

Happy Switching …