Mellanox Switch Port Types in MLNX-OS: Access, Trunk and Hybrid

Mellanox (now NVIDIA) switches running MLNX-OS / ONYX give you five switchport modes — access, access-DCB, trunk, hybrid and dot1q-tunnel — and each one has precise rules about which frames are tagged and which are dropped. Picking the wrong mode is a classic cause of "link up but no traffic" in RoCE and storage fabrics. This article explains each port type, the configuration commands, and how to verify your choices with show interfaces switchport.

The confusion usually comes from two different mental models. Engineers with a Cisco background expect "trunk" to mean "carries many VLANs, native VLAN untagged", while MLNX-OS uses "trunk" for a strictly tagged-only port and reserves "hybrid" for the mixed case. Engineers from an InfiniBand background expect ports to be routed by default. MLNX-OS is neither: every Ethernet port is a Layer 2 switchport with an explicit mode, and the mode alone decides whether a frame survives ingress.

The Five Port Types

• Access — untagged ingress only; tagged packets are dropped. The PVID is assigned on ingress. Used for switch-to-server links.
• Access-DCB — like access, but egress frames get a priority tag (VLAN ID 0). Used in lossless DCB fabrics.
• Trunk — tagged frames only; untagged frames are dropped. Multiple VLANs allowed, no PVID. Used switch-to-switch or when a server carries multiple VLANs.
• Hybrid — accepts both tagged and untagged frames; PVID applies to untagged ingress.
• Dot1q-tunnel — Q-in-Q mode for service-provider transparency.

How MLNX-OS Classifies a Frame on Ingress

Before touching any configuration, understand the three frame flavours that arrive at a port. The switch inspects the Ethernet header and sorts the frame into one of these buckets, and only then consults the port mode:

• Untagged — a plain Ethernet frame with no 802.1Q header. It belongs to the port's PVID (access VLAN).
• Priority-tagged — an 802.1Q header whose VLAN ID field is zero. It carries only a CoS/PCP value and no VLAN membership.
• Tagged — an 802.1Q header with a real VLAN ID (1–4094). It belongs to that VLAN, subject to the port's allowed-vlan list.

The port mode then decides the fate of each flavour: forward as-is, rewrite (add or strip a tag), or drop. Almost every "one direction works, the other does not" problem in a Mellanox fabric comes down to this table.

Configuration Examples

Every switchport command lives inside the interface context. Create the VLANs first so that the membership you assign actually exists in the VLAN database — MLNX-OS will accept a VLAN number on a port even when the VLAN itself is not yet defined, which produces a silently dead link.

switch (config) # vlan 10
switch (config) # vlan 100-200          # range
switch (config) # interface ethernet 1/1
switch (config interface ethernet 1/1 ) # switchport mode access
switch (config interface ethernet 1/1 ) # switchport access vlan 1

Trunk ports replace the access VLAN with an explicit allow-list. Note that a trunk port has no PVID: untagged frames — including LLDP-adjacent stray traffic and anything a host sends without a tag — are discarded at the ingress pipeline.

switch (config) # interface ethernet 1/1
switch (config interface ethernet 1/1 ) # switchport mode trunk
switch (config interface ethernet 1/1 ) # switchport trunk allowed-vlan all
switch (config interface ethernet 1/1 ) # switchport trunk allowed-vlan 100-200

Note: switchport trunk allowed-vlan all automatically includes VLANs added to the table later — watch out for silent trunk expansion.

Hybrid and PVID

Hybrid is the right answer for a server that runs a tagged VLAN for storage traffic while still needing untagged management on the same NIC. One port, both behaviours:

switch (config) # interface ethernet 1/1
switch (config interface ethernet 1/1 ) # switchport mode hybrid
switch (config interface ethernet 1/1 ) # switchport hybrid allowed-vlan 100-200
switch (config interface ethernet 1/1 ) # switchport access vlan 1   # PVID / native VLAN

Two rules are worth memorising. First, the PVID is configured with switchport access vlan even in hybrid mode — the keyword does not change. Second, the PVID VLAN must also appear in the hybrid allowed-vlan list in most ONYX builds, or untagged traffic is accepted at ingress and then dropped on egress because the VLAN is not a member of the port's egress set.

Access-DCB Mode for Lossless Fabrics

Access-DCB exists because RoCEv2 hosts need 802.1p priority marking to drive PFC, but they often have no reason to belong to a VLAN. A normal access port strips all tags on egress, which would destroy the priority information PFC depends on. Access-DCB keeps the frame untagged in terms of VLAN membership while still allowing a priority tag carrying the CoS value:

switch (config) # interface ethernet 1/2
switch (config interface ethernet 1/2 ) # switchport mode access-dcb
switch (config interface ethernet 1/2 ) # switchport access vlan 10

Use it on the host-facing ports of a RoCE storage fabric where DSCP/CoS trust and PFC are configured, and leave the uplinks in trunk mode. If you are still designing the lossless side of the fabric, the priority flow control and ECN parameters are covered in the RoCEv2 lossless Ethernet PFC and ECN guide.

Dot1q-Tunnel (Q-in-Q) for Service Transparency

Dot1q-tunnel ports take a customer frame — tagged or untagged — and push an outer tag (the tunnel VLAN, also called the S-VLAN) onto it before switching it through the provider core. The customer's own tag is preserved as the inner tag, so a customer using VLAN 5 in two different sites never collides in the provider network:

