Requirement

Overview

Open vSwitch (Ovs)

Open vSwitch, sometimes abbreviated as OvS, is a production-quality open-source implementation of a distributed virtual multi-layer switch. The main purpose of Open vSwitch is to provide a switching stack for hardware virtualisation environments, while supporting multiple protocols and standards used in computer networks.

OvS Database Management protocol

In virtualized server environments, a virtual switch (vSwitch) is typically used to forward traffic between different virtual machines (VMs) on the same physical host and between VMs and the physical network. Open vSwitch is designed to be used as a vSwitch in such environments. Open vSwitch (OVS) is open to programmatic extension and control using OpenFlow and the OVSDB (Open vSwitch Database) management protocol.

The OvS DB management protocol is based on RFC7047. It uses JSON (RFC4627) for its wire format and is based on JSON-RPC version 1.0. The schema of the Open vSwitch database is documented in http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf. Based on RFC7047 specification, the OvS DB management protocol should use JSON-RPC TCP transport. IANA has assigned TCP port 6640 for this protocol. The UNIX transport also can be used as is supported by current OvS implementation (OvS DB server application).

OvS events plugin

The OvS link plugin monitors the link status of OvS connected interfaces and dispatches the state of the interfaces through collectd notification mechanism whenever the link state change occurs. This plugin uses OvS DB to receive the link state change notification.

Design/Development Teams

OvS plugin main components

Since more than one OvS plugin is going to be developed, it was decided to split the plugin implementation into two main components:

OvS plugin

• This component implements the specific OvS plugin logic which uses OvS utils component to communicate with an OvS database.

OvS utils

• This component implements some part of the OvS DB transport communication specified by RFC7047 and provides API for OvS collectd plugins.

OvS utils module features:

• Connect/disconnect to/from OvS DB server;
• Recovery connection mechanism in case of OvS DB connection lost;
• Subscription mechanism to OvS DB table events like initial/insert/modify/delete table row;
• API to send custom JSON request to OvS DB server and receive the result (poll some table data, get table information etc.);
• Handling of “echo” request from OvS DB server to verify the liveness of the connection;
• Sending OvS DB connection lost notification.

OvS plugin interaction

The general overview of OvS plugin interaction with OvS database is described on figure 2.

Figure 2. OvS plugin interaction

OvS plugin/OvS utils internal architecture

Figure 3. OvS plugin/utils internal architecture

The Poll worker thread listens for incoming OVS DB raw data, parses and validate the JSON data (using JSON reader component) and takes care of calling corresponding handlers. If the OVS DB connection is lost the poll worker will send an event to event worker and try to establish the connection again (repeating in 1 second intervals). Handled JSON requests (implementation based on RFC7047):

• ECHO request. OVS DB server sends this request periodically to verify the liveness of a database connection. When such request is received by pool worker, the “ECHO” handler is called and appropriate reply is send to the server.
• Update request. This request is sent by OVS DB server to the plugin to report changes in tables that are being monitored. Once such request is received by poll worker, the appropriate handler registered by plugin is called.

The Event worker thread listens for incoming events (like establish/loss OVS DB connection) from poll worker thread and invokes an appropriate plugin handler.

OvS DB multi-instance support

The OvS DB multi-instance support is covered by OvS utils API which allows any OvS plugin to open multiple TCP/UNIX connections to different OvS DB instances. The general overview of OvS multi-instance support is described on figure 4.

Figure 4 Multi-instance support

Please note that OvS utils doesn’t create any addition threads to handle multiple OvS DB connections. It uses same number of threads (two) for all OvS DB instances.

Third-party libraries

