Cisco vPC vs Dell VLT: MLAG Explained

Colleagues often ask how Cisco vPC, Dell VLT, switch stacking and an ordinary port-channel differ. This article answers that in one place: why MLAG exists, how the three designs compare, how vPC and VLT work and fail, worked configurations for both, and notes for teams moving from Dell VLT to Cisco vPC.

Why MLAG exists

A standard port-channel (IEEE 802.3ad / 802.1AX link aggregation, usually negotiated with LACP) can only bundle links that end on one switch. When an access switch is dual-homed to two upstream switches for redundancy, its two uplinks are separate links, so Spanning Tree Protocol (STP) must block one of them to stop a loop. Half the uplink bandwidth sits idle until something fails.

Multi-Chassis Link Aggregation (MLAG) removes that limit. Two independent switches cooperate so that links landing on both of them look like a single port-channel to the device below. With no loop to break, STP blocks nothing and every link forwards. Cisco vPC and Dell VLT are each vendor’s implementation of MLAG.

On the left, STP keeps one uplink in blocking state. On the right, the two upstream switches act as one LACP partner, so both uplinks join one port-channel and both carry traffic.

Stack vs normal port-channel vs MLAG port-channel

To the access switch at the bottom, all three look identical: one port-channel. The difference is entirely upstream, in how many switches the bundle lands on and how many brains run them.

The blue ring marks the single logical bundle the access switch sees in every case.

In one sentence each: a normal port-channel adds bandwidth and link redundancy; a stack turns many switches into one; MLAG keeps two switches separate but lets them share a port-channel. A downstream device needs nothing special for any of them: standard LACP (or a static bundle) is enough.

What vPC and VLT are

Cisco vPC (virtual Port Channel) is the MLAG feature of Cisco Nexus switches running NX-OS (Nexus 9000, 7000, 5000 and 3000). Cisco places it in the Multichassis EtherChannel family: links physically connected to two Nexus switches appear as one port-channel to a third device, which can be a switch, a server or anything that supports link aggregation. vPC is not available on Catalyst (IOS-XE) switches; the Catalyst equivalent is StackWise Virtual, which merges two switches into one logical switch with a single control plane.

Dell VLT (Virtual Link Trunking) is the MLAG feature of Dell PowerSwitch, inherited from Force10. It runs on Dell Networking OS9 and on SmartFabric OS10. The two VLT peers share Layer 2 information, and the same VLT domain ID is configured on both.

Both do the same job with different words. This table maps each building block:

The roles matter only when something fails. Dell states plainly that the VLT role has no significance for data traffic; it decides which peer backs off in a split. Cisco uses the vPC role the same way, to define what each peer does when the peer-link goes down.

How it works

Each peer stays a complete, separate switch. MLAG adds four things on top: one shared identity toward the downstream device, constant state sync, a separate liveness check, and a rule that prevents loops.

1. One LACP identity. Both peers advertise the same LACP system identity on the MLAG port-channel, so the downstream device thinks it has one partner and bundles every link. On vPC this identity is derived from the vPC domain; on VLT it is the VLT MAC. Dell notes that without a configured vlt-mac, the VLT port-channels on the secondary flap briefly if the primary goes down, which is why it recommends setting one.
2. State sync over the peer-link. The peers exchange MAC address tables, member-port states and IGMP snooping data, and optionally ARP tables (ip arp synchronize on Nexus). vPC consistency-check messages also travel over the peer-link. OS10 reserves VLAN 4094 internally as the VLT control VLAN.
3. Local forwarding first. A peer always forwards out its own links when it can. In steady state the peer-link carries little user data; Cisco describes it as an extension of the control plane. It carries data mainly to reach orphan ports or when one side of a port-channel is down.
4. Loop prevention. Cisco documents the rule shown above: traffic that arrived on a vPC member port and crossed the peer-link may not leave on another vPC member port, only on orphan or Layer 3 ports. The only exception is when the first peer’s own member port in the destination vPC is down, leaving the peer-link as the only path. Any MLAG implementation, VLT included, needs an equivalent safeguard or the downstream device would receive duplicate frames.
5. Separate liveness check. The keepalive (Cisco) or heartbeat (Dell) runs over a different path, normally the out-of-band management network. Its only job is to answer one question when the peer-link drops: is the peer dead, or just unreachable over the peer-link? On OS10 the heartbeat interval is 1 to 30 seconds (default 30), and when the VLTi fails the switch checks the heartbeat at once instead of waiting for the next interval.
6. Roles. One peer is primary, the other secondary. The role decides who backs off in a failure, not who forwards traffic. On both platforms the election is not preemptive: a recovered primary returns as secondary unless you intervene.
7. Consistency checks. vPC compares configuration between peers. A Type 1 mismatch (for example STP mode or port-channel settings) suspends the affected vPCs; with graceful consistency check, enabled by default, only the secondary suspends them. A Type 2 mismatch only logs a warning. On VLT, show vlt <id> mismatch lists differences, and both peers must run the same OS10 version.

