The AAA Server Node test case provides a virtual AAA server that can be used in conjunction with a nodal test case to test a Network Access Server (NAS) SUT such as a GGSN, PDSN-FA, or HA. The nodal test case generates control and bearer traffic towards the NAS, and the AAA Server Node listens for and responds to requests from the SUT.
This topic will guide you through configuring the node for basic AAA authentication and accounting services, and then expanding the service with the optional IP Address Allocation feature.
You should have a basic understanding of the test system:
You should also know which standard and vendor-specific RADIUS attributes the SUT expects to receive in Access Accept and Accounting Response messages.
To configure basic AAA services:
The goal for the first test is to add a AAA Server Node to an existing test session and configure the virtual server to provide authentication services and support accounting sessions. Although the virtual server does not maintain accounting records, it will respond to Accounting Request messages with Accounting Responses that include accounting attributes that you define.
A virtual server will respond to any SUT or emulated node that directs traffic toward it, and you can use more than one server in a test session. For example, in an end-to-end test you can configure one server to respond with attributes acceptable to one NAS and configure another server to respond to the others. You can also configure one virtual server to provide authentication services and another to provide accounting support.
Open a test session... containing a nodal test case that you have successfully executed with the SUT.
Add a local AAA Server Node test case... from the Basic library. If your test system has more than one test server, select a test server that is not used by the nodal test case. The Test Case Settings window... opens to the General tab.
The test case Name is optional and is used as the display name for the test case in the Test Session window. It should give some indication as to the virtual server's configuration — Accounting Server or HAAA Server, for example. If you are configuring the server for a particular vendor, include the vendor name. Names are especially useful in identifying a test case when a test session includes more than one virtual server.
AAA Server Node — Define the AAA server emulator.
On the AAA Server Node Address sub-tab, select a Physical Interface for the emulator and the first address in the interface's address pool is selected for the Starting IP Address. You can accept the default address or enter another address from the pool. If the node and nodal test cases share the same test server, make sure that this address is not used by the nodal test case.
Authentication Services — Define the number of authentications, the user credentials, and the RADIUS attributes required for Access Accept messages.
Enter the number of MNs provisioned in the nodal test case in Number of User Names... This value represents the maximum number of unique user names that the virtual server can successfully authenticate.
Define the format used to generate unique user names in User Name. Use the same format that you used in the nodal test case to ensure that the user names will match.
If the SUT supports password authentication, check the Password Enable box and enter the same Password used for the MNs in the nodal test case.
Enter the port used by the SUT for authentication traffic in NAS Authentication Port...
Enter the secret used by the SUT to identify itself to a AAA server in NAS Authentication Secret...
Enable EAP support with the Use EAP Settings checkbox and then define the methods and credentials supported with the EAP Settings window.
If the SUT expects that the user name will be returned in an Access Accept message, check the Include User Name box.
Configure the rest of the RADIUS and vendor attributes that the SUT expects to receive in an Access Accept message. See Using VSAs for instructions.
If the virtual server will be responsible for assigning IP addresses to the MNs, follow the instructions in Add IP Address Allocation.
Accounting Services — Define the number of sessions supported, NAS authentication, and the RADIUS attributes required for Accounting Response messages.
Enter the Number of Accounting Sessions... that will be supported by the virtual server. In a GPRS or UMTS test, this is the total number of PDP contexts that the nodal test case will attempt to establish; in other scenarios, this is the total number of MN sessions that the nodal test case will attempt to establish.
Enter the port used by the SUT for accounting traffic in NAS Accounting Port...
Enter the secret used by the SUT to identify itself to a AAA server in NAS Accounting Secret...
Configure the rest of the RADIUS and vendor attributes that the SUT expects to receive in an Accounting Response message. See Using Optional Attributes for instructions.
You are now ready to validate your definitions. Click Apply to accept the test case. If any parameters fail validation, you will receive an error indicating the problem parameter. Correct the problem and when the definition is accepted, the test case is listed in the Test Session window.
Automation Control
The virtual server should be running and ready to respond to requests when a nodal test case starts, and it should continue to run until all nodal test cases reach the Stopped state. If the virtual server stops before a nodal test case, it is unable to respond to any final request messages. Use Automation Control to define the test sequence. See Adding Automation Control for detailed instructions.
If the test session already uses Automation Control, insert a step above the first test case.
In Step1, select the AAA Server Node from the Test Case drop-down list and set the Activity to Start.
In Step 2, select a nodal test case, set the Activity to Start, and the Predecessor to the AAA Server Node. RUNNING should appear in Predecessor State, indicating that the nodal test case will not start until the node reaches the Running state and is ready to accept requests.
Add the remaining nodal test cases, if necessary, and set start activities. These test cases do not need to use the AAA Server Node as a predecessor, they will execute sequentially or according to whatever predecessors or delay times you have defined.
If you have not defined a sequence that stops the nodal test cases, add a Wait step. When you run the test, it will execute this step until you hit the Continue button. Add new steps for each nodal test case and set the Activity to Stop. You can define predecessors, stopping each test case when the previous test case has stopped. If no predecessors are defined, the nodal test cases will all begin to stop at the same time just as if you had clicked Stop.
Add the final step and select the AAA Server Node. Set the Predecessor to the last nodal test case that will reach the Stopped state, and STOPPED should appear in Predecessor State. If you are using more than one nodal test case and have not defined predecessors in the other stop steps, select the test case that will take the longest to stop — typically the test case with the most MN sessions.
Run the test session, and a validation check is performed on the test session. This validation ensures that the IP addresses used by the test case do not conflict with any other test sessions that may be running on the test server, and that the test definition does not violate rate and volume limits. You will also receive an error if you attempt to run the test session on a test server that is already running at capacity or is otherwise unable to accept a test session. See Running a Test Session for more information on handling these types of errors.
Select the Reports tab when it becomes available. Ideally, your MN sessions established and the Sessions Established, Attempted Session Connects, and Actual Session Connects measurements on the Test Summary tab match the sessions provisioned in the nodal test case. Explore the measurements displayed on the two new tabs: RADIUS and AAA Server Node.
If this is your first test session with Automation Control, notice that the Session Status bar displays the amount of time remaining when a step with a delay time is executing, and that the current step is highlighted on the Automation Control tab. You can watch the test run or Continue the test session when you are ready to stop.
TROUBLESHOOT: If the MN sessions fail to connect, Attempted Session Connects will increment but no connections are recorded. Eventually, Session Errors will accumulate as the connection is retried. Common causes of session failures are connectivity problems and authentication failures.
A SUT may prevent a session from being established if the accounting session fails. No Free Accounting Session Errors indicates that Number of Accounting Sessions is not adequate to support all MN sessions. The SUT may be rejecting the responses from the virtual server if mandatory message attributes are missing or incorrect. Compare your VSA configuration with the SUT's requirements. |
After you have finished the definition and successfully tested it, save the test session... You can also save the AAA Server Node test case... to the Test Case Library to preserve the definition and use it as a linked test case.
For more advanced AAA support, you can add the following options to your virtual server:
If you need to supply non-sequential values for incrementing parameters, you can do so with Test Data Files.
Enable CoA Simulation.
When the virtual server is responsible for assigning IP addresses to MN sessions, you can use the IP Address Allocation feature. Addresses from pools that you define are allocated using methods that you select and are returned to the NAS in the Access Accept messages.
NOTE: The NAS must include the 3GPP-Session-Stop-Indicator attribute in Accounting Request - stop messages in order for the server to release an allocated address. |
Check the IP Address Allocation Feature box. New parameters are enabled on the General tab and the IP Pool Mgr tab is added to the test case.
The virtual server will reserve an IP address when authentication succeeds and will hold that address for the MN until the accounting session is started. The address will be released if an Accounting Request - start is not received within the time that you define in Wait Acct-Start-Msg Time...
The pool from which an address is allocated can be specified in the Called-Station-Id attribute in the Access Request messages from the NAS or you can specify a default pool selection method in the IP Pool Manager. Use the Ip Address Pool Selection Method... drop-down list to select the method used in this test.
Select the IP Pool Mgr tab and define the IP address pools. See Using the IP Pool Manager for instructions.