Port Mirroring (SPAN) Configuration on Cisco, Huawei, Arista and Juniper

Port mirroring - copying traffic from one port or VLAN to a monitoring port - is the foundation of network troubleshooting: packet capture, IDS/IPS inspection, and traffic analysis all depend on it. Every major switch OS implements it, but under different names and syntax: SPAN on Cisco, port mirroring on Huawei VRP, monitor sessions on Arista EOS, and analyzers on Junos. This guide gives you the exact commands for all four vendors so you can set up mirroring without re-reading manuals, plus a note on RSPAN for remote monitoring.

Cisco IOS: SPAN

Switch(config)# monitor session 1 source interface GigabitEthernet1/0/1 both
Switch(config)# monitor session 1 source vlan 10 rx
Switch(config)# monitor session 1 destination interface GigabitEthernet1/0/24
Switch(config)# end
Switch# show monitor session 1

both mirrors TX+RX; you can also choose rx or tx only. For RSPAN, configure a remote VLAN: monitor session 1 destination remote vlan 100 on the source switch and monitor session 1 source remote vlan 100 on the destination switch.

Huawei VRP: Port Mirroring (Observe Port)

[Huawei] observe-port 1 interface GigabitEthernet0/0/24
[Huawei] interface GigabitEthernet0/0/1
[Huawei-GigabitEthernet0/0/1] port-mirroring to observe-port 1 both
[Huawei-GigabitEthernet0/0/1] quit
[Huawei] display observe-port
[Huawei] display port-mirroring

The observe-port is the monitoring destination; multiple source ports can mirror to it. For VLAN mirroring: mirror to observe-port 1 under a VLAN view, or port-mirroring to observe-port 1 with the vlan keyword in newer VRP versions.

Arista EOS: Monitor Sessions

switch(config)# monitor session 1 source ethernet 1 both
switch(config)# monitor session 1 source ethernet 2-4 tx
switch(config)# monitor session 1 destination interface ethernet 24
switch(config)# end
switch# show monitor session
switch# show monitor session 1

EOS syntax mirrors Cisco closely but uses destination interface (no monitor session destination prefix).

Junos: Analyzers

set ethernet-switching-options analyzer MIRROR input ingress interface ge-0/0/1.0
set ethernet-switching-options analyzer MIRROR input egress interface ge-0/0/2.0
set ethernet-switching-options analyzer MIRROR output interface ge-0/0/24.0
run show ethernet-switching analyzer MIRROR

Junos uses the analyzer concept with explicit ingress/egress selection. On MX (routers) use forwarding-options port-mirroring with a port-mirroring instance instead.

How a Mirror Copy Is Made, and What It Costs

Mirroring is done in the forwarding ASIC, not in the control plane. When a frame is forwarded out of (egress) or received on (ingress) a source port, the ASIC writes an additional copy to the destination port's queues. Three properties follow from that, and all three bite people who treat the monitoring port like a normal port:

• The source port's forwarding is unaffected — a saturated mirror does not slow down production traffic on the source.
• The destination port stops behaving like a switch port. It does not forward normal traffic, does not learn MAC addresses from what it sees, and should not be used as an uplink or a user port. On several platforms, putting a mirrored port into a port-channel or spanning tree is either rejected or produces inconsistent behaviour.
• Every mirrored frame consumes destination-port bandwidth. If the sum of the mirrored traffic exceeds the destination link speed, the tail of each burst is dropped silently — you get a capture that looks complete but is missing frames, and the drop counters only show up if you actually look for them.

That last point drives the most common design decision in real deployments: mirror a single uplink to a same-speed port, or mirror many ports to a 10G/25G port only if the aggregate is expected to stay well below the line rate. When a capture must be lossless, use a network TAP instead of a SPAN port — see our notes on TAP aggregation and TAP tool ports for the aggregation trade-offs.

Sessions, Directions and Platform Limits

Every vendor caps the number of concurrent sessions, and the cap differs by platform family rather than by OS name. On Cisco Catalyst platforms, a local SPAN session can have several sources but only one destination, and the number of simultaneously supported sessions is a small single digit on access switches and higher on chassis platforms. Huawei counts observe-ports rather than sessions. EOS supports multiple monitor sessions, and Junos multiple analyzers — but on every vendor, a port cannot be a source and a destination in the same session.

