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
participants (3)
-
David Petera -
Thomas Holterbach -
Yifei Sun