Command Engine to Agent (AGT) test

The Command Engine to Agent (AGT) communications test system checks that the Command Engine can initiate an SSL connection to the Agent and execute an XML/RPC request.

The thirteen possible results are:

• AGT – OK
• AGT – Untested
• AGT – Unexpected error
• AGT – Connection refused
• AGT – Connection time-out
• AGT – Server never registered
• AGT – Realm is unreachable
• AGT — Tunnel setup error
• AGT — Gateway denied access
• AGT — Internal Gateway error
• AGT — Gateway could not connect to server
• AGT — Gateway time-out

AGT – OK

No troubleshooting necessary.

AGT – Untested

This result is returned when a functional area cannot be tested because of a previous failure that prevents further testing. For example, if the Command Engine cannot contact the Agent, then no other tests are possible.

What can I do if a test is not run during an AGT test?

First resolve all tests that failed, and then run the Communication Test again.

AGT – Unexpected error

This result indicates that the test encountered an unexpected error.

What can I do if I get an unexpected error?

First resolve all tests that failed, and then run the Communication Test again. If the unexpected error recurs, check to see if any additional details in the error message indicate the problem. If the error cannot be resolved, contact Hewlett Packard Enterprise Customer Support.

AGT – Connection refused

This result indicates that the Command Engine is receiving a TCP reset packet when it attempts to connect to the Agent on port 1002. The likely cause is that the Agent is not running. A firewall might also be blocking the connection.

What can I do if the connection is refused during an AGT test?

Log into the server and confirm that the Agent is running. See Verifying that a Server Agent is running.

If the Agent is not running, restart the Agent. See Restarting a Server Agent.

From the managed server, use netstat to confirm that a socket is in listen mode on port 1002. If not, stop and restart the Agent.

From the server itself, use SSH to connect to the IP address of the server where the Agent is installed and port (1002) that the Agent is listening on. If this does not succeed, stop and restart the Agent.

Verify that the Management IP address that Server Automation is using to reach the server is the correct address. See Checking management IP of a managed server for more information. If the IP addresses do not match, stop and restart the Agent, then rerun the test.

If the previous steps are performed and the test still fails, the problem is likely caused by either a software-based firewall on the server itself or an external firewall blocking the connection.

AGT – Connection time-out

This result indicates that the Command Engine is not receiving any reply packets when it attempts to initiate a TCP connection to the Agent on port 1002. The likely cause is that the server is not running, or that the IP address that Server Automation is using to reach the Agent is incorrect. (A firewall might also be blocking the connection.) To check the IP address that Server Automation is using to reach the Agent, see Checking management IP of a managed server.

What can I do if the connection times out during an AGT test?

Follow the same steps used to resolve this issue specified in What can I do if the connection is refused during an AGT test?.

AGT – Request time-out

This result indicates that the Command Engine is able to successfully complete a TCP connection to the Agent on port 1002, but no response is received from the Agent in response to the XML-RPC request. The likely cause is that the Agent is hung.

What can I do if the request times out during an AGT test?

Log into the server and restart the Agent. See Restarting a Server Agent for detailed information.

Check to see whether or not some other process is consistently utilizing an excessive amount of the CPU on the server where the Agent is installed. Also check to see if the system is performing slowly due to a lack of available memory and/or excessive file IO. In any of these cases, the system might be performing too slowly to permit the Agent to respond to the test in a timely manner.

AGT – Server never registered

This test indicates that the server being tested has neither been registered with the Command Engine, nor can it communicate with the Command Engine. The cause of this could be any number of reasons similar to those in the Agent to Command Engine (CE) test test. It is also possible (but unlikely) that the Agent was installed but never started.

What can I do if the server has not been registered with the Command Engine during an AGT test?

To troubleshoot this error, use the following procedures:

1. Ensure that the Agent is running. For these instructions, see Verifying that a Server Agent is running.
2. Ensure that the Agent can contact the Command Engine.
3. If the Agent is in a Satellite facility, ensure that its Gateways are properly configured and that it is properly configured to use those Gateways. See Checking network gateway configuration for more information.
4. If the Agent is not in a Satellite:
5. Ensure the host name “way” (no quotes) resolves to its valid IP address. See Resolving the host name for more information.
6. Verify that a connection can be established to port 1018 of way.

One (or more) of the above checks will fail. To solve that failure, refer to the corresponding error code in Agent to Command Engine (CE) test, or to the realm connectivity and configuration test.

AGT – Realm is unreachable

The Satellite realm where the managed server is located is unreachable. This means that a path of tunnels between the Gateways in the SA core and the realm of the managed server cannot be established.

What can I do if the realm is unreachable during an AGT test?

This error could be due to a network problem, a malfunctioning or failed Gateway, or a Gateway misconfiguration. Contact Hewlett Packard Enterprise Customer Support for assistance in troubleshooting the Gateway network.

AGT — Tunnel setup error

The Command Engine could not establish a connection through any of its defined Gateways. This could be due to a network problem, a malfunctioning or failed Gateway, or a Gateway misconfiguration.

What can I do if I get a Tunnel Setup error during an AGT test?

Contact your SA administrator.

AGT — Gateway denied access

The Gateway is working but refused to proxy the connection on behalf of the Agent. This error most likely means that the Gateway is misconfigured such that the Gateway will not allow the Command Engine access to the Agent.

What can I do if the gateway is denied access during an AGT test?

Contact your SA administrator.

AGT — Internal Gateway error

Due to an internal error, the Gateway was unable to proxy the connection. This typically occurs when the Gateway is overloaded.

What can I do if there is an internal gateway error during an AGT test?

Contact your SA administrator.

AGT — Gateway could not connect to server

The Gateway could not establish a connection to the Agent. This might be because the Agent is not running, or because a firewall might be blocking the connection.

What can I do if the gateway couldn’t connect to the server during an AGT test?

If you suspect the Agent is not running, see Verifying that a Server Agent is running. To make sure that the Gateway can establish a connection to the IP address of the server where the Agent is installed, try to ping the IP address of the server where the Agent is installed.

AGT — Gateway time-out

The Gateways on the two ends of a tunnel could not communicate with each other, most likely due to a network connectivity problem.

What can I do if the gateway times out during an AGT test?

Ensure that network connectivity is available between the Gateways in the path between the realm of the managed server and the SA core.