@Viacheslav , I tested in the 1.4 version, it seems that the neighborship is stuck in ExStart state with basic config. This behavior is not seen in 1.2.5 and 1.3
And also no frr.log is created.

PR: https://github.com/vyos/vyos-1x/pull/718

To round out the effort, i've added an optional patch to the series which provides granular AAA/RBAC from ring0 and can also deliver the W^X functionality for userspace along with those functions.

Since 5.10 appears to be holding solid, and grsecurity is using 5.10 for their beta branch, i've completed the forward port of these core functions to the same kernel revision being used in the current branch (at the time of commit).
Whats the intent with Intel drivers there? If we want to pull in from Intel, i think we ought to do the same in-tree patch process to build and sign the modules at build-time (and enforce module signing validation to load at runtime).

It is also allowed in VyOS 1.2 but the Kernel errors out:

If you create a VIF and VIF-S interface with the same ID, the resulting device names collide:

This is caused by the omission of a call to conntrack --orig-dst in the new Python script.

I have successfully replicated this on 1.3-rolling-202101052023 and 1.4-rolling-202101240218. It's absent in 1.2.6. I'm going to investigate this regression.

Looks good on 1.4-rolling-202102010218 and 1.3-beta-202102010443:

Looks good on 1.4-rolling-202102010218 and 1.3-beta-202102010443:

Looks good on 1.3-beta-202102010443:

vyos@vyos:~$ configure
[edit]
vyos@vyos# set interfaces ethernet eth0 dhcpv6-options
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# exit
Warning: configuration changes have not been saved.
exit
vyos@vyos:~$ ps ax | grep dhcp6c
 1877 ttyS0    R+     0:00 grep dhcp6c
vyos@vyos:~$ show version

Looks good on 1.3-beta-202102010443:

vyos@vyos:~$ configure
[edit]
vyos@vyos# set interfaces dummy dum0
[edit]
vyos@vyos# set interfaces ethernet eth0 dhcpv6-options pd 0 interface dum0
[edit]
vyos@vyos# set interfaces ethernet eth0 dhcpv6-options duid 00:02:00:00:0d:e9:30:30:31:45:34:36:2d:58:58:58:58:58:58:58:58:58:58:58:58:58:58
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# exit
Warning: configuration changes have not been saved.
exit
vyos@vyos:~$ show version

There's an easy workaround to hack this into your "configure" scripts:

On the other hand, it will not be possible to use login with "_"
https://github.com/vyos/vyos-1x/blob/current/data/templates/accel-ppp/chap-secrets.config_dict.tmpl#L6-L8

@Viacheslav , working on it and update you soon.

@dmbaturin Hi, I would like to discuss with you the possibility of introducing load-balancing components based on direct-routing mode in VYOS. VYOS already has binary components that implement LVS

Once confirmed in 1.4 this is a good backport candidate to 1.3. Thanks!

Backported to VyOS 1.3 equuleus

I think we definitely need to try because this reproducible. @Viacheslav did you reproduce this on the ESXi hypervisor?

Only some files in /etc are adjusted by the Python scripts. We can extend the render() function to only write the file if the content changed (by either read back the content or comparind checksums of the content).

Some weirdness: vyos-rsyslog.conf looks fine even though it's also unconditionally written in generate() in src/conf_mode/system-syslog.py in vyos-1x:

grub> ls -l (hd0,msdos1)/boot/1.4-rolling-202101290218/rw/etc/rsyslog.d/       
181          20210129162817 vyos-rsyslog.conf

In the crux branch of vyatta-cfg-system, scripts/system/vyatta_update_console.pl doesn't overwrite those files unless they've changed (see update()).

I think this is just filesystem corruption caused by yanking the power to the VM. [email protected] is also showing 0 file size (both are written in generate() in src/conf_mode/system_console.py in vyos-1x):

grub> ls -l (hd0,msdos1)/boot/1.4-rolling-202101290218/rw/etc/systemd/system/
0            20210129162816 [email protected]
DIR          20210129162816 getty.target.wants/
DIR          20210129100224 ntp.service.d/
DIR          20210129100302 ssh.service.d/

Looks like grub.cfg is being overwritten (note the 0 file size):

grub> ls -l (hd0,msdos1)/boot/grub/
DIR          20210129100148 i386-pc/
DIR          20210129100144 locale/
DIR          20210129100147 fonts/
0            20210129155859 grub.cfg
1024         20210129100147 grubenv

Thanks! Backported to equuleus branch.

Thanks! Fix also backported to equuleus branch.

@SrividyaA Can you recheck it in 1.4?

PR https://github.com/vyos/vyos-1x/pull/710

PR https://github.com/vyos/vyos-1x/pull/709

New syntax could be set protocols ospf interface eth0 dead-hello-multiplier <1-10> to not have to many nesting levels. Would that work out, too?

Actually even when setting the public key manually, FRR won't show it on a subsequent run:

@matzus give us more information

I think we have a workable solution to this.

Looks good on 1.4-rolling-202101280218:

vyos@vyos:~$ configure
[edit]
vyos@vyos# set interfaces ethernet eth0 dhcpv6-options
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# exit
Warning: configuration changes have not been saved.
exit
vyos@vyos:~$ ps ax | grep dhcp6c
 1860 ttyS0    R+     0:00 grep dhcp6c
vyos@vyos:~$ show version

Looks good on 1.4-rolling-202101280218:

vyos@vyos:~$ configure
[edit]
vyos@vyos# set interfaces dummy dum0
[edit]
vyos@vyos# set interfaces ethernet eth0 dhcpv6-options pd 0 interface dum0
[edit]
vyos@vyos# set interfaces ethernet eth0 dhcpv6-options duid 00:02:00:00:0d:e9:30:30:31:45:34:36:2d:58:58:58:58:58:58:58:58:58:58:58:58:58:58
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# exit
Warning: configuration changes have not been saved.
exit
vyos@vyos:~$ show version

Development is continuing, so this PR is a draft

PR with smoketest check https://github.com/vyos/vyos-1x/pull/706

Would it be too hard to hack the legacy config management script into using systemd for scheduling reboots instead of atd?