Virtual Network Architecture with Open vSwitch

Introduction

In virtualization infrastructures, Virtual Machines (VMs) and Containers require a Virtual Network Layer to communicate with the outside world. In the past, many environments used simple Linux Bridges, but with growing needs, a simple bridge is no longer sufficient for all scenarios.

Cases such as:

• VLAN
• Trunk
• Network Isolation
• Connection to a Virtual Firewall
• Bandwidth Control
• Port Security
• Connection of multiple virtual networks to a physical network
• Centralized Management of VM and Container Traffic

Drive us towards Open vSwitch, or OVS for short.

📌 Goal of this Document

This document does not intend to teach via GUI or Command-Line. The main goal is for you to learn the Architecture.

After studying this document, you will know the answers to the following questions:

• What is OVS?
• Why is it used?
• What does a virtual switch create?
• What is a Switch Profile?
• What is an Access Profile?
• What is a Trunk Profile?
• Where are VLANs applied?
• Where should the IP address be placed?
• When the server's physical port is connected to a physical switch, what is the correct architecture?
• When the physical port is a Trunk, what should we do?
• When we have a virtual pfSense, what does the architecture look like?
• How is LACP designed?
• When there is a direct connection to a firewall, what is the standard design?

What is OVS?

Open vSwitch, or OVS, is a software-based virtual switch. This switch operates at Layer 2 of the OSI Model and can manage traffic between VMs, containers, and the physical network.

💡 In Simple Terms

OVS is like a network switch, but instead of being a physical device, it runs inside the hypervisor/server.

This switch can perform tasks similar to physical switches:

• Creating multiple virtual ports
• Connecting VMs to each other
• Connecting VMs to the physical network
• Applying VLANs
• Creating Access ports
• Creating Trunk ports
• Bandwidth control
• Isolating networks
• Connecting to a virtual firewall
• Creating internal networks separate from the corporate network

Why Migrate from a Normal Bridge to OVS?

A simple bridge is suitable for initial scenarios, but when infrastructure grows larger, its limitations become apparent.

Feature	Standard Bridge	OVS
Simple network without VLAN	✅	✅
Multiple simple VMs	✅	✅
Multiple VLANs	❌	✅
Trunk between server and physical switch	❌	✅
Connection to Virtual Firewall (pfSense)	❌	✅
Separation of Management, VM, and DMZ networks	❌	✅
Bandwidth Control	❌	✅
Scalable Architecture	❌	✅
Precise coordination with physical network	❌	✅

📝 Note

When infrastructure moves toward standardization, using OVS becomes more logical.

What is a Virtual Switch?

⚠️ Very Important Concept

When creating a virtual switch in OVS, you have essentially built a Virtual Switching Fabric. This switch by itself does not yet have complete network behavior.

Merely building the switch does not mean having VLAN, IP, Trunk, or Access capabilities.

A virtual switch is like a switch chassis or body. To determine network behavior, you must define Profiles and Ports on this switch.

ℹ️ Info

Creating a virtual switch only creates the Infrastructure. It is the Profiles that define the behavior of each port.

What is an OVS Profile?

A Profile is essentially a configuration template for a port. When connecting a physical NIC, a VM, or a container to a virtual switch, you must specify the characteristics of this connection. We call this set of characteristics a Profile:

• Should this port be Access or Trunk?
• Which VLAN is it a member of?
• Which VLANs should it pass through?
• What is its Native VLAN?
• Are there bandwidth limitations?
• Is it for Management or Data?
• Which part of the physical network is it connected to?

Main Components of OVS Architecture

Virtual Switch

The virtual switch is the Central Connection Point. You may have multiple virtual switches for different uses:

• Virtual switch for the main VM network
• Virtual switch for Management network
• Virtual switch for DMZ
• Virtual switch for Firewall WAN
• Virtual switch for Firewall LAN
• Virtual switch for isolated test network

Physical Port (Uplink)

The server's physical port acts as a Bridge between the virtual world inside the server and the physical network.

If the server has two network cards:

• First NIC: Might be for Server Management.
• Second NIC: Might be for connecting VMs and containers to the physical network.

We usually refer to the physical port connected to the outside network as the Uplink.

Virtual Port

Every VM or container has a virtual network card. This virtual network card must connect to a Profile on the OVS switch:

• Web Server VM port
• Database VM port
• App Container port
• pfSense Firewall LAN port
• pfSense Firewall WAN port

Internal Profile

Sometimes the hypervisor itself needs to have an IP in a specific VLAN or network (e.g., for Backup, Monitoring, or corporate services).

