Had a long 4th of July weekend, but the issue appears to be resolved in 1.2.0-rolling+201907080337.

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.

need some info since the standard way of migrating the leafNode doesn't work as expected.

For my point of view this is a dependency from the bfd protocol specs.

Just a comment: wouldn't have these configuration options be inferred from the peer they're on?

Fix is commited in current branch (rolling/Equuleus), it can be tested with the latest rolling build and task status updated.

@hagbard Ok, if you need any help just hit me :)

@dienac Yup, thx. Already found that out. I'm already started with the implementation.

@hagbard Yes, it can be used with IPoE and PPPoE

@dienac Are you sure you mean pppoe and not IPoE?

The rewrite has been complete in the fork for some time, but is on hold pending: (1) consider taking advantage of the functionality in https://github.com/vyos/vyos-1x/blob/current/python/vyos/configsession.py to avoid duplication of code (2) ongoing work on options to replace the python list manipulations in the current rewrite. Regarding the latter point, it was expected that there would be a performance hit in moving away from the legacy C++ backend (via Perl bindings), and the cost was considered worthwhile in order to move forward; one data point is a performance hit of .3 on a 17k line config file, which was not bad, considering.

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

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

Also to consider, if going to a different naming scheme: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

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

There is one other use of XorpConfigParser (in the vyatta-config-migrate package), that was not mentioned in the above: the scripts used for persistent interface naming; this is currently being rewritten and reorganized in T1499: 'Move nic to mac mapping out of the configuration file'.

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

Thanks for the explanation

@Dmitry that was actually I had in mind when I was implementing it. Otherwise it's hard to monitor if you want to have it down to specific ways it does route the traffic. Let's see if the community requests something like that. It would mean a whole buch of more flexibility but also way more items to configure and verify. IPv6 would be global anyway, so the only way there would to disable IPv6 on an interface, the subnets on Ipv6 are usually big enough, so it would only come down to Ipv4 anyway.

@hagbard I think authentication must work without any changes, but we just may use shared ip-address pool for any numbers of interfaces. If used current schemas, we will need adding ip-range for everyone interfaces.

@Dmitry What would be the benefit for that? You would lose the ability to authenticate a particular mac address via a specific interface, wouldn't you?

@mb300sd do you know how long it takes for the config to load for you? because the /etc/resolv.conf file is persistent. but on loading the config it should do the 'set system nameserver 2001:470:20::2' and overwrite the resolv.conf file.

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)

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?

Yeah, that's the one I just installed.

@mb300sd i just created this one https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201907022116-amd64.iso did you already test with it?

Still using the dhcp servers on 1.2.0-rolling+201907022116. Will post back in a few hours if the one with a bunch of lines happens again.

Not sure when the messed up one with all the lines happens, it wasn't right after commit, seemed to be after sitting for a few hours, but it was broken again when I tried to add system image just now.

@UnicronNL yes. On boot it creates the resolv.conf with DHCP nameservers and missing the domain/search options. If I commit, it generates one with my configured servers and the domain/search options.

@mb300sd
could you please retest it with:
https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201907022116-amd64.iso

Tested with:
set service ipoe-server authentication interface eth2 mac-address 08:00:27:2F:D8:06
set service ipoe-server authentication interface eth3 mac-address 08:00:27:2F:D8:06
set service ipoe-server authentication mode 'local'
set service ipoe-server client-ipv6-pool delegate-prefix '2001:db8:1::/48,56'
set service ipoe-server client-ipv6-pool delegate-prefix '2001:db8:2::/48,56'
set service ipoe-server client-ipv6-pool delegate-prefix '2001:db8:3::/48,56'
set service ipoe-server client-ipv6-pool prefix '2001:db8::/48,64'
set service ipoe-server dnsv6-server server-1 '2001:db8::'
set service ipoe-server dnsv6-server server-2 '2001:db8:aaa::'
set service ipoe-server dnsv6-server server-3 '2001:db8:bbb::'
set service ipoe-server interface eth2 client-subnet '192.168.0.0/24'
set service ipoe-server interface eth3 client-subnet '192.168.1.0/24'

So in my testing of VyOS - after tinkering with an edgerouter, this is a kinda major feature to be lacking...

I was able to reproduce your first issue...

@mb300sd can you share your config maybe?

@mb300sd do you mean after a fresh boot you get:

Updated to latest rolling, 1.2.0-rolling+201907020337

IPv6 is all static - he.net tunnels. Will try the rolling when it's up.

@mb300sd is the ipv6 address provided via dhcp?

It's at&t's dhcp server, I have no idea what they run.

@mb300sd what is the dhcp server you are using?
Could you also please share the content of the files:
/etc/resolv.conf.dhclient-new-eth0 (or other interface if you use an other)
/etc/resolv.conf.dhclient-old-eth0 (or other interface if you use an other)

@c-po @mb300sd found the issue 'Nameservers are not propagated into resolv.conf' (no script in node def) , also the issue with the split ipv6 does not seem to be in host_name.py, will look a bit further for that.

I was check ipoe local user authentication, with next config:

The difference might be because my IPv6 server is first, but I'm also experiencing the non-update when I try to add 1.1.1.1 to see if having an IPv4 server first helps.

Putting the migration script on hold until I can get sample configs for "service dhcp6-server static-mapping identifier ..." and related host entries in /etc/dhcp/dhcpdv6.conf from an old vyos version with the old vyatta-cfg-dhcp-server scripts.
In particular if it was possible to set quoted strings as identifier which would be set unchanged in dhcpd6.conf, this would necessitate detecting whether the identifier was a quoted string or not, and converting the string to hex. If it wasn't possible to set quoted strings the migration script is not necessary.

https://vyos.readthedocs.io/en/latest/services/ipoe-server.html

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb
Will build an iso with it too, shouldn't be that much different from a functional point of view.