Proxmox Best Practices: Your guide to performance and safety

Proxmox Virtual Environment (short: Proxmox VE) has established itself as one of the most popular open source virtualization platforms. Whether you're just getting into the world of virtualization or are already experienced administrators, hopefully there's something for everyone here.

Part 1: network | Part 2: storage | Part 3: backup | Part 4: security | Part 5: performance

This guide provides you with a collection of field-tested best practices to get the most out of your Proxmox installation. Further details are otherwise directly linked. But let's start right up front, what is Proxmox anyway?

Before we go into depth, here is a short explanation of the terms for all beginners:

Proxmox VE is a complete virtualization platform that combines two main technologies:

KVM (Kernel-based Virtual Machine): For complete virtual machines with their own kernel
LXC (Linux Containers): For lightweight containers that share the host's kernel

virtualization means that you can run multiple isolated ‘virtual computers’ on a physical server. This saves hardware, electricity, space and helps you set up, organize and separate services.

The basics: Hardware Requirements and Setup

Minimum requirements (which you should better outdo)

For one productive use is recommended:

RAM: At least 16GB (better 32GB+), as Proxmox itself consumes about 2-4GB
storage: At least 2 hard disks – one for the Proxmox system, one for VM data
CPU: Modern CPU with virtualization support (Intel VT-x or AMD-V)
network: At least 2 network interfaces for redundancy and traffic separation

To oneself Making a first impression But it's also less:

RAM: At least 4GB (better 8GB+), as Proxmox itself consumes about 2-4GB
storage: A 256 GB SATA SSD for the Proxmox system and VM data
CPU: Modern CPU with virtualisation support (Intel VT-x or AMD-V) – there is no way around it, sorry.
network: Once 1GB Ethernet, but recommend a second (e.g. to USB)

Pro tip: Check the hardware compatibility on the Proxmox website before investing! Popular in the Homelab Here are e.g. refurbished mini-PCs.

Part 1 – Network Best Practice

Network best practices are the solid foundation for everything

1. Network interfaces intelligently divide

A common beginner's mistake: Run everything via a network interface. It is better to use two separate interfaces. For example, this can look like this:

# Management interface (for Proxmox Web UI) auto vmbr0 iface vmbr0 inet static address 192.168.1.10/24 gateway 192.168.1.1 bridge-ports eth0 bridge-stp off bridge-fd 0 # VM-Traffic Interface auto vmbr1 iface vmbr1 inet manual bridge-ports eth1 bridge-stp off bridge-fd 0

Details as follows: In this example, you see vmbr0 and vmbr1 as two separate network interfaces. This is a typical Proxmox network configuration from the /etc/network/interfaces File.

The first bridge: vmbr0 (Management Interface)

auto vmbr0 iface vmbr0 inet static address 192.168.1.10/24 gateway 192.168.1.1 bridge-ports eth0 bridge-stp off bridge-fd 0

What exactly is happening here?

`Auto vmbr0`

meaning: This bridge is automatically activated at startup
Without car: Did you have to use the bridge manually? ifup vmbr0 launch

`iface vmbr0 inet static`

iface: Defines a network interface
vmbr0: Name of the bridge (Proxmox Convention: vm + br + number)
inet: IPv4 protocol
static: Fixed IP address (not DHCP)

`address 192.168.1.10/24`

IP address: 192.168.1.10
/24: Subnet mask (corresponds to 255.255.255.0)
Means: This bridge can communicate with devices in the range 192.168.1.1-254

`gateway 192.168.1.1`

Default gateway: Router/Gateway for Internet Access
Typical: Routers often have the .1 at the end.

`bridge ports eth0`

Physical port: The bridge uses the real network card eth0
Bridge concept: Like a virtual switch that connects eth0 to virtual interfaces

`bridge-stp off`

STP: Spanning Tree Protocol (prevents network loops)
off: Disabled because simple setups do not require
performance: STP can increase latency

