Network analysis changes dramatically as network speeds grow (10G, 40G, and up to 100G). From more packets to capture, to changing traffic patterns like East-West traffic among servers, network analysis strategies must adapt as new technologies are introduced. We’ve written in the past about best practices for network monitoring on high-speed networks. However, we have never gone into detail on how to position capture points to see inside areas that might be neglected by previous monitoring methods.
Below we go into where you should set up your capture points to get the most visibility on your high-speed network.
Capturing Data on the Network
Typically, if you are connecting directly on the network you are going to collect data through traditional SPAN ports, mirror ports, or taps. This is a well known method that is used frequently to obtain a passive feed from a network, so the process and any associated configuration should be familiar. One challenge does arise when virtualization is in use, as you will miss intra-host traffic when capturing only on the physical network. Don’t worry, below we will explain how you can capture this traffic as well.
In this video, you will see where to capture traffic if you are in the data center, a corporate campus, or remote office.
Capturing Data on vSwitch
Data on virtual servers pose a unique challenge, as oftentimes much of the data never leaves the virtual server – for example, communication between and application and a database running on the same virtual machine. In this case, capturing data off the span port of the virtual switch or hypervisor allows you to get visibility into intra-host traffic. To do so, you either need to have network analysis software running directly on the server, or you need a “virtual tap” (a piece of software) that can perform the function of a traditional hardware tap and copy network traffic off to a separate physical tap which can then be utilized in a traditional fashion. If you’re running the network analysis software directly on the local VM, remember to allocate enough memory, IO, and disk space to accommodate your network analysis needs.
Capturing Packets in the Cloud
Cloud computing comes in many shapes and forms. If you are trying to capture data in a private cloud, the practice and procedure will be similar to that of capturing on your vSwitch. If you control the infrastructure, you can sniff anywhere. If you are a service provider, you need to carefully consider data access, data separation, and customer privacy issues.
If you are using a third-party cloud service, the ability to capture and monitor traffic is going to depend on the implementation. If you are running software-as-a-service (SaaS) from a provider, it will be hard to have sniffing rights, so your last point of knowledge about your traffic will be at WAN link. This will still allow you to obtain valuable analytics, like round trip latency, which will provide a good indication of the overall user experience. However, if users are experiencing latency and you think that it might be an application performance problem and not an overall network problem, then it will be difficult to analyze the situation. For example, a database connection issue or database contention may be very difficult to troubleshoot. But then again, isn’t that why you’re paying your SaaS provider?
If you are employing infrastructure-as-a-service then you will have the ability to sniff your own traffic by installing a network analysis software probe on the hosted virtual server to see all the traffic on the virtual server, thereby restoring your ability to analyze application issues that may otherwise be hidden.
If you are working within another environment and would like tips on capturing data, please leave us a comment.