Recently in Network Analysis Category

With SaaS (software as a service) adoption continuing to increase, some have postulated that appliance-based network analysis and troubleshooting is in jeopardy. In a SaaS model, an application is hosted by a provider and then offered as a service to enterprises across the Internet. In other words, no on-premise hardware is required. This type of software delivery is attractive because it removes the requirements to download, install, and maintain software on-premise. Not having to buy the IT infrastructure is also on obvious financial benefit.

SaaS is taking off. In fact, Gartner recently forecasted that SaaS' worldwide revenue would surpass $8.5 billion in 2010. That doesn't mean it's the right choice for everything, namely network analysis and troubleshooting. We believe network analysis is difficult and complex and the process cannot be effectively transitioned to a service via the cloud. We believe that network analysis and troubleshooting is still best handled with on-premise software and hardware appliances. Here's why:

1.  You still own the network

Just because you've outsourced the application, doesn't mean you've outsourced the network. And odds are your internal network has grown to be quite complicated, and your users are relying on that network for access to your SaaS provider. Ongoing monitoring, with a capability to drill down into suspicious issues and quickly achieve root-cause analysis, remains as important as ever. Perhaps even more so, if the issue is with the SaaS provider and they do not own up to it.

2. Independent (and in-house) verification is key

You have the vested interest in the performance of your overall network design, whether that design is totally within your control or involves third parties like SaaS providers. Relying on a third party to monitor your network is like ignoring your vehicle's check engine light. You know the light is on; you have no idea what's wrong and no ability to dig in and figure out the problem.

3. Multiple SaaS vendors, then what?

Once you start down the SaaS track, you'll likely work with multiple application providers for best-of-breed applications. It's imperative that network monitoring, analysis, and troubleshooting remain within your control. What if applications interact? Who will notice, or care, besides you? And what about network latency, between you and your SaaS providers or perhaps between the SaaS providers themselves? The best location to measure latency is within your own network, right where your users are. This will give the most accurate latency measurements and constant monitoring will ensure acceptable end-user performance.

Network speeds are constantly evolving and the arrival of 10G brings a whole new set of challenges for network managers. Proper network analysis and troubleshooting is key in this high-speed world as our networks become even more complex. While SaaS may be convenient and inexpensive, appliance-based network analysis and troubleshooting is the best way to ensure organizations continue to meet critical operational practice needs. We do believe, however, that the future of enterprise computing is not going to just be on-premise or SaaS. Instead, they will likely exist in symbiotic harmony.

Network troubleshooting using deep packet inspection is a tried and true approach for network engineers - no one would ever doubt this approach when a difficult problem is plaguing the network. But suggest the use of deep packet inspection for troubleshooting slow applications and you'll likely get some blank stares. Deep packet inspection is the domain of network engineers, not application engineers, right?

Not necessarily. Analyzing decoded packet headers is definitely more suited to a network engineer, but what about the payload data from all the packets? Most network engineers find little value in the payloads, often times they filter them out to conserve analysis resources. But payloads can be of high interest to application engineers investigating application problems, including slow response time.

Consider the example of a help desk application used by a large online retailer. Support professionals, who access the help desk application for each customer call they receive, begin to experience slow response times from the application and of course the initial report is that the network is the problem. A network engineer begins his investigation and after a short time, calls in the application designer stating the problem is the application, not the network. "How do you know that," asks the application engineer? "Simple", says the network engineer. "Your application is generating the following messages. Your server command was deadlocked with another process and has been chosen as a deadlock victim. Re-run your command. And The rollback transaction request has no corresponding BEGIN TRANSACTION". Flabbergasted, the application engineer exclaims, "Where did you get that information?" "From the packet payloads involved in the slow response time transactions on the network, using deep packet inspection network analysis troubleshooting. You should try it sometime."

Deep packet inspection can provide greater value than simple network troubleshooting. Application engineers can certainly benefit, both in troubleshooting application problems and analyzing the overall behavior of an application before trouble is reported. The following four steps should be done to quickly isolate and analyze specific application data:

