Did anything happen to the github integration?

Will just setting it to =n solve the problem?

@oliko Could you retest it with rc9, which uses a 4.19.4 kernel?

Apparently we do not have phabricator integration setup for the ipaddrcheck repo, since it didn't pick this commit up: https://github.com/vyos/ipaddrcheck/commit/21c0775c51da1ca3d4ef6506fca82bce5b334c79

This should have been resolved by T956, but if it reappears or the fix turns out incomplete, feel free to reopen.

Since most of the work is done and every release candidate of 1.2.0 has been using FRR already, I suppose we should close it. Remaining issues that are causes by FRR incompatibilities should, and are getting their own tasks anyway.

Is the root hints file included in the package? I can't find it. Or it has a built-in list of root servers?

Since the fix is far from trivial, a workaround exists, and the entire PBR subsystem is due for a rewrite in the next release, I'm moving this to 1.3.x.

This issue existed in Quagga as well, so I'm simply disallowing decimal notation.

@Line2 Could you attach the IPsec config and the output of "sudo ipsec statusall"?

Good idea, thanks! I've applied the patch and will push it shortly.

A long standing problem indeed. StrongSWAN changed its output format, I cannot say it was for the better.

@rps Sorry for late reply. I would prefer a git format patch of course, but I've merged it by hand and it seems to work fine. It will be in tomorrow's release candidate and today's nightly build.

Looks like this was reported before we released the first version with 4.19 kernel. Please re-test with rc7 and let us know if you still have this issue.

I think I've fixed it enough to give it meaningful testing.

Deleting neighbors, as such, works, so we need an exact reproducing procedure.

Since WAN load balancing/failover is due for complete rewrite, perhaps it's better to move this to 1.3.0

It is not possible to use this exact syntax in FRR, and it's not possible to fake it in the current BGP script either. It is possible to add a new "interface" option to match the FRR CLI though.

Good ol' Occam says no. We already have a general mechanism for that, and I think as we rewrite code, we may want to get rid of the description fields that predate that mechanism.

I've also reported the issue to FRR: https://github.com/FRRouting/frr/issues/3309

The argument number in the command definition was wrong.

The last bit is blocked by https://github.com/FRRouting/frr/issues/3308 , but otherwise it's done now.

I couldn't reproduce the issue on my rc6 setup. We'll need exact reproducing steps.

The range feature is quite problematic since IPset doesn't really support ranges, and "ipset -A foo 192.0.2.10-192.0.2.20" really adds 20 addressed to the group "foo". Thus, if you add a range and then add a single address to that range, and then delete that address (or the range), your IPset setup ends up in an inconsistent state where that address is supposed to be there according to the VyOS config, but actually isn't.

I cannot reproduce it in rc6, either with zone-policy or without. I guess the pull request fixed it.

Good catch!

It's quite a shame that iproute2 can't do it on its own. I've added a workaround.

Indeed, I missed one command when adjusting the script for the new syntax!

Yeah, missing sudo. Thanks for finding it!

This is a purely cosmetic issue, but I agree, an annoying one, especially with lots of duplicate messages. I've reported the issue to FRR.

It's a classic issue. You need to create rules with "exclude" option for such networks.

For the reference, the syntax is "set interfaces tunnel tun0 parameters ip bridge-group bridge br0". It wasn't me who designed it, and I see no reasons why it was designed that way, but that's what we've got for now. We should rework the tunnel interface CLI in general and this on in particular.

Since it does no harm, I suppose we can address it when we get to rewriting those scripts.

With the new BGP syntax where IPv4 is in its own address family just like IPv6, the no default ipv4-unicast option should work as expected. See T849.