`bridge-fd 0`

Forwarding delay: Time until Bridge forwards again after changes
0 seconds: Immediate forwarding (good for VMs)
default: It would be 30 seconds

The second bridge: vmbr1 (VM traffic)

auto vmbr1 iface vmbr1 inet manual bridge ports eth1 bridge-stp off bridge-fd 0

`iface vmbr1 inet manual`

manual: This bridge does NOT get its own IP address
purpose: Only throughput of VM traffic
Difference from Static: Host itself cannot communicate over this bridge

`bridge ports eth1`

Second network card: Use eth1 instead of eth0
Traffic separation: Completely separate from management traffic

Practical importance of this configuration

Why two bridges?

vmbr0 (Management):

Proxmox Web Interface (Port 8006)
SSH access to the host
API access
Backup traffic
Cluster communication

vmbr1 (VM traffic):

Communication between VMs
VM Internet access
Productive application traffic

Network diagram:

Internet  ⁇  Router (192.168.1.1)  ⁇  +-- eth0 --> vmbr0 (192.168.1.10) --> Proxmox Management  ⁇  +-- eth1 --> vmbr1 (no IP) --> VM Traffic  ⁇  +-- VM1 (192.168.2.10) +-- VM2 (192.168.2.11) +-- VM3 (192.168.2.12)

How can my VMs or LXC containers now use these bridges?

VM with management network:

qm set 100 --net0 virtio,bridge=vmbr0 # VM gets IP in the 192.168.1.x range

VM with dedicated VM network:

qm set 101 --net0 virtio,bridge=vmbr1 # VM gets IP in other area (e.g. 192.168.2.x)

Extended concepts

What exactly is a bridge?

A bridge is like a Virtual switch:

Connects physical and virtual network interfaces
Learns MAC addresses and forwards packets intelligently
Allows VMs to behave like physical computers

Alternative: VLAN-aware Bridge

Instead of two bridges, you could also use a VLAN-aware bridge:

auto vmbr0 iface vmbr0 inet static address 192.168.1.10/24 gateway 192.168.1.1 bridge-ports eth0 bridge-stp off bridge-fd 0 bridge-vlan-aware yes bridge-vids 2-4094

Then VMs in different VLANs:

# Management VLAN 10 qm set 100 --net0 virtio,bridge=vmbr0,tag=10 # Production VLAN 20  qm set 101 --net0 virtio,bridge=vmbr0,tag=20

However, we will go into this in more detail below in the VLAN area. Have a little patience. ⁇

Common problems and solutions for such setups:

Problem: Bridge has no IP

# Check if Bridge is active ip addr show vmbr1 # Manually Enable Bridge ifup vmbr1

Problem: "VMs do not reach the Internet"

# Enable IP Forwarding echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf sysctl -p # NAT rule for vmbr1 (if VMs have private IPs) iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o vmbr0 -j MASQUERADE

Problem: ‘Proxmox web interface not reachable’

# Check bridge status brctl show # Restart the interface ifdown vmbr0 && ifup vmbr0

Best practice recommendations

For beginners:

Starts with a bridge (vmbr0)
Extended later with dedicated VM bridges

For production environments or your Homelab:

At least 2 physical NICs (once fixed and once via USB e.g.)
Separate management and VM traffic (also via LAN and WLAN if necessary)
Consider bonding for resiliency

For complex setups:

VLANs instead of multiple bridges
Dedicated Storage Network (vmbr2)
Cluster Network (vmbr3)

This configuration is a solid foundation for most Proxmox installations!

2. VLANs for Network segmentation

Virtual Local Area Networks (VLANs) allow you to divide a physical network into several logical networks:

# VLAN-aware Bridge auto vmbr0 iface vmbr0 inet manual bridge-ports eth0 bridge-stp off bridge-fd 0 bridge-vlan-aware yes bridge-vids 2-4094

Practical simple example:

VLAN 10: production
VLAN 20: Test/Staging
VLAN 30: DMZ
VLAN 99: management

Here, too, we can go into more detail. What do I need that for? Excellent question! This is a so-called VLAN-aware Bridge – a very powerful network configuration in Proxmox. Let me explain this in detail:

What is a VLAN-aware Bridge?

One VLAN-aware Bridge is like a ‘smart switch’ that can understand and process VLAN tags. Instead of creating a separate bridge for each network, you can use a single bridge that manages multiple virtual networks (VLANs).

The configuration in detail

auto vmbr0 iface vmbr0 inet manual bridge ports eth0 bridge-stp off bridge-fd 0 bridge-vlan-aware yes bridge-vids 2-4094

`iface vmbr0 inet manual`

manual: The bridge itself does NOT get an IP address
reason: The IP addresses are configured on VLAN interfaces, not on the bridge
flexibility: Bridge can pass through all VLANs without its own network identity

`bridge-vlan-aware yes`

Core function: Enables VLAN support for this bridge
Means: Bridge can read, understand and forward 802.1Q VLAN tags
Without this option: Bridge would ignore VLAN tags

`bridge-vids 2-4094`

VIDs: VLAN IDs (Virtual LAN Identifiers)
range: VLAN 2 to 4094 are allowed
Why not 1?: VLAN 1 is often the "native/untagged" VLAN
Why not 4095?: Reserved for internal purposes

Practical example: How it works

Step 1: Create VLAN interfaces on the host

# VLAN 10 for Management auto vmbr0.10 iface vmbr0.10 inet static address 192.168.10.1/24 vlan-raw-device vmbr0 # VLAN 20 for Production auto vmbr0.20 iface vmbr0.20 inet static address 192.168.20.1/24 vlan-raw-device vmbr0 # VLAN 30 for DMZ auto vmbr0.30 iface vmbr0.30 inet static address 192.168.30.1/24 vlan-raw-device vmbr0

Step 2: Assign VMs to different VLANs

# VM in Management VLAN (10) qm set 100 --net0 virtio,bridge=vmbr0,tag=10 # VM in Production VLAN (20) qm set 101 --net0 virtio,bridge=vmbr0,tag=20 # VM in DMZ VLAN (30) qm set 102 --net0 virtio,bridge=vmbr0,tag=30 # VM without VLAN tag (native/untagged) qm set 103 --net0 virtio,bridge=vmbr0

Network diagram from the example above:

Physical Network (eth0)  ⁇  [vmbr0] - VLAN-aware Bridge  ⁇  +--------------------------------------+  ⁇   ⁇   ⁇  VLAN 10 VLAN 20 VLAN 30 Untagged Management Production DMZ Native 192.168.10.x 192.168.20.x 192.168.30.x 192.168.1.x  ⁇   ⁇  VM 100 VM 101 VM 102 VM 103

Understanding VLAN tags

What happens to the Ethernet frames?

Without VLAN (normal traffic):

[Ethernet Header][IP Packet][Ethernet Trailer]

With VLAN tag:

[Ethernet Header][VLAN Tag: ID=20][IP Packet][Ethernet Trailer]

The VLAN tag contains:

VLAN ID: Which VLAN (e.g. 20)
Priority: QoS Information
DEI: Drop Eligible Indicator

Advantages of the VLAN-aware Bridge

1. efficiencies

# Instead of several bridges:
# vmbr0 (Management)
# vmbr1 (Production) 
# vmbr2 (DMZ)
# vmbr3 (Storage)

# Just one bridge:
# vmbr0 with VLANs 10,20,30,40

2. flexibility

# VM can use multiple VLANs at the same time qm set 100 --net0 virtio,bridge=vmbr0,tag=10 # management qm set 100 --net1 virtio,bridge=vmbr0,tag=20 # production

3. Easier management

A physical interface for everything
Central VLAN configuration
Less bridge management

But beware, this also requires a switch configuration!

