Reserving Ports For Your Test Session

You may Reserve Port for a Test Session to prevent other users from using the ports. Reserving ports for exclusive use of your test session provides the ability to run multiple IP addresses and sub-masks on the same physical interface, , i.e., allows you access to custom subnet ranges. You may use the Reserve Port feature with your Test Server provided Subnets and Routes and without storing any Subnet/Route information in the Test Session.

The Reserve Ports features allows you to Override Default Test Server Ports, Subnets, and Static Routes. You may configure custom subnets and static routes for your test server ports and override your Test Case Configuration. The custom configuration is stored with the Test Session and override the Test Case server configuration when you run the test. You may use the Reserve Port feature as follows.

The Reserve Ports features allows you to configure a static ARP table or User specified address table that is resolved before Test Case startup and is VLAN supported. Select Pre-Resolved ARP pane. See Step 8 below.

Open new/existing Test Session, Reserve Port and then add new/existing Test Cases to use the reserved configuration.

Open new/existing Test Session, configure Test Cases (with Test Servers, Subnets, Port), and then use Reserve Ports to override Test Case configuration.

See also Test Server ModesTest Server Modes

NOTE: Each Test Server supports/runs test sessions in three modes:

Non-Reserved (No ports or Processes reserved)	Reserved Ports	Reserved Ports + Reserved Processes
All tests run on one process All tests share ports A single test case can use 100% of license values/capacity	All tests run on one process Each test owns only the ports it uses A single test case can use 100% of license values/capacity	Each process runs one test Single test can run on multiple processes Each process owns the ports it uses If using Performance Accelerator: A single test case can use 66%, that is, 2/3 of the licensed values/capacity. (Hence, 3 tests cases across 3 processes = ~200%)

Reserving Ports and Overriding Default Test Server Ports, Subnets, and Static Routes

Select the Session Builder tab..., select Reserve Ports and click Configure. A blank TS Ports, Subnets and Routes window opens. The Configure button is also available while the test is running.

NOTE: You may Reserve Ports, configure the Test Servers, Ports, Subnets, Routes and then add/edit new or existing test cases.

By default, the TS Ports, Subnets and Routes window opens in the Overrides Pane, Use Default Subnets and Routes mode that does not require or allow you to add/edit Subnets and Routes within the test session.

NOTE: The Test Session uses the Subnets and Routes defined during Test Server Configuration and reported to TAS and shown in Test Server Administration window.

On Test Server Administration window, reserved ports displays/indicated as R[ETHn], example, R[eth1]

Select Override Default Subnets and Routes from the dropdown list to enable custom assignments.

To provision Network Profiles:

<…> button will display list of provisioned Network Profiles that can be applied to the PHY on that row. The <…> button will only be enabled if at least 1 Network Profile has been provisioned on that Test Server.

Add Test Servers, Ports, and Static Routes.

Included Test Servers column

Click to Select the test server/servers from the A Select test Server to Add window. You may select multiple-select TSs to add.

Select Only TS in Test to show test servers in the test that are not already overridden.

NOTE: The Populate button automatically fills out the overrides based on current TS/TC configuration.

Ports-Subnets tab

Select Port from Add Port list and the relevant PHY-SUBNET based on the IP address for each PHY-SUBNET displays. You may Edit fields PHY, Starting IP Address, Mask and #Nodes by double clicking or F2 or by placing your cursor in that field and begin your edits. i.e to change the location of the Subnet From one port (eth2) to another (eth4), edit the PORT Name in field PHY by double clicking/F2 or placing your cursor in the field and perform the update (from eth2 to eth4).

Mask - If you want a CIDR (Classless Inter-Domain Routing Notation) Slash-mask, BIT Count, you must use a "/". CIDR notation is a compact representation of an IP address and its associated routing prefix. The notation is constructed from an IP address, a slash "/" character and a decimal number. If you want a normal 255.255.255.0 type mask, just enter the IP address.

