Difference between loopback and dummy interfaces for use in Linux routing
Hi, I’m learning about IP-networking and am in the process of setting up a Linux router using bird. During my research I’ve come across the usage of loopback interfaces. I could gather that this is done, because Ethernet interfaces for example (in contrast to loopbacks) can go down making the addresses configured on them unavailable. In addition, the kernel accepts packets destined to loopbacks addresses on other interfaces making these addresses available on multiple interfaces and not just the loopback. On Linux I found both the lo(opback), and dummy interfaces recommended to achieve the behavior outlined above. What I’m struggling with is understanding the differences between both interface types (besides the obvious difference in packet processing) and when to use which. Searching this mailing list I’ve seen people use lo, on other sites dummy interfaces are recommended. From a quick test (assigning address to lo/dummy; pinging/receiving pings on the host) I wasn’t able to find a difference. When should I use which interface? Cheers, Wilhelm.
Hi. There isn't a difference from perspective of routing. On 27 April 2018 at 11:52, Wilhelm Schuster <ws@rot13.io> wrote:
Hi,
I’m learning about IP-networking and am in the process of setting up a Linux router using bird. During my research I’ve come across the usage of loopback interfaces. I could gather that this is done, because Ethernet interfaces for example (in contrast to loopbacks) can go down making the addresses configured on them unavailable. In addition, the kernel accepts packets destined to loopbacks addresses on other interfaces making these addresses available on multiple interfaces and not just the loopback.
On Linux I found both the lo(opback), and dummy interfaces recommended to achieve the behavior outlined above. What I’m struggling with is understanding the differences between both interface types (besides the obvious difference in packet processing) and when to use which. Searching this mailing list I’ve seen people use lo, on other sites dummy interfaces are recommended. From a quick test (assigning address to lo/dummy; pinging/receiving pings on the host) I wasn’t able to find a difference.
When should I use which interface?
Cheers, Wilhelm.
-- Anton.
Hi, One of the differences is when you configure some prefix on lo you get route like this: local 127.0.0.0/8 dev lo ... And with dummy it is not the case. This route type makes kernel consider every address from this space as local - bind on it, reply to pings etc. On Fri, Apr 27, 2018 at 11:40 AM, Anton Danilov < littlesmilingcloud@gmail.com> wrote:
Hi. There isn't a difference from perspective of routing.
On 27 April 2018 at 11:52, Wilhelm Schuster <ws@rot13.io> wrote:
Hi,
I’m learning about IP-networking and am in the process of setting up a Linux router using bird. During my research I’ve come across the usage of loopback interfaces. I could gather that this is done, because Ethernet interfaces for example (in contrast to loopbacks) can go down making the addresses configured on them unavailable. In addition, the kernel accepts packets destined to loopbacks addresses on other interfaces making these addresses available on multiple interfaces and not just the loopback.
On Linux I found both the lo(opback), and dummy interfaces recommended to achieve the behavior outlined above. What I’m struggling with is understanding the differences between both interface types (besides the obvious difference in packet processing) and when to use which. Searching this mailing list I’ve seen people use lo, on other sites dummy interfaces are recommended. From a quick test (assigning address to lo/dummy; pinging/receiving pings on the host) I wasn’t able to find a difference.
When should I use which interface?
Cheers, Wilhelm.
-- Anton.
On 2018-04-27 12:59, Alexander Zubkov wrote:
One of the differences is when you configure some prefix on lo you get route like this: local 127.0.0.0/8 [1] dev lo ... And with dummy it is not the case.
It could be done manually with any interface, actually: # ip route add local 192.168.128.0/24 dev dummy table local And you don't even need to add address from this range to the interface, or bring it up - just a route is enough to make the system respond to (or bind to) the whole range (unless, of course, there are firewall or other explicit restrictions). Best regards, Alexander.
Yes. But with lo interface you get such route by default. On Fri, Apr 27, 2018 at 3:04 PM, Alexander Demenshin < aldem-bird.201704@nk7.net> wrote:
On 2018-04-27 12:59, Alexander Zubkov wrote:
One of the differences is when you configure some prefix on lo you get
route like this: local 127.0.0.0/8 [1] dev lo ... And with dummy it is not the case.
It could be done manually with any interface, actually:
# ip route add local 192.168.128.0/24 dev dummy table local
And you don't even need to add address from this range to the interface, or bring it up - just a route is enough to make the system respond to (or bind to) the whole range (unless, of course, there are firewall or other explicit restrictions).
Best regards, Alexander.
There's quite good article discussing that: https://b4ldr.wordpress.com/2014/09/06/dummies-link-local-and-the-loop-back/ On 04/27/2018 10:52 AM, Wilhelm Schuster wrote:
Hi,
I’m learning about IP-networking and am in the process of setting up a Linux router using bird. During my research I’ve come across the usage of loopback interfaces. I could gather that this is done, because Ethernet interfaces for example (in contrast to loopbacks) can go down making the addresses configured on them unavailable. In addition, the kernel accepts packets destined to loopbacks addresses on other interfaces making these addresses available on multiple interfaces and not just the loopback.
On Linux I found both the lo(opback), and dummy interfaces recommended to achieve the behavior outlined above. What I’m struggling with is understanding the differences between both interface types (besides the obvious difference in packet processing) and when to use which. Searching this mailing list I’ve seen people use lo, on other sites dummy interfaces are recommended. From a quick test (assigning address to lo/dummy; pinging/receiving pings on the host) I wasn’t able to find a difference.
When should I use which interface?
Cheers, Wilhelm.
On 2018-04-27 13:08, Daniel Suchy wrote:
There's quite good article discussing that: https://b4ldr.wordpress.com/2014/09/06/dummies-link-local-and-the-loop-back/
Thank you for providing the link. Though I'm not sure if I fully understand the implications of the post: In the conclusion they wrote:
Using the loopback interface caused other issues due to the fact that there is no link-local address. with the loopback interface the next hop for the default route becomes unreachable due to the lack of a link-local address so it is probably best to stick with the dummy interface
root@router1:~# ip -6 route 2001:db8:1::/64 dev zzz0 proto kernel metric 256 unreachable 2001:db8::/47 dev lo proto kernel metric 256 error -101 fe80::/64 dev zzz0 proto kernel metric 256 unreachable fe80::/64 dev lo proto kernel metric 256 error -101 unreachable default dev lo proto zebra metric 1024 error -101
Why does the lack of a link-local address result in the default route being marked unreachable? I'm guessing this is, because the lack of a link-local address implies that the interface is not on a IPv6 link and thus won't be able to reach another host (since the v6 spec requires interfaces to at least have a link-local address).
On 04/27/2018 10:52 AM, Wilhelm Schuster wrote:
Hi,
I’m learning about IP-networking and am in the process of setting up a Linux router using bird. During my research I’ve come across the usage of loopback interfaces. I could gather that this is done, because Ethernet interfaces for example (in contrast to loopbacks) can go down making the addresses configured on them unavailable. In addition, the kernel accepts packets destined to loopbacks addresses on other interfaces making these addresses available on multiple interfaces and not just the loopback.
On Linux I found both the lo(opback), and dummy interfaces recommended to achieve the behavior outlined above. What I’m struggling with is understanding the differences between both interface types (besides the obvious difference in packet processing) and when to use which. Searching this mailing list I’ve seen people use lo, on other sites dummy interfaces are recommended. From a quick test (assigning address to lo/dummy; pinging/receiving pings on the host) I wasn’t able to find a difference.
When should I use which interface?
Cheers, Wilhelm.
On 04/27/2018 02:52 AM, Wilhelm Schuster wrote:
Hi,
Hi,
I could gather that this is done, because Ethernet interfaces for example (in contrast to loopbacks) can go down making the addresses configured on them unavailable.
That's one of the reasons that loopbacks (or dummies) are used. Another is the fact that you can have an arbitrary interface that does not require associated hardware.
In addition, the kernel accepts packets destined to loopbacks addresses on other interfaces making these addresses available on multiple interfaces and not just the loopback.
My experience (primarily in Linux) suggests that this is the case with all interfaces by default, not just loopback (or dummy) interfaces. There are some /proc (and likely /sys) tuneables that can alter this default behavior.
What I’m struggling with is understanding the differences between both interface types (besides the obvious difference in packet processing) and when to use which.
My understanding is that it's not possible to add additional loopback interfaces on Linux. Instead dummy interfaces are added and removed on Linux like loopbacks are added and removed on other NOSs. (I know that you can create and remove loopback interfaces at whim on classic Cisco IOS.) I personally use lo exclusively for localhost and dummy interfaces for anything else that needs a loopback like interface. The only real nuanced difference that I've been able to find is that the lo interface automatically adds the 127.0.0.1/8 IP address when you bring the interface up. Where as dummy interfaces do not add any IP addresses automatically. The only other thing that I've found is that lo doesn't add the 127.0.0.0/8 prefix to the routing table. Conversely if you down lo and add 127.0.0.1/8 to dummy0, you do get the 127.0.0.0/8 prefix in the main routing table. I feel like the lo interface does some tricks and / or takes some shortcuts to try to be helpful. -- Grant. . . . unix || die
On 2018-04-27 17:48, Grant Taylor wrote:
On 04/27/2018 02:52 AM, Wilhelm Schuster wrote:
Hi,
Hi,
Thank you for the explanation.
What I’m struggling with is understanding the differences between both interface types (besides the obvious difference in packet processing) and when to use which.
My understanding is that it's not possible to add additional loopback interfaces on Linux. Instead dummy interfaces are added and removed on Linux like loopbacks are added and removed on other NOSs. (I know that you can create and remove loopback interfaces at whim on classic Cisco IOS.)
Can you give a scenario where I would want to use multiple dummy's instead of just adding/removing addresses to the loopback interface? I can't use a dummy interface for "real" packet processing since it just drops the packet. If the use case is to make addresses from loopback/dummy available on other interfaces, then does it matter if those addresses originally came from a single lo or multiple dummy's? Cheers, Wilhelm.
Anno domini 2018 Wilhelm Schuster scripsit: Hi,
Can you give a scenario where I would want to use multiple dummy's instead of just adding/removing addresses to the loopback interface? I can't use a dummy interface for "real" packet processing since it just drops the packet. If the use case is to make addresses from loopback/dummy available on other interfaces, then does it matter if those addresses originally came from a single lo or multiple dummy's?
I use dummy interfaces for service IPs which are then distributed by BGP inside my networks. So I have three use cases: 1. real loopback (lo): Loopback IP (v4+v6) where v4 == router-ID in OSPF 2. dummy interface for local services ('srv') for services which are exclusivly run on this box. 3. dummy interface for anycasted services ('anycast_srv') for services where on instance is running on this box. This way it's easy to have different direct protocols in bird and easily tag, filter and/or announce prefixes within your network accordingly. real loopback IPs are part of the IGP (OSPF), both 2 and 3 are read by instances of protocol direct and distributed by (i)BGP. Best Max -- "Wer nicht mehr liebt und nicht mehr irrt, der lasse sich begraben." -- Johann Wolfgang von Goethe
On 2018-04-27 21:47, Maximilian Wilhelm wrote:
This way it's easy to have different direct protocols in bird and easily tag, filter and/or announce prefixes within your network accordingly. real loopback IPs are part of the IGP (OSPF), both 2 and 3 are read by instances of protocol direct and distributed by (i)BGP.
I didn't consider that, but it looks like an interesting approach. Reading the bird documentation, it slightly discourages from using the direct protocol:
The question is whether it is a good idea to have such device routes in BIRD routing table. OS kernel usually handles device routes for directly connected networks by itself so we don't need (and don't want) to export these routes to the kernel protocol. OSPF protocol creates device routes for its interfaces itself and BGP protocol is usually used for exporting aggregate routes. But the Direct protocol is necessary for distance-vector protocols like RIP or Babel to announce local networks.
Though, I'll definitely be trying it out. Cheers, Wilhelm.
Anno domini 2018 Wilhelm Schuster scripsit:
On 2018-04-27 21:47, Maximilian Wilhelm wrote:
This way it's easy to have different direct protocols in bird and easily tag, filter and/or announce prefixes within your network accordingly. real loopback IPs are part of the IGP (OSPF), both 2 and 3 are read by instances of protocol direct and distributed by (i)BGP.
I didn't consider that, but it looks like an interesting approach. Reading the bird documentation, it slightly discourages from using the direct protocol:
The question is whether it is a good idea to have such device routes in BIRD routing table. OS kernel usually handles device routes for directly connected networks by itself so we don't need (and don't want) to export these routes to the kernel protocol.
That's true. And bird does not export devices routes back into the kernel if you don't force it to. So that's a non-issue.
OSPF protocol creates device routes for its interfaces itself
Also true. But if you want to run a SP like backone, you don't want to carry routes for services within the IGP. If OSPF is ok for you, making the lo/dummy interface a stub interface will get you a similar effect and you are done.
and BGP protocol is usually used for exporting aggregate routes.
The keyword here is 'usually'. If we are talking about eBGP between different organisations, this will mostly be the case. If we are talking about iBGP within your network, BGP can carry quite a lot of /32 and/or /128 routes for (anycasted) services.
But the Direct protocol is necessary for distance-vector protocols like RIP or Babel to announce local networks.
That's an entire different story :) Best Max -- "Does is bother me, that people hurt others, because they are to weak to face the truth? Yeah. Sorry 'bout that." -- Thirteen, House M.D.
On 04/27/2018 10:26 AM, Wilhelm Schuster wrote:
Thank you for the explanation.
You're welcome.
Can you give a scenario where I would want to use multiple dummy's instead of just adding/removing addresses to the loopback interface?
I like the idea that lo is used exclusively by the localhost and there is no non-local traffic to / from it. — With this in mind, it's entirely possible to add a dummy interface to bind a service that does communicate with non-local systems. Thus maintaining lo for local only traffic.
I can't use a dummy interface for "real" packet processing since it just drops the packet.
You absolutely can use a dummy interface for real traffic. Or at least you can use it like you can use a loop back. You can easily bind a routed IP address to a dummy interface and use that to communicate with other machines. I think it's common for BGP neighbor sessions to be terminated on a dummy address (much like Cisco uses loop backs.)
If the use case is to make addresses from loopback/dummy available on other interfaces, then does it matter if those addresses originally came from a single lo or multiple dummy's?
I don't know that it technically matters. I have heard of people using it as a mechanism to enable isolating lo for pure loop back / local host services. Read: soft under belly of the system. Conversely, dummy can act like another NIC connected to a switch to bring the link up and nothing else connected. I think there was a time when the loop back interface had hard isolation in the kernel such that no non-local traffic could get into / out of the lo interface. Thus you had to use something like dummy to bind BGP to if you wanted to be link agnostic. My recent tests indicate that there is not currently a hard isolation like this in the kernel that I'm running. -- Grant. . . . unix || die
participants (7)
-
Alexander Demenshin -
Alexander Zubkov -
Anton Danilov -
Daniel Suchy -
Grant Taylor -
Maximilian Wilhelm -
Wilhelm Schuster