IP Aliasing: Assigning Multiple IPs to One Network Card

One Physical NIC, Multiple IP Identities

A network interface card (NIC) is a physical piece of hardware. The IP address assigned to that NIC is a logical configuration. The distinction matters because nothing about the hardware prevents you from assigning multiple IP addresses to the same physical card — the operating system is perfectly capable of binding multiple addresses and responding to traffic destined for any of them.

This is IP aliasing: the configuration of additional IP addresses on a single physical network interface. Each additional address behaves as a fully functional IP — it can accept inbound connections, send outbound traffic with itself as the source, and be bound to specific applications or services. The physical cable into the server carries traffic for all configured IPs without distinction.

IP aliasing is not a hack or a workaround. It is a standard, well-supported feature of Linux networking used in production environments ranging from shared web hosting to high-availability database clusters. Understanding how to configure and manage it correctly is a fundamental sysadmin skill.

How IP Aliasing Works at the OS Level

In Linux, network configuration is managed by the kernel's networking stack. The kernel maintains a routing table that maps destination IP prefixes to outgoing interfaces. When you assign an IP address to an interface, the kernel adds a route for that address and begins listening for ARP requests for it.

With IP aliasing, the kernel simply adds another IP address to the same interface's address list. From the hardware's perspective, nothing changes — the NIC still has one MAC address and sends/receives frames on one physical medium. But the kernel now responds to ARP requests for multiple IP addresses, all mapping to the same MAC. Inbound packets destined for any of the configured IPs are accepted and passed up the network stack. The kernel's routing logic then hands them to whichever application is bound to the socket matching that destination IP and port.

Legacy Method: eth0:N Aliases

The traditional Linux approach (still supported on most distributions) uses virtual interface aliases named with a colon notation. The primary interface might be eth0, and aliases are named eth0:0, eth0:1, eth0:2, and so on. Each alias appears as a separate interface in ifconfig output and can be brought up or down independently.

To add an alias temporarily:

ifconfig eth0:1 192.168.1.100 netmask 255.255.255.0 up

This method works but is considered legacy. The ifconfig tool has been superseded by ip from the iproute2 package, and the colon alias notation does not map cleanly to iproute2 concepts.

Modern Method: iproute2 Secondary Addresses

With iproute2, IP aliasing is handled by adding secondary addresses directly to an interface:

ip addr add 192.168.1.100/24 dev eth0

This adds the address as a secondary address on eth0. You can view all addresses with ip addr show eth0. To make this persistent across reboots, add the configuration to your distribution's network configuration files:

• Debian/Ubuntu (Netplan): Add additional addresses in the addresses list in the YAML configuration file under /etc/netplan/.
• RHEL/CentOS/AlmaLinux: Create a separate interface config file named ifcfg-eth0:1 in /etc/sysconfig/network-scripts/ with DEVICE, IPADDR, PREFIX, and ONBOOT fields.
• systemd-networkd: Add multiple Address= lines in the [Network] section of the .network file.

Architecture and Components

Real-World Use Cases

Virtual hosting with IP-based SSL: Before Server Name Indication (SNI) became universal, HTTPS required a dedicated IP address for each SSL certificate because the TLS handshake occurs before the HTTP Host header is sent. A single web server could host dozens of HTTPS sites by assigning one IP alias per site and binding each Apache VirtualHost or Nginx server block to its dedicated IP. Even today, some older clients do not support SNI, making dedicated IPs necessary for full compatibility.

High-availability clustering with floating IPs: In active-passive HA configurations using tools like keepalived or Pacemaker/Corosync, a virtual IP (VIP) is the address that clients connect to. Normally, this VIP is configured as an alias on the primary server. When the primary server fails, the cluster management software removes the alias from the failed node and adds it to the standby node. From the client's perspective, the IP address never changes — only which physical server holds it does. This is IP aliasing at the core of production high-availability architecture.

