Top 10 Key Metrics for NetFlow Monitoring

Top 10 Key Metrics for NetFlow MonitoringNetFlow is a feature that was introduced on Cisco routers that provides the ability to collect IP network traffic as it enters or exits an interface. By analyzing the data provided by NetFlow, a network administrator can determine things such as the source and destination of traffic, class of service, and the causes of congestion.

There are numerous key metrics when it comes to Netflow Monitoring:

1-Netflow Top Talkers

The flows that are generating the heaviest system traffic are known as the “top talkers.” The NetFlow Top Talkers feature allows flows to be sorted so that they can be viewed, to identify key users of the network.

2-Application Mapping

Application Mapping lets you configure the applications identified by NetFlow. You can add new applications, modify existing ones, or delete them. It’s also usually possible to associate an IP address with an application to help better track applications that are tied to specific servers.

3-Alert profiles

Alert profiles makes network monitoring using NetFlow easier. It allows for the Netflow system to be watching the traffic and alarming on threshold breaches or other traffic behaviors.

4-IP Grouping

You can create IP groups based on IP addresses and/or a combination of port and protocol. IP grouping is useful in tracking departmental bandwidth utilization, calculating bandwidth costs and ensuring appropriate usage of network bandwidth.

5-Netflow Based Security features

NetFlow provides IP flow information in the network. In the field of network security, IP flow information provided by NetFlow is used to analyze anomaly traffic. NetFlow based anomaly traffic analysis is an appropriate supplement to current signature-based NIDS.

6- Top Interfaces

Included in the Netflow Export information is the interface that the traffic passes through. This can be very useful when trying to diagnose network congestion, especially on lower bandwidth WAN interfaces as well as helping to plan capacity upgrades / downgrades for the future.

7- QoS traffic Monitoring

Most networks today enable some level of traffic prioritization. Multimedia traffic like VoIP and Video which are more susceptible to problems when there are network delays typically are tagged as higher priority than other traffic like web and email. Netflow can track which traffic is tagged with these priority levels. This enables network engineers to make sure that the traffic is being tagged appropriately.

8- AS Analysis

Most Netflow tools are able to also show the AS (Autonomous System) number and well known AS assignments for the IP traffic. This can be very useful in peer analysis as well as watching flows across the “border” of a network. For ISP’s and other large organizations this information can be helpful when performing traffic and network engineering analysis especially when the network is being redesigned or expanded.

9- Protocol analysis

One of the most basic metrics that Netflow can provide is a breakdown of TCP/IP protocols in use on the network like TCP, UDP, ICMP etc. This information is typically combined with port and IP address information to provide a complete view of the applications on the network.

10- Extensions with IPFIX

Although technically not NetFlow, IPFIX is fast becoming the preferred method of “flow-based” analysis. This is mainly due to the flexible structure of IPFIX which allows for variable length fields and proprietary vendor information. This is critical when trying to understand deeper level traffic metrics like HTTP host, URLs, messages and more.

Thanks to NMSaaS for the article. 

How To Monitor VoIP Performance In The Real World

How To Monitor VoIP Performance In The Real WorldIt’s one of the most dreaded calls to get for an IT staff member – the one where a user complains about the quality of their VoIP call or video conference. The terms used to describe the problem are reminiscent of a person who brings their car in for service because of a strange sound “ I hear a crackle”, or “it sounds like the other person is in a tunnel” or “I could only hear every other word – and then the call dropped”. None of these are good, and unfortunately, they are all very hard to diagnose.

As an IT professional, we are used to solving problems. We are comfortable in a binary world, something works or it doesn’t and when it doesn’t, we fix the issue so that it does. When a server or application is unavailable, we can usually diagnose and fix the issue and then it works again. But, with VoIP and Video, the situation is not so cut and dried. It’s rare that the phone doesn’t work at all – it usually “works” i.e the phone can make and receive calls, but often the problems are more nuanced; the user is unhappy with the “experience” of the connection. It’s the difference between having a bad meal and the restaurant being closed.

In the world of VoIP, this situation has even been mathematically described (leave it to engineers to come up with a formula). It is called a Mean Opinion Score (MOS) and is used to provide a data point which represents how a user “feels” about the quality of a call. The rating system looks like this:

How To Monitor VoIP Performance In The Real World

Today, the MOS score is accepted as the main standard by which the quality of VoIP calls are measured. There are conditional factors that go into what makes an “OK” MOS score which take into account (among other things) the CODEC which is used in the call. As a rule of thumb, any MOS score below ~3.7 is considered a problem worth investigating, and anything consistently below 2.0 is real issue. *(many organizations use a different # other than 3.7, but it is usually pretty close to this). The main factors which go into generating this score come from 3 KPI’s

  1. Loss
  2. Jitter
  3. Latency / Delay

So, in order to try and bring some rigor to monitoring VoIP quality on a network (and get to the issues before the users get to you) network staff need to monitor the MOS score for VoIP calls. In the real world there are at least three (separate) ways of doing this:

1) The “ACTUAL” MOS score from live calls based on reports from the VoIP endpoints

