Cannot reproduce it with this configuration (VyOS 1.4-rolling-202302280651, don't have a lot of file descriptors):

set protocols bfd peer 192.0.2.5 multihop
set protocols bfd peer 192.0.2.5 source address '192.0.2.1'
set protocols bfd peer 192.0.2.6 multihop
set protocols bfd peer 192.0.2.6 source address '192.0.2.1'
set protocols bfd profile BBR interval multiplier '3'
set protocols bfd profile BBR interval receive '350'
set protocols bfd profile BBR interval transmit '350'

commit

vyos@r14# vtysh -c "show run bfd"
Building configuration...

Current configuration:
!
frr version 8.4.2
frr defaults traditional
hostname debian
log syslog
log facility local7
hostname r14
service integrated-vtysh-config
!
bfd
 profile BBR
  transmit-interval 350
  receive-interval 350
 exit
 !
 peer 192.0.2.5 multihop local-address 192.0.2.1
 exit
 !
 peer 192.0.2.6 multihop local-address 192.0.2.1
 exit
 !
exit
!
end
[edit]
vyos@r14#

Limit the number of file descriptors that will be used internally by the FRR daemons. By default, the daemons use the system ulimit value.
https://docs.frrouting.org/en/stable-8.4/basic.html?#cmdoption-limit-fds

To see the hard and soft values

ulimit -Hn
ulimit -Sn

sysctl fs.file-max

The limits look like standard
root@nn-vlns-3-1:~# ulimit -Hn
1048576
root@nn-vlns-3-1:~# ulimit -Sn
1024
root@nn-vlns-3-1:~# sysctl fs.file-max
fs.file-max = 9223372036854775807

But BFD process does not start after reboot.
Attaching journalctl -b --no-pager output.

The bfdd process did not start until i changed LimitNOFILE=1024 to LimitNOFILE=2048 in /lib/systemd/system/frr.service
That did the trick, but i'm not sure it's a good solution.
What do you think, @Viacheslav ?

Well there should be no harm in lifting the limit of open file descriptors for FRR as its a huge process tree.
Can you share your entire protocols configuration tree so we see what else is configured?

So I think it might be something else or you really have a lot of e.g. BGP peerings enabled.

Thank you for the hint, @c-po
Attached the entire config we have on the node.

In T5045#144137, @aserkin wrote:

Thank you for the hint, @c-po
Attached the entire config we have on the node.

lns-3-1-commands-clean.cfg213 KBDownload

I don't see attached config.

again. It says - download complete. And i can get it from the message:

@aserkin WOW that is a huge VRF config. With that amount you definately reach the max FD limit.

In this use-case we probably should lift the limit from 1024 to 4096 for LimitNOFILE.

Can you probably tell us more about this config? It might be worth adding this to our smoketest infrastructure.

Thank you, @c-po. Will try raising limits to 4096.
Well in this project we're trying to implement L2TP network server with MPLE-PE functionality with our partner mobile operator. This is for b2b projects with a number of customers connecting their mobiles to corporate resources for some reasons.
So the config has three groups of BGP peers: four of ipv4-unicast peers (10.228.134.34, 10.228.134.36, 10.228.134.38, 10.228.134.40) for connection to L2TP LACs (actually they are mobile gateways - GGSN/PGW) and AAA servers, another pair is ipv4-vpn multihop peers (10.5.72.1,10.5.72.2) where customer's L3VPN connections are terminated, And one more peer connecting to 3d party carrier grade NAT solution for the customers who need Internet access.
The LNS and NAT nodes are implemented on a single server with KVM virtual machines interconnected with each other and with external world by OpenVSvitch/DPDK.
The VRF names are assigned by AAA server for each subscriber with Accel-VRF-Name attribute.
This is also where the defect https://github.com/FRRouting/frr/issues/12919 comes from. Just to spot on it)
Let me know if you nedd additional info.

BTW this configuration takes almost 20 minutes to load. I wonder if there's a way to speed up this process?

Great project! As I understand it, you're using BGP label-unicast to transport labels, and I'm curious about the operating systems your PEs/Ps are running on - are they Cisco, Juniper, or other vendors? I'm particularly interested in learning about the interoperability between different vendors so that I can incorporate it into my testing. @aserkin

As you can see LNS/MPLS-PE is being built on VyOS 1.4. MPLS-P are NSN (aka Alcatel Lucent) boxes as far as i know.