1.  Capture data at the appropriate location
For application analysis and tuning, it's best to locate a distributed network analysis software probe or appliance in the data center in line with the application and database servers. This will capture the data for all application users, whether local or remote.

2. Save packet data to disk
By saving packets to disk and employing post-capture analysis, you can take your time in doing your analysis, without worrying about missing key data.

3. Filter stored packet data for the application of interest
Some solutions make this easier than others, but this step is crucial in creating a data set that is manageable and applicable to the application you wish to analyze. This can often be done by filtering out all traffic except traffic that has the source or destination IP of your application server or servers. If it's a troubleshooting exercise and the problem is isolated to a particular client, you can even further refine the filter to just the IP to IP conversation between the client and the server.

4. Use built-in analysis features to look for common faults

Before diving in and looking for complex, one-off faults, use the built-in fault detection and analysis capabilities of your analysis software (again, these features can vary wildly between competing solutions) to look for common issues, like one-way traffic, database client errors, slow server response time, failed login, resource errors, etc.

Overall, even though you may get some awkward stares for suggesting deep packet inspection  to troubleshoot slow applications, in the end it's worth it because, you'll not only keep the network healthy but employees happy and productive.

It's called World Cup fever for a reason. With millions of people watching and reading related news online, it undoubtedly increased Internet traffic. In fact, people apparently care more about soccer than they do the presidential election. The very first day of the tournament, traffic exceeded the previous record of 8.5 million views per minute (vpm), which occurred when Barack Obama was elected. According to measurements by Akamai, traffic for news sites on June 11 started to climb steadily at 6 am ET and peaked six hours later, reaching nearly 12.1 vpm.  And the fact that June 11 was a workday didn't stop people from watching. People turned to their office computers to follow the action. Being able to identify high talkers and effectively manage traffic is a must for organizations that want to stay productive and successful.

Below are some considerations for enterprises in regards to their networks during times of high traffic: 

Understand how your network performs normally

The only way a company can improve network performance is to know where they stand in terms of network demands. Then they can measure success against those baselines. By looking at Internet connections, WAN links, WLAN environments and the data center, enterprises can get a sense of how their network normally acts. A network analyzer can also help organize this information into a report that can be used to not only solve issues that currently exist, but also to allow organizations to go back in time to validate performance and bandwidth utilization as necessary.

Prune and clean WLAN traffic

Remove unnecessary traffic. Devices like printers, support stacks and protocols that aren't in use in the environment can be eliminated. Sometimes, protocols that help manage the network, like routing protocols and SNMP can be found, hogging valuable bandwidth without any purpose.

Know your options

Consider a Web surfing policy. The 2010 FIFA World Cup lasts from June 11 through July 11, 2010 and will likely suck up a lot of bandwidth. Having a set policy in place will help keep traffic down and is an option to be explored. However, getting employees to abide by regulations it's often more of challenge than it's worth.

The fact is, it is important to see new trends approaching and make changes to the network to account for an enterprise's behavior. Popular events can erode profitability and corporate security, as employees not only watch but also participate in social media discussions and gamble online. Review network analysis measures and policies now, so when 2014 rolls around, networks stay healthy and humming.

Filtering and slicing are powerful tools to employ when performing network analysis. Their use helps to focus analysis on just the data of interest, while reducing the load, including data volume and overall processing, on the system being used to collect and process the data. The bottom line is that techniques like filtering and slicing reduce the amount of time required to troubleshoot complex networks.

Filtering is a way of limiting the overall number of packets captured and stored based upon user-specified criteria. Typical filtering criteria include addresses, protocols and ports, though more detailed packet information including values, patterns and lengths can also be used in filters. The ability to generate complex filters that combine these criteria using Boolean logic enables users to develop very specific filters that identify critical and often transient network events. Using "not" logic allows you to filter out all "good" traffic, so when packets pass the filter you know you have data you want to investigate.

