| 1. How much does RouterDog service cost? | |||
| Please see our Pricing page. | |||
| 2. What paging services are compatible? | |||
| RouterDog works with virtually every numeric and alphanumeric paging service in North America, as well as most alphanumeric paging services in Europe, Asia-Pacific, and Latin America. | |||
| 3. Can I turn on monitoring and/or notification at will? | |||
| Yes, 24 hours a day via a Web interface, you can deactivate or reactivate monitoring of any device. You can also deactivate or reactivate notification of specific types of errors, for each of your email addresses and pagers individually or collectively, at any time. | |||
| 4. Is RouterDog ready for Y2K? | |||
| Yes. All software running on RouterDog is Y2K compliant. | |||
| 5. How soon am I paged after a failure? | |||
| RouterDog checks your devices every 15 minutes. You can specify how many "missed" cycles are allowed to pass before you are notified. It is often advisable to wait for two cycles before being notified, to help reduce "false alarms" due to network or system utilization. | |||
| 6. What does it mean when I get notified that my system is down? | |||
| Whether it is a router, server, or other device, a "down" notification means that RouterDog is unable to reach your system via the Internet. This may happen for several reasons - the device has crashed, your Internet connection went down, your ISP is having network problems, etc. Being notified that your device/service is unavailable to your customers - as seen from the Internet - allows you to begin troubleshooting before your customers call you. | |||
| 7. What types of statistics are available? | |||
| Line utilization, TCP/IP Service utilization, buffer depth, dropped packets, traceroute, system up time, just to name a few… | |||
| 8. How can RouterDog help me save money? | |||
| RouterDog gives you access to a visual representation of your network traffic on a per-device basis. By knowing how much bandwidth is being used on your Internet circuit, for instance, you can know if you have too little or too much bandwidth for your needs. Are you getting your full CIR on your Frame Relay connection during peak usage periods? Do you need to upgrade your fractional T1? Are you being billed accurately for your usage-based circuit? When does a circuit upgrade order need to be placed to allow for telco lead times? RouterDog can help you answer all these questions and more! | |||
| 9. What exactly is being tested for me? | |||
| RouterDog tests: How the server that's hosting your Web site is performing. How your site's Internet connection is performing, including bandwidth utilization and packet loss. | |||
| 10. How will RouterDog tell me that my server has crashed? | |||
| If RouterDog receives no response from your Web server or Router you will be
notified immediately by e-mail (and SMS message if you have requested this
service - additional charges apply). The fault will also be logged in your monthly text and graphical
reports.
RouterDog also provides daily, weekly and monthly graphs of performance and E-mail. | |||
| 11. How do I log in to view the results? | |||
| Just go to Your RouterDog Report page and view them in an Internet Browser given in each report. | |||
| 12. I've forgotten my password/member name? | |||
| If you have lost your password or member name then email Support. | |||
Technical General | |||
| 1. How do you check if my devices are "up"? Go to your personal status page. | |||
| We use ICMP echo/response packets - "pings" - to test if your system is running. To check if HTTP, SMTP, or any other "service" is running, we use application or protocol specific methods to checking responsiveness (HTTP GET, SMTP HELO, FTP, SSL, datbase query, etc.). | |||
| 2. I can monitor my own servers locally. Why do I need RouterDog service? | |||
| The RouterDog service does more than monitor the up/down status of a device. Individual services (SMTP, DNS, HTTP, etc) are checked with their respective protocols to ensure the service itself is responding properly. Most importantly, RouterDog tells you if your services are really available to your customers because we check their responsiveness via your Internet connection. You will always know with certainty that mail is deliverable, that your DNS server is resolving or that your web site is returning requests. | |||
| 3. What is a "Read-Only SNMP community string"? | |||
| A community string is like a password that can be used to read or write information on a remote system. A "read-only" community string only allows information to be read - not written. Read-Only strings are the only type of community strings that should ever be given out - and then only to trusted third parties. | |||
| 4. Can I specify CGI arguments in a URL to be monitored? | |||
| Yes. Your URL can include GET method CGI arguments (i.e. ones which follow a "?" in the URL. | |||
| 5. How can RouterDog monitor devices on my network through my firewall? Is this a security risk? | |||
| Some firewalls have the ability to securely pass the types of data RouterDog uses to monitor your systems (SNMP, ICMP, etc). But even for those that don't, security risks are minimal. Monitoring is done from a secure network. By knowing the IP addresses of RouterDog's monitoring servers, it is possible to configure your firewalls and routers to allow RouterDog to monitor your Intranet servers without leaving them exposed to the security risks of the general Internet. In addition, RouterDog's RouterDog service only requires Read-Only SNMP community strings - which ensure that your devices' configurations cannot be altered by RouterDog. | |||
| 6. How do I read the Graphical View graphs | |||
| In the graphical view you'll see two types of graphs. Online sample Report illustrates the type of graph you'll see for a monitor that can have variable readings. The URL monitor, which reports whether a particular page could be retrieved, is an example of this type of monitor. Historical information for monitors that return only an OK or fail reading is presented in a graph like the one in Online sample Report .
Each bar in the graph represents a single reading for that monitor. The graph will show approximately the last 20 readings. The color of the bar represents the status that the reading indicates. A red bar indicates an error status, green indicates OK, and yellow indicates warning.
In addition to the bar portion of the graph, you'll find information pertaining to the entire reporting period. *Peak This is the highest reading returned during the report period. *Average This is the average of all of the readings returned during the report period. *Low This is the lowest reading returned during the report period. Time In Error This is the total time that the monitor was in error during the report period. Error % This is the percentage of time that the monitor was in error during the report period. *Peak, average, and low information isn't provided for monitors that return only OK or fail readings. | |||
| 7. How do I Interpret Component Failure | |||
| Component failure means something different for network dependent and independent monitors. For network dependent monitors, it's when one of the many pieces necessary to handle requests is down for a period of time. For network independent monitors, it's when the monitored item itself is down. These errors show up as a block of several errors in a row for the duration of the problem. For example, if the web server process crashes, a report for a URL monitor will show a series of red bars until it's started again. | |||
| 8. How do I Interpret Capacity Overload Network devices | |||
| Capacity overload is when an error occurs because some part of your site has reached capacity. For network dependent items these errors appear one at a time on graphs because while most requests are handled correctly, some of them are refused. This type of problem can also show up as increased response times. Often you'll notice the increase occurs at the same time every day. For example, if your T1 line is at capacity every morning, you'll see higher response times and possibly an error or two on your reports. For network independent items, these errors can appear as either spikes or continuous high readings on the graph. These high readings may correspond directly to errors reported by other monitors. | |||
| 9. How do I Interpret Capacity Overload Web sites | |||
| You'll also want to look at your Web server report and compare hits with peak usage to determine if specific CGIs are causing a load problem | |||
| 10. How do I Interpret Slow Response Time (very important to Web Servers) | |||
| Even if your reports show no errors, you may still notice that response times are unusually slow at certain times of the day. Use the same techniques used for understanding capacity overload to figure out what's causing your slow response time. | |||