Hard to know since we do not have further information of the message contents and deployment details. The error you received is due the server not knowing what to do with the received request for an application it supports. I would have expected to see e.g. DIAMETER_UNKNOWN_SESSION_ID, though. I am _not_ a "CCR expert" but unless the primary and backup server share the session state, sending an update to a random server is obvious to fail. There is no such state change in the CCR state machine afaik (after a very quick look).
In RFC4006 Section 7 there is an explicit text stating:
In the following state machine table, the failover to a secondary server upon 'Temporary error' or 'Failure to send' is not explicitly described. Moving an ongoing credit-control message stream to an alternative server is, however, possible if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, as described in section 5.7.
Re-sending a credit-control event to an alternative server is supported as described in section 6.5.
In Section 6.5 it says:
Failover to an alternative credit-control server is allowed for a one time event, as the server is not maintaining session states.
Since your client is sending updates, I assume you are operating in a session-based credit-control mode, right? Sending an update to a backup server would cause an error and your client would be misbehaving.
In Section 5.7 it says:
If a failure occurs during an ongoing credit-control session, the credit-control client may move the credit-control message stream to an alternative server if the CC-server indicated FAILOVER_SUPPORTED in the CC-Session-Failover AVP. A secondary credit-control server name, either received from the home Diameter AAA server or configured locally, can be used as an address of the backup server. If the CC- Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit-control message stream MUST NOT be moved to a backup server.
Are these conditions met before sending the update to a random backup server?
