Users Guide

View VLT information
To monitor the operation or verify the configuration of a VLT domain, use a VLT show command on primary and secondary
peers.
● View detailed information about the VLT domain configuration in EXEC mode, including VLTi status, local and peer MAC
addresses, peer-routing status, and VLT peer parameters.
show vlt domain-id
● View the role of the local and remote VLT peer in EXEC mode.
show vlt domain-id role
● View any mismatches in the VLT configuration in EXEC mode.
show vlt domain-id mismatch
● View detailed information about VLT ports in EXEC mode.
show vlt domain-id vlt-port-detail
● View the current configuration of all VLT domains in EXEC mode.
show running-configuration vlt
Delay-restore for orphan ports
The delay-restore feature for non-VLT ports is used to delay the bring up of non-VLT ports; so that, there is enough time
available for the protocols and features to converge. If there is no such mechanism available, then traffic may get blocked.
This feature is similar to VLT delay-restore mechanism for VLT LAGs, which is already supported. The delay-restore mechanism
is applicable to the following two scenarios:
● VLT peer reload - When the reloaded node joins as a secondary node in the VLT domain or fabric, VLT LAGs are brought up
only after delay-restore timer expires.
● VLTi link failure - When the VLT heart beat is configured and is up and running, if VLTi link goes down, the secondary VLT
peer brings down its local VLT LAGs. All devices connected to the VLT LAG interfaces are expected to send or receive
traffic through the VLT primary device. When the VLTi link comes back up, the secondary VLT peer does not bring its VLT
LAG up immediately. They are brought up only after VLT delay-restore timer expires, assuming that heart-beat is up.
There are two sets of configurations, one for non-VLT deployments and the other for VLT deployments.
Delay-restore port (DRP for non-VLT deployments)
Delay-restore port is used for non-VLT deployments. The configured ports are kept down on system boot up (after a reload)
and are brought up only after the configured delay-restore port timer expires. The VLT delay-restore timer that controls the VLT
LAGs also controls the orphan ports.
Delay-restore orphan port (DROP for VLT deployments)
The delay-restore for orphan ports feature extends the support of delay-restore timer for the VLT LAGs to orphan ports. The
timer corresponding to the VLT LAG also control the orphan-ports. When delay-restore orphan port is configured, the orphan
port is treated just like VLT LAGs during VLT peer reload and VLTi link failure scenarios.
Restrictions and Limitations
Both delay-restore port and delay-restore orphan port configurations are only supported on physical and LAG interfaces with
the following exceptions:
● VLT LAGs
● VLTi link (VLTi LAG)
● VLT discovery interfaces (VLTi members)
● LAG member ports
● Management port
● FC ports
Virtual Link Trunking
1641