200200 - Failed to Check HA State

Uploading...Agent error code #200200 means the Knocknoc agent could not find out which firewall in an HA pair is active, so it had nowhere to send the grant.

It applies only to a knoc configured with an HA peer and talking to firewalls directly. Where the knoc goes through Panorama, Panorama chooses the device and the agent never runs this check.

Before every grant the agent asks the firewall the knoc names for its HA state, using the show high-availability state operational command. If that firewall does not answer, the agent asks the peer instead, and uses the peer when it reports itself active. This code means neither question could be answered.

A related code is worth knowing about: #200201 means both firewalls answered and neither was active, which is a different problem. If you are reading 200200, the checks themselves did not complete.

Common causes include:

Neither firewall's management interface is reachable from the agent The API key on the HA peer is wrong, missing, or belongs to an administrator without permission to run operational commands. The peer holds its own key, separate from the one on the rest of the knoc The peer's hostname on the knoc is wrong, or points at a data interface rather than the management interface A TLS certificate the agent will not accept on the peer, where the primary's is accepted Both firewalls busy with a commit for longer than the agent's 10 second per-request budget

Steps to Resolve

Read the Accompanying Message

The description alongside this code names which firewall was being checked and, where the agent could tell, what went wrong: a refused credential, an unreachable host, a certificate the agent would not accept. A knoc with an HA peer holds more than one API key, so check the field the message points at rather than the first key on the page.

The agent log has the firewall's own words in agent_error_vendor_msg on the same line.

Confirm the Agent Can Reach Both Firewalls

From the host running the agent, for each firewall:

curl -k "https://<firewall>/api/?type=op&cmd=<show><high-availability><state></state></high-availability></show>&key=<api-key>"

A successful response contains an <enabled> element and, on a firewall in a pair, a <state>. Run it for the peer with the peer's own key. This is the exact call the agent makes, so if it works here and not from the agent, the difference is the credential or the network path from the agent host.

Check the Peer's Credential Separately

In the Knocknoc admin interface, open the knoc and look at the HA peer's own API key field. It is easy to leave holding the primary's key, or a key from before the peer was rebuilt.

Check Operational Command Permission

The API key needs permission to run operational commands, which is separate from the User-ID Agent permission the tag operations need. On the firewall, under Device > Admin Roles, confirm the role assigned to the API administrator allows the XML API's Operational Requests.

Rule Out a Standalone Firewall

If HA was switched off on the firewall, or was never enabled, remove the HA peer from the knoc. The agent handles a standalone firewall with a peer still configured (it uses the firewall the knoc names and logs a warning), but the configuration is misleading to whoever reads it next.