Important: Your physical switch must also be VLAN-aware:

# Cisco Switch example interface GigabitEthernet0/1 switchport mode trunk switchport trunk allowed vlan 10,20,30 switchport trunk native vlan 1

Advanced configurations

Trunk port for multiple VLANs

# VM as Trunk (Router/Firewall) qm set 200 --net0 virtio,bridge=vmbr0,trunks=10;20;30

VLAN-aware Bridge with Bonding

auto bond0 iface bond0 inet manual slaves eth0 eth1 bond-miimon 100 bond-mode 802.3ad auto vmbr0 iface vmbr0 inet manual bridge-ports bond0 bridge-stp off bridge-fd 0 bridge-vlan-aware yes bridge-vids 2-4094

Common Problems and Debugging

Problem: VM reaches other VLANs

# Check VLAN isolation Bridge vlan show # Firewall rules between VLANs iptables -A FORWARD -i vmbr0.10 -o vmbr0.20 -j DROP

Problem: VLAN traffic does not work

# View VLAN Configuration cat /proc/net/vlan/config # Check bridge VLAN table bridge vlan show dev vmbr0 # Package Capture for Debugging tcpdump -i eth0 -e vlan

Problem: Native VLAN issues

# Set untagged VLAN explicitly bridge vlan add dev vmbr0 vid 1 pvid untagged self

Best practices

1. VLAN planning, segmenting like the pros:

VLAN 10: Management (Proxmox, Switch-Management) VLAN 20: Production (web server, databases) VLAN 30: Development (test systems) VLAN 40: DMZ (Public Services) VLAN 50: Storage (iSCSI, NFS) VLAN 99: Guest/IoT (Isolated)

2. security

# Controlling Inter-VLAN Routing
# Only explicitly allowed communication iptables -A FORWARD -i vmbr0.20 -o vmbr0.10 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i vmbr0.10 -o vmbr0.20 -p tcp --dport 443 -j ACCEPT iptables -A FORWARD -j DROP

3. performance

# Enable hardware VLAN offloading (if supported) ethtool -K eth0 rxvlan on txvlan on

When to use VLAN-aware Bridge?

You should consider using this if:

Multiple logical networks are required in your setup
A clean network segmentation is desired
Your switch also supports this function securely (VLAN)
Central VLAN management is preferred

However, you should avoid this if:

Only a simple network is needed
Your switch does not support VLANs
No one in the circle of friends/team knows VLANs well
Honestly, you have to say the debugging complexity is high

The VLAN-aware Bridge is a very powerful feature for professional network segmentation in Proxmox, whether in the ambitious Homelab or a company.

3. Network bonding for resiliency

Network bonding combines multiple network interfaces for higher availability:

# Bond Configuration auto bond0 iface bond0 inet manual slaves eth0 eth1 bond-miimon 100 bond-mode active-backup bond-primary eth0 auto vmbr0 iface vmbr0 inet static address 192.168.1.10/24 gateway 192.168.1.1 bridge-ports bond0 bridge-stp off bridge-fd 0

Bond modes at a glance:

active backup: One interface active, other than backup
802.3ad (LACP): Load distribution across multiple interfaces
balance-rr: Round-robin across all interfaces

So this is Network bonding (also known as link aggregation) – a very important technology for resiliency and performance. Let me explain this in detail:

What is Network Bonding?

Bonding Combines multiple physical network cards into one logical interface. This brings two main benefits:

redundancy: If one card fails, the other takes over
performance: More bandwidth through load distribution (depending on mode)

The Bond configuration in detail

Create Bond0 interface

auto bond0 iface bond0 inet manual slaves eth0 eth1 bond miimon 100 bond-mode active-backup bond-primary eth0

`auto bond0`

Automatic start: Bond is activated on boot
bond0: Logical name of the virtual interface

`iface bond0 inet manual`