Spanning Tree keeps running on both platforms as a safety net. It no longer decides which links forward, but it still catches a loop caused by miscabling or a misconfiguration.

Advantages

The headline benefit is that redundancy stops costing bandwidth: every uplink forwards, and losing a link or a whole switch does not depend on Spanning Tree to recover.

• No STP-blocked links. All uplinks forward at once, so a dual-homed device gets the bandwidth of every link it has.
• Switch-level redundancy for a single port-channel. A plain port-channel survives a link failure; an MLAG port-channel also survives the loss of an entire upstream switch.
• Fast failover. When a link or peer fails, the downstream device simply rehashes flows onto the links still in the bundle. Dell’s OS10 adds Graceful LACP: before a VLT peer takes its ports down, it warns the downstream device through LACP so traffic moves first.
• Active-active gateways. Both peers route for the default gateway, so a packet is routed by the switch it arrives on instead of crossing the peer-link. On vPC, HSRP and VRRP already forward on both peers, and peer-gateway extends this to frames sent to the other peer’s own MAC. On VLT, peer-routing lets each peer route on behalf of the other.
• Fault isolation. Each peer has its own control plane, so a software fault on one peer stays on that peer. This is the main advantage over a stack.
• Upgrades one switch at a time. You upgrade and reload one peer while the other carries all traffic. On Nexus, Cisco recommends ISSU, done sequentially; NX-OS locks the other peer’s configuration while one peer upgrades.
• Nothing special downstream. Access switches, servers, firewalls and storage need only standard LACP (or a static bundle). They never know two switches are involved.
• Standard ports between the peers. The peer-link and keepalive use ordinary Ethernet and IP, not proprietary stacking hardware, so the peers can sit in different racks.

The trade-off is operational: you manage two switches, keep their configurations consistent, and must understand the failure behaviour in the next section.

Reliability and failure behaviour

Both are mature, widely deployed technologies, and both handle any single failure without a full outage. Their weak point is the same: a double failure that cuts the peer-link and the keepalive at the same time while both switches stay alive. Reliability therefore depends as much on design and testing as on the feature itself.

This is the case the keepalive exists for. Because Peer B can still see Peer A over the management network, it knows A is alive and backs off, so only one switch forwards for the dual-homed devices and no loop forms.

Two Cisco features worth knowing. auto-recovery covers the case where the peer-link fails first and the primary then dies: after three missed keepalives the secondary takes over and brings its vPCs back up. It also lets a switch that boots alone bring up its vPCs after a reload delay (240 s by default). Cisco recommends enabling it. On Nexus, vpc orphan-port suspend can shut chosen orphan ports along with the vPCs, so active/standby devices fail over instead of being stranded.

Design rules that keep it reliable:

• Build the peer-link from at least two links, spread across line cards or port groups where the platform has them. On OS10, Dell recommends a static VLTi (no LACP) and does not support a VLTi over 1G ports.
• Never run the keepalive or heartbeat over the peer-link. Use the out-of-band management network so a peer-link failure cannot also take down the keepalive.
• Keep both peers on the same software version (Dell requires this) and the same configuration for anything that is consistency-checked.
• Set a vlt-mac on VLT and enable auto-recovery on vPC.
• Test every failure scenario before going live. Dell documents a case where an administrator shut the VLTi and the VLT port-channel on the primary while the heartbeat stayed up. The secondary saw a VLTi failure with a live peer, shut its own VLT port-channel as designed, and the network went fully down.

