1. FAQ

FAQ

Welcome to the OmniCenter FAQ page.

General

  • Should I deploy OmniCenter as a virtual or hardware appliance?

    While this is generally something that Netreo’s engineering team will address with you during the pre-sales process, it does come up often enough that it’s worth discussing the advantages and disadvantages so you can better understand the differences.

    Regardless of which platform you choose, OmniCenter is designed as an appliance, which means it’s designed to integrate the software with the operating system, databases and onboard libraries for maximum performance and stability. It is deployed as an “atomic” unit, meaning that there are no additional databases to manage, license or configure–and no other separate software to install.

    So, when would you want to install one over the other?

    If you don’t already have a VMware ESX/vSphere environment, the problem is solved for you, as it almost never makes sense to deploy VMware just to support OmniCenter. The licensing and hardware costs are prohibitive compared to the costs of simply deploying a dedicated hardware appliance. If you already have a VMware environment in place and you have some excess capacity, then you should consider the following pros and cons.

    Virtual Appliance Advantages:

    • Faster Deployment
      • No hardware to ship, install and deploy. You can download a virtual appliance and start immediately.
    • Flexible Scaling
      • VMware makes it easy to add more resources as/when needed—but, only up to a point. OmniCenter is very I/O intensive, so if your VMware infrastructure lacks I/O bandwidth, OmniCenter can tax it heavily.
    • Easy Migration
      • If you relocate your data center, it’s trivial to migrate your OmniCenter deployment.
    • Redundancy and Disaster Recovery
      • Infrastructure for redundancy already deployed for VMware will seamlessly extend to OmniCenter. It is possible to add these functions to the hardware appliance, but at an extra cost.
    • Price
      • There is no extra cost for a virtual appliance (just the software licensing), so you save the cost of the hardware appliance.

    Virtual Appliance Disadvantages:

    • Resource Intensive
      • If you don’t already have considerable free resources in VMware, adding additional hardware and licenses to support OmniCenter would not be cost effective compared to dedicated hardware. OmniCenter is a powerful, 24×7 application that will take considerable processing and I/O resources to run effectively, and the resources dedicated to OmniCenter will not have much spare horsepower to share with other virtual guests — which can affect their performance, too.
    • Scalability
      • Very large or intensive environments (such as extensive NetFlow or large IP telephony deployments) may not be well served with a virtual appliance deployment.
    • Consolidation
      • Monitoring your infrastructure (such as the VM servers) from within the virtual environment can create single points of failure. Large surges in processing demand from other virtual guests can cause the alerting and monitoring functions of OmniCenter to be adversely affected.

    Please note: Whichever platform you choose, OmniCenter is designed so that you can migrate to new platforms without much trouble, so it’s perfectly acceptable to deploy a virtual appliance and then migrate to hardware afterward; or to deploy a hardware appliance and migrate to a larger hardware appliance—or even to a virtual appliance.

    As always, if you are unsure or have other questions, please feel free to contact Netreo Support.

  • What does OmniCenter monitor?
    Please see our article What Does OmniCenter Monitor?
  • What kinds of devices can OmniCenter monitor?

    See our page on Device Polling Support.

  • How much traffic will OmniCenter add to my network?

    How much traffic OmniCenter will add to your network depends on a lot of factors, primarily because basic SNMP monitoring is going to have a different load profile than a configuration with a large amount of NetFlow traffic or IP telephony call records. Large numbers of detailed service checks can also have an impact, but after reviewing hundreds of customer configurations, we can provide some general guidelines to give you an idea of what to expect.

    SNMP is a very lightweight protocol, so the amount of traffic it contributes is usually a very small amount. A good rule of thumb is that “for every 1,000 devices under management, you can expect an average data rate of approximately 100Kb/sec.” For a remote site with 50 devices being managed, the data rate across that connection would be around 5,000 bits per second. If you aren’t configuring a lot of other management protocols or service checks, this is a fairly accurate estimate you can plan for.

    Windows and Linux/Unix hosts will generate slightly more traffic as we collect a large number of per-process statistics from them. In environments that are server-heavy, the actual amount of traffic could be as much as double that estimate, as much as 200Kb/sec per 1,000 devices.

    Flow technologies (NetFlow, sFlow, IPFIX) can generate considerably more traffic. In general, flow collection is going to increase your traffic on any given link by somewhere between 0.1% and 1% of the actual traffic in use (depending on the number of connections). So, if you have a fully-loaded T1 circuit (1.5Mbps), adding NetFlow across that circuit is going to increase your traffic somewhere around ~1.5kbps. In aggregate from dozens or hundreds of locations, traffic usage can be considerable. IPFIX or NBAR configurations will use even more—perhaps as much as 2% of the traffic in use in a worst-case scenario. This effect tends to level out above 100Mbps as the number of connections doesn’t increase with the volume of traffic in a linear fashion.

    Devices ManagedModules In UsePeak BW InPeak BW Out
    100OmniCenter basic: SNMP, configuration management.15 Kbps1.65 Kbps
    350OmniCenter fully configured with WebART checks.125 Kbps9.4 Kbps
    950OmniCenter with very high NetFlow volume (> 150,000 flows per minute, > 800 sites).2.01 Mbps32 Kbps
    1030OmniCenter w/ NetFlow.97 Kbps33 Kbps
    2850OmniCenter w/ email check, extensive service checks and syslog configured.606 Kbps214 Kbps
    19040OmniCenter monitoring a large network with extensive server and storage management.3.361 Mbps

    4.026 Mbps

  • What special characters are allowed in passwords?

    All passwords allow basic alphanumeric characters, plus the following special characters (by password type).

    SNMP
    ` ~ ! @ # $ % ^ & * ( ) - _ + = { } | [ ] : < > . ,

    SSH
    ` ~ ! @ # $ % ^ & * ( ) - _ + = { } | [ ] : < > . , ; \

    WMI
    ` ~ ! @ # $ % ^ & * ( ) - _ + = { } | [ ] : < > . ? ;

Security

  • What kind of security is built into OmniCenter?

    Netreo uses a security-in-depth, multi-layer approach to hardening and securing OmniCenter appliances.

    The OmniCenter appliance is hardened and secured in many ways.

    • The OS runs a hardened version of the Linux kernel.
    • All console and serial access to the server is password (or public/private key) protected, and user accounts are strictly limited to only those required for functionality.
    • Customer access to the OS shell is never permitted.
    • To secure the operating system from network attack, all unnecessary network services have been removed from the operating system completely, so the only listening (open) TCP or UDP ports on the server are the services in use:
      • HTTP (can be disabled)
      • HTTPS
      • SSH (can be disabled)
      • Logging (syslog, SNMP traps)
      • Flow collection (NetFlow, sFlow, IPFIX)
      • Encrypted MySQL networking (in some high-availability, cluster, and multi-server configurations)
    • Listening services are configured wherever possible to not reveal version numbers or software information to make reconnaissance more difficult.
    • Network access to any other ports from any interface is forbidden.
    • Reverse-path verification is used to insure that inbound packets cannot spoof the IP addresses of the OmniCenter server to bypass IP-level security.
    • TCP SYN-Cookies are used to prevent TCP SYN floods from being used to create Denial-of-Service (DoS) attacks.
    • Evasive HTTP techniques with automatic blacklists are used to further mitigate DoS attacks and prevent brute-force password scanning.

    Network-enabled services are also internally resource-limited to help prevent DoS flooding of available services – for example, sending a flood of HTTP requests to attempt to crash the web server. Remote SSH access is also strictly controlled and limited to specific administrative users, and login is done primarily using public-key cryptography instead of passwords. Only SSH version 2 is supported, and SSH access can be disabled entirely if desired.

    All OmniCenter software development uses a security-focused programming model and is done primarily in development languages that incorporate security checks to prevent common security flaws (such as buffer overflows). Netreo’s software quality assurance (QA) process insures that all code is tested for security flaws and undergoes periodic code auditing to limit potential security issues. Patches (available monthly or as required) can be scheduled to be applied automatically or on demand. Patching is designed to not disrupt the production use of the system.

    OmniCenter uses a secure VPN system for software updates. All VPN communications are sent outbound. Depending on version and configuration, this usually uses UDP port 1194, but may optionally use TCP port 443 or TCP port 5000 instead.

    VPN communications are initiated from the OmniCenter server to Netreo’s VPN concentrator, and are authenticated and encrypted with 128 or 256-bit AES encryption using 1024- or 2048-bit HMAC authentication. This insures the highest possible level of data security. VPN tunnels can be administratively activated or deactivated by the customer to further restrict access.

    The VPN tunnels terminate in an isolated secured network with strictly regulated access. Each end of the tunnel uses separate packet-level filters, application-level firewalls and packet analysis, and stateful inspection to limit the type, origin, and destination of the traffic, and access is controlled through multiple separate password and public/private key authentications. OmniCenter is configured to never forward traffic between interfaces, to prevent any leaking of data between networks.

    OmniCenter web users can be authenticated locally, or using SAML or LDAP. When using LDAP/Active Directory or SAML, user passwords are never stored or cached on the server. When locally authenticated, user passwords are encrypted using one-way hash functions with a minimum complexity of 256 bits and randomly generated salts. Web users can be forced to change their password at an administrator-defined interval.

    All of Netreo’s technical personnel undergo extensive background checks prior to employment and are trained to maintain high standards of security awareness.

    Independent auditing of the OmniCenter appliance was conducted by Spirent, including penetration testing using a known administrative password, and the system was found to be extremely resistant to intrusion. Periodic vulnerability scans are conducted against new versions of the software, and any vulnerabilities found are remediated before release.

    Because of inherent limitations in application dependencies, error, fraud, or dependencies to supporting systems such as networks and operating systems no controls can provide one hundred percent assurance of system security. However, we believe that the comprehensive security assessment and development processes used by Netreo Inc provide reasonable assurances to our customers. Customers are welcome to perform any security assessments or evaluations they desire on the OmniCenter product as deployed, provided such assessments are limited to the normal methods used to access and operate the software (i.e., Netreo provides no assurance against penetration techniques involving destructive methods, hardware stress, or bypass techniques not commonly employed against in-place software over the network).

    None of the assertions or statements in this document are intended to modify, supplement, or supersede the warranty statements provided in the Netreo Software License Agreement, or any of the open-source license agreements applicable to the Netreo OmniCenter product as sold or deployed.

  • Why does the login page for my OmniCenter say that the connection is not secure?

    Beginning with Firefox version 52, the login page will display this warning unless you are using HTTPS to access OmniCenter.

    You can use HTTPS to avoid this problem. However, by default OmniCenter ships with a self-signed certificate which will then cause a “Your connection is not secure” error when you attempt to access it. Netreo support can install a valid certificate for your OmniCenter server if you choose to purchase one to prevent this from happening.

  • OmniCenter comes with a self-signed certificate. How do I get an officially-signed certificate to use with OmniCenter?

    OmniCenter ships with a built-in self-signed certificate for use with SSL/TLS in order to make secure communications with OmniCenter simple.

    The SHA-256 fingerprint for the built-in certificate is:

    A2:04:8E:FD:5B:8C:9F:46:04:12:5C:E0:A8:AD:D0:B3:CB:0D:B1:64:A0:6D:17:CF:02:CF:6A:C6:92:72:03:D2

    If you wish to use a fully-signed certificate with OmniCenter, you can do so by following the the article How to Install Your Own SSL Certificate, or by contacting Netreo Support using the steps below.

    NoteSince certificates are based on DNS names, you will need to provide our support engineer with the Fully-Qualified Domain Name (FQDN) that you use to access OmniCenter in your environment.

    The steps are as follows:

    1. Determine the FQDN you are using to access OmniCenter in your environment.
    2. Send that information to your Netreo support engineer with your request for a certificate, by opening a trouble ticket.
    3. Your support engineer will send you a Certificate Signing Request (CSR).
    4. Contact any certificate authority and send them your CSR. They will validate your account (usually by email) and then send you a Certificate file (CRT). They may also include a CA Certificate Chain or “bundle” certificate. Note: Most Certificate Authorities charge for this service.
    5. Send both the CRT and any included bundle or chain files to your support engineer, who will then install them on your OmniCenter appliance.

External Threats

  • Is OmniCenter vulnerable to the Heartbleed bug in OpenSSL?

    Short Answer

    The version of OpenSSL that OmniCenter uses IS NOT, and HAS NEVER BEEN, vulnerable to this exploit.

    In April 2014, OpenSSL announced the existence of the CVE-2014-0160 bug (also known as Heartbleed) which is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

    OmniCenter uses the Apache web server, which uses OpenSSL for encryption. However, the version of OpenSSL that OmniCenter uses is not, and never has been, vulnerable to this exploit.

    In practice, the risk of this type of exploit for OmniCenter customers is very low anyway, as OmniCenter is typically deployed behind the customer firewall and is not publicly accessible to outside attackers. OmniCenter also includes intrusion prevention technology to dynamically respond to attempts to gain unauthorized access. Please see the OmniCenter Security page for more information.

    If you have any concerns, please feel free to contact Netreo Support.

  • Is OmniCenter vulnerable to the ShellShock BASH exploit?

    Short Answer

    OmniCenter is NOT vulnerable to this exploit.

    In September 2014, the vulnerability CVE-2014-6271 (also known as Shellshock) was discovered in the BASH operating system shell used in most or all versions of Linux (as well as Mac OS X). Netreo evaluated this vulnerability and determined that our products are NOT vulnerable to this exploit. Although the affected version of BASH was present in the version of Linux used by OmniCenter, Netreo uses advanced forms of access security to protect the system from intrusion, and does not use CGI, making it effectively impossible to exploit this vulnerability.

    Netreo has also released a patch for OmniCenter systems to remove any possibility of this exploit being exposed in the future.

    In practice, the risk of this type of exploit for OmniCenter customers is very low anyway, as OmniCenter is typically deployed behind the customer firewall and is not publicly accessible to outside attackers. OmniCenter also includes intrusion prevention technology to dynamically respond to attempts to gain unauthorized access. Please see the OmniCenter Security page for more information.

    If you have any concerns, please feel free to contact Netreo Support.

  • Is OmniCenter vulnerable to the Ghost exploit?

    Short Answer

    Based on our testing and research, we believe that OmniCenter is NOT vulnerable to this exploit at this time.

    In January 2015, Qualys announced the existence of security vulnerability CVE-2015-0235 (also known as Ghost) in one of the underlying libraries that is used in almost all Linux-based operating systems.

    This is a serious vulnerability in one of the most central software libraries in Linux and Unix (glibc), and affects almost all executable programs that use DNS or name lookups. A remote attacker able to call either of the compromised functions could exploit the flaw to execute arbitrary code with the permissions of the user running the application.

    In a later post, Qualys researchers enumerated applications they believed were not vulnerable. Those apps include Apache, OpenSSH, and Postfix, which are the only applications used by OmniCenter that are accessible over the network.

    Based on our most current testing and research, as well as our “defense-in-depth” security implementation on the OmniCenter appliance, we believe that a standard deployment of OmniCenter is not vulnerable to this exploit at this time. However, it is possible as new information is discovered that novel ways to exploit the vulnerability may be found. For this reason, Netreo is preparing at the time of this writing (January 28, 2015) a software patch to replace the vulnerable libraries in all of the applications present on the OmniCenter software image. A notice will be emailed out to all customers on the Netreo Software Announcements mailing list as soon as a patch is available to install.

    In practice, the risk of this type of exploit for OmniCenter customers is very low anyway, as OmniCenter is typically deployed behind the customer firewall and is not publicly accessible to outside attackers. OmniCenter also includes intrusion prevention technology to dynamically respond to attempts to gain unauthorized access. Please see the OmniCenter Security page for more information.

    If you have any concerns, please feel free to contact Netreo Support.

  • Is OmniCenter vulnerable to the Venom exploit?

    Short Answer

    OmniCenter is NOT vulnerable to this exploit.

    In May 2015, security vulnerability CVE-2015-3456 (also known as Venom) was disclosed that affects Xen and KVM virtualized host systems.

    This vulnerability allows an attacker who controls a virtual machine on the host system to compromise other virtual machines by using a flaw in the floppy disk controller software.

    Although some implementations of the OmniCenter appliance use a Xen hypervisor, OmniCenter is not vulnerable to this exploit. OmniCenter appliances shipped in the last 5 years do not implement the floppy drive controller software that caused this problem, and use more current versions of the Xen hypervisor that do not contain this code. Additionally, since no other virtual machines are installed on the Xen hypervisor in an OmniCenter appliance, there is no way an attacker could compromise the host using this exploit. This type of exploit is of much greater concern to companies that provide cloud-hosted virtual servers.

    OmniCenter appliances installed as vSphere virtual appliances are likewise unaffected as the software code in question is not present on VMware-based hypervisors.

    If you have any concerns, please feel free to contact Netreo Support.

  • Is OmniCenter vulnerable to the Intel AMT/ISM exploit?

    Short Answer

    OmniCenter is NOT vulnerable to this exploit.

    In May 2017, security vulnerability CVE-2017-5689 was disclosed that affects Intel-based hardware systems running Intel Active Management Technology (AMT), Intel Standard Manageability (ISM), and Intel Small Business Technology (SBT).

    Exploiting this vulnerability means that an unprivileged local attacker could provision manageability features gaining unprivileged network or local system privileges on affected systems.

    Although some versions of the OmniCenter hardware appliance use Intel processors, OmniCenter is not vulnerable to this exploit. OmniCenter appliances shipped in the last 5 years use processors and firmware that are not affected by this problem.

    OmniCenter appliances installed as Virtual Appliances are not specifically affected as the issue in question only occurs at the hardware level. However, Netreo recommends that customers using Intel-based hardware in their virtualization environment check their hardware platforms to make sure that they are not affected by this vulnerability using the resources provided by Intel here.

    If you have any concerns, please feel free to contact Netreo Support.

  • Is OmniCenter vulnerable to the SambaCry exploit?

    Short Answer

    OmniCenter does not expose any writable file shares, and therefore IS NOT, and HAS NEVER BEEN, vulnerable to this exploit.

    In May 2017, Samba.org announced the existence of CVE-2017-7494) (also known as the SambaCry bug), which is a serious vulnerability in the Samba open-source file sharing SMB library. This weakness allows a malicious client to upload a shared library to a writable share, and then cause the server to load and execute it.

    OmniCenter uses the Samba libraries for SMB file sharing. However, OmniCenter does not expose any writable file shares, and therefore is not, and has never been, vulnerable to this exploit.

    As a precaution, Netreo has implemented several workarounds and patches in OmniCenter 9.1 and 10 to insure this vulnerability could never be exploited in the future.

    If you have any concerns, please feel free to contact Netreo Support.

  • Is OmniCenter affected by the Intel Meltdown/Spectre kernel memory vulnerabilities?

    Short Answer

    OmniCenter is NOT vulnerable to this exploit.

    Updated: 8 January 2018

    In January 2018, a vulnerability was discovered in all versions of the Intel X86-64 processor architecture that can cause arbitrary memory leakage, possibly including code execution or the dissemination of critical protected information (such as passwords) contained in memory. These are referred to as the Meltdown and Spectre vulnerabilities, formally known as CVE-2017-5753, CVE-2017-5754 and CVE-2017-5715.

    Netreo has evaluated this vulnerability and determined that our products are NOT vulnerable to these exploits, and that they pose no increased risk to OmniCenter appliances. Although Netreo hardware appliances use Intel processors which are affected by this issue, OmniCenter does not permit users to upload or execute code on the system and provides no command line (CLI) shell access to users, making it effectively impossible to exploit this vulnerability.

    Exploiting these vulnerabilities would require an attacker to have already established local arbitrary code execution; in other words, the system would need to already be successfully exploited. An attacker that has gained the ability to execute arbitrary code on an OmniCenter appliance will not gain any significant additional capability through exploitation of Meltdown or Spectre attacks on the device.

    In practice, the risk of this type of exploit for OmniCenter customers is very low anyway, as OmniCenter is typically deployed behind the customer firewall and is not publicly accessible to outside attackers. OmniCenter also includes intrusion prevention technology to dynamically respond to attempts to gain unauthorized access. Please see the OmniCenter Security page for more information.

    If you have any concerns, please feel free to contact Netreo Support.

  • Is OmniCenter affected by the DHCP Command injection vulnerability?

    Short Answer

    OmniCenter is NOT vulnerable to this exploit.

    Updated: 17 May 2018

    In May 2018, A command injection flaw was found in the NetworkManager integration script included in the DHCP client packages in CentOS, Fedora, and Red Hat Enterprise Linux. This exploit was cataloged as CVE-2018-1111. Netreo has evaluated this vulnerability and determined that our products are NOT vulnerable to these exploits, and that they pose no increased risk to OmniCenter appliances.

    Although our OmniCenter appliances do use a CentOS-based software image, OmniCenter and the underlying KVM image do not use DHCP and do not use the NetworkManager framework. OmniCenter is therefore unaffected by this vulnerability.

    OmniCenter also includes intrusion prevention technology to dynamically respond to attempts to gain unauthorized access. Please see the OmniCenter Security page for more information.

    If you have any concerns, please feel free to contact Netreo Support.

  • Is OmniCenter affected by any of the known SSH vulnerabilities?

    Short AnswerOmniCenter is NOT vulnerable to any of these exploits.

    OmniCenter uses the OpenSSH networking utilities suite. In practice, the following vulnerabilities are not exploitable in OmniCenter. Additionally, users can disable SSH shell access entirely using the OmniCenter system preferences if they would like to eliminate these results from their vulnerability scans entirely.

    CVE-2016-10009
    CVE-2016-10010
    These are not exploitable as they have to do with port forwarding, which is disabled in OmniCenter’s SSH implementation.

    CVE-2016-10011
    CVE-2016-10012
    These are local user privilege escalation issues that are not exploitable as they require local shell access, which OmniCenter does not provide to any user.

    CVE-2016-8858
    This is a disputed CVE. OpenSSH does not consider it a vulnerability and therefore it is not fixed. The worst case scenario in any case is a local DOS of the SSH process which is resource limited.

Graphs and Reports

  • Why does the MAX value in the legend not show up in the graph?

    A common question our customers ask is something similar to “Why does the text on the bottom of the graph have a ‘Max Blocks written’ value of 81.023K, yet the Y-axis of the graph only goes to 40K”?

    The shortest (and easiest) explanation is that the graphs have a limited amount of real estate to use on the display (depending on your screen width). The longer explanation is that in a 30-day graph like the one above, we only have 660 pixels or so to display 8,640 horizontal data points. So, even though the actual values are in the system; in order to draw the graph in the space available, we have to display an average of the data points. Thus, the line you see in the graph is the average, and not the max, of the data.

    Averaging data in this manner will inevitably blunt some of the peaks. You can, however, force the peaks to be visible on the graph in one of two ways: either click-and-drag to zoom into the histogram (thus looking at a smaller time frame), or select the option in the query box labeled “Peaks” and then click GO to redraw the graph.

    So, the same graph with “Peaks” enabled looks like this:

    You can see that the peak data can cause the graphs to become a little cluttered, which is why this option is disabled by default.

  • How does OmniCenter calculate average and peak values?
  • How does OmniCenter handle storage of historical data?

    See our page on Data Retention.

  • How do I use OmniCenter for capacity planning?
  • Why does an Interface Error graph have different numbers than the device’s CLI?
  • What does it mean when OmniCenter shows that a device poll time is “slow?”

    OmniCenter uses an adaptive polling system to manage devices that may be responding slowly, so that they do not interfere with data collection on devices that are responding normally. This feature was introduced in version 7.2 of OmniCenter.

    When the polling process detects that a device is taking more than 100 seconds to complete a full data poll (the “critically slow” threshold), it flags the device as a “slow” device. Polling for that device is then handed over to the slow-device poller process. On the device dashboard, the poll time will display “Slow” when this happens. The polling speed flag for the device is also set to 5.

    The device will continue to be polled by the slow poller process until OmniCenter detects that the device is responding in under 30 seconds (the “recovery” threshold). When the device responds faster than the recovery threshold, the polling speed flag for the device is reduced by one. If the device completes a poll above the recovery timer, but below the critical timer, OmniCenter will increase the polling speed flag by 1. When the polling speed flag is less than 5 (critically slow) but greater than 1 (normal), the device dashboard will display “Slow, Recovering.” The slow polling process will continue to manage the device until it has fully recovered.

    If the device completes any poll above the critical threshold, the polling speed flag is set back to 5.

    When the polling speed flag returns to 1, the regular polling process will resume polling of the device, and the device dashboard will display “Normal” for poll speed.

    Therefore a device must complete 4 successful polls in a row faster than the recovery threshold to return to normal operation. This minimizes the net shift between slow and normal devices.

Monitoring

  • Can a URL be monitored without specifying a device?

    Yes. A URL can be monitored without specifying a device using a Web Application Response Time (WebART) check.

  • What is the best way to monitor a redundant firewall cluster?

    See our page on Virtual IP Monitoring.

  • How do I monitor a cluster of Windows Servers?

    This is confusing, because it is not a very straightforward situation. First lets get a high-level overview of how the clusters work.

    Usually there are two or more physical servers. Each running the cluster service and logically, if not physically, grouped together. Each server has its own network identity and running services.

    Then through the cluster manager, one or more virtual IP addresses are assigned, as well as “cluster aware services.” These services can be database instances, web servers, shared SAN storage or a host of other things. The idea being that these are the critical resources that need to survive in the event that any member of the cluster experiences a hardware failure. If the server that currently hosts the cluster service fails, the service is supposed to seamlessly transition to a different available cluster member. This presents a unique challenge when monitoring the servers.

    If you monitor just the physical servers, then the cluster instances like drives, open ports and cluster interfaces only appear on the server hosting them. But if there is a failover event, intentional or not, then you are no longer able to poll these instances, since they will no longer exist on that server. This causes problems with historical continuity of statistics, threshold check settings and a number of other things. Additionally, you would need to repoll all cluster members right after the failover event to make sure that the server that the resources have moved to now sees those instances and are polling them—not to mention setting alerting and threshold check parameters on them.

    If you choose to monitor only the virtual IP address, you will lose visibility into server-level faults and threshold checks, since you will effectively only be monitoring the server that has control of the virtual interface. This will render CPU, interface, memory, and (local) drive utilization stats useless, since one day the stat will reflect those values on one cluster member and another day (if there was a failover event) they could be the values of a different cluster member.

    What we recommend is a hybrid of both. Monitor both the physical servers as well as the virtual cluster interfaces. Set fault and threshold check alerting on the physical servers to instances that are local to the physical server (CPU, memory, BW, errors, and drives and services that are local to the server itself and not cluster aware).

    Then disable any cluster threshold checks that are automatically created. On the virtual server, do the opposite and configure your status checks, alert contacts and threshold check alerting for only those services and drives (like the Quorum drive and SAN drives) that are associated with the cluster and will transition to different cluster members in the event of a failover.

    This is easiest to do by creating two device templates—one for physical cluster members, and one for virtual cluster addresses—and applying them appropriately.

    You can then include cluster members in a strategic group in order to get visualization of the cluster environment, as seen in this example:

    Optionally, you can upload a cluster functional diagram and have it reflect OmniCenter availability data using our Custom Maps functionality, like this:

  • Why is there a notification delay after an alarm recovers?

    The alarms cleared icon shown in the incident view.

    OmniCenter 9 changed the behavior of some alarm notifications when it introduced the new incident management system. Now, when an alarm is no longer critical, rather than immediately returning to an OK state (and sending the related notifications), it enters what’s called an “Alarms Cleared” state. This state is a window of time that acts as a buffer to allow the alarm time to stabilize before returning it to an OK state. This prevents redundant and false alarm notifications for alarms that are experiencing a flapping condition. If the alarm fails to stabilize, it will then be returned to whatever state the opened incident was last in (typically, open or acknowledged) without any further action. The default delay time for the Alarms Cleared window is 5 minutes, but in OmniCenter 9.1 the delay can be customized by an administrator.

    Note: If you lower the delay timer and you have flapping devices, this change could increase the volume of notifications that you receive (directly proportional to the number of flapping devices).

    To change the delay timer: From the main menu, select Administration → Alerts → Incident Management. Set the Incident Close Delay Timer field to the desired number of minutes and click Update.

  • Does OmniCenter's Looking Glass feature support non-Cisco network devices?

    Yes. Any manufacturer with a working SSH or telnet interface is already supported, although there are no prebuilt commands for them. The Looking Glass Administration page (Administration → Tools → Looking Glass) allows you to add custom commands for any vendor. If the device type doesn’t appear in the list, simply go to the Polling Administration page (Administration → Change Devices → Edit Pollers), click the edit icon for the device type and make sure “Looking Glass” is set to ON.

  • OmniCenter says my Cisco device configuration is not saved, but it is. What’s happening?
    In certain cases, Cisco configurations may show as “Changed but not saved!” even though they have been saved, or not changed in a long time.

    This is caused by a quirk in the way Cisco counts time. OmniCenter uses SNMP to check configuration “save status” on Cisco devices. Cisco limits the response on these counters to 32 bits, and they read in “uptime in hundredths of seconds.”

    This means the counters “roll over” to zero after approximately 497 days.

    In rare cases, this can generate false alarms. If the router has been running a long time (high uptime) and the configuration hasn’t been changed, but the router has had a “write memory” or “write startup-config” performed more recently, the “Last configuration change time” can become a higher number than the “Last configuration save time” (because the counter rolled over to zero between the last change and the save).

    This will cause OmniCenter to think the configuration was changed after the last write.

    A simple workaround is to make a change to the router configuration. Any change will do, and you can undo it immediately afterwards (for example, change or add a description line and then resave the configuration). This resets the counters and clears the error. You could also reboot the router, but this will impact traffic flow through the device.
  • Why does the last reboot time for a device listed in OmniCenter show a different time than the device itself does?
    OmniCenter measures the last reboot time for a system by collecting data from the system.sysUptime MIB in MIB-2. This is an industry standard and a widely supported method.

    The variable collected is defined as “The time (in hundredths of a second) since the network management portion of the system was last re-initialized.” This means that if the SNMP agent on the device restarts, the counter will be reset to zero.

    This counter is only 32 bits, so the largest value it can hold is 497.1 days before it rolls over. Although most devices restart periodically for updates, if your device hasn’t rebooted in a very long time, this counter will eventually roll over to zero and OmniCenter will show a more recent “last reboot time” than actually occurred on the device. This is a limitation of SNMP and is beyond our control.
  • How do I use WMI management through a firewall?

    OmniCenter monitors Windows using the WMI protocol, and sometimes SNMP on very old versions.

    The ports that will need to be opened across the firewall are the same as those required for any WMI access to Windows, namely TCP/135 and all high ports (1024-65535), unless you have modified the Windows server to use a fixed port-range for WMI, in which case you can open TCP/135 and those ports instead. See this MS KB article for details on using WMI across firewalls and how to assign a fixed port range.

    For SNMP, UDP/161 will need to be opened. Windows servers newer than 2003 generally do not need SNMP enabled for full visibility in OmniCenter.

  • When using WMI, do I have to give administrator privileges to the user account?
    Not strictly speaking. It’s highly recommended when monitoring Windows servers to use a service account for the purposes of WMI management. While a Domain Administrator account is the easiest to use, it is possible to use a non-administrator user account by following the steps on our page How to Create Non-Administrator-Based Service Accounts in Windows.
  • When monitoring Windows services I get a "WMI: Generic failure" or "ERROR: Login to remote object" message. What's wrong?

    The error messages “ERROR: Login to remote object” or “ACCESS_DENIED” can occur when attempting to monitor Windows services using WMI or WBEM (in the Windows environment, these terms are used interchangeably). If you have ruled out the possibility that a username or password was not entered properly, there are two common causes for this error.

    The most frequent cause is a result of too many requests accessing the WMI/WBEM service simultaneously. We have frequently seen this problem occur in conjunction with the McAfee NITRO agent during updates, but it can also be caused by high system load or other management applications accessing the server simultaneously. If the problem resolves itself after a short time, this is the likely cause.

    If the problem persists, or you also receive “WMI: Generic error” messages, this can indicate that the WMI repository or other system files are corrupted.

    Experienced administrators can see our page on Fixing WMI Corruption for some advice on potential repairs.

Configuration and Setup

  • Why does OmniCenter sometimes show over 100% utilization on some interfaces?

    OmniCenter detects bandwidth using SNMP. Specifically, we read the ifSpeed and/or the ifHighSpeed MIB.

    ifHighSpeed is only supported on devices set to SNMPv2 polling, and reports only in megabits (not fractions), so in order to avoid rounding off the bandwidth on low-speed ports, all interfaces with a reported speed below 1Gbps (1,000,000,000 bits/second) use the ifSpeed MIB exclusively.

    Note

    The bandwidth we detect on Cisco devices is determined from what you set with the Bandwidth command on that interface. If it is not set, or set incorrectly, the numbers, percentages, and thresholds in OmniCenter may be incorrect.

    If we detect that it’s a serial interface, we do allow a certain amount of bursting over 100%. However, this doesn’t change the “maximum” used to calculate percentages – that is always strictly based on the bandwidth setting.

    If the interface is more than 56Kbps, but less than 1.5Mbps, we assume it could burst as high as 1.5Mbps.

    If the interface is over 1.5Mbps, but less than 45Mbps, we assume it might be a fractional T3 and allow bursts up to 45Mbps.

    If the interface is more than 45Mbps but less than 155Mbps, we assume it might be a fractional OC3 and allow bursts up to 155Mbps.

  • What is the blackhole action group used for?

    OmniCenter uses the concept of a “black hole” for routing messages that aren’t supposed to go anywhere, something known as an “email black hole” (thus the name).

    It can be thought of as a placeholder for “none,” since in early releases of OmniCenter it wasn’t possible to configure some types of checks without specifying at least one group.

    It is now maintained mostly for compatibility with older configurations, and can be safely ignored.

  • Why am I getting a zlib1.dll error when trying to deploy a virtual instance of OmniCenter?

    Sometimes attempts to deploy the OmniCenter OVA file using vSphere result in the following error:

    This error message is the result of a known bug in the VMware vSphere 5 client application. More information about the bug can be found in this link: https://communities.vmware.com/message/1992930

    To work around this issue follow, these steps:

    1. Go to: http://sourceforge.net/projects/libpng/files/zlib/1.2.3/zlib123-dll.zip/download
    2. Extract only “zlib1.dll” and copy it to:
      1. C:\Windows\System32\ (for 32-bit windows 7) or
      2. C:\Windows\SysWOW64\ (for 64-bit windows 7)
    3. Deploy the OVA file again.

Web Browsers and UI

  • Which web browsers are compatible with OmniCenter?

    The user interface in OmniCenter is designed for most modern web browsers, but utilizes some newer features of those browsers to deliver a richer user experience. As a result, some customers using older-version browsers may experience some issues when using OmniCenter.

    OmniCenter is designed to work seamlessly in all up-to-date browsers. Newer versions of Firefox, Internet Explorer, Safari, and Chrome should work perfectly.

    Internet Explorer versions prior to IE10 are known to not function properly with OmniCenter due to limited compatibility with HTML5 and CSS3 elements. This is a limitation of these browsers and cannot be fixed. We recommend moving to the current version of Internet Explorer or using an alternative browser such as Firefox or Chrome.

  • Why are email alerts formatted strangely in Outlook 2010?

    There is a setting in Outlook 2010 the removes extra carriage returns from email messages. This can cause alert and recovery emails to be munged together and illegible. To find more information on this issue take a look at the following Microsoft knowledge base article: Line breaks are removed in posts made in plain text format in Outlook.