Page MenuHomeVyOS Platform

Loopback interface naming and dummy devices
Open, WishlistPublic


in vyos 1.2 there are two interface types named loopback and dummy this Task is a suggestion to unite the two types into ine loopback type.
also look at this vyos blog entry for reference:

A bit of background on why:
One of the main audiences for vyos are network engineers familiar with networking equipment and their configuration. Configuring routing protocols eg. ospf and bgp on almost Any vendor discusses the use of Loopback interfaces and all that i can find use the term loopback or lo to describe these interfaces .. cisco/huawei/hp: eg. Lo0 or Loopback0 . junos: eg. lo.0 and so on.

Then looking to vyos, the names are dummy dum0 ? the reason for this name is the driver that is loaded to create them (dummy). as a network engineer this naming scheme fails on every point in the book. Also, looking into the blog the blog states that: Dummy interfaces are functionally identical to loopbacks so the difference is mostly aesthetic. (i know that this is not 100% correct, but from a users point of view its good enough) .

With these things in mind my question is: From a users point of view what is the difference of the loopback and the dummy interface? i would say.. there are no difference between them, and when there are no difference, why should we bother the user with having a difference between them?

I now would propose a new naming scheeme for these interfaces:

vyos@vyos# set interfaces loopback ?
Possible completions:
 > lo           Main Loopback interface
 > loN          Dummy Loopback interface
 > dumN         Dummy Loopback interface

Here i've extended the loopback type to also include dummy interfaces, the lo interface is still the Main linux lo interface, but creating eg. lo0 or dum0 will create a dummy interface instead, but still inside the loopback type. The dumN naming scheme is still allowed because interfaces today uses that naming scheme and it might(?) be hard to create interface name change migration scripts.

The following naming scheme is quite easy to make possible by a small change in interfaces/loopback/node.def eg. like this:

priority: 300
type: txt
help: Loopback interface name
syntax:expression: pattern $VAR(@) "^(lo|lo[0-9]+|dum[0-9]+)$" ; "name must be lo, lo0-lo9999 or dum0-9999"
val_help: lo; Main Loopback interface
val_help: loN; Dummy Loopback interface
val_help: dumN; Dummy Loopback interface

create: if [ "$VAR(@)" != "lo" ]
            # Check if the dummy module is loaded
            [ -d /sys/module/dummy ] || sudo modprobe dummy
            sudo ip link add name $VAR(@) type dummy

        sudo ip link set $VAR(@) up

delete: if [ "$VAR(@)" != "lo" ]
            sudo ip link set dev $VAR(@) down
            sudo ip link delete dev $VAR(@)

the only thing necessary to implement after this is a way to disable the interface like its possible on dummy interfaces today, and i don't think that will be a big problem as long as it don't allows disabling of the linux lo interface, but only the dummy interfaces.

I'm now asking to the community and maintainers of vyos. What is your standpoint in this? if i don't get a lot of negative feedback on this i will prepare an PR for this.


Difficulty level
Unknown (require assessment)
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Config syntax change (migratable)
Issue type
Improvement (missing useful functionality)

Event Timeline

runar created this object in space S1 VyOS Public.

I think it may be a good idea.

Some considerations:

  1. Let's not use different naming, but call then "lo" and "loN" (where "lo" is the "real" loopback and the rest are dummies).
  2. Let's use it as a chance to purge at least some of the old interfaces code and rewrite the loopback and dummy parts in the new XML/Python stack
  3. We'll need a migration script to move the old dummies to their new home. Luckily, it's much less of a headache to do not.

Thanks for quick reply! :)

  1. Agreed, i omly created dum interfaces to ease migration... But if thats not an issue there is no reason to keep them
  1. Ospf syntax is still mashed-up inside the interface context.. will that be an issue if its migrated to xml/python?
  1. Sure, that wou'nt be an issue i think

I strongly disagree about mixing dummy/loopback at any of level (CLI or under the hood). Now we have two different types of interfaces: dummy and loopback with the according to names. And they are equal only if you use a dummy for the /32 addresses. In general situation:

  • Loopback interface will be used to reach any of the address inside the configured network;
  • If the IP address assigned to a dummy interface, the system will respond only to this address, not for the whole network.

Example, to be more precise:

set interfaces loopback lo address
set interfaces dummy dum1 address

root@test-06:/home/vyos# /bin/ping -c 1
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.064 ms

--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.064/0.064/0.064/0.000 ms

