1

Bear with me. This relates to this Stack Overflow question.

My Linux thing (actually a BeagleBoard) has two interfaces, eth0 and eth1. It needs to connect to a client's network on eth0 (address range unknown, may be DHCP, probably 192.168.0.x). My software also needs to connect to another device on eth1 via a private link (i.e. just device to device). I want to keep the private network totally separate - it should NOT be visible on the main network. Only my own code on the Beagle will be talking to the device on eth1.

I've figured out how to make my C code bind a socket to a specific interface as well as IP address. I can also put the private link on a separate subnet to the main network and everything is happy.

However, given that I don't know the address range of the main network, and I want to use fixed IP addresses for my private link (for simplicity), how do I ensure that the address ranges don't clash? I tried putting the private device on the same IP address as something on the main network (for a test), which caused routing issues.

Is it possible to set up routing so that duplicate IP addresses (on the main network and my private network) would work (given that I can specify the interface as well as IP address)? Or is that crazy talk? I don't need to actually "route" anything between the networks and my private device doesn't need to see the main network. I just need it to still work even if the IP addresses happen to be the same.

Alternatively, can I use one of the reserved IP address ranges on my private so that I know it won't clash with the main network?

I've been searching a lot for an answer to this, but it seems like an unusual thing to do and all the answers assume the two ethernet interfaces will connect to different subnets.

Any ideas? Including doing it some other way... Thanks!

3
  • This doesn't strictly answer your question, but why have them on the same IP range? If one network uses 192.168.*.*, have the other use 10.*.*.*, or vice versa. Commented Aug 29, 2013 at 4:15
  • Yeah, that does work - but we don't know what the client's network will be using in advance. We will have to configure eth0 anyway (most likely to DHCP but possibly a static address) but I was hoping to avoid needing to also configure the private connection for each installation. It would be great if that side was always the same.
    – Jeremy
    Commented Aug 29, 2013 at 21:01
  • Well, you could set the IP address for both eth1 and that other device to addresses that you control (i.e. you have servers with those IP addresses out on the net) and therefore would never appear in your clients network. Instead of routing through eth0 to wherever those addresses are supposed to be, you set up the routing table to use eth1. This is breaking all sorts of rules, but it will work. Commented Aug 29, 2013 at 23:15

1 Answer 1

2

Two parts; First the linux specific side of things:

Create your interface being very careful that your internal interface does not affect the linux routing table. netstat and ip commands should be your friends in analyzing the route information.

Once your interface is non globally routable then go ahead and bind to that interface using setsockopt after creating the socket. These are the two options you would likely need:

SO_BINDTODEVICE
SO_DONTROUTE

See also linux/if.h.

Easier but not a complete answer to your question; Use IPv6.

2
  • Thanks! Re: IPv6: I see that there are various reserved address ranges. Are there are some addresses which would be safe to use on my internal interface, and would guarantee never to clash with address ranges used on someone's LAN?
    – Jeremy
    Commented Jan 27, 2014 at 21:23
  • No, their was originally an RFC defining site-local IP range, however this was deemed un-workable by the standardization committee's... Still, given 8 byte addresses if you pick some random range you should be OK for the forseeable future.
    – Clarus
    Commented Jan 27, 2014 at 22:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .