VNIs are 24-bit identifiers: range 1 to 16,777,215. VLAN IDs are 12-bit: 1-4094. Both need planned allocation. Burning VNIs randomly is how you create a spreadsheet that nobody understands and changes that nobody will make for fear of breaking something.

# Map VLAN to VNI
nv set bridge domain br_default vlan 101 vni 10101

# Create tenant VRF with L3 VNI
nv set vrf TENANT1 evpn vni 10102

# Advertise tenant prefix in BGP
nv set vrf TENANT1 router bgp address-family ipv4-unicast redistribute connected enable on

# Enable EVPN globally
nv set evpn enable on
nv set router bgp address-family l2vpn-evpn enable on

nv config apply

# Verify
nv show evpn vni 10101
# Expected: VNI 10101, type L2, VLAN 101, VTEP 10.10.0.1

VNI naming convention

A simple and widely used VNI allocation convention:

VNI = (Pod number * 10000) + (Tenant number * 100) + (Segment number)

Example:
  Pod 1, Tenant 1, Segment 1:  10101
  Pod 1, Tenant 1, Segment 2:  10102  (L3 VRF VNI for this tenant)
  Pod 1, Tenant 2, Segment 1:  10201
  Pod 2, Tenant 1, Segment 1:  20101

This gives you 9 pods, 99 tenants per pod, and 99 segments per tenant -- more than enough for most deployments, and every VNI is immediately decodable.

In EVPN terminology, each tenant typically needs:

• A MAC-VRF VNI (L2 VNI): used for BUM (Broadcast, Unknown unicast, Multicast) flooding and ARP suppression within the tenant's L2 segment.
• An IP-VRF VNI (L3 VNI): used for routing between subnets within the tenant's L3 VRF.

Tenant 1 (production training job):
  L2 VNI:  10101  -- MAC-VRF for GPU network segment
  L3 VNI:  10102  -- IP-VRF for inter-subnet routing

Tenant 2 (dev/test cluster):
  L2 VNI:  10201
  L3 VNI:  10202

VLAN ID planning alongside VNIs

VLAN IDs are the L2 segment identifiers on the leaf switches before encapsulation into VXLAN. The VLAN-to-VNI mapping is maintained by EVPN. Keep them aligned to prevent confusion:

VLAN 101 <-> VNI 10101  (Tenant 1 GPU segment)
VLAN 102 <-> VNI 10102  (reserved for future L3 VNI bridging interface)
VLAN 201 <-> VNI 10201  (Tenant 2 GPU segment)

VLAN exhaustion warning: 4094 is the hard limit. In a multi-tenant SuperPOD with many tenants plus storage VLANs plus management VLANs plus OOB VLANs, you can approach this limit faster than you expect. Allocating VLANs 1-999 for infrastructure (storage, management, OOB) and VLANs 1000-4094 for tenants gives you 3094 tenant VLANs -- enough for most deployments, but you must enforce the allocation from day one.

EVPN VNI configuration on Cumulus Linux

# On leaf-01: configure EVPN VNI for tenant 1
nv set bridge domain br_default vlan 101 vni 10101
nv set vrf TENANT1 evpn vni 10102
nv set router bgp autonomous-system 4200000001
nv set router bgp router-id 10.10.0.1
nv set vrf TENANT1 router bgp address-family ipv4-unicast redistribute connected enable on
nv set evpn enable on
nv config apply

# Verify VNI-to-VLAN mapping
nv show evpn vni
# Output shows VNI, type (L2/L3), tenant VRF, and VTEP IP