Bond + VLAN — trunk on a bond, sub-interfaces on bond members, native VLAN rule

A bond is a single logical cable. A VLAN is a logical partition on a cable. The two combine when the operator wants redundant links carrying multiple broadcast domains. This is the production shape: a bond between the router and the switch, with the bond carrying several VLANs as sub-interfaces. This lesson walks through the configuration, the native VLAN trap, and the silent-drop failure modes that hide in bond + VLAN combinations.

The topology

flowchart LR
  A[VyOS bond0] --> B[Switch<br/>port-channel<br/>trunk]
  B --> C[VLAN 10<br/>data]
  B --> D[VLAN 20<br/>voice]
  B --> E[VLAN 30<br/>mgmt]
  A -. vif 10 .-> C
  A -. vif 20 .-> D
  A -. vif 30 .-> E

The bond is one logical cable. The switch port-channel is configured as a trunk carrying VLAN 10, 20, and 30. The host creates VLAN sub-interfaces on the bond for each VLAN. Each sub-interface has its own IP address and its own routing table.

The two ways to combine bond and VLAN

There are two approaches:

1. Bond as trunk — the bond is a trunk port. The host creates VLAN sub-interfaces on the bond with vif N.
2. VLAN-aware bond — the bond is configured with vlan-aware and the VLANs are members of the bond.

flowchart TD
  A[Bond + VLAN] --> B[Bond as trunk]
  A --> C[VLAN-aware bond]
  B --> B1[set interfaces bonding bond0 vif 10 address ...]
  B --> B2[set interfaces bonding bond0 vif 20 address ...]
  C --> C1[set interfaces bonding bond0 vlan-aware]
  C --> C2[set interfaces bonding bond0 vlan 10]
  C --> C3[set interfaces bonding bond0 vlan 20]

The two produce the same forwarding behaviour. The trunk approach (vif N) is more common in production because it matches the way most operators reason about VLANs. The VLAN-aware approach is closer to the Linux bridge model.

Configuration — bond as trunk

The bond is configured with members and a mode. The VLAN sub-interfaces are added on top:

[edit]
vyos@vyos# set interfaces bonding bond0 mode '802.3ad'
[edit]
vyos@vyos# set interfaces bonding bond0 lacp-rate 'fast'
[edit]
vyos@vyos# set interfaces bonding bond0 member interface eth0
[edit]
vyos@vyos# set interfaces bonding bond0 member interface eth1
[edit]
vyos@vyos# set interfaces bonding bond0 vif 10 address '192.0.2.1/24'
[edit]
vyos@vyos# set interfaces bonding bond0 vif 20 address '198.51.100.1/24'
[edit]
vyos@vyos# set interfaces bonding bond0 vif 30 address '203.0.113.1/24'
[edit]
vyos@vyos# set interfaces bonding bond0 mtu '9000'
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

The vif N syntax creates a VLAN sub-interface on the bond. The bond becomes the trunk; each VLAN is a logical sub- interface with its own IP address.

The Linux kernel creates:

• bond0 — the bond itself.
• bond0.10 — the VLAN 10 sub-interface.
• bond0.20 — the VLAN 20 sub-interface.
• bond0.30 — the VLAN 30 sub-interface.

vyos@vyos:~$ ip link show bond0
3: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 ...
vyos@vyos:~$ ip link show bond0.10
4: bond0.10@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 ...

The mtu 9000 on the bond is the maximum frame size. The VLAN sub-interfaces inherit the MTU. The VLAN tag adds 4 bytes to each frame, so the actual on-wire MTU is 9004.

Configuration — VLAN-aware bond

The alternative is a VLAN-aware bond. The VLANs are members of the bond:

[edit]
vyos@vyos# set interfaces bonding bond0 mode '802.3ad'
[edit]
vyos@vyos# set interfaces bonding bond0 member interface eth0
[edit]
vyos@vyos# set interfaces bonding bond0 member interface eth1
[edit]
vyos@vyos# set interfaces bonding bond0 vlan-aware
[edit]
vyos@vyos# set interfaces bonding bond0 vlan 10 address '192.0.2.1/24'
[edit]
vyos@vyos# set interfaces bonding bond0 vlan 20 address '198.51.100.1/24'
[edit]
vyos@vyos# set interfaces bonding bond0 vlan 30 address '203.0.113.1/24'
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

This is the same forwarding behaviour under the hood — the kernel creates the same bond0.N sub-interfaces — but the VyOS configuration is grouped differently. Use one or the other; do not mix them in the same configuration.

The switch side

The switch port-channel must be a trunk with the matching VLANs allowed:

Cisco IOS / NX-OS
interface Ethernet1/1
  channel-group 10 mode active
interface Ethernet1/2
  channel-group 10 mode active
interface port-channel 10
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30
  switchport trunk native vlan 1

The switchport mode is trunk. The allowed VLANs are 10, 20, 30. The native VLAN is the default (typically 1).