inet manual: Bond himself does not get an IP address
reason: IP is configured on the bridge (vmbr0) that uses the bond

`slaves eth0 eth1`

Physical interfaces: eth0 and eth1 are added to the bond
Important: These interfaces are NOT allowed to have their own IP configurations!
number: Can be 2 or more interfaces

`bond-miimon 100`

MII Monitoring: Monitors link status every 100ms
MII: Media Independent Interface (hardware-level link detection)
Alternatively: bond-arp interval for RRP-based monitoring

`bond-mode active-backup`

modus: Only one interface active, other than standby
failover: Automatic switch to backup in case of failure

`bond-primary eth0`

Primary interface: eth0 is preferably active
fallback: After repair, Bond returns to eth0

Bridge over Bond

auto vmbr0 iface vmbr0 inet static address 192.168.1.10/24 gateway 192.168.1.1 bridge-ports bond0 bridge-stp off bridge-fd 0

`bridge-ports bond0`

Bond as a bridge port: Bridge uses the Bond instead of individual NICs
transparency: VMs only see the bridge, not the bond

Bond modes in detail

1. `active backup` (Mode 1)

How it works:

    Switch  ⁇  +--+--+  ⁇   ⁇  eth0 eth1  ⁇   ⁇  +bond0+ <- Only eth0 active  ⁇  vmbr0  ⁇  VMs

Characteristics:

Resilience: Yes (this is the main purpose)
Switch support: Not required, externally these are two separate interfaces, each occupying its own port.
simplicity: Very easy to configure

Now, however, there is a "but" around the corner: In this setup, there is no Bandwidth doubling

Practical example:

# Check status cat /proc/net/bonding/bond0 # Output shows:
# Currently active slave: eth0
# MII Status: up
# Slave interface: eth1
# MII Status: up (backup)

2. `802.3ad` (LACP – Mode 4)

How it works:

    LACP enabled switch (port channel/LAG)  ⁇  +--+--+  ⁇   ⁇  eth0 eth1  ⁇   ⁇  +bond0+ <- Both active  ⁇  vmbr0  ⁇  VMs

Configuration:

auto bond0 iface bond0 inet manual slaves eth0 eth1 bond-miimon 100 bond-mode 802.3ad bond-lacp-rate fast bond-xmit-hash-policy layer2+3

Characteristics:

Resilience: Yes, just like in the first example, you get redundancy
Bandwidth doubling: Yes (theoretical doubling, in practice a little less)

Again, however, there is a But, no, actually even two:
This necessarily requires the Switch support: LACP/port channel is required for this
Again, something for the at least ambitious Homelab operator or at least Semi-Pro, because a switch configuration is necessary!

Switch configuration (Cisco as an example):

interface Port-channel1 switchport mode trunk interface GigabitEthernet0/1 channel-group 1 mode active interface GigabitEthernet0/2 channel-group 1 mode active

3. `balance-rr` (Round-Robin - Mode 0)

How it works:

Package 1 -> eth0 Package 2 -> eth1 Package 3 -> eth0 Package 4 -> eth1 ...

Characteristics:

Resilience: Yes, just like the above two examples.
Load balancing: Yes, network traffic is evenly distributed across the interfaces.

And here, too, of course, there is a but:
The first thing to remember is that the Package order It can get messed up.
Next, it is likely that the Homelab range exceeds and is more likely to be used in HA/HP environments with a lot of load. usage find. Just something for very special applications.

Extended bond configurations

Bond with VLAN-aware Bridge

# Creating Bonds auto bond0 iface bond0 inet manual slaves eth0 eth1 bond miimon 100 bond mode 802.3ad # VLAN-aware Bridge over Bond auto vmbr0 iface vmbr0 inet manual bridge-ports bond0 bridge-stp off bridge-fd 0 bridge-vlan-aware yes bridge-vids 2-4094 # VLAN interfaces auto vmbr0.10 iface vmbr0.10 inet static address 192.168.10.1/24 vlan-raw-device vmbr0