root@test-06:/home/vyos# /bin/ping -c 1
PING ( 56(84) bytes of data.

--- ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

There are also several another differences between these interface types.

So, now in VyOS everything is respectively to their names. I see the following ways from here, under this topic:

  • Delete dummy interface and keep only loopback with the ability to create more than one;
  • leave all as is;
  • Keep dummy and add the ability to create more than one loopback too.

As for me, the first one variant is nonsense - why we need to remove useful parts of the system? The organic way to evolution - add the ability to create more loopback interfaces. Just give them the correct names, because of loopback != dummy.

@zsdc Thanks for your comments!

I se that wee disagree on this :)

The point of this is not to follow the linux standard, but to create an environment where the user feels at home. we are here talking about a network engineer and not an experienced linux user that knows every bits and bytes of how thing is working inside the kernel.

The next point here is that loopback devices on linux does not work the way loopback interfaces on different NOS(network operating systems) work.
For the first, the loopback interface should not answer to any other address then the one configured on the interface.. if it's a /24 i only responds to the /32 address configured. And the interface type that looks most like a NOS loopback is the dummy driver.

(as for getting all addresses in a subnet to resolve this also could be done with adding a route pointing to the lo interface, and don't need to be addresses on this interface)

creating multiple loopback interfaces, is that allows on an linux system? my impression is that this should not be done (but it is possible to create aliasses)

and now for my point (seen from my network engineer eyes):
As for these points when the Network engineer create a loopback interface he actually wants a dummy interface with the name of a loopback interface.
This is especially true when we already have sed that a loopback and a dummy is the same (ref. the blogpost)

As my understanding you aren't allowed to create multiple loopback interfaces and don't se that calling dummy devices on my solution will do any harm (without the fact that a experienced linux used does need to know that this in-fact is a dummy driver device). And my solution also makes it possible to interface with the loopback driver directly so nothing is lost in that regards..

I also don't agree with you that this breaks the point that in vyos everything is in respect to its name, for my view a loopback interface is the same as a dummy interface(with the network engineer hat on), just with a different driver. that is also how it works in ethernet, we aren't calling an e1000 nic another name than eg. a realtek nic. because it uses an different driver on the backend. This has more to do with the modelling of the cli on top and the restrictions in the current cli interpreter / config interpreter.

with my last post in mind, here are the workings of a cisco IOS loopback:

router(config)#int loop 123
router(config-if)#ip addr

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 0 percent (0/5)

I agree with you on many arguments. I just wanted to say my point of view.
There are many differences between vendors: in terminology, in behavior, in technologies. This is a normal situation. The same applying to engineers - we are very diversified, and this is beautiful :).

VyOS have its own way. If we try to do the same as someone of big vendors just because they do this, then we will be fated only to be a catcher, not innovator. I believe that this is a losing strategy.

Whichever decision we make, let's not change this in 1.3—there are lots of changes already.

Hi all,

I notice this thread about dummy interfaces. I used in the past this dummy interface in my routers configuration also.
But these days I moved from simple configuration setup with GRT (Global Routing Table) to multiple VRF interfaces. Here I got complicated issues. This driver, dummy, is not able to comunicate inside of a VRF because it doesn't have a proper xmit function.
For this reason when you have a dummy interface inside of a VRF it will not respond to ping anymore, because it drops all the traffic.

For this reason I was starting a small project to build a new driver called linux-multi-loopback and based on dummy, internal linux loopback interface and VRF interfaces I created a new driver that is beheave more like a loopback interface.

You can find this project here and maybe it helps us in the future to be implemented as a Linux driver inside of kernel. It doesn't do any hacks, it just reinject the packets back to IP Linux stack.

I change a little bit also the iproute2 and I added the posibility to add / remove dinamically those interfaces via this tool. Is basically using the same part as dummy interfaces. You can find here the iproute2 version for multi loopback interfaces:

Hop it helps.

Just want to jump onto the train and say that I too like the proposal of having "lo" as the main linux kernel loopback and loN as the networking loopback who is VRF-aware aswell.

Making the renaming from dumN to loN would ease the migration from other vendors/models into VyOS (one less thing to think about what is different).

VRF-aware loopbacks are commonly used for mgmt, routing and other situations where you need an "always-on" interface.

dmbaturin triaged this task as Wishlist priority.Jan 9 2024, 4:42 PM
dmbaturin edited projects, added VyOS 1.5 Circinus; removed VyOS 1.4 Sagitta.
dmbaturin set Is it a breaking change? to Config syntax change (migratable).
dmbaturin set Issue type to Improvement (missing useful functionality).