vDC Networking
How tenant networks are built and carried: IPAM, the VXLAN transport, tenant VLAN networks, networks stretched across several vDCs, and shared bridges.
Network and IPAM
Each vDC can receive dedicated SDN VNets and subnets. ProxCenter tracks IP and MAC reservations so tenant deployments remain consistent even when VMs are cloned, restored, or edited later. A vDC that also holds VLAN pools lets its users build VLAN-backed networks themselves, described in Tenant VLAN Networks below.
IPAM handles:
- Automatic IP reservation during deployment
- Automatic MAC reservation for new network interfaces
- Reservation updates when VM network configuration changes
- Reconciliation when a VM is created externally in the tenant's Proxmox pool
A network created with Addressing managed outside ProxCenter is deliberately left out of IPAM: its CIDR and gateway stay documentation, and no address is reserved or handed out at deploy time.
If operators create or move VMs directly in Proxmox, make sure the VM is placed in the correct tenant pool. ProxCenter reconciles tenant pool membership, but resources outside the pool remain outside the tenant vDC.
VXLAN Transport
A vDC's own networks are VXLAN: the vDC owns an SDN zone on the cluster and ProxCenter allocates the VNI. How that zone reaches its peers is configurable per vDC, on the Network tab of the vDC dialog under VXLAN transport: "How this vDC's VXLAN zone reaches its peers. Saving the vDC rewrites the zone on Proxmox and applies the SDN configuration when peers or MTU change." (Enterprise)
Transport mode takes one of three values:
| Mode | Where the peers come from | What ProxCenter writes on the nodes |
|---|---|---|
| Cluster network | The cluster node addresses, read when the zone is created. Use Sync zone after a node joins | Nothing: the overlay follows the management network and its MTU. This is the default |
| Peer list | Every peer address you type. Endpoints outside the cluster are accepted | Nothing. An address that exists nowhere makes Proxmox fall back to the route it would take, on another network |
| Transport network | The node addresses of a dedicated VLAN segment, plus any additional endpoint | The VLAN interface on every listed node, then a network reload on that node and an SDN apply |
A diagram under the picker is drawn from the form itself, so you see which node contributes which address, which peers belong to no node, and which underlay carries the overlay before you save.
Fields
| Field | Applies to | Rule |
|---|---|---|
| Peer addresses | Peer list | One IPv4 or IPv6 address per line or comma separated. At least one |
| Additional peers | Transport network | Endpoints on the segment that are not cluster nodes: tenant routers ingesting the VXLAN stream, hardware VTEPs, another cluster |
| Zone MTU (VNets) | Every mode | The MTU of the tenant VNets. Underlay MTU minus 50, so 1450 for a 1500-byte underlay and 8950 for jumbo frames. An integer between 1280 and 9000 |
| VLAN ID | Transport network | 1 to 4094 |
| Underlay device | Transport network | The parent interface the VLAN is built on. device.vlan must be at most 15 characters, which is the kernel's interface-name limit |
| Segment (CIDR) | Transport network | The segment the node addresses live in |
| Node addresses on the segment | Transport network | One address per node, each inside the segment and each used once. A Fill sequentially helper allocates them in order. A node left without an address is a warning, not a refusal: Proxmox accepts it, and it simply receives no tenant traffic |
Peers and MTU reach Proxmox before anything is written to the database, so a body Proxmox refuses leaves the stored vDC untouched, and a save that changes neither peers nor MTU never touches Proxmox at all.
Provisioning the transport network
Creating the VLAN interfaces is a separate, explicit action, never a side effect of saving: Provision on nodes, with the warning that it "Creates or updates the VLAN interface on each listed node, then reloads that node's network. This applies every pending network change of the node."
Per node it creates a VLAN interface named device.vlan, with the node's address on the segment, autostart on, a comment naming the vDC, and an MTU of the zone MTU plus the 50 bytes of VXLAN overhead. A network reload follows on each node, then one SDN apply at the end, which is what makes the zone pick up the new addresses. The run is idempotent and reports per node whether the interface was created, updated, already correct, or in error, and the panel then shows each node as provisioned, not provisioned, different from what is expected, or unreachable.
Sync zone and Provision on nodes are both disabled while the form differs from what is stored: save the vDC first. Sync zone rewrites the zone from the stored transport and recreates it if it has been deleted on the Proxmox side, and the panel next to it compares what Proxmox actually runs, staged changes included, against what the transport asks for: In sync, Out of sync, Zone not found on Proxmox or Pending apply.
Deleting a vDC deletes its zone and its networks but leaves the VLAN interfaces in place on the nodes. They may be shared with another vDC, and removing a node's interface is a change to the node's network configuration, not to a tenant's.
Two vDCs on one segment
Two vDCs on the same cluster may share a transport segment, but only with the same definition. A disagreement is refused before anything is written, on either side, and the message names the vDC already holding it. Five disagreements are caught: a different CIDR on the same interface, a different zone MTU on the same interface, one node given two addresses, one address given to two nodes, and one segment reached through two interfaces.
This is a transport for L2 segments. EVPN and the routing that comes with it are out of scope.
Tenant VLAN Networks
By default a vDC's networks are VXLAN: the vDC owns an SDN zone and ProxCenter allocates the VNI, over the transport described in VXLAN Transport above. A provider can additionally dedicate one or more VLAN pools to a vDC, after which the tenant builds VLAN-backed networks itself, self-service, with the tag taken from its own ranges. (Enterprise)
Dedicating VLAN pools (provider)
In Settings > Virtual Datacenters, edit the vDC and use the VLAN pools section. A range is a Bridge, a First VLAN ID, and a Last VLAN ID; the + button on the section header adds another.
| Rule | Detail |
|---|---|
| Bridges offered | The cluster's physical bridges, Linux and OVS alike, deduplicated across nodes. SDN VNet names are excluded; a bridge already used as the uplink of an SDN zone stays available for pools |
| VLAN awareness | A bridge that does not report VLAN awareness is still selectable, with a warning under the field that tagged traffic may not pass. Fix it on the Proxmox side before handing the range to a customer |
| Bounds | 1 to 4094. Proxmox itself accepts higher values, but 0 and 4095 are reserved by 802.1Q, so ProxCenter stops at 4094. The first ID must be lower than or equal to the last |
| No overlap | Two ranges of the same vDC may not overlap on the same bridge, and neither may a range of another vDC on the same cluster and bridge. The error names the other vDC and its range |
| No unsafe shrink | A range cannot be narrowed below a VLAN network that already uses a tag inside it. The error names the network and the tag it holds |
Creating a VLAN network (tenant)
Tenant users create networks from Infrastructure > Inventory, in the Network view, from the Virtual Networks card and its Create VNet button.
- The Network type selector only appears when the selected vDC carries at least one VLAN pool. Without a pool the dialog creates a VXLAN network.
- Choosing VLAN adds a Bridge picker, limited to the bridges this vDC has a pool on, and a VLAN ID field. A single bridge in the pools is selected implicitly.
- Leave VLAN ID empty and ProxCenter assigns the lowest free tag in the vDC's ranges for that bridge. The helper text spells out the ranges available.
- A tag typed outside those ranges is refused, and so is a tag already carried on that bridge, whether by another vDC's network or by a zone the provider built directly in Proxmox.
- Freed tags are reused. Unlike VXLAN VNIs, VLAN tags are a scarce, provider-bounded resource.
- A subnet with a CIDR and a gateway is mandatory on both network types. The gateway is prefilled with the first usable host of the CIDR.
The Addressing managed outside ProxCenter checkbox is offered on VLAN networks only. Ticked, the subnet stays declarative: IPAM hands out no address at deploy time and the tenant runs its own DHCP or a static plan. It is not offered on a VXLAN overlay, where ProxCenter's IPAM is the only allocator that works, so opting out would leave the network with none at all.
How VLAN networks sit on the cluster
How the VLAN zones, tag uniqueness and VNI ranges are laid out on the cluster
- All VLAN networks of a cluster share one provider-owned SDN zone per bridge, created automatically the first time a tenant asks for a VLAN network on that bridge. Its name is derived from the connection and the bridge, so concurrent creations converge on the same zone.
- That shared zone is the L2 backstop: Proxmox enforces tag uniqueness inside a zone, so two vDCs racing for the same tag end in a Proxmox error rather than a shared broadcast domain.
- VXLAN VNIs are allocated from 10000 upward, cluster-wide. A VLAN tag never reaches that floor, so a tag and a VNI cannot collide on the same cluster.
Deleting a vDC deletes its own networks and its own VXLAN zone. The shared VLAN zones are kept, since other vDCs may still use them and an empty zone costs nothing.
Tagging a shared bridge directly
A VLAN pool also widens what a tenant may write in a guest NIC. On a bridge the vDC already receives as a shared bridge, a NIC may carry tag= or trunks= values that fall inside the vDC's pools for that bridge; anything outside is refused. A pool on its own never opens a bridge the vDC does not already share, and a tag on an SDN VNet is refused outright because the VNet already carries its own.
See Network Security for the full list of checks and where they run.
Stretched Tenant Networks
One tenant holding a vDC on several clusters can be given one L2 segment carried by all of them at once: the same VNI and the same VNet on every member cluster, one shared subnet and one shared IPAM pool, so guests on different clusters sit on the same network with no routing between them. (Enterprise)
Stretched networks are created and managed by the provider, from Settings > Virtual Datacenters > Tenant networks. There is no tenant-side request flow: the tenant asks, the provider creates and attaches.
Creating one
New tenant network takes:
| Field | Rule |
|---|---|
| Name, Description | The name is unique inside the tenant |
| VNI | Left empty, a VNI free on every cluster of the tenant is allocated. Set it explicitly when something outside ProxCenter, a tenant router for instance, reads the tag. A VNI already taken names its holder |
| Zone MTU | Every member zone has to carry it. It cannot be changed once a vDC carries the network |
| Subnet (CIDR), Gateway, DNS servers | The single subnet of the whole segment |
Only tenants owning at least one enabled vDC with a VXLAN zone can hold a stretched network; otherwise the create button says so instead of opening an empty form. Once created, only the name, the description and the DNS servers can be edited: the VNI, the subnet and, as soon as a vDC carries it, the MTU are locked.
The VNI reservation is global and survives an empty network, so a cluster that joins later cannot find the VNI already in use by something else. It is checked against the VNets ProxCenter created, the live VNet tags of every cluster of the tenant, legacy zones and VLAN tags included, and every other tenant network.
Adding and removing member vDCs
Member vDCs lists the vDCs carrying the network, one chip per cluster, and Add a vDC offers only the tenant's vDCs that have a VXLAN zone on a cluster no member holds yet.
Joining creates a real VNet in that vDC's own zone, carrying the network's VNI and name, so everything that already consumes a vDC VNet keeps seeing an ordinary one. It also rewrites the zone of every member with its own peers plus the other members', which is what makes the VXLAN tunnels between the clusters meet. The same exchange happens again when a member's own transport changes or a member is removed, and Sync zones replays it on demand, reporting how many zones were rewritten and how many were already in sync.
Leaving is refused while a guest NIC still uses the local VNet, and the network cannot be deleted until the last member has left. Deleting it releases the VNI.
IPAM is shared. The network owns one canonical subnet and every member points at it, so an address is handed out once for the whole segment rather than once per cluster, across deploy, guest creation, clone and restore alike.
Checking that the underlay carries it
Test reachability has each node of a member cluster ping the transport peers of the other members over SSH. It needs at least two members, and it answers per node and per peer.
Read the result for what it is: an address that answers is routed by the underlay, which does not prove that UDP 4789 passes. One that does not answer is the usual explanation for an overlay that stays silent while both zones report themselves in sync.
What the tenant sees
In My Datacenter, a VNet that comes from a stretched network is badged Stretched, with the tooltip "Part of the tenant network ..., present on several clusters" and the subtitle "Managed by your provider". Editing and deleting it are disabled in the interface and refused by the server. A Stretched networks card lists each network once with the vDCs carrying it.
The vDC dialog shows the same list, read-only, on its Network tab: "Stretched networks this vDC carries. Managed from the Tenant networks tab."
Shared Bridges and Provider VNets
Beyond the networks a vDC builds for itself, a provider can hand it existing uplinks, in the vDC dialog's Network tab under Shared bridges (uplinks): "Optional: grant host bridges for WAN or management uplinks. The tenant's own networks are the VNets it creates in its SDN zone above."
That list also carries provider-managed SDN VNets next to host bridges, so a segment the provider already runs as a VNet, a WAN or a transit network, can be shared with a tenant without being rebuilt as a bridge. Each is shown with its own icon and its zone in parentheses, and ticking one prefills its Proxmox alias as the label.
What is offered, and what is not:
- A bridge used as the uplink of an SDN zone is offered as a VLAN pool bridge but not as a shared bridge, so the same segment is never offered twice under two names.
- A VNet belonging to any vDC's own zone is never offered. Only VNets the provider manages outside the vDC zones are.
In the deploy wizard, the network picker groups its entries as VNets (your vDC), Shared bridges and Cluster bridges. The VLAN tag field follows the kind of network selected: hidden on a vDC's own VNet, where the VNet already carries its tag, and editable on a shared bridge. When the vDC holds a VLAN pool on that bridge, the field states the ranges it accepts, "Allowed VLAN ranges: ...", and a bridge with no pool says so. A tag must be an integer between 1 and 4094, checked in the wizard and re-checked against the vDC's pools by the server.