<p>In short, you want to attach to a single host a number of devices all of which have the same IP.  There are two issues you need to deal with — the ARP cache and routing.</p>
<h1>The ARP cache</h1>
<p>The ARP cache maps neighbours' IPs to MAC addresses.  Since all of your devices have the same IP, the ARP cache will get confused in your situation, and cause all of the traffic to be sent to the same neighbour.</p>
<p>I believe that under Linux the ARP cache is indexed by (IP, interface) pairs.  This implies that the ARP cache will not get confused if each device is connected to a different interface (please let us know if that works).  On the other hand, if you connect all of your devices to the same switch, the ARP cache will get in the way (unless you play tricks with VLANs).</p>
<h1>Routing</h1>
<p>In traditional next-hop routing, the routing table is indexed by destination IPs.  Since all of your devices have the same IP, traditional next-hop is unable to distinguish them.  In <em>source-specific routing</em>, the routing table is indexed by <em>(dest, src)</em> pairs.  In other words, a source-specific router can choose the next hop by using both the source and the destination.</p>
<p>In order to use source-specific routing, you will need to set up a distinct IP on your host for each of the devices.  Your application will then be able to pick the right device by performing <code>bind</code> on the right address.</p>
<p>Setting up a source-specific routing table is described in Section 4.1 of the <a href="http://lartc.org/howto/" rel="nofollow noreferrer">LARTC</a>.  For more information about source-specific routing, please see <a href="https://datatracker.ietf.org/doc/html/draft-troan-homenet-sadr" rel="nofollow noreferrer">draft-troan-homenet-sadr</a> or <a href="http://arxiv.org/pdf/1403.0445.pdf" rel="nofollow noreferrer">this paper about source-specifig routing</a> (disclaimer — I'm a co-author).</p>
Routing around an insane device interface
<p>I've inherited a swath of code that talks to a device developed in-house. Said device has a network interface that is, generously, rather ad-hoc:</p>

<ul>
<li>it always sets its IP address to be 172.16.0.50, and assumes it's connected directly to 172.16.0.250 (via a physical cable)</li>
<li>it sends a UDP heartbeat to .250:2000, regardless of whether .250 has bound to that port</li>
<li>it can send UDP traffic to .250:9001 through .250:9016</li>
<li>it exposes a text-based admin interface over TCP at .50:7734</li>
<li>it binds as UDP to .50:7734 and accepts any incoming traffic on that port as a timestamp to synchronize itself against</li>
</ul>

<p>Modifying the device's code is absolutely out of the question, sadly. Source is available, unboxed hardware is available to test against, but deployed boxes are aggressively sealed against the environment, and gaining access to the flash chip it boots from is a day-long process.</p>

<p>I'm interested in attaching several of these devices to the same host computer, but my background is in applications, web, and some embedded - not networking. Each device has a dedicated network interface (eg p1p1, p1p2, etc), which I think should save me, but I'm not sure how to set Fedora up to do the necessary impersonation, and I'm not sure how to set up my application code to distinguish between UDP traffic on interface p1p1 - IP 172.16.0.50 - port 9000, from UDP traffic from interface p1p2 - IP 172.16.0.50 - port 9000, or to specify that I want to broadcast a given datagram via UDP at 172.16.0.50:9000 on interface p1p1 vs 172.16.0.50:9000 on interface p1p2.</p>

<p>I believe I can pull this off with a sufficiently clever combination of static routing entries and iptables rules for bidirectional port forwarding, but I'd like to ask before spending days on a fundamentally flawed approach. What's the sanest way to make this palatable?</p>