Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

Resource Management

This section explains how Steel-Belted Radius Carrier manages limited resources, such as network addresses, user or tunnel connections, and UDP ports.

Network Address Assignment

The Steel-Belted Radius Carrier address pooling feature allows you to set up one or more pools out of which unique network addresses are assigned dynamically as users require them. Each pool consists of a list of one or more ranges of IP addresses (an IP pool).

By using this feature, you can avoid allocating specific fixed addresses to individual users. You can make fewer addresses go farther, and you can consolidate address assignment across all your network access servers.

How Address Assignment Works

Proper operation of address assignment from a pool depends crucially on both RADIUS authentication and RADIUS accounting transactions, as follows:

  1. During the RADIUS authentication transaction, if the user’s attribute settings specify address assignment from a pool, an address is allocated for that user from that pool.
  2. The address is reserved for that user until a RADIUS accounting transaction indicates that the user has terminated the connection.

For this reason, the network access server must be configured for RADIUS accounting, and the same Steel-Belted Radius Carrier server must be specified for both authentication and accounting.

Note: If your network access server is not configured for accounting (or does not support accounting), you should not use the address pooling feature because addresses would be assigned but never released.

Setting Return List Attributes

The Framed-IP-Address return list attribute controls how the user’s IP address is assigned. The Framed-IP-Address attribute can be set for each user in the Steel-Belted Radius Carrier database.

Handling Address Leaks

Under optimal conditions, Steel-Belted Radius Carrier assigns and releases addresses automatically. In some circumstances, you can get address leakage, where an address remains reserved for a user after the user has terminated the connection.

Address leakage occurs when the address has been assigned during the authentication transaction, but the accounting transaction that would have released the address is never received by Steel-Belted Radius Carrier. This can occur for several reasons:

  • The Steel-Belted Radius Carrier server might have been taken down for a period of time during which accounting transactions occurred.
  • The network access server might have failed or been taken down before the user terminated the connection. (In many cases, however, Steel-Belted Radius Carrier might be able to prevent address leakage by recovering the addresses when the NAS starts up again.)
  • The network access server might have sent the authentication and accounting transactions to different RADIUS servers.
  • Despite a successful authentication, the user’s access with the NAS might have terminated unsuccessfully for a variety of reasons. In such a case, some network access servers might not initiate a subsequent accounting transaction.
  • Routing problems might have prevented the accounting transaction from reaching Steel-Belted Radius Carrier.

An address that has leaked remains out of circulation until the session expires or you manually release it by displaying the current sessions list and deleting the corresponding session. See Deleting Sessions.

Note: To prevent IP address leaks, when assigning IP addresses using tunneled authentication methods such as TTLS or PEAP, the "Transfer Inner Attribs To Accept" filter must be enabled, and the Framed-IP-Address attribute must be transferred by the filter. By default, the ttls_accept filter does this properly.

Address Leakage upon Stopping and Starting the Server

Steel-Belted Radius Carrier maintains all current address assignments in a persistent database on disk in non-cluster installations. For cluster, current address assignments are kept in the session database. If you shut down the server and then restart it, all the information about which address is assigned to which user is retained.

If you leave Steel-Belted Radius Carrier turned off for a substantial period of time after addresses have been assigned, address leakage may occur. After you restart the server, review the Current Sessions list (described in Current Sessions Overview) and delete entries you know are obsolete.

Overlapping Address Ranges

If you maintain multiple IP address pools, you can duplicate some of the addresses among the pools. The address tracking mechanism of Steel-Belted Radius Carrier, when it is enabled, ensures that, if an IP address appears in more than one pool, after it is assigned out of any pool, it remains unavailable through any of the pools until it is released.

You must disable this type of address tracking if the server is assigning IP addresses from disjointed networks. In that configuration, two numerically identical IP addresses would signal a conflict, even though they actually belong to two different networks.

Note: Overlapping IP Address ranges are supported only in the standalone version of SBR Carrier.

Order of Address Assignment

IP addresses are assigned on a first-in-first-out basis; that is, the address that was first released is the first to be reassigned. This ensures that addresses are out of use for as long as possible before reuse.

Concurrent Network Connections

The Web GUI enables you to limit the number of active connections, on a per-user, or per-tunnel basis.

Concurrent User Connections

You can set a maximum limit on the number of concurrent connections that a user can have. Subsequently, when the user requests a new connection, Steel-Belted Radius Carrier compares the current number of connections to the maximum limit.

If a new connection would exceed the limit, Steel-Belted Radius Carrier can reject the additional connection or allow the connection, but log the event in the server log (described in Using the Server Log File).

Note: When counting connections, Steel-Belted Radius Carrier does not distinguish between multi-link connections and new user authentication attempts.

For concurrent connection limits to work, each NAS must be configured for RADIUS accounting and the same Steel-Belted Radius Carrier server must be responsible for both authentication and accounting. These conventions give the server full access to the data it needs to track connections accurately.

The maximum number of concurrent connections can be set individually for any type of user by selecting the Maximum Concurrent Connections check box and entering a number in the accompanying field in the appropriate Add User/Edit User dialog box. See Administering Users.

Note: This concurrency is based on username only. The optional Session State Register module also supports attribute-based concurrency which is not limited to username only. For more information see Managing Concurrency with Attributes in Session State Register.

