Dell OS10 VLT Peer Routing: Active-Active Layer 3 Gateway

Dell SmartFabric OS10 does not support stacking; instead, two identical physical switches are paired with Virtual Link Trunking (VLT) to act as one logical switch. By default that virtual switch is still a Layer 2 construct, which means routed traffic often has to cross the VLT interconnect (VLTi) to reach the peer that owns the gateway MAC. VLT peer routing removes that hairpin by letting each peer locally route traffic destined to the other peer's Layer 3 endpoint. This guide walks through the full VLT foundation and then enables peer routing for an active-active default gateway.

VLT Foundation: Domain, VLTi and Port Channel

Before peer routing can work, the VLT domain must be healthy. Start by removing switchport mode from the VLTi ports and creating the domain with the same ID on both peers:

OS10# configure terminal
OS10(config)# interface range ethernet 1/1/1-1/1/2
OS10(conf-range-eth1/1/1-1/1/2)# no switchport
OS10(config)# vlt-domain 1
OS10(conf-vlt-1)# discovery-interface ethernet 1/1/1
OS10(conf-vlt-1)# discovery-interface ethernet 1/1/2

Then set the primary/secondary roles with primary-priority (for example 4096 on the primary peer and 8192 on the secondary), configure a backup link over the out-of-band management network, and build the LAG toward the downstream device. Keep spanning-tree enabled: RPVST+ (default) or RSTP is supported on VLT ports and prevents loops in the VLT domain.

The full sequence from an empty configuration to a working VLT pair is:

The downstream device-side configuration is ordinary LACP, and the vlt-port-channel keyword is what makes the port channel a VLT port channel rather than a local one:

OS10(config)# interface port-channel 5
OS10(conf-if-po-5)# vlt-port-channel 5
OS10(conf-if-po-5)# exit
OS10(config)# interface ethernet 1/1/10
OS10(conf-if-eth1/1/10)# channel-group 5 mode active
OS10(config)# interface ethernet 1/1/10
OS10(config-if)# description uplink-to-server-rack

Note that the VLTi itself is presented internally as port-channel1000; when a forwarding problem occurs, that is the interface whose state you are actually reading in the status output. In a healthy pair it is always up, and losing it is a domain-level event rather than a single-link failure.

Spanning Tree and the VLT Domain

Spanning tree is enabled by default on OS10 and should remain enabled even on a healthy VLT pair. The default mode is Rapid per-VLAN Spanning Tree (RPVST+), and both peers must run the same mode:

OS10# configure terminal
OS10(config)# spanning-tree mode rapid-pvst
! or, for a single topology:
OS10(config)# spanning-tree mode rstp
OS10# show spanning-tree active
OS10# show spanning-tree interface ethernet 1/1/10

VLT ports are treated as a single logical port by spanning tree, so the downstream LAG appears once in the topology and does not block. If you see one member of a downstream LAG in a blocking state, the VLT port channel is not recognised as such - which nearly always traces back to a mismatched LAG number or a missing vlt-port-channel statement on one of the two peers.

Enabling VLT Peer Routing

Peer routing is enabled inside the VLT domain configuration on both nodes and is applied domain-wide rather than per VLAN or per routing protocol:

OS10# configure terminal
OS10(config)# vlt-domain 1
OS10(conf-vlt-1)# peer-routing enable
OS10(conf-vlt-1)# exit
OS10(config)# exit
OS10# show vlt 1 detail

One correction worth making explicitly, because older documentation and the OS9 lineage both contribute to the confusion: in current OS10 the command takes no parameter. peer-routing enable is accepted in some releases for compatibility, but the documented syntax is simply peer-routing, and the command reference states it as "Syntax: peer-routing · Parameters: None · Default: Disabled · Command Mode: VLT-DOMAIN", supported from release 10.2.0E onwards. If the switch rejects the keyword, drop the enable:

OS10(config)# vlt-domain 1
OS10(conf-vlt-1)# peer-routing
OS10(conf-vlt-1)# no peer-routing        ! disable again
OS10# show running-configuration vlt

Peer routing synchronizes the router MAC address across the VLT domain, so a server can send a frame to either peer's gateway MAC and the packet is forwarded locally without crossing the VLTi. The result is an active-active Layer 3 gateway with no dependence on VRRP for normal forwarding.

What Peer Routing Actually Changes

It helps to be precise about the problem being solved. In a VLT pair without peer routing, both peers share one gateway IP, but the router MAC that hosts ARP for is owned by one of them - normally the primary. A host connected through the secondary peer therefore sends its default-gateway frames to the secondary, which notices the destination MAC is the peer's and forwards the frame across the VLTi for the primary to route. Every routed packet makes the round trip, consuming VLTi bandwidth and adding latency, and the VLTi becomes a throughput ceiling for the whole rack.

Two behaviours change once peer routing is enabled:

• Local forwarding. Each peer recognises the shared router MAC as its own and routes the packet locally, using its own routing table and its own uplinks. Nothing crosses the VLTi for normal north-south traffic.
• Shared ARP ownership. Both peers respond for the router MAC, so a host behind the secondary is served by the secondary. The peer-routing timeout timer (visible as Peer-Routing-Timeout timer in show vlt output) governs how long a peer continues to answer and forward on behalf of the other after the peer link fails.

