Recently in Network Monitoring 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.

 

They say the truth shall set you free...

There is a common misconception lingering in the networking world. Even though several protocol analysis and troubleshooting solutions claim "line-rate" analysis, the actual network throughput that can be effectively analyzed varies greatly and is highly dependent on a number of factors. One of the most important factors is whether or not the analysis is expected to be real-time, or if all analysis will be performed post-capture. Real-time analysis is extremely demanding, so much so that "real-time" and "line-rate" should not even be used in the same sentence. The only condition under which line-rate can even be considered is when data is being collected for post-capture analysis, often referred to as forensics analysis. In this scenario all network packets are written directly to disk. The most capable network analysis and troubleshooting solutions available today have a data capture rate of somewhere in the range of 4 - 6 Gbps. Even though these solutions claim 10G "line-rate" captures on fully utilized, half-duplex 10Gigabit links, they begin to lose packets if pushed beyond 4 - 6 Gbps, obviously far short of a fully utilized rate of 10Gbps. A solution that could capture at that high rate and not drop any packets would be beyond the state-of-the-art!  

The fact is that today's networks are actually faster than the available network analysis and troubleshooting solutions, resulting in greatly diminished network visibility. This is significant to network administrators because the 10G technology enterprises are actively deploying can be difficult to troubleshoot, and until now, no vendor has been able to capture at the half-duplex line-rate without packet loss. However, achieving both real-time visibility and historical network traffic storage for post-incident analysis is possible in 10G environments - you just have to add clarity to your analysis by being specific and a bit more selective.

Three tips for being more selective when analyzing 10G Ethernet traffic:

1. Understand the network and the data you need to collect

Do not try to blindly move forward and perform analysis without knowing what data matters most to your organization. It's important to know exactly what you want to capture and what information is going to be beneficial for your analysis. Your requirements will likely vary between each network segment and you are likely going to have to capture data at several locations. The key is to use post-capture analysis and only save the data to a disk in real-time. Trying to capture and analyze simultaneously, in real-time, on highly utilized network segments puts too much strain on the system.

2.  Capture only what you need

There is a great temptation to try to capture and analyze everything because enterprises fear that the source of the problem is not immediately known. When it comes to 10G Ethernet traffic, analyzing every bit of data is nearly impossible  due to the volume of data. However, if you know your network well enough, certain conditions can be immediately ruled out. By using these clues to limit the collection and analysis to only what is necessary, you can dramatically improve network analysis performance.

3. Limits are everything

Even after analysis has been streamlined to only essential areas of the network, data capture for network analysis on 10G networks generates a great deal of data quickly, and managing the data becomes a significant challenge. The data is typically stored for subsequent retrieval and post-capture analysis. The two most common formats are standard packet files and databases. In either case, two metrics to manage closely are file size and frequency of disk writes. If the files are too large they will be unworkable on the computer being used for analysis. Smaller files lead to more frequent disk writes, and this can rob the system of resources for performing the actual packet capture. Optimum performance is achieved with a balance of these two demands, and this is different depending on the hardware resources available. After a few captures, you can determine if either of these parameters can be better optimized for your system.

Until a solution is developed that doesn't just claim "line-rate" analysis but actually allows packets to be written to disk without data loss, these tips are helpful for keeping an organization up to speed with 10G traffic. In the end, paying careful attention to detail when configuring network management systems will reward you with the analysis and troubleshooting results you desire.

Thanks to the likes of YouTube, Facebook, iTunes, and VoIP (among others), networks are more taxed than ever with heavy traffic loads. Making sure today's networks are humming and healthy is not only a daunting task for network administrators, it's a must for organizations that want to stay productive and competitive.

Enter bandwidth management - the process of measuring and controlling communication on the network in order to avoid poor performance. Below are six bandwidth management tips to keep organizations ahead of network issues.

 

1.       Baseline critical network segments