Limitations and design considerations

MLAG solves dual-homing well, but it is not free and it does not scale on its own. Know these limits before you commit to it.

• Two peers only. A vPC or VLT domain always has exactly two switches. Growing beyond that means more pairs, each a separate domain, or a leaf-spine fabric.
• Same vendor, same family, same software. Both peers of a domain must come from the same vendor, and Dell requires the same OS10 version on both. You cannot mix a Nexus and a PowerSwitch in one domain.
• More to operate. There are two configurations to keep consistent. On vPC a Type 1 mismatch suspends vPCs, so a careless change on one peer can take ports down.
• Orphan ports are the weak spot. A device connected to only one peer loses its path when the peer-link fails and it sits on the secondary. Dual-home everything that matters.
• Routing over MLAG needs care. Forming a routing protocol adjacency with a router that is itself attached over a vPC is a special case on Nexus. It needs peer-gateway plus layer3 peer-router on both peers; check the release notes for your NX-OS version.
• Split-brain is possible. If the peer-link and the keepalive fail together while both switches stay up, both act as primary. Good design makes this unlikely but cannot make it impossible.
• The peer-link costs ports. It needs at least two high-speed links. Cisco’s vPC Fabric Peering can replace the physical peer-link with a path through the leaf-spine fabric in VXLAN EVPN designs.

In large data-centre fabrics, EVPN multihoming (ESI-LAG) is a standards-based alternative that dual-homes devices without a dedicated peer-link. For a two-switch top-of-rack or aggregation pair, vPC and VLT remain the simpler choice.

Configuration example: Cisco Nexus vPC

This builds a vPC domain on two Nexus 9000 switches and connects one access switch with a vPC. Configure the keepalive before the peer-link, so the pair can tell a link failure from a dead peer from the first moment.

Both peers use the same port numbers. N9K-1 is made primary with the lower role priority.

feature lacp
feature vpc

vlan 10,20

spanning-tree vlan 10,20 priority 4096

interface mgmt0
  vrf member management
  ip address 10.0.0.1/24

vpc domain 10
  role priority 100
  peer-keepalive destination 10.0.0.2 source 10.0.0.1 vrf management
  peer-switch
  peer-gateway
  auto-recovery
  ip arp synchronize

interface port-channel10
  description vPC peer-link
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 10,20
  spanning-tree port type network
  vpc peer-link

interface Ethernet1/49-50
  description vPC peer-link members
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 10,20
  channel-group 10 mode active
  no shutdown

interface port-channel20
  description vPC 20 to ACCESS-SW1
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 10,20
  vpc 20

interface Ethernet1/1
  description ACCESS-SW1 Gi1/0/49
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 10,20
  channel-group 20 mode active
  no shutdown

N9K-2 is identical except for these lines:

interface mgmt0
  vrf member management
  ip address 10.0.0.2/24

vpc domain 10
  role priority 200
  peer-keepalive destination 10.0.0.1 source 10.0.0.2 vrf management

interface Ethernet1/1
  description ACCESS-SW1 Gi1/0/50

ACCESS-SW1 (a Catalyst running IOS-XE here, but any switch with LACP works):

interface range GigabitEthernet1/0/49 - 50
 description Uplinks to N9K-1 and N9K-2
 switchport mode trunk
 switchport trunk allowed vlan 10,20
 channel-group 1 mode active
!
interface Port-channel1
 switchport mode trunk
 switchport trunk allowed vlan 10,20

What the vPC domain commands do:

Verify on either peer:

show vpc brief
show vpc peer-keepalive
show vpc consistency-parameters global
show vpc consistency-parameters vpc 20
show port-channel summary

In show vpc brief, a healthy domain reports peer adjacency formed ok, peer is alive for the keepalive, success for configuration consistency, and vPC 20 as up.

Configuration example: Dell OS10 VLT

The same design on two Dell PowerSwitches running SmartFabric OS10. VLT needs less configuration than vPC: you name the VLTi ports with discovery-interface and OS10 builds the interconnect port-channel (Po1000) itself.

