Library Table of Contents Index Previous Next Comments

Troubleshooting the GRM configuration

Troubleshooting GRM configuration issues  Top

The following table lists common GRM configuration problems and provides information about how to troubleshoot them.

If...

Then...

You have deployed a GRM DNS server and the IP address in the GRM server access log is the IP address of the local DNS nameserver but no edge caches were returned.

Verify that the IP address of the local DNS nameserver is covered by the CIDR blocks specified in the edge group definition specified on the GRM server.

You have deployed a GRM DNS server and the IP address in the GRM server access log is different from the IP address of the local DNS nameserver.

Troubleshoot the local DNS infrastructure to determine why the local DNS nameserver does not contact the authoritative DNS nameserver (GRM server) directly.

One or more of the center or edge caches are not reporting status to the GRM server.

Verify that

  • Port 89 (the port on which the GRM server and GRM agent caches communicate) has not been blocked by any firewalls that are located between the agents and the GRM server.
  • The GRM server software has been enabled on the GRM server.
  • The center or edge cache has a GRM license installed.
  • The GRM agent software has been enabled on the center or edge cache.
  • The center or edge cache has been identified by a host name that the GRM server is able to resolve.

    If you think that the GRM server cannot resolve the host name, reconfigure the center or edge cache information in the GRM server so that the center or edge cache is identified by an IP address.

You expected the GRM server to return the IP addresses of edge caches, but none was returned.

  1. Ensure that the edge group definition (specified on the GRM server) contains the correct CIDR blocks.
  2. Verify that at least one edge cache belongs to the specified edge group.
  3. Check the GRM Server - Caches page to verify that the edge cache was not excluded because it was overloaded. To access this page, select Data Tab > GRM Server > Caches.

You defined an edge group to include center caches for failover, but the IP addresses of center caches were not returned.

Check the Edge Groups and Caches page to verify that the edge group was defined to include center caches. To access this page, select Setup tab > GRM Server > Edge Groups and Caches.

You expected the GRM server to return the IP addresses of center caches, but the IP addresses of center caches were not returned.

  1. Check the GRM Server - Caches page to verify that the center caches are reporting in. Also look for connection errors. To access this page, select Data Tab > GRM Server > Caches.
  2. Check the GRM Server - Caches page to verify that the center cache was not excluded because it was overloaded. To access this page, select Data Tab > GRM Server > Caches.

You expected the GRM server to return a close center cache, but a random center cache was returned instead.

Use the grm CLI command to verify that the GRM server had sufficient time to make proximity measurements to the IP address.

For example:

grm -ip IPaddress

If no proximity measurements are reported, continue checking until proximity measurements are displayed and repeat the test.

If no proximity measurements are reported, the center caches might not be able to reach the client. Contact your Network Appliance service engineer for assistance.

If you are deploying a GRM DNS server or are using a proxy.pac file to direct requests to the GRM L7 server, and you expected the GRM server to return the IP addresses of more center caches.

For example, if you defined an edge group to return three center caches, but only one center cache was returned.

Use the grm CLI command to verify the center caches have not been excluded because of their proximity to the local DNS nameserver.

For example:

grm -ip LDNS IP address

The preceding command lists the proximity of center and edge caches.

Example

Assume that you have set the Proximity for Center Caches option to 10 milliseconds and the CLI output shows the following:

center1.company.com: proximity 20

center2.company.com: proximity 35

The closest center cache, center1.company.com, is 20 milliseconds from the local DNS nameserver. Because the proximity match is set to 10 milliseconds, only center caches that are 20 and 30 milliseconds away from the local DNS nameserver will be returned.

To have more center caches returned, modify your proximity settings accordingly.

Note
If the proximity range indicates that more center caches should have been returned, check the GRM Server - Caches page to verify that the center cache was not excluded because it was overloaded. To access this page, select Data tab > GRM Server > Caches.

You shut down all edge caches to test center cache failover, but the GRM server is still returning the IP addresses of edge caches.

Check the Cache Status entry on the GRM Server - Caches page to verify that all edge caches in the edge group are displayed as Down. To access this page, select Data Tab > GRM Server > Caches.

Wait until all edge caches are marked as Down and retest.

If you are deploying a GRM DNS server and the GRM Server - Caches page shows all edge caches marked as Down, but no center caches are returned.

Using a DNS tool, such as dig, identify the DNS lookup Time To Live (TTL) to determine if the local DNS nameserver is caching stale DNS information. If the TTL is too high, the local DNS nameserver configuration might need to be altered. Contact your DNS system administrator for more information.

Viewing connection status for GRM servers and agent caches  Top

The GRM Server - Caches page and the GRM Agents - Connection Status page on the Data tab report errors that could result in a connection problem. Through these two pages, you can detect errors from the GRM server to specific GRM agent caches and from specific GRM agent caches to the GRM server.

Troubleshooting GRM functionality for CDN clients  Top

If you successfully completed the testing procedures described in Verifying the GRM network, the client tests you performed in Testing GRM functionality for CDN clients should have been successful. If your tests were unsuccessful, complete the following steps.

Step

Action

1

Check the proxy settings on the browser to ensure that no proxy is set.

2

View the GRM server access log to determine if the GRM server is being queried.

3

If...

Then...

The GRM server is not being queried

If the GRM server is a GRM DNS server or a GRM DNS server is being used to direct requests to a GRM L7 server, use a DNS tool, such as dig, to determine if the TTL on the local DNS nameserver is causing it to cache stale DNS information. If the TTL is too high, the local DNS nameserver configuration might need to be altered. Contact your DNS system administrator for more information.

The GRM server is not being queried (continued)

If the GRM server is an L7 server and a GRM DNS server is not directing requests to it, troubleshoot the method used to direct the requests to the GRM L7 server.

For example, if you are using a device in the network infrastructure to direct requests to the GRM L7 server, check for problems with the device. If you are using a proxy.pac file, check that the proxy.pac file is set up correctly on the GRM L7 server and that the client browsers are configured to point to the correct GRM L7 server.

The GRM server is being queried

Review the configuration settings on the GRM agent cache. Determine if the desired protocol services are enabled and that the correct ports are open.

On the GRM server, review the information on the Data tab > GRM Server - Caches page to see whether all configured protocols are being reported to the GRM server.

4

Perform any of the relevant tasks described in Troubleshooting the GRM configuration.

Library Table of Contents Index Previous Next Comments