Rover is the network status monitor.
For each device, Rover monitors one or more specific services. For example, it may test whether a particular Ethernet hub responds to IP PING requests. To monitor a host that provides Web and POP3 services, Rover may be configured to test the host's HTTPD and POP3 ports, in addition to IP PING.
When a device fails a test, Rover adds that device to the problems appearing on the Rover Display; if the device fails several tests (e.g. PING, HTTPD, SMTP), each problem is listed separately.
Each problem remains on the Rover Display until the device resumes responding to that test. As some tests are performed repeatedly (e.g. during one Rover cycle, a device is PINGed several times in quick succession), a device need only respond once during a cycle to pass the test.
Rover's tests are not intended to check the correct operation of the monitored devices. For example, to monitor a host's POP3 service, Rover simply tries to open a TCP connection to the host's POP3 TCP port. Rover's primary mission is to detect reachability problems; if a particular device or service that should be reachable becomes unreachable, something is probably wrong.
As a reachability tester, Rover has no knowledge of network topology, or how various network components or services rely on each other. Therefore, if a router fails, one can expect not only the router to fail Rover's tests, but also all of the monitored devices behind the router to fail the tests. Interpretation of the Rover Display requires a knowledge of the network topology and these dependent services, as well as an understanding of the connectivity of the actual hosts collecting the Rover data. Therefore, the Rover Display is intended to be interpreted primarily by members of OIT's Network Systems, Platform Services, and Hardware Support staff.
InetRover was originally developed by MERIT, the networking organization at the University of Michigan; we have enhanced and customized it significantly to suit Princeton's needs.