Page MenuHomePhabricator

Loopback interface naming and dummy devices
Open, Requires assessmentPublic

Description

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: https://blog.vyos.io/loopback-and-the-dummies

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:

tag:
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" ]
        then
            # Check if the dummy module is loaded
            [ -d /sys/module/dummy ] || sudo modprobe dummy
            sudo ip link add name $VAR(@) type dummy
        fi

        sudo ip link set $VAR(@) up

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

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.

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close

Event Timeline

runar created this task.Jun 21 2019, 7:29 PM
runar created this object in space S1 VyOS Public.
runar updated the task description. (Show Details)Jun 21 2019, 7:32 PM
runar updated the task description. (Show Details)Jun 21 2019, 9:34 PM

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
zsdc added a subscriber: zsdc.Jun 22 2019, 6:36 PM

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.

runar added a comment.Jun 22 2019, 8:12 PM

@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.

runar added a comment.Jun 22 2019, 8:32 PM

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)
zsdc added a comment.Jun 22 2019, 9:17 PM

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.