Results 1 to 3 of 3
I am trying to investigate the possibility of using of the loopback network block (127.0.0.0/ for private networking. My system has a set up of multiple processors interconnected by a ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 09-05-2008 #1
- Join Date
- Oct 2007
Unable to use 127.0.0.0 for Private Networking
My system has a set up of multiple processors interconnected by a private IP network via a layer 2 switch. Each processors run Linux and has its own IP stack. The application on these processors exchange packets with private source and destination IP. These packets does not leave the private network to a public IP network.
So my prototype would have change the configuration of the loopback interface in the /etc/rc.sh from this,
%ifconfig lo 127.0.0.1 up
%route add 127.0.0.0 lo,
%ifconfig lo 127.0.0.1 netmask 255.255.255.255 up
%route add -host 127.0.0.1 lo
And I make further changes to the routing table and interfaces on each processor, specifically:
- I assign a 127.0.0.x address (not 127.0.0.1) to its interface
- Add a route to route 127.x.x.x packets out of the interface.
After these changes, I tried to ping a 127.0.0.x destination of another processor. from one processor to another processor. But it didn't work. The packets with 127.0.0.x destination did not leave the interface as indicated by the routing table.
I checked the system call when running the ping with strace. The sys_sendto() returns successfully.
Can anyone comment on why this 127.0.0.x does not work based on my set up?
Is there anything in the Ethernet Driver that blocks 127.0.0.x address from being routed correctly?
Thanks for the help.
- 09-11-2008 #2
127.0.0.x is reserved for the local loopback and is never forwarded. Can I ask why you are trying to use this when there are so many private ip addresses available?
The adventure of a life time.
Linux User #296285
- 09-11-2008 #3
- Join Date
- Oct 2007
The objective driving this investigation is to have a "truly" private network within my router product, which we deployed in our customers' own networks. This router product embodies multiple entities/cards, whose processes communicate with one another over an private IP network. Since our router product needs to work in whatever ip address space the customer chooses to use for their own enterprise network (it can be any of the RFC1918 blocks), we need to come up with a solution to avoid any ip address collision between the internal router network, i.e. the private in-the-box network, and external customer network.
127.x.x.x is an address space that immediately comes to mind because it is address that is reserved for host loopback and it is highly unlikely to be deployed. For this reason, it is arguably a reasonable candidate to solve this problem.