zNetLaB › Guided labs › Enterprise
SPAN — mirror a port so an analyser can see the traffic
Enterprise Intermediate 4 devices 4 checked tasks 100 points Plan lab
A switch only sends a frame out of the port its destination is on, so an analyser on another port sees nothing. Configure a SPAN session that copies everything the server’s port sends and receives to the analyser’s port — the standard way to capture on a switched network. You build it in a browser, type real commands at each device, and every task below is
checked against the running configuration — so you find out it is wrong before anybody else does.
Open this lab in the simulator
The simulator runs in your browser with nothing to install. This lab is part of the full simulator: open it free for 7 days with a new account, then with a plan. It needs an account, which keeps your progress.
The scenario
A switch only sends a frame out of the port its destination is on, so an analyser on another port sees nothing. Configure a SPAN session that copies everything the server’s port sends and receives to the analyser’s port — the standard way to capture on a switched network.
Your role: a network engineer on the enterprise team. Level: Intermediate Done when: all 4 goals show as passed (100 points).
Network status
Devices: 1 switch, 1 server, 2 PCs, cabled as drawn. No Layer 1 or Layer 2 faults: every link is connected and up. Server is a host with 10.0.0.10/24. Client is a host with 10.0.0.20/24. Analyser is a host with 10.0.0.99/24. SW starts with an empty configuration. Known problems
None: nothing is misconfigured. The network is simply not finished: what the goals list is what you have to build or secure. Goals
A SPAN session names the server’s port as its source (35 pts) The analyser’s port is the destination (35 pts) The session is listed as active (15 pts) The client still reaches the server (15 pts) The activity, in order
A SPAN session names the server’s port as its source Why: This is the task that checks your configuration directly: the line must really be there, not just look right. Verify with: show running-config The analyser’s port is the destination Why: This is the task that checks your configuration directly: the line must really be there, not just look right. Verify with: show running-config The session is listed as active Why: Reading a show command is the core skill of troubleshooting: the output is the truth, not your configuration. Verify with: show monitor session 1 The client still reaches the server Why: A ping needs a route in BOTH directions. This is the end-to-end proof that everything before it worked. Verify with: ping 10.0.0.10 Tips
Work in the order given: later goals depend on the earlier ones. After every change, run the verify command before moving on; do not guess. Stuck? Read the verify output first. It names the interface, neighbour or route that is wrong. Common mistake: Using the destination port for something else Common mistake: Oversubscribing the monitor port Common mistake: Forgetting the direction (rx, tx, both) Why this matters
A switch forwards a frame only toward its destination, so an analyser on another port sees nothing. SPAN copies a port’s traffic to a monitor port — the foundation of capture and IDS on switched networks.
What you will be able to do
Configure a local SPAN session
Choose source direction and destination port
Verify the session and explain the limits (bandwidth, the destination port stops normal forwarding)
The network
Catalyst 2960-24TT, Server, PC — 4 devices in all, already cabled.
Fa0/1 Fa0 Fa0/2 Fa0 Fa0/3 Fa0 SW Server 10.0.0.10/24 Client 10.0.0.20/24 Analyser 10.0.0.99/24 Drawn from this lab: devices, cables, ports and the addresses already set. Device Model Address already set
SW Catalyst 2960-24TT configure it Server Server 10.0.0.10 / 255.255.255.0 Client PC 10.0.0.20 / 255.255.255.0 Analyser PC 10.0.0.99 / 255.255.255.0
Cabling
SW Fa0/1 ↔ Server Fa0 SW Fa0/2 ↔ Client Fa0 SW Fa0/3 ↔ Analyser Fa0
What is configured at the start
Nothing is configured to start with beyond the addresses above: you build the configuration from a clean start.
Tasks, and how each one is checked
Every task is decided by reading the live network — a neighbour in FULL, a ping that succeeds, a line in the running configuration — not by looking for a keyword you typed. The same command shows you what the lab sees.
# Task Pts How to verify it yourself
1 A SPAN session names the server’s port as its source 35 On SW: show running-config contains the line(s) matching monitor session 1 source interface (Fa0/1|FastEthernet0/1). 2 The analyser’s port is the destination 35 On SW: show running-config contains the line(s) matching monitor session 1 destination interface (Fa0/3|FastEthernet0/3). 3 The session is listed as active 15 On SW: show monitor session 1 output matches Fa0/1|FastEthernet0/1. 4 The client still reaches the server 15 On Client: ping 10.0.0.10 must succeed.
Stuck? Ask the coach
Tell the coach what you see or what you tried. It gives you a hint, not the answer, the way a senior engineer would. Included with a free trial or any plan.
Ask the coach
Common mistakes
Using the destination port for something else
Oversubscribing the monitor port
Forgetting the direction (rx, tx, both)
Reference solution
Try it yourself first — the lab checks your work either way. This is one configuration that makes every task pass, device by device:
SW monitor session 1 source interface Fa0/1 both
monitor session 1 destination interface Fa0/3 Where this is examined
CCNP ENCOR (monitoring), Network+ (traffic capture), Security+ (monitoring).
This lab practises these topics in the zNetLaB certification courses:
Debugs, ping/traceroute, SNMP, syslog, NetFlow, SPAN, IP SLA — CCNP Enterprise · ENCOR · Network Assurance QoS, NAT, FHRP, IP SLA, NetFlow, multicast services — CCIE Enterprise Infrastructure · Infrastructure Security and Services Monitoring, logging, SNMP and traffic capture — CompTIA Network+ · Network Operations Monitoring, logging, SIEM and traffic analysis — CompTIA Security+ · Security Operations Intrusion prevention and traffic visibility — CCNP Security Core · Network Security Network visibility: NetFlow, SPAN, syslog, NTP — CCNP Security Core · Secure Network Access, Visibility and Enforcement Sniffing and man-in-the-middle: rogue DHCP, ARP spoofing — Ethical Hacking (network level) · Network Attacks and Defences Detection: logging, NetFlow, SPAN and IDS placement — Ethical Hacking (network level) · Perimeter, Evasion and Secure Design Capturing: SPAN, TAPs and where to capture — Packet Analysis with Wireshark · Capturing and filtering
Related labs
Where to start
The lessons all guided labs plans
CCNA®, CCNP® and Cisco® are trademarks of Cisco Systems, Inc. zNetLaB is not affiliated with or endorsed by Cisco.