🔴 Danger

In this state, you should not place the IP directly on the physical network card. It is better to build an Internal Profile on OVS and place the Server IP on that Internal Profile.

Access Profile

The Access Profile is used for devices that should not see VLAN Tags:

• Regular Virtual Machine
• Regular Container
• A service that must only exist in a specific VLAN

In Access Profile:

• Incoming traffic from the VM is Untagged.
• OVS assigns it to the specified VLAN.
• When traffic returns from the network, OVS strips the tag, and the untagged frame reaches the VM.

💡 Tip

Summary: Access Profile is used on the End Device side.

Trunk Profile

The Trunk Profile is used for passing multiple VLANs. This mode is usually between:

• Hypervisor and Physical Switch
• Hypervisor and Firewall
• Virtual Switch and Virtual Router
• Virtual Firewall and different Networks

In Trunk Profile:

• Frames usually pass with VLAN Tags.
• You can specify which VLANs are allowed to pass.
• You can define one VLAN as Native (Untagged).

What is a VLAN and Why is it Important in OVS?

VLAN means dividing a physical network into multiple logical networks. It is a virtual network logically separated from others.

For example, a physical network might have these VLANs:

VLAN	Usage
VLAN 10	Users
VLAN 20	Servers
VLAN 30	Management
VLAN 40	DMZ
VLAN 50	Guest

When the hypervisor connects to the physical network, it must behave exactly according to those VLANs.

🔴 If VLAN is misconfigured

• Traffic goes to the wrong network.
• Traffic might get Dropped.
• An incorrect Broadcast Domain might be created.
• Network security could be compromised.
• The VM might get the wrong IP or go to the wrong gateway.

The Concept of Access and Trunk in Real Architecture

Access

This is a port where usually an End Device is connected. A port is used for only one VLAN, and the device behind it typically does not see the VLAN tag.

Trunk

A port can pass traffic from multiple VLANs and usually preserves the VLAN tag.

💡 Advantage of Trunk

Instead of running a separate cable for every VLAN between two switches, you make one cable a Trunk. Consequently, that single cable can carry traffic for VLAN 10, VLAN 20, and VLAN 30.

What is a VLAN Tag?

When a frame passes through a Trunk, the switch usually adds a VLAN Tag to indicate which VLAN the frame belongs to. The common standard for this is 802.1Q.

Concept	Description
Access	This port belongs to one VLAN.
Trunk	This port can pass multiple VLANs.
Tag	Specifies which VLAN a frame moving on the Trunk belongs to.

Naming Standards

⚠️ Warning

One of the most important parts of standardization is Correct Naming. If you don't have standardized naming, after a while you won't know what each profile is for.

Virtual Switch Naming

Suggested Name	Usage
ovs-edge	Switch connected to external network
ovs-lan	Internal switch for VMs
ovs-dmz	Switch for DMZ services
ovs-mgmt	Management switch
ovs-fw-wan	Switch on WAN side of Firewall
ovs-fw-lan	Switch on LAN side of Firewall
ovs-isolated	Isolated switch without external access

Profile Naming

Suggested Name	Usage
uplink-phys-trunk-vlan20	Physical port profile as Trunk for VLAN 20
uplink-phys-access-vlan10	Physical port profile as Access for VLAN 10
vm-web-access-vlan20	Web VM profile in VLAN 20
ct-app-access-vlan20	Application Container profile in VLAN 20
fw-wan-vlan20	Firewall WAN profile in VLAN 20
fw-lan-private	Internal LAN profile for Firewall
mgmt-internal-vlan30	Internal profile for Server Management in VLAN 30

Golden Rules of OVS Standardization

🔒 Security

Before entering scenarios, definitely follow these principles.

Rule 1: Architecture First, Connection Later

Before creating any profile, you must know:

• Where is this traffic supposed to go?
• What is its VLAN?
• Where is the Gateway?
• Is a Firewall needed?
• Should this network be Isolated?
• Is the physical network Trunked or Accessed?
• What IP Range is being used?

Rule 2: Every Logical Network Must Have a Defined Identity

Every VLAN or Zone must have the following:

• VLAN ID
• Subnet
• Gateway
• Usage/Purpose
• Access Level
• Technical Owner
• Security Restrictions

Rule 3: Do Not Assign IP Directly to Physical Ports

🔴 Danger

When a physical port enters OVS, it is better not to have a direct IP. If the server itself needs an IP, the IP should be placed on an Internal Profile.

Rule 4: Access for Endpoints, Trunk for Network Links

