Filter
Top Products
112 COMMANDCENTER NOC ADMINISTRATOR GUIDE
Why Can’t My CC-NOC Manage X Service?
ICMP - If a device responds to a "ping", which uses ICMP for its transport, the device will be
flagged as supporting ICMP and will be tested for ICMP availability on the standard polling
interval.
Microsoft Exchange - If a device is determined to support Microsoft Exchange, it means that we
have discovered email-related services (IMAP, POP3, or SMTP) on one of its interfaces, and the
banner received from that service identified the server as Microsoft Exchange. The MSExchange
service indicates that the CC-NOC was able to recognize that the server is Microsoft Exchange,
but due to potential configurations of the server that could disable banners, we do not guarantee
that all Microsoft Exchange servers will be identified as such.
Router - If a device is identified to support the "Router" service, it must first support either
SNMP or SNMPv2, and it must respond positively to a query of the ip.ipForwarding OID. This
service is not polled on a regular polling interval, but instead, is used to help maintain appropriate
contextual displays in the CC-NOC's user interface.
SNMP/SNMPv2 - The CC-NOC will discover if a device supports SNMP version 2 (SNMPv2).
SNMPv2 support implies that the devices supports the GET-BULK operator, which allows the
CC-NOC to pull performance data from the device using a far more efficient query, reducing
network overhead, and freeing up the CC-NOC to poll the next device in less time. Note: If a
device supports both SNMP (which implies SNMP version 1) and SNMPv2, the CC-NOC will
query the device with SNMPv2 only, as it's more efficient and there is no need to retrieve
redundant data.
Pollers
The pollers decide what to poll by analyzing the interfaces and services in the database and
comparing them to the Managed Ranges - if the interface is in the managed range, it will get
polled, if it's not, it won't.
The complete list of pollers is available under the Admin tab, Network Management, and
Configure Pollers. The Pollers use synthetic transactions to test, where possible. In essence,
synthetic transactions communicate with the polled service, with minimal impact. For example,
some pollers use banner grabbing. Some pollers interact more directly, for example, the HTTP
service poller simulates the user viewing a URL from a browser. Other pollers use simple port
connectivity to test, for example, telnet. All pollers are standards-compliant.
Some services are TCP based, for example, connection-oriented, and some are UDP based, for
example, connectionless. An example of a TCP-based poller would be telnet – you will connect
through port 21 and if that connection was successful, then you can assume the service is
operating correctly (you will know almost immediately). An example of an UDP-based poller
would be DNS - the poller generates a name query packet, and sends it out UDP to the server and
simply has to wait for a response.
There are benefits and problems associated with not doing authentication as part of polls. Raritan
does not use any authentication-based polling - instead, we exercise protocols. Yes, you can get
more information by actually “logging in” to a service, but the security risks outweigh the
benefits.
If a service "fails" a poll, a "Node Lost Service" event is generated. The text of that event looks
like:
XXX outage identified on interface WWW.XXX.YYY.ZZZ