DOCSEARCHbyAlgolia
Submit Docs

Open vSwitch (OVS) Documentation

repository·main·Indexed 26 days ago

https://github.com/openvswitch/ovs

Documentation for Open vSwitch, a high-performance multi-database virtual switch. Covers configuration of tunnel ports (Bareudp, GRE, GTP-U, SRv6), port mirroring (SPAN, RSPAN, ERSPAN), and bridge management. Includes guides for DPDK integration, Debian networking stack configuration via /etc/network/interfaces, and developer instructions for implementing new OpenFlow messages, actions, and flow fields.

Tokens
100K
Snippets
193
Records
580
Agent score
88%

What's inside Open vSwitch

  1. Overview of Open vSwitch components

    main

    Open vSwitch (OVS) consists of several core components for implementing a multilayer software switch:

    • ovs-vswitchd: The main daemon that implements the switch logic, typically used with a Linux kernel module for flow-based switching.
    • ovsdb-server: A lightweight database server used by ovs-vswitchd to retrieve configuration.
    • ovs-vsctl: A utility for querying and updating the configuration of ovs-vswitchd.
    • ovs-appctl: A utility for sending commands to running Open vSwitch daemons.
    • ovs-dpctl: A tool for configuring the switch kernel module.
    • ovs-ofctl: A utility for querying and controlling OpenFlow switches and controllers.
    • ovs-pki: A utility for managing the public-key infrastructure for OpenFlow switches.
    • ovs-testcontroller: A simple OpenFlow controller intended for testing purposes (not for production).

  3. Overview of OVSDB (Open vSwitch Database)

    main

    OVSDB is a network-accessible database system used for state synchronization. It uses a JSON-RPC based protocol (specified in RFC 7047) to allow clients to monitor database contents. When monitored portions of the database change, the server notifies the client of added, modified, or deleted rows.

    Key components in Open vSwitch include:

    • ovsdb-server(1): The OVSDB server implementation.
    • ovsdb-client(1): A basic command-line OVSDB client.
    • Client libraries: Available for C and Python.
    • ovsdb-tool(1): A utility for working with on-disk database formats and inspecting transactions.
    • ovs-vsctl: A tool specifically for the ovs-vswitchd configuration database.
    • vtep-ctl: A tool specifically for the VTEP database.

  4. Configure Bond Packet Input and Output behavior

    main

    Open vSwitch bonding allows multiple interfaces (members) to act as a single logical port, increasing bandwidth and robustness.

    Input Behavior

    • Unicast: Accepted on any member. Note that packet duplication may occur briefly if the physical switch has not yet learned the correct member for a MAC.
    • Multicast/Broadcast: Only accepted on a single "active member" at a time. Packets received on other members are dropped to prevent duplication.
    • MAC Learning: Packets are dropped if the vswitch has learned that the packet's MAC is on a port other than the bond itself. An exception is made for broadcast ARP replies (often seen during VM migration).

    Output Behavior

    • Member Selection: The specific member used for a packet is determined by hashing the packet's source MAC and VLAN tag into one of 256 values. This value is looked up in the bond_hash table.
    • Rebalancing: Every 10 seconds, vswitchd performs a rebalance (bond_rebalance()). It shifts hashes from a highly loaded member (H) to a least-loaded member (L) if:
      1. H carries at least 1 Mbps more traffic than L.
      2. H's traffic is at least 3% greater than L's.
      3. The shift decreases the load ratio between H and L by at least 0.1.
      4. H carries at least two hashes.

  5. Compare vhost-user and vhost-user-client port types

    main

    Open vSwitch supports two DPDK vHost User port types:

    1. vhost-user (dpdkvhostuser): OVS acts as the server and QEMU acts as the client. If OVS dies, all VMs must be restarted. This type is deprecated and will be removed in a future release. Requires QEMU >= 2.2.
    2. vhost-user-client (dpdkvhostuserclient): OVS acts as the client and QEMU acts as the server. OVS can be restarted without affecting VMs, and instances can be restarted independently. This is the preferred type for all known use cases. Requires QEMU >= 2.7.

  6. Understand the Open vSwitch Datapath Architecture

    main

    The Open vSwitch kernel module provides userspace control over packet processing on network devices. It uses a datapath model where:

    • Datapaths: Analogous to bridges.
    • vports: Analogous to ports within a bridge.
    • Flow Tables: Associated with each datapath, containing flows that map packet header keys (and metadata) to specific actions (e.g., forwarding to another vport).

    Packet Processing Flow:

    1. A packet arrives on a vport.
    2. The kernel extracts a flow key and looks it up in the flow table.
    3. If a match is found, the associated actions are executed in-kernel.
    4. If no match is found, the packet is queued to userspace for processing. Userspace typically then installs a new flow in the kernel to handle subsequent packets of that type.

  7. Scale OVSDB access using Relay mode

    main

    OVSDB Relay mode allows you to scale database access for large deployments (like OVN) by using a 2-tier architecture. A relay server connects to a primary database (the relay source), maintains an in-memory copy of the data, and handles read-only requests locally. Write transactions are forwarded to the source. This reduces the connection load and transaction latency on the main clustered database.

    In a 2-tier deployment:

    1. Main Cluster: A standalone or clustered ovsdb-server acting as the source.
    2. Relay Tier: Multiple ovsdb-server instances configured in relay mode.
    3. Clients: Clients (e.g., ovn-controller) connect to the relay servers instead of the main cluster.

  8. Identify supported virtualization platforms for Open vSwitch

    main

    Open vSwitch can run on any Linux-based virtualization platform using kernel 3.10 or newer. Supported platforms include:

    • KVM
    • VirtualBox

    Since Linux 3.3, Open vSwitch has been part of the mainline kernel. While the Linux kernel module provides the highest performance, a userspace datapath is available for increased portability across different operating systems.

  9. Understand the limitations of hybrid provider approaches

    main

    Open vSwitch does not support a hybrid approach between ofproto providers (which leverage hardware TCAM) and dpif providers (which leverage OVS built-in software features).

    Attempting a hybrid approach is discouraged because:

    1. Performance Unpredictability: Users may experience massive slowdowns if a feature (like a specific OpenFlow action) is not supported in hardware and falls back to the slow management CPU in software.
    2. Feature Inconsistency: Software-implemented flows are only efficient for low-volume traffic, but many OVS features (like bonding or 802.1Q VLAN support) are needed for all traffic types.
    3. Traffic Bottlenecks: Forcing packets to software for matching (e.g., matching on IPv6 headers when hardware only supports IPv6 Ethernet type) can slow down all related traffic, not just the specific flows being matched in software.

  10. Understand Open vSwitch Performance (Fast Path vs. Slow Path)

    main

    Open vSwitch performance relies on keeping packets in the fast path (the datapath) and avoiding the slow path (ovs-vswitchd).

    • Slow Path: Processes OpenFlow logic to determine actions. This is required for protocols like STP, LLDP, or any flow that modifies ARP fields.
    • Fast Path (Datapath): Uses a multi-level cache to execute actions directly.
      • Microflow Cache: High-performance cache for long-lived, high-rate flows (common in DPDK).
      • Megaflow Cache: Key for performance; caches flows based on a subset of fields.

    Optimization Tip: To maximize performance, avoid overly specific megaflow entries. If a megaflow matches too many specific fields (like L2/L3/L4 combined), it will only match a single connection, forcing more packets into the slow path. Use ofproto/trace to inspect the Megaflow output and see which fields are being matched to ensure the cache is as broad as possible.

  11. Use ovs-flowviz to visualize OpenFlow and datapath flows

    main
    The ovs-flowviz utility helps visualize OpenFlow and datapath flow dumps in various formats (console, JSON, HTML, etc.) to make them easier to understand. It can read flows from stdin or from files specified via the --input option. You can apply filters to show only specific flows or use --highlight to emphasize certain flows.

  12. Identify if a bug is a security vulnerability

    main

    A vulnerability is a bug that compromises one or more of the following:

    • Confidentiality: Unauthorized access to personal or corporate confidential data (e.g., an OpenFlow protocol bug allowing a controller to read arbitrary files).
    • Integrity: Compromising the trustworthiness or correctness of the system (e.g., a flow translation bug that misforwards traffic across security boundaries, or memory corruption allowing modification of OVS behavior via OVSDB).
    • Availability: Compromising uptime or service (e.g., a crafted packet causing a kernel or userspace crash).

    If you are unsure whether a bug is a vulnerability, use the vulnerability management process. At worst, it will be handled through standard bug reporting channels.