To implement JSON routine (parsing, generating JSON) specified in OvS management protocol the YAJL library (https://lloyd.github.io/yajl/) is used. This library is already integrated into collectd which makes the library easier to use in new OvS plugin.

Limitations

• No known limitation

OvS events plugin

The collectd OvS events plugin state diagram is described on figure 4. It uses OvS utils API (by default) subscribes to link status updates in OVS DB and to receive the interface status change event from OvS database. When connection to OvS database is lost, the proper collectd notification is generated by the plugin.

The  collectd OvS events plugin can also be used to poll the OvS interface link status as a statistic but this is not a default behaviour and not recommended from a performance perspective.

Figure 5 OvS events plugin state diagram

Plugin configuration

The following configuration options should be supported by ovs_events collectd plugin:  

Instance block configuration options:

Here is an example of the plugin configuration section of collectd.conf file:

LoadPlugin ovs_events     

<Plugin "ovs_events">

          <Instance default>

            Port 6640

            Address "127.0.0.1"

            Socket "/var/run/openvswitch/db.sock"

            Interfaces "br0" "veth0"

            DispatchValues false

          </Instance>

          SendNotification true

</Plugin>

Supported metrics and events

The ovs_events  plugin monitors the link status of Open vSwitch (OVS) connected interfaces, dispatches the values to collectd and sends the notification whenever the link state change occurs. This plugin uses OVS database to get a link state change notification. The ovs_events plugin should collect the following metrics and notifications:

Notifications:

SNMP support

The SNMP OVS interface link status is provided by standard IF-MIB (http://www.net-snmp.org/docs/mibs/IF-MIB.txt). Please note, that information about ports that are not supported by standard SNMP (e.g. like DPDK ports) aren’t available there.

OvS stats plugin

The plugin collects a statistics of OVS connected interfaces/ports/bridges. It uses OVS Utils API to get the statistics from OVS database. The internal OVS stats plugin state diagram is described on figure.

Figure 6 OvS stats plugin state diagram

Plugin configuration

The following configuration options should be supported by ovs_stats collectd plugin:  

Instance block configuration options:

Here is an example of the plugin configuration section of collectd.conf file:

LoadPlugin ovs_stats     

<Plugin "ovs_stats">

          <Instance default>

            Port 6640

             Address "127.0.0.1"

            Socket "/var/run/openvswitch/db.sock"

            Bridges "br0" "br_ext"

          </Instance>

</Plugin>

List of OVS statistics supported by the plugin

For dpdk ports in openvswitch v 2.6 and above extended statistics (RFC2819) is available:

SNMP Support

OvS stats plugin rely on standard Linux SNMP support, thus information about DPDK ports is not available.OvS multi instance support

The collectd OVS multi instance statistics support is achieved using ovs_pmd_stats application and collectd exec plugin. The interaction between those applications is described on Figure 7.

Figure 7 Collectd exec plugin/ovs_pmd_stats interaction

The collectd exec plugin forks off the ovs-pmd-stats application and reads all counters from its STDOUT (in specific format described in collectd exec plugin documentation). In turn, ovs_pmd_stats application connects to ovs-vswitch instance using bidirectional binary UNIX socket. After connection is established, JSON RPC message is sent that requests response to the OVS command “dpif-netdev/pmd-stats-show”. In case response message is not full or corrupted, it will be ignored and corresponding error reported. Otherwise, it will be parsed by ovs_pmd_stats application and each counter/value pair will be put to STDOUT in specific format suitable for collectd exec plugin.

One argument is required for ovs-pmd-stats application to get counters from ovs-vswitch:

• “--socket-pid-file” - The ovs-vswitchd.pid file location to connect to ovs-vswitch daemon.

ovs_pmd_stats application puts counters in the following formats depending to the OVS configuration:

• For non-core threads (main thread):
  PUTVAL <host-id>/ovs_pmd_stats-main_thread/counter-<counter-name> N:<counter-value>
• For pmd threads:
  PUTVAL <host-id>/ovs_pmd_stats-pmd_thread_numa_id_<numa-id>_core_id_<core-id>/counter-<counter-name> N:<counter-value>

Considerations

Configuration Considerations

Deployment Considerations

API/GUI/CLI Considerations

Equivalence Considerations

Security Considerations

Alarms, events, statistics considerations

Redundancy Considerations

Performance Considerations

Not part of Telemetry so performance is Not Applicable

Testing Consideration

For ovs_events, the timing interval requirement needs to be taken into consideration when conducting tests.

The Tests should be carried out on a system underload as well as a relatively idle system.

Other Considerations
ovs-vswitchd.pid.ctl unix socket file can be used to monitor vswitch liveliness, killing ovs-vswitchd process removes “ovs-vswitchd.pid.ctl” from “/usr/local/var/run/openvswitch” directory.

If a bridge with an interface is created and traffic run through it, after killing the switch no changes were detected in traffic flow and the bridge is still present.
(Not applicable to OvS with DPDK, when flow times out it will no longer be functional)

Impact

The following table outlines possible impact(s) the deployment of this deliverable may have on the current system.

Key Assumptions

The following assumptions apply to the scope specified in this document.

Key Exclusions

The following exclusions apply to the scope discussed in this document.

Key Dependencies

The following table outlines the key dependencies associated with this deliverable.