Radius Accounting Authentication Association

From TBwiki
(Difference between revisions)
Jump to: navigation, search
m (moved Radius Acct Auth Association to Radius Accounting Authentication Association: Use complete name to be more formal)
(Removed the screen, changed format and description)
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:
  
===== Association Field in Radius Configuration =====
+
== General Usage ==
[[File:Radius_client_configuration_Association.jpg]]
+
===== Link accounting and authentication together logically =====
 
+
===== General Usage =====
+
'''Link accounting and authorization together'''.
+
  
 
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.
 
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.
Line 14: Line 9:
 
So both servers have to be the 'current' at the same time.
 
So both servers have to be the 'current' at the same time.
  
'''The association can ensure that Toolpack sends RADIUS requests to a single physical RADIUS server at a 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).
 
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 =====
+
 
 +
== A specific scenario ==
 
There are 2 Radius AUTH servers provisioned (IPerbill & IPeradius) and 2 Radius ACCT servers provisioned (the same IPerbill & IPeradius)  
 
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:
 
So there are 3 different possibilities for switchover:
  
1.- Toolpack will work with IPerbill as master for ACCT and AUTH
+
# 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
  
2.- In case of external failure Toolpack will switchover both stacks ACCT and AUTH to IPeradius
+
In this case, associating the accounting and authentication to the same IP will prevent occurrence of scenario 3.
  
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:
+
== Configuration ==
 
+
*[[Web_Portal_Tutorial_Guide_v2.7#CDR|Web Portal v2.7: RADIUS configuration]]
- 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.
+

Revision as of 15:47, 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