https://github.com/vyos/vyos-1x/pull/1665

as we talked , this behavior is the same on vyos1.3.x/frr7.5.x . the main difference is that on vyos-cli doesn't add this command .

In T973#137840, @elico wrote:

@Viacheslav I want to test this, what should be done?

@Arc771 Thanks, Could you check it in the next rolling release after 20221118?

@DerEnderKeks Could you check it in the next rolling release after 20221118?

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

@Viacheslav I want to test this, what should be done?

I guess it was implemented in the T4750
Should be easy to fix

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

@marc_s thanks for testing !

Added file:// parser to vyos.remote.download and used that to simplify the code, no need to check if it's local now.

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

Now as linux-cp available we can consider adding support

https://www.youtube.com/watch?v=D7PF1cOAAUk&ab_channel=DENOG

thank you

https://github.com/vyos/vyos-1x/pull/1661

Hello sir,

Pull request: https://github.com/vyos/vyatta-cfg-system/pull/189

We figured out the problem. So for OSPF segment routing to work we need to enable opaque LSA capabilities. So by default VyOS doesn't have opaque LSAs (type 9, type 10, type 11) enabled. So after checking the configuration for the OSPF FRR template I noticed that the actual command to enable opaque LSAs is broken because it's not in the OSPF FRR template. Once we fix that, we'll have working OSPF segment routing.

First of all, sorry for my late reply. I was on vacation and stayed away from IT for a bit ;)

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

vyos@r14:~$ show vpn ipsec connections 
Connection         State        Type    Remote address    Local TS        Remote TS    Proposal
-----------------  -----------  ------  ----------------  --------------  -----------  ---------------------------------------
OFFICE-B           established  IKEv1   192.0.2.2         -               -            AES_CBC/256/HMAC_SHA2_256_128/MODP_1024
OFFICE-B-tunnel-0  up           IPsec   192.0.2.2         192.168.0.0/24  10.0.0.0/21  AES_CBC/256/HMAC_SHA2_256_128/MODP_1024
OFFICE-B-tunnel-1  down         IPsec   192.0.2.2         192.168.1.0/24  10.0.0.0/21  -
OFFICE-B-tunnel-2  down         IPsec   192.0.2.2         192.168.2.0/24  10.0.0.0/21  -
OFFICE-C           down         IKEv1   192.0.2.2         -               -            -
OFFICE-C-tunnel-0  down         IPsec   192.0.2.2         192.168.5.0/24  10.0.0.0/21  -
vyos@r14:~$

@rcit I can assure you were never planned to explicitly disallow embedded IPv4 notation. Moreover, I thought the current validator supports it, even though we didn't have tests for it. I'll take a look!

Created PR to fix this: https://github.com/vyos/vyos-1x/pull/1656
This issue also exists in 1.3 though I didn't backport it.

https://github.com/vyos/vyos-1x/pull/1655

I seem to have jumped the gun a bit as the issue seems to have been resolved via:

@c-po I think the reason you're seeing the old name of 'pdns-r/worker' is due to a packaging regression described in T4814. All the latest builds of vyos 1.4 seem to be providing powerdns 4.4 instead of the expected 4.8. Since this issue and corresponding bugfix only pertains to powerdns >= 4.8, the issue would not be visible if powerdns is downgraded to 4.4.

Just as a point of additional reference, I've bisected the PowerDNS source code to see where the change from 'pdns-r/worker' to something else occurred and successfully found that commit 69b39198 in the repository changes the thread names away from the prefix of 'pdns-r'. Since that change, the string pdns-r/ no longer exists in the source code. The aforementioned commit is included in the following tags:

PR for policy route refactor updates to vyos_mangle: https://github.com/vyos/vyos-1x/pull/1654

or maybe better add this subsection in firewall section?

Relevant PR:

Hmm, I can't seem to reproduce that name with "pdns-recursor/now 4.8.0~beta1-1pdns.bullseye amd64" or "pdns-recursor/now 4.8.0~beta2-1pdns.bullseye amd64" both in a live bare-metal system or in a VM. Both versions return pdns_recursor for me when printed from p.name(). The worker thread names (as listed from ps or htop) also don't match: "rec/web+stat" and "rec/taskThread", not that either of these are returned by p.name().

We use p.name from process_iter and it returns pdns-r/worker. That‘s why I have reverted the commits as in the latest 1.4 VyOS iso with PDNS 4.8 beta it‘s how they names the worker thread

list/lists in config and op-mode now moved to external-list