VLANs and tagged interfaces
A VLAN lets one physical port carry several separate networks. It is how a single uplink serves your public traffic and your private one without them meeting.
Tagged and untagged
An untagged (access) port belongs to one VLAN and the server sees ordinary traffic. A tagged (trunk) port carries several, each packet labelled with a VLAN id, and the server has to be configured to understand the tags.
The common arrangement with us: your public network untagged so the machine works out of the box, and any private networks tagged on the same port. See connecting your own servers.
Configuring it on Linux
To test immediately:
ip link add link eno1 name eno1.20 type vlan id 20
ip addr add 10.20.0.5/24 dev eno1.20
ip link set eno1.20 up
Permanently, in netplan:
vlans:
eno1.20:
id: 20
link: eno1
addresses: [10.20.0.5/24]
On RHEL-based systems, nmcli con add type vlan with the parent and the
id. Either way the interface name is conventionally
parent.id, which makes it obvious later what it is.
Agree the ids with us
VLAN ids must match on both ends. Ours is the switch; yours is the server. Open a ticket saying which machines, how many networks and what you are separating, and we will tell you the ids to use.
Do not invent tags. A frame with an unexpected tag is treated as a fault, and traffic claiming to be on another customer's VLAN is exactly what the switch configuration exists to prevent.
MTU
A VLAN tag adds four bytes. On a trunk with a 1500-byte MTU, that leaves 1496 for your payload unless the switch allows a slightly larger frame — which ours does, so 1500 on the VLAN interface is normal here.
If you see small packets working and large ones hanging, it is this: see MTU, fragmentation and tunnels. For deliberately larger frames, see jumbo frames.
With bonding and bridges
Order matters. Bond the physical interfaces first, then put VLANs on the bond
— bond0.20, not two VLANs bonded together. See
bonding and LACP.
For virtual machines, bridge the VLAN interface rather than the physical one, so
guests land in the right network:
vmbr20 on eno1.20. See Proxmox.
Checking your work
ip -d link show eno1.20 — confirms the id and the parent
tcpdump -i eno1 -e vlan — shows tagged frames arriving, which
settles whether the problem is the switch or the server
If frames arrive tagged and nothing works, the server configuration is wrong. If nothing arrives at all, tell us — that is our side.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base