Some VoIP phones will actually perform measurements of the critical KPI’s (Loss, Jitter, and Latency) and send reports of the call quality to a Call Manager or other server. Most commonly this information is transmitted using the Real Time Control Protocol (RTCP) and may also include RTCP XR (for eXtended Report) data which can provide additional information like Signal to Noise Ratio and Echo level. Support for RTCP / RTCP XR is highly dependent on the phone system being used and in particular the handset being used. If your VoIP system does support RTCP / RTCP XR you will still need a method of capturing and reporting / alarming on the data provided.

2) The “PREDICTED” MOS score based on network quality metrics from a synthetic test call.

Instead of waiting for the phones to tell you there is a problem, many network managers implement a testing system which makes periodic synthetic calls on the network and then gathers the KPI’s from those calls. Generally, this type of testing takes place completely outside of the VoIP phone system and uses vendor software to replicate an endpoint. The software is installed at critical ends of a test path and then the endpoints “call” each other (by sending an RTP stream from one endpoint to another). These systems should be able to exactly mimic the live VoIP system in terms of CODEC used and QoS tagging etc so that the test frames are passed through the network in exactly the same way that a “real” VoIP call would be. These systems can then “predict” the Quality of experience that the network is providing at that moment.

3) The “ACTUAL” MOS score bases on a passive analysis of the live packets on the network.

This is where a passive “probe” product is put into the network and “sniffs” the VoIP calls. It can then inspect that traffic and create a MOS score or other metrics which is useful to determine the current quality of service being experienced by users. This method removes any need for support from the VoIP system and also does not require the network to handle additional test data, but does have some drawbacks as this method can be expensive and may have trouble accurately reading any encrypted VoIP traffic.

Which is best? Well, they both all have their place, and in a perfect world an IT staff would have access to live data and test data in order to troubleshoot an issue. In an even more perfect world, they would be able to correlate that data in real time to other potentially performance impacting information like router / switch performance data and network bandwidth usage (especially on WAN circuits).

In the end, VoIP performance monitoring comes down to having access to all of the critical KPI’s that could be used to diagnose issues and (hopefully) stop users from making that dreaded service call.

How To Monitor VoIP Performance In The Real World

Thanks to NMSaaS for the article.

Webinar- The Importance of VoIP Testing

Industry Analysts say that approximately 85% of today’s networks will require upgrades to their data networks to properly support high-quality VoIP and video traffic.

Organizations are always looking for a way to reduce costs, and that’s why they often try to deploy VoIP by switching voice traffic over to a LAN or WAN links.

In a lot of cases the data networks which the business has chosen cannot handle VoIP traffic accordingly, generally speaking voice traffic is uniquely time sensitive, it cannot be qued and if data grams are lost the conversation can become choppy.

To ensure this doesn’t happen many organizations will conduct a VoIP quality test in the pre and post deplomyent stage.

NMSaaS Free Webinar - The Importance of VoIP Testing

Pre-Deployment testing

There are several steps network engineers can take to ensure VoIP technology can meet expectations. Pre-deployment testing is the first step towards ensuring the network is ready to handle the VoIP traffic.

After the testing process, IT staff should be able to:

  • Determine the total VoIP traffic the network can handle without audio deprivation.
  • Discover any configuration errors with the network and VoIP equipment.
  • Identify and resolve erratic problems that affect network and application performance.
  • Identify security holes that allow malicious eavesdropping or denial of service.
  • Guarantee call quality matches user expectations.

Post deployment testing

Places that already have VoIP/video need to constantly and easily monitor the quality of those links to ensure good quality of service. Just because it was fine when you first installed it, doesn’t mean that it is still working well today, or will be tomorrow.

The main objective of post deployment VoIP testing is to measure the quality and standard of the system before you decide to go live with it. This will in return stop people from complaining about poor quality calls.

Post-deployment testing should be done early and often to minimize the cost of fault resolution and also to provide an opportunity to apply lessons learned later on during the installation.

In both pre and post deployment the testing needs to be simple to setup and provide at a glance actionable information including alarms when there is a problem.

Continuous monitoring

In many cases your network changes every day as devices are added or removed, these could include laptops, IP phones or even routers. All of these contribute to the continuous churn of the IP network experience.

A key driving factor for any business is finding any faults before they become a potential hindrance on the company, regular monitoring will eliminate any potential threats.