Directional mirroring is the cheapest optimisation available. Most packet-capture work needs one direction: a troubleshooting session for a voice quality complaint usually needs rx on the access port, a firewall inspection feed usually needs both. Mirroring both when you only need one direction doubles the load on the destination port for no benefit.

Switch(config)# monitor session 1 source interface GigabitEthernet1/0/1 rx
Switch(config)# monitor session 1 source interface GigabitEthernet1/0/2 tx
switch(config)# monitor session 1 source ethernet 5-8 rx
[Huawei-GigabitEthernet0/0/1] port-mirroring to observe-port 1 inbound
[Huawei-GigabitEthernet0/0/1] port-mirroring to observe-port 1 outbound

VLAN as a source is the second-most useful primitive. It mirrors every member port of the VLAN, which is how you capture traffic from a whole segment without knowing which port the suspect device is on. Cisco takes source vlan 10 rx, EOS accepts a VLAN source on platforms that support it, and Junos models the same idea by listing the VLAN in the analyzer input. Use it deliberately: a VLAN source on a busy segment can double the traffic of a single-port source.

Filtering What You Mirror

A raw mirror of a busy trunk is rarely useful — you get a capture file full of storage replication and backup traffic while the one conversation you care about scrolls past. Filtering at the switch is far better than filtering later, because it reduces destination-port load as well as capture size.

Switch(config)# monitor session 1 source interface GigabitEthernet1/0/1 both
Switch(config)# monitor session 1 filter vlan 10
Switch(config)# monitor session 1 source interface GigabitEthernet1/0/1 rx filter ip access-group CAPTURE
set ethernet-switching-options analyzer MIRROR input ingress interface ge-0/0/1.0
set ethernet-switching-options analyzer MIRROR ratio 10

Where the platform supports ACL-based filters, an access list with a permit for the source, destination or protocol of interest — and an implicit deny — turns the mirror into a targeted feed. Junos offers a different lever: the ratio statement samples one frame in N, which is ideal for statistics rather than for a full reconstruction of a session. Where a vendor has no filter mechanism, fall back to a VLAN source and let the capture host do the discarding with a BPF filter — the extra cost is only capture-host CPU.

If you are still choosing a capture approach, the comparison in sFlow, NetFlow and IPFIX is worth reading first: flow telemetry answers "who talks to whom and how much" far more cheaply than a full mirror, and a mirror is only needed when you must see payload or packet-level timing.

RSPAN and ERSPAN: Mirrors That Leave the Switch

A local SPAN session forces you to plug a capture host into the switch that has the problem — inconvenient in a data centre, impossible when the switch is in a remote POP. Two transports solve that.

RSPAN builds a dedicated VLAN that carries mirrored frames between switches. The source switch marks the traffic as RSPAN, the intermediate switches trunk that VLAN, and the destination switch un-tags it onto the physical monitoring port. Requirements: the RSPAN VLAN must be allowed on every trunk along the path, it must have no user ports in it, and on some platforms the source switch needs a reflector port to loop the mirrored traffic into the remote VLAN.

Switch-Source(config)# vlan 100
Switch-Source(config-vlan)# remote-span
Switch-Source(config)# monitor session 1 source interface GigabitEthernet1/0/1 both
Switch-Source(config)# monitor session 1 destination remote vlan 100
Switch-Dest(config)# vlan 100
Switch-Dest(config-vlan)# remote-span
Switch-Dest(config)# monitor session 2 source remote vlan 100
Switch-Dest(config)# monitor session 2 destination interface GigabitEthernet1/0/24

ERSPAN goes one step further and encapsulates the mirrored frames in GRE, so the mirror can cross a routed network to a collector anywhere. On Cisco Nexus the session is created with a type keyword and a tunnel source and destination:

switch(config)# monitor session 2 type erspan-source
switch(config-mon-erspan-src)# source interface Ethernet1/1 both
switch(config-mon-erspan-src)# destination
switch(config-mon-erspan-dst)# erspan-id 100
switch(config-mon-erspan-dst)# ip address 10.10.10.10
switch(config-mon-erspan-dst)# origin ip address 10.10.10.1
switch(config-mon-erspan-dst)# no shutdown

