Troubleshooting - Adaptive Applications - BlueCat Gateway - 22.1

BlueCat Distributed DDNS Administration Guide

Locale
English
Product name
BlueCat Gateway
Version
22.1

The following section outlines common problems that might occur when implementing the Distributed DDNS Adaptive Application.

How do I see the Docker volumes that have been created on a BDDS?

You can see a list of Docker volumes created on a BDDS by running the following command:
docker volume ls

How do I see the location of a Docker volume?

You can see the location of a Docker volume by running the following command:
docker volume inspect <volume_name>
For example, to view the volume location of Distributed DDNS, run the following command:
docker volume inspect ddns_config

How can I check the log files for DDNS Service on a Distributed DDNS Service Node?

You can list the directory of the log files by running the following command:
docker exec <service_node_container_name> ls /var/log/distributed_ddns/
You can also see the contents of a log file by running the following command:
docker exec <service_node_container_name> tail -f /var/log/distributed_ddns/receiver.log

How can I check DDNS Service configuration on a Distributed DDNS Service Node?

You can list the directory of the configuration files by running the following command:
docker exec <service_node_container_name> ls /ddns/ddns_service/etc/
You can also see the contents of the DDNS service configuration file by running the following command:
docker exec <service_node_container_name> cat /ddns/ddns_service/etc/ddns.yaml

How can I check the configuration of Anycast services on the Distributed DDNS Service Node?

You can list the directory of the Anycast configuration files by running the following command:
docker exec <service_node_container_name> ls /etc/quagga/
You can also see the contents of the Anycast service configuration file by running the following command:
  • BGP service configuration file:
    docker exec <service_node_container_name> cat /etc/quagga/bgpd.conf
  • OSPF service configuration file:
    docker exec <service_node_container_name> cat /etc/quagga/ospfd.conf
  • OSPFv3 service configuration file:
    docker exec <service_node_container_name> cat /etc/quagga/ospf6d.conf

How can I check the configuration of the Queue Service on the Distributed DDNS Service Node

You can list the directory of the configuration files by running the following command:
docker exec <service_node_container_name> ls /etc/rabbitmq/
You can also see the contents of the queue service configuration file by running the following command:
docker exec <service_node_container_name> cat /etc/rabbitmq/rabbitmq.conf

How can I check the logs of the Queue Service on the Distributed DDNS Service Node

You can list the directory of the log files by running the following command:
docker exec <service_node_container_name> ls /var/log/rabbitmq/

How can I check the configuration of all Configuration Daemons on the Distributed DDNS Data Node?

You can list the directory of the configuration files by running the following command:
docker exec <database_node_name> ls /daemon_run/

The configuration files of each daemon are located in the /config directory of each daemon.

How can I check the logs of all Configuration Daemons on the Distributed DDNS Data Node?

You can list the directory of the log files by running the following command:
docker exec <database_node_name> ls /daemon_run/

The log files of each daemon are located in the /config directory of each daemon.

How can I check the cluster configuration on the Distributed DDNS Data Node?

You can list the directory of the configuration files by running the following command:
docker exec <database_node_name> ls /etc/mysql/custom/

How can I check the cluster logs on the Distributed DDNS Data Node?

You can retrieve the log files by running the following command:
docker exec <database_node_name> tail -f /var/log/mysql/mariadb.err

Distributed DDNS Service sends an update to the DNS server but the server fails to process it

If the DNS server fails to process the update, check the Distributed DDNS Service log files for the following message:
2019-09-22 23:26:55,220 DEBUG: Response from DNS: <Message id=39580 opCode=5 rCode=9 maxSize=0 flags=answer queries=[Query('56.168.192.in-addr.arpa', 6, 1)] additional=[<RR name=key-example-com type=TSIG class="ANY" ttl=0s auth=False>]>
2019-09-22 23:26:55,221 ERROR: 56118 Update failed by server: verified = 0, rCode = 9. No retry
If these messages exist, verify the following information:
  • Check if Distributed DDNS and DNS server are using the same TSIG key name. For example, check if the key name is not assigned to an "update-policy" of the zone or is assigned but not deployed to the DNS server.
  • Check if the secret, algorithm, and key length are the same for that key name.
  • Verify that the time on the Distributed DDNS and DNS server does not differ by more than 5 minutes.

A client sends an update to a Distributed DDNS Service Node but the node fails to update

If the Distributed DDNS Service Node fails to process the update, check the Distributed DDNS log files for the following message:
"Failed permission: Update is not allowed or denied explicitly"
If the messages exist, check the Distributed DDNS workflow configuration to see if there are any permissions configured for the updated zone. The update is denied in the following cases:
  • No permissions are configured. In this case, all DDNS updates are denied.
  • No permissions are configured that explicitly allow the resource record to be updated.
  • Permissions are configured that explicitly deny the resource record from being updated.

The Distributed DDNS Data Node container did not start after rebooting my BDDS

When you reboot your BDDS, the Distributed DDNS Data Node containers do not automatically start after the BDDS has come back up. The Distributed DDNS Data Nodes are clustered and must be restarted in a certain order to ensure that all nodes in the cluster are operating correctly.

For more information on determining the order in which Distributed DDNS Data Nodes must come up and how to restart the Distributed DDNS Data Node containers, refer to Recovering the Distributed DDNS Data Node database cluster.