+1

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

2. Ospf syntax is still mashed-up inside the interface context.. will that be an issue if its migrated to xml/python?

3. 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 192.168.8.1/24
set interfaces dummy dum1 address 192.168.9.1/24

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

--- 192.168.8.5 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 192.168.9.5
PING 192.168.9.5 (192.168.9.5) 56(84) bytes of data.

--- 192.168.9.5 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 1.4.4.1 255.255.255.0
router(config-if)#exit
router(config)#exit

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

router#ping 1.4.4.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.4.4.2, 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 https://github.com/EasyNetDev/linux-multi-loopback 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: https://github.com/EasyNetDev/iproute2

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.

I'd tag it as wontfix