Skip to content

IP Aliasing (Multiple IP Addresses)

Problem: Your application routes traffic based on client IP address (e.g., load balancer uses source IP for session affinity), and all virtual users originating from a single IP address causes incorrect behavior or unrealistic load distribution.

When You Need IP Aliasing

This is a rare configuration. Most applications don't care about client IP addresses. Do not set up IP aliasing unless you are certain it's required.

You'll know you need IP aliasing if:

  • Load balancer routes by source IP and all virtual users hit the same backend server (instead of distributing across servers)
  • Application limits concurrent sessions per IP and virtual users get blocked
  • Geographic routing uses IP address and you need to simulate users from different locations
  • Security rules rate-limit by IP and single-IP testing triggers those limits

Consult with your network administrator before proceeding. Incorrect IP configuration can render your computer inoperable.

How IP Aliasing Works

By default, all virtual users originate from the same IP address (the controller's primary network adapter). This works fine for 99% of applications because web servers don't care about source IP; they only care about HTTP headers, cookies, and session state.

With IP aliasing enabled, you configure your operating system to create virtual network interfaces, each with its own IP address. During a load test, Load Tester assigns each virtual user a different IP address from the pool of available interfaces. If you have more virtual users than IP addresses, multiple users share IPs (round-robin).

Example:

  • Without IP aliasing: 100 virtual users all originate from 10.0.0.100
  • With IP aliasing (5 IPs configured): 100 virtual users split across 10.0.0.100, 10.0.0.101, 10.0.0.102, 10.0.0.103, 10.0.0.104 (20 users per IP)

Two-Step Configuration Process

IP aliasing requires TWO separate configurations:

  1. Operating System configuration (create virtual network interfaces at the OS level)
  2. Load Tester configuration (tell Load Tester which IP addresses to use)

You must complete BOTH steps for IP aliasing to work.

Step 1: Operating System Configuration

This step is dangerous. Incorrect network configuration can break your network connectivity entirely. Work with your network administrator to obtain valid IP addresses and subnet masks before proceeding.

IP address requirements:

  • Must be on the same subnet as your primary network adapter (same network, different host)
  • Must be UNUSED by other machines on the network (duplicate IPs cause conflicts)
  • Must be STATIC (not DHCP-assigned); IP aliasing doesn't work with DHCP
  • Consult your network administrator to reserve a block of IPs for load testing

Typical configuration: Reserve 5-10 IP addresses on your test network (e.g., if your primary IP is 10.1.1.100, reserve 10.1.1.101 - 10.1.1.110).

Windows Configuration

Step 1: Open Network Connections:

  • Right-click: My Network Places (on the Desktop)
  • Or: Start → Control Panel → Network and Dial-up Connections

Step 2: Edit Network Adapter Properties:

  • Right-click your Local Area Connection (NOT VPN, ISDN, or dial-up, as those don't support IP aliasing)
  • Select: Properties

Step 3: Configure TCP/IP:

  • Select: Internet Protocol (TCP/IP) from the list
  • Click: Properties button

Step 4: Verify Static IP Configuration:

  • Ensure "Use the following IP address" is selected (NOT "Obtain an IP address automatically" via DHCP)
  • If using DHCP, IP aliasing won't work. You must configure a static IP first (consult your network admin)

Step 5: Open Advanced TCP/IP Settings:

  • Click: Advanced button

Step 6: Add Virtual IP Addresses:

  • In the IP addresses list, you'll see your primary IP address
  • Click: Add button
  • Enter:
  • IP address: The virtual IP to add (e.g., 10.1.1.101)
  • Subnet mask: Usually the same as your primary IP (e.g., 255.255.255.0)
  • Click: OK to add the IP
  • Repeat for each additional IP address you want to configure

Step 7: Save and Apply:

  • Click: OK on all dialogs to save changes
  • Restart the network adapter (or reboot) to activate the new IPs

Verification:

ipconfig /all

You should see multiple IP addresses listed for your Local Area Connection.

Linux/UNIX Configuration

Using ifconfig (temporary, does not survive reboot):

# Add a virtual interface with IP 10.1.1.101
sudo ifconfig eth0:0 10.1.1.101 netmask 255.255.255.0

# Add more virtual interfaces
sudo ifconfig eth0:1 10.1.1.102 netmask 255.255.255.0
sudo ifconfig eth0:2 10.1.1.103 netmask 255.255.255.0

Verification:

ifconfig

You should see eth0:0, eth0:1, eth0:2 interfaces listed.

Permanent configuration (survives reboot):

  • Red Hat/CentOS/Fedora: Create files /etc/sysconfig/network-scripts/ifcfg-eth0:0, ifcfg-eth0:1, etc.
  • Debian/Ubuntu: Edit /etc/network/interfaces to add virtual interfaces
  • Or: Add ifconfig commands to /etc/rc.local startup script

Consult the Linux Network Administrators Guide or your distribution's documentation for permanent configuration details.

Step 2: Load Tester Configuration

After configuring virtual IPs at the OS level, you must configure Load Tester to use those IPs during load testing.

Configuring the Local Workstation

To configure IP aliasing on the controller:

  1. Navigate to: Window → Preferences → Load Tester → IP Aliasing
  2. You'll see: A list of all IP addresses available on your system (primary + virtual IPs you just configured)

Default behavior: Load Tester uses "Use OS Default", which selects the primary network adapter automatically.

To enable IP aliasing:

  1. Select: "Use Selected Interfaces"
  2. Check the boxes next to the IP addresses you want virtual users to use
  3. Uncheck any IP addresses you want to exclude (e.g., wireless adapters, VPN connections)
  4. Click: Apply and OK

Example:

  • Your system has 5 IPs: 10.1.1.100 (primary), 10.1.1.101, 10.1.1.102, 10.1.1.103, 10.1.1.104 (virtual)
  • Check all 5 to allow virtual users to use any of these IPs
  • Uncheck wireless IP (192.168.1.50) if you don't want virtual users using Wi-Fi

Result: During load testing, each virtual user is assigned one of the selected IPs (round-robin).

Configuring Remote Engines

If you use remote engines, you must configure IP aliasing separately for each engine (OS-level configuration happens on each engine machine, Load Tester configuration happens via the Engines View).

To configure IP aliasing for a remote engine:

  1. Perform OS-level configuration on the remote engine machine (follow Windows or Linux steps above)
  2. In Load Tester, open: Engines View
  3. Select the engine you want to configure
  4. Click: Configure IPs button (toolbar)
  5. A dialog appears showing the engine's available IP addresses (Load Tester queries the engine to get this list)
  6. Select: "Use Selected Interfaces"
  7. Check the boxes next to the IPs you want the engine to use
  8. Click: OK

Repeat for each remote engine.

Verification

To verify IP aliasing works:

  1. Run a small load test (5-10 virtual users)
  2. Monitor server logs or load balancer logs to see source IP addresses
  3. Expected result: You should see requests coming from multiple IP addresses (not just one)

If all requests still come from a single IP:

  • Verify OS-level configuration (run ipconfig or ifconfig to confirm virtual IPs exist)
  • Verify Load Tester configuration (Use Selected Interfaces is selected, not Use OS Default)
  • Restart Load Tester after changing IP Aliasing preferences

Troubleshooting IP Aliasing

Virtual Users Still Use Single IP

Symptom: Server logs show all requests coming from the same IP address despite configuring multiple IPs.

Likely causes:

  1. Load Tester not configured to use the virtual IPs (still using "Use OS Default")
  2. Virtual IPs not checked in the IP Aliasing preferences
  3. OS-level configuration failed (virtual IPs don't actually exist at the OS level)

Solution:

  • Check Preferences: Ensure "Use Selected Interfaces" is selected and the desired IPs are checked
  • Verify OS config: Run ipconfig (Windows) or ifconfig (Linux) to confirm virtual IPs exist
  • Restart Load Tester: IP Aliasing preferences only take effect after restart

Network Connectivity Lost After Configuring Virtual IPs

Symptom: After adding virtual IPs at the OS level, you lose network connectivity (can't browse the web, ping other machines, etc.).

Likely causes:

  1. Incorrect subnet mask (doesn't match your network)
  2. Duplicate IP address (another machine on the network already uses one of the IPs you configured)
  3. Gateway or DNS settings corrupted during configuration

Solution:

  • Remove virtual IPs immediately: Reverse the OS-level configuration steps
  • Verify IP addresses with network admin: Ensure the IPs you're using are valid and unused
  • Double-check subnet mask: Must match your primary IP's subnet mask
  • If you can't recover, restore network settings from backup or contact IT support

This is why we told you to consult your network administrator before configuring IP aliasing.

Remote Engines Don't Use Custom Configuration

Symptom: IP aliasing works on the controller but not on remote engines.

Likely causes:

  1. IP aliasing not configured per-engine (each engine needs its own configuration)
  2. OS-level configuration missing on the engine (virtual IPs don't exist on that machine)
  3. Engine version mismatch (older engines may not support some configuration options)

Solution:

  • IP aliasing requires per-engine configuration: Use Engines View → Configure IPs for each engine
  • Verify OS config on the engine: Run ipconfig / ifconfig on the engine machine to confirm the virtual IPs exist
  • Verify engine version: Ensure all engines match the controller version
  • Check engine logs: Remote engine logs may show configuration errors

Ask the AI About IP Aliasing Requirements

If you're unsure whether you need IP aliasing or how to configure it:

My load balancer routes traffic based on source IP, and all my virtual users
are hitting the same backend server. Do I need IP aliasing? How do I configure
it safely?

The AI can:

  • Determine whether your scenario actually requires IP aliasing (most don't)
  • Explain the risks and prerequisites before you start
  • Guide you through safe OS-level configuration
  • Generate the exact commands for your operating system
  • Configure Load Tester's IP Aliasing preferences
  • Troubleshoot connectivity issues after configuration
  • Suggest alternatives (e.g., testing with diverse session cookies instead of IPs)