Being able to analyze other users network traffic is a key part of troubleshooting networks. Back in the day when using hubs was common than switches, it was really easy to analyze network traffic. All you had to do was plug into an available switchport and you would see all of the network traffic on your segment. Why? Because, by default, hubs flood traffic out all of their ports. When switches came around, the game changed. Switches build layer 2 address tables (MAC/ARP) and forward traffic based on the layer 2 information in the frame. That being said, plugging into an available switchport these days will only get you frames that are unicast for your MAC address or broadcast on the segment. This makes troubleshooting a pain. In some cases I’ve seen engineers carry small hubs with them. When they need to listen to traffic for a particular device, they’ll actually throw the hub in wiring path so that they receive all of the data destined for the target they are trying to analyze. This is shown below. 
In this diagram, the blue shows the normal wired connection directly between a switchport and the end user. The red line shows what the wiring might look like when a hub is injected into the path. In this configuration the frames destined for the end user hit the hub, and are forwarded out all of the ports. This causes packets destined for the end user to also be sent to the network engineer so they can be analyzed. It should be noted that this is a two way street. Frames destined for the network engineer will also be flooded out the port that the end user is plugged into.
While the solution above works, it’s not that great. Best case is that you can put the hub in the switch closet and throw it in line between the patch panel and the switch. This eliminates the need to crawl under the users desk with a hub and a laptop to analyze their traffic. However, regardless of what you are analyzing, throwing a hub in place is messy. What if you are trying to find a bandwidth hog on a local segment and you need to analyze all the traffic going out through the default gateway? While the hub method works, it requires temporarily taking the network down to throw a hub in the path of all of your outbound traffic. Not a very elegant solution. Looking for something easier that doesn’t require re-cabling and throwing a 20 year old hub in your network? Enter the beauty of Cisco managed switches.
Cisco switches allow you to do what is called port spanning. While in documentation you might find it called port mirroring, sessions mapping, or spanning, they all mean one thing – you can duplicate port traffic. Through the rest of the article I’ll refer to the technology as ‘spanning’. Examine the diagram below. 
That looks a lot cleaner! Rather than physically putting a device in line to duplicate traffic we now define a span port which duplicates all of the traffic from a selected source port. Let’s take the example of my home network to solidify the point.
So let’s say that my wife is playing XBOX and I’m sitting on my laptop. I open a WireShark session on my NIC and start analyzing traffic. While it’s hard to see in the image below, I’m only seeing traffic coming and going from 10.20.30.58 which is the IP address assigned to my laptop via DHCP. 
Now let’s say that I want to see all of the traffic leaving my network. To do this, I’m going to span the port that’s connecting the switch to the 2800 series router. The router is running a ‘router on a stick’ configuration and is acting as the default gateway for all of the VLANs defined on the switch. The instant I enable spanning and map it to the port my laptop is plugged into, I start seeing all of the traffic. I can now see traffic coming and going from the XBOX (10.20.30.56) as well as 10.20.30.82 (my wife’s laptop) and 10.20.30.58 (my laptop).
There are a couple of things you should know about span ports before you start using them. Most notably, a destination span port doesn’t pass normal traffic. For instance, if I plug into the LAN, telnet into my switch, and configure my port as a span destination, I’m going to lose telnet access to the switch. If I try to renew my IP address, I’ll get a 169.254.X.X address meaning the laptop wasn’t able to receive a DHCP address so it issued its own. Destination span ports only receive copies of the data from the source port. They aren’t designed to pass their own traffic in addition to this. Just keep this in mind when configuring spanning.
Also, a source and destination span port need to be on the same switch. I believe (not 100% sure here) that the exception would be something like a pair of 3750 stack switches. Generally, I try to keep the source and destination ports on the same physical piece of hardware.
Configuring port spanning
Now let’s take a look at configuring the spanning. For instance, in my example above, the switch connecting the 2800 router to the rest of my switching infrastructure is a Catalyst 2940. Configuration was pretty straightforward.
2940#config t
Enter configuration commands, one per line. End with CNTL/Z.
2940(config)#monitor session 1 source interface faste0/1
2940(config)#monitor session 1 destination interface faste0/2
2940(config)#exit
2940#
The connection to the router was port fast ethernet 1 and my laptop was plugged into fast ethernet 2. To disable the port span you simply issue the ‘no’ version of the command.
2940#config t
Enter configuration commands, one per line. End with CNTL/Z.
2940(config)#no monitor session 1
2940(config)#exit
2940#
Now you might be asking yourself at this point about trunks and VLANs. In the above example, I slightly reconfigured my network. Typically I use separate VLANs for different types of devices. To make things more straightforward I put all the devices in the same subnet/VLAN. The port connecting the router to the switch was configured as a trunk with DOT1Q encapsulation. So what happens if we have multiple VLANs generating traffic across the trunk to different sub interfaces on the router? The above configuration captures all of it. Since I’m mirroring all of the traffic that traverses that port, I’m going to see everything from every VLAN. Take a look at the WireShark capture below when I moved the XBOX to a different VLAN/Subnet. The XBOX now has the IP of 10.10.10.100 and is on VLAN 2. Note that the capture shows traffic from both the 10.20.30.X and 10.10.10.X subnet which are defined in separate VLANs. 
Summary
The point of this article was just to clue you in to the fact that there are better options than physically plugging a hub into your network to analyze non-broadcast traffic. The configuration above is very basic, but for the most part all you would need to configure in order to analyze non-broadcast traffic on your LAN using an application such as WireShark. If you are interested in further span configurations check out this article which describes spanning on Cisco Catalyst series switches in much greater detail.