You may use extra subnets if you need more than one subnet on a Ethernet port, i.e., two completely different ranges. Add a second or third instance of the port (for example eth4_1, eth4_2) and modify the IPs address and masks (the address of the newly added PHY cannot overlap other addresses on the PHYs)

The Configured Network Mask defines the number of IP addresses allowed as well as the starting and ending address of the port. You may provision any starting IP address from within the range of the interface address. You cannot overlap IP address ranges on the same physical port.

The system will validate the Starting IP Address, Mask and #Nodes provided. You will receive an error message if:

# of nodes > maximum allowed by the Mask
# of nodes > maximum allowed because the Starting IP Address is not first in the Subnet

To provision Network Profiles:

In the below example, profile1 was applied to eth1 for the Test Server: SIM Server:

NOTE:

You may configure a maximum of 5 subnets for each IP version on any given Port/PHY (that is, ethN thru ethN_4 and ethv6N thru ethV6N_4) and a total of 30 subnets on a TS Process.

Static Routes tab

Static Routes allows you to add static routes for a specific Test Server. Select the Static Routes tab and add Destination IP, Mask, and Gateway.

NOTE: You may configure a maximum of 30 subnets on any given TS Process.

For example, you may configure 60 subnets across 6 ports on one test server and split them between two or more TS Processes using the Reserving Test Server Processes window.

IMPORTANT:

If you add/change the IP address, mask, and # of nodes you must go back to each Test Case and pick/configure the new IP address, if you wish the newly added TS routes and PHY ranges to be used in the test session.
If you require additional physical interfaces for routing to a destination that is not on the same subnet as the Physical Test Port, you must add the interface using port reservation, open the test case, and then select it in the test from the Extra PHYs pull down menu.

NOTE:

If you configure PHYs on the TS Routes and PHY Ranges window but have not assigned a PHY within your test case, the PHY configuration will not be applied to or included with your test session. To apply/include PHY reservation configuration with your test, click Extra PHYs on the top right-hand side of your test case window and from the Pick Extra Phys to Associate window, select the relevant PHYs from the list.

If your Test Session does not include any Test Cases and you have used Reserve Port to configure Test Servers and Ports, add new/existing Test Case(s) from the Session Builder tab... and click Configure. See Steps below

If your Test Session includes Test Cases with previously assigned Test Servers and Ports, click Populate to display the Test Servers, Subnets and ports assigned in the Test Cases.

See Step 3 for a detailed description of the TS Ports, Subnets, and Routes window.

Included Test Servers column	Populates with the test servers used in the test cases.
Ports-Subnets tab	Populates with specific PHY-SUBNET based on the IP address for each PHY-SUBNET selected in the Test Case. In addition, for any Extra Phys or Forced Outbound Ports selected, the list populates with both the IPv4 and IPv6 PHY-SUBNETs for the Test Server, if available.
Static Routes tab	Static Routes allows you to add static routes for a specific test server. Select the Static Routes tab and add Destination IP, Mask, and Gateway.

Configure the test session according to your requirement and click the Optimize button to remove the PHYs/ports not used in the test session.

The action keeps any PHY-SUBNETS for any Extra or Forced Outbound Ports, leaving both the IPv4 and IPv6 + the extra subnets (for example, eth2_1, eth2_2, and so on).
The action removes PHY-SUBNETs when only used as a real node selection and an exact match is not found. A warning will display that indicates all PHY-SUBNETs that are provisioned in the test case but not configured (i.e. missing).

Click OK to save Overridden Port Configuration or Cancel to discard any changes.

Clicking OK ensures the Port Reservation Configuration is valid for the Test Case selected Ports/IPs.

NOTES:

The Test Cases turn RED if there are any mismatches between your Test Case configuration Port Reservation configuration.
You are required to edit both the Port Reservation Configuration and the Test Cases to ensure they are accurate (turns Green). Fixing only the Port Reservation does not fix the mismatch.
To quickly clear the test cases, if the Test Session has only one Test Case, open the Test Case and click OK. If there are more than one TC, open the Cross-Reference and click Save.

