Local Span 2

One of many reasons to use the Switched Port Analyzer (SPAN) feature is a Cisco switch is to copy frames out a port that connects to a network analyzer (like Wireshark). Wireshark can then analyze the messages so that you can reasonably interpret the meaning of the messages flowing between the devices in the LAN. One key configuration choice revolves around the choices for what interfaces and VLANs to use as sources for a SPAN session. This lab gives you some requirements so that you can exercise that decision making, beyond the simple configuration of the correct SPAN parameters.
Requirements
Configure local SPAN on switch SW1 in the figure. Note that with SPAN it is difficult to capture exactly the subset of messages you want to capture, so you typically capture a superset of messages, and then the tool to which the messages are directed (like a network analyzer) then filters out the messages that should be ignored.
For this lab, you have two goals. The primary goal defines all the messages that you must capture. The secondary goal, one that probably exists for most real-life SPAN sessions for network analyzers, tells you to capture as few extra messages beyond those requested as part of the primary goal. The requirements for this lab are as follows:
- The primary goal: capture all frames flowing between devices in VLAN 2
- The secondary goal: capture as few extra frames as possible, which then requires less filtering on the network analyzer.
- Configure all parameters, even default parameters, in an effort to practice remembering all command parameters
- You may capture per interface, or per VLAN, and for any direction needed to meet the goals
- As for the topology:
- All devices except PC4 sit in VLAN 2
- All devices in VLAN 2 use IP addresses in subnet 172.16.2.0/24, with the last octet of each respective address shown in the figure near the device.
- PC4 sits in VLAN 4, and in subnet 172.16.4.0/24, using IP address 172.16.4.4
- The link between switch SW1 and router R1 operates as a trunk, supporting both VLAN 2 and VLAN 4
- The rest of the enterprise network (not shown) exists to the right of the router
- The server on the left is the network analyzer
Figure 1: Single Switch Topology for Local SPAN Configuration
Initial Configuration
Examples 1 and 2 show the initial configurations on switch SW1 and router R1, respectively.
Example 1: Switch SW1 Configuration
hostname SW1 ! vlan 2 vlan 4 ! interface GigabitEthernet0/1 switchport mode access switchport access vlan 2 ! interface GigabitEthernet0/2 switchport mode access switchport access vlan 2 ! interface GigabitEthernet0/3 switchport mode access switchport access vlan 2 ! interface GigabitEthernet1/0 switchport mode access switchport access vlan 4 ! interface GigabitEthernet1/1 switchport mode access switchport access vlan 2 ! interface GigabitEthernet1/2 ! next line required only on some switches switchport trunk encapsulation dot1q switchport mode trunk
Example 2: Router R1 Configuration
hostname R1 ! interface GigabitEthernet0/1 no shutdown ! interface GigabitEthernet0/1.2 encapsulation dot1q 2 ip address 172.16.2.6 255.255.255.0 ! interface GigabitEthernet0/1.4 encapsulation dot1q 4 ip address 172.16.4.6 255.255.255.0
Answer on Paper, or Maybe Test in Lab
To answer on paper, the process is of course simple: write your answer, and check it against the answer post that follows this post.
To test in lab, if you build this lab exercise in hardware, you will need to download and install a network analyzer on the computer that sits where the server sits in the figure. The process of how to do that is beyond the scope of this lab. However, if you start at www.wireshark.org and follow the instructions.
Do this Lab with Cisco’s CML (Formerly VIRL)
You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for Cisco Modeling Lab – Personal (CML-P). CML-P replaces Cisco Virtual Internet Routing Lab (VIRL) software, in effect serving as VIRL Version 2.
Below, find two files: a file useful with CML-P and another useful with VIRL. (Note that the CML-P file has a .yaml filetype, while the older VIRL file has a VIRL filetype.) Once the file is loaded, CML-P or VIRL will create a lab topology similar to this lab’s topology, with the initial configuration shown in the lab as well.
The CML/VIRL topology matches this lab topology exactly. The host info does as well.
Host device info:
This table lists host information pre-configured in VIRL, information that might not be required by the lab but may be useful to you.
Device | IP Address | User/password |
PC1 | 172.16.2.1 | cisco/cisco |
PC2 | 172.16.2.2 | cisco/cisco |
PC3 | 172.16.2.3 | cisco/cisco |
PC4 | 172.16.2.4 | cisco/cisco |
Wireshark | 172.16.2.5 | cisco/cisco |
R1 | 172.16.2.6 |
Handy Host Commands:
To see PC IP address: ifconfig eth1
Ping example: ping6 -c4 2001:0:0:10::100
Trace example: tracepath6 2001:0:0:10::1
A Word about Packet Captures for this Lab
VIRL does support the ability to capture packets, which allows you to then feed the packets into Wireshark running on your computer. Basically you tell VIRL on what interface to capture, and then direct VIRL where to send the packets. However, the specifics require several steps. So, I’ve left the rest of the details out of the blog post here, other than to mention that you can further research this feature on your own if you happen to use VIRL.
Hello,
It doesn’t look like VIRL supports the monitor session commands.
SW1(config)#monitor session 1 source vlan 2 rx
^
% Invalid input detected at ‘^’ marker.
SW1(config)#monitor ?
event-trace Tracing of system events
Am I missing something?
Bob
Hi Bob,
Yep, my bad, I should have pointed out that VIRL wouldn’t actually do the packet captures with SPAN. I had meant to state that explicitly in that last paragraph, but didn’t. But yes, you can’t test the solution in VIRL. Sorry for the misdirection.
Wendell