Administrator Guide

Port Monitoring on VLT
Devices on which VLT is configured are seen as a single device in the network. You can apply port monitoring function on the
VLT devices in the network.
Port monitoring enables ingress or egress traffic traversing on a port to be sent to another port so that the traffic can be
analyzed. The port to which traffic is sent for analysis is called the mirroring port. This port is connect to a port analyzer, which
performs the traffic analysis function.
Depending up on the location of the port to which the port analyzer is connected, port monitoring is classified into three
categories: local Port mirroring, remote port mirroring (RPM), and encapsulated remote port mirroring (ERPM).
NOTE: For more information on port monitoring, see Port Monitoring.
The port monitoring or mirroring function when applied to VLT devices works as expected except with some restrictions. You
can configure RPM or ERPM monitoring between two VLT peers. As VLT devices are seen as a single device in the network,
when a fail over occurs, the source or destination port on one of the VLT peers becomes inactive causing the monitoring session
to fail. As a result, Dell Networking OS does not allow local Port mirroring based monitoring to be configured between VLT
peers. However, you can create local Port mirroring monitoring sessions separately on individual devices that are a part of the
VLT configuration.
NOTE: For more information on configuring VLT, see Configuring VLT on page 1035.
VLT Non-fail over Scenario
Consider a scenario where port monitoring is configured to mirror traffic on a VLT device's port or LAG to a destination port on
some other device (TOR) on the network. When there is no fail over to the VLT peer, the VLTi link (ICL LAG) also receives the
mirrored traffic as the VLTi link is added as an implicit member of the RPM vlan. As a result, the mirrored traffic also reaches the
peer VLT device effecting VLTi link's bandwidth usage.
To mitigate this issue, the L2 VLT egress mask drops the duplicate packets that egress out of the VLT port. If the LAG status of
the peer VLT device is OPER-UP, then the other VLT peer blocks the transmission of packets received through VLTi to its port
or LAG. As a result, the destination port on the device to which the packet analyzer is connected does not receive duplicate
mirrored packets.
VLT Fail-over Scenario
Consider a scenario where port monitoring is configured to mirror traffic on the source port or LAG of a VLT device to a
destination port on an other device on the network. A fail-over occurs when the primary VLT device fails causing the secondary
VLT device to take over. At the time of failover, the mirrored packets are dropped for some time. This time period is equivalent
to the gracious VLT failover recovery time.
RPM over VLT Scenarios
This section describes the restrictions that apply when you configure RPM in a VLT set up. Consider a simple VLT setup where
two VLT peers are connected using VLTi and a top-of-rack switch is connected to both the VLT peers using VLT LAGs in a ring
topology. In this setup, the following table describes the possible restrictions that apply when RPM is used to mirror traffic:
Table 71. RPM over VLT Scenarios
Scenario RPM Restriction Recommended Solution
Mirroring an Orphan Port on a VLT LAG
— In this scenario, the orphan port on a
VLT device is mirrored to the VLT LAG
that connects a top-of-rack (TOR)
switch to the VLT device. The packet
analyzer is connected to the TOR
switch.
The bandwidth of the VLTi link is
unnecessarily used by mirrored traffic if
max rate limit value is configured in the
RPM mirror session.
Use ERPM session instead of RPM.
Port Monitoring 751