I’m going to write up a typical design I usually do and where I like to place the taps but before that I just wanted to jot down some key differences between going with a TAP or Spanning a Port.
WHY THE HECK DO I NEED IT?:
If you don’t know what either one of these are or why you need it, then I’ll briefly explain. In todays day in age with all the great security news you hear online and on TV about companies getting hacked, finally some companies are actually looking more at their security structure to help prevent these bad guys from hacking their network. One important thing you need to do is look and see who is on your network. You need visibility into your network so you can go, Ohh that’s bad traffic or ahh that’s good traffic. You also want to be able to act upon what is happening. It’s not actually you saying traffic is good or bad but something called a SIEM like Splunk which had some really nice data analytics built into it so it’s smart enough to see this stuff. I’m really dumbing this down. So you have all this traffic on your network and now you need to send it off to a SIEM to have it looked at. You have two choices, TAP or SPAN. The TAP sits on your network like a man in the middle and takes that traffic without manipulating it and sends it off to the SIEM. The SPAN almost does the same thing except it’s done on the same switch that’s doing all the switching and possibly routing. With all the buffers on ports and different port speeds and utilizations, this one doesn’t always send all the traffic need to the SIEM.
1. TAPs take the exact copy of your traffic (bi-directional) at line rate so you get FULL visibility into your network. It doesn’t mess with it. This is the whole point, right? You want FULL visibility into your network without any manipulation to the traffic.
2. Being that TAPs just take the traffic and copies it, it doesn’t care what protocol it is or if it has errors. Errors can be filtered out.
3. TAPs are passive so you just implement them and sit back and watch the traffic get sent to your SIEM. It’s a set it and forget it implementation even though there are things you might want to configure now or later like error checking and de-duplication or getting rid of duplicate packets. So it might not always be, forget it. See below for more cool features that Gigamon has:
Application Filtering, Application Metadata and Application Visualization
5G and 4G LTE CUPS Correlation, GTP Correlation, Flow Sampling and SIP/RTP Correlation, Video Data Records
1. Since your switch(s) has to do the work, you have a high probability for oversubscription and dropped packets. You’re relying on your switch to take a copy of your traffic while it’s doing many other things.
2. Not guaranteed to get line rate because of all the low priority traffic which will cause dropped packets even if the links aren’t over utilized. I’ve seen this in the past where the switch was dropping the packets even though the link utilization was at 9%.
3. Could cause a negative performance on your switch. I also saw this where the CPU spiked to 100%.
4. Bad configuration could give you negative performance or even bring down the network
5. Legal and compliance wise, TAPs might not pass so make sure you look into this. Because there’s a high probability that you are missing traffic, this is not good for audits.
6. Could run into bugs on the software side. Man this one scares me. I’m glad I really never had to do SPAN ports but this would scare me if I had to do it in production on one of the core switches. I’ve heard too many horror stories.
7. Limitations on the vendor side so look into that. Below is a Cisco Nexus limitation:
2 sessiong can run simultaneously 128 source interfaces can be configured per session. 32 source VLANs can be configured per session. 32 destination interfaces can be configured per session.
TAPing obviously comes at a cost because you need hardware and software to implement it but it’s definitely the way to go if you have the option.