Results 1 to 4 of 4
I am working in a system (all redhat 5.x) and we have piece of hardware from an outside source that has to have the IP address 192.168.1.188. We need to ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 07-23-2010 #1
- Join Date
- Apr 2010
Need duplicate IP solution
I am working in a system (all redhat 5.x) and we have piece of hardware from an outside source that has to have the IP address 192.168.1.188. We need to add many of these pieces of hardware and they have to be visible from all the nodes in the network.
Each piece of hardware does have a linux server with a dual nic card that it plugs into. I need to solve the problem of having all these items with the same IP on the same subnet.
Every node needs to be able to mount an NFS share on the hardware (it is kinda like a self contained NAS.)
I thought I could plug in the hardware to its respective server's eth1, and plug in the server to the local sunbet on eth0. Then I could mount the NFS share on the server, and let other nodes mount the mount on there machines. I couldn't get a mount of a mount to work. I though of maybe using iptables to pass the hardware IP as another IP to the rest of the subnet but I am not savey enough to get it to work.
Does anyone know if there is a way to mount an NFS mount to another system? Or does anyone have a better solution?
Don't bother asking why this hardware has to be this way. It is old an proprietary. And we only have a dumb switch in the middle of the network.
- 07-24-2010 #2
- nfs mount of a nfs mount is just asking for trouble (locking, permissions, performance, etc)
- translating and forwarding the network *might* be possible, but of course not the most straightforward way and therefore errorprone and maintenance heavy.
First thing that comes to mind:
There *must* be a way to configure the IP to something else than 192.168.1.188.
Then you could integrate as much as you want of these NAS without funny tricks.
Can you tell the name and product?
If there is no way to configure the IP:
This is just a NAS, right?
- a 1,5TByte disc is about $90, get some miniATX board, a cheap CPU and any linux/bsd or ready-made distribution (FreeNAS [FreeNAS] is great)
- or get a pre-made NAS
Or asked in another way: What is the reason to use that hardware, if it is apparently not production ready?You must always face the curtain with a bow.
- 07-24-2010 #3
- Join Date
- Apr 2010
Thanks for your reply.
The hardware is developed by another company. They use the these IPs to bring up their system in certain configurations. They did this because they are using even more proprietary hardware that was completely unconfigurable in their hardware. It was one of those decisions that trickles down everyone trying to use the system. Believe me, if it was changeable, that is what we would have done.
I know the mount of a mount has all sorts of issues like you mentioned, but we would have complete control of the configuration and the mount is only used by a closed system.
That is why I was hoping for a NAT solution. So I could keep away from touching the configuration of the proprietary hardware.
This hardware is a lot more than storage. It would be great to upgrade to a more open system, but it is not a possibility at this time. Hopefully in the future.
- 07-25-2010 #4
Seems there are solutions:
1) NFS using iptables PREROUTING?
Answer: NFS using iptables PREROUTING?
This is old and for debian, so there surely is some rtfm to do.
2) A more controllable and visible way (think: logfiles) would be to use a userspace proxy:
NFS-GANESHA: Project Web Site
Connecting each hardware(tm) to its own server via eth1 to have multiple 192.168.1.0/24 networks should work.
For 1) you need to enable ip forwarding.
And one word of advise, no matter if you get it to work or not:
Document your effort and also your opinion on the weaknesses of this setup and send it to your boss/manager.
Also, I would annoy the support team of the hardware(tm) a little bit.
- why their hardware(tm) is not scaleable (only one per network)
- what their proposed solution would be
- you have to use one server per hardware(tm) as proxy and your time and effort for a workaround. This additional costs surely lower the license/hardware costs of the hardware(tm)?
Last edited by Irithori; 07-25-2010 at 12:31 PM.You must always face the curtain with a bow.