You are right with the naming we should consider this.
Regarding differentiation between network and address lists:
The current sources are returning mixed lists containing addresses and prefixes so I would not consider having both.

A lot of work was lost in mid of the year when my not pushed changes got lost due to a hardware failure.
So I had to do the work again.

In T6486#193845, @Viacheslav wrote:

@adestis Can you add an example of the expected configuration if use-lzo-compression is configured and not configured?
https://github.com/vyos/vyos-1x/blob/e270712f7ebd76e4e1be598766d999cef4f05e26/src/op_mode/generate_ovpn_client_file.py#L57

There is another incompatibility:

Hi Giggum,
our previous solution was IPv4 only and not so nice integrated in VyOS,
therefore there are several reasons why a rework is a good idea.

I probably can continue here in summer at first.

Thank you very much!

@c-po in task T4797 (https://github.com/vyos/vyos-1x/pull/1648) you mentioned that the author should use the system task-scheduler feature.
I would understand this the same way as the author did:
The implementation of scheduling should be a module which could be reused by other features/extensions but the "cron" data should be stored separate from
what the user can schedule via the config.
But maybe you see it differently?

@Apachez I would need this feature in another feature (https://vyos.dev/T6040) to avoid a double implementation.

@TheSin- we also need this feature because our old blacklisting implementation is no longer working since the new nft implementation replaces sets after changes in the config.
So we have to go the official way and I just stumbled over your feature request when I started to make my own implementation.
Even when I have not implemented any core parts for VyOS yet, I offer my help with the implementation of this feature.

@dmbaturin I understand that show commands are already implemented via the API.
But what about commands like ping and traceroute?
Would this require much more effort?

In T5249#174317, @jestabro wrote:

@adestis
https://vyos.dev/T5976

Just a question: Would it be nice if this feature could also be combined with the commit-confirm?
e.g. like commit-confirm soft 20

Warning would be much better because it would solve the problem.
When you have the image already loaded and the system was rebooted, the image should still exist and therefore the user/pass is not required (for the moment).

Viacheslav suggested the following change which worked for me:

The same problem (container config does not get loaded) occurs, when DNS is not available for whatever reason.
This must not prevent the current container settings to be online.

I think I found the problem.

Seems like it's the same for the other functions
sudo podman ps --all vs. sudo podman ps --all --format='{{json .}}'
sudo podman network ls vs. sudo podman network ls --format='{{json .}}'

The implementation in file container.py has the command podman image ls which is ok when called from shell.
When called from API it should have been podman image ls --format='{{json .}}'

Seems like I was wrong, the content is returned but not in structured json format.
For further automation it would be nice to have json objects instead of a string which needs to be parsed by the client.

I was not aware that the nft implementation changes the kind of how groups are used.
We have implemented a blacklisting approach which heavily relates on using ipset because no one wants to have hundred thousand of addresses in the config file.
So I think this is essential, at least for us.

In T1610#110278, @jestabro wrote:

@adestis there were discussions on this in the past week --- I will be helping @dmbaturin with the task

Seems like this is already handled in T4101

I could commit a merge request but I have not figured out in which repo the file is located.

@Viacheslav steps to reproduce:

@m.korobeinikov why not use network group with /32 host addresses ?

Great. As soon as there is an example available I think I can also help provide additional commands.

Who can help with the architecture of this webservice?

When there is an example for operator rest api commands I could add some functionality.
But the architecture for such operations should be provided by someone who is deeper involved in the vyos roadmap.

So far I have seen that BFD for static routes in FRR is currently under development:
https://github.com/FRRouting/frr/issues/3369

@Cheeze_It BFD for static routes would be nice as well but sometimes the target you test against is not under your control and/or does not support BFD.

@jestabro you removed VyOS 1.2.6 does this mean it will not be included in 1.2.x ?

@c-po wrote:
I would not backport it. Its a proof of concept and things are still unclear about peer configuration (why does cumulus FRR behave differently and has no peer config) also the FRR interface is only a PoC.

Hi trae32566

It would be awsome if the feature could also be made available in the next VyOS 1.2.x version.
Because it likely takes a lot more time until version 1.3 gets released.

Hello runar,
I know that it's possible to do it manually.
But I really would like to see a more integrated solution where you can add a check for the next hop inside the configuration.

Hi zsdc,

The suggestion from @rps (XORP style) seems to be the best way from my point of view:
https://phabricator.vyos.net/V3#51

@higebu: Thank you we will give it a try.
I think that should be the default setting as long as the problem is not fixed.

In T67#1060, @dmbaturin wrote:

@brona Do you know exact reproducing procedure?
We noticed this problem with Veeam Backup and Replication tool that uses quiescence, but we could never reproduce it simply by making a snapshot of a test VM.

Maybe just bad luck, but 4x create snapshot 4x frozen router (Always on ESXi 5.5)