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.

I figured out the order we need to remove things in:

https://github.com/vyos/vyos-cloud-init/commit/9dd5fa374ccfd74d46551641fb68428e4860b820
https://github.com/vyos/vyos-cloud-init/commit/e979e3d269ce8cbdb3933a141853bb35b9ed7b74

PR for current version https://github.com/vyos/vyos-1x/pull/952

I've cleaned the build space and rebuilt the Docker container - no dice locally or in the CI stack, still fails the same way.
It looks like they're using an AWS CA in the cert chain:

Certificate chain
 0 s:CN = repo.saltstack.com
   i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
 1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
   i:C = US, O = Amazon, CN = Amazon Root CA 1
 2 s:C = US, O = Amazon, CN = Amazon Root CA 1
   i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
 3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
   i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority

i do recall the starfield certs being a problem back in the day as well, but guessing its quite unlikely for the base build environment to have an AWS root CA in its trusted list.

I have added a test which does not let you delete the default BGP instance when VRF bound instances exist.

This is causing a configtest failure on 1.4-rolling-202107301807 stemming from not cleaning up after bgp-evpn-l3vpn-pe-router ("Cannot delete default BGP instance. Dependent VRF instances exist"):

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

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