Loopback adapter questions.

I am trying to figure out what loopback adapters are used for.
One use case I see is jails.
The manual says:
performance analysis, software testing, and/or local communication.

So if I remember right sendmail uses the loopback adapter? What else does?
For performance analysis I thought a tee would be used. What tools use the loopback adapter?
 
sendmail defaults to localhost. Setting sendmail_enable="yes" in rc.conf will allow it to bind to all IPs. You now have publicly accessible inbound SMTP port(s). Any time you want to provide a service - TCP or UDP - but don't want it exposed to the outside, use the loopback interface.

Here's one example: apache or nginx listens on port 80 on a public IP. Either is configured to relay select traffic to another internal service. Say a ruby-on-rails REST service, a SOAP service, or a Fast CGI service. That internal service can be bound to listen only on the internal (localhost) IP. The service can be chroot'd, or run inside a jail (or bhyve for that matter). The internal service won't be visible or accessible to the outside.

Another example: a Java service listens on a public IP. The Java service talks to postgresql which listens on a private IP. Your Java service can talk to pgsql, but the outside world can't.
 
I was noticing an IPv6 address on the loopback interface and it made me wonder what loopback interface is used for.
Still not sure I understand the concept. Dummy local interface you could call it?
Linux calls file devices loopback so that is really confusing.
Why does my dummy or psudo interface have an IPv6 line?
I guess it is back to not understanding how 127.0.0.1 and localhost work or why they exist.
127.0.0.1 is a non-routed local IP right?
 
localhost is just a name in your /etc/hosts file. By convention it points to 127.0.0.1 - which by default - is assigned to lo0.

You can add more 127.* addresses to lo0. This is very handy for creating jails that each get a unique IP.

Bottom line is - for two programs to speak to each other via TCP or UDP - even when no physical network interfaces exists - you need at least one IP address and one interface.
 
Why do I see such latency on the loopback? I would expect it to be near zero.
Code:
# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.029 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.040 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.039 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.029 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.036 ms
 
OK Now that I look at my local results I see it is not really that much latency.
Code:
# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=63 time=3.842 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=1.851 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=1.814 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=1.844 ms
 
Why do I see such latency on the loopback? I would expect it to be near zero.
Code:
# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.029 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.040 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.039 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.029 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.036 ms
The equivalent command result on MX Linux:
Code:
$ ping -c 4 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.025 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.030 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.038 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.034 ms

--- 127.0.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3063ms
rtt min/avg/max/mdev = 0.025/0.031/0.038/0.008 ms
It's almost the same guy. And if I'm not wrong, it really nears to zero. Your conclusion seems wrong.
 
OK Now that I look at my local results I see it is not really that much latency.
Code:
# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=63 time=3.842 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=1.851 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=1.814 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=1.844 ms
The equivalent command result on MX Linux:
Code:
$ ping -c 4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=75.6 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.959 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.930 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=47.7 ms

--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3018ms
rtt min/avg/max/mdev = 0.930/31.326/75.679/31.948 ms
What is your definition of latency? I only know lower ping time means less latency. The completely opposite to your conclusion.
 
I am trying to figure out what loopback adapters are used for.
...
What tools use the loopback adapter?

Have a look at your routing table using the command netstat -nrW.

lo0 is linked to each of the local Host-IP-Adresses, while the NICs are linked to the respective subnet. This has a performance impact, since MTU of lo0 is usually 16384 while the default for NIC's is 1500. Pinging (and other network operations) a host IP address compared to pinging localhost won't make any difference.
 
So if I remember right sendmail uses the loopback adapter? What else does?

Practically everything might.
As soon as you run an IP service (i.e. not unix domain sockets) that talks to something on the same host, it nevertheless needs an interface to talk to. It should talk to localhost, which should be translated to 127.0.0.1 and/or the respective IPv6 address (usually in /etc/hosts), which should be placed on lo0 (usually in /etc/rc.conf).

sendmail is one of the first to complain if name resolution and network is not properly configured.

I for my part prefer to add the regular fqdn hostname also to lo0 in /etc/hosts.

Concerning performance: the data goes thru the full IP stack, including firewall rules or whatever else is there. I think this is a fair tradeoff for having technically identical behaviour on local and remote links.
If there is a high-bandwidth local connection, one should consider to get rid of IP for that (and use some more efficient IPC protocol).
 
MTU of lo0 is usually 16384
Interesting is this 'Jumbo Frames' sized? MTU is frame size right? Maximum Transmission Units.

Code:
# netstat -nrW
Routing tables

Internet:
Destination        Gateway            Flags       Use    Mtu      Netif Expire
default            192.168.100.1      UGS      195427   1500      wlan0
127.0.0.1          link#2             UH            0  16384        lo0
192.168.100.0/24   link#3             U            62   1500      wlan0
192.168.100.23     link#3             UHS           0  16384        lo0
 
Reading on MTU's I see standard Jumbo frame is 9000 to 9216 so 16384 is well above even that.

I am building a FreeBSD 10G soft switch so I will be asking lots of networking questions.
 
Back
Top