There have been some deletion errors yesterday - are you running the latest rolling release? They should have been fixed in there. If noe please provide me some CLI samples to reproduce the issue.

Check out the October versions on both sides.

I spoke to soon.
The interfaces are very persistant now - when you delete the vtun interface it doesn't get taken down!

Tested in my lab and it works both during creation and reboot.

Submitted PR

Works for me!

trae@cr01b-vyos:~$ show protocols bfd peers
Session count: 11
SessionId  LocalAddress                             PeerAddress                             Status         
=========  ============                             ===========                             ======         
3776760774 192.168.253.3                            192.168.253.7                           up             
1851352402 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:6       up             
3344115206 192.168.253.3                            192.168.253.2                           down           
1252680903 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:2       down           
3664188082 192.168.253.3                            192.168.253.6                           up             
2809207409 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:1       up             
2086113021 192.168.253.3                            192.168.253.12                          up             
1362288442 unknown                                  fd52:d62e:8011:fffe:192:168:253:12      down           
3846665654 fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:7       up             
276439511  fd52:d62e:8011:fffe:192:168:253:3        fd52:d62e:8011:fffe:192:168:253:12      down           
1342044518 192.168.253.3                            192.168.253.1                           up

Well spotted - i hadn't seen that option before.
I'll give it a go and see how it runs.

I agree. Therefore, if someone understands the code structure of FRR, we can modify the implementation from within FRR according to Prometheus protocol framework, implement the exporter integration, and then generate a patch file. Set the automatic compilation script and automatically package it into DEB

The best possible solution would be for FRR to support Prometheus directly, rather than require an exporter.

It seems that calling openvpn --mktun is what we need. Please try the next rolling ISO which will contain a fix for this.

It is true, but I just want to record it to avoid forgetting that another solution is to redevelop FRR and promote it in parallel with the official version of FRR (in other words, we can patch FRR or maintain a branch separately, then compile a version of our own, and get the indication directly from its code, but this work needs someone to do.)

Timeouts and SIGKILL don't always work. If process is stuck on IO, it will not exit.

I think I understand what you mean. Don't worry. I'm also a user of Prometheus. I know how Prometheus works.

I'm not sure you understand how this works.

Most of Prometheus data is generated from the exporter. It is not collected and pushed in real time. When Prometheus queries, it can query relevant indications through the port exposed by the exporter. Therefore, I don't think it is possible to create thousands of sub processes/threads. What do you think?

No, that's not the problem. The exporter itself could potentially create thousands of sub processes if something were to go wrong.

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

I know, that my specific problem is related to OpenVPN, but are you saying, that this is only relevant for OpenVPN and it's not going to impact other interfaces?

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

@runar Some interesting commands, such as tinc - n netname join URL, seem to be supported in tinc1.1

The frr_exporter linked uses os/exec to run an external binray, /usr/bin/vtysh. This is not a great way to build an exporter, as it can lead to a fork bomb. There is also the overhead of calling the external binary to gather data.

The frr_exporter linked uses os/exec to run an external binray, /usr/bin/vtysh. This is not a great way to build an exporter, as it can lead to a fork bomb. There is also the overhead of calling the external binary to gather data.

Tinc 1.1 supports rereading a lot of the configuration without resetarting the daemon, i've compiled a version of 1.1 for you from the debian salsa repository: https://salsa.debian.org/guus/tinc/-/tree/1.1/debian (this is whats available in the experimental debian branch) the deb is available her for now: https://borge.nu/vyos/tinc_1.1~pre17-1.1_amd64.deb. just put it in the packages directory when you're generating the iso or dpkg -i it into a image that have tinc-1.0 allready.

In T766#77850, @jack9603301 wrote:

What information do you need access to from within op-mode?

Since restarting tinc requires resetting the interface, it means that you may need to get all the configuration information to call the update function settings of the interface class

Do you know of a version of that FRR exporter that doesn't fork sub processes?

@jack9603301 Do you know of a version of that FRR exporter that doesn't fork sub processes?

What information do you need access to from within op-mode?

I hope to implement an operation mode command, but too many interface parameters are generated according to the configuration in the interface. I don't know how to call these existing configurations. Can I call the user's configuration information through config in operation mode?

It seems that we need to think about it now

You can pull the host configuration in operation mode using the following command:

generate tinc tincN host-conf <user@service:/path>

I hope to implement an operation mode command, but too many interface parameters are generated according to the configuration in the interface. I don't know how to call these existing configurations. Can I call the user's configuration information through config in operation mode?

Note: my test found that when the server is in switch mode, the client cannot Ping to the peer in routing mode (more tests may be needed)

To prevent forgetting, write the address of the exporter to task

The root cause of this problem is that OpenVPN when the deamon is started and in tries to connect to the server, yet did not create the vtun11 interface on the system. Thus all calls to the ifconfig python library will fail big time.

I updated pr. so far, tinc VPN cli will automatically generate the local node key file, such as the following code:

Isn't anyone implementing this feature right now?

My last comment was wrong, here are the outputs for bridge fdb show dev vxlan122:

I can't reproduce it with VyOS 1.3-rolling-202010170146 and other october releases

source-interface cannot be used as the routers are not in the same multicast group, neither can communicate via multicast

In T2987#77730, @Viacheslav wrote:

@tom.siewert
What will be if you delete the source-address on "October" node?

@tom.siewert
What will be if you delete the source-address on "October" node?