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 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,
DavidDavid 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/2500b450b404ab41eeff3b2d92ba943d0178fb50
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