Connection Target	Suggested Mode
VMs and Containers	Access
Link to Physical Switch	Access or Trunk (depending on physical port type)
Link to Virtual Firewall	Access or Trunk (mostly Access)
Link between Virtual Switches/Routers	Usually Trunk

Rule 5: Allow Only the Minimum Necessary VLANs

🔒 Security

If only VLAN 20 is needed, do not open all VLANs on the Trunk. This is both a security measure and prevents network errors.

If you leave the VLAN Tag field empty when creating a Trunk profile, traffic from ALL VLANs will be allowed through.

Rule 6: Native VLAN Must Be Specific and Controlled

If using Trunk, definitely know what the Native VLAN is. If Native VLAN is misconfigured, untagged traffic might enter the wrong VLAN.

Rule 7: IP Belongs to Layer 3, OVS is Inherently Layer 2

ℹ️ Info

OVS alone is a Layer 2 switch. If you need routing between VLANs, there must be a router or firewall like pfSense in the path.

Standard OVS Setup Process

In any virtualization environment, regardless of the panel used, the general process is almost identical.

Step 1: Identify the Physical Network Card

First, identify which server NIC is connected to the physical network:

• First NIC: Server Management
• Second NIC: Connecting VMs and containers to the physical network

📝 Note

From here onwards, we assume the Second NIC is intended to connect to the physical network via OVS.

Step 2: Create a Virtual Switch

Create a virtual switch. This switch acts as an internal switch inside the server.

⚠️ Warning

Choose its name according to Naming Standards, not arbitrarily. At this stage, no VLAN, Trunk, or Access has been defined yet. Just an Empty Switch has been created.

Step 3: Create Profile for Physical Network Card

Now specify how the server's physical NIC connects to the physical network. In this profile, specify:

• Port Type: Physical
• Mode: Access or Trunk
• Allowed VLAN(s)
• Bandwidth limits (if needed)
• Descriptions

Step 4: Create Profile for VMs or Containers

For each VM or container, create a profile connected to the same virtual switch. In this profile, specify:

• Port Type: Virtual
• Mode: Access or Trunk
• Desired VLAN
• Bandwidth limit
• Descriptions

Step 5: Connect Profile to VM or Container

Connect the created profile to the VM's or container's NIC. From this moment, that VM/container's traffic enters the network according to the profile's rules.

Step 6: Configure IP Inside VM or Container

If the physical network has DHCP, the VM or container can get an IP. If not, manual IP configuration is required:

• IP Address
• Subnet Mask
• Gateway
• DNS

💡 Tip

In case of using Containers, pfSense or Ubuntu should be set up as a DHCP Server, and the Uplink profile should be configured as the WAN NIC on it.

Scenario 1: Physical Switch Port is Access

Scenario Description

We have a hypervisor server. The second port of this server is connected with a cable to one of the physical switch's ports. The physical switch port is configured in Access mode.

ℹ️ Message from Network Engineers

This port is Access. It is VLAN 20. Any device connected to this port enters VLAN 20.

Scenario Logic

When the physical switch port is Access, the switch expects the connected device to send traffic without tags.

Frames entering the switch from the server port are automatically considered members of VLAN 20, because that specific port on the switch is assigned to VLAN 20.

⚠️ Warning

VLAN is determined by the Access port on the switch, not by the container.

Therefore, the hypervisor server must not send a VLAN tag to the physical switch. In this case, the server's physical port profile must be defined as Access.

Required Profiles

Physical Uplink Profile:

This profile connects OVS to the physical switch!

Feature	Suggested Value
Profile Name	uplink-phys-access-vlan20
Port Type	Physical
Connected To	Server's Second NIC
OVS Switch	Internal-Switch
Mode	Access
VLAN	20
Description	Connection to physical switch Access port

VM or Container Profile:

Feature	Suggested Value
Profile Name	vm-access-vlan20
Port Type	Virtual
Connected To	VM or Container NIC
OVS Switch	Internal-Switch
Mode	Access
VLAN	20
Description	Connecting VM to physical VLAN 20

Why Do We Need Two Profiles?

For better understanding, consider OVS like a real physical switch.

💡 Analogy with Physical Switch

Assume you have a physical switch and want to connect it to another switch. You run a network cable from one of your switch's ports to the destination switch. That port plays the role of Uplink.

Now assume you want to connect a computer to the switch. This port is not an Uplink; it is a port where an End Device is connected.

Consider the physical structure :

Connection between two switches = Uplink

Connection from server to switch = End Device

In OVS, exactly the same concept exists:

