The AAA Server Nodal test case tests a AAA server's capability to process authentication and accounting transactions. This topic will guide you through configuring and running a basic Capacity Test, and then expanding the basic test with the optional behaviors available in the test case.
After you have a functioning test session, you can build tests using other test activities and options:
You should have a basic understanding of the test system:
Prepare the system and gather information about the SUT:
Add at least one SUT to the database if necessary
The AAA SUT's VSA requirements
To configure a AAA Server Nodal Capacity test:
The goal for the first test is to authenticate one MN and establish one accounting session to confirm the test case definition, then to successfully execute the test with increased rates and multiple MNs. RADIUS is used in this example.
Create a new test session... and add a AAA Server Nodal test case... from the Basic library. The Test Case Settings window... opens to the General tab.
General Parameters — Identify the SUTs, define the NAS emulator, and select the test type
Define one NAS emulator on the NAS Node sub-tab. Select a Physical Interface and the first address in the pool is provisioned in Starting IP Address.
Select the NAS tab.
The AAA Test... drop-down list allows you to configure the test to generate authentication traffic, accounting traffic, or both (default). If your SUT only supports one or the other, select the appropriate test type; otherwise, accept the default for this test.
In the basic configuration, either one or two SUTs may be tested. The Authentication and Accounting panes each contain a System Under Test sub-pane used to define the SUT for the respective function. You can select the same SUT in both sub-panes or select one SUT to handle authentication traffic and another to handle accounting traffic.
Message Attributes — Define the attributes that will be included in RADIUS messages
Define the authentication credentials associated with an MN: User Name and an optional Password.... You can provision these parameters to generate static values that are used for all MNs, or you can generate unique values for each MN with the Auto-Increment feature. Configure values that will be acceptable to the SUT.
Define a NAS Identifier... that will be recognized by the SUT. This parameter can also use Auto-Increment to generate unique values when you configure a test with multiple NAS nodes.
Starting Accounting ID... will automatically increment for each MN. Accept the default value or define a new starting value.
Add any other attributes required by the SUT to the Vendor Specific Attribute Configuration. Click the View/Edit button and follow the instructions in Using Optional Attributes.
Authentication Parameters — Configure the authentication traffic settings
The default RADIUS authentication port is 1812. If the SUT listens for traffic on a different port, set SUT (AAA) Port... to that port number.
Define an Authentication Secret... that is acceptable to the SUT.
Select the Authentication Type... used by the SUT.
Use the checkboxes to select the optional message attributes... (defined above) that will be included in authentication messages sent by the NAS.
Accounting Parameters — Configure the accounting traffic settings
The default RADIUS accounting port is 1813. If the SUT listens for traffic on a different port, set SUT (AAA) Port... to that port number.
Define an Accounting Secret... that is acceptable to the SUT.
Use the checkboxes to select the optional message attributes... that will be included in accounting messages sent by the NAS.
The remaining parameters define the accounting message cycle. Accept the defaults for now.
You are now ready to test your configuration. The parameters that have not been addressed control optional behaviors that do not affect the success of a session. Click OK 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.
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 session is established and the Sessions Established, Attempted Session Connects, and Actual Session Connects measurements on the Test Summary tab are all 1. If your test includes accounting traffic, you should also see Accounting Started Sessions, and if you let the test run, you'll see the session move to Accounting Stopped Sessions when the Started Time expires (30 seconds) and the accounting session is stopped. Explore the measurements displayed on the other tabs. The measurement definitions are located in the Measurement Reference. Stop the test session when you are ready to continue.
|
TROUBLESHOOT: If the MN session fails 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. Access Request Timeouts and Accounting Request Timeouts on the RADIUS tab can indicate connectivity problems. Confirm that the SUT address is correct, and that the address assigned to the NAS node does not conflict with another device in the test network. You can also SSH to the test server as cfguser and ping the SUT. If connectivity is not a problem but timeouts are reported, check Poorly Formed Received. A count there indicates that the test is not able to interpret messages from the SUT. If Access Rejects Received is greater than 0, look for Authentication Failed as a reason for the reject and adjust the user credentials accordingly. |
Next, increase number of MNs and the test rates. Edit the test case..., set the Number of Mobile Nodes to 100, and set the Activation Rate and Deactivation Rate to 10.
OK the change, and Run the test session again. This time you should be able to see the MN sessions establish over 10 seconds (10 sessions each second).
|
TROUBLESHOOT: If all of the MN sessions fail to establish, Attempted Session Connects will be larger than Actual Session Connects and Sessions Established. The most likely reason is a problem with incrementing user credentials. |
Finally, customize the optional behaviors to tailor the test to your purpose.
Send Accounting-On and Accounting-Off messages to the SUTs when the test starts and ends.
Apply a distribution model to vary the activation and deactivation rates with the Advanced settings on the Mobile Node sub-tab.
Adjust the retry behavior.
Request that the SUT allocate IP addresses for the MNs during authentication with the Enable IP Address by AAA... checkbox.
If the test includes accounting transactions, you can modify the accounting message cycle and choose the types of accounting messages that will be sent.
Provision non-sequential values with a Test Data File.
After you have finished the definition and successfully tested it, save the test case and the test session as "AAA Base" or something similar.
Continue building your standard tests with other test activities and then try combining multiple test cases in one test session using linked test cases and Automation Control.
A AAA test can use one of two ways to select the SUT that will be requested to service an MN: dedicated or round-robin. In dedicated mode the SUT is selected by function — all authentication traffic is sent to the SUT identified in the Authentication pane and all accounting traffic is sent to the SUT identified in the Accounting pane. In round-robin mode, all traffic for an MN is sent to a SUT selected from a pool of SUTs defined in the AAA Pool pane.
Your foundation test case used the default dedicated mode and you selected the SUTs for authentication and accounting traffic. You can add up to two additional failover or secondary SUTs, one for each function, by checking the Secondary SUT box and selecting the SUT from the drop-down list that is now available. If the primary server fails to respond, the test will attempt to execute the failed transaction with the secondary server.
To configure a round-robin test, set AAA Distribution Mode... to Round-Robin. The AAA Pool pane is enabled and the System Under Test sub-panes are disabled. Select the Number of AAAs in Pool and a separate, numbered sub-tab is displayed for each SUT. Select a SUT from the drop-down list on each sub-tab.
When your test model requires that another network element participate in user authentication, such as an HA in a CDMA2000 Mobile IP simulation, you can add a generic NAS node that also sends Access Requests to the AAA SUT.
Select the NAS tab and check the Authentication box in the Alternate Node sub-pane.
Define the Access Request Delay Time...
Provision a NAS Identifier for the node.
If you have defined a VSA configuration, check the Access Request Node 2 box in all attributes that should be included in requests sent by the node and add any attributes that will only be sent by this node. If you need one attribute to send two different values depending on the sender, add another attribute and only select the node 2 box.
Select the General tab and define the NAS emulator on the Alternate Node sub-tab.
When you run the test, you should see that 2 access requests were sent for every MN (RADIUS tab), and you should see measurements in both Average Node2 Access Response Time and Node2 Access Response Count.