0

I have two networks that are physical separate and distinct. They both have the same subnet 192.168.1.0 netmask 255.255.255.0. I need to share a drive to both networks. My hosts are all Linux. setting two nics to the same subnet in one PC is not working. No, i cannot change the network IP of one of the networks which is of course the simplest solution. Using two PC in which one attempts to re-export an NFS share from the other does not work as NFS does not allow re-exporting NFS shares. I tried using a virtual machine (VMWARE) which solved all connectivity issues except it cannot NFS export a shared folder of type vmhgfs. surely this is not that unique of a situation.

I cannot edit the networks because the devices that are attempting to NFS mount this shared drive are aircraft "black boxes" their embedded code has hardcoded to do an NFS mount of 192.168.1.10:/diskB on one network and 192.168.1.11:/diskB on the other network. there are two networks for redundancy in the aircraft. In the real aircraft there is a box which can accomplish this and serve both networks at the same time via those hard coded IP addresses. I am trying to simulate this box because to get a flight box will take over a year (all current production allocated to actual aircraft).

hillsm
  • 9
  • 2
  • How can these two networks even be connected? Anyway, given your inability to changing your addressing you are probably out of luck. – Zoredache Nov 22 '16 at 21:21
  • 1
    You say the networks are distinct, but you're trying to communicate between them. This implies a link of some sort. What sort? – Jeter-work Nov 23 '16 at 15:31
  • Without knowing where the data is stored (Network A or B or external to both), and how each network (A and B) can connect to the data storage device, we cannot provide a good answer. – Jeter-work Nov 23 '16 at 19:28

4 Answers4

1

Your problem is one of many IPv4 problems which has been solved in IPv6. In that respect I see your problem as a problem of how to support legacy IPv4-only devices in an IPv6 world.

With that view on the problem, this is how I would solve it:

Run the server as IPv6-only at least from the kernel's point of view. Run a user mode program that talks IPv4 on a single physical network interface and translates that to IPv6 on a virtual network interface presenting the traffic to the kernel.

You can run as many instances of this program as the number of physical network interfaces you need to support. Each instance of the program is responsible for a separate network interface. You need to allocate a /96 IPv6 range to each instance of the program, which is a negligible amount of IPv6 addresses.

Using that very approach I have previously implemented a NAT64 program which allowed me to have a single machine be used as a client on two separate IPv4 networks with identical prefixes and same gateway address.

Your problem is slightly different because the role of client and server appears to be swapped compared to the usage case I needed to address. That means the solution would be slightly different, but it would also be a slightly simpler solution in your case because it could be stateless with no need for connection tracking.

The parameters for the program would be the following:

  • Which network interface to use
  • Which IPv4 address the program has on this interface
  • Which /96 IPv6 prefix it has on the virtual interface

The program needs to receive ARP requests for its IPv4 address and respond to those. It needs to perform ARP queries for any client it needs to communicate with and cache the responses. And it needs to translate packets between IPv4 and IPv6.

The address mappings between IPv4 and IPv6 would be as follows:

  • From IPv4 to IPv6 prepend the configured /96 to the address.
  • From IPv6 to IPv4 compare the first 96 bits of the address to the configured prefix.
    • If there is a match remove the first 96 bits to find the IPv4 address
    • If there is no match construct a no route to host response
kasperd
  • 30,455
  • 17
  • 76
  • 124
  • not being a network engineer this may outside my realm. I've never dealt with the networking below socket layer. The kernel has always handled it. – hillsm Nov 27 '16 at 16:42
  • @hillsm I think I could implement the solution I described in 1-2 days - if I had the time. But if you don't have intimate knowledge of the wire formats of IP traffic, it is probably going to take a bit longer than that. – kasperd Nov 27 '16 at 23:26
0

The correct answer is to

  • put the two physically separate networks on separate IP networks and use a router to route between them,
  • or join the two physically separate networks using VLANS on a Layer 2 Switch.

Another solution is to use NAT on one or both networks on whatever link you're using to connect them.

Your VM solution sounds like it must be dual homed, which may resolve some of the issues, but you may see some routing issues. You could always format the shared partition in a FS other than vmhgfs.

Update: Use classless IP subnetting (CIDR), 25 bit. Push network A to the bottom of the subnet, and B to the top. You may have to re-IP one or both networks. Set up the storage device in a third network (for Pete's sake use a different private subnet.) Have the storage device export to each 25bit CIDR network.

Update2: Use cloud storage.

If you can't do any of these suggestions, I begin to believe that you're trying to set up something within a network for which you are not an admin.

Jeter-work
  • 845
  • 4
  • 15
  • I am not trying to communicate between the two networks. Just share a drive between them – hillsm Nov 23 '16 at 17:01
  • Sharing a drive between two networks IS communicating between two networks. The root problem here is that you are using the same IP space for two separate networks. Which means that any box on one of the networks will not know that a given address is really on another network. – Jeter-work Nov 23 '16 at 19:21
0

You could try adjusting the subnet on the interface that is talking to the blackboxes, give it an IP of 192.168.1.12, a subnet of 255.255.255.248, and a broadcast of 192.16.1.15

And then set the other interface to have an IP of 192.168.1.100 and give it a subnet of 255.255.255.248 which would have a broadcast of 192.16.1.103

Winter Faulk
  • 471
  • 2
  • 14
0

Ok so i managed to get one of my early failures to work. I created a virtual machine (VMware) on my RHEL7 host. I also installed RHEL7 as the guest OS. On the host I have IP 192.168.1.10 on one NIC. the other NIC is on but has no IP assigned to it in the HOST. instead the VM has a bridged NIC to it using IP 192.168.1.11. I then created a "shared folder" of my diskB and mounted it as /diskB with type vmhgfs in my VM. I enabled nfs on the host and am exporting /diskB. Now here was the trick. in the VM I could not use the kernel nfsd instead i build a user space NFS daemon unfsd. I then run this unfsd as root on the VM exporting /diskB. now both networks are happy and clients on either network can see changes made by clients on the other network.

hillsm
  • 9
  • 2