1. Uplink Profile: Connects OVS to the server's second NIC and creates a communication path with the physical network switch.
2. End Device Profile: Connects VMs and containers to OVS.

Traffic Flow

When VM sends traffic:

1. VM sends an Untagged frame.

2. OVS places it in VLAN 20.

3. The frame exits the server's physical port Untagged.

4. The physical switch accepts it as VLAN 20.

ℹ️ Info

When a Frame enters OVS, it receives the tag corresponding to VLAN 20 within the OVS environment. When it is supposed to exit from an Access port, the switch logic removes the VLAN tag so the frame leaves the port as Untagged. Exactly the same logic that exists in a real switch.

When traffic returns from the network:

1. Physical switch sends the frame in VLAN 20.
2. Untagged frame enters the server's physical port.
3. OVS delivers it to the VM port in VLAN 20.
4. VM receives the untagged frame.

If the Server itself also needed an IP

🔴 Danger

If the hypervisor server itself must be managed in VLAN 20, you should not put the IP directly on the physical NIC.

Meaning, on the profile connected to NIC2 (Profile-Uplink), no IP should be configured.

The IP should be configured on the End User profile or a new profile with Access mode and VLAN Tag 20.

Why is this Configuration Correct?

Because the physical switch port is Access. On an Access port:

• The switch expects no tags.
• The connected device should not send tags.
• All traffic belongs to one VLAN.
• VLAN is managed by the physical switch.

⚠️ Warning

If you Trunk the server's physical port in this state and send a tag, the physical switch might Drop the traffic or behave unpredictably.

Limitation of this Scenario

📝 Note

In this scenario, only one VLAN passes. If you need to connect VMs to the physical network in different VLANs, an Access port is not enough. In that case, you must use the Trunk Scenario.

Scenario 2: Physical Switch Port is Trunk

Scenario Description

In this scenario, the server's second port is connected to a physical switch. However, the physical switch port is not Access.

ℹ️ Message from Network Engineers

They might say:

• This port is Trunk.
• VLAN 20 is Allowed on it.
• Traffic for VLAN 20 must pass with a tag.

Or the scenario might have been designed from the start to separate VM traffic based on VLAN:

• For certain VMs, set VLAN 20.
• For other VMs, assign VLAN 30.
• Other VMs will be placed in VLAN 40.

Scenario Logic

When the physical switch port is Trunk, it means multiple VLANs can pass through it. For the switch to know which VLAN each frame belongs to, frames are usually sent with VLAN Tags.

Therefore, the server's physical port must be set to Trunk and allow only the required VLANs.

Required Profiles

Physical Uplink Profile (Trunk):

Feature	Suggested Value
Profile Name	uplink-phys-trunk-multivlan
Port Type	Physical
Connected To	Server's Second NIC
OVS Switch	Internal-Switch
Mode	Trunk
Allowed VLANs	20, 30, 40
Description	Connection to physical switch Trunk port

VM Profiles (One profile per VLAN):

📝 Note

Regarding VM profiles, a separate profile must be created for each VLAN.

Profile Name	Mode	VLAN
vm-access-vlan20	Access	20
vm-access-vlan30	Access	30
vm-access-vlan40	Access	40

Scenario architecture for better understanding:

Traffic Flow

When VM sends traffic:

1. VM sends an Untagged frame.
2. OVS assigns the frame to VLAN 20.
3. OVS places VLAN 20 Tag on the frame.
4. The Tagged frame exits the server's physical port.
5. Physical switch reads VLAN 20 Tag.
6. Frame enters the organization's VLAN 20.

When traffic returns:

1. Physical switch sends the frame with VLAN 20 Tag to the server.
2. Server's physical port introduces it to OVS.
3. OVS reads VLAN 20 Tag.
4. Sends the frame to the virtual port corresponding to VLAN 20.
5. OVS Strips the tag.
6. VM receives the untagged frame.

When Does a Frame Leave the Switch with a VLAN Tag?

ℹ️ Two important conditions for sending a frame as Tagged

1. The frame must have entered the switch from an Access port belonging to that same VLAN.
2. The exit port must be Trunk and the desired VLAN must be in the list of Allowed VLANs for that port.

Based on this logic, in OVS we also need two types of profiles:

1. VLAN Access Profile: For connecting VMs or clients. When traffic enters OVS from the client side, OVS considers it part of that VLAN internally.
2. Trunk Profile: For connecting OVS to the upstream network and physical NIC. In this profile, desired VLANs are specified as Allowed VLANs.

How to Assign IP in this Scenario

🔴 Very Important Point

