Analysis

An emerging network management headache: analysing ever-faster networks

Peter Williams By: Peter Williams, Practice Leader - IT Infrastructure Mgmt., Bloor Research
Published: 27th March 2008
Copyright Bloor Research © 2008
 Logo for Bloor Research

Talking about protocol analysers is not really my beat—except that they do provide useful information for troubleshooting faults to support network management (which is my beat). However, a major issue concerning network speeds and real-time analysers should be receiving more management attention.

In mission-critical environments, the ideal analysers are those which can capture all the data all the time by working in real-time; then, if a problem occurs, the network specialists can trawl for exactly what passed along the line at the point of problem. Otherwise, they could be faced with trying to figure out, then recreate, the problem in order to analyse what happens—a very hit-a-miss affair.

However (in case anyone hadn't noticed), the more data that has to travel over networks the faster the networks have had to become to cope. So, in the case of Ethernet, we have gone from 10Mb/sec to 100Mb to 1Gb to 10Gb (so a 1000 times as fast as 10Mb) in a few short years.

The problem for these ‘real-time’ protocol analysers, of which there are only a few, is partly that they have had to keep up. This has, for instance, meant upgrading from software-only to purpose-built plug-in hardware appliances. Yet, even if they do keep up, the amount of information they collect in a very short time is multiplied, leaving the network specialist with a tougher task trying to see the wood for the trees to pinpoint the problem.

The market-leading protocol analyser is called Sniffer (nowadays owned by Netscout after its recent purchase of Network General). Yet, even in its hardware-software appliance format, Sniffer cannot yet cope with 10Gb Ethernet in real-time. The product nearest to achieving this at present is from Network Instruments. To do this, its Observer software is supported by a dedicated capture card designed from scratch for throughput and its GigaStor disk technology that incorporates daisy-chained SATA RAID arrays to which the data is written in parallel to keep up with storing the data at the speed received.

Of this combination, Ian Cummins, Network Instruments' VP of EMEA, told me: "It is completely happy with 100Mb and 1Gb Ethernet, but 10Gb is a challenge."

However, the challenge he is referring to is not that it cannot keep up with the speed of data flow; it is probably the only real-time product on the market which can, Sniffer notwithstanding. It is that, as the speed of the network has multiplied, so the analysis has become more complex.

All such analysers use retrospective network analysis (RNA) software to trawl through the captured information to identify possible problem points. But suppose, at 100Mb, the analysis finds two potential causes of a glitch in a given time-span; at 1Gb this may multiply to 10 and at 10Gb perhaps 30, all needing deeper investigation. In other words, the faster the network the more difficult it is to pinpoint the problem when a fault occurs—and the fastest networks are typically those that run the most mission-critical tasks.

The longer term management issue is that networks will inevitably get even faster and, even if the appliances can be upgraded to keep up, the complexity in pinpointing the problem will only get worse and resolving problems will tend to take longer—when they need to take less time!

Nor is this the end of the story. This difficulty is multiplied when Voice over IP (VoIP) and data traffic are mixed, since the software has to be able to separate out the two different streams and, even after that is done, a fault caused by one may manifest as a problem in the other. In Network Instruments' own annual user survey on networking, it found the number of VoIP users had grown by 5% in a year (from 61 to 66%).

A further factor is that VoIP traffic is not verified to the same degree as other data, so adding VoIP tends to introduce more rogue packets so potentially multiply the error count and making pinpointing problems even tougher.

So what's to be done? Cummins explained that Network Instruments is now working hard on the analysis for 10Gb. The main approach Network Instruments is taking is to provide an overview of the potential problem sources in less technical form, then provide a drill down capability to get into the fine detail for each. Parameters can also be set that will screen out acceptable "errors" to assist in seeing the wood for the trees.

This is a sound approach which other protocol analyser providers would do well to follow. Yet I doubt that, come the next hike in network speeds, this will be enough.

Reader Comments

Sorry, we are no longer accepting comments on this item. We suggest trying to contact the author directly.

27th March 2008: 'Jesse Price' said:

Peter,

I think your article is addressing a larger and growing problem faced by many vendors. While you mention the aspect of mixed traffic types (i.e. VOIP and Data), this is only one of the issues. For most of the vendors mentioned, correlating and extracting useful operational and troubleshooting data is their core competency. Of course, getting access to the right data is a necessary precursor, and as you have highlighted this is a moving target and a dynamic not likely to change.

As the world continues to move toward converged network technologies and as core transport technologies race to the next plateaus of speed (10G to 40G to100G) we are also transforming from connection-oriented to connectionless paths. The challenge moving forward for service and solution providers is daunting and will likely require a change in traditional thinking. At the same time, assurance solution providers need to concentrate most of their efforts on their core competencies to provide operators with the advanced software tools needed to successfully operate their networks.

I’d like to suggest an alternative strategy that is being used (or at least considered by operators around the globe) and offers exceptional returns when compared to multiple single-function probes. Monitoring at the network’s core is sensible and cost effective; yet separating the traffic types as we enter a fixed mobile convergence (FMC) world is better left to a generic access strategy. Network access devices that can provide protocol separation without distortion of the results enable operators to utilize best in class software solutions without placing multiple disparate vendor-specific probes on their networks. This proven and practical technology is making major in-roads due to the very issues your article points out.

I thought the article was great… concise and thought-provoking!!! Cheers!

Best Regards,
Jesse Price
Vice President Sales and Marketing
NetQuest Corporation
jprice@netquestcorp.com

Reply to Jesse Price?

2nd April 2008: 'Martin Pinner' said:

It is obvious from Peter Williams’ article that attaching a network monitor to a high-speed infrastructure is often aimed at measuring the throughput on the link or troubleshooting poor performance.

An alternative to trying to diagnose poor performance after it has happened is to prevent it happening in the first place. The key questions to ask are “Do I know what is been transmitted across the measured link?”, “Why is the bandwidth demand increasing over time?” and even more important “How do I control the bandwidth used by different protocols or, better still, different applications (otherwise how can I differentiate between competing HTTP traffic, for example)?”

In other words: rather than just measuring everything, IT service units and service providers should focus on pre-emptive activities such as shaping traffic based on business rules and service level objectives. Even though YouTube does have its charm, surely this application has less priority during business hours of a bank, where financial transactions are crucial to the business.

This technology is available now from NetDialog (and partner in the UK, Application Performance Ltd). Our Software-as-a-Service, SLA-management platform, NetX, in conjunction with remotely deployed application sensors, has proven itself to optimise application flows across high speed networks, prioritising business critical data above fun traffic, minimising performance problems, optimising end user response time and scrutinising the need and hunger for network bandwidth.

Yes, measuring networks after a problem point will still be necessary, as problems will turn up.
No, we don’t need to suffer from bandwidth congestion and performance bottlenecks because a colleague prefers a movie download above a business transaction.
Yes, these issues can now be addressed with leading-edge technology serving the company goals, end-user response time and IT efficiency.

Regards,
Wilfried van Haeren,
VP Customer Advocacy / Founder,
NetDialog BV
http://www.netdialog.eu

Reply to Martin Pinner?

The messages above were all contributed by IT-Director.com readers. Whilst we take care to remove any posts deemed inappropriate, we can take no responsibility for these comments. If you would like a comment removed please contact our editorial team.