Understanding Open vSwitch: Concepts, Installation, and Architecture
This article introduces Open vSwitch, compares it with Linux Bridge, details its features, provides step‑by‑step installation on CentOS 7, explains its architecture and packet‑forwarding process, and clarifies key components and terminology for building virtual networking in cloud environments.
What Is Open vSwitch?
Open vSwitch (OVS) is a high‑quality, multi‑layer virtual switch released under the Apache 2.0 license. It is designed for large‑scale network automation with programmable extensions and supports standard management interfaces and protocols such as NetFlow, sFlow, IPFIX, RSPAN, CLI, LACP, 802.1ag, OpenFlow, GRE, VXLAN, and LISP.
Standard 802.1Q VLAN model
LACP automatic and manual link aggregation
NetFlow, sFlow, and port mirroring
QoS configuration and policies
GRE, GRE over IPSEC, VXLAN, and LISP tunneling
802.1ag connectivity fault management
OpenFlow and extensions
C and Python bindings for a transactional configuration database
High‑performance forwarding based on Linux kernel modules
Linux Bridge vs. Open vSwitch
Linux Bridge is a virtual network device that also functions as a simple L2 switch. Its packet‑processing workflow is:
Record source MAC address and input port when a packet arrives.
Lookup destination MAC in the local cache; if found, forward to the associated port.
If no entry exists, drop the packet.
If a matching port is found, forward the packet out that port.
If the MAC is unknown, broadcast within the subnet.
While Linux Bridge is sufficient for basic virtual networking, Open vSwitch offers several advantages:
Convenient network management and monitoring (including third‑party monitoring tools).
Faster packet forwarding via flow caching, reducing reliance on pure MAC‑learning.
Native support for the OpenFlow protocol, enabling SDN control‑plane separation.
Installing Open vSwitch on CentOS 7
Download the source package, build an RPM, and install it:
# Install dependencies
yum -y install make gcc openssl-devel autoconf automake rpm-build redhat-rpm-config python-devel kernel-devel libtool wget
# Build from source
mkdir -p ~/rpmbuild/SOURCES
wget http://openvswitch.org/releases/openvswitch-2.5.0.tar.gz
cp openvswitch-2.5.0.tar.gz ~/rpmbuild/SOURCES/
tar xfz openvswitch-2.5.0.tar.gz
sed 's/openvswitch-kmod, //g' openvswitch-2.5.0/rhel/openvswitch.spec > openvswitch-2.5.0/rhel/openvswitch_no_kmod.spec
rpmbuild -bb --nocheck ~/openvswitch-2.5.0/rhel/openvswitch_no_kmod.spec
yum localinstall -y ~/rpmbuild/RPMS/x86_64/openvswitch-2.5.0-1.x86_64.rpm
# Start the service
systemctl start openvswitch.serviceOVS Architecture and Forwarding Process
The overall architecture consists of user‑space components (ovsdb‑server, ovs‑vswitchd) and a kernel‑space datapath module. A controller (e.g., RYU, ODL) connects via OpenFlow.
Key components:
datapath : Kernel module that matches packets against flow tables and executes actions directly in kernel space.
vswitchd : User‑space daemon that communicates with the controller (OpenFlow) and the datapath via netlink.
ovsdb : Central configuration database.
ovsdb‑tool / ovsdb‑client : Command‑line utilities for managing the database.
ovs‑vsctl : High‑level configuration tool.
ovs‑appctl : Direct interaction with vswitchd.
ovs‑fpctl : Inspect and control OpenFlow flow tables.
ovs‑dpctl : Directly configure the datapath.
Packet forwarding proceeds as follows: the datapath receives a packet, checks the kernel‑space flow table, and if a match exists, forwards according to the associated action. If no match is found, the packet triggers an upcall to vswitchd, which may forward it to the controller via OpenFlow. The controller decides the forwarding port (or floods) and installs a new flow entry in both the datapath and ovsdb for future packets.
Key Terminology
Bridge : An Ethernet switch; a host can have multiple bridge devices.
Port : Analogous to a physical switch port; each belongs to a bridge.
Interface : Network interface attached to a port; one‑to‑one unless the port is in bond mode.
Controller : OpenFlow controller managing OVS.
datapath : Executes packet switching in kernel space.
Flow table : Stores flow entries used by the datapath for matching.
miss table : Low‑priority table that matches all packets and forwards them to the controller when no other match is found.
user space : Execution context for user‑level processes.
kernel space : Execution context for privileged kernel code.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Cloud Native Technology Community
The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
