Need to implement in customer, if I can help in something, please don't hesitate to ask.

Maybe with FRR 8.1
In any case, we'll do more tests.

It's upgrade on FRR planned?

In T3728#99683, @Viacheslav wrote:

It is possible this bug.
https://github.com/FRRouting/frr/issues/9181

It is possible this bug.
https://github.com/FRRouting/frr/issues/9181

Take a look to:

PR for 1.3 https://github.com/vyos/vyos-1x/pull/957

Did more checks.....and noticed it *IS* properly sending the ping command:

It's not a bug, it's simply a weird syntax. That command could never be used without the delete option, so your config example wouldn't work in 1.2 or 1.1.8 either.

salt-minion in the debian buster tree is version 2016.11.2+ds-1+deb9u4

Seems like the repo's not needed anymore as my iso just built without it, twice, after a clean, and with a bunch of added stuff (tor, docker, systemd-nspawn, xtables-addons, hardened-malloc, a grsec kernel, etc) for which dependencies are also available without it.
Either way, probably a good idea to keep deps for anything third-party in the vyos repo itself since third parties can become hostile through buyouts or license changes any time and anywhere in these post-FOSS times.

salt-minion which depends on salt-common which may depend on a couple of other things:

What packages are we actually pulling from there? Any reason they're not in the VyOS repo itself?
I removed their repo entirely from the JSON config and my image built fine (apparently i now have to add a /debian suffix for all packages in our repo, but that's weirdness in the repo management stack):

Reading package lists...
Building dependency tree...
Reading state information...
[2021-08-06 21:39:40] lb source 
P: Source stage disabled, skipping
P: Build completed successfully

The procedure I usually end up using:

https://repo.saltproject.io/py3/debian/10/amd64/latest buster Release looks wrong - shouldn't it read main at the end, instead of Release?

Trying to use their instructions from https://repo.saltproject.io/#debian i'm back to the certificate issue - repo is set to https://repo.saltproject.io/py3/debian/10/amd64/latest buster main and the custom GPG key has been added, but certificate checks still fail hard:

Reading package lists...
W: https://repo.saltproject.io/py3/debian/10/amd64/latest/dists/buster/InRelease: No system certificates available. Try installing ca-certificates.
W: https://repo.saltproject.io/py3/debian/10/amd64/latest/dists/buster/Release: No system certificates available. Try installing ca-certificates.
E: The repository 'https://repo.saltproject.io/py3/debian/10/amd64/latest buster Release' does not have a Release file.
E: An unexpected failure occurred, exiting...
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists...
Building dependency tree...
Del nftables 0.9.6-1 [66.8 kB]

After cleaning the chroot and retrying, it now fails utterly with the '#' in there:

Since we cannot update the kernel in 1.3 due to the QAT issues, we likely need to backport netmap support. It seems to have been introduced by this commit: https://github.com/torvalds/linux/commit/3ff7ddb1353da

@maznu
Add these lines:

Thank you for pointing that out - updated defaults.json and it seems to have made that issue go away.
For some reason its now breaking on using our internal repo (no TLS there, inside the datacenter), but i suspect its got something to do with the repo itself or some change in Debian since we started using it.

I've tested it on 1.3 with kernel 5.4.138, and for me the persistent option works as expected. I think it's a non-issue for equuleus already and the task can be closed, though I'd like other people to test that first.

Not having much luck with the build environment — and it doesn't seem to be something I've caused, because I get the same error building vyos-1x from mainline:

@stepler interesting - this bahavior changes when running from frr-reload vs. vtysh.

I think all that is required is in: https://github.com/maznu/vyos-1x/commit/68d7897622ddaa4b2e5a98d79154500b33959567

Hello, @Dmitry, I agree. I'll prepare patches for 1.3 and 1.4.

Unhelpfully it looks like Salt has changed repo: https://repo.saltproject.io/#debian

Hello @maznu , I also prefer the first variant set vpn l2tp remote-access lns host-name example.com I'm sure that we no need to overload l2tp remote-access root noded

Made the change to "do" and I noticed that.....DF is used even if there is no DF bit explicitly set...:

It seems the man page that I looked at I either didn't read carefully enough, or I completely messed it up. You're right @Viacheslav.

Did a quick test...

Already rewritten in 1.4 and 1.3 T3535
https://phabricator.vyos.net/rVYOSONEX21527ef4551613fe9b7eed9e4b2ce33ad46fe540

Hmmmm....it worked last time. I'll give it another run.

Reopen
It doesn't work properly

@stepler I created https://github.com/FRRouting/frr/pull/9281 for "easier" debugging

I tried this locally and you can do no router bgp 100 vrf blue before no vni 2000, my vtysh instance does not scream for an error - it more feels like a programming issue on our side.