BMP: no monitoring messages when enabled after BGP sessions (BIRD 3.2.1)
Dear BIRD community, I am running a BMP collector and encountering an issue where no monitoring messages are exported over BMP, even though I am using the latest BIRD version (3.2.1), which should include the fix for the previous route export bug: https://gitlab.nic.cz/labs/bird/-/commit/2500b450b404ab41eeff3b2d92ba943d017... We tested this both in our lab and with a network operator, and consistently observe the following behavior: If the BMP session is activated before the BGP sessions, everything works as expected, and monitoring messages are exported. If the BGP sessions are established before enabling BMP, then BMP does not export monitoring messages at all. This suggests that BMP does not correctly pick up already-established BGP sessions. Below is a minimal configuration example. The behavior depends solely on the order in which the sessions are established : debug protocols all; router id 192.168.222.54; protocol kernel { ipv4 { export all; }; } protocol device { scan time 10; } filter ALLOW_ALL { accept; } protocol bmp { station address ip 192.168.222.1 port 4567; monitoring rib in pre_policy; tx buffer limit 1024; } protocol bgp peer_asn_10 { local 192.168.222.54 as 11; neighbor 192.168.222.52 as 10; multihop 255; ipv4 { import all; export all; next hop self; import table on; }; ipv6 { import all; export all; next hop self; import table on; }; } protocol bgp peer_asn_12 { local 192.168.222.54 as 11; neighbor 192.168.222.53 as 12; multihop 255; ipv4 { import all; export all; next hop self; }; ipv6 { import all; export all; next hop self; }; } Has anyone else experienced similar behavior? Could this be another bug related to BMP? Thanks in advance for your help. Best regards, Thomas
Hi Thomas, you are unfortunately correct that it is a another bug in the BMP protocol in v3... We even found another one related to this while investigating the issue and we will fix them in the new version. We are also finishing a lab test case for our CI that will hopefully catch such errors in BMP protocol in the future. Thanks a lot for your thorough reporting, David David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o. On 4/9/26 19:02, Thomas Holterbach wrote:
Dear BIRD community,
I am running a BMP collector and encountering an issue where no monitoring messages are exported over BMP, even though I am using the latest BIRD version (3.2.1), which should include the fix for the previous route export bug:
https://gitlab.nic.cz/labs/bird/-/commit/2500b450b404ab41eeff3b2d92ba943d017...
We tested this both in our lab and with a network operator, and consistently observe the following behavior:
*
If the BMP session is activated before the BGP sessions, everything works as expected, and monitoring messages are exported.
*
If the BGP sessions are established before enabling BMP, then BMP does not export monitoring messages at all.
This suggests that BMP does not correctly pick up already-established BGP sessions.
Below is a minimal configuration example. The behavior depends solely on the order in which the sessions are established :
|debug protocols all; router id 192.168.222.54; protocol kernel { ipv4 { export all; }; } protocol device { scan time 10; } filter ALLOW_ALL { accept; } protocol bmp { station address ip 192.168.222.1 port 4567; monitoring rib in pre_policy; tx buffer limit 1024; } protocol bgp peer_asn_10 { local 192.168.222.54 as 11; neighbor 192.168.222.52 as 10; multihop 255; ipv4 { import all; export all; next hop self; import table on; }; ipv6 { import all; export all; next hop self; import table on; }; } protocol bgp peer_asn_12 { local 192.168.222.54 as 11; neighbor 192.168.222.53 as 12; multihop 255; ipv4 { import all; export all; next hop self; }; ipv6 { import all; export all; next hop self; }; } |
Has anyone else experienced similar behavior? Could this be another bug related to BMP?
Thanks in advance for your help.
Best regards, Thomas
Hi David, I read that the latest releases (v3.2.2 and v3.3.1) include several BMP-related fixes, which, if I understand correctly, may address the bug I reported below. We tested BMP with both v3.2.2 and v3.3.1 in our lab today, and unfortunately we still observed the same issue in both versions. With v3.3.1, when BMP is enabled, we also observed BGP crashing when a remote BGP session starts. For a bit of context, we operate bgproutes.io <https://bgproutes.io/?utm_source=chatgpt.com>, a BGP data collection platform to which network operators can connect via BMP to share routing data. Several of our participants use BIRD, and many have reported experiencing the same issues. I hope this information helps. Best regards, Thomas
On 17 Apr 2026, at 18:18, David Petera via Bird-users <bird-users@network.cz> wrote:
Hi Thomas,
you are unfortunately correct that it is a another bug in the BMP protocol in v3...
We even found another one related to this while investigating the issue and we will fix them in the new version.
We are also finishing a lab test case for our CI that will hopefully catch such errors in BMP protocol in the future.
Thanks a lot for your thorough reporting, David
David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o. On 4/9/26 19:02, Thomas Holterbach wrote:
Dear BIRD community,
I am running a BMP collector and encountering an issue where no monitoring messages are exported over BMP, even though I am using the latest BIRD version (3.2.1), which should include the fix for the previous route export bug:
https://gitlab.nic.cz/labs/bird/-/commit/2500b450b404ab41eeff3b2d92ba943d017...
We tested this both in our lab and with a network operator, and consistently observe the following behavior:
If the BMP session is activated before the BGP sessions, everything works as expected, and monitoring messages are exported.
If the BGP sessions are established before enabling BMP, then BMP does not export monitoring messages at all.
This suggests that BMP does not correctly pick up already-established BGP sessions.
Below is a minimal configuration example. The behavior depends solely on the order in which the sessions are established :
debug protocols all;
router id 192.168.222.54;
protocol kernel { ipv4 { export all; }; }
protocol device { scan time 10; }
filter ALLOW_ALL { accept; }
protocol bmp { station address ip 192.168.222.1 port 4567; monitoring rib in pre_policy; tx buffer limit 1024; }
protocol bgp peer_asn_10 { local 192.168.222.54 as 11; neighbor 192.168.222.52 as 10; multihop 255;
ipv4 { import all; export all; next hop self; import table on; };
ipv6 { import all; export all; next hop self; import table on; }; }
protocol bgp peer_asn_12 { local 192.168.222.54 as 11; neighbor 192.168.222.53 as 12; multihop 255;
ipv4 { import all; export all; next hop self; };
ipv6 { import all; export all; next hop self; }; } Has anyone else experienced similar behavior? Could this be another bug related to BMP?
Thanks in advance for your help.
Best regards, Thomas
Hey Thomas, I've had the same issue in 3.3.0/3.3.1 deployment and submitted a oneliner patch few days ago to temporarily address it: https://trubka.network.cz/archives/list/bird-users@network.cz/thread/XN43FOR... Not sure if this helps but feel free to try it out :) Best, Yifei On 6/23/26 15:12, Thomas Holterbach wrote:
Hi David,
I read that the latest releases (v3.2.2 and v3.3.1) include several BMP-related fixes, which, if I understand correctly, may address the bug I reported below.
We tested BMP with both v3.2.2 and v3.3.1 in our lab today, and unfortunately we still observed the same issue in both versions. With v3.3.1, when BMP is enabled, we also observed BGP crashing when a remote BGP session starts.
For a bit of context, we operate bgproutes.io <https://bgproutes.io/?utm_source=chatgpt.com>, a BGP data collection platform to which network operators can connect via BMP to share routing data. Several of our participants use BIRD, and many have reported experiencing the same issues.
I hope this information helps.
Best regards, Thomas
On 17 Apr 2026, at 18:18, David Petera via Bird-users <bird-users@network.cz> wrote:
Hi Thomas,
you are unfortunately correct that it is a another bug in the BMP protocol in v3...
We even found another one related to this while investigating the issue and we will fix them in the new version.
We are also finishing a lab test case for our CI that will hopefully catch such errors in BMP protocol in the future.
Thanks a lot for your thorough reporting, David
David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o. On 4/9/26 19:02, Thomas Holterbach wrote:
Dear BIRD community,
I am running a BMP collector and encountering an issue where no monitoring messages are exported over BMP, even though I am using the latest BIRD version (3.2.1), which should include the fix for the previous route export bug:
https://gitlab.nic.cz/labs/bird/-/commit/2500b450b404ab41eeff3b2d92ba943d017...
We tested this both in our lab and with a network operator, and consistently observe the following behavior:
*
If the BMP session is activated before the BGP sessions, everything works as expected, and monitoring messages are exported.
*
If the BGP sessions are established before enabling BMP, then BMP does not export monitoring messages at all.
This suggests that BMP does not correctly pick up already-established BGP sessions.
Below is a minimal configuration example. The behavior depends solely on the order in which the sessions are established :
|debug protocols all; router id 192.168.222.54; protocol kernel { ipv4 { export all; }; } protocol device { scan time 10; } filter ALLOW_ALL { accept; } protocol bmp { station address ip 192.168.222.1 port 4567; monitoring rib in pre_policy; tx buffer limit 1024; } protocol bgp peer_asn_10 { local 192.168.222.54 as 11; neighbor 192.168.222.52 as 10; multihop 255; ipv4 { import all; export all; next hop self; import table on; }; ipv6 { import all; export all; next hop self; import table on; }; } protocol bgp peer_asn_12 { local 192.168.222.54 as 11; neighbor 192.168.222.53 as 12; multihop 255; ipv4 { import all; export all; next hop self; }; ipv6 { import all; export all; next hop self; }; } |
Has anyone else experienced similar behavior? Could this be another bug related to BMP?
Thanks in advance for your help.
Best regards, Thomas
Hello, I have looked at the BMP problems with BIRDv3 again and have some comments. The crashes are related to regression in BGP like Yifei mentioned below in this thread. In regard to your other issue, I have tried to reproduce it with the exact BIRD versions, but was not successful. We had a bug that behaved similarly but that one should be fixed in versions you mentioned. One problem I can see in the config you provided is that one of the two instances of BGP protocol (`peer_asn_12`) does not have `import table` enabled. Any routes from that protocol will not be sent to BMP listener. For `pre_policy` to work, import table must be turned on all BGP protocols from which you want BMP updates, otherwise BIRD will not have information about the pre filtered routes. `post_policy` does work without import table, but there is a know issue with configs that have both `pre_policy` and `post_policy` enabled in a single BMP instance. Basically if BGP does not have import table enabled, failed initialization of `pre_policy` prevents even `post_policy` from working for that BGP instance (others should still work). We are going to fix this bug eventually, but hot-fix to this is having two instances of BMP protocol set up like this: ``` protocol bmp bmp_pre { local address 10.1.1.1; station address ip 0.0.0.0 port 11019; monitoring rib in pre_policy; } protocol bmp bmp_post { local address 10.1.111.1; station address ip 0.0.0.0 port 11019; monitoring rib in post_policy; } ``` Other possible cause may be the BMP listener itself, which listener are you using in your operations? Lastly if you could enable logs from BMP with `debug all` and sent us the result, it might help us understand what's going on. Hope this helps, David David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o. On 6/23/26 15:12, Thomas Holterbach wrote:
Hi David,
I read that the latest releases (v3.2.2 and v3.3.1) include several BMP-related fixes, which, if I understand correctly, may address the bug I reported below.
We tested BMP with both v3.2.2 and v3.3.1 in our lab today, and unfortunately we still observed the same issue in both versions. With v3.3.1, when BMP is enabled, we also observed BGP crashing when a remote BGP session starts.
For a bit of context, we operate bgproutes.io <https://bgproutes.io/?utm_source=chatgpt.com>, a BGP data collection platform to which network operators can connect via BMP to share routing data. Several of our participants use BIRD, and many have reported experiencing the same issues.
I hope this information helps.
Best regards, Thomas
On 17 Apr 2026, at 18:18, David Petera via Bird-users <bird-users@network.cz> wrote:
Hi Thomas,
you are unfortunately correct that it is a another bug in the BMP protocol in v3...
We even found another one related to this while investigating the issue and we will fix them in the new version.
We are also finishing a lab test case for our CI that will hopefully catch such errors in BMP protocol in the future.
Thanks a lot for your thorough reporting, David
David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o. On 4/9/26 19:02, Thomas Holterbach wrote:
Dear BIRD community,
I am running a BMP collector and encountering an issue where no monitoring messages are exported over BMP, even though I am using the latest BIRD version (3.2.1), which should include the fix for the previous route export bug:
https://gitlab.nic.cz/labs/bird/-/commit/2500b450b404ab41eeff3b2d92ba943d017...
We tested this both in our lab and with a network operator, and consistently observe the following behavior:
*
If the BMP session is activated before the BGP sessions, everything works as expected, and monitoring messages are exported.
*
If the BGP sessions are established before enabling BMP, then BMP does not export monitoring messages at all.
This suggests that BMP does not correctly pick up already-established BGP sessions.
Below is a minimal configuration example. The behavior depends solely on the order in which the sessions are established :
|debug protocols all; router id 192.168.222.54; protocol kernel { ipv4 { export all; }; } protocol device { scan time 10; } filter ALLOW_ALL { accept; } protocol bmp { station address ip 192.168.222.1 port 4567; monitoring rib in pre_policy; tx buffer limit 1024; } protocol bgp peer_asn_10 { local 192.168.222.54 as 11; neighbor 192.168.222.52 as 10; multihop 255; ipv4 { import all; export all; next hop self; import table on; }; ipv6 { import all; export all; next hop self; import table on; }; } protocol bgp peer_asn_12 { local 192.168.222.54 as 11; neighbor 192.168.222.53 as 12; multihop 255; ipv4 { import all; export all; next hop self; }; ipv6 { import all; export all; next hop self; }; } |
Has anyone else experienced similar behavior? Could this be another bug related to BMP?
Thanks in advance for your help.
Best regards, Thomas
Hi David, Thank you for your reply. I am responding on behalf of my colleague Thomas Alfroy, who performed the debugging. I tried to reproduce the issue once more to ensure that I had not made any configuration mistakes. I am now using the following configuration on the BIRD v3.2.2 router: log syslog all; log stderr all; log "/var/log/bird-bmp.log" all; timeformat log iso long us; router id 192.168.222.53; protocol device { } protocol static announced_prefixes { ipv4; route 13.1.0.0/24 blackhole; route 13.2.0.0/24 blackhole; route 13.3.0.0/24 blackhole; route 13.4.0.0/24 blackhole; route 13.5.0.0/24 blackhole; } protocol bgp peer_192_168_222_52 { local as 10; neighbor 192.168.222.52 as 10; source address 192.168.222.53; ipv4 { import all; export all; import table on; next hop self; }; } protocol bgp peer_192_168_222_54 { local as 10; neighbor 192.168.222.54 as 10; source address 192.168.222.53; ipv4 { import all; export all; import table on; next hop self; }; } protocol bmp bmp1 { debug all; station address ip 192.168.222.1 port 4568; monitoring rib in pre_policy; tx buffer limit 64; } This BIRD instance runs on a VM with the IP address 192.168.222.53. Two FRRouting instances connect to it. The first FRRouting instance runs on 192.168.222.52 with the following configuration: log syslog informational ! ip nht resolve-via-default ! router bgp 10 bgp router-id 192.168.222.52 ! no bgp network import-check ! neighbor 192.168.222.51 remote-as 1000 neighbor 192.168.222.51 ebgp-multihop 255 neighbor 192.168.222.51 next-hop-self neighbor 192.168.222.51 route-map ALLOW-ALL in neighbor 192.168.222.51 route-map ALLOW-ALL out ! neighbor 192.168.222.53 remote-as 10 neighbor 192.168.222.53 next-hop-self neighbor 192.168.222.53 route-map ALLOW-ALL in neighbor 192.168.222.53 route-map ALLOW-ALL out ! address-family ipv4 unicast network 12.1.0.0/24 network 12.2.0.0/24 network 12.3.0.0/24 network 12.4.0.0/24 network 12.5.0.0/24 exit-address-family ! route-map ALLOW-ALL permit 10 ! end The second FRRouting instance runs on 192.168.222.54 with the following configuration: log syslog informational ! ip nht resolve-via-default ! router bgp 10 bgp router-id 192.168.222.54 ! no bgp network import-check ! neighbor 192.168.222.53 remote-as 10 neighbor 192.168.222.53 next-hop-self neighbor 192.168.222.53 route-map ALLOW-ALL in neighbor 192.168.222.53 route-map ALLOW-ALL out ! ! address-family ipv4 unicast network 14.1.0.0/24 network 14.2.0.0/24 network 14.3.0.0/24 network 14.4.0.0/24 network 14.5.0.0/24 exit-address-family ! route-map ALLOW-ALL permit 10 ! end After starting both FRRouting instances and the BIRD instance, everything works correctly and all routes are installed. I then start my BMP collector, and BIRD successfully connects to it: <hostname>:~/bird$ sudo bird -f -d -c /usr/local/etc/bird.conf bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: Initializing bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: Starting bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: initialized rte_src owner bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: State changed to start bird: 2026-07-29 16:42:55.085659 [0001] <INFO> Started bird: 2026-07-29 16:42:55.285985 [0002] <TRACE> bmp1: Connecting to 192.168.222.1 port 4568 bird: 2026-07-29 16:42:55.286407 [0002] <TRACE> bmp1: Connection lost (Connection refused) bird: 2026-07-29 16:43:05.287940 [0002] <TRACE> bmp1: Connecting to 192.168.222.1 port 4568 bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: Connected bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: BMP session established bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: new rte_src ID 0L 5G, have 1 sources now bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: State changed to up However, nothing further happens. On the collector side, I receive only the BMP Initiation message. I do not receive any Peer Up or Route Monitoring messages for the already-established BGP sessions. When I manually restart the FRRouting instance running on 192.168.222.54, I receive the Peer Up message for that BGP session, followed by the corresponding BMP Route Monitoring messages: production@publicmirror3:~/bird$ sudo bird -f -d -c /usr/local/etc/bird.conf bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: Initializing bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: Starting bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: initialized rte_src owner bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: State changed to start bird: 2026-07-29 16:42:55.085659 [0001] <INFO> Started bird: 2026-07-29 16:42:55.285985 [0002] <TRACE> bmp1: Connecting to 192.168.222.1 port 4568 bird: 2026-07-29 16:42:55.286407 [0002] <TRACE> bmp1: Connection lost (Connection refused) bird: 2026-07-29 16:43:05.287940 [0002] <TRACE> bmp1: Connecting to 192.168.222.1 port 4568 bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: Connected bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: BMP session established bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: new rte_src ID 0L 5G, have 1 sources now bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: State changed to up bird: 2026-07-29 16:43:20.462939 [0002] <RMT> peer_192_168_222_54: Received: Peer de-configured bird: 2026-07-29 16:43:21.910098 [0002] <TRACE> bmp1: Peer up for peer_192_168_222_54 bird: 2026-07-29 16:43:21.910098 [0002] <TRACE> bmp1.export: Export state changed from DOWN to FEEDING bird: 2026-07-29 16:43:21.910098 [0002] <TRACE> bmp1.export: Export state changed from FEEDING to PARTIAL bird: 2026-07-29 16:43:21.910098 [0002] <TRACE> bmp1: Sending END-OF-RIB for peer_192_168_222_54.ipv4 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 13.1.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 13.2.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 13.3.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 13.4.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 13.5.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 12.1.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 12.5.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 12.4.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 12.3.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 12.2.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Export state changed from PARTIAL to READY bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Fed up bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Updating 14.1.0.0/24, seq 1 bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export 1 released bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Updating 14.5.0.0/24, seq 2 bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export 2 released bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Updating 14.4.0.0/24, seq 3 bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export 3 released bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Updating 14.3.0.0/24, seq 4 bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export 4 released bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Updating 14.2.0.0/24, seq 5 bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export 5 released bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export drained The BIRD logs indicate that all prefixes were fed to the BMP export process, including the prefixes received from the BGP session that was not restarted. However, my collector receives only the prefixes learned from the restarted session on 192.168.222.54. It does not receive the static 13.x prefixes or the 12.x prefixes learned from the session on 192.168.222.52. I am using a custom BMP receiver. Its logs for the test described above are as follows: 2026-07-29 18:42:56 [DEBUG] Creating multi BMP peer 2026-07-29 18:42:56 [DEBUG - MASTER - 11_192.168.222.53] BMP master peer correctly listening on address '192.168.222.1:4568'. 2026-07-29 18:42:56 [DEBUG] Multi BMP peer has been correclty created 2026-07-29 18:43:05 [DEBUG - MASTER - 11_192.168.222.53] Remote BMP feeder is TCP connected (incoming SYN). 2026-07-29 18:43:05 [DEBUG - MASTER - 11_192.168.222.53] Receiving a message of size 36 2026-07-29 18:43:05 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:05 [DEBUG - MASTER - 11_192.168.222.53] Receiving an initiation BMP message with SYS_DESCR: 'Not defined'. 2026-07-29 18:43:21 [DEBUG - MASTER - 11_192.168.222.53] Receiving a message of size 286 2026-07-29 18:43:21 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:21 [DEBUG - MASTER - 11_192.168.222.53] We received a Peer Up message. First OPEN is of size 53, second open is of size 94. 2026-07-29 18:43:21 [DEBUG] Extracted ASN is '65535'. Extracted router_id is '255.255.255.255'. 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] Sub peer structure correctly created. 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] We received a Peer Up message for BMP sub-peer. 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] VRF for peer Up message if ''. 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] Admin label for peer Up message if ''. 2026-07-29 18:43:21 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343401'. 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] We received an IPv4 End-of-RIB for BMP sub peer. 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] Receiving a message of size 515 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343405'. 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We processed a update for prefix '14.1.0.0/24' for feed type bmp_adj_in_pre. 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343405'. 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We processed a update for prefix '14.5.0.0/24' for feed type bmp_adj_in_pre. 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343405'. 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We processed a update for prefix '14.4.0.0/24' for feed type bmp_adj_in_pre. 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343405'. 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We processed a update for prefix '14.3.0.0/24' for feed type bmp_adj_in_pre. 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343405'. 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We processed a update for prefix '14.2.0.0/24' for feed type bmp_adj_in_pre. To summarise, I can reproduce two related behaviours: When the BMP connection is established after the BGP sessions, BIRD sends only the Initiation message. No Peer Up or Route Monitoring messages are sent for the already-established sessions. After restarting one BGP peer, BIRD reports that it is feeding routes from multiple sources, but the BMP receiver receives only the routes belonging to the restarted peer. Please let me know if you need packet captures, additional logs, or any other information to help reproduce and debug the issue. For completeness, I am using the following BIRD build: <hostname>:~/bird$ bird --version BIRD version 3.2.2+detached.455677e6d09b Best regards, Thomas
Hi, just letting you know that the upcoming v3 patch versions should include three fixes for BMP that should hopefully resolve your issues. The relevant commits are: https://gitlab.nic.cz/labs/bird/-/commit/5d5274f6d2ea16a9a93b6477f20aefbbf2c... https://gitlab.nic.cz/labs/bird/-/commit/9e847edc797739815c2713493733ce356ef... https://gitlab.nic.cz/labs/bird/-/commit/5bed739703b640fc5e7a22b6c39bbe86ba9... For more information check the commit messages or later the release notes. The v3 development branch `thread-next` contains all of them in case you would like to test it in your scenario. Thanks a lot for all your reporting and happy routing, David David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o. On 7/30/26 00:22, Thomas Holterbach wrote:
Hi David,
Thank you for your reply.
I am responding on behalf of my colleague Thomas Alfroy, who performed the debugging.
I tried to reproduce the issue once more to ensure that I had not made any configuration mistakes. I am now using the following configuration on the BIRD v3.2.2 router:
|log syslog all; log stderr all; log "/var/log/bird-bmp.log" all; timeformat log iso long us; router id 192.168.222.53; protocol device { } protocol static announced_prefixes { ipv4; route 13.1.0.0/24 blackhole; route 13.2.0.0/24 blackhole; route 13.3.0.0/24 blackhole; route 13.4.0.0/24 blackhole; route 13.5.0.0/24 blackhole; } protocol bgp peer_192_168_222_52 { local as 10; neighbor 192.168.222.52 as 10; source address 192.168.222.53; ipv4 { import all; export all; import table on; next hop self; }; } protocol bgp peer_192_168_222_54 { local as 10; neighbor 192.168.222.54 as 10; source address 192.168.222.53; ipv4 { import all; export all; import table on; next hop self; }; } protocol bmp bmp1 { debug all; station address ip 192.168.222.1 port 4568; monitoring rib in pre_policy; tx buffer limit 64; } |
This BIRD instance runs on a VM with the IP address |192.168.222.53|. Two FRRouting instances connect to it.
The first FRRouting instance runs on |192.168.222.52| with the following configuration:
|log syslog informational ! ip nht resolve-via-default ! router bgp 10 bgp router-id 192.168.222.52 ! no bgp network import-check ! neighbor 192.168.222.51 remote-as 1000 neighbor 192.168.222.51 ebgp-multihop 255 neighbor 192.168.222.51 next-hop-self neighbor 192.168.222.51 route-map ALLOW-ALL in neighbor 192.168.222.51 route-map ALLOW-ALL out ! neighbor 192.168.222.53 remote-as 10 neighbor 192.168.222.53 next-hop-self neighbor 192.168.222.53 route-map ALLOW-ALL in neighbor 192.168.222.53 route-map ALLOW-ALL out ! address-family ipv4 unicast network 12.1.0.0/24 network 12.2.0.0/24 network 12.3.0.0/24 network 12.4.0.0/24 network 12.5.0.0/24 exit-address-family ! route-map ALLOW-ALL permit 10 ! end |
The second FRRouting instance runs on |192.168.222.54| with the following configuration:
|log syslog informational ! ip nht resolve-via-default ! router bgp 10 bgp router-id 192.168.222.54 ! no bgp network import-check ! neighbor 192.168.222.53 remote-as 10 neighbor 192.168.222.53 next-hop-self neighbor 192.168.222.53 route-map ALLOW-ALL in neighbor 192.168.222.53 route-map ALLOW-ALL out ! ! address-family ipv4 unicast network 14.1.0.0/24 network 14.2.0.0/24 network 14.3.0.0/24 network 14.4.0.0/24 network 14.5.0.0/24 exit-address-family ! route-map ALLOW-ALL permit 10 ! end |
After starting both FRRouting instances and the BIRD instance, everything works correctly and all routes are installed.
I then start my BMP collector, and BIRD successfully connects to it:
|<hostname>:~/bird$ sudo bird -f -d -c /usr/local/etc/bird.conf bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: Initializing bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: Starting bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: initialized rte_src owner bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: State changed to start bird: 2026-07-29 16:42:55.085659 [0001] <INFO> Started bird: 2026-07-29 16:42:55.285985 [0002] <TRACE> bmp1: Connecting to 192.168.222.1 port 4568 bird: 2026-07-29 16:42:55.286407 [0002] <TRACE> bmp1: Connection lost (Connection refused) bird: 2026-07-29 16:43:05.287940 [0002] <TRACE> bmp1: Connecting to 192.168.222.1 port 4568 bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: Connected bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: BMP session established bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: new rte_src ID 0L 5G, have 1 sources now bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: State changed to up |
However, nothing further happens. On the collector side, I receive only the BMP Initiation message. I do not receive any Peer Up or Route Monitoring messages for the already-established BGP sessions.
When I manually restart the FRRouting instance running on |192.168.222.54|, I receive the Peer Up message for that BGP session, followed by the corresponding BMP Route Monitoring messages:
|production@publicmirror3:~/bird$ sudo bird -f -d -c /usr/local/etc/bird.conf bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: Initializing bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: Starting bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: initialized rte_src owner bird: 2026-07-29 16:42:55.085659 [0001] <TRACE> bmp1: State changed to start bird: 2026-07-29 16:42:55.085659 [0001] <INFO> Started bird: 2026-07-29 16:42:55.285985 [0002] <TRACE> bmp1: Connecting to 192.168.222.1 port 4568 bird: 2026-07-29 16:42:55.286407 [0002] <TRACE> bmp1: Connection lost (Connection refused) bird: 2026-07-29 16:43:05.287940 [0002] <TRACE> bmp1: Connecting to 192.168.222.1 port 4568 bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: Connected bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: BMP session established bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: new rte_src ID 0L 5G, have 1 sources now bird: 2026-07-29 16:43:05.288558 [0002] <TRACE> bmp1: State changed to up bird: 2026-07-29 16:43:20.462939 [0002] <RMT> peer_192_168_222_54: Received: Peer de-configured bird: 2026-07-29 16:43:21.910098 [0002] <TRACE> bmp1: Peer up for peer_192_168_222_54 bird: 2026-07-29 16:43:21.910098 [0002] <TRACE> bmp1.export: Export state changed from DOWN to FEEDING bird: 2026-07-29 16:43:21.910098 [0002] <TRACE> bmp1.export: Export state changed from FEEDING to PARTIAL bird: 2026-07-29 16:43:21.910098 [0002] <TRACE> bmp1: Sending END-OF-RIB for peer_192_168_222_54.ipv4 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 13.1.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 13.2.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 13.3.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 13.4.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 13.5.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 12.1.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 12.5.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 12.4.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 12.3.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Feeding 12.2.0.0/24 bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Export state changed from PARTIAL to READY bird: 2026-07-29 16:43:21.910746 [0002] <TRACE> bmp1.export: Fed up bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Updating 14.1.0.0/24, seq 1 bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export 1 released bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Updating 14.5.0.0/24, seq 2 bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export 2 released bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Updating 14.4.0.0/24, seq 3 bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export 3 released bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Updating 14.3.0.0/24, seq 4 bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export 4 released bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Updating 14.2.0.0/24, seq 5 bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export 5 released bird: 2026-07-29 16:43:25.912674 [0002] <TRACE> bmp1.export: Export drained |
The BIRD logs indicate that all prefixes were fed to the BMP export process, including the prefixes received from the BGP session that was not restarted.
However, my collector receives only the prefixes learned from the restarted session on |192.168.222.54|. It does not receive the static |13.x| prefixes or the |12.x| prefixes learned from the session on |192.168.222.52|.
I am using a custom BMP receiver. Its logs for the test described above are as follows:
|2026-07-29 18:42:56 [DEBUG] Creating multi BMP peer 2026-07-29 18:42:56 [DEBUG - MASTER - 11_192.168.222.53] BMP master peer correctly listening on address '192.168.222.1:4568'. 2026-07-29 18:42:56 [DEBUG] Multi BMP peer has been correclty created 2026-07-29 18:43:05 [DEBUG - MASTER - 11_192.168.222.53] Remote BMP feeder is TCP connected (incoming SYN). 2026-07-29 18:43:05 [DEBUG - MASTER - 11_192.168.222.53] Receiving a message of size 36 2026-07-29 18:43:05 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:05 [DEBUG - MASTER - 11_192.168.222.53] Receiving an initiation BMP message with SYS_DESCR: 'Not defined'. 2026-07-29 18:43:21 [DEBUG - MASTER - 11_192.168.222.53] Receiving a message of size 286 2026-07-29 18:43:21 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:21 [DEBUG - MASTER - 11_192.168.222.53] We received a Peer Up message. First OPEN is of size 53, second open is of size 94. 2026-07-29 18:43:21 [DEBUG] Extracted ASN is '65535'. Extracted router_id is '255.255.255.255'. 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] Sub peer structure correctly created. 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] We received a Peer Up message for BMP sub-peer. 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] VRF for peer Up message if ''. 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] Admin label for peer Up message if ''. 2026-07-29 18:43:21 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343401'. 2026-07-29 18:43:21 [DEBUG - PEER - 10_192.168.222.54] We received an IPv4 End-of-RIB for BMP sub peer. 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] Receiving a message of size 515 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343405'. 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We processed a update for prefix '14.1.0.0/24' for feed type bmp_adj_in_pre. 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343405'. 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We processed a update for prefix '14.5.0.0/24' for feed type bmp_adj_in_pre. 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343405'. 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We processed a update for prefix '14.4.0.0/24' for feed type bmp_adj_in_pre. 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343405'. 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We processed a update for prefix '14.3.0.0/24' for feed type bmp_adj_in_pre. 2026-07-29 18:43:25 [DEBUG - MASTER - 11_192.168.222.53] We received a BMP message with feed type 'bmp_adj_in_pre' (peer_flags=0x00, post_policy=0, adj_rib_out=0). 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We received a message with timestamp '1785343405'. 2026-07-29 18:43:25 [DEBUG - PEER - 10_192.168.222.54] We processed a update for prefix '14.2.0.0/24' for feed type bmp_adj_in_pre. |
To summarise, I can reproduce two related behaviours:
1.
When the BMP connection is established after the BGP sessions, BIRD sends only the Initiation message. No Peer Up or Route Monitoring messages are sent for the already-established sessions.
2.
After restarting one BGP peer, BIRD reports that it is feeding routes from multiple sources, but the BMP receiver receives only the routes belonging to the restarted peer.
Please let me know if you need packet captures, additional logs, or any other information to help reproduce and debug the issue.
For completeness, I am using the following BIRD build:
|<hostname>:~/bird$ bird --version BIRD version 3.2.2+detached.455677e6d09b |
Best regards,
Thomas
participants (3)
-
David Petera -
Thomas Holterbach -
Yifei Sun