We have two types of BGP performance jobs. bgp-ingest and bgp-ingest-mixed (the second one mixes in prefix withdrawals).
We also have two types of suites, one (prefixcount) counts number of prefixes in example-ipv4-topology, the other one (changecount) uses data change counter to detect when topology is stable. The suites are run in successive order, but the two jobs use differing order.

Currently, in both jobs the first suite works (apart from the performance loss tracked as BGPCEP-380), but the second suite fails, detecting zero prefixes or just a single data change (see "state" value in [0] respectively [1]).

Also, the suites run two cycles of ingestion, depending on which side is initiating BGP connection, so mere peer disconnect is not breaking the ingestion [2], [3].

So the natural explanation is that things get broken during peer de-configuration between suites.
Onother explanation is lack of heap space, as attempt to compress karaf.log ends with:
xz: Filter chain: --lzma2=dict=64MiB,lc=3,lp=0,pb=2,mode=normal,nice=273,mf=bt4,depth=512
xz: 674 MiB of memory is required. The limiter is disabled.
xz: Decompression will need 65 MiB of memory.
xz: /tmp/distribution-karaf-0.4.0-SNAPSHOT/data/log/karaf.log: Cannot allocate memory

Possibly, Sandbox test with reduced number of prefixes is needed to exclude memory issues.

[0] https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-bgp-ingest-mixed-only-beryllium/87/robot/report/log.html#s1-s3-t5-k2-k2-k7-k182-k1-k6
[1] https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-bgp-ingest-only-beryllium/88/robot/report/log.html#s1-s3-t7-k2-k2-k7-k136-k1-k6
[2] https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-bgp-ingest-mixed-only-beryllium/87/robot/report/log.html#s1-s2-t15-k2-k2-k7-k210-k1-k6
[3] https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-bgp-ingest-only-beryllium/88/robot/report/log.html#s1-s2-t13-k2-k2-k7-k29-k1-k6