If you have been working with Cisco switches for any period of time, you are familiar with the SPAN process and what it takes to get it working. There are two other SPAN options that you may not have heard about RSPAN and ERSPAN. While related, they are enough different to warrant a little bit of discussion and planning.
With SPAN, it is pretty straight forward to setup. The main thing you need to keep in mind is the possibility of overrunning the data backplane on the switch which might cause some of the traffic you are watching and other traffic that you arent to get dropped on the switch. I havent had this happen to me yet, but it is a possibility. Earlier versions of IOS for some switches had a two SPAN session limit. Later versions dont see to have this limit but if you start going past one SPAN session that is always running, it might be a good time to consider buying a TAP and putting it in service.
RSPAN allows you to create a SPAN session on one switch but have the destination of the SPAN be on another switch entirely that is on the same network. Basically what happens is that you create a special VLAN intended only for transporting SPAN traffic across switches. This comes in handy when the problem you are working on is on a switch in another part of the building or campus that you are in versus where you are at. Doing this type of spanning is where you need to be a little more careful than when you SPAN traffic from one port to another on the same switch. The reason is that it is entirely possible that you can saturate the trunk connection between the remote switch and one or more downstream switches that are between you and the switch where the source port resides. When spanning just a port that a client is on, you should have a problem with saturating the trunk link but you do need to keep this in mind when doing a SPAN across switches.
ERSPAN is RSPAN on steroids. You also have fewer platforms that support this. According to the information I read, only 6509 chassis’s running a SUP720 switch fabric. The main reason for this is that the remotely SPAN’d traffic is sent over an encapsulated that switches such as the 3750 family simply dont have the resources to handle because they need to be able to support a Layer 3 GRE tunnel. I have seen references to the ASR 1000 router being able to support this but I dont have one in the lab to be able to confirm that.
From a previous post, you have seen me recommend the use of a TAP. While a brief outage is needed to put the device inline, the advantage is that you lessen the CPU overhead in the switch while traffic on the source port/vlan is being SPAN’d. For short term/one off situations, SPAN will probably be simpler to use. For longer term situations or where you dont want to advertise to a user or users that you are watching traffic on the port they are connected to, a TAP will be the more prudent option to use. If you would like more information about setting up SPAN or RSPAN, I will be glad to post information in a future post on the website. Click on the Contact Us button at the top of the page and sent me a note and I will get it on the schedule.