Differences

This shows you the differences between two versions of the page.

--- en:dpi:bras_bng:radius_integration:radius_accounting:radius_reliability [2024/09/26 15:29] – external edit 127.0.0.1
+++ en:dpi:bras_bng:radius_integration:radius_accounting:radius_reliability [2024/12/05 15:10] (current) – elena.krasnobryzh
@@ Line 1: / Line 1: @@
-===== Monitoring the connection to the Radius server =====
+====== Monitoring the connection to the RADIUS server ======
 {{indexmenu_n>5}}
-Stingray SG monitors the connection to the Radius server, trying to catch the moment of connection breakage and the need to switch to another (standby) Radius in time. Since this is a UDP connection, such control can be carried out only if there are no responses to the Stingray requests. Only authorization requests are controlled: when a connection break is detected (the Radius does not respond to Access-Request), the Stingray's authorization subsystem notifies the accounting subsystem about the need to switch to another server. That is, authorization is the master subsystem, and accounting is the slave subsystem (note that the ports for sending authorization and accounting requests in the Radius protocol are different, although the server is the same).
+Stingray SG monitors the connection to the RADIUS server, trying to catch the moment of connection breakage and the need to switch to another (standby) RADIUS in time. Since this is a UDP connection, such control can be carried out only if there are no responses to the Stingray requests. Only authorization requests are controlled: when a connection break is detected (the RADIUS does not respond to Access-Request), the Stingray's authorization subsystem notifies the accounting subsystem about the need to switch to another server. That is, authorization is the master subsystem, and accounting is the slave subsystem (note that the ports for sending authorization and accounting requests in the RADIUS protocol are different, although the server is the same).
-If the connection is broken, the accounting cannot notify the Radius-server about this event, because the server is considered to be down. All active (started) accounting sessions are put into suspended state: fastpcrf continues to receive data from all fastDPI, to start new sessions and close old ones, – everything works as if there is a connection to Radius-server, but no accounting data is sent to Radius. A suspended session behaves the same as an active session.
+If the connection is broken, the accounting cannot notify the RADIUS-server about this event, because the server is considered to be down. All active (started) accounting sessions are put into suspended state: fastpcrf continues to receive data from all fastDPI, to start new sessions and close old ones, – everything works as if there is a connection to RADIUS-server, but no accounting data is sent to RADIUS. A suspended session behaves the same as an active session.
-When connection with the Radius-server is re-established (or when it is switched to another one) fastPCRF sends an Accounting-On message to it with the NAS attributes of fastPCRF (specified in fastpcrf conf with parameters radius_attr_nas_ip_address and radius_attr_nas_id). Then for each suspended session (as well as for all new sessions which were created while Radius-server was unavailable) Acct-Start is sent, and the session is switched to started (active) state.
+When connection with the RADIUS-server is re-established (or when it is switched to another one) fastPCRF sends an Accounting-On message to it with the NAS attributes of fastPCRF (specified in fastpcrf conf with parameters ''radius_attr_nas_ip_address'' and ''radius_attr_nas_id''). Then for each suspended session (as well as for all new sessions which were created while RADIUS-server was unavailable) Acct-Start is sent, and the session is switched to started (active) state.

Profile

Settings

Differences