Description
This is similar to this question, but different:
Linux computer has two NIC. eth0
is statically assigned with an IP. eth1 is assgiend by personnel in the field which could be same IP or different IP. The plan is for eth0
and eth1
to be on different network, and never exchange or bridge any packets. And my Linux application only listens and accepts connection on eth0
and eth1
, and start sending packets upon receiving, but never try to initiate any activity.
Question
Can two NIC have IP in same subnet: 192.168.1.4
and 192.168.1.5? As you can see eth0
and eth1
are assigned to be in same subnet (255.255.255.0
) but they are not connected and are not supposed to be connected.
In this case, when the application listens on eth0
port 55555
, accepts connection and returns packet back, does the underlying layer knows it should return to eth0? Or will it possibly try eth1
since the OS thinks it is on same subnet? Is there anything I need to do to the routing table to make sure it doesn’t think that these two NICs are actually on the same subnet?
Should I avoid not only similar IPs but also same subnet in this case?
Update
What if PC0 and PC1 have same IP?
PC0 (1.100) <-------> [eth0 (1.4) My System eth1 (1.5)]<-------PC1(1.100)
My application needs to listen on port 55555 on eth0, and eth1, and a request comes in through eth1, can the OS knows to reply go through eth1? Will this configuration cause a problem?
The business case is I am building this embedded system, and I pre-define the IP for eth0 and PC0 (PC0 could be DHCP as well). But my customer already has a network on the right side. What if they have a device which conflicts with either PC0 or eht0? Even with DHCP server on the eth0, there is no way to exclude the IPs on the right side when assigning IP to PC0. If this creates problems, I have many solutions. But I would like to hear peer opinions whether it is a problem.
Two of my colleagues think it is not a problem. My opinion is that the IP layer doesn't know which interface to use to reply a packet even using a socket (assume bind to right side). It will just pick one no matter how we set up the routing table.
Best Answer
Yes, you can. Your computer will send return packets out whichever interface is associated with the route to the destination network.
In likelihood, the destination network is contained within the default route - 0.0.0.0/0, through the default gateway.
Don't believe me ?
Let's examine :
Two interfaces, eth0 and eth1, with IP addresses & mask as in your question.
Full start-up config :
Note that different gateway addresses are set for each - .1 and .2.
Now let's look at the routing table :
Looks like only one default route has been chosen - out eth0 for whatever reason (I don't know, but I assume because it's the lower-numbered NIC), but using the gateway .2. Perhaps because it was the latter gateway statement ? Hell if I know.
Let's see what the kernel considers the appropriate route for a given public-address destination, sourced from either local IP address :
As we'd expect from "default ... dev eth0", packets destined to the public IP address will exit eth0.
Note it doesn't matter what the source IP address is.
Let's check to be sure though !
We'll sniff both eth0 and eth1 while we ping from either interface and either source address.
First, ping using eth0's IP address as the source (.4) :
Looks good - consistent with our routing table !
Nothing is seen on eth1 (the second summary) as we'd expect.
Now let's ping from source .5 (belonging to eth1) :
See how even though the source address of the pings was set to eth1's IP address, the packets left eth0 ?
But!, we can specify to ping from a source interface rather than a source address.
Specifying eth0 works as you'd expect (success) but something interesting happens if we set eth1 as the source :
... What gives ?
WELL, we're only sniffing ICMP traffic. Because no default route (or more specific route to 8.8.8.8) exists off eth1, the destination is assumed to exist on the same broadcast domain.
That means it tries to get the destination's MAC address before it can even construct the packet to send. If it can't get a MAC address, it doesn't send the packet :
(Google's DNS server probably isn't on your LAN, just as it's not on mine.)
Okay, okay, okay.
Now what if we replace the default route from out eth0 to out eth1 ?
We should expect our connectivity situation to be mirrored, right ? :
And so it does ! Now eth0 can't reach anything but eth1 can.
Assuming you want both interfaces to "just work", let's go down the road of madness that is load-balancing ... :
But does it work ?
Huzzah !
... Though, even I'm a little surprised.
Your own milage may vary. I'd advise against this madness.
In my testing, things get wonky when trying to reach destinations on the local subnet.
This is because in normal system use (i.e., not specifying an exit interface explicitly), one interface is chosen.
For example, if I ping a non-existant host (.17) on the subnet, ARP requests are only sent out eth0.
So in theory if the host did exist off eth1, would ARP even work ?
Likely not :
Cheers.