In this manner, you’ll receive maximum benefit from your VoIP investment. Regular monitoring builds upon all the assessments and testing performed in support of a deployment. You continue to verify key quality metrics of all the devices and the overall IP network health.

If you missed our webinar last week you can watch the live recording of it here

listen_button

Thanks to NMSaaS for the article.

Managing End­‐to­‐End VoIP Networks

VoIP Management Overview

There are any number of VoIP management solutions available in today’s market place. However, when you start to drill-­down into the capabilities of these tools they tend to focus on the performance elements of your network infrastructure and associated VoIP metrics (e.g. RTT, RTD\Latency, Packet Loss, Jitter, Moss, R-­‐Factor etc.) , assumptions are made on infrastructure and fault management being in place, so it is vitally important to assess the complete picture of your solution requirement before selecting the choice of tool to be deployed. VoIP monitoring lies central to this, as VoIP downtime and poor VoIP performance directly impacts such things as business performance, profitability and revenue. Achieving a consistent level of quality on VoIP calls requires multiple dependent components working properly, thus the importance of a monitoring system that correlates the infrastructure, performance, and fault management into an integrated End-­to­‐End view is vital.

In order to manage a VoIP solution End­‐to­‐End you need to monitor the hosting environment, (e.g. CUCMs, V.Rec, V.Mail, V.Gateways, SIP Trunks, etc.) the WAN (e.g. CE Access Routers, Core WAN if you’re an ISP\MSP), and the end user locations. It is then vital that you on‐board the identified components to best practice processes in order that you start to build up the End-to-End visibility of your VoIP managed service solution. Once the physical device component infrastructure has been on-boarded and tested (e.g. SNMP trap, syslog collection, Netflow, etc.), for accuracy around the fault and event management, you can then build your performance measurements & reporting requirements based on Service Level Agreements (SLAs), Key Point Indicators (KPIs), and threshold alarm management criteria for proactive management purposes.

Having End-to-End visibility of your VoIP solution is vital when troubleshooting issues and potential problem areas, as assuring a great customer experience can no longer be assessed simply by having green LEDs on a dashboard. StableNet® is a unified End-to-End Service Quality Management platform and therefore, takes a customer-centric approach to the service assurance monitoring infrastructure, performance, and fault management in a single solution. A unified management approach significantly cuts the time it takes to analyze complex issues in the managed environment. Best practice on-boarding reduces time to operate and assures rapid fault identification with root-cause-analysis (RCA), unique to the StableNet® architecture.

Infosim StableNet® is the only all-in-one unified End-to-End Service Quality Management tool capable of delivering and visualizing a complete End-to-End VoIP service solution monitoring system in a single product that has proven ROI (Return-­‐On-­‐Investment) in reducing capital (CAPEX) and operating (OPEX) expenditure, with conceivable savings in customer service credits thru reduced MTTR (Mean-Time-To-Repair), and increased service availability.

Holistic VoIP End-to-End Management using StableNet®

Holistic VoIP End-to-End Management using StableNet

Read more…………

Infosim Managing End-to-End VoIP Networks

Ensuring VoIP Success with GigaStor™ Portable

practice1

Avoiding The Perfect VoIP Storm

Although now a mainstream technology, managing VoIP remains a challenge for even the most seasoned IT pro. The application’s sensitivity to packet loss and delay and users intolerance for anything less than audio perfection can create a troubleshooting nightmare.

1. Understand and measure call quality

There are a variety of metrics and variables you can use to assess VoIP call quality, including jitter, MOS, R-Factor, gap density, burst density, Quality of Service prioritization, and compression techniques. Ensure accurate analysis by learning how to measure these attributes.

2. Make QoS a priority

Incorrectly set QoS precedence for VoIP traffic leads to delays in packet delivery and reduced call quality.

3. Deploy analysis tools strategically

Placing analysis consoles and probes on your network requires a clear understanding of VoIP traffic patterns. Are you concerned with monitoring VoIP traffic locally, over WAN links, or both? Depending on your objectives, place your analysis tools to ensure optimal visibility of VoIP communications.

4. Compare jitter to overall bandwidth utilization

When jitter becomes a problem, look at the big picture. A correlation between jitter and bandwidth usage means the problem is overall network usage. If there is no direct correlation, excessive jitter might be caused by isolated network factors that require further investigation.

5. Proactively monitor VoIP activity

Utilize monitoring and notification tools to speed problem resolution. Determine “normal” or “acceptable” levels of activity for your network and its users. Then set up thresholds within your analyzer to alert you when performance degrades.

6. Baseline network traffic

