Vivinet Diagnostics can diagnose many VoIP call quality problems on your network right out of the box. However, some additional configuration can ensure your diagnoses are based on as much information about your particular network and its quality requirements as is possible to collect.
For more information, see the following topics:
Vivinet Diagnostics uses SNMP (Simple Network Management Protocol) to gather important information about VoIP data patterns and performance from your network hardware, including routers and VoIP gateways.
Configure SNMP information in the Vivinet Diagnostics Console or in NetIQ AppManager or Vivinet Assessor. This configuration provides Vivinet Diagnostics the permissions it needs to access the MIBs (management information bases) on SNMP-enabled network devices.
The type of information you configure varies according to the version of SNMP implemented on your network devices. Vivinet Diagnostics supports SNMP versions 1, 2, and 3.
For more information, see the following topics:
For SNMPv1 and SNMPv2, the community string acts as a password to let Vivinet Diagnostics collect information from the MIB on SNMP-enabled devices.
Before you run a Diagnosis, configure SNMP properties to let Vivinet Diagnostics communicate with devices on your network. If you do not supply your community string information, the Vivinet Diagnostics attempts to use the default SNMP community string, which is not secure and therefore is probably not in use on your network.
NOTE:Each string’s authorization indicates the type of variables it can access from a device MIB: either read/write or read-only. Read/write strings are required for certain Cisco IOS IP SLA actions and traceroute testing.
On the Options menu, click SNMP.
On the SNMPv1v2 tab, click Add. Complete the fields according to the information below:
|
Field |
Description |
|---|---|
|
Community String |
Provide the SNMP community string currently in use on your network. Community strings for read-only variables may be different from those for read/write variables. Add each valid community string on your network to the list, one by one. Strings are limited to 64 characters. Because the SNMP community string allows access to the MIB of each network device, secure the console computer to protect this and any other sensitive information. SNMP community strings are case-sensitive. |
|
Community string has read/write authorization |
Identifies the type of variable Vivinet Diagnostics can access from a VoIP device’s MIB with this community string. Read/write community strings can access both read/write and read-only variables. Read/write authorization is required for Cisco IOS IP SLA tests. |
|
Community string has read-only authorization |
Identifies the type of variable Vivinet Diagnostics can access from a VoIP device’s MIB with this community string. Read-only community strings can access only read-only variables. |
|
Extended application support |
Leave this option unselected. |
Vivinet Diagnostics diagnoses devices using SNMP v3 by borrowing the SNMP v3 permissions you configured for NetIQ Vivinet Assessor or NetIQ AppManager. To use SNMP v3 permissions from either application, Vivinet Diagnostics looks for matching permission configurations in the following order:
AppManager Security Manager entry for a single IP address with a VDiag label
AppManager Security Manager entry for a single IP address with a NetworkDevice label
Vivinet Assessor device range, single IP address, or fully qualified domain name
AppManager Security Manager “default” entry with a VDiag label
AppManager Security Manager “default” entry with a NetworkDevice label
NOTE:In environments with a mixture of SNMP v2 and v3 devices, you must configure Vivinet Assessor or AppManager Security Manager permissions for every SNMP v3-enabled device.
If all other attempts fail, Vivinet Diagnostics tries the SNMP v1 and SNMP v2 community strings until it finds one that works, or until they all fail.
For more information, see the following topics:
In order for Vivinet Diagnostics to use the permissions configured for Vivinet Assessor, Vivinet Assessor must be installed on the computer on which Vivinet Diagnostics is installed.
On the Options menu, click SNMP.
On the SNMPv1/v2 tab, ensure the Community String is public and the Authorization is read-only, even if you have no SNMPv1 or v2 devices configured on your network.
On the SNMPv3 Vivinet Assessor tab, select Use SNMPv3 profiles defined in NetIQ Vivinet Assessor.
In the list, select the assessment that contains the SNMPv3 profiles you want to you in Vivinet Diagnostics. If you have recently created an assessment that does not appear in the list, click Refresh Assessment List.
The list contains only those assessments for which at least one SNMPv3 profile exists.
To use SNMP v3 permissions from AppManager, Vivinet Diagnostics searches AppManager Security Manager for entries created with either VDiag or NetworkDevice labels. If you have no NetworkDevice-labeled permissions that provide access to the devices you want to diagnose, you can configure permissions with a VDiag label. In addition, you can override a NetworkDevice label with information configured with a VDiag label. For more information, see Configuring Vivinet Diagnostics SNMP v3 Permissions in AppManager.
AppManager and Vivinet Diagnostics do not need to be installed on the same computer.
On the Options menu, click SNMP.
On the SNMPv1/v2 tab, ensure the Community String is public and the Authorization is read-only, even if you have no SNMPv1 or v2 devices configured on your network.
On the SNMPv3 AppManager tab, select Use SNMPv3 profiles defined in NetIQ AppManager.
In the Server field, type the fully qualified domain name of your AppManager server.
In the Repository field, type the name of your AppManager repository.
If access to your AppManager server requires Windows authentication, select Use Windows authentication.
If access requires SQL Server authentication, select Use SQL Server authentication, and then provide the Login name and Password.
To ensure Vivinet Diagnostics can connect to your AppManager repository, click Test Connection. A message indicates whether the connection attempt was successful.
If the attempt was not successful, ensure you are attempting to access a repository for which you have connectivity permissions. Also, if you selected Use SQL Server authentication, ensure your login name and password are correct.
Vivinet Diagnostics supports the following authentication modes for SNMP v3:
No authentication; no privacy
Authentication; no privacy
Authentication and privacy
In addition, the application supports the following protocols for SNMPv3:
MD5 (Message-Digest algorithm 5, an authentication protocol)
SHA (Secure Hash Algorithm, an authentication protocol)
DES (Data Encryption Standard, encryption protocol)
Your SNMP v3 implementation may support one or more combinations of mode and protocol. That combination dictates the type of information you configure in AppManager Security Manager: User Name (or entity), Context name, protocol name, and protocol passwords.
You must configure AppManager Security Manager with the SNMP v3 permissions that provide Vivinet Diagnostics with access to the devices you want to diagnose. In environments with a mixture of SNMP v2 and v3 devices, you must explicitly identify every SNMP v3-enabled device.
On the Custom tab in Security Manager, complete the following fields:
|
Field |
Description |
|---|---|
|
Label |
VDiag To share this configuration with the AppManager for Network Device module, type NetworkDevice. |
|
Sub-label |
|
|
Value 1 |
SNMP user name or entity configured for the device. All SNMP v3 modes require an entry in the Value 1 field. |
|
Value 2 |
Name of a context associated with the user name or entity you entered in the Value 1 field. A context is a collection of SNMP information that is accessible by an entity. If possible, enter a context that provides access to all MIBS for a device. If the device does not support context, type an asterisk (*). All SNP v3 modes require an entry in the Value 2 field. |
|
Value 3 |
Combination of protocol and password appropriate for the SNMPv3 mode you have implemented.
|
The Cisco CallManager application uses a predefined SNMP community string named “public.” Its rights are set to “none.” To diagnose VoIP problems for CallManager, change those rights to be “read-only.” After changing the rights, you can add the community string to Vivinet Diagnostics.
In Control Panel, double-click Administrative Tools, and then double-click Services.
Right-click SNMP Service and select Properties.
On the Security tab, in the Accepted community names panel, select public and then click Edit.
In the Community rights list, select READ ONLY, and then click OK twice to exit the Properties dialog box.
Configure the SNMP community string in Vivinet Diagnostics. For more information, see Configuration for Versions 1 and 2.
Cisco CallManager handles VoIP call processing and maintains records about call activity. Vivinet Diagnostics can gather important information to use in diagnosing your network problems by querying CallManager applications that are active on the VoIP network.
You must configure information about at least one CallManager. Vivinet Diagnostics should be able to locate all others based on that information. You can configure more CallManagers if necessary.
NOTE:Ensure SNMP is running on the CallManagers to be queried.
On the Options menu, click CallManager.
To add a CallManager to the list, click Add in the CallManagers section.
Specify the IP network address of the CallManager server in dotted notation, such as 122.34.56.78, or a DNS hostname, such as callmgrsvr01. The address or hostname must be no more than 64 characters in length.
Click OK to add the new CallManager to the list.
To remove a CallManager from the list, highlight its name or address in the list and click Delete.
If the CallManagers on your network have been secured with user ID and password protection, configure the CallManager security information into Vivinet Diagnostics.
For CallManager versions earlier than version 4.0, the default user ID and password for any CallManager are actually the default SQL Server user ID and password, which are not secure. Vivinet Diagnostics can gather a lot of useful diagnostic information from CallManagers using this CallManager security information.
NOTE:The CiscoCCMCDR user ID is already configured into Vivinet Diagnostics. If you changed this ID, configure the new ID in Vivinet Diagnostics. In addition, configure any additional SQL users you may have created.
On the Options menu, click CallManager, and then click Add in the User IDs and Passwords section.
In the User ID and Password fields, type the SQL Server user ID and password.
In CallManager versions 4.0 and later, the method used for obtaining information is different from earlier versions. For security reasons, SQL Server user IDs and passwords are no longer used to access information. Instead, CallManager uses a new API called AXL (AVVID XML Layer). Configure Vivinet Diagnostics with the user ID and password that have authority to use this API. In most cases, the CallManager administrator user ID and password have the authority.
NOTE:You may have used the Cisco Multilevel Administration (MLA) application to set up other accounts to have the same authorization.
On the Options menu, click CallManager, and then click Add in the User IDs and Passwords section.
In the User ID and Password fields, type the AXL user ID and password.
You set thresholds to control how Vivinet Diagnostics evaluates network conditions and reports them as “issues” in the Diagnose view. To set thresholds, click Thresholds from the Options menu.
A collected statistic crosses a threshold, and thereby flags an issue, when it either exceeds or fails to meet the threshold level you set. For each metric, you can set one or two different thresholds. Values discovered during a Diagnosis that exceed a Marginal threshold indicate poor VoIP performance. Values that exceed the Good threshold indicate marginal, or barely acceptable, performance.
Thresholds determine the performance rating assigned to each performance metric in the Results portion of the Diagnosis. They also determine the severity assigned to any issue discovered during a Diagnosis. For more information, see Section 5.1.9, Severity.
Threshold settings apply only to the present Diagnosis unless you select Set As Defaults. This option ensures the settings you select apply to any new diagnoses you configure. The settings can be changed at any point. However, if you change a threshold for a Diagnosis that has already run and has results, those results will be cleared.
Click Restore Defaults to change threshold settings back to the values you previously set as defaults. If you never changed the defaults, Restore Defaults changes the thresholds back to the recommended values — the settings Vivinet Diagnostics uses by default. However, after you select Set As Defaults to set new default values, you must manually restore the recommended values. See the following threshold definitions for a discussion of the default values for each tab in the Thresholds dialog box.
Use the Call Quality tab to set thresholds for MOS, R-value, delay, jitter buffer loss, and lost data.
|
Threshold Type |
Description |
|---|---|
|
MOS |
Refers to the Mean Opinion Score, which represents the quality of a VoIP transmission by factoring in the “mouth-to-ear” characteristics of a speech path. Vivinet Diagnostics calculates the MOS by evaluating simulated VoIP traffic based on a standardized model. A MOS of 5 is considered excellent. A MOS of 1 is unacceptably bad. The default is 4.03 for Good performance. For more information, see Section 5.3.7, Mean Opinion Score. You can select either MOS or R-value, not both. MOS is the default selection. The call quality metric you choose is displayed in the Diagnosis table of the Report view. However, both metrics are displayed on the Performance tab of the Results table in the Report view. After you set a MOS threshold, the R-values for Good and Marginal change accordingly. Note, a single MOS score can map to a range of R-values. Therefore, the equation Vivinet Diagnostics uses to convert MOS to R-value (and vice versa) produces an approximate R-value. For example, with a MOS score of 4.1, the conversion equation produces an R-value of 82.64. However, when converting an R-value of 82.64, the equation produces a MOS of 4.12, a small, but noteworthy, difference. |
|
R-value |
Call quality value derived from delays and equipment impairment factors. An R-value can be mapped to an estimated MOS. R-values range from 100 (excellent) to 0 (poor). The default is 80.45 for Good performance. For more information, see Section 5.3.9, R-value. You can select either MOS or R-value, not both. The call quality metric you choose is displayed in the Diagnosis table of the Report view. However, both metrics are displayed on the Performance tab of the Results table in the Report view. After you set an R-value threshold, the MOS values for Good and Marginal change accordingly. Note, a range of R-values can map to a single MOS. Therefore, the equation Vivinet Diagnostics uses to convert R-value to MOS (and vice versa) produces an approximate MOS. For example, with an R-value of 82.64, the conversion equation produces a MOS of 4.12. However, when converting a MOS of 4.12, the equation produces an R-value of 83.28, a small, but noteworthy, difference. |
|
Delay |
Determines how much delay (latency) in milliseconds can be detected for a simulated VoIP call before Vivinet Diagnostics reports an issue. Vivinet Diagnostics uses the delay statistic when calculating a MOS for simulated VoIP traffic sent between the Target Devices. The default is 150 ms for Good performance. For more information, see Section 5.3.3, Delay. |
|
Jitter Buffer Loss |
Determines how much datagram loss due to jitter (or delay variation) can be detected for a VoIP call before Vivinet Diagnostics reports an issue. Any jitter detected in the call is compared to the size of the jitter buffer in the call script. Jitter buffer lost datagrams are then expressed as a percentage of all datagrams sent. Vivinet Diagnostics uses the jitter buffer loss statistic when calculating a MOS for simulated VoIP traffic sent between the Target Devices. The default is 0.500% for Good performance. For more information, see Section 4.2.5, Defining Jitter Buffer and Section 5.3.5, Jitter Buffer Loss. |
|
Lost Data |
Determines how much packet loss can be detected for a simulated VoIP call before Vivinet Diagnostics reports a problem. Equals the number of datagrams lost between the Target Devices, expressed as a percentage of all data sent. Vivinet Diagnostics includes data loss when calculating a MOS for simulated VoIP traffic. The default is .500% for Good performance. For more information, see Section 5.3.6, Lost Data. |
Use the Device/Link tab to set thresholds for WAN and LAN interface bandwidth utilization, device CPU utilization, and insufficient bandwidth.
|
Threshold Type |
Description |
|---|---|
|
WAN interface bandwidth utilization |
Determines how much traffic a particular WAN link can carry, expressed as a percentage of the total capacity of that link, before Vivinet Diagnostics reports a problem. Vivinet Diagnostics defines a WAN link as any interface slower than 10 Mbps. The default is 30% for Good performance. For more information, see Section 5.3.8, Network Congestion. |
|
LAN interface bandwidth utilization |
Determines how much traffic a particular LAN link can carry, expressed as a percentage of the total capacity of that link, before Vivinet Diagnostics reports a problem. Vivinet Diagnostics defines a LAN link as any interface 10 Mbps or faster. The default is 50% for Good performance. For more information, see Section 5.3.8, Network Congestion. |
|
Device CPU utilization |
Refers to the percentage of processor (CPU) time being taken up by network processes. Vivinet Diagnostics checks CPU utilization on any network device that carries the VoIP RTP traffic between the Target Devices during a Diagnosis. It does not check CPU utilization on the end devices themselves. The default is 30% for Good performance. |
|
Insufficient bandwidth |
Determines how little bandwidth can be available on a particular VoIP network link before Vivinet Diagnostics reports an issue. The default is 35 kbps for Marginal performance (only determines “insufficient” bandwidth, not “sufficient,” and therefore, does not have a Good threshold). For more information, see Section 5.3.4, Insufficient Bandwidth. |
Use the POTS Interface tab to set thresholds for voice signal strength, ACOM, ERL, and T1/E1 bearer channel utilization.
|
Threshold Type |
Description |
|---|---|
|
Signal |
Voice signal strength is a measurement of decibel relative to one milliwatt. Use this field to specify the thresholds for Good and Marginal voice signal strength. |
|
ACOM |
Short for ACombined, ACOM is equal to ERL + ERLE (Echo Return Loss Enhancement). ERLE is the amount of echo provided by an echo canceller. Use this field to specify thresholds for Good and Marginal ACOM decibel levels. |
|
ERL |
Echo Return Loss is the ratio of the power level of the transmitted voice signal to the power level of the echo signal generated by the VoIP gateway. ERL varies greatly depending on the switched telephone network connected to the VoIP gateway. There will always be echo whenever you have an analog trunk line connected to a digital network. Use this field to specify thresholds for Good and Marginal ERL decibel levels. |
|
T1/E1 Bearer Channel utilization |
Bearer channels are the channels in a T1 or E1 circuit that carry phone calls. Use this field to specify Good and Marginal thresholds for the percentage of bearer channels that can be in use at any time. |
Use the Traffic Class tab to set thresholds for traffic class utilization, priority queue depth, and dropped packet rate.
|
Threshold Type |
Description |
|---|---|
|
Traffic class utilization |
A traffic class is a particular category of traffic on an interface. For example, voice and data can be classified as individual traffic classes. Use this field to set the threshold for what is considered “marginal” traffic class utilization in your network. Vivinet Diagnostics can provide diagnoses only for those traffic classes for which priority queuing is enabled. For details about enabling priority queuing, see the QoS configuration documentation for your device. |
|
Priority queue depth |
Use this field to set the threshold for the highest number of packets that can be in the priority queue before being considered an issue. |
|
Dropped packet rate |
Use this field to set the highest acceptable rate at which packets are dropped due to factors such as queuing, policing, early detection, or traffic shaping. |
In a Nortel CS1000 environment, the Call Server provides call and connection management services for the IP network, and helps Vivinet Diagnostics determine whether the destination IP address is a phone in a Diagnosis triggered by AppManager.
The Signaling Server provides signaling interfaces to the IP network, and performs call control services such as the registration of terminals and gateways, admission control, IP address translation, and bandwidth control. The R-value SNMP trap on the Signaling Server provides the call quality information Vivinet Diagnostics uses in diagnoses triggered by AppManager. If you define a Diagnosis from the Define view, the Signaling Server provides the call quality information collected by RTPStatShow.
NOTE:Vivinet Diagnostics obtains the SNMP trap information from the NortelCS_Alarms and Action_DiagnoseNortelIPT AppManager Knowledge Scripts. For more information, see Section 8.0, Working with NetIQ AppManager.
When a trap comes in, Vivinet Diagnostics must determine whether the destination IP address is a phone. To this end, it queries the Signaling and Call Servers, which are not available for querying unless you configured all possible address/user ID/password combinations into Vivinet Diagnostics. Without complete or correct configuration information, Vivinet Diagnostics may not be able to determine whether the destination address is a phone, and instead will consider it to be “other,” for instance a VGMC or a voice application such as Call Pilot.
Vivinet Diagnostics also uses this configuration information to collect phone properties, RTPStatShow call quality information, and rTraceRoute path information.
Ensure you selected Nortel as your phone vendor, and then complete the following procedures for each Call Server and Signaling Server. For more information, see Section 3.5.7, Changing the Phone Vendor.
On the Options menu, click Call Server, and then click Add.
Complete the following fields:
|
Field |
Description |
|---|---|
|
Call Server |
IP address of the Call Server |
|
User ID |
SL1 level 1 user ID associated with the Call Server |
|
Password |
SL1 level 1 password associated with the Call Server |
On the Options menu, click Signaling Server, and then click Add.
Complete the following fields:
|
Field |
Description |
|---|---|
|
Signaling Server |
IP address of the Signaling Server |
|
User ID |
SL1 level 1 user ID associated with the Signaling Server If you never configured your Signaling Server with the LNAME option in overlay 17, the user ID is the default, which is admin. |
|
Password |
SL1 level 1 password associated with the Signaling Server |
When you installed Vivinet Diagnostics, you were asked to select the vendor (Nortel, Cisco, or Other) whose Target Devices you will use to run diagnostic tests. By selecting a vendor, you customize the Define view, and the Options menu. Cisco-specific options and fields will not appear when you select Nortel or Other as a vendor. The reverse is also true.
You can change vendors without having to reinstall Vivinet Diagnostics.
To change the phone vendor:
On the Options menu, click Phone Vendor and select Nortel, Cisco, or Other.
To make the selection permanent for future diagnoses, click Set As Default
NOTE:
If you run diagnoses between Performance Endpoints only, you can select any vendor.
To run diagnostic tests for Avaya devices, select Other.
The Virtual Router Redundancy Protocol (VRRP), implemented by Cisco and Nortel, provides for router failover. VRRP allows multiple routers to be configured together as one virtual router. This virtual router advertises a virtual IP address as the default gateway. At any one time, there is a Master router, which is the actual router acting as the default gateway, and one or more backup routers. If the Master router fails, one of the backup routers becomes the Master and begins routing traffic.
Vivinet Diagnostics’ SNMP queries to VRRP-enabled devices are successful if you configured VRRP so that the Master router’s real IP address is the same as the VRRP virtual IP address.
If router failover has occurred, or if the VRRP virtual IP address is not the same as the Master router’s real IP address, Vivinet Diagnostics’ SNMP queries cannot determine the real IP address of the Master router.
To enable Vivinet Diagnostics to query a Master router regardless of failover or VRRP IP address configuration, you must provide a list of VRRPs in use in your network. Perform the following steps for each router acting as a VRRP Master or backup.
On the Options menu, click VRRP, and then click Add.
Complete the following fields:
|
Field |
Description |
|---|---|
|
VRRP Router |
Management IP address of the router |
|
Virtual IP |
Virtual IP address of the virtual router |
|
VRID |
Virtual router identifier for the group of routers that back up the IP address you specified in the Virtual IP field. A virtual router is defined by its virtual router identifier and its associated IP addresses. |