Several IP address within the same subnet on the same host

Yeah, sure, there's literally no problem doing this at all - might need to be a little careful how you setup you default gateway but it really isn't a problem at all. If fact time was when that's how you had to setup multi-site webservers (we're talking a long time ago).

There is a somewhat common problem with peoples expectations in this type of setup. With multiple addresses assigned on the same subnet like that typically all outgoing communication will appear to come from a single address.

So responses to incoming connections should be fine. Replies should come from the address that the incoming connection was made to. But if you expect some process, that will be making outgoing connections, to use a specific address other then the first then you will need to make sure that you can specifically configure the IP to bind too in the application.

I have a complicated set up somewhere that uses this type of network. I have two internal interfaces and an external interface to the Internet. (this is about to change to two external interfaces on different subnets and on internal interface split to two internal interfaces, but it's going along the same route) Anyways -- on to the answer!

let's say you have two internal interfaces at:

eth0 192.168.1.2
eth1 192.168.1.3

You use an internal uplink to the Internet (router) at 192.168.1.1

So your default routing table will look like (command: netstat -rn)

Dest            Gw         Genmask   Flags  ... ... Iface

0.0.0.0     192.168.1.1    0.0.0.0    UG           eth0

192.168.1.0  0.0.0.0     255.255.255.0 U           eth0

192.168.1.0  0.0.0.0     255.255.255.0 U           eth1

Here's your problem, all output will go via eth0 because it's the first hit on your routing table. So if you use another computer (or even this same box) to ping 192.168.1.3 (eth1) you will not get a response? Why? Because it's coming from 192.168.1.2.

You'll have to use iproute2 to set up individual routing tables for each device. This way when a device gets something on the INPUT chain it replies via the same device.

edit /etc/iproute2/rt_tables add:

1  my_eth0

2  my_eth1 

then execute the following:

ip route add 192.168.1.0/24 dev eth0 table my_eth0

ip route add default via 192.168.1.1 dev eth0 table my_eth0

ip route add 192.168.1.0/24 dev eth1 table my_eth1

ip route add default via 192.168.1.1 dev eth1 table my_eth1

Now add the rules for the tables to be used on by executing:

ip rule add from 192.168.1.2 table my_eth0

ip rule add from 192.168.1.3 table my_eth1

This will tell your system that when it gets a request on eth0 use the my_eth0 routing table to reply. When it gets a request on eth1, reply using the my_eth1 routing table. When you get the commands working put them in your /etc/rc.local file and make rc.local executable by performing sudo chmod u+x /etc/rc.local that way your routes are not wiped out when you reboot. Have fun!

No, this configuration is not recommended despite popular belief.

Having virtual interfaces (eg: eth1:1) in the same subnet that the physical one (eg: eth1) is a very common and useful configuration that pose no problem.

However, having different physical interface in the same subnet (or worst, in different subnets but in the same broadcast domain) can lead to issues due to non deterministic ARP entries. This applies at least to Solaris and Linux. If for some reason you need to do it anyway, it is recommended or required to tune the ARP behavior, i.e. disable ARP on one of the interfaces or configure ARP to limit its replies from a physical interface to its matching IP address(es). Look for arp_filter in http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt . Another way is to set the netmask to /24 on all but one of the interfaces.

On Solaris, a supported way to configure multiple interfaces on the same subnet would be to use IPMP (IP multipathing).

Finally, this restriction doesn't apply if the physical interfaces are not sharing the same IP stack (eg: Solaris exclusive IP zones) or are isolated by 802.1Q VLAN tagging.

It's perfectly fine, but doing it as you are - with more than one physical interface in the same subnet connected to the same switch - isn't recommended. Linux generally copes OK with it, but some OSes (eg Solaris) really don't like it.

Put all your addresses on one physical interface (eth0, eth0:0, eth0:1, etc.), and connect only that, If you want to connect multiple interfaces for performance, look into bonding, and then overload the bonded interface (bond0, bond0:0, bond0:1, and so on).

It is possible to do it. I used it before.

I have an application that needs to use different source IP addresses when connecting to a remote server. This is important in my case to overcome the limitation on the number of allowed connections per IP that was imposed by the remote server.

I configured multiple IP addresses on the same interface and my application was configured to use these IPs in round-robin fashion.

Yes this will work.

As hinted at in the other answers, the real purpose of doing this is for serving out different services on the different IP addresses.

If you had IIS and Apache on the same machine and you wanted to run them both on port 80, you'd need to set one on 10.0.0.1 and the other on 10.0.0.2 as they both couldn't serve on port 80 of the same IP address.

It really isn't much of a matter of routing as that would only come into play on that machine reaching out onto the network from generic programs like web browsers, ping, etc. In those situations, it is always going to be using the same address as it's source.

In the routing table, the route specifies the interface to use so it would be whichever address is tied to the qualifying route.

I'm going to throw out a bit of a caveat here. Namely, that the usual Linux tools will give you problems. They doesn't handle the multiple interfaces well at all. To do so, you'll have to use iproute2. That's a less common tool than the usual ifconfig/route method. Without it, you're going to see strange and incorrect behavior, like one NIC responding to the others traffic.


--Christopher Karel