The collector must be able to strip the ERSPAN header — Wireshark and most IDS platforms do it natively. Keep the ERSPAN source address on a loopback or a routed interface that survives link changes, because the tunnel dies with its source address. Junos reaches the same result with a remote analyzer whose output is a VLAN carried across the routed core, and Huawei platforms with remote mirroring configured on the observe-port.

Quick Reference Table

Verifying a Session per Vendor

Configuration that takes without error is not the same as a working mirror. Verify on the switch before you blame the capture host:

Two counters tell you whether the mirror is complete: the destination port's output rate (should roughly match the mirrored source rate) and its output discards (should be zero). On Cisco, show interfaces GigabitEthernet1/0/24 | include rate|drops is a fast check; on any vendor, watch the destination port before starting the capture so you have a baseline.

From Mirror Port to Capture File

The switch side is only half of a capture. On the capture host, three settings routinely cause "the mirror is broken" reports that are actually capture-host problems:

sudo ip link set eth1 up
sudo ethtool -K eth1 gro off lro off tso off gso off
sudo tcpdump -i eth1 -n -s 0 -w /tmp/mirror-$(date +%F-%H%M).pcap
sudo tcpdump -i eth1 -n -c 20 'host 10.10.10.55 and port 443'

Disable receive offloads first: with GRO/LRO enabled, the host reassembles frames into larger buffers and tcpdump writes captures that other tools read back as malformed or truncated packets. Use -s 0 for a full-length capture unless you are deliberately limiting size, and confirm the interface is in promiscuous mode (tcpdump sets it automatically). A quick filtered capture of 20 packets proves the mirror is live in seconds.

When mirroring specifically to debug TCP behaviour, remember the capture contains one direction per source port: with rx on a server port you see what the server received, not what it sent. Mirror both the server port and the uplink if you need both halves of the conversation, and read the combined trace with the sequence-number analysis in capture filters vs display filters.

Best Practices and Pitfalls

• Mirroring doubles the traffic on the destination port - never mirror a full 100G trunk to a 1G monitoring port.
• On high-speed switches, prefer destination ports at the same speed as the source.
• Check CPU/mirroring counters - some platforms rate-limit mirrored traffic.
• For remote capture across switches use RSPAN (Cisco) or configure the analyzer on both ends (Junos remote analyzers).
• Verify with show monitor session / display port-mirroring before assuming the capture works.

Common Mistakes

• Using the destination port for production traffic. It stops forwarding normally the moment the session is active — the outage appears minutes later when something else is moved onto that port.
• Mirroring an uplink that carries 40 Gbps to a 10G port. The switch drops the excess without any alarm; the capture is silently incomplete.
• Forgetting to remove the session. A mirror left running consumes destination bandwidth and collects data indefinitely. Remove it with no monitor session 1 as soon as the capture is finished.
• Not threading the RSPAN VLAN through the core. The destination switch sees nothing because an intermediate trunk does not allow VLAN 100.
• Leaving a user port in the RSPAN VLAN. Mirrored frames leak to a host that should never see them.
• Assuming the platform supports ACL-based filters. Check the release notes; otherwise filter at the capture host.

Security and Compliance Notes

A mirror port is a full-packet wiretap on whatever it copies. Treat it as a privileged interface: restrict physical access, do not leave the session in place after the incident, and never mirror a link that carries credentials in cleartext unless the capture is required and the file is protected. In regulated environments, mirroring triggers the same obligations as any other access to production data — a written reason, a defined retention period, and deletion when the case closes.

Two controls help. First, prefer ACL-filtered or VLAN-scoped mirrors over full-port mirrors, so the capture contains only what the task requires. Second, log the change: a monitor session is a configuration change like any other, and an unexplained mirror session noticed during an audit is a finding on its own.

For related work, see SPAN, RSPAN and ERSPAN transport comparison, tcpdump command examples and filters, Junos monitor traffic packet capture examples, and the Huawei-specific walkthrough in Huawei port mirroring with observe-port. The older related pair on this site: tcpdump packet capture guide and STP troubleshooting on Catalyst.

原文链接：https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html