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