Understanding Open vSwitch: Part 1
Welcome to the first phase of our Open vSwitch (OVS) journey! This post takes a closer look at a single bridge handling two VLANs, both with a common VLAN tag.
Open vSwitch (OVS) is an open-source, multilayer virtual switch designed to enable efficient networking within virtualized environments. It was initially developed by Nicira Networks and later became a collaborative project within the open-source community. OVS gained prominence due to its flexibility, scalability, and robust features, making it a popular choice for managing network connections in virtualized infrastructures.
The history of OVS dates back to its first release in 2009, and it has since evolved through contributions from a diverse community of developers. Its adoption has been widespread in various virtualization and cloud computing platforms.
One notable integration is with the OVN-Kubernetes plugin. OVN (Open Virtual Network) is a virtual networking subsystem that builds on OVS to provide additional features like logical switches, routers, and security groups. The OVN-Kubernetes plugin leverages OVS and OVN to enhance networking capabilities within Kubernetes clusters. This integration is crucial for orchestrating communication between containers and ensuring efficient networking in dynamic and scalable containerized environments.
The OVN-Kubernetes plugin extends the capabilities of OVS to provide network virtualization services in Kubernetes clusters, allowing for better isolation, scalability, and management of networking resources. This integration is especially significant in the context of containerized applications, where dynamic scaling and efficient networking are essential for the success of platforms like OpenShift and Kubernetes.
Open vSwitch (OVS) operates at the Data Link Layer (Layer 2) of the OSI model, making it a crucial component for managing Ethernet frames within virtualized environments. Here’s an explanation of how OVS operates at the L2 level and how it extends network segments:
Switching and Forwarding:
- OVS functions as a virtual switch, much like a physical Ethernet switch.
- It examines the MAC addresses in incoming Ethernet frames and uses a MAC address table to make forwarding decisions.
MAC Address Learning:
- OVS employs MAC address learning to build and maintain a table that maps MAC addresses to specific switch ports.
- When a frame arrives, OVS records the source MAC address and the port through which the frame entered.
Broadcast and Multicast Handling:
- OVS handles broadcast and multicast frames, ensuring they are forwarded only to the relevant ports, minimizing unnecessary network traffic.
Bridging and Bridging Domains:
- OVS creates bridges that act as virtual switches connecting multiple ports.
- Each bridge represents a bridging domain, allowing devices connected to different ports to be part of the same logical network.
VLAN Tagging:
- OVS supports VLAN tagging, allowing the segmentation of a physical network into multiple logical networks (VLANs).
- This feature enhances network isolation and security, as traffic from different VLANs does not interfere with each other.
Tunneling:
- OVS can be configured to create tunnels between switches, enabling the extension of network segments across different physical locations or virtualized environments.
- Common tunneling protocols used with OVS include VXLAN and GRE.
Lab Setup
In this tutorial we will be using an Ubuntu host with Virtualbox installed. First of all, we need to install the necessary packages to use open vswitch.
sudo apt-get update
sudo apt-get install openvswitch-switchNow we can confirm that open vswitch is up and running with the following command:
> sudo ovs-vsctl show
2754d6a1-4c15-4a41-bb9e-185bd0cf18a1
Bridge br-int
fail_mode: secure
datapath_type: system
Port br-int
Interface br-int
type: internal
ovs_version: "2.17.7"Here we see that OVS has already added a default bridge which is used for internal network of OVS.
Also we can list the network interfaces to see that ovs has created two interface, “br-int” and “ovs-system”.
> ip link show
4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 7a:77:b8:37:bb:e9 brd ff:ff:ff:ff:ff:ff
8: br-int: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 96:bd:cc:37:a8:b8 brd ff:ff:ff:ff:ff:ffNow we will create the components to explore ovs capabilities.
Create an OVS bridge:
We use the following commands to create an ovs bridge (br0), confirm it and the related network interface (br0).
> sudo ovs-vsctl add-br br0
> sudo ovs-vsctl show
ozcan@lenovo:~$ sudo ovs-vsctl show
2754d6a1-4c15-4a41-bb9e-185bd0cf18a1
Bridge br0
Port br0
Interface br0
type: internal
Bridge br-int
fail_mode: secure
datapath_type: system
Port br-int
Interface br-int
type: internal
ovs_version: "2.17.7"
> ip link show
4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 7a:77:b8:37:bb:e9 brd ff:ff:ff:ff:ff:ff
8: br-int: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 96:bd:cc:37:a8:b8 brd ff:ff:ff:ff:ff:ff
20: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 5a:a4:45:af:da:49 brd ff:ff:ff:ff:ff:ff
Now we need two OVS switch port to represent our physical networks. Use the following commands to create ports and add VLAN tags. Here we give “tag=10” to both ports so that the hosts in these interfaces can communicate with default settings.
> sudo ovs-vsctl add-port br0 eth1 tag=10 -- set interface eth1 type=internal
> sudo ovs-vsctl add-port br0 eth2 tag=10 -- set interface eth2 type=internalNow if we list the OVS components again, we see the details of the ports we created, and we can list the network interfaces to see that two new interfaces have been created. You should set the new interfaces as up (see the commands below).
> sudo ovs-vsctl show
2754d6a1-4c15-4a41-bb9e-185bd0cf18a1
Bridge br0
Port br0
Interface br0
type: internal
Port eth1
tag: 10
Interface eth1
type: internal
Port eth2
tag: 10
Interface eth2
type: internal
Bridge br-int
fail_mode: secure
datapath_type: system
Port br-int
Interface br-int
type: internal
ovs_version: "2.17.7"
> sudo ip link set dev eth1 up
> sudo ip link set dev eth2 up
> ip link show
4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 7a:77:b8:37:bb:e9 brd ff:ff:ff:ff:ff:ff
8: br-int: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 96:bd:cc:37:a8:b8 brd ff:ff:ff:ff:ff:ff
20: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 5a:a4:45:af:da:49 brd ff:ff:ff:ff:ff:ff
23: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether ea:4c:ca:87:95:49 brd ff:ff:ff:ff:ff:ff
24: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 32:67:7a:63:0d:8e brd ff:ff:ff:ff:ff:ffNow create two virtual machines on Virtualbox. To establish two virtual machines on VirtualBox, employ an Ubuntu Server image for their instantiation. In the network settings, opt for the “Bridged Adapter” configuration and select “Paravirtualized Network (virtio-net)” as the Adapter Type. This specific adapter type, namely virtio-net, facilitates the utilization of advanced features such as VLAN tagging. The selection of “Bridged Adapter” ensures that the virtual machines are connected directly to the host’s physical network, allowing them to operate as individual entities within the broader network infrastructure. This configuration enhances network flexibility and supports the implementation of VLANs for improved network segmentation and management.
Now add ip addresses to the network interfaces in virtual machines (we do not add any ip addresses to network interfaces on the host machine).
# On VM1 (test1)
sudo ip addr add 192.168.1.10/24 dev enp0s3
# On VM2 (test2)
sudo ip addr add 192.168.1.20/24 dev enp0s3Confirm if the new ip numbers are added with the following command. You should see the ip address listed:
# On VM1 (test1), repeat for VM2
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:4d:b2:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global enp0s3
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe4d:b2f6/64 scope link
valid_lft forever preferred_lft foreverThis completes our setup. Now let’s examine the components and OVS bridge details.
How it works?
In the absence of an Open vSwitch (OVS) setup, default virtual machine communication on different network interfaces (e.g., eth1 and eth2) is hindered, regardless of the assigned IP addresses. When attempting communication from one virtual machine (e.g., VM1) to another (e.g., VM2), the destination host’s MAC address must be known for proper packet forwarding. OVS bridges address this by maintaining records of MAC addresses associated with the ports they manage.
The command sudo ovs-appctl fdb/show br0 reveals details, including MAC addresses and associated ports, aiding in the identification of VMs.
sudo ovs-appctl fdb/show br0
port VLAN MAC Age
4 10 08:00:27:92:62:0a 0
3 10 08:00:27:4d:b2:f6 0For instance, “08:00:27:4d:b2:f6” corresponds to VM1 (test1), while “08:00:27:92:62:0a” belongs to VM2 (test2), as confirmed with the “ip a” command on the virtual machines. To facilitate inter-VM communication, OVS bridges employ VLAN tagging on bridge ports, indicating the VLAN tag associated with each port. This enables the bridge to scrutinize destination host MAC addresses and efficiently forward packets based on VLAN information, ensuring accurate communication between virtual machines on the specified VLAN.
VLAN Tags
Virtual LANs (VLANs) are a networking technology that enables the segmentation of a single physical network into multiple logical networks, providing enhanced network isolation and security. The IEEE 802.1Q standard defines the VLAN tagging protocol, which adds a 4-byte VLAN tag to the Ethernet frame header. This tag includes information such as the VLAN ID, which identifies the specific VLAN to which the frame belongs. VLAN tagging allows network administrators to logically partition a network, isolating broadcast domains and enhancing network scalability. In a data frame, the VLAN tag is inserted into the Ethernet frame between the Source MAC Address and EtherType fields. It plays a crucial role in facilitating the distinction and proper routing of traffic between different VLANs within a network, contributing to efficient network management and improved security by creating distinct broadcast domains within a shared physical infrastructure.
In our case, when a package is received by the OVS bridge, it adds a VLAN tag to the package and forwards to the router, and when router forwards to package to the OVS bridge again, it strips that tag and forward package to the destination port. That’s why this tag is not visible on our VLANs “eth1” and “eth2”. We can confirm that using wireshark.
First let’s start a web server on vm2 using python3.
> python3 -m http.server --bind 192.168.1.20 8443Now we can send a request to vm2 from vm1 using curl command and start watching the traffic using wireshark.
curl --interface enp0s3 -vkL http://192.168.1.20 8443As you can see in the screenshot below, the ethernet frame does not have a 802.1Q field.
In conclusion, we’ve explored the fundamental role of Open vSwitch (OVS) in enabling communication between virtual machines (VMs) on different network interfaces. OVS bridges, with their MAC address learning and VLAN tagging capabilities, enhance network isolation and facilitate efficient packet forwarding. In upcoming posts, we’ll delve deeper into OVS’s capabilities, examining scenarios involving multiple VLANs within a single bridge and controlling flows between them. Additionally, we’ll explore the configuration of two bridges with VLANs sharing the same tag, showcasing OVS’s versatility in managing complex network architectures. Stay tuned for further insights into maximizing the potential of Open vSwitch in virtualized environments.
