pointer

Category Archives: Virtual Networks

Where to Capture Packets in High-Speed and Data Center Networks

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.

Announcing Our Upcoming Webinar Series

Searching for information on 802.11ac? Having problems with blind spots in your virtual network? Looking for general tips and tricks on how to analyze and troubleshoot common network problems? We’ve got some great topics coming up to answer these questions in our webinar series. Check them out and RSVP today!

802.11ac – Wireless Gigabit Speeds Driving Changes in Wireless Analysis
Wednesday, April 17, 2013, 8:30 am PDT

802.11ac is the very latest technology to be introduced as part of the 802.11 family of specifications. Join us as we dive into 802.11ac, and demonstrate what we believe will be the new standard in wireless packet capture and analysis.

The Blind Spot in Virtual Networks: Seeing with Network Analysis
Wednesday, May 15, 2013, 8:30 am PDT

Virtualization provides tremendous efficiencies, reducing the cost of equipment, management, and even utilities. But as with most technological shifts there are consequences, especially in network analysis, that must be addressed. Virtualization, regardless of the “flavor,” creates a blind spot – a loss of visibility into traffic between virtual applications or virtual systems – when using traditional network analysis products and techniques. In this webinar, we will dissect this problem and demonstrate ways to overcome these network blind spots.

WildPackets Tips and Tricks
Wednesday, June 19, 2013, 8:30 am PDT

In this web seminar our team of customer-facing engineers will highlight some of their favorite problems, including how they uncovered the problem, what they recommended to solve it, and how they verified that the proposed solution was successful. Please join us for this highly informative, real-world demonstration of what really goes wrong in enterprise networks. And get your questions answered too!

Best Practices for Network Monitoring on High-Speed Networks

High-speed networking – networks operating at 10Gbps or greater – is growing across the globe, from San Francisco to Stuttgart. In fact, while at CeBIT last week our discussions with visitors to the booth often turned to corporate initiatives focused on 40G network upgrades, and of course, the ability to monitor, analyze, and troubleshoot at these blinding speeds. And as networks get faster the data they carry is becoming increasingly hidden inside overlay networks created by VM infrastructure, software-defined networks, and layer 2 multipathing.

Given these increasing challenges, here are a few best practices for monitoring, analyzing, and troubleshooting your system when poor performance or errors occur.

Monitoring on High-Speed Networks
With today’s network speeds and complexities, network monitoring is no longer a “one size fits all” proposition. You first need to decide what it is you want to monitor. Your devices and assets? Your network performance? Your application performance? Although there may be other ways of dissecting the network monitoring market, this approach is very understandable, is consistent with current industry analyst market segmentation, and significantly simplifies your search for commercially available solutions. And it’s certainly not an either/or choice. Your company most probably needs to monitor all of these functions, although not all may be your individual responsibility. And some functions may be much more important to your business than others. What’s most important is to define your requirements based on this breakdown. Once your requirements are well defined, you can look for a solution, or multiple solutions, that meet your needs. Many solutions available on the market attempt to address several, if not all, of these areas of network monitoring, but each has its strengths and typically excels in only one area.

Analysis on High Speed Networks
When we talk about analysis on high speed networks the focus shifts a bit. Although it seems a bit geeky, the best way to better define your analysis needs on a network is to reference the OSI Model and its seven layers of networking. Just to review, these are the physical layer, the data link layer, the network layer, the transport layer, the session layer, presentation layer, and the application layer. Solutions typically marketed as “network monitoring and analysis” focus on the first four layers. These solutions are often based on flow-based technologies, for example NetFlow or sFlow, and have little to no visibility into the session, presentation, and application layer. Solutions marketed as “application monitoring and analysis” specifically focus on layers five through seven, leveraging application characteristics instead of network data as the basis of their reporting. Each solution type does have some overlap, but this is definitely an area where one class of solution excels over the other, depending on your needs.

Solutions based on packet capture and analysis are designed to address all seven layers of the model, and do so quite well. A packet capture solution will passively analyze each and every packet on the network, compiling data corresponding to all network layers. But again, no one solution excels in all areas, and although a packet-based solution will certainly give you the most breadth, they still tend to excel at network layer analysis (layers one through four) versus application layer analysis.

We are holding a webinar on March 20th at 8:30am PDT to discuss this topic further. If you have any specific questions that you would like us to address during the webinar, please post a comment. We’ll also have some time after the webinar to discuss any questions that you may have.

Blind Spots on High Speed Networks
Virtual servers are now commonplace. Virtual storage is taking the IT market by storm. And the virtual data center and virtual networks are visible on the horizon. Virtualization provides tremendous efficiencies, reducing the cost of equipment, management, and even utilities. But as with most technological shifts there are consequences, especially in network analysis, that must be addressed. Virtualization, regardless of the “flavor,” creates a blind spot – a loss of visibility into traffic between virtual applications or virtual systems – when using traditional network analysis products and techniques.

Blind spots in virtual servers are the easiest to address. These exist when inter-application traffic all resides within the same virtual host. Since the traffic never hits a traditional hardware NIC, capturing the data through traditional means is ineffective, and the data is essentially hidden. A simple solution is to carve out a small segment of the virtual server to run packet-based network analysis software. Since the software is running on the VM, it has access to the virtual NICs that are part of the VM, giving the software access to traffic that is communicated between each of the virtualized applications on the server.

Virtualized storage is less prone to this problem as the storage systems are physically separated from the virtual application servers (in most cases) so the traffic between the applications and the storage systems traverses a physical hardware NIC, providing a traditional capture point for network monitoring data.

Virtual data centers and virtual networks are just beginning to be deployed, and mostly by cloud service providers and not in traditional enterprise networks, though the technology will certainly filter down to the enterprise at some point. Virtual data centers and virtual networks employ new standards, like VXLAN and NVGRE, which encapsulate traffic in distributed VMs, a core technology in virtual data centers. To monitor traffic in these environments, not only does the solution need to have access to virtual NICs, as it does when monitoring virtual servers, it also needs to strip the actual TCP/IP traffic out from these new encapsulation layers to be effective. Since this area of virtualization is very new, network monitoring products are just beginning to address these challenges.

Networks are becoming faster, and much more complex. The days of a “one size fits all” network monitoring and analysis solution are gone. Network analysis requirements must be very carefully considered, and multiple solutions are typically needed to address these complex environments, particularly in large enterprises. But by breaking down your network analysis requirements as defined in this blog you’ll be able to quickly find the solutions you need to best address your specific needs.