Troubleshooting - Adaptive Applications - BlueCat Gateway - 23.2.4

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

docker volume ls

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

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

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

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

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

You can list the directory of the log files by running the following command:

docker exec <service_node_container_name> ls /var/log/rabbitmq/

You can list the directory of the configuration files by running the following command:

docker exec <database_node_name> ls /daemon_run/

You can list the directory of the log files by running the following command:

docker exec <database_node_name> ls /daemon_run/

You can list the directory of the configuration files by running the following command:

docker exec <database_node_name> ls /etc/mysql/custom/

You can retrieve the log files by running the following command:

docker exec <database_node_name> tail -f /var/log/mysql/mariadb.err

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.

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.