@hagbard Hello, I'll test it

@dienac Can you please test?

this commit broke it: https://phabricator.vyos.net/rVYOSONEXd76798085ea8a77ffca3c6fbb6df74fc3121c333
There may be more scripts affected.

Issue present in the 1.2.2 ISO, too

@ekim, could you make a screen record with this CLI delay?

Hello, all!
I have prepared the pull requests for fixing this bug. They add hooks for two situations:

• if VRRP configuration changed;
• if firewall settings for interface changed.

Today I experienced the same asynchronity in the OSPFv3 subsystem

https://github.com/vyos/vyos-1x/commit/65b2f36a77f311a207b8e5406d222f4dbef177cf

Thanks, the trick was adding some link-local adresses.

The protocols BGP being missing, I believe is the bug in https://phabricator.vyos.net/T1490 and actively being worked on.

This is frr show run, immediately after an upgrade to 1.2.1

@dienac Can you please test the implementation, should work in the next rolling image without any issues. Let me know if you encounter any.

I tested the following so far successful:

https://vyos.readthedocs.io/en/latest/services/pppoe-server.html#automatic-vlan-creation
https://vyos.readthedocs.io/en/latest/services/ipoe-server.html#automatic-vlan-creation

• vlan-id and range documentation for vlan_mon

https://github.com/vyos/vyos-1x/commit/14b4fa607f37b051957abc9cbe01014a610adc81

https://github.com/vyos/vyos-1x/commit/209163351c8bbd25050a6541070aa94aaff3ce08
Should be available in the next rolling build (July 9th).

Neither the CPU or memory load ever exceeds 0.5% utilization while idling. I haven't tested whether throughput or control plane timings have been impacted.

Hello, @ekim!
Such a significant increase of boot time with the same configuration is very strange, but still possible - even small changes can easily cause such behavior if you have a huge or some specific configuration. But what is more strange - CLI response time. Regardless of configuration, CLI should work without visible delays, except for autocompleting or commit operations.
Could you check the current load of the host at that moment, when CLI is slow? We must be sure that the system is not overloaded.

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

The issue can be reproduced using the sanitized configuration below:

that commit should be reworded to have the task id in front.

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.

Unfortunately the configuration is incomplete. Can you either add the missing parts or you can PM your real configuration if this works for you, or use the show configuration commands | strip-private command to remove any sensitive stuff.

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

mode 802.3ad doesn't support setting a primary interface.

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