Loopback and the dummies

"There is no place like 127.0.0.1" the old saying goes. While the loopback interface is most often seen as the interface where the 127.0.0.1 address is assigned by default and where the 127.0.0.0/8 network is routed, and just a way for programs on the same host to communicate over the network without actual network, it has uses in networked context as well.

Before we talk about those use cases, we need to discuss interfaces themselves. In some OSes, such as Cisco IOS, and many BSD derivatives, it is possible to create multiple loopbacks. Linux kernel (and thus VyOS) historically allowed only one loopback (named "lo"), and this behaviour has become too traditional and relied upon to change overnight, so to implement multiple loopback, a new interface type called "dummy" was added. Dummy interfaces are functionally identical to loopbacks so the difference is mostly aesthetic.

This is how to setup a dummy interface: "set interfaces dummy dum0 address ...". If your problem does not require independent interfaces, you can also just add another address to the loopback.

So, why would one want to use a loopback/dummy interface instead of assigning another address to a physical NIC?

Case 1: tunnel endpoints

We have already talked about GRE/IPsec behind NAT and/or with dynamic addresses. Since GRE requires fixed local and remote endpoint  addresses to work, and in a setup where dynamic addresses or NAT is involved you do not have fixed addresses, the trick is to use a pair of addresses made up specially for this purpose as GRE endpoints.

Case 2: management addresses

Suppose you have a router A with two NICs, connected to networks B and C that are connected to each other, so that if any of the links fails, the network as a whole is still operational. However, if you choose either NIC A or NIC B address as a management address, it may become inaccessible if one of the NICs fail, forcing you to manually fall back to the other address.

To prevent this situations, people often assign a dedicated management address to a loopback, create a DNS record for it, and advertise that address to all other routers so that as long as there is at least one path to that router that works, they do not need to worry about addresses of physical NICs to SSH to the router, and are free to change those addresses without having to update the DNS or memorize the new address.

Case 3: iBGP peer addresses

Since iBGP uses the same autonomous system number for all routers, it loses the ability to use AS path for path selection and loop detection. This means to keep the network loop-free, one has to setup it as a full mesh, or use a route reflector.

If we use addresses of physical NICs for session endpoints, we run into the same problem as in the previous use case: a session goes down with the link even if there are other valid paths. A possible solution is to select dedicated addresses for iBGP sessions, assign them to loopbacks, and advertise them to all other routers through a link-state protocol such as OSPF.

Your use case?

If you know other cases when a network setup can be improved by using loopback or dummy interfaces, let us know!

2 responses
A great use case is for troubleshooting routing issues also. Assigning a /32 or /128 to a loopback from a larger block of IP’s allows you to easily verify packets for that subnet are reaching the device, or if you source packets from the loopback you can validate that packets from that subnet are reaching the destination from that part of the network. You could also use loopbacks to spoof other IP’s and offer services up on them in place of the real service. This might be useful in corner cases where settings for some service cannot be changed for whatever reason and you need it to function with the legacy IP address.
On a most proprietary network OS loopbacks can be used to statically place subnet routes (for redistribution or for blackholing). On Linux it works, but needt to know that all addresses from subnet assigned to loopback becomes "local" to system, which can be undesirable. Better use "unreachable"- or "blackhole"-type routes for this. Other case from proprietary world is to use loopback interface as donor for unnumbered IP interfaces, but in Linux "unnumbered" behavior can be done by "direct" routes (which currently is not supported by VyOS, afaik) and assigning same IP/32 to all necessary interfaces without "borrowing" addresses . The one annoying thing in VyOS is that you need to configure "input" firewall for EVERY ip interface on system. In most cases it only increases "human factor" and just adds another place for "easy-to-forget" misconfig. In J, fo example, applying firewall policy to loopback interface acts like "INPUT" and "OUTPUT" chains from Linux iptables, which is very handily.