SPANs on Cisco Switches

I can’t believe I haven’t blogged on this yet.  SPANs are one of my favorite things in the world.

The switched port analyzer (SPAN) is a mechanism on Cisco switches that allows you to take traffic on one port and copy it to another.  It’s generally used to get traffic to a sniffer or IDS for analysis, but it’s a great tool to use to sample traffic from a host for troubleshooting.

Let’s use a real-world example.  You’ve told your roommate to quit illegally downloading songs off the Internet, but you suspect he’s still doing it.  Instead of sneaking into his room at night and checking his machine, you can use a SPAN to copy his traffic to another switch interface where you can use tcpdump to record what’s happening.

Let’s say you have a 2950, and the roomie is on F0/1.  You have a Linux box plugged into F0/24 ready to capture the traffic.  Here’s what you do.

This will create a new monitor session (that is, a SPAN session) that copies traffic from port F0/1 in both directions to port F0/24.  Now, when you run tcpdump on your Linux box, you see all the traffic coming in and going out of your roommate’s port.

That’s pretty easy, right?  You can have multiple sources ports by just adding more source lines or using ranges of ports.  You can also just copy received or transmitted traffic from a source.  Check out the contextual help for a little more info.

To see what’s going on, you can do a show monitor or a show monitor session 1 (depending on the IOS version).  You’ll see something like this.

If you take a look at the destination port when the SPAN is running, you’ll see it’s in a state of up/down (monitoring).  I think you can figure out that this means we’re monitoring some traffic to this port.  Here’s what you’ll see if you look at the port.

There are two big things to keep in mind when doing SPANs.  The first is that monitoring a port can drive CPU utilization way up (depending on the platform and traffic volume), so you may run into problems if you have a bunch of SPANs going at the same time.  Related to this is the fact that, if your switch has to decide between switching and copying traffic, it will stop copying until there’s enough CPU headroom to do that safely, and you’ll lose packets in the meantime.  It’s a switch — not a copier.

The second thing to keep in mind involves those little voices in your head called ethics.  What if you see a VOIP phone call from your boss to the HR department?  How about if you find someone in upper management copying a spreadsheet of people to be fired tomorrow?  How about if you find an engineer’s telnet password to a key system?  These are things that you probably shouldn’t see, so be careful when looking at the packets.  I would suggest you tell someone in your security when you’re going to do a packet capture to make sure someone knows you’re not up to no good.

Send shamrocks questions my way.

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages.

More Posts

Follow Me:
Twitter

8 comments for “SPANs on Cisco Switches

  1. Iain
    March 16, 2009 at 4:49 pm

    For those of you who want to do this on an enterprise network where you only want to capture specific traffic. This is a very slick feature. If you have the requirement to capture at an aggregate point (which would otherwise overwhelm your capture device) and know something about the type of data you want, then this is your ticket.

    http://www.cisco.com/en/US/tech/tk389/tk814/technologies_configuration_example09186a00808122ac.shtml

    Enjoy!

  2. March 18, 2009 at 6:34 am

    Wow – Great posting! I was blown away with how to configure that. While I’ve analyzed packets being captured, I never was quite sure how folks captured network packets through a “configured” sniffer port. For some reason I always thought it was in-line with it. That is a great piece of information for me. Additionally, I REALLY appreciate the link that Iain sent about the VACL-based methods for packet capture! Then we can really narrow down our data sets to look at. Thanks to the both of you!

  3. March 18, 2009 at 10:24 am

    Thanks for the link, Iain. Doing VACLs in a SPAN would be great in a whole mess of situations — like capturing traffic for a whole server farm or a list of vendor routers on your LAN. It’s also great for keeping your sniffer from seeing things like CDP, OSPF (or any other multicast routing protocol), STP, etc.

  4. March 18, 2009 at 10:30 am

    Glad to see you here again, Clint.

    There are a some commercial sniffers that use an inline tap to get traffic instead of relying on a switch to provide it for them. With a tap, you’re looking at the voltages on the pins themselves, so you don’t run into the problem of losing packets due to resource issue on the switch; you’re seeing exactly what comes through a cable in real-time. Some taps have multiple inputs, so you’re seeing the information on multiple wires at the same time without affecting the switch itself.

    I’ve heard NetOptics makes a decent product, but I’ve never tried them myself.

  5. PB
    May 28, 2009 at 10:21 am

    Wow – Great posting! I was blown away with how to configure that. While I’ve analyzed packets being captured, I never was quite sure how folks captured network packets through a “configured” sniffer port. For some reason I always thought it was in-line with it. That is a great piece of information for me. Additionally, I REALLY appreciate the link that Iain sent about the VACL-based methods for packet capture! Then we can really narrow down our data sets to look at. Thanks to the both of you!

  6. May 28, 2009 at 8:07 pm

    I’m glad to help, PB. 🙂

  7. rach
    November 13, 2014 at 2:42 am

    Is there datasheet about maximum traffic which can monitored/SPAN at Cisco Cat-2960 ? And it’s correlation with CPU impact.

Leave a Reply

Your email address will not be published. Required fields are marked *