senn-techNetwork Basics: VLANs & Jumbo Frames
VLANs and Jumbo Frames are two techniques every Proxmox administrator should understand. One segments, the other accelerates — and both can create subtle problems if misconfigured.
VLANs: Why segment?
A flat network where management, storage, clients, and guest WLAN all hang in the same broadcast domain is a security nightmare. VLANs separate these worlds at Layer 2.
Under Proxmox, configuration is straightforward: Linux bridge with VLAN-aware flag, then set the VLAN ID per VM network card.
iface vmbr0 inet manual
bridge-ports eno1
bridge-vlan-aware yes
The VM network card receives the VLAN ID when created. The switch must be trunk-capable — this is standard even on entry-level models today.
What we separate
- Management: Proxmox host, iDRAC/iLO, switch UI
- Storage: Ceph/LINSTOR/DRBD replication, NFS
- DMZ: publicly accessible services (reverse proxy)
- Internal: VMs, clients, printers
This costs 10 minutes of switch configuration and brings years of security.
Proxmox SDN: Managing VLANs cluster-wide
With multiple nodes, maintaining identical bridge configurations on each host becomes tedious. Proxmox provides under Datacenter → SDN a Software-Defined Networking module: VLAN- (and VXLAN-) zones are centrally defined and automatically rolled out to all cluster nodes. A VM that migrates finds its network unchanged on the target node.
Jumbo Frames: MTU 9000
Standard Ethernet frames hold 1500 bytes. Jumbo Frames increase this to 9000 — reducing the number of frames for large transfers and lowering CPU load on both ends.
Where it pays off: storage networks (Ceph, NFS with large I/O) and backup networks. Where it brings nothing: normal client traffic, internet uplinks.
Bonds and LACP
In storage and backup networks, besides Jumbo Frames, a bond (LACP/802.3ad) over two NICs pays off: higher throughput and failover redundancy at once. Important is only that the switch configures the LACP group appropriately — otherwise the interface flaps.
The pitfall
All devices in the same Layer-2 segment must speak the same MTU. A switch with MTU 1500 between two Jumbo endpoints leads to fragmented or dropped packets — and the error pattern is diffuse: "sometimes slow, sometimes timeout".
The rule: storage VLAN gets MTU 9000, everything else stays at 1500. And before production, test with ping -M do -s 8972 <ziel>.
Conclusion
VLANs are mandatory from the second service onward and form the basis for any HA cluster. Jumbo Frames are optional, but in storage networks a simple performance gain. Both techniques reward clean documentation.
From when are VLANs mandatory for us?+
From the second service onward. A flat network where management, storage, clients, and guest WLAN all sit in the same broadcast domain is a security risk. We separate at least management, storage, DMZ, and internal traffic at Layer 2. Under Proxmox, a VLAN-aware bridge plus a VLAN ID per network card is enough — ten minutes of switch configuration for years of security.
Where do Jumbo Frames help and where not?+
Only in storage and backup networks — for example Ceph replication, NFS with large I/O, or backup jobs. MTU 9000 reduces the frame count and lowers CPU load on both sides. For normal client traffic or internet uplinks they bring nothing. The key is that all devices in the same Layer-2 segment speak the same MTU, otherwise you get fragmented packets and diffuse timeouts.
What is the most common pitfall with Jumbo Frames?+
An inconsistent MTU. If a switch with MTU 1500 sits between two Jumbo endpoints, you get fragmented or dropped packets — the symptom is diffuse: sometimes slow, sometimes timeout. The rule is: storage VLAN gets MTU 9000, everything else stays at 1500. Before production, test with a ping at a fixed packet size so such problems show up immediately.