Select the Pre-Resolved ARP to add the Starting IP Address, #Nodes (Range: 1 to 999) , Outer VLAN ID (Range: 0 to 4094, where zero (0) indicates no VLAN) and select PHY from provided list.

Enter a list of IP addresses to be resolved before test case startup.

Select to Use Router Solicitation for IPv6 Network.

User configurable static ARP table.

Pre-Resolved ARP addresses will be created/deleted separately for each Test Case (TC) before the TC:start and TC:cleanup methods are called. The TAS knows which addresses go with each TC by knowing which Test Server (TS) and ETH Port the Address is associated with. If the ARP address does not have a port associated with it, it will apply to ALL TCs on the TS. If the ARP address include a port, then only TCs that use that port will use that ARP address.

Pre-Resolved ARP Real-Time Log Messages:

When starting a test, if a test server has any Pre-Resolved ARP addressed defined, each TC on the test server will report this informational message:

08/25 07:13:57.318:ts0(SharedHPvTS1):p0(0)::tc1: Creating Pre-Resolved ARP Ranges

If any IP addresses are matched to the test case to be pre-resolved (via the port assignment or lack thereof), they will be listed in this informational message:

08/25 07:13:57.319:ts0(SharedHPvTS1):p0(0)::tc1: TC Pre-Resolved ARP List: 10.203.1.5,10.24.1.1

If no IP addresses are matched to the test case, this informational message will be sent:

08/25 07:13:57.319:ts0(SharedHPvTS1):p0(0)::tc1: TC Pre-Resolved ARP List: None

When the TC is cleaned-up, before TC::cleanup is called, the same ARPed Addresses that were created will be deleted, and there will be just one informational message:

08/25 07:14:04.327:ts0(SharedHPvTS1):p0(0)::tc1: Deleting Pre-Resolve ARP Ranges

Examples:

If TS has Pre-resolved ARP and TC is associated with some:

08/25 07:13:57.246:ts0(SharedHPvTS1):p0(0)::tc1: Session Control Initialization...
08/25 07:13:57.246:ts0(SharedHPvTS1):p0(0)::tc1: Init Complete.
08/25 07:13:57.248:ts0(SharedHPvTS1):p0(0)::tc1: State=INITIALIZED
08/25 07:16:11.120:TAS: Executing s0001::tc1::startWrapper on ts0(SharedHPvTS1)
08/25 07:13:57.318:ts0(SharedHPvTS1):p0(0)::tc1: Creating Pre-Resolve ARP Ranges
08/25 07:13:57.319:ts0(SharedHPvTS1):p0(0)::tc1: TC ARP List: 10.203.1.5,10.24.1.1
08/25 07:13:57.319:ts0(SharedHPvTS1):p0(0)::tc1: Starting (capacity)...
08/25 07:13:57.320:ts0(SharedHPvTS1):p0(0)::tc1: State=STARTING
08/25 07:13:57.321:ts0(SharedHPvTS1):p0(0)::tc1: Pre-Resolving state ARP_INSTALLED with RS false
08/25 07:13:57.321:ts0(SharedHPvTS1):p0(0)::tc1: Starting Pre-Resolving ...

If TS has Pre-resolved ARP and TC is not associated with any:

08/25 07:16:11.121:1_DELAY
08/25 07:13:57.246:ts0(SharedHPvTS1):p0(0)::tc1: Session Control Initialization...
08/25 07:13:57.246:ts0(SharedHPvTS1):p0(0)::tc1: Init Complete.
08/25 07:13:57.248:ts0(SharedHPvTS1):p0(0)::tc1: State=INITIALIZED
08/25 07:16:11.120:TAS: Executing s0001::tc1::startWrapper on ts0(SharedHPvTS1)
08/25 07:13:57.318:ts0(SharedHPvTS1):p0(0)::tc1: Creating Pre-Resolve ARP Ranges
08/25 07:13:57.319:ts0(SharedHPvTS1):p0(0)::tc1: TC ARP List: None
08/25 07:13:57.319:ts0(SharedHPvTS1):p0(0)::tc1: Starting (capacity)...
08/25 07:13:57.320:ts0(SharedHPvTS1):p0(0)::tc1: State=STARTING