Know who is using what, when, where, and why in regards to network segments. The only way a company can improve bandwidth management is to know where they stand in terms of network demands. Then measure success against those baselines. Organizations can start this process by looking at Internet connections, WAN links, WLAN environments, and the data center. A network analyzer is a great tool for creating baselines as it helps with organizing critical statistics into a PDF or web report on all types of networks including wired and wireless. These reports can then 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.

 

2.       Prioritize critical business applications

Every organization will have different priorities. In fact, each network segment may have different protocol priorities because of the specific applications that traverse those segments. Certainly, the top application (based on business importance) on the sales segment will be different from the top application on the marketing segment. Those application protocols need to be handled in terms of importance for the segment they are individually on. But, when those protocols get to the same wire at the core or elsewhere, it is important that they still respect other segments' needs.

 

3.       Tie baseline protocols and usage to those critical business applications

Understand specific applications and their use of protocols. And remember, there is usually more than one. Any protocol that isn't performing well can affect the overall application performance (the weakest link per se). This is another area where a network analyzer can help break down and show individual flows and their performance. Organizations can have a window into the network to see the weakest link as well as options to sort application flows with various criteria choices.

 

4.       Remove unnecessary protocols/traffic

Almost every network has unnecessary traffic. Some devices (especially printers) support stacks and protocols that aren't in use in the environment. Often, WLAN traffic has not been pruned. Sometimes, protocols that help manage the network, like routing protocols, SNMP, etc., can be found on those WLANs without any purpose, eating up available bandwidth, again, with no benefit.

 

5.       Use QoS and bandwidth shaping to prioritize the business priority applications

Organizations can initially use the feature sets on their routers and switches to help with prioritization. In some cases, they may need to purchase specific hardware or software to help with this. There are many solutions on the market today, each focusing on solving issues with bandwidth management.

 

6.        Review and manage

Since the network is dynamic and users won't always do the same thing twice, it is critical that organizations consistently review network activity. Businesses should verify that the processes and/or devices architected are accomplishing what they need to and that the overall network profile has not changed. It is very important to see new trends approaching and make changes to the network to account for behavioral changes in an organization's user communities.

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.

 

Recently, we posted "Three tips for determining whether latency is caused by the network or application," which investigated the potential causes of latency along with suggestions for effective latency monitoring. It turns out that a lot of people were interested in the topic, as evidenced by the volumes of detailed comments generated on LinkedIn Group forums. So we've decided to offer additional insight on latency issues and explain how Latency Monitor, a free add-on application for our OmniPeek protocol analyzer, can help organizations fight latency issues and ultimately, save money.

If latency issues cause system failures, it can cost a lot of money to fix. It needs to be monitored 24/7 in order to successfully run business critical applications. However, not all latency issues are created equal and monitoring applications need to be intelligent and flexible to accommodate specific situations. 

Latency Monitor provides an intelligent and flexible way to determine and react to latency. It is designed to produce meaningful notifications across groups of servers as well as specific applications. This type of high value notification system can be used to build procedures, both manual and automated as well as react and fix problems in advance. By fixing problems before they occur, companies save money.

By monitoring the level of latency, Latency Monitor makes sure it does not exceed an acceptable threshold. If levels become unmanageable, a notification is sent. Appropriate actions can be taken either automatically or manually to lower the latency. By lowering the latency before end users are affected, they can continue working, the IT department remains undisturbed and the company ultimately saves money.

There is no doubt that latency can be expensive and a serious threat to productivity if not monitored closely. By providing intelligent notifications, the Latency Monitor for OmniPeek helps organizations save money by identifying and solving latency problems quickly.

 

The OmniPeek Plug-ins are flying off the shelves.  And they should, since they are free to customers with maintenance.   There are over 40+ plug-ins available on MyPeek.   Some are more popular than others.   To help you decide which ones to try first, we have taken a look at the stats, and have come up with the top 10 most downloaded plug-ins.

Compass Forensics Dashboard with enhanced Milliseconds view