If an IP needs to be configured on this Trunk link, you must not configure it directly on the NIC or the Trunk profile attached to the NIC.

Just as we use SVI in a Layer 3 switch to assign an IP to a VLAN, in OVS, you must create an Access Profile with the desired VLAN and set the Internal IP on that same profile.

Otherwise, the logic for the desired VLAN will not be applied, and the two necessary conditions to preserve the VLAN Tag will not be met.

If Multiple VLANs are Needed

For example, if VLAN 20, VLAN 30, and VLAN 40 are needed. In this case, the Uplink profile must be Trunk and Allow these VLANs:

Feature	Suggested Value
Mode	Trunk
Allowed VLANs	20, 30, 40

Then create a separate Access profile for VMs for each VLAN:

Profile	VLAN
vm-web-access-vlan20	20
vm-db-access-vlan30	30
ct-app-access-vlan40	40

Scenario 3: Virtual pfSense

Scenario Description

In many environments, we do not want to connect VMs directly to the physical network. Reasons:

• Need for a firewall between VMs and the physical network
• Need for NAT
• Need for traffic control
• Need for Isolation
• Need for Internal DHCP ⭐
• Need for Routing between networks
• Need for more security

In this case, we create a Virtual pfSense. pfSense has two sides:

• WAN Side: Connects to the physical network.
• LAN Side: Connects to internal VMs and containers.

Scenario Logic

In this architecture, VMs are not directly connected to the physical network. They are connected to an internal network behind pfSense.

• VM traffic first goes to pfSense.
• pfSense decides whether to let the traffic pass or not.
• NAT is performed if needed.
• Then traffic goes to the physical network.

Required Switches and Profiles

In this scenario, you need a switch named Internal-FW-Switch along with two separate profiles.

WAN Profile for pfSense:

Feature	Suggested Value
Profile Name	ovs-fw-wan-uplink
Port Type	Virtual for pfSense
Connected To	WAN NIC in pfSense
OVS Switch	ovs-fw-wan
Mode	Access or Trunk (depending on physical network)
VLAN	According to agreement with physical network
Description	Connecting Firewall WAN to physical network

LAN Profile for pfSense:

Feature	Suggested Value
Profile Name	ovs-fw-lan
Port Type	Virtual for pfSense
Connected To	LAN NIC in pfSense
OVS Switch	ovs-fw-lan
Mode	Access
VLAN	With selected VLANs
Description	Connecting Firewall LAN to internal VM network

💡 Tip

For every ovs-fw-lan profile created, select a different VLAN so that the Broadcast Domain is separated from other profiles and the Uplink profile and network congestion is prevented.

VM and Container Profiles:

⚠️ Warning

VMs and containers must not connect to the WAN profile. They must connect to the LAN profile.

Each of the LAN profiles should have a different VLAN:

Profile Name	Mode	VLAN
vm-servers-access-vlan20	Access	20
vm-mgmt-access-vlan30	Access	30
vm-dmz-access-vlan40	Access	40

IP Settings

Firewall WAN Side IP:

pfSense must have an IP in the physical network on the WAN side:

Feature	Value
Subnet	192.168.20.0/24
Gateway	192.168.20.1
WAN IP	192.168.20.10

💡 Tip

If the physical network provides DHCP, pfSense can set WAN to DHCP.

Firewall LAN Side IP:

The LAN side is usually a separate private network:

Feature	Value
LAN Subnet	10.10.10.0/24
pfSense LAN IP	10.10.10.1
VM IP (Example)	10.10.10.20
VM Gateway	10.10.10.1

💡 Tip

If pfSense has an internal DHCP Server, VMs can get IPs automatically.

NAT or Routing Mode

First State — NAT:

If IPs on the LAN side are private and the physical network doesn't recognize them, pfSense usually performs NAT. VMs send traffic with their internal IP, but pfSense sends it out with the WAN side IP.

This is common when:

• The VM network is private.
• The external network has only given an IP to the firewall.
• We don't want internal VM IPs visible in the physical network.

Second State — Routing without NAT:

If the physical network recognizes the network behind pfSense and has routes, NAT might not be needed:

Network	Range
Physical Network	192.168.20.0/24
VM Network	10.10.10.0/24

📝 Note

If the physical network knows that 10.10.10.0/24 network is behind the Firewall IP, it can route traffic without NAT. This state is mostly used in controlled corporate environments.

If pfSense Needs VLANs

If the physical network gives you multiple VLANs and you want pfSense to manage multiple networks, you can Trunk the WAN profile:

