Vtysh becomes unresponsive during BGP soft reset

[ZBoris7]

Description

When executing a soft reset on all BGP peers using either clear ip bgp * soft out or clear ip bgp * soft in, the FRR CLI becomes temporarily unresponsive.

Version

FRRouting 10.5.1 (router2) on Linux(6.1.0-41-amd64).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--sbindir=/usr/lib/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--enable-rpki' '--disable-scripting' '--enable-pim6d' '--disable-grpc' '--disable-address-sanitizer' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-protobuf' '--disable-zeromq' '--enable-ospfapi' '--enable-bgp-vnc' '--enable-multipath=256' '--enable-pcre2posix' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' 'build_alias=x86_64-linux-gnu' 'PYTHON=python3'

How to reproduce

1. Establish multiple BGP sessions (in this case, 18 peers with ~6M prefixes total).

2. Run the following command:

   clear ip bgp * soft out
   

3. While the command is being processed, try to execute:

   show ip bgp summary
   

Expected behavior

Vtysh remains responsive. Commands like show ip bgp summary can be executed while a soft BGP reset is in progress.

Actual behavior

Vtysh becomes unresponsive for about one minute after running clear ip bgp * soft out, and commands like show ip bgp summary cannot be executed during this time.

Additional context

The temporary CLI freeze makes operational monitoring difficult.

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[mjstapp]

thanks for the report: yes, this is a known, long-existing issue. The soft clearing code path looks like it is mainly run-to-completion, and that occupies the main pthread as you have seen. We have migrated some of the other peer-clearing or peer-shutdown code paths to an asynchronous pattern, but no one has adapted the soft clearing path yet.