Linux networking primer: interfaces, bridges, taps

Why this matters in production

Most production VM outages that look like “the VM can’t reach the database” are not VM problems — they are Linux networking problems on the host. Knowing the path a packet takes and which Linux primitive owns each step is the only way to triage effectively.

Mental model

A packet from a guest to an external host traverses several layers, each owned by a different Linux construct:

flowchart LR
  A[Guest virtio-net] --> B[tap device]
  B --> C[Linux bridge]
  C --> D[Bond or VLAN]
  D --> E[Physical NIC]
  E --> F[Switch]

Each box is a real Linux construct with state you can inspect.

The constructs

Physical NIC

The hardware device. Names like eno1, ens4, enp3s0. Managed by the kernel driver (e.g. ixgbe for Intel 10 GbE, mlx5_core for Mellanox).

ip -br link show | grep -v 'veth\|br-\|vmbr\|tap\|bond\|fwpr\|fwln\|veth'

VLAN subinterface

A tagged VLAN on a physical NIC. Names like eno1.100 (VLAN 100 on eno1). The host kernel strips or adds the 802.1Q tag at this layer.

ip -d link show | grep 'vlan proto'

Bond (LAG)

Two or more NICs aggregated. bond0 typically. Modes:

• balance-rr (round-robin) — seldom used.
• active-backup — one NIC active, the other on standby. Survives link loss on the active.
• 802.3ad / LACP — requires the switch to participate; load-balancing + failover.

Linux bridge

A virtual switch inside the host. vmbr0 is the typical default. VMs are attached to it via tap devices. The bridge can be bound to a physical NIC, a bond, or nothing (an “internal” bridge for isolated VM-to-VM traffic).

bridge link show && brctl show vmbr0 2>/dev/null || bridge link show vmbr0

Tap device

A virtual NIC that connects a QEMU process to the Linux bridge. Each VM NIC produces one tap device (e.g. tap100i0 for VM 100, NIC 0).

ip -d link show | grep -A1 'tun'

SDN VNet

A Proxmox-managed bridge equivalent. Created via SDN configuration; appears as a Linux bridge with a name you chose. VNet bridges have the same semantics as regular bridges, with the addition of SDN-level firewall and routing.

The firewall bridge chain, and why ip link shows more than you expect

Run ip -br link on a node with the firewall enabled and guests running, and you will find interfaces nobody created: fwbr100i0, fwpr100p0, fwln100i0. They are not leftovers.

When the iptables firewall backend filters a guest interface, it cannot attach rules directly to a tap device on a bridge. So Proxmox inserts a small bridge per guest interface and a veth pair to connect it to the real bridge:

tap100i0  ->  fwbr100i0  ->  fwln100i0 <-> fwpr100p0  ->  vmbr0
 (guest)      (firewall       (veth pair, one end in each  (real
               bridge)         bridge)                      bridge)

The naming decodes cleanly: fwbr is the firewall bridge, fwln its end of the veth pair, fwpr the end plugged into the real bridge, and the numbers are the VMID and interface index.

Two things follow.

Anything that counts or enumerates bridges sees three times what you expect. A monitoring check on bridge count, a script parsing brctl show, an inventory of interfaces — all of them see the firewall scaffolding as topology.

The proxmox-firewall nftables backend does not create them. It attaches its rules differently, so a node converted to nftables has a visibly different interface list and the tap device is on the real bridge directly. That is a behaviour change to know about before the migration, not after a monitoring check starts alerting.

VMID=100

ip -br link show | grep -E "(tap|fwbr|fwln|fwpr)${VMID}"
bridge link show | grep -E "${VMID}|vmbr0"

The packet walk

A packet sent from the guest’s application to an external host:

1. Guest kernel + virtio-net driver: builds the packet in guest memory and pushes it to the virtio ring.
2. QEMU: reads the packet from the ring, injects it into the tap device via the file descriptor.
3. Linux kernel networking: receives the packet on the tap device, applies bridge forwarding rules.
4. Bridge: forwards the packet to its uplink port (bond, VLAN, or physical NIC).
5. VLAN / bond layer: if tagged or aggregated, adds the 802.1Q tag or selects a member.
6. Physical NIC driver: transmits the packet via DMA.
7. Network: arrives at the switch port.

Each step can fail independently. The packet-flow visualizer above lets you simulate MTU mismatch and link failures to see the failure modes.

Inspecting the stack

ip -br addr

ip route

bridge fdb show

iptables -L -n -v | head -50

Common “VM has no network” diagnoses

Production considerations

Common mistakes

• Creating a bridge without an uplink interface.
• Putting the management IP on the same bridge as VM traffic without a firewall.
• Assuming VLAN tags work on a bond without configuring the switch for trunk mode.
• Editing /etc/network/interfaces without ifreload -a afterwards (Proxmox uses ifupdown2 — direct ifup may not work).

Key takeaways

• A packet goes: guest virtio → tap → bridge → bond/VLAN → physical NIC → switch.
• With the iptables firewall backend there are two more hops: tap → fwbr → veth pair → the real bridge. The nftables backend removes them.
• Every layer is a real Linux construct you can inspect.
• Most “VM has no network” tickets trace to bridge or bond misconfiguration.

Knowledge check