Multi-tenant network isolation: A server providing services to multiple customers can bind each customer's service to a dedicated aliased IP. This allows precise firewall rules, separate logging per IP, and the ability to migrate specific customer services by simply moving which server holds the aliased IP, without changing any client-side configuration.

Service migration and maintenance: During a server migration, you can add the old server's IP as an alias on the new server, test it thoroughly, then remove it from the old server. Traffic transparently shifts to the new hardware without DNS TTL propagation delays.

Multiple routing tables: In advanced configurations involving policy-based routing, separate routing tables can be associated with different source IP addresses. This allows a server with multiple aliased IPs to route traffic from different source IPs through different gateways — useful for multi-homed servers connected to multiple ISPs.

Comparison: IP Aliasing vs. Related Techniques

Common Misconceptions

IP aliasing requires multiple physical network cards

This is entirely false. IP aliasing is specifically the technique of assigning multiple IPs to a single physical NIC. If you have multiple NICs, each can independently have its own set of aliases, but the aliasing itself is purely a software/OS configuration. The physical hardware is not involved in the distinction between primary and secondary addresses.

All traffic on aliased IPs shares the same bandwidth

Yes — and this is by design, not a limitation. All aliased IPs share the physical link capacity of the single NIC. This is generally not a problem because a server's network bottleneck is rarely the NIC capacity itself (modern server NICs handle 1-25 Gbps). If you genuinely need isolated bandwidth guarantees per IP, you need separate NICs with traffic shaping, not aliasing.

Adding an IP alias automatically routes return traffic correctly

Not always. In multi-homed environments or when the aliased IP is on a different subnet than the primary, you may encounter asymmetric routing issues where return traffic uses the wrong source IP or wrong gateway. This requires configuring additional routing rules using ip rule and ip route with separate routing tables — one per source IP — to ensure that return traffic from each aliased IP uses the correct gateway.

IP aliasing and virtual machines are the same thing

A virtual machine has its own virtual NIC and its own OS networking stack, appearing as a completely separate host on the network. IP aliasing is a configuration on a single OS instance where multiple IPs share one NIC and one networking stack. They solve different isolation problems. IP aliasing keeps everything in one OS context; virtual machines provide full OS-level isolation.

Pro Tips

• Use ip addr instead of ifconfig for all alias management on modern Linux systems. The iproute2 toolset handles secondary addresses more cleanly and is the actively maintained standard. ifconfig is legacy and missing on minimal installs of current distributions.
• Set arp_announce=2 and arp_filter=1 on servers with IP aliases used in load balancing configurations. Without these kernel parameters, a server may respond to ARP requests for IPs on the wrong interface, causing traffic routing issues in LVS (Linux Virtual Server) and similar setups.
• For keepalived virtual IPs, configure the VIP with a /32 prefix on the interface (not the subnet prefix) and let the parent interface handle subnet routing. This prevents the alias from generating conflicting route entries and makes VIP transitions cleaner.
• Test alias reachability from a remote host after configuration — do not just test locally. ARP behavior differs between loopback and external interfaces, and a locally pingable alias may not be reachable from outside the server if ARP responses are not configured correctly.
• Document all IP aliases with purpose and owner. On servers that accumulate aliases over time (common in virtual hosting environments), it is easy to lose track of which aliased IPs are still in use. An undocumented alias may be silently accepting traffic for a decommissioned service. Audit alias configurations in your change management process.
• When migrating a service, add the alias first, verify, then remove from the old server — never the reverse. Removing the IP from the old server before the new server is confirmed working causes downtime. The brief period where both servers respond to ARP for the same IP is acceptable on the same subnet and resolves naturally once the old server's alias is removed.

IP aliasing is a compact, hardware-efficient technique with a wide range of legitimate production applications. Whether you are running a shared hosting environment, building a high-availability cluster, or managing service migrations without DNS TTL delays, understanding how to configure and troubleshoot secondary IP addresses is a core Linux networking competency. Inspect your server's responding IP addresses here.