Authentication methods that do not require user entries must provide alternate mechanisms for supporting concurrent connection limits. For example, if you are using external database authentication there is an alias mechanism you can use in the SQL or LDAP configuration file. Concurrent connection limits can be supported under proxy authentication only if the target server supports them.

Concurrent Tunnel Connections

Steel-Belted Radius Carrier uses its Current Sessions Table (CST) list to determine the number of active connections for each tunnel. The CST list summarizes all of the RADIUS accounting data currently available to the server. Tunnel connections appear in the CST list using a special display convention that distinguishes them from user connections.

You can set a maximum limit on the number of concurrent connections that can be open using a specific tunnel. Subsequently, when a user requests a new connection through that tunnel, Steel-Belted Radius Carrier compares the current number of connections to the maximum limit. If a new connection would exceed the limit, Steel-Belted Radius Carrier rejects the additional connection.

Note: Concurrent tunnel connections are supported locally only.

For concurrent connection limits to work, it is essential that each NAS that can open a tunnel be configured for RADIUS accounting and that the same Steel-Belted Radius Carrier server be specified for both authentication and accounting and this applies only to non-cluster. For cluster installations, authentication and accounting must be sent to servers within the same cluster. This permits the server’s CST list to be kept up to date and available to every NAS that needs to authenticate a tunnel connection.

Note: Concurrent tunnel connections cannot be tracked across multiple Steel-Belted Radius Carrier servers without additional software extensions. Contact Juniper Networks for more information.

Attribute Value Pooling

Attribute value pooling lets you define pools of attribute sets that are assigned dynamically when an Authorization Request is processed. The attribute sets are distributed according to specified weights and the values are returned with the Access-Accept message.

Attribute value pooling allows for a dynamic allocation of attribute values sets, so that attributes needed to configure changeable and complex situations do not have to be assigned in static profiles. This functionality is supported by the use of a vendor-specific attribute called Funk-Round-Robin-Group. The value for this attribute is a string, and should be set to the name of an .rr suffix file that defines an attribute value pool.

An .rr file is defined as follows:

[Sets] SetName1 = Weight1 SetName2 = Weight2 ...[ SetName1 ] AttributeName1.1 = AttributeValue1.1 AttributeName1.2 = AttributeValue1.2 ...

Steel-Belted Radius Carrier maintains round-robin statistics for each attribute value pool so that weight calculations can be performed properly. When a user who belongs to a profile that has been assigned to a particular attribute value pool logs in, the round-robin values are incremented to determine which Attribute Value set should be assigned to the user. This attribute set is added to the return list of the Access-Accept.

Attribute value pooling can be used in several ways. For example, the Acme Company wants off-site employees to be able to establish tunnels to the company network. The Acme Company maintains three tunnel connection endpoints to which end users can create VPNs into the corporate network, each of these with different capacities. The Acme Company would define an attribute value pool of three attribute sets, each describing how to establish a tunnel with one of these connection points. These attribute sets should be weighted according to the capacity of the three connection points.

The following is a sample acme.rr file.

;acme.rr
[Sets]
VPN1=20
VPN2=12
VPN3=7

[VPN1]
Tunnel-Server-Endpoint = 8.4.2.1
Tunnel-Password = GoodGuess

[VPN2]
Tunnel-Server-Endpoint = 8.4.2.2
Tunnel-Password = BestGuess

[VPN3]
Tunnel-Server-Endpoint = 8.4.2.4
Tunnel-Password = OurSecret

To make this attribute value pool visible, the Acme Company would define a Funk-Round-Robin-Group VSA and assign it to the users (or the profile assigned to these users) and make the value of the VSA point to the acme.rr file.

Funk-Round-Robin-Group = acme.rr

Attribute value pools can be combined with other features. For example, by specifying an IP Pool name for a Framed-IP-Address attribute, you could load-balance IP pools.

Note: Attribute merging rules do not apply to attributes in round-robin files. You must follow appropriate attribute usage (single-valued, multi-values, check list, and so on). No special checks are performed to ensure that the attributes and values specified in round-robin files are consistent with the rest of your system configuration. Check the dictionary file for information about attribute usage.

Attribute value pools can be reconfigured dynamically. When you issue the SIGHUP (1) signal to the Steel-Belted Radius Carrier process, the modified files are re-read and the pool configuration is reset appropriately.

Note: You can have multiple, active Round-Robin-Group attributes in use simultaneously.

Phantom Records

When Steel-Belted Radius Carrier allocates resources such as IP addresses, user connections, and tunnel connections, to its clients, it generates a phantom accounting record for its internal use. Phantom records are not written to the RADIUS accounting database, but they are displayed in the Current Sessions Table (CST) list (described on Current Sessions Overview). Phantom records resemble accounting start records, except that the session ID for phantom records is displayed as N/A.

After Steel-Belted Radius Carrier receives the corresponding accounting start request packet from the client, it discards the phantom record and replaces N/A with the actual Session-ID number returned by the client device in the Current Sessions list.

In some cases, Steel-Belted Radius Carrier can allocate a resource and create a phantom record, but then never receive a corresponding start packet from the client. To avoid committing the resource indefinitely, Steel-Belted Radius Carrier waits for a limited period for the start packet to confirm the transaction. By default, Steel-Belted Radius Carrier waits 180 seconds, though you can configure a different wait period by editing the radius.ini file (described in the SBR Carrier Reference Guide).

Modified: 2017-03-07