Whenever a new application is rolled out on the network, IT must be able to predict with confidence how it will perform for the business. Moreover, other mission-critical applications must not be negatively impacted. Solutions that provide network performance analysis capabilities should be able to provide immediate feedback on how new applications behave on the network and can predict the impact to existing, business-critical applications.

 

Here are three warning signs that a new application on the network is not performing well on the network and / or is negatively affecting other business-critical applications.

 

1) Performance in production doesn't match pre-deployment testing/analysis
Pre-deployment testing can take many forms, from a relatively simple set of tests followed by predictions of the network impact, to complete test networks that simulate the entire usage pattern of the application. While the latter approach can be complicated and time consuming, the former technique is simple to perform with a few basic tools. By installing the application and capturing some representation transactions with packet-based network analysis software, one can perform "what if" analysis that allows one to "scale" these representative transactions to the expected number of users of the application once in production. The resulting analysis provides a clear assessment as to the readiness of the network for the new application. Additionally, it will give the data needed to compare application performance once the application is in production. Any discrepancies are a red flag and should be addressed.

 

2) Network baselines change dramatically after deployment
Without network baseline data organizations are operating blind, whether it pertains to the specific issue of deploying a new application, or just general day-to-day network performance management. Baseline data should include long-term (weekly cycles work well) sets of network utilization data from key network interfaces; node, protocol and application utilization over time; and an assessment of the typical "noise floor" of the network - typical packet loss numbers, number of retransmissions, latency measurements for key applications, etc. After deploying a new application (and as part of the pre-deployment testing) a new set of baseline data should be generated and compared against data from before the rollout. Unexpected differences should be addressed.

 

3) A change in network "health"
Network health ties into the aforementioned "network noise floor", but changes in network health can usually be seen much more quickly than comparing long-term baseline data. Enterprise-quality network analysis software will constantly monitor the vital signs of the network by performing background expert analysis, and it will send alerts when vital signs begin to drift. For example, if an organization deploys a new application and its network analysis software begins sending alerts that there are too many TCP retransmissions, this is a strong indication that this new application has tipped a balance. (even without even knowing the network's current threshold for TCP retransmissions).
 

No matter what solution an organization selects for analyzing how a new application behaves on a network, it must meet the following criteria ...

 

1)       Provides detailed information through all seven layers of the OSI model

2)       Enables collection of key network data over meaningful time cycles (like a week) to develop high quality network baseline data

3)       Quickly identifies if the network is being stressed and where

4)       Offers "What If" capabilities for analyzing the impact of new developments and implementations

By Joe Habib, WildPackets Director of Global Services

OmniPeek is the first protocol analyzer to offer both expert diagnostics and frame decoding in real time, during capture. WildPackets' OmniPeek has been carefully designed to help IT Professionals analyze and diagnose increasingly diverse volumes of network data, providing precise, contemporary analysis of the problems facing today's networks.

 

Here are ten cool things you can do today with OmniPeek!

Main window of OmniPeek, showing the Expert view

1. Capture and view packets

Though you can see global network statistics without capturing packets, for most analysis sessions you'll want to capture packets. One of OmniPeek's many strengths is in its flexibility. This is immediately apparent in the packet list display, where you can easily customize the display.

 

1.    Click the New Capture button on the Start Page, or pull down File...New from the menu bar. Click OK in the Capture Options Dialog, then click the Start Capture button.

2.    OmniPeek provides several ways to customize your view of traffic with a single click.

a. The auto scroll option (Ctrl-K) allows you to see packets as they come in, which is useful if you're looking for particular information in the Summary or Expert columns.

b. The Show Packet List, Show Decode View, and Show Hex View buttons allow you to pick the content you want to see in real-time. Most other analyzers show all three (and not usually in real time) and do not allow you to toggle between the different views.

Many network monitoring tools are available. All will give you the health of the network, and most will alert you when a problem occurs. However, not all network monitor products provide enough actionable information to really drill down to the root cause of network bottlenecks - that is, network monitoring and root-cause analysis in the same product.

