Are you getting the right traffic from your span?
There are very good reasons to go for SPAN / port mirroring to get the traffic you need 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.
You have several ways to approach network traffic 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:
- 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 datacenters, I would recommend you take a look at this other article: How to capture virtual traffic?
SPAN can provide unique advantages
SPAN 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.
- Measure the level of usage of each source port, before you activate the SPAN.
- Check that there is no oversubscription on the destination interface of the switch (the traffic sent is lower than the maximum capacity.
- 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 PerformanceVision, 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: PerformanceVision 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: PerformanceVision reports drops, duplicates!
If you would like to get a clear action plan to troubleshoot your next performance issues, do consider taking a look at our "4 steps guide to troubleshoot performance", just click here: