Soumya Y Shanthimohan 270004GAQS Visits (1342)
What is an IP alias
IP aliasing is associating more than one IP address to a network interface.
IP aliasing in RPT
By default, when you run a schedule, each virtual user has the same IP address. However, you can make each virtual user appear as though it is running on its own host. To do this, you configure IP aliases on the host computer (RPT workbench), and enable IP aliasing in the schedule. When you run the schedule, the network traffic will appear to be generated by multiple hosts.
To avoid IP conflicts, the IPs have to be legitimate, available within the same subnet, and blocked for distribution.
Configuring IP aliases for a remote Windows location
To make it appear that a virtual user has its own IP address during a schedule run, configure IP aliases for each Windows remote location.
Now, when you run the schedule, it will give the impression that the network traffic is being generated from multiple hosts.
Note: To add multiple IP aliases, use the netsh command, as shown in the following example:
The ntcmds.chm file, typically located in C:\WINDOWS\Help, contains more details about the netsh command. When you are finished with the IP aliases, use the following command to remove them:
You can also use a batch file to add and delete the aliases.
Enabling virtual users to use IP aliases
After you have configured aliases at on remote computers, you set the schedule so that the virtual users can use the configured IP aliases.
To set the schedule so that the virtual users will use the IP aliases during a run:
Assignment of IP addresses for each virtual user in RPT
When IP aliases is enabled, it is expected that each virtual users have unique IP address available in order to emulate unique virtual users. However in some circumstances the number of IP address available may be less than the number of virtual users.
The answer to this is, when the location has IP aliasing enabled, RPT will ask the agent computer how many IP addresses it has available. It is up to you to have already configured the computer with these IP addresses. By default, RPT will use all IPv4 (but not IPv6) address available. You can also restrict the selection to IP addresses on particular interfaces.
If there are more virtual users on the location than there are IP addresses (which would normally be the case), RPT will distribute the virtual users evenly (more or less) across the available IP addresses. For example, if your location has IP addresses 192.22.22.02, 192.22.22.03, and 192.22.22.04 and you ran 10 users on the location, you would have a distribution similar to:
192.22.22.02: Users 1, 4, 7, 10
192.22.22.03: Users 2, 5, 8
192.22.22.04: Users 3, 6, 9
Identifying the originating IP address for each Virtual Tester
By default, when you run multiple Virtual Testers the originating IP address will be the IP address of the system hosting the individual Virtual Tester. However, RPT does have a feature (IP Aliasing) that allows you to assign a specific set of IP addresses per Virtual Tester (See the topic ‘Emulating network traffic from multiple hosts’ in RPT online help). If you have IP aliasing set up, there are two ways to verify the originating IP address.
You can see the IP address that a virtual Tester is using by setting the Test Log level of your schedule to ‘All’ and then checking the Extended Properties of a request in the Test Log after a playback. The originating address of the virtual user will appear as the "Local IP Address".
Alternatively, there is a custom code class outlined in the RPT online help (Extending Rational Performance Tester Functionality -> Custom Code Examples -> Retrieving the IP address of a Virtual user) that you can add to your test/schedule that will obtain the IP address
AcdntlPoet 2700019V2G Visits (1335)
Getting to know the Rational Client Support process- This is an introduction to the IBM Rational Client Support process. Topics include contacting support and addressing PMR severity.
AcdntlPoet 2700019V2G Visits (1334)
As a welcome to the new year, we've just released th IBM Technical Support mobile app for Android which is now available via Google Play!
You can use this mobile app to:
The IBM Technical Support mobile app provides a new way for you to get quick, effective product technical support assistance from IBM. Check it out by downloading it from
AcdntlPoet 2700019V2G Visits (1334)
Make an App for that with Bluemix- Are the needs for new business apps outstripping your enterprise's ability to deliver? Is the business asking for: simple mobile apps based upon existing systems? Situational apps for their department? Simple B2B apps to streamline collaboration and information sharing with customers, suppliers, or partners?
GRUC Webcast on August 21: What's in your (e) Wallet? Transforming payments and transactional capabilities.
JackSchneiderCO 270007HB0G Visits (1334)
Date & Time: August 21, 2014, 011:00 AM to 12:00 PM (Eastern Daylight Time)
LIVE TWEETING DURING THE WEBCAST! USE #GRUCPAYMENTS TO FOLLOW AND SUBMIT QUESTIONS AND COMMENTS TO OUR SPEAKERS.
Payments and transactional services present multiple ‘moments of truth’ for demanding clients who are often interacting with us anytime and anywhere. For financial services organizations, the 24/7 nature of the industry and its intense competition have made innovation and optimization of these capabilities critical. In this session, you will learn about the experiences of IBM clients in transforming their payments and transactional services with IBM Rational DevOps capabilities.
Learn how banks, brokerages and insurance firms are aligning the life cycles of legacy back offices with the agile sprints of the mobile payments development shops and value-added technology partners.
Bruce Baron, Financial Services Sector Offerings Leader, IBM
Peter Eeles, Financial Services Sector Industry Lead, IBM Rational Worldwide Tiger Team, IBM
***Dial in codes will be sent a few minutes before the webcast and posted in the online meeting. Please check your email before 12:00 EDT (sender is info