SPAN traffic capture: are you capturing the right traffic?

SPAN traffic capture

There are very good reasons for using SPAN traffic capture in your efforts to troubleshoot network and application performance.

However, there are a certain amount of checks you will want to perform to make sure the data that you are getting is trustworthy!

Wrong data, bad conclusions!

If you input incorrect data into your analysis device, you will draw bad conclusions! This applies to network troubleshooting with network traffic capture, including SPAN traffic capture.

You have several ways to approach network traffic capture depending on your objectives and the scope of the traffic you need to capture (e.g. on physical links or inside a virtual/cloud-based data center): you can rely on:

• TAPs
• SPAN/port mirroring
• and use Network Packet Brokers/Matrix switches or not

If you would like to read more about this topic, check out this article “How to capture traffic? (Span vs TAP)”.

Or, if you are looking for some guidance on how to capture traffic in virtual and private cloud data centers, I would recommend you take a look at this other article: How to capture virtual traffic?

SPAN can provide unique advantages

SPAN traffic capture is still a very advantageous option offering unique possibilities:

• Rely on existing devices (network switches)
• Require no cut in the production traffic to setup
• Offers wide visibility (several links or even VLANs)

What do you need to check before you go for SPAN?

Remember, that there are a certain number of risks attached to SPAN. You need to make sure you are not impacted by any of these to be sure you are getting the right data out of it:

1. Check the resources of your switch first

Port mirroring is not always a high priority service for a switch: your switch needs free resources (processor, memory) to process it. You need to ensure that the current use of these resources is far below the limit before you activate your SPAN.

2. Make sure you get unicast traffic for the targeted machine(s)

You have activated your SPAN and connected your analysis device to it: great!

The very first check you need to perform is to make sure you are getting unicast traffic for the machines/links you want to monitor (and not just multicast traffic for example!!!).

3. Beware of duplicates

If you span different ports to a single destination port (or if you span a VLAN to a destination port), it is likely that some communication will be seen several times. As an example, if you span port A and port B to port C, all communications going from port A to/from port B will be copied twice to port C.

You must have a way to deduplicate traffic before you analyze. Otherwise, you are likely to consider duplicates as retransmissions and draw bad conclusions. 

4. Make sure you are not dropping packets

If you are spanning several ports to one, it is likely that the sum of the capacity of all source ports exceeds the capacity of the destination port. In that case, you need to evaluate the risk of oversubscription of the destination port.

1. Measure the level of usage of each source port, before you activate the SPAN.
2. Check that there is no oversubscription on the destination interface of the switch (the traffic sent is lower than the maximum capacity.
3. Do the same check on the analysis device (if you are using a software analyzer on the laptop, make sure you don’t skip checking the stats of your network interface).

5. Errors on the interfaces

You may get some errors on the source and destination ports: you should check that there is no checksum, CRC errors (in your switch management interface).

6. Make sure you are seeing traffic both ways

Response time measurement requires to see the requests… and the responses, and to measure the time intervals between them. If you see traffic only Client to Server or Server to Client, you will not get any meaningful data.
If you are using SkyLIGHT PVX, do not worry, we have integrated into our solution all of the required features in order to make sure you are getting the right data:

• Automatic deduplication: SkyLIGHT PVX performs the deduplication automatically to avoid any confusion between duplicates and retransmissions so that you do not have to worry about it.
• Inbound traffic quality check: SkyLIGHT PVX reports drops, duplicates!