One of things which people often asked me around in past was on how to have multiple IPs on Linux machine under various circumstances. I know there are ton of blog posts about this but very few explain how it works and possible options under different use cases etc.
I will share router side and server side config with focus on how it should be done from server end. Assuming server side config to be for Ubuntu/Debian. You can find similar concept for CentOS.
Say you have a router on IP 10.10.10.1 and server on IP 10.10.10.2 on a /24 (255.255.255.0) subnet. Assming that entire 10.10.10.0/24 is available for server’s connectivity. Setup would be like:
Configuration so far is super simple. You have got 10.10.10.1 placed on R1’s interface (g1/0) which connects to server01 and server01 has 10.10.10.2.
R1#sh run int g1/0
Building configuration...
Current configuration : 127 bytes
!
interface GigabitEthernet1/0
description ***Link to server01***
ip address 10.10.10.1 255.255.255.0
negotiation auto
end
R1#
and on server’s config is:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
#iface eth0 inet dhcp
#iface eth0 inet6 auto
iface eth0 inet static
address 10.10.10.2
netmask 255.255.255.0
gateway 10.10.10.1
Now let’s say you want to add additional IP’s to the server. There can few ways:
- You may add more IP’s from this same pool i.e un-used IP’s from within 10.10.10.0/24.
- You may add more IP’s from all together different pools say from 192.168.1.0/24.
When adding new IP’s/additonal IPs to server, you must understand that they would be either via layer 2 (i.e those IP’s will generate ARP packets on the interface connected to the router) or would be layer 3 i.e routed IP’s which are routed “behind” an existing working IP (like 10.10.10.2) in this case. Another case you can have is additonal IP’s which are eventually NATTed behind public IPs which I will also discuss in the end.
Layer 2 based addition
When IP’s are from layer 2 – they are are supposed to be present on the interface so that they reflect in ARP and hence machines on the LAN do IP to MAC conversion and route packets destination for those IPs. Currently connected interface here is eth0 and hence new IP’s should be eth0 only. Thus you can add those IP’s by creating so called “alias interface”. eth0 can have eth0:1, eth0:2 etc as alias. IP’s can also be added on same single eth0 interface.
Since entire pool is available for use between R1 and server01, this doesn’t needs any change at R1 end. On server end, we can add IP as:
Temporary addition (will get removed after reboot):
anurag@user-1:~$ sudo ip -4 addr add 10.10.10.3/24 dev eth0
[sudo] password for anurag:
anurag@user-1:~$
anurag@user-1:~$
anurag@user-1:~$ sudo ip -4 addr add 10.10.10.4/24 dev eth0
anurag@user-1:~$
So there we go – two IP’s added on eth0 itself.
anurag@user-1:~$ sudo ip -4 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 10.10.10.2/24 brd 10.10.10.255 scope global eth0
valid_lft forever preferred_lft forever
inet 10.10.10.3/24 scope global secondary eth0
valid_lft forever preferred_lft forever
inet 10.10.10.4/24 scope global secondary eth0
valid_lft forever preferred_lft forever
anurag@user-1:~$
Let’s try to ping them from router:
R1#ping 10.10.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/43/48 ms
R1#ping 10.10.10.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/42/48 ms
R1#
And so it works. Now, if we examine ARP table for g1/0 interface of router (which connects to server01) we will find all these three IP’s which are in use by server.
R1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.10.2 14 0800.2787.d567 ARPA GigabitEthernet1/0
Internet 10.10.10.3 1 0800.2787.d567 ARPA GigabitEthernet1/0
Internet 10.10.10.1 - ca01.349f.001c ARPA GigabitEthernet1/0
R1#
Another way of doing same thing is by creating alias interface and adding IP’s on it. So we can add following in the /etc/network/interfaces:
auto eth0:1
iface eth0:1 inet static
address 10.10.10.3
netmask 255.255.255.0
auto eth0:2
iface eth0:2 inet static
address 10.10.10.4
netmask 255.255.255.0
Being those interfaces up using: ifup eth0:1 and ifup eth0:2. A logical question – where to put gateway often comes up and confuses. Keep in mind as of now all IP’s are coming from same single device R1 and IP at R1 end is 10.10.10.1 and hence single gateway in eth0 config is good enough to ensure that traffic to any IP outside 10.10.10.0/24 pool can be routed via 10.10.10.1. Let’s say you want to add IP from a completely different pool (for some reason) on server like 192.168.1.0/24. Here you can do it via layer 2 by first defining an IP as secondary on R1 and add IP as alias on the server.
R1#sh run int g1/0
Building configuration...
Current configuration : 175 bytes
!
interface GigabitEthernet1/0
description ***Link to server01***
ip address 192.168.1.1 255.255.255.0 secondary
ip address 10.10.10.1 255.255.255.0
negotiation auto
end
R1#
On Server01 end:
auto eth0:1
iface eth0:1 inet static
address 192.168.1.2
netmask 255.255.255.0
This simply ensures that both R1 and Server01 get in single broadcast domain which has broadcast address 192.168.1.255 and hence can speak to each other. Again, in this case as well on router end – router gets ARP for IP and that tells how to reach. ARP table (IP to MAC address conversion) and forwarding of packets based on Mac (Mac table: Mac >> Interface conversion).
R1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.10.2 0 0800.2787.d567 ARPA GigabitEthernet1/0
Internet 10.10.10.1 - ca01.349f.001c ARPA GigabitEthernet1/0
Internet 192.168.1.1 - ca01.349f.001c ARPA GigabitEthernet1/0
Internet 192.168.1.2 0 0800.2787.d567 ARPA GigabitEthernet1/0
R1#
Another way of layer 2 setup can be by either patching an un-used extra port and have separate network on it (separate IP / subnet mask). You can also have a setup where you send tagged VLAN till server and untag it on the server. I will put blog post about it later on.
Layer 3 based addition
Due to scalability as well as scarcity of IPv4 address issue, layer 2 based method isn’t the best one when it comes to adding of additional IP’s. Layer 3 setup is simply where additional IP’s are “routed” behind a working single public IP.
So e.g thought it’s better to use /30 for P2P (infact /31!) but let’s keep same case going. We have 10.10.10.1 on R1 and 10.10.10.2 on Server01 and both are in /24. Now to allocate say 10.10.10.3 to server, we can route this IP behind 10.10.10.2.
So setup on R1:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip routing
R1(config)#ip route 10.10.10.3 255.255.255.255 10.10.10.2
R1(config)#end
R1#wr
Building configuration...
*Aug 21 19:21:53.495: %SYS-5-CONFIG_I: Configured from console by console[OK]
R1#
This will ensure that all packets going towards 10.10.10.3/32 (single IP) are routed to 10.10.10.2 which is on server01. Next, we can add this IP on existing loopback interface lo or a new alias of loopback as lo:1.
ip -4 addr add 10.10.10.3/32 dev lo for temporary addition (removed after reboot) and
auto lo:1
iface lo:1 inet static
address 10.10.10.3
netmask 255.255.255.255
R1#ping 10.10.10.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/43/48 ms
R1#
So how exactly this works? It’s important to understand it as it explains key difference between IP’s added on interface Vs IP’s routed. Let’s see “sh ip route” output for 10.10.10.2 and 10.10.10.3:
R1#sh ip route 10.10.10.2
Routing entry for 10.10.10.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet1/0
Route metric is 0, traffic share count is 1
R1#sh ip route 10.10.10.3
Routing entry for 10.10.10.3/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.10.10.2
Route metric is 0, traffic share count is 1
R1#
Here clearly there’s a “directly connected route” 10.10.10.2 while for 10.10.10.3 there’s a static route towards 10.10.10.2.
Some of key comparison point layer 2 Vs layer 3 based setup:
- With layer 3 method you can have as many IP’s as want on server without getting into CIDR cuts. So e.g if you want to add entirely new pool to server, you would need at least 2 IP’s (a /31). If you want just 3 IP’s then you would need a /29 (consuming 8 IPs) and so on. This approach has issue as it wastes lot of IPs and that becomes critical when we are almost out IPv4. In IPv6 that’s no issue at all.
- With layer 3 you can have a setup where addition of IP’s doesn’t really creates any layer 2 noise (ARP packets). So e.g you can use just 10.10.10.0/31 and then route entire 192.168.1.0/24 behind server. This will ensure that server can use 192.168.1.0/24 without generating any ARP for it and router will just have one single routing table entry for that enture /24. ARP would be just for single IP which is used to connect R1 with the server.
I hope this will help you !