Arista EOS
interface Ethernet1
  channel-group 10 mode active
interface Ethernet2
  channel-group 10 mode active
interface Port-Channel10
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30
  switchport trunk native vlan 1

Same configuration, different syntax. The key is that the trunk allowed VLANs on the switch match the vif N IDs on the host.

The native VLAN rule

The native VLAN is the VLAN that untagged frames are assigned to. When a frame arrives on the trunk with no 802.1Q tag, the switch places it in the native VLAN. If the native VLAN configuration does not match on both sides, the result is silent drops.

flowchart LR
  A[Host] -->|VLAN 10 tagged| B[Switch trunk]
  B -->|VLAN 10 untagged| A
  A -. native VLAN mismatch .-> C[Frames dropped]

The trap: the host sends a tagged frame on VLAN 10. The switch receives it on the trunk. The switch is configured for native VLAN 1. The switch expects the host to send tagged frames on VLAN 10 and untagged frames on VLAN 1. The host is sending tagged frames on VLAN 10, which is correct. The switch forwards them on VLAN 10.

The other trap: the host is configured with vif 1 and the switch is configured with native VLAN 1. The host sends tagged frames on VLAN 1. The switch receives tagged frames on the native VLAN — the switch interprets this as a tagging mismatch and may drop the frames.

The cleanest practice:

• The host sends tagged frames on every VLAN (vif 1 is created explicitly).
• The switch native VLAN is set to a VLAN the host does not use, or the host does not send on the native VLAN.

The MTU chain

The MTU must be consistent end-to-end. The chain is:

1. Host bond — MTU 9000 (for jumbo).
2. Host sub-interface — MTU 9000 (inherits from bond).
3. Switch port-channel — MTU 9216 (jumbo on the switch).
4. Switch VLAN — MTU inherited from the port-channel.
5. Destination device — MTU 9000 (must match).

flowchart LR
  A[Host bond0<br/>MTU 9000] --> B[Switch port-channel<br/>MTU 9216]
  B --> C[Switch VLAN 10<br/>MTU 9216]
  C --> D[Destination<br/>MTU 9000]

If any link in the chain has a smaller MTU, frames larger than that MTU are dropped. The fragment is not reassembled at Layer 3 because the VLAN tag has already been added.

The validation:

vyos@vyos:~$ ping -M do -s 8972 <peer>

The -M do flag disables fragmentation. The -s 8972 is the payload size (8972 + 8 ICMP + 20 IP + 18 Ethernet + 4 VLAN tag = 9022 bytes, larger than MTU 9000). If the ping works, the MTU chain is consistent end-to-end.

Configuration traps

The configuration traps that catch operators:

• VLAN on member instead of bond. The member interfaces are slaves; they do not carry VLANs. The VLAN sub-interfaces are on the bond, not on the slaves.
• MTU on sub-interface only. The MTU must be set on the bond. The sub-interface inherits the bond MTU.
• Native VLAN mismatch. The switch native VLAN is not the same as the host vif 1. The host sends tagged; the switch expects untagged.
• Bond mode without LACP partner. The bond is configured with 802.3ad but the switch is in access mode. The bond appears up but the trunk does not work.
• VLAN exists on one side but not the other. The host has vif 10 but the switch does not have VLAN 10 in the allowed list. Frames are dropped.

How it fails

The production failure modes the engineer must recognise:

• Native VLAN mismatch. Silent drops on the native VLAN. Visible only with tcpdump -e vlan and the switch’s MAC table.
• MTU chain break. Large frames dropped at the smallest link in the chain. Visible only with ping -M do -s 8972.
• VLAN allowed on host but not on switch. Frames dropped at the switch. The bond is up but the VLAN is unreachable.
• VLAN on the wrong bond. The operator added vif 10 to bond1 instead of bond0. Frames never reach the destination.
• Bond without members. The bond has no slaves, so the trunk is down. The VLAN sub-interfaces have no carrier.
• Trunk mode mismatch. The switch port is in access mode for VLAN 10, but the host is sending tagged frames on VLAN 10. The switch treats them as malformed and drops them.

Rollback

The recovery from a misconfigured bond + VLAN:

• Wrong VLAN on the bond: delete interfaces bonding bond0 vif N; commit; save.
• MTU mismatch: set interfaces bonding bond0 mtu '9000'; commit; save.
• Native VLAN mismatch: align the switch and host native VLAN configuration.
• Wrong bond: delete interfaces bonding bond0 vif N; commit; save and add to the correct bond.

Production discipline

Cross-course references

The Linux course’s V-Linux-NetConfig covers the kernel VLAN model. The OPNsense course’s XIV-OPNsense-VLAN covers the firewall-side VLAN and LAG patterns. The Proxmox course’s XXIX-Proxmox-Networking covers the host-side VLAN on bridges and bonds.

Quiz