Slicing truncates the packets after a certain length, significantly reducing the data that is collected and analyzed. Slicing is typically used to capture the header information from packets and not the payloads. This is a very useful technique, particularly when your analysis is centered on nodes, protocols, and flows, and not payload information, which is a significant percentage of typical network analysis.

Four key benefits of filtering and slicing include:

1. Extra time for value added projects

Improving an engineer's ability to isolate traffic by filtering and slicing can reduce the time spent responding to problems and increase the time available to proactively prevent other issues. Businesses benefit in that they accelerate the resolution of critical issues, thereby shortening the impact on productivity or revenue.

2. Quickly identify anomalous traffic

By applying filters that only allow unexpected traffic through the analyzer, enterprises can quickly monitor their network for malicious behavior. This makes it difficult to spot conditions that need immediate attention and to set up alarms so engineers can be notified of anomalous conditions even when they're away from their network dashboard.

3. Resourceful analysis

The overall amount of data to analyze and store is significantly reduced through the use of filtering and slicing, freeing up more processing power for capture and analysis and more disk space for storing the data that's truly important to the current analysis task.

4. Increased flexibility and performance

By not capturing the whole packet on a segment, you're limiting the collection and analysis to only what is necessary; certain conditions can be immediately ruled out, which dramatically improves network analysis performance.

Filtering and slicing are not without their drawbacks. Both techniques are "final" - once employed, the discarded data is lost forever. This is typically not a problem, if you're confident you know what you're looking for, but for situations where the problem isn't clear, or no problem is even expected, it may be better to collect all packet data for a complete post-capture forensics analysis. Also, the use of filtering and slicing does require advanced knowledge for effective results. Both can lead to frustration if not carefully employed.

Roaming occurs when a handset moves out of the range of one access point into the range of another. It gives users the mobility to move around within a local coverage area and still be connected to the network. However, roaming is one of the primary reasons why users experience problems on wireless networks. Excessive roaming times lead to poor quality for voice and video over wireless and can lead to dropped calls or data connections.

Roaming usually involves a channel change, but that depends on the type of technology deployed. If it's a multi-channel architecture, which is most likely the case, a channel change is required. When roaming occurs, the client needs to be re-authenticated and re-associated with the new access point, which takes longer than 150 milliseconds in most instances, especially when advanced features like WPA2 and WMM are in use. Most organization's wireless networks are outfitted with multiple access points (APs) and users can experience poor signal strength and performance despite proper coverage in the area if the client is connected to the "wrong" AP. Even in the most modern, centrally managed systems, the wireless client is the one who decides when to switch from one AP to another. This decision is typically determined based on the current signal strength and is executed by the underlying software controlling the wireless client radio (the "supplicant"). This software is different from manufacturer to manufacturer and from device to device, so the way the decision to roam is made varies widely. In most cases, the wireless client will wait too long and as a result the available signal strength lowers, before the client switches to an AP with greater signal strength.

New and improved standards are available that specify the conditions for "fast roaming," enabling transitions that take as little as 5 - 10 milliseconds. These specifications include:

• 802.11i - with opportunistic key caching so there is no re-authentication step
• 802.11r - fast BSS transition, which optimizes the hand-off as clients move from one access point to another
• 802.11k - radio resource management of WLANs allows re- authentication to be maintained between multiple APs and has predictive capabilities

These new standards (802.11i isn't new, but it's still part of an improving situation for roaming) allow APs greater control in determining when roaming should occur and the APs are more in tune with the current performance of, and demands on, the wireless network. However, this situation is even better when the overall wireless network is under the control of a centralized manager. The issue is that adoption of 11k and 11r has been very slow, especially in wireless clients, and until adoption increases significantly users will continue to suffer slow AP transitions when roaming, leading to poor voice and video over IP performance.

In the meantime, the best approach is to carefully monitor and analyze the roaming activity on your network. Obtaining a complete and accurate view requires real-time aggregation of data from multiple channels and APs, with integrated analysis that leads to detailed reporting - who is roaming, how long each event is taking and what does the average look like for each AP. The end result is simple, yet the process is complex, demonstrating why proper network analysis tools are key to staying productive. 

