BMP Adj-RIB-Out post-policy support

[David Petera]

Hi Matthieu,

thanks a lot for the patch of BMP in v3!
I put it in our internal backlog and as soon as this busy period* is 
over, we will review it and hopefully merge it.
Then we can also proceed further in the Adj-RIB-Out post-policy support.

You mentioned that you rely on BMP quite a lot, can I ask you which BMP 
listener do you use?
I will soon get back to writing a test for BMP (initially prompted by 
your previous mail concerning BMP in v3) and I would be curious about 
your actual setup.
Will most likely use Rotonda and/or pmbmpd utility, but maybe you are 
using something else entirely.

WIP of the test can be seen on a branch here: 
https://gitlab.nic.cz/labs/bird-tools/-/tree/bmp_test/netlab/cf-bgp-bmp?ref_type=heads 

(note it is not in a working state yet)

I would also like the test to be ready for the eventual support of 
Adj-RIB-Out post-policy.

Thanks again and happy routing!
David

*most of our team is either finishing EVPN or writing drafts for the 
upcoming IETF))

David Petera (he/him) | BIRD Tech Support | CZ.NIC, z.s.p.o.

On 1/15/26 11:50, Matthieu Gouel via Bird-users wrote:
>
> Dear Maria,
>
> Thanks a lot for the review and for the pointers!
>
> Indeed, my initial patch is wrong. I was sourcing updates from the 
> main table, which effectively means I was exporting the RIB as updates 
> and calling that ADJ-RIB-Out.
>
> I tried to fix the implementation to use the actual |out_table|, but I 
> kept running into crashes. From what I can tell, this is because the 
> out table is an internal table and I didn’t manage to correctly create 
> or attach a channel to it without hitting invalid states.
>
> Given your comment about |thread-next| handling |out_table| very 
> differently, I wondered whether it might make more sense to target 
> that branch instead. Before going further in that direction, I wanted 
> to double-check that BMP ADJ-RIB-In Route Monitoring was working 
> properly there first.
>
> I had a suspicion it wasn’t, since I had already tested early BIRD v3 
> releases back when they came out and saw issues at the time (mentioned 
> it on the mailing list but that was a busy period). After retesting, 
> it turns out ADJ-RIB-In RM was indeed broken: my collector was only 
> receiving End-of-RIB messages, with no actual route updates.
>
> Since I had a good test setup handy, I dug into it and found a few 
> issues that prevented IPv4 and IPv6 updates from being sent as BMP 
> Route Monitoring messages. Here is the result:
>
> https://github.com/matthieugouel/bird/commit/835ea3fae7f162105621bd773a078bd7ad36ec4d
>
> I compared the BMP output against BIRD v2 and got matching behavior, 
> using v2 as the reference. That said, given my C skills, this would 
> definitely need a careful review before merging.
>
> This is a bit of a detour from the original ADJ-RIB-Out goal, but I 
> think getting the current BMP implementation in v3 into a solid state 
> is probably a good first step before extending it further.
>
> Thanks again for the feedback, happy to iterate or adjust direction 
> based on what you think makes the most sense.
>
> Best,
> Matthieu
>
>
> On Wednesday, 14 January 2026 at 15:39, Maria Matejka via Bird-users 
> <bird-users at network.cz> wrote:
>>
>> Dear Matthieu,
>>
>> thank you for your patch!
>>
>> On Wed, Jan 14, 2026 at 07:50:29AM +0000, Matthieu Gouel via 
>> Bird-users wrote:
>>
>>     Currently, the (preliminary) BMP protocol implementation in BIRD
>>     does not support ADJ-RIB-Out monitoring. Only ADJ-RIB-In pre- and
>>     post-policy are supported at the moment.
>>
>>     I have implemented support for ADJ-RIB-Out post-policy
>>     monitoring, which is relatively straightforward to add. The
>>     proposed implementation is available here:
>>
>>     https://github.com/CZ-NIC/bird/compare/master…matthieugouel:bird:bmp-adj-rib-out
>>
>>     I have not implemented ADJ-RIB-Out pre-policy yet, as this would
>>     require more intrusive changes related to export tables.
>>
>> I suspect that you don’t export from the |out_table| actually, you 
>> are using the main table instead if I read your patch correctly.
>>
>> Also, your commit is missing documentation in |doc/bird.sgml|, as 
>> well as supported RFC in |proto/bmp/bmp.c| header.
>>
>> You should also check mergability of your patch with the thread-next 
>> branch, as if I remember correctly, the out_table is implemented 
>> there completely differently.
>>
>> Last but not least, I would love to see a commit on top of 
>> https://gitlab.nic.cz/labs/bird-tools/ in the |netlab| folder as an 
>> automatic test suite. David Petera (cc) is currently working on BMP 
>> tests for other scenarios, and it might be worth consulting this 
>> topic with him.
>>
>>     I would be interested to know whether this is something you would
>>     consider merging. More generally, is there interest in extending
>>     BMP support in BIRD with additional features? I know that BMP is
>>     still marked as preliminary and not production-ready, but it is a
>>     protocol I personally rely on quite heavily.
>>
>> BMP should be production-worthy and we do consider merging BMP 
>> extensions.
>>
>> Please note, however, that BGP export is a very hot path and one 
>> should very much think about what is being done there, 
>> performance-wise. That deserves at least a warning in the 
>> documentation, so that somebody doesn’t unknowingly turn their router 
>> into a traffic generator.
>>
>> More specifically, the BMP implementation still severely lacks update 
>> merging, and there have been some very serious thoughts about merging 
>> the BMP TX with BGP TX data structures (which would do the update 
>> merging). With that, I would suggest informing us about your plans 
>> beforehand, so that we can plan around accordingly.
>>
>> Have a nice day!
>> Maria
>>
>> –
>> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20260226/bed8c315/attachment.htm>