Dell OS10 Port Monitoring (SPAN) Configuration Guide - 夜莺博客

Dell OS10 Port Monitoring (SPAN) Configuration Guide

When an application team says packets are being dropped somewhere in the leaf-spine fabric, a packet capture on the Dell PowerSwitch is often the fastest way to end the argument. SmartFabric OS10 supports three mirroring flavours — local port monitoring, remote port monitoring (RPM) over a Layer 2 transport VLAN, and encapsulated remote port monitoring (ERPM) over Layer 3 — and this guide covers the CLI workflow for each, the hard session limits you have to design around, and how to verify that mirrored traffic is actually leaving the switch.

Local port monitoring: the everyday case

A monitoring session has one destination port (where the copy goes) and up to 108 source ports. Direction is chosen per source port with rx, tx or both.

OS10# configure terminal
OS10(config)# monitor session 1
OS10(conf-mon-local-1)# source interface ethernet 1/1/7-1/1/8 rx
OS10(conf-mon-local-1)# destination interface ethernet 1/1/48
OS10(conf-mon-local-1)# no shutdown
OS10(conf-mon-local-1)# end

OS10# show monitor session 1
OS10# show monitor session all

Two rules that catch people out. First, the destination port must be a plain switchport — if it is still configured as an L2/L3 port, OS10 rejects the configuration with "destination port should not be a L2/L3 port". Second, mirrored traffic consumes bandwidth on the destination port with no rate limit, so a 10G capture port fed by four busy 10G sources will simply drop copies. Capture with a filter, not a shotgun.

Remote port monitoring (RPM) for other switches

When the analysis tool sits on a different switch, OSC10 carries the mirrored frames in a dedicated transport VLAN across the Layer 2 network.

# On the switch with the traffic (source switch)
OS10(config)# monitor session 2
OS10(conf-mon-local-2)# source interface ethernet 1/1/1 both
OS10(conf-mon-local-2)# source remote-vlan 300

# On the switch where the analyser is cabled (destination switch)
OS10(config)# monitor session 2
OS10(conf-mon-local-2)# destination interface ethernet 1/1/20
OS10(conf-mon-local-2)# destination remote-vlan 300

Configuration order matters on most PowerSwitch platforms: add the destination remote VLAN first, then the source. If you configure the source first, OS10 accepts the command silently and the session never passes traffic. Also note that overwriting a transport VLAN requires removing it with the no form before re-entering the new VLAN ID.

Session limits you should design around

Limit Value
Sessions with bidirectional mirroring 2
Sessions with ingress-only or egress-only mirroring 4 (four unique destination ports)
Maximum source ports per session 108
Destination ports per session 1
Interfaces per RPM VLAN (S4148F-ON) 4 bidirectional, 4 unidirectional
Interfaces per RPM VLAN (other platforms) 2 bidirectional, 4 unidirectional

What port monitoring will not show you

Control-plane packets generated in software by the switch CPU are not mirrored: ARP replies, ICMP replies and PTP delay-response/Announce/Sync frames never appear in the capture. If you are chasing a PTP or control-plane problem, run a capture from the OS10 Linux shell instead:

OS10# system bash
$ sudo tcpdump -i any -nn -s 256 port 320

Remote monitoring also has platform caveats worth knowing before a maintenance window: VLAN statistics for the RPM VLAN are not incremented on S4048-ON, S4048T-ON, S4100-ON, S6010-ON and Z9264F-ON (so show interface vlan <id> looks empty even when mirroring works), destination LAG is unsupported on Z9664F-ON, and the feature is absent on N3248TE-ON and Z9332F-ON.

Verification checklist

  1. show monitor session all — confirm source, destination and direction as expected.
  2. Confirm the destination port is operationally up and, for RPM, in the transport VLAN.
  3. On the analyser, verify frames arrive (a simple protocol counter is enough — no need for a full decode).
  4. Check the destination port for egress drops: show interface ethernet 1/1/48 | grep -i discard.
  5. Tear the session down when finished: no monitor session 1. Mirrored sessions survive a config save and have caused more than one "why is this port busy at 3am" ticket.

Keep a small runbook of which session IDs are reserved for which team. OS10 gives you four unidirectional sessions and no more, and the fastest way to break an existing capture during an incident is to grab the last free ID.

Related Reading on This Site

原文链接:https://www.dell.com/support/manuals/en-vn/smartfabric-os10-emp-partner/smartfabric-os-user-guide-10-5-4/port-monitoring?guid=guid-b951a342-5d04-4fd1-873e-976a654e1104&lang=en-us (Dell SmartFabric OS10 User Guide 10.5.4)