The recent approval for Yahoo to build a massive campus in the heart of Silicon Valley is the perfect example of how wireless networks can grow and evolve. The sprawling campus will consist of thirteen six-story buildings across 3-million square feet. As a result, the 12,000 Yahoo employees will likely become much more dependent on wireless access, demand it from more locations and expect to have the performance and reliability characteristics of the wired network. There are several issues to consider in a wireless campus environment. As new standards come into play like fast roaming, capacity will become even more of an issue. As more people try to access the network in one area, density will increase and put significant strain on the access point resource. Security is always an issue but in a wireless network environment, it's more about the nature of those on the network and their desire to cause harm. Besides coverage, capacity, density and security issues, below are some key considerations for Yahoo and other enterprises that have distributed wireless worlds.

1. Take advantage of a single vendor's access point management system

These management systems are key in a distributed world. Before, there were wireless monitoring vendors called overlays, which offered additional sensors to access points deployed in the network. However, they were costly in terms of power, equipment and network drops. With access point management systems, companies have access to software that can control channels and power on the fly. Depending on the amount of traffic and people accessing one particular point, the power can be adjusted appropriately.

2. Keep an eye on the spectrum

There are still several interferers out there. 802.11n uses an unlicensed spectrum meaning a lot of other technologies share that same spectrum including Bluetooth, cordless phones, video cameras and microwaves. It's important to be aware of interferers, know what they are and how to manage them.

3. Don't forget about troubleshooting

Monitoring the network through access point management systems isn't enough. It only indicates trouble - it doesn't troubleshoot and solve problems. Being at the scene isn't always effective with campus wide networks, especially when you have satellite offices or are spread across acres of land. Enterprises need an analysis and troubleshooting capability on top of management that can be distributed. This can be done through purchasing additional software probes with wireless adapters. Another option is to leverage the network that is already in place by switching thin APs into promiscuous mode, where their only purpose is to receive and collect packets to be analyzed. Lastly, enterprises can equip network USB hubs with wireless adapters that plug into the Ethernet network. This makes the network transparent and businesses can access adapters to use along with their network troubleshooting software anywhere on the network.

Telepresence is a big hit in the business world. For good reason too, not only does it provide unique and sophisticated remote collaboration but it's inexpensive and more environmentally friendly. Enterprises are quickly discovering the business value in telepresence as it transforms conferencing into a lifelike and immersive experience with high-definition video, life-sized video displays, high quality sound and unobtrusive cameras and microphones. Cisco, who owns the mindshare around telepresence, couldn't be more pleased.

With the technological benefits of telepresence comes the responsibility in making sure networks can handle the demand. Monitoring the network is critical as it carries the service for telepresence.

In terms of network strain, video is much more demanding than VoIP. VoIP expects regular delivery but video does not as it largely depends on movement and what is going on in the environment. Video is much more bandwidth intensive as well as more sensitive to latency, jitter and packet loss. In fact, below a certain quality threshold for video it is nearly impossible to see anything.

Organizations should understand their current baselines and network in preparing for telepresence. Key metrics include travel levels per segment, packets per second and packet size distribution. Also be aware of what the traffic level is per application including average rates, peak rates and weekly patterns. With this depth of understanding of network performance, organizations can better scope telepresence computing needs and validate network configurations.

There are three points to consider when implementing telepresence in a network environment:  

1) Success breeds success

In order for employees to accept a new technology and adopt it fully, the initial experience using it has to be successful. Beat the outset; be diligent in terms on network analysis as this is when user opinions are formed. Expect the demands to be extreme when first introducing telepresence into the organization.

2) Success increases network demands

The more people that are using the successful technology, the more demand on the network. It's important to stay in tune and not assume a certain baseline status will be reached. Network needs will constantly change depending on load.

3) Interoperability is key

