PathSolutions Network Performance Manager
- 1001: Network Monitor startup is slow
The service attempts to communicate with network devices via the SNMPv2c protocol. If a device fails to respond to the SNMPv2c queries, the service will attempt to communicate via SNMPv1.
By default, the service will try three times to communicate with the device, waiting 3 seconds between each try. Thus, it can take 9 seconds for the device to fail to respond to SNMPv2c packets before an SNMPv1 packet is sent.
If there are a lot of devices on the network that only support SNMPv1, the service will have to wait 9 seconds for each device to fail before it is able successfully communicate with the device.
Workaround: It is recommended that all monitored network devices are upgraded to the latest release of code so they can support SNMPv2c.
Alternate: Edit the SNMPv1.cfg file and add the device’s IP address to this file. This will instruct PathSolutions Network Monitor to only communicate with this device via SNMP V1.
- 1002: Cannot connect to the license server through a proxy firewall
When the system tries to validate their license against the license server, it will fail if the user has a proxy server type of firewall. This may occur if the proxy firewall is programmed to block all direct outbound HTTPS (SSL port 443) requests.
Since the license validation server must be directly connected in order to prevent fraudulent verification of licenses, proxy interpretation of these requests cannot be permitted.
Workaround:The proxy firewall should be configured to permit bypassing the proxy for requests from the PathSolutions Network Monitor server that are sent to https://sub01.nlsubscription.com. The proxy firewall should be configured to permit this for the entire server where PathSolutions Network Monitor is installed. Configuring the proxy firewall to permit this connection from a single logged in user will not work, as the service does not run from a user context or login.
- 1004: System is not monitoring a specific switch or router
The device must be configured to support SNMP v1 or preferably SNMP v2c. If the device is unable to support either of these protocols, then it cannot be monitored.
Possible reasons that a device would not be listed in the Devices tab:
- The device is not configured in the PathSolutions Network Monitor configuration tool
- The device is an unmanaged router or switch and does not support SNMP
- The device is not configured for SNMP
- The SNMP read only community string in the device does not match the community string configured in PathSolutions Network Monitor
- The device may be configured to only respond to certain SNMP hosts
- The device may be behind a firewall that is preventing SNMP packets from flowing
Workaround:Use the Poll Device tool from the server where PathSolutions Network Monitor is installed to verify that SNMP packets are being sent and received with the device.
- 1005: Specific interfaces are not showing up on the interface listing
Interfaces can be ignored if they offer no monitoring value. The user should look in the C:\Program Files\PathSolutions\NetworkMonitor\IgnoreList.cfg file. This file contains all of the interfaces that the user has selected to be ignored.
Workaround: To add an interface back to monitoring, it should be deleted from this file. The file must be saved, and the SwitchMonitor service must be stopped and re-started to have this interface monitored again.
Certain interface types are automatically ignored by the system, as they typically offer no value. They are listed in the C:\Program Files\PathSolutions\NetworkMonitor\IgnoreType.cfg file. These interfaces (null, loopback, etc.) are ignored on all monitored devices. The list may be modified by adding interface descriptions or removing interface descriptions. The file must be saved and the PathSolutions Network Monitor service must be stopped and re-started to have these changes take effect.
- 1006: Emails are not being received from PathSolutions Network Monitor
Alerts and the Daily Network Weather Report are all sent out via SMTP email. The system must have a valid connection to an SMTP mailserver or SMTP mail relay.
The SMTP mailserver IP address is entered on the last page of the Quick Config Wizard, or on the Email tab of the Config Tool. Use the “Test” button on these pages to validate that the emails are accepted by the mailserver. If any errors occur, they will be displayed in the dialog box.
Possible reasons email is not working:
- SMTP mailserver is not accepting email from PathSolutions Network Monitor
- SMTP mailserver IP address is incorrect
- SMTP mailserver is not configured to relay emails
- Anti-SPAM filter is preventing emails from being received
- Anti-Virus software on PathSolutions Network Monitor server is preventing emails from being sent
When PathSolutions Network Monitor initially connects to the SMTP mailserver, it introduces itself as “pathsolutions.com”. Some Anti-SPAM servers may not like this, as the server has a different DNS MX record than “pathsolutions.com” on the Internet. This entry can be changed to match the user’s company by modifying the following registry entry:
The PathSolutions Network Monitor service must be stopped and restarted for this change to take effect.
- 1007: User receives Poll Failure email notification
PathSolutions Network Monitor will attempt to query network information from all configured network devices within the time allotted for the poll frequency. If the network is particularly large, or the Poll Frequency is configured to be small, there may not be enough time to query all of the network devices before the next poll should start.
In general, the default Poll Frequency setting of 5 minutes is sufficient for most all networks.
If this message is received infrequently (less than once a week), it can be safely ignored.
If this message is received on a more frequent basis, it should be interrogated to determine the cause.
Evaluation:All timing information in the notification is provided in Milliseconds (ms).
The notification will contain timing information on:
- Current polling period
- How long the SNMP query took
- How long it took to save all of the statistics to disk
- How long it took to analyze the statistics
- How long it took to write output information to the disk
The average information is also available to help evaluate which variables are out of norm. If the provided numbers are within 10% of the average, then the Polling period should be increased, or the number of monitored interfaces should be reduced.
Another option is to implement a second monitoring server in a remote site to monitor any high latency devices.
SNMP Query took too long:If this occurs, check the table below to determine which specific device is out of normal compared to the average. If there are a number of retries with a device, then the communications links between the PathSolutions Network Monitor server and the device should be investigated for over-utilization and/or errors.
Save Statistics took too long:This may mean that the disk subsystem of the PathSolutions Network Monitor server may be too slow, or overloaded. If other applications are running on this server, investigate how they use the hard disk to see if there may be contention.
Analyze statistics took too long:This section is 100% dependent on the CPU of the server. If this is out of normal, other processes on the PathSolutions Network Monitor server may be starving the PathSolutions Network Monitor process for CPU attention.
Writing Output to disk took too long:This is also disk subsystem dependent. Check to see if other processes are doing a lot of writing to the hard disk system at the same time as PathSolutions Network Monitor
- 1009: How to detect connection loss
There are three types of alerting that can be employed to detect connection loss in PathSolutions Network Monitor.
- If the device is being monitored, PathSolutions Network Monitor can be configured to generate an email alert if the device is unreachable. This is done via the config tool on the “Alerts” tab. Click “Add” and enter the email address where the alert should be sent along with the IP address of the monitored device. Select “Comm Fail” as the Interface. Any communications failure with the device will generate an alert email.
- If the interface is being monitored, PathSolutions Network Monitor can be configured to generate an email alert if the interface changes status from UP to DOWN, or from DOWN to UP. This is done via the config tool on the “Alerts” tab. Click “Add” and enter the email address where the alert should be sent along with the IP address of the monitored device. Select the interface number, and then check the “Status change” box. Any status change of this interface will generate an alert email.
- If the device is forwarding syslog messages to the PathSolutions Network Monitor server, alerts can be generated from the syslog message. This is done via the config tool on the “Syslog” tab. Click “Add” and enter the email address where the alert should be sent along with the IP address of the device. The search string should include the specific message that the device would generate for triggering this alert to be sent out.
Additionally, historical loss of communication information is available at the bottom of the device information page. The system will add notes as to when the device was unreachable, and when the device was reachable again.
For interfaces, the historical tracking of interface availability is at the bottom of the interface details page.
Historical syslog messages can be viewed in the “Syslog” listing
- 1011: How to determine NIC speeds are set correctly
The interface speed of a link can be determined on the interface details web page for the interface.
The speed and duplex setting is available for viewing in the Interface Summary section. The interface speed displays the speed that the device reports for the interface in the SNMP ifSpeed OID, or ifHighSpeed if the ifSpeed is invalid.
Interface duplex is queried from the device via dot3StatsDuplexStatus (RFC 2665). If this OID is not available, it will estimate the duplex setting based on the presence or absence of collisions on the interface
- 1012: How to determine if load balancing is employed on links
The current utilization of both load balanced links should be viewed in separate browser windows.
This permits load balancing to be tested to make sure that both links are equally handling the network load provided. If both links are opened at the same time, the high-water mark can be rest for both windows to zero.
- 1014: How to search for general loss of network connections
Network connections can drop as a result of packet loss that is too high or utilization that is too high. PathSolutions Network Monitor is able to monitor utilization rates and packet loss rates for every interface on the network.
- The “Issues” tab can be used to locate interfaces that have high utilization or high packet loss rates (defined according to the threshold levels previously set).
- The “Top-10” tab shows interfaces that have the highest error rates, utilization rates, and broadcast rates.
It is suggested to use the “Issues” tab and/or “Top-10” tab to locate interfaces that could cause a loss of connection and then drill down into the interface to discover the specific conditions that exist on the interface.
- 1021: How to perform automatic scans for new devices
The PathSolutions Network Monitor Quick Config wizard can be set to automatically scan for new devices on a regular basis. This is performed via Windows Scheduled Tasks, and running the Quick Config wizard in automated mode.
To run the Quick Config Wizard in automated mode, the program should be run from the command line with the “/a” operand:
MonitorWizard /aThis can be set to run on a regular basis via the Windows Task Scheduler. Additional details can be found in TechNote #1021.
- 1022: Device uptime may not show correctly
If a monitored device is up for more than 1.3 years, the UpTime displayed may be incorrect.
If a network device (switch, router, server) has been online for more than 1.3 years, the SNMP counter sysUpTime may roll over. The SNMP sysUpTime counter is a 32bit counter that tracks hundredths of seconds that the system has been online. This counter will wrap around after 1 year, 18 weeks, 6 days, 2 hours, 27 minutes, 52.95 seconds.
When the SNMP standards committee created the specification for the sysUpTime counter, it was expected that network equipment would be rebooted sometime within a year timespan (either for OS upgrades or general equipment preventive maintenance cycles).
PathSolutions VoIP Performance Manager
- 1010: How to determine proper prioritization of packets
The queuing strategy employed on a link can be determined on the interface details web page for the interface.
Below the interface utilization information is the Queuing mechanism. This will be displayed as one of the following mechanisms:
- FIFO First In, First Out
- WFQ Weighted Fair Queuing
- PQ Priority Queuing
- CQ Custom Queuing
- MQC Modular Qos CLI
- 1013: How to determine if NAT is employed
NAT can be checked via the Check Address Translation button on the “Tools” tab, “VoIP Tools” sub-tab.
Since it is valuable to have a network administrator have a remote user run this tool, an email link has been provided to make it easy to send an email to a user with this link.
When the user clicks the link, the system will check the user’s local IP address against the IP address that the server sees to determine if NAT is being employed anywhere between the user’s local PC and the PathSolutions Network Monitor server.
An email link is provided on the resulting page so the remote user can easily return these results back to the network administrator.
If NAT is suspected, this test should be performed for both ends of the call.
Note:It is assumed that the user’s desktop computer is on the same subnet (and therefore would have the same NAT) as the user’s VoIP phone.
- 1043: Interfaces not displaying any health or performance data
If the configuration is set to have the program monitor more than the licensed number of interfaces, the program will still permit additional devices to be configured to be monitored, but the interfaces on those devices will not show any collected information.
For example, if a license will permit monitoring 1,000 interfaces, then only the first 1,000 interfaces will be monitored. Additional interfaces beyond that 1,000 will not collect any health or performance statistics, but the device will still be listed.
To remedy this problem, reduce the number of monitored interfaces by ignoring interfaces that don’t need to be monitored, remove devices from being monitored, or purchase more licenses.