Score:-2

Connectivity issues with 127.x.x.x series

gt flag

Asked this in network-engineering in stack exchange and was redirected here.

I have a couple of servers with the below config

server1:

eno1: 127.15.0.1/16 scope global
eno2: 5.0.0.1/24

server2:

lo: 127.0.0.1/16 (it had /8. I changed the subnet mask using 'ip addr del 127.0.0.1/8 dev lo; ip addr add 127.0.0.1/16 dev lo')
eno2: 5.0.0.2/24

eno1 of server1 is connected to a completely different L2 network and is completely isolated.

eno2 interfaces of both servers are connected to the same L2 network. Now i have to access 127.15.0.1 from server2.

Server1 was deployed long back and i dont have permissions to change any sort of config. I dont know why some one used 127.x.x.x subnet with scope global. Not sure if it is a valid config but i have to live with it. I have complete control on the server2 and i can change anything.

Both servers are linux based.

connectivity between 5.0.0.1 <-> 5.0.0.2 is good.

My first try was to add a route in server2 as below

ip r add 127.15.0.1/32 via 5.0.0.1 pinged 127.15.0.1 from server2. I see the ping requests and replies in tcpdump on server2, but ping command is showing 100% loss.

I disabled rp_filters

sysctl.cnf:

net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.lo.rp_filter=0
net.ipv4.conf.eno2.rp_filter=0

rebooted after updating sysctl.conf

And i flushed out the iptables. (iptables -F)

Same result. I thougt may be server2 doesnt like using 127.x.x.x series. So i added the below rule on server 2

iptables -t nat -A OUTPUT  -d 5.0.0.1 -j DNAT --to-destination 127.15.0.1

this rule is supposed to replace destination ip to 127.15.0.1 if packet is destined to 5.0.0.1.

pinged 5.0.0.1 from server2. Iptables replaced the destination ip with 127.15.0.1(confirmed this on server1 tcpdump). Server1 replied but the replies are dropped again.

I ran out of ideas at this point. I took down server1 for maintenance and replaced 127.15.0.1/26 with 192.168.1.1/16. Connectivity worked fine in this case (with and without iptables). Now the question is, is the issue because of using 127.x.x.x? If yes, is there a way out of it?? If no, what else can I try?

Note: This config was working before. We recently lost server2 (which had old Linux) and I am building it from scratch. Also windows doesn't allow using 127.x.x.x to interfaces other than loopback. Not sure why Linux allows it on non lo interfaces. may be there is a rationale!

To summarize I have these questions:

  1. Windows outright rejects the config when we try to configure 127.x.x.x but Linux allows it and that too with global scope. Is there a use case for this?
  2. In this case server2 sends out requests destined to 127.x.x.x and server1 is actually sending replies back. If 127.x.x.x is only host-internal, why are they even sending packets on the link??
Zac67 avatar
ru flag
127.0.0.0/8 is reserved for *host-internal* loopback and not for use on a local network, see RFC 5735. There are plenty of other, functional address ranges as per RFC 1918.
RBK050 avatar
gt flag
Thankyou. I don't want to sound rude but I already knew that. As already mentioned in the question, the moment I change the subnet to private/public subnets, it works. I am working on fixing the config. I have summarized my queries at the end of the question. Would be interesting to get your view(s) on it.
anx avatar
fr flag
anx
Even if you do not have access to the other server, it would be appropriate if the person responsible for its maintenance a) explains himself b) showed you the relevant configuration so you do not have to wonder *why* this even worked before and c) fix this mess.
Ron Maupin avatar
us flag
Addresses in the `127.0.0.0/8` loopback block cannot appear on any network, anywhere. See [this answer](https://networkengineering.stackexchange.com/a/40156/8499) for the relevant RFCs. That range is recognized by IPv4, itself, and any IPv4 implementation that allows traffic destined to an address in that range to exit the host is a flawed IPv4 implementation. Traffic destined to those addresses is _required_ to loop back inside the source host.
Ron Maupin avatar
us flag
_[RFC 1122, Requirements for Internet Hosts -- Communication Layers](https://tools.ietf.org/html/rfc1122#section-3.2.1.3)_: "_Internal host loopback address. Addresses of this form MUST NOT appear outside a host."_
RBK050 avatar
gt flag
Relax guys. I am well aware of the RFCs. I just wanted to know if linux supports it. And looks like it does. Please look at the answer. I am not encouraging anyone to use it. Just wanted to know if there is a possibility.
Score:0
fr flag
anx

The Linux sysctl flags at

/sys/net/ipv4/conf/*/route_localnet

allow disabling reasonable treatment for such packets.

route_localnet - BOOLEAN

Do not consider loopback addresses as martian source or destination while routing. This enables the use of 127/8 for local routing purposes. default FALSE

Since few sane people would ever do such a thing, this may or may not work these days (I last tested it a few years back).

Please assign any reserved-for-this-purpose (possibly link-local, but not host-internal) or owned IP space to the interfaces in question. Continuing with this strange setup is only going to cause more trouble, especially when easy alternatives exist.

RBK050 avatar
gt flag
This worked. This proc entry is the reason for black magic. After setting this, connectivity worked. I was able to convince my team use private IPs. Thank you
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.