Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Linux dummy / loopback interface, what are you using it for?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Linux dummy / loopback interface, what are you using it for?

Just wondering if anyone is using Linux's dummy interface or some other form of loopback and what you are using it for?

Apart from routing OSPF, I wonder what could this be used for... perhaps there are few good ideas out there : -)

Comments

  • ramnetramnet Member, Host Rep
    edited March 2018

    For running network services you don't want directly reachable from the whole world, of course.

    Things like database servers (eg: memcached and MySQL), local application servers (eg: tomcat) as well as fastcgi/wscgi applications.

    Also stuff like smtp servers that send only.

    Yes, there are other ways to do that without binding to loopback (such as setting up iptables or using tcpwrappers) but it's much simplier, less error-prone, more secure, and better for performance to use loopback.

    Another way to avoid using loopback is having everything local communicate over stuff like local unix domain sockets. Most of what I listed above can be used that way and you could skip network bindings altogether. Another alternative is local process communication (such as using /usr/sbin/sendmail instead of binding to loopback port 25 for local smtp)

  • FranciscoFrancisco Top Host, Host Rep, Veteran

    ramnet said: memcached

    Yeah, uh, we gotta have a chat about that....

    Francisco

    Thanked by 2netomx pike
  • Thank you, Yes, understood that loopback is generally used for binding to locally accessed network service..

    Actually I am wondering if anyone assigns an IP (private/public) to dummy / loopback interface and can share a useful scenario.

    One example would be using loopback as the source IP address for certain application when having more than one outgoing interfaces as this IP would work for both outgoing interfaces.

    Any other ideas?

  • ramnetramnet Member, Host Rep
    edited March 2018

    @job0121 said:
    Actually I am wondering if anyone assigns an IP (private/public) to dummy / loopback interface and can share a useful scenario.

    127.0.0.0/8 is reserved for loopback. And yes, valid scenarios exist where you might want to assign multiple IPs from that range to loopback.

    I cannot see a valid scenario where one would want to assign an IP to loopback not from the reserved 127.0.0.0/8 range.

    @job0121 said:
    One example would be using loopback as the source IP address for certain application when having more than one outgoing interfaces as this IP would work for both outgoing interfaces.

    That's not how networking works. Using loopback by definition means loopback is both your outgoing and incoming interface for the connection in question - the connection loops back on itself, and cannot be routed across any other interfaces. Loopback is the only interface that behaves that way (in contrast to other dummy interfaces such as tun/tap and bridge interfaces which are routable).

    If you wanted to do what you describe, then you'd simply assign that IP to one of your real interfaces and turn off reverse path filtering and enable ip forwarding so it was reachable from all your real interfaces. This is all standard stuff for building a Linux router box.

    For example, say you had a Linux server with 2 network interfaces:
    eth0: IP 10.0.0.1/24 and eth1 IP: 192.168.0.1/24
    If you turn off reverse path filtering and enable ip forwarding in the Linux kernel, then traffic behind eth0 will be able to access 192.168.0.1 even though that is bound to my other interface. I will also be able to originate traffic going out eth0 with a source IP that belongs to eth1. All of this is vice-versa too.

    Reference https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt specifically arp_announce arp_ignore ip_forward and rp_filter

  • Yes, that's partially true about loopback by taking the literal meaning of loopback and that's why I put the topic as dummy / loopback.

    (However, for Cisco/Juniper/etc. terms, I am not so sure if they use other interface name rather than loopback. Please correct me.)

    I am not sure if your explanation is sufficient to reject the use of dummy and I don't think you understood my example fully, you might have taken only a possibility from the possible example I have given. So here I will elaborate a bit more to open the possibility:

    Example1:
    Eth0: 10.1.1.1/24 GW 10.1.1.254 -> router/switches->public Internet without NAT
    Eth1: 10.1.2.1/24 GW 10.1.2.254 -> router/switches->public Internet without NAT
    Dummy0: real public IP x.x.x.x/32

    Eth0,Eth1 can be fail-over/load-balance etc. So in order to have a proper configuration don't you think binding x.x.x.x to Dummy0 would be most appropriate? Or do you have a better suggestion so I can learn as well. x.x.x.x could make outgoing connection and could also be a service which listens with TCP/UDP/SCTP/RAW/etc.
    x.x.x.x could even be the NAT outgoing address.
    (Taking into consideration that there could be more Eth interface added and removed from time to time. )

    Example2:
    Similar to the scenario above but Eth0---EthX are all DHCP based
    Dummy0: real public IP x.x.x.x/32
    Now, where should the x.x.x.x be binded to since there no EthX interface which are static? I still think dummy0 is most appropriate. What do you think?

    Again, thank you for your comment, I agree on some points and thank you for pointing them out. Yet, what do you think of these scenarios : -).

  • ramnetramnet Member, Host Rep
    edited March 2018

    job0121 said: (However, for Cisco/Juniper/etc. terms, I am not so sure if they use other interface name rather than loopback. Please correct me.)

    Your question was about Linux, so I answered in the context of that. Yes, loopback on certain other devices isn't actually a loopback device. On many routers you assign the public IP address of the router to loopback, and in this case loopback behaves like an unattached bridge device reachable from everywhere rather than behaving as loopback which is reachable from nowhere.

    job0121 said: what do you think of these scenarios : -).

    Example 1 is not an issue in the real world. The reason is if the purpose is for IP failover this will require both gateways on both interfaces to be aware of this, as it would require both gateway endpoints to route a single IP address down multiple paths. Without using a bonded configuration or something like vrrp or a routing protocol you'd be creating a routing loop and nothing would work.

    However failover is handled on the two external gateway devices will dictate how this gets configured on the local system.

    Example 2 is a non-issue. DHCP changes nothing.

    The best answer I can give you for what you would do in that situation is you would want to create an unattached bridge interface, and setup your server as a router to that. You could then bind IPs to that, and route traffic to and from it and treat it as if it was another physical interface, just like how it's done on certain network appliances.

    So, to summarize: you don't want to use loopback. The best solution here IMHO is to use a bridge - it will result in the most flexibility and bridging is very well documented and supported on Linux.

    Also, as far as Linux dummy, it doesn't do what you think it does. dummy on Linux is equivalent to /dev/null, it can't pass traffic. The source gives an example usage case. The only reason dummy exists is if you want to create multiple loopback interfaces.

    Thanked by 1that_guy
  • job0121job0121 Member
    edited March 2018

    @ramnet said:
    So, to summarize: you don't want to use loopback. The best solution here IMHO is to use a bridge - it will result in the most flexibility and bridging is very well documented and supported on Linux.

    Thank you for explanation and sharing your preference in using a bridge.

    Also, as far as Linux dummy, it doesn't do what you think it does. dummy on Linux is equivalent to /dev/null, it can't pass traffic. The source gives an example usage case.

    From that github "The purpose of this driver is to provide a device to point a route through, but not to actually transmit packets."

    From testing, it passes traffic just like loopback (lo on linux, and it seems to just work like loopback on Cisco/Juniper routers). Perhaps it should not? (BUG!?)

    Here is the testing config just to demonstrate that it can pass packets :

    A (tun0 a.a.a.a/24) --- (a.a.a.b/24 tun0) B (using ovpn)

    (A: default gw is B)
    A: # ip addr add x.x.x.x/32 dev dummy0
    A: # ip addr add x.x.x.y/32 dev lo
    A: # sysctl net.ipv4.ip_forward
    net.ipv4.ip_forward = 0

    B: # ip route add x.x.x.x via a.a.a.a
    B: # ping x.x.x.x
    0% packet loss

    B: # ip route add x.x.x.y via a.a.a.a
    B: # ping x.x.x.y
    0% packet loss

  • mkshmksh Member

    I have used 127.0.0.0/8 to simulate raw wifi traffic using broadcast (which was a bit of a pain to get working on loopback though iirc).

  • raindog308raindog308 Administrator, Veteran

    job0121 said: Example1: Eth0: 10.1.1.1/24 GW 10.1.1.254 -> router/switches->public Internet without NAT Eth1: 10.1.2.1/24 GW 10.1.2.254 -> router/switches->public Internet without NAT Dummy0: real public IP x.x.x.x/32

    This is not a loopback example. Are you sure you mean loopback adn not RFC1918 addresses? (10.x, 172.16.x, 192.168.x)?

    job0121 said: From that github "The purpose of this driver is to provide a device to point a route through, but not to actually transmit packets."

    Again, not loopback.

  • PUSHR_VictorPUSHR_Victor Member, Host Rep

    The loopback is where we measure real time bandwidth of all Nginx server blocks, as well as where Linux's traffic control runs (shaping every server block separately if necessary, as each block is on it's own port). There is a "public" server block for every "private" one, which proxies to the private block and runs on port 80/443 for the public to access.

  • ramnetramnet Member, Host Rep

    @PUSHR_Victor said:
    The loopback is where we measure real time bandwidth of all Nginx server blocks, as well as where Linux's traffic control runs (shaping every server block separately if necessary, as each block is on it's own port). There is a "public" server block for every "private" one, which proxies to the private block and runs on port 80/443 for the public to access.

    That is quite interesting. Personally I would just use iptables to count traffic bytes and the limit/hashlimit modules of it to do traffic shaping.

  • msg7086msg7086 Member
    edited March 2018

    We bind a range that we don't own on loopback to work as a virtual IP so that we can bind port forwarding on loopback addresses.

    We VPN to that server and route that range through VPN to make use of those virtual IPs. You can't route 127/8 through VPN so it's a handy hack way to securely use virtual IP based port forwarding.

  • NeoonNeoon Community Contributor, Veteran

    Well, the OS and the applications are already using it, removing it, results in higher cpu load. So usefull, keep it.

  • freerangecloudfreerangecloud Member, Patron Provider

    I volunteer for a Ham radio IP-Based microwave network and we use loopback IPs for a basic anycast setup. What we'll do is assign the anycast address to a loopback, then advertise it over OSPF, we're then able to replicate this setup over multiple servers to create some redundancy for critical services such as DNS.

    Thanked by 1florianb
  • Very interesting uses of dummy/loopback interface with non-127/8, it seem to work well.

    In Linux, as I have tested, DUMMY/LOOPBACK still could communicate with other interfaces (as per example above) even when ip forwarding is disabled, I have checked the followings:

    # sysctl net.ipv4.ip_forward
    net.ipv4.ip_forward = 0
    # sysctl net.ipv4.conf.lo.forwarding
    net.ipv4.conf.lo.forwarding = 0
    # sysctl net.ipv4.conf.eth0.forwarding
    net.ipv4.conf.eth0.forwarding = 0
    # sysctl net.ipv4.conf.tun0.forwarding
    net.ipv4.conf.tun0.forwarding = 0
    

    Do you think this is an expected behavior?

  • Assuming you're announcing a /32 over BGP to two redundant routers connected to your server on eth0 and eth1, it'd make generally sense to assign the announced /32 to a loopback interface.

    That behaviour is pretty much expected.

  • PUSHR_VictorPUSHR_Victor Member, Host Rep
    edited March 2018

    @ramnet said:

    @PUSHR_Victor said:
    The loopback is where we measure real time bandwidth of all Nginx server blocks, as well as where Linux's traffic control runs (shaping every server block separately if necessary, as each block is on it's own port). There is a "public" server block for every "private" one, which proxies to the private block and runs on port 80/443 for the public to access.

    That is quite interesting. Personally I would just use iptables to count traffic bytes and the limit/hashlimit modules of it to do traffic shaping.

    We do use iptables to count the bytes, but we need the bytes per server block per second. If all blocks were on port 80 or 443 there would be no way to distinguish them and measure their individual bandwidth. And since counting $bytes_sent from Nginx logs gives a completely wrong data on bandwidth this was the most portable and the easiest way to solve the problem across all servers at that point.

  • ramnetramnet Member, Host Rep
    edited March 2018

    PUSHR_Victor said: If all blocks were on port 80 or 443 there would be no way to distinguish them and measure their individual bandwidth.

    Just so you are aware, iptables can count bytes based on any parameter it is capable of classifying, such as on a per-IP basis. Simply add an accept rule for each thing you are trying to count.

  • PUSHR_VictorPUSHR_Victor Member, Host Rep

    Can you provide some example on how you would measure the individual bandwidth of a number of different server blocks with iptables, all running on 443 and on the same IP? I would be very interested to know more as this would simplify our stuff big way.

  • mininet/openflow

  • @florianb Could you please share your knowledge with us why that behavior is expected? (Why packets get forwarded from tun0 to dummy0 and from dummy0 to tun0 when ip-forwarding is disabled?)

    @florianb said:
    That behaviour is pretty much expected.

    http://linux-ip.net/html/routing-forwarding.html

     Operating as a router allows a linux machine to accept packets on one interface and transmit them on another. This is the nature of a router. The process of accepting and transmitting IP packets is known as forwarding. IP forwarding is a requirement for many of the networking techniques identified here. Stateless NAT and firewalling, transparent proxying and masquerading all require the support of IP forwarding in order to function correctly.
    
    The sysctl net/ipv4/ip_forward toggles the IP forwarding functionality on a linux box. Note that setting this sysctl alters other routing-related sysctl entries, so it is wise to set this first, and then alter other entries. Frequently, an administrator will forget this simple and crucial detail when configuring a new machine to operate as a router only to be frustrated at the simple error.
    
    The sysctl net/ipv4/conf/$DEV/forward defaults to the value of net/ipv4/ip_forward, but can be independently modified. In order to allow forwarding of packets between two interfaces while prohibiting such behaviour on a third interface, this sysctl can be employed. 
    
  • @job0121 said:
    (Why packets get forwarded from tun0 to dummy0 and from dummy0 to tun0 when ip-forwarding is disabled?)

    Quite simple. You could figure that out yourself simply by taking a look at the linux kernel source code:

    https://github.com/torvalds/linux/blob/master/net/ipv4/ip_forward.c
    https://github.com/torvalds/linux/blob/master/net/ipv4/ip_input.c

    In very short:

    Packet arrives at tun0, gets delivered locally to dummy0 which directly sends back the response using a FIB-lookup. The actual ip_forwarding function is not used, therefore it can't be blocked or allowed ( unless you're doing firewalling, of course ).

    Rule of a thumb: looping packets on a devices backplane isn't quite Layer 3 forwarding. Not in that case.

    Thanked by 2RickBakkr job0121
  • Thank you for the detailed, very useful and insightful. Yes indeed, corresponding to FORWARD/INPUT just like rules for iptables.

    @florianb said:
    Rule of a thumb: looping packets on a devices backplane isn't quite Layer 3 forwarding. Not in that case.

    Thanked by 1florianb
  • VPNVPN Member
    edited March 2018

    I have two Vultr instances running PiHole (properly firewalled) with a dummy interface on each and Bird and Bird6 running on both to get BGP sessions going.

    Means my devices can use one IPv4/6 address and get distributed DNS requests to both boxes.

    Hugely overkill considering it’s only about 30 devices connecting to them for DNS but then I love me some redundancy.

Sign In or Register to comment.