Skip to main content

Linux Multi IP Setup: Assigning Multiple Addresses Safely

Created: April 24, 2026 Larry Qu 3 min read

Introduction

Assigning multiple IP addresses to a single Linux host is common in real infrastructure. You may need it for service isolation, migration windows, virtual hosting, or legacy compatibility.

The dangerous part is not adding the IP. The dangerous part is applying network changes remotely over SSH without a rollback plan.

This guide covers both modern and legacy methods safely.

Common Use Cases for Multiple IPs

  1. Hosting multiple services with separate IP-based ACLs.
  2. Migration from old IP to new IP without downtime.
  3. Temporary cutover or failover testing.
  4. TLS or legacy app binding requirements.
  5. Internal/external split addressing.

Fast Temporary Method (Runtime Only)

Use ip command for immediate changes that disappear after reboot.

# Add secondary IPv4 to interface
ip addr add 10.1.1.63/20 dev eth0

# Verify
ip addr show dev eth0

# Remove if needed
ip addr del 10.1.1.63/20 dev eth0

Use this for testing before writing persistent config.

Persistent Configuration by Platform

Linux networking stacks differ by distribution and generation.

1) Ubuntu with Netplan

# /etc/netplan/01-netcfg.yaml
network:
 version: 2
 ethernets:
  eth0:
   dhcp4: false
   addresses:
    - 192.168.0.33/24
    - 10.1.1.63/20
   gateway4: 192.168.0.1
   nameservers:
    addresses: [8.8.8.8, 1.1.1.1]

Apply carefully:

netplan try
netplan apply

Prefer netplan try first because it allows timed rollback if connectivity breaks.

2) RHEL/CentOS legacy ifcfg style

# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.0.33
PREFIX=24
GATEWAY=192.168.0.1

Secondary address file:

# /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=eth0:1
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.1.1.63
PREFIX=20

Note: alias format (eth0:1) is legacy. Newer systems prefer NetworkManager keyfiles or nmcli.

3) NetworkManager with nmcli (modern RHEL/Fedora)

nmcli connection modify "System eth0" +ipv4.addresses 10.1.1.63/20
nmcli connection up "System eth0"
nmcli device show eth0 | grep IP4.ADDRESS

Routing Considerations

Multiple IPs do not always require multiple gateways.

Rules:

  1. Usually keep one default gateway per routing table.
  2. Avoid adding different default gateways on same interface unless you know policy routing.
  3. If asymmetric routing appears, review source-based routing (ip rule, ip route).

DNS and Reverse DNS Considerations

If services are expected to resolve by each IP:

  1. Create A/AAAA records for each service hostname.
  2. Ensure reverse DNS if your providers and applications depend on it.
  3. Bind services to specific addresses where needed.

Example (Nginx):

server {
  listen 10.1.1.63:80;
  server_name app.example.com;
}

Safe Remote Change Procedure

When changing network config remotely:

  1. Keep current SSH session open.
  2. Open second SSH session before applying.
  3. Use runtime ip addr add test first.
  4. Validate reachability from external host.
  5. Only then persist configuration.

If your platform supports rollback (netplan try), use it.

Validation Commands

ip addr show
ip route show
ping -c 2 192.168.0.1
ss -tulpen

From another machine:

ping 10.1.1.63
curl -I http://10.1.1.63

Troubleshooting Checklist

If secondary IP does not respond:

  1. Confirm IP is assigned to correct interface.
  2. Confirm subnet mask/prefix is correct.
  3. Check firewall rules for that interface/IP.
  4. Check cloud security group/NACL if on cloud provider.
  5. Check service bind address (0.0.0.0 vs specific IP).

IPv6 Note

Everything in this article has IPv6 equivalents using ip -6 and distribution-native config. If your environment supports dual stack, explicitly validate both protocols.

Conclusion

Multi-IP setup on Linux is straightforward technically, but operational safety is what matters. Start with temporary runtime assignment, validate externally, then persist with your distro’s native tooling.

Never apply network changes blind on production SSH sessions without a rollback plan.

Resources

Comments

Share this article

Scan to read on mobile