Page MenuHomePhabricator

Move nic to mac mapping out of the configuration file
Open, Requires assessmentPublic

Description

today the nic to mac address mapping is inside the configuration file, via the hw-id tag that is parsed before the configuration is loaded into the device..
This is a device specific mapping and i'm trying to change this so that the mapping is in its own config file in /config/persistant_interface_mapping (or some other name)

but, what format to use for the file...

a few examples..

>>> for k in i:
...     print("{} {}".format(k,i[k]))
...
eth2 00:00:00:00:00:02
eth1 00:00:00:00:00:01
eth0 00:00:00:00:00:00
>>> for k in i:
...     print("{}={}".format(k,i[k]))
...
eth2=00:00:00:00:00:02
eth1=00:00:00:00:00:01
eth0=00:00:00:00:00:00
>>> json.dumps(i)
'{"eth2": "00:00:00:00:00:02", "eth1": "00:00:00:00:00:01", "eth0": "00:00:00:00:00:00"}'
>>> print(yaml.dump(i,  default_flow_style=False))
eth0: 00:00:00:00:00:00
eth1: 00:00:00:00:00:01
eth2: 00:00:00:00:00:02

personally i prefer a format that is parseable line by line. So, if the user "screws up" the file in some way, only the lines the user screwed up is "lost".. all other interfaces are still going to parse in without issues. we could also have more control over what the parser does every step of the way.

using eg json, if the user misses a ' , " or : all entries in this file becomes invalid, the same is partly true with a simple yaml syntax, because the whole file would not parse on a syntax error.

I need some input on this before continuing this work, what other opinions on this are there? or is there a format i've missed completely?

Details

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

Event Timeline

runar created this task.Jul 1 2019, 8:01 PM
runar created this object in space S1 VyOS Public.
pasik added a subscriber: pasik.Jul 2 2019, 3:26 PM
c-po added a subscriber: c-po.Jul 2 2019, 9:24 PM

What is the purpose of getting the nic/mac mapping before configuration is applied? Is the result passed to a second script which pins the ethernet interface to its mac address? Why not write a script which dynamically reads the info from the config, parses it and applies further actions without the need of an intermediate file?

Or did I miss something?

runar added a comment.Jul 2 2019, 10:08 PM

The issue here is not the scripts themself, it is our(vyattas) mixing of hardware/ system configuration.. the ethernet mapping table is a device specific table that only works on one particular device, all other configuration inside vyos is portable between devices, but this information is not.
This also makes it impossible to move a config file to another hardware without modifications (removing the hw-id mappings)

The second thing here is that this modification/remapping is done prior to system load, it is udev that is responsible for this remapping and the mapping is done on a read-only filesystem so modifications are not possible to be stored directly back to the config file. (We need some kind of intermediate storage, eg /run

This modification will not create an intermidiate file before passing things to the configuration file, it will replace the current implementation and remove everything from the config file and into its own device spesific file. And thous makes the vyos config files movable between systems without modifications.

That is the idea thow :)

Right now the script first alocates interfaces with udev and stores temp files inside /run/udev, then it is a second script thats is executed inside the rl-init script that saves this info into the hw-id tags right before vyos is loaded.

Did it answer your questions?

c-po added a comment.Jul 3 2019, 10:14 PM

Thanks for the explanation

jjakob added a subscriber: jjakob.EditedJul 4 2019, 8:00 AM

I had a few (one or two) cases where I did a rolling-to-rolling offline migration (installed the new rolling to a clean drive and copied the old config dir into new image's /boot/<image>/rw/) that the interface naming got completely screwed up, creating new eth devices in the config with higher numbers and leaving the config defined ones inactive, I then had to rescue the situation manually on console (don't remember how exactly). I probably should've created a issue then but I was just glad it was over with. Hopefully this does something to improve the situation as I'm now hesitant to do remote upgrades for fear of losing connectivity...

runar added a comment.Jul 4 2019, 1:59 PM

As for now, the mapping scheme is done with mac adress=>name, so as long as the mac address dont change and you preserve the persistent interface mapping file you should be all good.. i'm wondering if its possible to migrate from a mac-address mapping scheme to instead use eg. Pci index.. but havent found any good solution on this.. the best i've found is to start using systemd and rewrite all occations that has hardcoded eth name mappings.. but thats a bigger case i think.. so for now it's going to be mac address=>name

runar added a comment.Jul 4 2019, 2:07 PM

As i commented : the best i've found is to start using systemd and rewrite all occations that has hardcoded eth name mappings.. but thats a bigger case i think..

There is some further discussion here, which I found useful in considering the changes for Stretch:

https://lists.debian.org/debian-user/2017/07/msg01453.html

runar added a comment.Jul 6 2019, 10:41 PM

I've updated all found instances of hardcoded eth instances to also take systemd interfaces names. this will be working when were upgrading to buster.. i've built an iso with these changes and i'm able to set an ip on my ens3/ens4 nic's and it works. for buster this could be a solution on this issue. the question then is if buster comes soon enough to not rewrite these scripts until then.

The largest issues with using systemd interface naming is that it requires an interface rename on upgrade (migration script?) and the user won't get a name mapping stating from zero as it is today.
But it will be a more consistent naming scheme on devices with the same hardware.
I don't have much experience in the naming scheme yet, but at least my qemu vm's gets ens3, ens4++ nics in ascending order as the nic's are on pcibus 0, slot 3 and 4.
My qotom device will get interfaces enp1s0, enp2s0, enp3s0 and enp4s0 as theire all slot0 on their own dedicated pcie bus'es bus 1-4.
multiport nic's will also be group'ed together by the pcibus, slot and port number syntax enp3s0f0 for the first port on a multi-nic card in pcie bus 3 slot 0