{{indexmenu_n>5}}
====== Radius Servers Reservation ======

Each Radius server is described by an FSM (Finite State Machine).

A Radius server can be in one of six states:
  * **Initial** — the state when fastPCRF starts;
  * **Alive** — the Radius server is accessible, requests can be sent to it;
  * **Dead** — the Radius server is inaccessible, requests cannot be sent;
  * **Alive-ping-sent** — a ping has been sent to the Radius server in the Alive state, waiting for a response;
  * **Dead-ping-sent** — a ping has been sent to the Radius server in the Dead state, waiting for a response;
  * **Disabled** — the server is administratively prohibited.

The main states are **Alive** and **Dead**, while the other states are transitional.
A Radius server is considered accessible if it is in the **Alive** or **Alive-ping-sent** states. In other states, the Radius server is considered inaccessible and requests cannot be sent to it.

Ping — is a Status-Server request, or if the Radius server does not support Status-Server (the `radius_status_server` option), an Access-Request with User-Name and Password equal to the `radius_ping_user_name` and `radius_ping_user_password` options, respectively.

Every 10 seconds, a watchdog task runs to check whether a ping should be sent, whether a response to the ping has been received, and based on this, it changes the server's state or leaves it unchanged.

When fastPCRF starts, all Radius servers are in the **Initial** state. fastPCRF sends a ping to them and transitions to the **Dead-ping-sent** state, waiting for a ping response.

In the **Alive** state, the server is pinged only if no responses have been received from it within the last `radius_keepalive` seconds. If the server is responding to requests and there is continuous request-response exchange, pings are not sent. When a ping is sent, the server transitions to the **Alive-ping-sent** state (waiting for a ping response).

In the **Dead** state, the server is pinged every `radius_dead_timeout` seconds: a ping is sent, and the server transitions to the **Dead-ping-sent** state. For example, if `radius_dead_timeout=3600` (1 hour), the Radius server cannot transition to the **Alive** state earlier than one hour after transitioning to the **Dead** state.

In the **Dead**/**Alive-ping-sent** states, the response to the ping is awaited for a maximum of `radius_response_timeout` seconds. The important factor is not the response to the ping itself but the fact of receiving any (any Radius message) from the server. If there is a response, the server transitions to the **Alive** state. If there is no response, it transitions to the **Dead** state.

The **Disabled** state can only be set via the CLI command `pcrf radius disable`. This state is similar to the **Dead** state (the server is inaccessible), but no pings are sent. Exiting the **Disabled** state is also only via the CLI command `pcrf radius enable`. The server transitions to **Dead**, and a ping is immediately sent (the state becomes **Dead-ping-sent**).

When a Radius server transitions to the **Dead**/**Disabled** or **Alive** states, the watchdog notifies fastPCRF that a particular server has become unavailable or available, respectively.\\ **Important!** Reservation of Radius servers is implemented according to the Master-Slaves scheme: only one Radius server is considered operational (master), the rest are backups (regardless of their state). Radius servers are specified in a list (each Radius server in a separate `radius_server` option), with the most preferred server being the one specified in the first `radius_server` option in `fastpcrf.conf`, followed by the less preferred ones, and so on. If the server with number N > 1 is the master, it means all servers before it (1..N-1) are unavailable (**Dead**). If any of the servers 1..N-1 becomes alive (**Alive**), it immediately becomes the master, and all requests go to it. Responses from the previous master are accepted.

If the current master becomes unavailable, the first server in the **Alive** state is searched for and becomes the master.

Authorization Radius servers do not receive any messages when they gain or lose master status. However, accounting servers do: if an accounting server loses master status, it is sent Accounting-Off; if an accounting server gains master status, it is sent Accounting-On. The following attributes are sent in Accounting-On/Off:
  * NAS attributes: NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier. Either only one of these attributes is sent (in the priority order listed here — the highest priority is NAS-IP-Address), or if the `radius_add_all_nas_ids=1` option is set, all known attributes are sent;
  * Acct-Status-Type = Accounting-On or Accounting-Off;
  * Acct-Session-Id = 0 — this acct-session-id value cannot be encountered by any acct session.