Radius Accounting Authentication Association

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(Created the initial page with the information of "RADIUS Accounting and Authorization Association")
 
(fixed link)
 
(4 intermediate revisions by one user not shown)
Line 1: Line 1:
'''''Applies to version(s): v2.7'''''
 
{{DISPLAYTITLE:Toolpack:RADIUS Accounting and Authorization Association}}
 
  
 
With version 2.7.31+, Toolpack has the Associated server field in the RADIUS Client configuration page:
 
With version 2.7.31+, Toolpack has the Associated server field in the RADIUS Client configuration page:
[[File:Radius_client_configuration_Association.jpg]]
 
  
== Multiple Radius Servers ==
+
== General Usage ==
Toolpack Radius AUTH/ACCT can be provisioned with several Radius servers (not only two).
+
===== Link accounting and authentication together logically =====
Each Radius client processing AUTH and ACCT are flexibly configurable by:
+
  
=====Use polling (Status-Server)=====
+
This allows to specify that whenever one of the two associated server is the Current one, then the other one should also be set as the current one.
  
=====Requests timeout and number of retries=====
+
So both servers have to be the 'current' at the same time.
  
This list of Radius servers can be configured here: [[Toolpack:Adding_RADIUS_server_B|Configuring Radius]]
+
===== Sends Acct/Auth requests to the same physical RADIUS server =====
  
== Current(Primary) Radius AUTH/ACCT server ==
+
The association resolves a problem when you would have two physical RADIUS servers, each server hosts an accounting and authorization server, and you have a limitation on the Radius server to run the primary accounting and authentication on the same server (identical IP).
If polling is enabled, the selected "Current" server will be the first that responds to the polling requests.
+
All other servers in the list will be flagged as "online" or "offline" depending whether it responses to the polling.
+
  
If polling is disabled, the server is selected in a round robin order, the first being tested successfully is the "Current".
 
All other servers in the list will be flagged as "online" or "offline" depending whether it responses to requests within the timeout and retries.
 
  
== Radius AUTH/ACCT switch-over ==
+
== A specific scenario ==
Let's take this scenario to explain the Radius AUTH/ACCT switchover feature:
+
There are 2 Radius AUTH servers provisioned (IPerbill & IPeradius) and 2 Radius ACCT servers provisioned (the same IPerbill & IPeradius)
  
We have servers '''A''' and '''B''', both 'online', and server '''A''' is 'Current'.
+
So there are 3 different possibilities for switchover:
  
Request W is sent to server '''A'''.
+
# Toolpack will work with IPerbill as master for ACCT and AUTH
 +
# In case of external failure Toolpack will switchover both stacks ACCT and AUTH to IPeradius
 +
# In some specific cases of external failures Toolpack will switchover only one stack, so we will have AUTH to IPerbill and ACCT to IPeradius:
 +
:* Either: AUTH to IPerbill and ACCT to IPeradius
 +
:* Or: ACCT to IPerbill and AUTH to IPeradius
  
Request X,R,Z are in the queue sent to server '''A'''.
+
In this case, associating the accounting and authentication to the same IP will prevent occurrence of scenario 3.
  
Server '''A''' doesn't respond to Request W. In consequence, server '''A''' is qualified as 'offline' and server B is elected as 'Current'.
+
== Configuration ==
 
+
*[[Web_Portal_Tutorial_Guide_v2.7#RADIUS_Authorization_and_Authentication|Web Portal v2.7: RADIUS Authorization and Authentication]]
Request W is then sent to server '''B'''.
+
 
+
All new requests M,Y,Q will be sent to server '''B'''.
+
 
+
The Request X which is in queue to '''A''', will be sent to '''A'''. If A is still qualified as 'offline'. It will be then sent to '''B'''.
+
 
+
If server '''A''' is back qualified as "online". It will process the request X.
+
 
+
The requests R,Z in queue will be processed same as X.
+

Latest revision as of 15:49, 5 February 2014

With version 2.7.31+, Toolpack has the Associated server field in the RADIUS Client configuration page:

Contents

General Usage

Link accounting and authentication together logically

This allows to specify that whenever one of the two associated server is the Current one, then the other one should also be set as the current one.

So both servers have to be the 'current' at the same time.

Sends Acct/Auth requests to the same physical RADIUS server

The association resolves a problem when you would have two physical RADIUS servers, each server hosts an accounting and authorization server, and you have a limitation on the Radius server to run the primary accounting and authentication on the same server (identical IP).


A specific scenario

There are 2 Radius AUTH servers provisioned (IPerbill & IPeradius) and 2 Radius ACCT servers provisioned (the same IPerbill & IPeradius)

So there are 3 different possibilities for switchover:

  1. Toolpack will work with IPerbill as master for ACCT and AUTH
  2. In case of external failure Toolpack will switchover both stacks ACCT and AUTH to IPeradius
  3. In some specific cases of external failures Toolpack will switchover only one stack, so we will have AUTH to IPerbill and ACCT to IPeradius:
  • Either: AUTH to IPerbill and ACCT to IPeradius
  • Or: ACCT to IPerbill and AUTH to IPeradius

In this case, associating the accounting and authentication to the same IP will prevent occurrence of scenario 3.

Configuration

Personal tools