To truly understand VoIP traffic, capture and store long-term network data. Only with critical trending data can you accurately perform baselining activities. Baselining validates VoIP performance, helps future capacity planning efforts, and provides long-term understanding of VoIP health.

Visit our online resources for in-depth info on VoIP and other unified communication applications.

tech1Can’t See Call Details?

According to NI University instructor Mike Motta, one of the most common problems users encounter monitoring VoIP is determining which voice stream goes with which call.

You’ll want to know the call signaling protocol your VoIP application uses, and be sure to capture all call-setup information.

There are four common call signaling protocols: H323, Cisco Skinny, SIP, and MGCP. This is helpful to know when applying filters and running reports in Observer®.

The most common problem with VoIP monitoring is failing to capture all the call-set up information. When this happens, Observer’s Expert Analysis can’t match up the RTP stream to the correct call, and won’t provide details on a per-call basis.

With complete setup info captured, go to VoIP Events under Expert Data, where Observer displays a summary of call metrics including jitter, packet loss, R-Factor and MOS scores. Clicking on the VoIP Events Call tab lists individual calls in a browsable tree. By clicking on the calls listed on the left side of the display, you can break each one down by direction and stream of RTP/RTCP packets.

tech2

Thanks to Network Instruments for the article.

Setting VoIP Server Configuration

It’s important to have VoIP servers properly configured within your monitoring solution to correctly identify and display VoIP traffic and connections. If the server IP and type aren’t properly configured, it may be difficult to identify when calls were established (call setup) and completed (call teardown). In this discussion, we’re going to explore how to properly configure Observer Expert to handle Avaya systems under the Expert VoIP Settings menu.

Avaya VoIP systems use specialized media and control processors to set up and teardown calls. Without configured settings a call transferred from one phone to another may not be followed. This leaves Observer to assume that the original call timed-out, so it establishes the transferred call as a new call. But with Observer, there’s an easy way to identify these servers to help identify calls.

  • Choose Capture > Packet Capture from the Observer main menu.
  • From the Packet Capture screen click the Decode button at the top. From the Decode and Analysis screen select the Expert Analysis tab in the lower left-hand corner. Then select VoIP Events on the left side, listed under Expert Data.
  • Click on Settings within the VoIP Events menu. This will cause the Expert VoIP Settings menu to appear. Under the General tab, you can list specific servers in the white box below Server Configuration.
  • In the white box, click below IP to list the address of the server. You can then choose the IP type from the drop-down menu indicating it as a Server IP, Outside IP, Media Processor, or Control Processor.

Thanks to Network Instruments for this Article

OPNET Talks End-to-End Management and Monitoring of Unified Communications

Unified Communications (UC), especially the real-time applications, is unique because of user expectations. Management of UC is very important as it ensures service availability and service performance, as well as other aspects of UC including security and compliance.

“At the end of the day, the user expectation is real-time communication services are available any time all the time,” Gurmeet Lamba, VP R&D Unified Communications Management, OPNET told TMCnet in an exclusive interview.

For example, if your phone is not connected you can’t make a phone call. A user has an expectation that the phone should work every it’s used. If you call somebody on a cell phone, but the voice is broken, you can’t complete your conversation. In both of these cases, the service performance is not adequate and the user’s expectations are not met.

“The reason the user expectation is so high is because it is so critical to the users living their lives,” said Dave Roberts, director of product management, Unified Communications, OPNET. “You car should start, your lights should turn on, your shower should run.

”End-to-End in UC means managing and monitoring the breadth and the depth of all components involved in orchestrating a successful communications session. To make this happen in today’s world, there are a number of components that are involved.

For instance, in order to complete a conference call, all parties phones must work, the network to the conferencing server must work, and the conferencing server itself must work properly.

End-to-end management and monitoring means getting visibility and performance of every single component involved in the complete communication session.  End-to-end involves management and monitoring of every component in the breadth and the depth of the communication session. The breadth consists of the applications – unified messaging, conferencing server, devices, call management servers, etc. When it comes to the depth, components include a client such as a phone or an application on your computer, the configuration of the application, the network, the virtual server, and the physical server.

“You can see the technology stack from top to bottom and from left to right. All of it has to work,” explained Lamba. “Communication is the oil that keeps everything moving

”When it comes to the most perfect End-to-End Management and Monitoring UC solution ever invented, Dave Roberts, director of product management, Unified Communications, OPNET, said, “The first goal would be to have 100 percent visibility to all of the information at all times. You would have to know every configuration of everything that is involved with the communication and every state of everything happening on the network at any instance. And then, it would have to have a way to correlate and use that information to do to a few things including detect problems, analyze information to find the cause of the problem, and fix the problem.

Article from TMCnet.com by Amada Ciccatelli  on OPNET