The ability to quickly pinpoint the origin of a problem, thus reducing mean-time-to-recovery (MTTR), is an important business benefit for an increasingly mobile workforce. Additionally, by speeding up the identification of rogue wireless devices - whether a rogue access point or rogue peer (end user computer that has bridging and wireless enabled) - root-cause analysis serves to protect confidential data and critical assets.  Overall, it simply improves the user experience.

To do root-cause analysis, you first need to choose a network monitoring approach that collects the appropriate data. As WildPackets' Jay Botelho wrote in October, there are three primary data sources for network monitoring solutions: Simple Network Management Protocol (SNMP), Flow Records, and the Packet themselves. Regardless of which approach you chose, you're going to have to make compromises. Two metrics that are useful when making those compromises are data granularity and data accuracy.  The compromises you make here determine whether or not you're able to do root-cause analysis.

For example, a help desk may receive a call where a particular user is having a problem with a particular application. This might go unnoticed with a flow record-based approach, as the high-level alerts that have been configured may not flag this for attention. In this circumstance, having the packets and the payload can be important. As all packets are captured (unlike flow records, which rely on statistical sampling), packet-based network monitoring provides information that is 100 percent accurate for each flow. As Botelho notes in his article,

"Generally speaking, you want to use the appropriate monitoring technology for the appropriate need. If you just need to check the status of a device, then SNMP may be all you need...If you are interested in sampled high-level information about who is talking to whom, approximately how much traffic they are generating or receiving, then flow-based analysis may be fine...Lastly, if you need all the detail about what is happening on the network, as well as possibly being able to go back in time to prove what happened on the network, then a packet-based solution would be best."

By planning appropriately and considering issues like data granularity and data accuracy, organizations can move beyond network monitoring and set themselves up for root cause analysis with an approach and solution that best fits their needs.

If anyone had doubts about the strength of the network monitoring/reporting/troubleshooting market, this week's news should put those doubts to rest. Of course we're referring to the announced purchase of NetQoS by CA for $200M in cash. This is a multiplier of approximately 4 over the reported 2008 annual revenue of $56M from NetQoS. Not a bad deal indeed for the current economic climate.
 
Though not sexy, and often considered commoditized, the network monitoring/reporting/troubleshooting market may be just the opposite. At the core of this market is packets. Yes, I said packets. Geeky, techie, call it what you want but we're back to basics on this one. Accumulating statistics on the basis of packets, whether through direct, deep packet inspection or through the use of flow-based technology available in most contemporary routers and switches, is proving to be a highly valuable capability, especially as networks grow and IT staffs shrink.
 
For years it seems the industry tried to steer clear of packets, looking to higher-level solutions like SNMP, but in the end it's becoming clear that packets never lie, and to obtain reliable network data one must start with network packets.
 
Now, I think we're going to come full circle on this one. Even the solution from NetQoS - which relies on flow-based information from routers and switches - can't provide the level of detail compared to complete packet inspection.  And this technique provides no capability of unequivocally determining a root-cause for reported problems. It merely shows network trends and alerts when thresholds are exceeded - it does not allow for detailed analysis as the offending data has already passed through the network. That's why NetQoS partnered with Network Instruments and OEM'd their Gigastor solution. With that partnership, NetQoS could provide the full monty - network reporting, monitoring, and troubleshooting. Or, as I see it, coming full circle back to packet capture and deep packet inspection -- the only way to truly identify network issues.
 
The purchase of NetQoS by CA provides validation that the network monitoring/reporting/troubleshooting market is not only alive and well, it is thriving. The traditional, "full-featured" network management solutions (like CA) are realizing that quality network monitoring, reporting, and troubleshooting are key features, and that they need capabilities like flow-based monitoring and deep packet inspection to continue to claim that their solutions are complete. The value of these types of solutions continues to rise, and the "big boys" have only two options, start developing fast or acquire. And with the head start many of us have with our network monitoring/reporting/troubleshooting solutions acquisition is by far the better alternative.