switch (config) # vlan 1000
switch (config) # interface ethernet 1/3
switch (config interface ethernet 1/3 ) # switchport mode dot1q-tunnel
switch (config interface ethernet 1/3 ) # switchport dot1q-tunnel allowed-vlan 1000

Two optional knobs are commonly used. switchport dot1q-tunnel use-vlan-tag-as-pvid derives the PVID from the outer tag instead of a fixed value, and switchport dot1q-tunnel tpid changes the outer tag protocol ID when a customer environment expects a non-standard ethertype. In a data-centre scenario you rarely need QinQ; in a metro-Ethernet handoff or a lab that emulates it, this is the only mode that does the job cleanly.

Interface Ranges and VLAN Ranges

Applying a mode to forty ports one at a time is how typos happen. MLNX-OS supports both interface ranges and VLAN ranges in the same context:

switch (config) # interface ethernet 1/1-1/24
switch (config interface ethernet 1/1-1/24) # switchport mode access
switch (config interface ethernet 1/1-1/24) # switchport access vlan 10
switch (config) # vlan 200-210
switch (config) # interface ethernet 1/49
switch (config interface ethernet 1/49) # switchport mode trunk
switch (config interface ethernet 1/49) # switchport trunk allowed-vlan 200-210,300

Ranges also accept the add and remove keywords on the allowed-vlan commands, which is far safer for an uplink that must never lose its management VLAN: switchport trunk allowed-vlan add 400 only ever grows the list.

Verification

Always confirm the mode from the switch's point of view rather than from your notes. Three commands answer the whole question:

switch (config) # show interfaces switchport
Interface  Mode    Access vlan  Allowed vlans
---------------------------------------------
Eth1/1     hybrid  1            100
Eth1/2     hybrid  1            100
Eth1/3     access  1
Eth1/5     trunk   N/A          1, 100
# show vlan
VLAN  Name     Ports
----  -------  --------------------------------
1     default  Eth1/1, Eth1/2, ...
100           Eth1/1, Eth1/5

Add show interfaces ethernet 1/1 for link state, speed and counters, and show mac-address-table to prove that the host's MAC actually learned behind the port. A port that shows the expected mode but never learns a MAC has a VLAN membership or PVID problem, not a cabling problem.

Troubleshooting: Symptom to Cause

• Link is up, no traffic at all. Trunk port facing a host that sends untagged frames — the frames are dropped at ingress. Switch the port to hybrid or access.
• Traffic works one way only. Classic tag mismatch: the remote side tags, the local trunk's allowed-vlan list does not include that VLAN. Check show interfaces switchport on both ends.
• Server can reach its gateway but not other VLANs. Port is access; the server thinks it is trunking. Check the NIC's VLAN settings.
• RoCE traffic loses priority / PFC storms. Host port is plain access and strips the priority tag — switch it to access-dcb.
• Whole rack dies when a new VLAN is added. Someone used allowed-vlan all on an uplink. Replace it with an explicit range.

Choosing Between Hybrid and Trunk

The two multi-VLAN modes overlap enough that the choice is often made for the wrong reason. Ask a single question: does anything on this link need to be untagged?

If the answer is no — a switch-to-switch link, or a server NIC configured with explicit 802.1Q sub-interfaces for every VLAN it uses — use trunk. It is stricter and therefore safer: a misconfigured host that leaks untagged frames shows up immediately as a dead port instead of silently joining the native VLAN.

If the answer is yes — a hypervisor management interface that expects to be untagged on VLAN 1 while storage traffic is tagged on VLAN 100 — use hybrid. You trade away the strictness that makes trunk self-documenting, so write the PVID down in the change ticket and in your configuration notes.

How Port Modes Interact with LAG, PFC and Routing

Port mode is the first layer; several other features sit on top of it and all of them assume the mode is correct.

• LAG / LACP — every member port must be in the same mode, with the same allowed-vlan list and the same PVID. One mismatched member produces a link that works fine until the first hashed frame lands on the odd port out. Details are in the LAG and LACP configuration guide.
• Lossless / PFC — PFC operates on CoS values, which only exist if the port preserves or adds a priority tag. Plain access ports strip them; access-dcb and hybrid ports keep them intact.
• VLAN interfaces and routing — a Layer 3 VLAN interface only carries traffic for VLANs that at least one port actually admits. If a routed SVI is up but forwards nothing, check port membership before touching the IP configuration.
• MLAG / MC-LAG pairs — both peers must present an identical view of port mode and VLAN membership, or the peer-link will carry inconsistent forwarding state.

Persisting the Change

None of the above survives a reload until it is written to the active configuration file. In Config mode run configuration write, or in Enable mode run write memory. Named snapshots, factory resets and file switching are covered in the MLNX-OS configuration management guide, and CLI navigation between modes is explained in the NVIDIA MLNX-OS CLI modes and commands guide. If you are wiring Layer 3 services onto these VLANs, continue with VLAN interfaces and IP routing setup, and for link aggregation across two ports see LAG and LACP configuration. New to the platform? Start with the MLNX-OS first-time setup wizard walkthrough.

原文链接：https://enterprise-support.nvidia.com/s/article/howto-configure-switch-port-types-with-mlnx-os