Feature	Suggested Value
WAN Profile Mode	Trunk
Allowed VLANs	20, 30, 40

Then inside pfSense, you define an interface or VLAN interface for each VLAN. In this case, pfSense can perform routing or firewalling between VLANs.

Why is this Architecture Correct?

• VMs are not directly exposed to the physical network.
• Traffic control is done by pfSense.
• You can have NAT, Firewall, and internal DHCP.
• Architecture is scalable.
• Security increases.
• You can separate your internal network from the client's network.

Scenario 4: Direct Connection to Client's Firewall

Scenario Description

Sometimes the server's physical port is connected directly to a Client's Physical Firewall, not a switch. In this case, there is no physical switch in between, but logically the same Layer 2 rules apply.

Possible States

First State — Firewall delivers port without VLAN:

Meaning there is an untagged network on that port. In this case, the server's physical port profile must be Access without VLAN Tag (VLAN 0).

Second State — Firewall delivers port with single VLAN:

In this case, the server's physical port profile must be Access for that VLAN.

Third State — Firewall treats port like Trunk:

Meaning multiple VLANs pass with tags from that port. In this case, the server's physical port profile must be Trunk and Allow the required VLANs.

Setting IP

ℹ️ Info

• VM/Containers must get IP from DHCP of that firewall.
• If DHCP is not possible and Container is used, Virtual pfSense must be deployed.
• If VM is used, manually set IP in the firewall's range.

Why Doesn't This Scenario Differ Much?

💡 Tip

From OVS's perspective, it doesn't matter if the other side is a Switch or a Firewall. What matters is that the other side:

• Wants a tag or not?
• Is it Access or Trunk?
• Which VLAN does it accept?
• What is the IP and Gateway?
• Does it have DHCP or not?

Therefore, OVS architecture is configured based on the Layer 2 behavior of the other side.

Scenario 5: LACP and Link Aggregation

What is LACP?

LACP stands for Link Aggregation Control Protocol. It is a standard protocol based on IEEE 802.3ad (later moved to IEEE 802.1AX) for combining multiple physical links into a single logical link.

Simply put, if your server has two or more physical NICs and you want to:

• Have more Bandwidth
• Have Redundancy so if one link fails, traffic passes over the other
• Perform Load Balancing between links

You use LACP.

ℹ️ Info

LACP is a Layer 2 protocol and works at the Ethernet frame level. Both sides of the link (server and physical switch) must support LACP and have it enabled.

How Exactly Does LACP Work?

LACP works by sending control frames called LACPDU (LACP Data Unit) between both sides of the link. The general process is:

Stage 1 — Discovery and Negotiation:

Each side of the link (server and physical switch) sends LACPDU frames on each physical port. These frames contain information such as:

• System ID: Unique ID of the device (usually MAC Address + System Priority)
• Port ID: Physical Port Identifier
• Key: Aggregation Key (ports with the same key can be placed in one group)
• State: Current status of the port (Active, Passive, Timeout, etc.)

Stage 2 — Forming Aggregation Group:

When both sides receive each other's LACPDUs and conditions below are met, links are placed in a LAG (Link Aggregation Group):

• Port speeds match
• Duplex mode matches
• Key matches
• Both sides have accepted LACP

Stage 3 — Maintenance and Monitoring:

After forming the LAG, LACPDU frames are sent periodically (every 1 second in Fast mode or every 30 seconds in Slow mode). If one side stops receiving LACPDUs, it removes that link from the group.

⚠️ Warning

If one side has LACP active and the other doesn't have LACP, the aggregation link will not form and traffic might be Dropped or pass over only one link.

LACP Modes: Active and Passive

LACP has two operational modes that determine how negotiation starts:

Mode	Behavior	Starts Negotiation?
Active	The device itself sends LACPDU frames and initiates negotiation.	✅ Yes
Passive	The device just waits for receiving LACPDU from the other side and responds upon receipt.	❌ No

Possible Combinations and Results:

Server Side (OVS)	Physical Switch Side	Result
Active	Active	✅ LACP forms (both sides initiate negotiation)
Active	Passive	✅ LACP forms (Server is initiator)
Passive	Active	✅ LACP forms (Switch is initiator)
Passive	Passive	❌ LACP Does Not Form (neither initiates negotiation)

🔴 Danger

If both sides are Passive, LACP will never form. At least one side must be Active.

💡 Tip

The best state is for both sides to be Active. This provides the fastest negotiation time and highest stability.

Difference Between LACP and Static LAG