Because the routing table itself is still per-peer, the two switches must independently reach the same conclusions about where traffic goes. That is why the symmetric-configuration rules below are not stylistic preferences - a routing table that differs between peers produces a black hole that only affects hosts on one side of the pair.

Design Rules and Restrictions

• Both VLT peers must operate in Layer 3 mode for VLT unicast routing to be enabled.
• VLAN configuration must be symmetrical on both peers: you cannot configure the same VLAN as Layer 2 on one node and Layer 3 on the other.
• Peer routing supports IPv4 and IPv6 unicast; it is not restricted to VLANs running a dynamic routing protocol.
• If the peer link is lost, traffic behavior depends on the VLT failure mode (primary/secondary election), which is why the backup link and consistent priority settings matter.
• Both peers must run the same OS10 version, and each VLT domain in the network needs its own unique vlt-mac - identical on the two members of a pair, unique across pairs.
• Keep the peer-routing configuration symmetric: enabling it on one peer only leaves the other hairpinning through the VLTi, and the mismatch is reported by the switch.

Symmetry is checked, not assumed. OS10 exposes a dedicated consistency report that should be run after every change and after every firmware upgrade:

OS10# show vlt 1 mismatch
Peer-routing mismatch: No mismatch
VLAN mismatch: No mismatch
VLT VLAN mismatch: No mismatch

A "Peer-routing mismatch" line here is the fastest explanation for an active-active gateway that works from one rack and not the other. "VLAN mismatch" points at a VLAN configured on one peer only; "VLT VLAN mismatch" points at a VLAN treated as Layer 2 on one side and Layer 3 on the other.

Routing Protocols on Both Peers

When both peers route their own traffic and each keeps a default route to the upstream, static or dynamic routing (OSPF/BGP) must be configured on both nodes so the upstream sees consistent next hops. See how the concept compares to multi-chassis designs in our Arista EOS MLAG peer-link and domain setup article.

Two practical patterns cover most deployments:

• Routing over the VLT port channel. The upstream device sees one logical LACP bundle terminating on two peers and forms a single routing adjacency with the gateway IP. Cleanest for a single upstream pair, and it removes the need to advertise per-peer links.
• Per-peer routed uplinks plus a loopback. Each VLT peer has its own routed link to the fabric and advertises a loopback with the gateway address. More adjacencies to manage, but resilient in a way that does not depend on the LAG staying bundled.

Whichever pattern you choose, the requirement is that both peers arrive at equivalent forwarding state. Verify with the routing protocol's own show commands on both switches; a route present on the primary and absent on the secondary produces exactly the intermittent failure that peer routing is supposed to eliminate.

Verification and Monitoring

OS10# show vlt 1
OS10# show vlt 1 detail
OS10# show vlt mac-inactive
OS10# show vlt role
OS10# show lacp port-channel 1
OS10# show vlt 1 vlt-port-detail
OS10# show vlt backup-link
OS10# show running-configuration vlt

Confirm the VLT role shows primary on one node and secondary on the other, verify the VLTi is in the up state, and check that the downstream LAG bundles on both peers. If peer-routing traffic is not forwarding, confirm the VLT peer-routing status is enabled on both switches and that the VLANs exist as Layer 3 on both peers. For more background on the underlying LAG mechanics on OS10, read our guide to Dell OS10 port-channel and LACP configuration.

The field to look for first in show vlt 1 is Peer-Routing - it reads Enabled or Disabled, and it reports the local switch's view only. Reading it on one peer tells you nothing about the other, which is the single most common reason a half-configured domain is mistaken for a working one.

Failure Modes and Troubleshooting

• Traffic still hairpins across the VLTi: peer routing is disabled or enabled on only one peer. Check show vlt 1 mismatch.
• One direction of traffic fails: asymmetric VLAN or routing state between peers. The mismatch report and a side-by-side show running-configuration vlt comparison usually identify it immediately.
• VLT domain will not come up: mismatched VLT MAC, different domain IDs, differing OS10 versions, or a VLTi port still in switchport mode.
• Peer link down but both peers active: a dual-primary condition; the switch reports the peer state and the secondary should suppress its VLT-facing ports. Confirm the backup link heartbeat is reachable out of band - if the management path is also down, the two peers cannot arbitrate.
• Downstream LAG has only one member active: the LACP timers or the LAG mode differ between host and switch, or the member ports sit on different VLT peers while vlt-port-channel is missing.
• Slow north-south throughput despite peer routing: the upstream path is still asymmetric, so all return traffic is arriving on one peer and transiting the VLTi on ingress even though egress is local.

Two companion articles are worth reading before and after any change to a VLT pair: the step-by-step domain build in Dell OS10 VLT setup, and the command-by-command diagnostic walkthrough in Dell OS10 VLT troubleshooting with show vlt commands.

原文链接：https://www.dell.com/support/kbdoc/en-us/000102901/dell-emc-networking-os10-how-to-set-up-virtual-link-trunking-vlt