How does a loopback IP Address value helps in determining whether the system is centralized or distributed?
Posted by tastuwa@reddit | linuxadmin | View on Reddit | 43 comments
This was an interview question. I did my best to extract the question from the interviewer but you know that is not how it works. It is an interview and that was all information I got. And I was not able to ask any much distinct follow up questions except "Please repeat." LOL.
The most I can remember is at that time, we were talking about virtualizing servers, location of servers distributed or in same place...And how to tell if the server location is distributed by looking at the loopback address might have been the question.
randomfrequency@reddit
Hairpin NAT would sometimes require you to bind things to localhost, but this is a really weird question that I'm struggling to think is useful for anything outside of a pen test.
If a service is bound to localhost for some reason, it's not normally accessible outside of the node (NORMALLY).
I also don't understand the concept of it being "centralised" or "distributed" though.
daq42@reddit
It seems like the question is asking how you cam tell if a system (like a LAMP stack or other multi-service application stack) is on a single server or distributed across multiple hosts. If you see any loopback addresses in the system configuration, it means it is centralized to a single host. If you see non-loopback IP addresses, and those IP’s are not associated with tha single host, you likely have a distributed system.
serverhorror@reddit
A distributed system can perfectly exist on a single host.
If you have seven binaries and every one listens on a different local Adresse from the 127.0.0.0/8 space, it is still distributed and, for most intents and purposes, passes the same stack as reaching out to another host.
People tend to forget that.
daq42@reddit
Given that the question asked about "system(s)", I would categorize your multiple binaries as a system (multiple components that work together as a single entity/application). A single host running multiple binaries would be a centralized system, while spreading those binaries across multiple hosts would be distributed, since you are isolating resource allocation, and collectively providing more resources to your application than a single host.
This was why I mentioned a LAMP stack, which is 3 separate applications in a single application (and of course, the host OS being Linux). Of course, the real question gets into some very weird places, especially when you start getting into containerization, which, when done based on the original intent, you are distributing your component binaries, but you may still use the loopback addresses provided all the containers are running on a single host. Again, this still points to the system being "centralized" to a single host, since loopback networking only communicates on a single host. A distributed system would, by definition, be unable to utilize loopback address binding, since binaries on separate hosts would be unable to communicate with each other.
serverhorror@reddit
So many words to describe something that completely missed the point I highlighted.
I said that you have the same problem domain when using loopback or using routed addresses. I extended this to include multiple binaries, because the problem domains of a single binary are just orders of magnitude smaller.
emprahsFury@reddit
I wouldn't call that distributed. It might be logically distributed. This sort of nuance is what makes it a bad question. And it's a bad interviewer that would ask a question with two right answers and only accept one
serverhorror@reddit
Well it'll have all the potential problems of a system running in different hosts.
Heck even two separate processes already have an abysmal addition of error domains compared to a single process.
BloodyIron@reddit
No it doesn't. The majority of systems have loopback addressed by default and that typically has zero impact whether the system is part of a distributed greater system or not, as those are typically on other interfaces with other (non-loopback) addresses.
Literally every Linux system I work with have loopback addresses (127.0.0.1) and not once has that ever impeded systems being configured to be distributed (or not).
The question OP posts is a trick question.
tastuwa@reddit (OP)
Exactly that was the question. Could you provide a reason to the curious readers of this thread on why? I never looked at loopback address while I was working on that company. Stupid me. It would be fun to actually understand stuffs.
techworkreddit3@reddit
If you bind a service to loopback or localhost it cannot be reached outside of the machine. If you bind a service to the actual IP address it is reachable on the network and thus more likely distributed. There are cases where this might not be true if you have a reverse proxy that is bound the machine IP address and then directs traffic to the localhost bound service.
All in all this a pretty shitty worded question and honestly one that I would never give a shit to ask in an interview.
Envelope_Torture@reddit
This is kind of a weird question.
But in some systems you bind VIP for LBs/HA type stuff or Anycast addresses on the loopback interface. They aren't loopback IPs, because they are used for external traffic.
BloodyIron@reddit
A loopback interface by definition cannot and should not accept external traffic. That's the key distinction by anything labelled "loopback", that it by definition does nothing related to external anything.
Envelope_Torture@reddit
Can you clarify the point you're trying to make? Is it a semantics thing? As far as I know the loopback interface itself (lo, lo0, etc) is not defined in any RFC, rather it's just the IP ranges themselves that are.
Binding an anycast IP address on the loopback interface and advertising it via BGP for example is an industry best practice.
aenae@reddit
If your loopback has routable adresses (beside ::1 and 127.x) it is part of a distributed system. Binding them to loopback causes the system to not send ARP's for them, but if they do receive a packet with that address, they can respond to it, because the address is known. If they don't have the address locally, they just ignore it.
tastuwa@reddit (OP)
what is a loopback address use case?
aenae@reddit
Say you have 10 servers that respond to 1.1.1.1 on your local network, but you don't want 10 ARP replies when you ask 'who has 1.1.1.1, tell me'.
If you bind 1.1.1.1 to a loopback interface on a server, and only 1 server responds to 'who has 1.1.1.1', that responding server can than send the packet to the other servers, which will accept it, as they 'know' 1.1.1.1.
Next they can send out the reply directly back to the client with source '1.1.1.1'.
This as opposed to the more common model where the worker nodes send back the response to the loadbalancer who than forwards it to the client. The advantage is that your loadbalancer isn't the bottleneck for responses anymore.
Normal model: client -> loadbalancer -> worker -> loadbalancer -> client
This model: client -> loadbalancer -> worker -> client
BloodyIron@reddit
What you're describing is, by definition, not loopback, as the traffic (packets, probably TCP in this case) exits the "client" servers in your example. Loopback literally cannot and does not leave the relevant system as by definition it ... loops back on itself.
What you're describing is LAN IP resolution overrides (and with public IPv4 addresses no less, very bad practice, but I know you're just giving an example).
saranagati@reddit
Isn’t that just ECMP? Otherwise how would that even work unless you’re all on the same hub rather than a switch? And how would TLS work if there’s nothing keeping track of what flows go where? In fact how would packets even make it to the correct host? Is the idea here that it’s a like k8s cluster where any node can respond accept the packets and route it to the correct location?
No matter what the answer none of this would determine whether you’re on a distributed system. It could provide clues that you are but far from confirming it’s distributed or centralized.
aenae@reddit
The xkcd “protocols” comic is relevant here ;)
The loadbalancer receives the packets, rewrites the mac address and sends it out to a node. The node responds to the packet with the correct mac address. TLS is done on the nodes, the loadbalancer doesnt need to know anything above layer 3 (or 2, cant remember).
It is something i used in the 2000’s with LVS
And indeed, the question is rather vague, but something like this would be my answer
saranagati@reddit
Oh god I forgot about LVS. Funny though that your answer had triggered me to think that this sounds like how things would be done back then but have since been replaced by much more sane practices. If someone is trying to create a “distributed system” these days, doing something like that, I’d be concerned. If you want to go that far to avoid a load balancer, just use DPDK.
arvoshift@reddit
great answer. networking isn't my strong point. I could see how this may be used if anycast isn't really worth setting up? I'd think the use-case nowadays would be application specific and not too many reasons to use this over anycast. I'd envision the loadbalancer runing geoip or a table of source nets for other routing protocols to respond with the closest worker node?
aenae@reddit
It is also useful in small clusters where you want 'direct return'.
Say you have a video streaming service with 5 servers as worker nodes and 1 loabalancer. All connected with a 10Gbit link. If everything ran through the loadbalancer, you could stream at max 10gbit. If you use direct return (ie; the trick i wrote about) you can serve 50gbit.
It also need a bit of mac address rewrting, so it is usually done on a dummy interface, but the loopback interface can be used as well.
paulstelian97@reddit
This feels like a cursed way to do something useful
Longjumping_Gap_9325@reddit
It's this similar to, or how, direct server return on load balancers work?
aenae@reddit
Yes, that is exactly it
BloodyIron@reddit
A loopback interface is the fastest interface you can get and you can't buy it. This is because it's moving at the speed of your CPU and RAM as the traffic never leaves your CPU and RAM due to how the Operating System Kernel handles the traffic.
Regardless of if it's IPv4 or IPv6 loopback interfaces are particularly useful for connecting services that you don't want to be reachable externally from the "System".
For example, let's say you have a LAMP stack (Linux Apache MySQL PHP) system. In most (but not all) cases you want to have MySQL ONLY listen on loopback. This has two primary benefits:
In-contrast if you have MySQL on a different server, serving data for the same website (LA(M)P) the data read/writing to the MySQL server would only be able to go as fast as the network interface between the two servers (this is of course putting aside any underlying storage bottlenecking).
We're talking about the difference between say... 1 gigabit per second and... tens of GIGABYTES per second, as a theoretical (and typically practical) scale comparison.
DigitalBison@reddit
In VXLAN overlay networking it’s common to assign VTEP addresses to a loopback interface.
BloodyIron@reddit
Then it's by definition not loopback, because not only linguistically but functionally loopback literally means to go back to itself. The moment it becomes routable (to ANYTHING other than itself) it stops being loopback, by definition and function.
BloodyIron@reddit
"A loopback IP address value in and of itself never actually reliably indicates if said system is centralised or part of a distributed system" is what I would answer.
It's a trick question. I've dealt with many forms of clustered systems (Linux and otherwise) and every single one has a loopback IP address by default (127.0.0.1) which never was involved in whether the system was configured to be distributed or not.
Even with, for example, clustered Proxmox VE systems loopback IP Addresses don't need to be changed in any way when a PVE single node joins a PVE cluster (which would then qualify as being a distributed system by default).
I would hazard the following speculations:
Honestly I wouldn't sweat it worrying about this question. I'd love to be proven wrong, because despite working with more different IT Systems than I can remember for decades, I don't know everything. But I have very high confidence in what I say above.
(to anyone reading that thinks they can correct me on this, this is me welcoming you to prove me wrong, but please do it with evidence)
1esproc@reddit
I guess the idea is that you have inbound as Clients->VIP->LoadBalancer (LB)->A,B,C, and outbound as A,B,C->Clients sourced from the VIP. A,B,C have the desired VIP on their loopback - this prevents having them wrongly ARP for the VIP if you put it on a real interface, though your system (if it's Linux at least) maybe consider the packets martians? So the Load Balancer routes to the backend systems on their real interfaces and the packets return with source as the VIP interface right to the clients without passing through the LB
/shrug
After writing this I found this: https://deepwiki.com/microsoft/Azure-ILB-hairpin/3.2-loopback-vip-with-dsr - so yeah
michaelpaoli@reddit
Sounds like a relatively crud question to me. Loopback IPs, you've got ::1, and for v4 127.0.0.1 and possibly some additional 127/8 IPs, and those IPs themselves don't really tell you much of anything. Now, as for what services may be on them and/or what additionally those services may be able to tell you, that's another matter, but that's not what the question asked, at least as you stated it.
tastuwa@reddit (OP)
https://community.unix.com/t/how-does-loopback-address-helps-in-verifying-whether-a-system-is-distributed-or-not/397329?u=ihattaren
A discussion was going on here. But it looked like AI generated so I ignored further. I am just sharing if in case this can help someone formulate some answer.
1esproc@reddit
I think that answer from Peasant might make sense - though I've never seen or done that.
I guess the idea is that you have inbound as Clients->VIP->LoadBalancer (LB)->A,B,C, and outbound as A,B,C->Clients sourced from the VIP. A,B,C have the desired VIP on their loopback - this prevents packets being considered martians. So the Load Balancer routes to the backend systems on their real interfaces and the packets return with source as the VIP interface
/shrug
reditanian@reddit
Question seems like AI too
michaelpaoli@reddit
Yeah, looks like nothing there addressed your question here. "Benefit(s) of" is a totally different question. Determining whether centralized or not isn't even addressed there.
billndotnet@reddit
You're confusing localhost for loopback. While the loopback address is usually 127.0.0.1 / localhost, that isn't always the case. On routers, which can have potentially hundreds of interfaces, the loopback address will often be the router's 'own' address, being the address it will respond to SSH on, source logs from, and be used to hang other relevant services on.
Ok-Pomegranate-7458@reddit
I always wonder why the loopback range was so big. It seems like a waste of IP address.
random_mayhem@reddit
Likely ease of use? /8's were handed out when you could still count sites on fingers and toes. I wonder how long before we question the waste of handing out /40 IPv6 allocations :)
Due_Adagio_1690@reddit
most places only give out /50ish... but still ipv6 is so big its hard to grasp, the math, it would take years to ping hosts with just one packet, if you did it over a 100 gigabit link.
arcimbo1do@reddit
It doesn't, all hosts have a loopback IP address. However, looking at what services are listening on the loopback ip and what iptables rules you might give you some hint on the setup. For instance in k8s sidecar containers will run services that listen to localhost because they are supposed to be reachable only from other services in the same container; docker containers use 127.0.0.11 as DNS server, and when using load balancers you can see the VIP assigned to the loopback interface (which is not the loopback IP but this question is idiotic and so an idiotic mistake can be expected), and again when using istio you will see a lot of nat rules to redirect traffic to localhost, where the sidecar is listening.
All in all, this question only makes sense if you allow the interviewee to ask questions, and you evaluated then based on how smart the questions are.
Out of curiosity, which company (of you can say) and what role?
Virtual_Ordinary_119@reddit
Dunno, but sometimes I bind addresses on loopback interfaces, the same address on several boxes, and then announce them via BGP, so that the upstream peer can leverage ECMP to distribute traffic providing load balancing and HA. So in that context, if you find the same address on loopback interfaces on several servers it might be a hint of a distributed workflow
lazylion_ca@reddit
Thanks for posting this. Everytime I think I have a good handle on networking, something like this pops up and I find myself re-reading about the basics like arp and how they used in a way I havent had to deal with before.
PJBonoVox@reddit
Personally I'm not great at extrapolating a meaning from questions other than what is directly written. It would be obvious to me that presence of a loopback IP means nothing.
But other folks in the comments here have stated that it probably meant if the loopback IP was referenced anywhere or bound to be a service. I hate these kind of questions 😒