Feature	LACP (Dynamic)	Static LAG (Manual)
Auto Negotiation	✅ Yes	❌ No
Failure Detection	✅ Yes (via LACPDU)	❌ Only if physical link breaks
Misconnection Detection	✅ Yes	❌ No
Standard	IEEE 802.3ad / 802.1AX	Vendor dependent
Usage Recommendation	✅ Recommended	⚠️ Only for special cases

⚠️ Warning

In Static LAG mode, if a cable is plugged into the wrong port on the physical switch, the switch won't notice and a Loop might occur. But in LACP, because negotiation exists, this error is detected.

Load Balancing Algorithms in LACP

When multiple links are in a LAG, the switch and server must decide which link to send each frame over. This decision is made by a Hashing Algorithm.

Common algorithms:

Algorithm	Based On	Description
balance-slb	Source MAC	Distribution based on sender MAC. Simple and compatible with all switches.
balance-tcp	Source/Dest IP + Port	More precise distribution based on combination of IP and TCP/UDP port. Requires switch support.
src-mac	Source MAC	Based on source MAC only.
dst-mac	Destination MAC	Based on destination MAC only.
src-dst-mac	Source + Dest MAC	Combination of both MACs.
src-dst-ip	Source + Dest IP	Combination of both IPs.

💡 Tip

In OVS, balance-slb or balance-tcp is usually used.

• balance-slb requires no special configuration on the switch side and works with any switch.
• balance-tcp performs better but definitely requires LACP enabled on both sides.

Scenario Description

We have a hypervisor server with two physical NICs for connecting VMs and containers to the physical network (e.g., NIC2 and NIC3).

Network Engineers say:

ℹ️ Message from Network Engineers

• Two physical switch ports have been allocated for your server.
• These two ports are in a Port-Channel or LAG.
• LACP Active mode is enabled on the switch.
• VLAN 20 and VLAN 30 on this LAG are set to Trunk.

Scenario Architecture

In this architecture:

• The server's two physical NICs (NIC2 and NIC3) enter a Bond in OVS.
• Bond acts as the Uplink for the OVS virtual switch.
• VMs and containers connect to Access profiles like previous scenarios.

Sample Configuration for Physical Switch

For LACP to work correctly, the physical switch side must also be configured.

Example for Cisco Switch:

interface range GigabitEthernet0/1 - 2
  channel-group 1 mode active
  switchport mode trunk
  switchport trunk allowed vlan 20,30

interface Port-channel1
  switchport mode trunk
  switchport trunk allowed vlan 20,30

Example for MikroTik Switch:

/interface bonding
add name=bond1 slaves=ether1,ether2 mode=802.3ad \
    lacp-rate=1sec transmit-hash-policy=layer3-and-4

/interface bridge port
add bridge=bridge1 interface=bond1

/interface bridge vlan
add bridge=bridge1 tagged=bond1 vlan-ids=20,30

Example for Juniper Switch (JunOS):

set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members VLAN20
set interfaces ae0 unit 0 family ethernet-switching vlan members VLAN30

set interfaces ge-0/0/0 ether-options 802.3ad ae0
set interfaces ge-0/0/1 ether-options 802.3ad ae0

📝 Note

Examples above are general patterns. Exact commands depending on the Model and Software Version of the switch may vary slightly. Be sure to check your vendor's documentation.

Required Profiles

Bond Profile (Uplink):

Feature	Suggested Value
Name	bond0
Type	Bond (LACP)
Members	NIC2 + NIC3 (Must assign both physical NICs to this profile from Physical port section)
OVS Switch	ovs-lan
LACP Mode	Active
Load Balancing Algorithm	balance-tcp
LACP Rate	Fast (every 1 sec)
Trunk/Access Mode	Trunk
Allowed VLANs	20, 30

VM Profiles:

Profile Name	Mode	VLAN
vm-web-access-vlan20	Access	20
vm-db-access-vlan30	Access	30

Traffic Flow with LACP

When VM sends traffic:

1. VM sends an Untagged frame.
2. OVS assigns the frame to VLAN 20 (based on Access profile).
3. OVS places VLAN 20 Tag on the frame.
4. OVS decides based on Hashing Algorithm which physical link (eth1 or eth2) to send the frame from.
5. The tagged frame exits from the selected link.
6. The physical switch receives the frame via Port-Channel.
7. The physical switch reads VLAN 20 tag and puts the frame into the organization's VLAN 20.

When traffic returns:

1. Physical switch sends the frame with VLAN 20 Tag via Port-Channel.
2. Physical switch selects one of the links based on its own algorithm.
3. Frame enters OVS.
4. OVS reads VLAN 20 Tag.
5. Sends the frame to the virtual port corresponding to VLAN 20.
6. OVS Strips the tag.
7. VM receives the untagged frame.

