Span or switched port analyzer also called port mirroring or port monitoring, is a way to configure
a switch to make copies of Ethernet frames that are received on certain ports or certain VLANs.
You could say as an example that all traffic arriving on Port Gigabit101 gets copied out of
another port gigabit102
or you could say that all traffic that's received or sent on VLAN 1 is copied out of gigabit1
02. Span becomes really important when you want to monitor traffic that's not destined to a specific
device.
As an example, you may have a network analyzer or intrusion detection system that needs to monitor
traffic that traverses your network.
You can configure a switch to either make copies of frames out of a local port or, as you'll learn
later, use what is called remote SPAN where you copy frames from a local switch to a remote switch
so that a remote monitoring station can receive the traffic.
Now, in this topology, I'm not using GNS3, GNS3 and Cisco VIRL do not currently
support span.
So what I'm using are physical Cisco routers which are connected to 2950 physical Cisco switches, which
in turn are connected to 3750 Cisco switches.
I've got a PC connected to the 3750 switch, and it's running Wireshark, and we'll use it to capture
traffic from the network.
Now, I'm going to demonstrate in a moment that when traffic is sent from router 1 to router 2 in other
words, unicast traffic such as pings or telnet are sent from router 1 to router 2. The traffic will
be sent to the first 2950, which in turn will be sent to the first 3750, which in turn will be sent
to the 3752 switch
and that will continue until the traffic arrives at router 2. This
capturing PC will not have visibility of unicast traffic because when the Mac address table of switch
1 is populated, it's simply going to switch the traffic from this interface too, for example, this
interface to forward the traffic to router 2. Traffic is only going to be sent out of this interface
if it's sent to unknown unicast addresses, multicast addresses or broadcast addresses or specifically
sent to this capturing device. So the capturing device will have no visibility of traffic sent from
router 1 to router 2 unless we enable SPAN or port monitoring on the 3750 switch.
So I'll firstly demonstrate that traffic sent from router 1 to router 2 is not received by the capturing
PC
and then we'll configure SPAN on the switch so that the PC is able to capture the traffic
using Wireshark. Here's the console of the 3750 switch show Mac address table.
So Mac addresses are listed in the table.
What I'll do now is ping from router 1 to router 2 show IP interface brief router 1 has this IP
address and router 2 has this IP address, which we can see on the console of router 2.
So there is the IP address of router 2
router 1 is once again able to ping router 2.
So when we look at the Mac address table of switch 1.
Previously, we only had those three Mac addresses in the table, but now notice we have this Mac address
as well as this Mac address in the table. I have configured the Mac address of router 1 as follows.
So I'm using a Cisco Vendor Code Mac address
and to make it simple, I've specified the Mac address of router 1 as follows, on router 2 I've done something
similar.
So Mac address is the Cisco Vendor Code 0s and a 2.
So at this point, the first 3750 switch has learnt about the Mac addresses of router 1 and router
2 to keep things simple, I haven't configured any VLANs,
all devices on VLAN 1.
Let's capture traffic in Wireshark on our PC, so it's currently receiving some traffic
but let's do a ping from router 1 to router 2 once again and I'll filter for ICMP traffic.
In the output here, you can see that the PC is not receiving any ICMP traffic from router 1 to router
2
and in the same way, if router 2 pings router 1, no ICMP traffic is shown on the capturing
PC
but if router 1 ping's
this Windows PC, which has an IP address of 10.1.1.2.2.2
Notice we see the ICMP packets, so Wireshark is able to capture traffic from 10.1.1.1 going
to 10.1.1.2.2.2.
So the PC is not able to capture
unicast traffic sent from router 1 to router 2. What about multicast traffic?
In this example, you can see that the ICMP traffic was received to the multicast address.
So router 1 with IP address, 10.1.1.1 is sending traffic to the multicast address
239.1.1.1,
you can see as an example that the source Mac address is router 1 destination Mac address is 01
005E which is the multicast Mac address in IPV4 as you can see over there.
What about a broadcast? So I'll ping 10.1.1.1.255
and I'll just repeat this once.
As you can see here, broadcast traffic is being received by the PC.
So in other words, unicast traffic is sent from router 1 to the capturing device is forwarded out of
this port
and that's based on the Mac address
shown here, as learnt by the 3750 switch. On this PC
I have changed
the Mac address in Windows
to a bunch of 0s and a 1, so the Mac address is
eleven 0s followed by a 1, and that was learnt by the switch on fast Ethernet 105 as shown
over here.
So unicast traffic gets forwarded to the PC, multicast traffic gets forwarded to the PC
and that's because multicast Mac addresses are not added to the Mac address table in the same way that
unicast Mac addresses are broadcast traffic is also forwarded to the PC.
So to summarize,
I'll restart the wireshark capture
Unicast traffic sent from router 1 to router 2 is not received by the capturing device.
Multicast traffic is received.
Broadcast traffic is received.
If we want to capture traffic from router 1 to router 2 for troubleshooting as an example, we would
need to enable SPAN on this port or mirroring to use the other term.
So the traffic sent and received on this port or this port or on VLAN 1 in this example is forwarded
out of this port so that the capturing device can see the traffic. As another example if we telnet from
router
1 to router 2 and log in,
the capturing device does not see the telnet traffic.
So we can't see the session from router 1 to router 2
and that's because the switch is doing what it's supposed to do.
It's forwarding traffic from this interface to this interface and not sending it out of unnecessary
ports.
So now let's configure span so that the capturing device can see the unicast traffic.