pointer

Monthly Archives: August 2011

Distributed Networks: Best Practices for Selecting Your Analysis Options

Distributed networks, which include pretty much any corporate network today, require distributed analysis, the collection of network data across multiple key points in the network, 24/7. This is in stark contrast with the portable analysis approach where you capture data only after a problem has been reported, and do so by moving around to different points in the network with a laptop or other mobile device running network analysis software. With today’s high speed and highly distributed networks, this approach is often too little too late, though it does remain a viable option in some smaller wireless LAN (WLAN) infrastructures.

Nobody’s network is the same, and the topology depends on many factors, but most networks have similar characteristics which can be used to help you plan for a holistic solution that will best monitor and analyze your entire distributed environment. Below are several common network characteristics in distributed environments, and the network analysis solutions best suited for each situation.

The Heart of Your Network: The Network Operations Center (NOC)

Though not necessarily located in the center of your corporate campus, it is typically the center of your network, and is therefore a key point to monitor. The NOC typically includes most of the core routing resources, and acts as the hub for network traffic, especially traffic between users and key resources like application servers and data centers. The NOC is essentially a wired environment, so no need for wireless monitoring and analysis. But you will certainly have 1G and 10G network links in the NOC, so employing a network analysis solution specifically designed and optimized for 10G is a must, like TimeLine. And it’s highly recommended that you have a solution that allows for storing detailed network data (packets) over time, providing a complete record of your network transactions. As we’ve been known to say, “packets don’t lie.” At 10G, the last thing you want to do is try to reproduce spurious issues – it’s a whole lot easier to just play the packets back and analyze the original report. Plan for as large an appliance (in terms of disk storage) as you can so you can maximize the historical record you can save.

Where Virtualization Lies: Server Farms

In server farms you often find virtual servers with virtualized applications and data storage. It’s critical to have a solution in place that is able to see the traffic that is traversing within the virtual server, sometimes referred to as “hidden traffic” since it never traverses a physical NIC. These solutions can be software only (like WildPackets OmniVirtual), but may also include additional hardware if you wish to tap into the virtual data for multiple purposes.

Where Wireless Technologies Come Into Play: Remote Offices and Widespread Campuses

Remote offices and campuses have different networking requirements. Remote offices can often get by with wireless-only solutions, especially with the new 802.11n speeds, offering significant savings over wired networks. But keep in mind that all wireless data eventually becomes wired network traffic, with all data being sent back to the corporate data center, so wired network monitoring and analysis is often also required. Given that the max wired network speed at a remote office is likely to be 1Gbps or less, you can usually get away with a less expensive wired analysis solution, like our Omnipliance Edge.

Widespread campuses, with universities being excellent examples, demand mobility with very dense yet ephemeral usage, so wireless again becomes an excellent choice. Capturing wireless data requires a “point of presence”, typically within a 300ft radius of the problem. But this does not mean you need to be physically located within 300ft. Remote sensors, like a WildPackets OmniEngine with wireless adapters, or usage of access points themselves as remote packet collection devices, is very effective in performing remote wireless analysis.

Most importantly, you need to have visibility into all key areas of your network, whether local, remote, or virtual, and to leverage the best technologies on the market to keep your network running smoothly.

Announcing Our Fall Webinar Series

Are you ready to go back to school? This Fall we go back to basics covering commonly available packet capture software and techniques, demystifying 802.11n, and dissecting the impact of video on network performance.

  • September 21, 8:30AM PDT: WildPackets Compass – Navigating Shark-Infested Waters” Paralyzed by an intimidating packet list? Join us for a live 1:1 conversation with Chris Bloom, evangelist and senior software engineer, as he shows us how with WildPackets Compass you can visualize packet traces from any software, including Wireshark, and determine what’s going on in your network before analyzing how it is doing it.
  • October 19, 8:30AM PDT:802.11n – Increased Speed, Increased Complexity” Making the move to 802.11n? Join us as we explore the number of MIMO streams, channel bonding, guard interval lengths, and other characteristics that define your WLAN capabilities. Registrants will receive a complimentary 802.11n Primer after the webinar.
  • November 9, 8:30AM PDT: Stop Streaming That Movie – I Need to Check My Email” Video impacting your network’s performance? Join us to learn how to determine the overall video usage on your network, assess the impact of video traffic that is not “business justified,” and ensure and monitor high quality video delivery.

Mark your calendars, and make plans to join us!

Don’t like the topics we’ve got lined up? Voice your opinion! We’re currently planning the topics for our Winter Webinar Series (December, January, and February), and would love to know what topics you’d like tackled.

Is A Flow-Based Solution, A Whole-Based Solution?

NetFlow and other flow-based technologies, like sFlow, Jflow, and IPFIX, have become increasingly popular given their leverage of existing resources –network switches and/or routers — to obtain data that is already being processed by these devices. However, as the old adage goes, “There is no free lunch.” Flow-based solutions lack the ability to solve specific problems experienced by the end-user, and can not only stress your network with additional data, but lose key data when your network is most heavily utilized.

End-User Frustration: Why packets and payloads are so important

Problem: You receive a call from an end-user who is experiencing significant application performance problems. Of course the immediate blame goes to the network. How do you quickly fix this problem in a flow-based solution?

Answer: Without access to the packets and payloads, the network engineer would have to perform a great deal of experimentation with the user. Additionally, without help from the application engineer, the network engineer would be hard pressed to figure out the issue if it’s not a simple network issue. Now you have three players that are experiencing frustration: end-user, network engineer, and application engineer.

Remedy: Get a solution that is able to troubleshoot and provide you with access to both the payload and packet information.

In this video Jay Botelho, Director of Product Management of WildPackets, walks through the process of determining the issues centred around a particular user and a particular application, as discussed in the above scenario, and displays how simple and short this process can be when using a solution that provides visibility into your packets and payloads.

Too Much Traffic on Your Network? Flow-based technologies generate traffic of their own

Flow-based analysis generates additional network traffic, with the volume of traffic proportional to the size of the network segment being monitored. The typical packet size is around 1500 bytes, which is relatively large. These packets come in spurts ranging from tens of Kilobytes to several Megabytes of traffic for each reporting interval, depending on how many flows are monitored by the switch or the router for that given interval. NetFlow packets usually contain data for 5 to 10 flows per packet.

On highly utilized network segments, this added traffic could cause undesirable results.

Flow-based technologies break down under pressure: How flows react to a heavily utilized network

All flow-based solutions share hardware resources with the prime directive of your router or switch – forwarding packets. If your router or switch is heavily utilized, it will focus first on its prime directive, compromising flow-based reporting. This can create intermittent inaccuracies in your monitoring and reporting that are very difficult to detect, affecting your ability to collect essential information from your network at a time when it is needed most.

In addition, the flow records sent from the switch or the router to the flow-based processor are based on UDP packets, an unreliable transport mechanism. There are no acknowledgments with UDP, so dropped packets result in missing and inaccurate flow-based data. Remember, each NetFlow packet reports on 5 to 10 flows, so for each dropped packet many flows are ignored. And this is most likely to happen when the network is busiest, compounding your inability to get an accurate picture of the current state of the network.

Sampling is another important factor to consider when evaluating flow-based analysis systems. The default configuration for NetFlow is to monitor and develop flow records for 100% of the packets – no sampling. But it can be configured to “1 out of k” static sampling, or the network device itself can switch to a sampling mode when network traffic gets heavy. Sampling leads to inaccuracies in reporting, and these inaccuracies can vary substantially since it all depends which flows are being ignored through the sampling.