The VLTi ports must be taken out of Layer 2 mode (no switchport) before they are used as discovery interfaces. If you run RSTP or RPVST+ with non-default settings, configure them before VLT.

interface mgmt1/1/1
 no ip address dhcp
 ip address 10.0.0.1/24
 no shutdown
!
interface vlan10
 no shutdown
!
interface vlan20
 no shutdown
!
interface range ethernet1/1/49-1/1/50
 description VLTi
 no switchport
 no shutdown
!
vlt-domain 10
 backup destination 10.0.0.2
 discovery-interface ethernet1/1/49-1/1/50
 primary-priority 4096
 vlt-mac 00:11:22:33:44:10
!
interface port-channel20
 description VLT 20 to ACCESS-SW1
 no shutdown
 switchport mode trunk
 switchport trunk allowed vlan 10,20
 vlt-port-channel 20
!
interface ethernet1/1/1
 description ACCESS-SW1 Gi1/0/49
 no shutdown
 channel-group 20 mode active

VLT-2 is identical except for these lines:

interface mgmt1/1/1
 ip address 10.0.0.2/24
!
vlt-domain 10
 backup destination 10.0.0.1
 primary-priority 8192
!
interface ethernet1/1/1
 description ACCESS-SW1 Gi1/0/50

ACCESS-SW1 uses exactly the same configuration as in the Cisco example; it cannot tell the difference.

If the VLAN interfaces carry IP addresses and act as gateways, add peer-routing under vlt-domain so each peer routes on behalf of the other.

Verify on either peer:

show vlt 10
show vlt 10 backup-link
show vlt 10 vlt-port-detail
show vlt 10 mismatch

A healthy domain shows the VLTi and the VLT peer as up, Peer Heartbeat status : Up in the backup-link output, port-channel 20 up on both units, and no entries under mismatch.

Migrating from Dell VLT to Cisco vPC

The concepts carry over one to one; the differences are in defaults, strictness and what you must configure by hand.

A practical cutover approach. Build and test the new Nexus vPC pair first. Then join it to the existing VLT pair with one port-channel of four links: a VLT port-channel on the Dell side and a vPC on the Cisco side. Each pair presents one LACP identity, so the four links form one loop-free bundle; Cisco documents this pair-to-pair design as double-sided vPC. Keep the STP root where it is, move downstream devices across one at a time, and use different domain IDs on the two pairs.

Equivalent technologies from other vendors

Every major switch vendor offers the same capability under its own name. Two of them (Catalyst StackWise Virtual and HPE IRF) solve the same problem by merging switches into one, like a stack, rather than with MLAG.

Each vendor’s MLAG is proprietary (IEEE 802.1AX-2014 defines a standard alternative called DRNI, but vPC and VLT do not use it), so a vPC peer cannot pair with a VLT peer inside one domain. Both peers of a domain must be the same vendor. Between domains, only standard LACP is exchanged, which is why mixed-vendor pairs connect to each other without trouble.

Choosing the right design

None of the three replaces the others. Each answers a different question, and many networks use all three.

The short version for colleagues: a port-channel bundles links, a stack merges switches, and MLAG lets two separate switches share a port-channel. vPC is Cisco’s MLAG and VLT is Dell’s; they work the same way and differ mainly in commands, defaults and how strictly they check configuration.

References

Cisco

• Understand and Configure Nexus 9000 vPC with Best Practices
• Understanding the vPC Election Process
• Nexus 7000 vPC Auto-Recovery Configuration Example
• Nexus 5000 vPC Operations: consistency checks
• vPC failure scenarios and troubleshooting checklist (Cisco Community)

Dell

• SmartFabric OS10: How to Set Up Virtual Link Trunking
• SmartFabric OS10 VLT Layer 2 Reference Architecture
• OS10 VLT Reference Architecture: peer liveliness check
• OS10 VLT Reference Architecture: delay-restore
• OS10 VLT Reference Architecture: Graceful LACP
• VLT failover test behaviour

Command syntax and defaults vary between software releases. Check the configuration guide for your exact NX-OS or OS10 version before deploying.