Failover — When a Link Breaks

One of the most important advantages of LACP is Automatic Link Failure Detection.

Failure Scenario:

1. Assume eth1 breaks (cable cut, switch port broken, etc.).

2. OVS stops receiving LACPDU from eth1.
3. After 3 times missing LACPDU reception (in Fast mode, i.e., after 3 seconds), OVS declares that link Inactive.
4. All traffic automatically passes over eth2.

5. When eth1 becomes active again and sends LACPDU, OVS adds it back to the Bond.

💡 Tip

In Fast LACP mode (lacp-time=fast), failure detection takes approximately 3 seconds. In Slow LACP mode (lacp-time=slow), this time is about 90 seconds.

For Production environments, always use Fast mode.

Important Points and Common Mistakes

🔴 Danger — Common Mistakes

1. Mismatch of LACP Mode: If OVS side is active but switch side has no LACP enabled (mode on or Static), LACP will not form and traffic might be Dropped.

2. Mismatch of Port Speeds: If one port is 1Gbps and another is 10Gbps, LACP will not place them in the same group.

3. Mismatch of Allowed VLANs: If OVS side allows VLANs 20 and 30 but switch side only allows VLAN 20, VLAN 30 traffic will be Dropped.

4. Cables Connected to Wrong Ports: Both cables must be connected to ports that are in one Port-Channel. If one cable goes to a free port, LACP rejects that link.

🔒 Security

Never connect Bond cables to different switches unless those switches support MLAG (Multi-Chassis Link Aggregation). Otherwise, LACP won't form or a Loop will be created.

Difference Between LACP and Active-Backup Mode

Sometimes Active-Backup is used instead of LACP. In this mode, only one link is active, and the other activates only if the first link fails.

Feature	LACP	Active-Backup
Number of Active Links	All links simultaneously active	Only one link active
Bandwidth Increase	✅ Yes	❌ No
Redundancy	✅ Yes	✅ Yes
Switch Configuration Required	✅ Yes (Port-Channel)	❌ No
Complexity	Medium	Low
Recommended Use	Production envs needing high bandwidth	Simple envs or when switch doesn't support LAG

📝 Note

In Active-Backup mode, no configuration on the switch side is needed. The physical switch sees each port independently and sends traffic only over the active link.

Why Use LACP?

• Increased Bandwidth: Two 1Gbps links provide total capacity up to 2Gbps.
• Redundancy: If a link breaks, traffic automatically passes over the other.
• Smart Failure Detection: Via LACPDUs, link failure is detected within ~3 seconds.
• Misconnection Detection: If cable is plugged into wrong port, LACP rejects it.
• Standards-Based: Based on IEEE standard, compatible with all vendors.
• Combination with Trunk: Can combine LACP with Trunked VLANs.

Configuration Summary

Stage	Server Side (OVS)	Physical Switch Side
1	Create Virtual Switch (ovs-lan)	Create Port-Channel (LAG)
2	Create Bond with lacp=active	Enable LACP Active on ports
3	Set bond_mode=balance-tcp	Set Load Balancing algorithm
4	Set Trunk and Allowed VLANs on Bond	Set Trunk and Allowed VLANs on Port-Channel
5	Create Access Profiles for VMs	—
6	Check status with lacp/show	Check status with vendor-specific command

Final Conclusion

Open vSwitch is a powerful virtual switch that allows you to connect the network of your VMs and containers to the client's physical network in a standard, scalable, and manageable way.

🏢 Key Takeaways

• Building an OVS switch alone only creates an Empty Switch.
• Network behavior is defined by Profiles.
• Profile determines if a port should be Access or Trunk.
• If the client's switch is Access, the server's physical port must be Access too.
• If the client's switch is Trunk, the server's physical port must be Trunk.
• If you need Security, NAT, or Traffic Control, place a Virtual pfSense.
• The physical port passed to OVS usually should not have a direct IP.
• Standardized naming and documentation are essential for long-term management.

Final Checklist

Have you understood these items?

• Should the physical port be Access or Trunk?
• Should the VM be Access or Trunk?
• Is pfSense needed?
• Where should the IP be placed?
• How do VLANs connect to the client's network?
• How does LACP help maintain stability?
• How to maintain security and isolation?

✅ End of Document

If you understand this architecture correctly, you can make correct decisions in any scenario. This is exactly what is needed for designing standard networks in virtualization infrastructure.