Multiple Bonds for Different Purposes

# Management bond auto bond0 iface bond0 inet manual slaves eth0 eth1 bond-mode active-backup bond-miimon 100 auto vmbr0 iface vmbr0 inet static address 192.168.1.10/24 bridge ports bond0 # Storage Bond (higher performance) auto bond1 iface bond1 inet manual slaves eth2 eth3 bond-mode 802.3ad bond-miimon 100 auto vmbr1 iface vmbr1 inet static address 10.0.0.10/24 bridge-ports bond1

Monitoring and troubleshooting

Monitoring Bond Status

# Detailed bond information cat /proc/net/bonding/bond0 # Interpret the output:
# Ethernet Channel Bonding Driver: v3.7.1
# Bonding mode: fault-tolerance (active-backup)
# Primary slave: eth0 (primary_reselect always)
# Currently active slave: eth0
# MII Status: up
# MII Polling Interval (ms): 100
# Up Delay (ms): 0
# Down Delay (ms): 0

Frequent problems

Problem: The bond doesn't start.

# Loading modules modprobe bonding # Permanently Activate echo bonding >> /etc/modules # Creating Bond Manually (Debug) echo +bond0 > /sys/class/net/bonding_masters

Problem: Failover does not work

# Test link status mii-tool eth0 eth1 # Or with ethtool ethtool eth0  ⁇  grep "Link detected" # MII-Monitoring vs ARP-Monitoring
# MII: Hardware level (recommended)
# RRP: Network level (for special cases)

Problem: Performance is not as expected

# Check traffic distribution cat /proc/net/dev # Customize hash policy (for 802.3ad)
# layer2: MAC addresses
# layer2+3: MAC + IP 
# layer3+4: IP + ports (best distribution) echo layer3+4 > /sys/class/net/bond0/bonding/xmit_hash_policy

Best Practices in TL:DR

1. Hardware planning

# Use various PCIe slots
# eth0: onboard NIC
# eth1: PCIe card
# Reason: Redundancy against PCIe slot failure

2. Switch configuration

# For active backup: Normal ports
# For 802.3ad: Configure Port Channel/LAG
# For balance-rr: Attention Spanning Tree

3. Set up monitoring

# Installing Bond Status in Monitoring
#!/bin/bash BOND_STATUS=$(cat /proc/net/bonding/bond0  ⁇  grep "Currently Active Slave") echo $BOND_STATUS # Nagios/Zabbix check if [ "$(cat /proc/net/bonding/bond0  ⁇  grep -c 'MII Status: up')" -lt 2 ]; Then echo "CRITICAL: Bond degraded" exit 2 fi

4. Testing

# Failover testing ip link set eth0 down # Check if eth1 takes over ip link set eth0 up # Check if back to eth0 (at primary)

# Test performance iperf3 -s # On target system iperf3 -c target-ip -t 60 -P 4 # Multiple streams

When should I use which Bond mode? You can see it here:

`active backup` – The safe

Homelab/small environment
Simple switches without LACP
Maximum compatibility
Reliability is more important than performance

`802.3ad` – The professional

Production environment
Managed Switches with LACP
Performance and Redundancy
High network traffic

`balance-rr` – The specific

For local storage network only
If package order doesn't matter
Not for standard networks

So let's briefly summarize again. Each area of application has special requirements for your network. Network bonding is an essential feature for professional Proxmox installations and offers elegant solutions for reliability, performance and throughput!

Completion and advanced resources

Proxmox is a powerful tool, but with great power comes great responsibility. (winker) The best practices shown here are the result of experience in practice. Start with the basics and gradually work your way up to the advanced features.

Your next steps:

Build a testing/staging environment: Test all configurations in a separate environment
Implement monitoring: Monitor your system from the beginning
Test backup strategy: Performs regular restore tests
Join the Community: The Proxmox forum is very helpful