Ensure quality across networks segments you don't control. When monitoring and optimizing the quality of your network, try to reach for the best quality at the end point and don't settle for the lowest common denominator.

Telepresence can provide an organization a lot of advantages and benefits provided the network is designed to handle it. In short, don't compromise on what's under the hood - the network and tools to keep it humming. Otherwise, your telepresence deployment will be remembered as an expensive mistake.

Before we address this question, we must address an even more basic question - "What is NetFlow"?  NetFlow, and other flow-based technologies like sFlow, JFlow, and IPFIX, are simply specifications for collecting certain types of network data for monitoring and reporting. The data sources are network devices themselves, like switches and routers, the idea being to leverage existing resources in the network to provide data that is for the most part already being processed by these devices. To that end, flow-based systems provide an economical source for network monitoring data.

All flow-based systems start with flows as their basic element. A flow is a sequence of packets that has the following seven identical characteristics: source IP address, destination IP address, source port, destination port, layer 3 protocol type, TOS byte, and input logical interface. By definition, a flow is unidirectional. Flows are processed and stored by supported network devices as flow records, and it is these flow records that vary from specification to specification -  i.e. a NetFlow flow record does not take quite the same form as an sFlow flow record. This requires different parsing and processing techniques for each flow-based specification. It is at this step where flow records are consumed and the term NetFlow Analyzer is introduced.

Basic flow analysis is a multistep process, requiring several different elements to be present. Packets enter a switch or router, just as they would as part of normal network operation. If the network device is flow-enabled and the feature is active, additional processing will take place to identify individual flows in the packet stream per the seven characteristics mentioned above. Depending on the configuration of the network device and how busy the network is at any given time, this processing may be done on every packet, or just a sampling of the packets. As flows are identified, flow records are created per the specification supported by the network device, for our purposes NetFlow, and the records are stored locally in the network device. As flows are completed, the records associated with those flows are exported to an external NetFlow Collector, where they are archived for further analysis and reporting. Once the flow record leaves the network device it is deleted from memory to make room for other flow records. Though efficient since the packets already must be processed by the network device, NetFlow does put an additional strain on the network device since it requires additional processing beyond that required for only switching or routing, and it requires additional storage on the switch for the flow records being processed and exported.

A NetFlow Analyzer includes the NetFlow Collector, which accepts and stores the completed flow records; a storage system to allow for long-term storage of large volumes of flow-based data; and analysis software to mine, aggregate, and report on the collected data per user requests through a customized UI, often web-based but sometimes client-server. The NetFlow Analyzer can be software-only or appliance-based, but most systems are appliance-based, and the system often includes multiple appliances.

So what are the advantages? NetFlow data comes "for free" from NetFlow-enabled network devices, eliminating the need for additional network probes to collect the flow-based data. But remember, it's not entirely free since it requires processing and storage resources on the network device thereby competing with the prime directive of the device - route packets. Given the 7 characteristics of a flow, NetFlow Analyzers can provide a relatively detailed set of network performance data, and given enough storage this data can be archived for quite a long time providing a long-term record of network behavior.

But there's no such thing as a free lunch. NetFlow Analyzers may not always be 100% accurate since the source of the flow data can be from sampling and not an analysis of each and every packet. NetFlow Analyzers also create additional network traffic moving flow records from the network device to the NetFlow Collector, possibly impacting performance on an already busy network. And NetFlow Analyzers can report on nothing more than the information they can interpolate from the 7 flow characteristics, making them excellent network monitors but poor network analysis solutions because they often lack the data to perform root-cause analysis once a network anomaly is detected.

Network analysis systems that derive data from independent interrogation of each an every packet, like the OmniPeek Distributed Analysis Solution, provide all the data necessary not only for detailed network reporting, but for advanced, root-cause analysis as well. No sampling, no need to move data across the network for storage and analysis. All analysis is done at the source, by tapping into a network device and processing all the data locally.

Each system has its place, but when the time comes for root-cause analysis, and it always does, a packet-based analysis solution like the OmniPeek Distributed Analysis Solution is what you need.