SERVER PLUS INSIGHTS
Cisco NX-OS 9.3.x VLAN Translation: 1:1 VLAN Mapping Design and Validation in a vPC Environment
VLAN translation preserves the customer-facing tag while using a different forwarding VLAN inside the Nexus environment. This is essential when neither party can change the VLAN ID.
2026-07-11 · Server Plus
VLAN translation preserves the customer-facing tag while using a different forwarding VLAN inside the Nexus environment. This is essential when neither party can change the VLAN ID.
When VLAN translation is required
A typical case is an upstream provider already using a VLAN ID for another customer while the local environment must retain the same customer-facing tag. Translation maps the ingress tag to an internal forwarding VLAN and maps it back on egress.
Core design rules
Build and allow the translated VLAN, not the ingress wire tag, on the translation trunk. Both members of a vPC pair must use the same VLAN database, mapping, and allowed VLAN configuration.
- Keep ingress and translated VLAN IDs separate
- Use the translated VLAN as the forwarding domain
- Maintain vPC Type-1 consistency on both peers
- Validate MAC learning and end-to-end tags
NX-OS 9.3.x considerations
On affected 9.3.x designs, the translated VLAN must be associated with the required vn-segment programming path. This does not mean the traffic must be carried as VXLAN; it is a platform-specific requirement for the mapping path.
Change and verification
Stage the VLAN database and peer-link allowance on both peers, apply matching mapping configuration, then validate vPC consistency, VLAN state, MAC learning, counters, and wire tags at both ends.
FAQ
Why not simply change the customer VLAN?
The customer-side VLAN can be constrained by an existing site, service, or equipment configuration. Translation resolves the conflict without changing the wire tag the customer must use.
Why must both vPC peers match?
VLAN mapping is checked by vPC consistency mechanisms. A mismatch can suspend the affected VLAN and interrupt traffic.