TechBytes with Ron Nutter

The downside to using a Ethernet TAP is that you have to have a momentary disruption on a network when you install or remove a TAP. If you need to use one in a longer term situation, an outage shouldnt be a problem. For long term situations such as putting in an IDS or IPS you probably wont be moving the tap. Where to place the TAP will depend on what you need to watch. Monitoring the traffic crossing a Trunk connection may be a bit overwhelming because of the amount of traffic that you will have to filter through. You will also need a very clean laptop in terms of install applications to keep as much of the CPU free as possible to allow it to capture as efficiently as possible. If you have to capture large amounts of data and dont have the most powerful of laptops, you may want to look at learning the cli version of Wireshark so you can reduce as much of the overhead normally associated with the GUI so that it can capture as much of the traffic on the wire as possible.

Capturing in front of and behind the router that interfaces to your ISP, in front of and behind your firewall and in front of one or more of the servers in your server farm are just some of the locations that you may need to watch on a periodic basis. Moving the TAP from place to place is not only a hassle but keeps a series of outages present on your network. It also draws attention from the users and or management that something is either going on or there is a problem on the network that doesnt seem to go away. In this case, you either need a series of TAP’s to so that you can watch at any of the points you need to when you want to which can be very expensive. If that is the case, you may want to look at a multi-port tap that allows you to watch multiple points on your network without having to move a network cable or a TAP. With a multi-port TAP, you access the TAP using a console session or management program and logically move the “monitoring” port of the TAP to the connection you want to watch without having to be in the room or even in the same building.

When looking at where you may need a TAP, don’t limit yourself to a TAP that monitors a copper connection and sends the data to a copper based monitoring port. When TAP’ing into a fiber port, it isn’t likely that you will be able to monitor the traffic with a fiber network card. In this case, you can look at a TAP that is a combination TAP/Media converter. In this way, you can monitor fiber based connections when you need to but still use a copper based monitoring system. As with all fiber type connections, you will want to make sure that you have the correct fiber tab for the type of fiber that you want to watch. Trying to monitor a long haul fiber connect (Cisco switches use a LH type laser SFP with a SX (short haul) capable fiber tap probably wont get you any data that you can use. If you are surent what type of fiber that you have or what fiber TAP will be best to use, this is a area where the vendor whose fiber TAP’s you want to buy should be more than glad to help.

If you decide to acquire a multi-port TAP, look thoroughly at all the places where you might want to be able to monitor at some point. Prioritize all of the locations in one of three categories – need it now, nice to have and future potential. Try to equally divide the points in the network that you would like to monitor in the different groups. This will help you identify the type of multi-port TAP that you may need to acquire. Another thing to consider is the ability to “grow” the TAP you are looking at. What I mean by that is can you add additional modules or capacity to the multi-port TAP or can you connect an additional chassis to the one that you started out with. With 10 Gig speeds and higher starting to become common on some networks, does the TAP you are looking at have the ability handle those speeds and what type of filtering ability does it have so that you are trying to shove 10 lanes of network traffic down a one lane country road. This is where a multi-port tap such as the NetOptics Director will come in handy. With this type of switch, you can mix and match the types of ports that you need on your network.

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.