So remember: Take your time, the basics Understand before you More complex setups fades over. The Proxmox admin guide As a website I have linked several times in the article as a reference is also worth gold. Take a look in the forum around, If you have a question. There is also an entry point for YouTube channel. For those of you who are in the enterprise environment: The makers of Proxmox also offer training courses.

And most importantly: Always have a working backup.

Proxmox Best Practice Part 1 – Network: Your guide to optimal performance and greater safety

Proxmox Virtual Environment (short: Proxmox VE) has established itself as one of the most popular open source virtualization platforms. Whether you're just getting into the world of virtualization or are already experienced administrators, hopefully there's something for everyone here.

Before we go into depth, here is a short explanation of the terms for all beginners:

The basics: Hardware Requirements and Setup

Minimum requirements (which you should better outdo)

Part 1 – Network Best Practice

Network best practices are the solid foundation for everything

1. Network interfaces intelligently divide

The first bridge: vmbr0 (Management Interface)

Auto vmbr0

iface vmbr0 inet static

address 192.168.1.10/24

gateway 192.168.1.1

bridge ports eth0

bridge-stp off

bridge-fd 0

The second bridge: vmbr1 (VM traffic)

iface vmbr1 inet manual

bridge ports eth1

Practical importance of this configuration

Why two bridges?

Network diagram:

How can my VMs or LXC containers now use these bridges?

Extended concepts

What exactly is a bridge?

Alternative: VLAN-aware Bridge

Common problems and solutions for such setups:

Problem: Bridge has no IP

Problem: "VMs do not reach the Internet"

Problem: ‘Proxmox web interface not reachable’

Best practice recommendations

For beginners:

For production environments or your Homelab:

For complex setups:

2. VLANs for Network segmentation

What is a VLAN-aware Bridge?

The configuration in detail

iface vmbr0 inet manual

bridge-vlan-aware yes

bridge-vids 2-4094

Practical example: How it works

Step 1: Create VLAN interfaces on the host

Step 2: Assign VMs to different VLANs

Network diagram from the example above:

Understanding VLAN tags

What happens to the Ethernet frames?

The VLAN tag contains:

Advantages of the VLAN-aware Bridge

1. efficiencies

2. flexibility

3. Easier management

But beware, this also requires a switch configuration!

Advanced configurations

Trunk port for multiple VLANs

VLAN-aware Bridge with Bonding

Common Problems and Debugging

Problem: VM reaches other VLANs

Problem: VLAN traffic does not work

Problem: Native VLAN issues

Best practices

1. VLAN planning, segmenting like the pros:

2. security

3. performance

When to use VLAN-aware Bridge?

3. Network bonding for resiliency

What is Network Bonding?

The Bond configuration in detail

Create Bond0 interface

auto bond0

iface bond0 inet manual

slaves eth0 eth1

bond-miimon 100

bond-mode active-backup

bond-primary eth0

Bridge over Bond

bridge-ports bond0

Bond modes in detail

1. active backup (Mode 1)

2. 802.3ad (LACP – Mode 4)

3. balance-rr (Round-Robin - Mode 0)

`Auto vmbr0`

`iface vmbr0 inet static`

`address 192.168.1.10/24`

`gateway 192.168.1.1`

`bridge ports eth0`

`bridge-stp off`

`bridge-fd 0`

`iface vmbr1 inet manual`

`bridge ports eth1`

`iface vmbr0 inet manual`

`bridge-vlan-aware yes`

`bridge-vids 2-4094`

`auto bond0`

`iface bond0 inet manual`

`slaves eth0 eth1`

`bond-miimon 100`

`bond-mode active-backup`

`bond-primary eth0`

`bridge-ports bond0`

1. `active backup` (Mode 1)

2. `802.3ad` (LACP – Mode 4)

3. `balance-rr` (Round-Robin - Mode 0)

`active backup` – The safe

`802.3ad` – The professional

`balance-rr` – The specific