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