If no Pre-Resolved ARPS for the entire TS nothing is logged:

08/25 07:16:11.121:1_DELAY
08/25 07:13:57.246:ts0(SharedHPvTS1):p0(0)::tc1: Session Control Initialization...
08/25 07:13:57.246:ts0(SharedHPvTS1):p0(0)::tc1: Init Complete.
08/25 07:13:57.248:ts0(SharedHPvTS1):p0(0)::tc1: State=INITIALIZED
08/25 07:16:11.120:TAS: Executing s0001::tc1::startWrapper on ts0(SharedHPvTS1)
08/25 07:13:57.319:ts0(SharedHPvTS1):p0(0)::tc1: Starting (capacity)...
08/25 07:13:57.320:ts0(SharedHPvTS1):p0(0)::tc1: State=STARTING

If any addresses were ARPed during init , see messages about deleting them:

08/25 07:16:18.124:TAS: There was a test case error, aborting test
08/25 07:16:18.124:TAS: Switching to step CLEANUP
08/25 07:16:18.125:TAS:Test is finishing...
08/25 07:14:04.322:ts0(SharedHPvTS1):p0(0): Completing PCAP captures for eth3 eth2
08/25 07:16:18.142:TAS: Checking for PCAP files on ts0
08/25 07:16:18.142:ts0(SharedHPvTS1):p0(0): Entering TC cleanup
08/25 07:14:04.327:ts0(SharedHPvTS1):p0(0)::tc1: Deleting Pre-Resolve ARP Ranges
08/25 07:14:04.330:ts0(SharedHPvTS1):p0(0)::tc1: State=CLEANUP
08/25 07:14:04.333:ts0(SharedHPvTS1):p0(0)::tc1: Cleaning Up

Common error messages reported by the TS include :

08/25 07:13:57.319:ts0(SharedHPvTS1):p0(0)::tc1: WARNING: Cannot resolve Ip range with starting Ip 10.24.1.1/32 and following 1 more by process 0 - When the ARP address is not resolve-able.
08/25 07:14:03.323:ts0(SharedHPvTS1):p0(0)::tc0: ERROR: total 2 remote hosts are not resolvable with reserving processes disabled.
08/25 07:14:03.324:ts0(SharedHPvTS1):p0(0)::tc0: EXITING: Abort test when "Reserve Processes" is unchecked with previous error - When the Pre-resolve ARP address did not resolve the remote hosts, i.e. indication to use to set up correct pre-resolved ARPs for their remote Hosts they want to use.

After reserving ports you may assign a group of Test Cases to a particular virtual Test Server process and override the automatic assignment by TAS. See Assigning Virtual Test Server Processes.

NOTES:

Port Reservation cannot be used if a test is already running in normal mode without reserved ports.
A test not using reserved ports cannot be run on the same port if a test is running in reserved mode.
Loop back address is not available in Port Reservation mode.

NOTES: The following applies depending on whether a test is using Port Reservation with Override Phy-Subnets/Routes.

If using Overridden Phy-Subnets, when moving to a new TS, that new TS could already be defined, and the user has option to use those pre-defined Phy-Subnets or to copy the Phy-Subnets from the original TS.
If copying originals, if there is more than one source TS, only the last one encountered is used to override the target.
If not using Overridden Phy-Subnets, the only question is if the TestNode IP Addresses should be auto-selected based on the Target TS, or left alone for the user to fix.

NOTES: The following displays during test execution:

Port Reservation single port test displays R[eth2] and a message: TS is currently being used in reserved mode
Port Reservation full ports test displays R[eth2-eth9] and a message: TS is currently being used in reserved mode
Non-Port Reservation single port test displays [eth2] and a message: TS is currently being used in unreserved mode
Non-Port Reservation full ports test displays [eth2-eth9] and a message: TS is currently being used in unreserved mode

In addition, you may also view status on the Test Server Administrator window and System Status window, which indicates whether Port Reservation is used.