Skip to content

* BMP daemon: add EVPN route-monitor parsing and JSON fields - #918

Draft
jaredmauch wants to merge 9 commits into
pmacct:masterfrom
jaredmauch:bmp_evpn
Draft

jaredmauch wants to merge 9 commits into
pmacct:masterfrom
jaredmauch:bmp_evpn

Conversation

@jaredmauch

Copy link
Copy Markdown
Contributor

Short description

Wires in the BMP code similar to the BGP code for emitting EVPVN routes

Checklist

I have:

  • [ x ] compiled & tested this code
  • [ x] included documentation (including possible behaviour changes)

@paololucente paololucente left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Jared ( @jaredmauch ),

Thanks very much for this monumental contribution, support for EVPN in BGP and BMP is something that has been long in the radar as a future feature, so this all goes in the right direction.

Could you by any chance share (here or privately) a BMP trace that can be replayed with bmp_play ( https://github.com/paololucente/bmp_play ) so that i can test the code at my end? This would allow me to take care of a couple of improvement to this PR, for example:

  • Dynamic and conditional allocation of EVPN data
  • Better integrate code in bgp_nlri_parse() to avoid the continue
  • Move code in a new bgp_evpn.c file

I would have also a question for you since right now only msglog is supported. Would we store EVPN data in memory, effectively building a RIB, for supporting dumps at regular time intervals later: how would you propose to organize it? As a RIB with longest-prefix match using maybe evpn_ip for that or rather as a hash where we define a key (and if so which one?) so that entries can be inserted / updated for non-key attributes / removed? What would be useful?

Paolo

@jaredmauch

Copy link
Copy Markdown
Contributor Author

Hey Jared ( @jaredmauch ),

Thanks very much for this monumental contribution, support for EVPN in BGP and BMP is something that has been long in the radar as a future feature, so this all goes in the right direction.

Could you by any chance share (here or privately) a BMP trace that can be replayed with bmp_play ( https://github.com/paololucente/bmp_play ) so that i can test the code at my end?

So I just pushed up some anonymized data for the test suite and added the 209 test, is that enough to satisfy what you need on this? if not, I can work to get you the private data which is more complex.

jaredmauch added 9 commits May 5, 2026 07:03
Add a new BMP EVPN regression test with sanitized raw_msg hex samples covering route types 1-5, so parser-output invariants are validated deterministically without traffic replay.
Decode EVPN (type 0x06) and Encapsulation opaque communities with IANA
names and structured or hex value fields; unknown EVPN sub-types and other
unhandled tuples use hex instead of "?". BMP route-monitor uses the same
bgp_attr_parse_ecommunity path as BGP UPDATEs, so ecomms strings match.
Decode tunnel TLVs and sub-TLVs into a summary string (VXLAN/NVGRE VNI,
egress endpoint); expose as tunnel_encap in JSON msglog. Include attribute
in attr hash interning; fix BGP-LS attr parse fall-through to default.
Introduce config directive bmp_daemon_msglog_evpn_raw_msg (default false).
When enabled on BMP, unknown path attributes in UPDATE messages are collected
as tlv type plus hex payload (0x-prefixed, truncated at 4096 octets) and
emitted in EVPN JSON msglog as unknown-tlv array. Extend bgp_attr_parse with
bgp_msg_data context and bgp_peer_log_msg with optional bmd for JSON output.
Parse path attribute 22 (RFC 6514) into structured PMSI fields, emit them in JSON output, and include PMSI state in attribute lifecycle/hash paths so EVPN IMET updates are logged as decoded PMSI instead of unknown TLV blobs.
Parse RFC4577-compatible legacy EC types 0x8000 and 0x8001 into OSPF-RT and OSPF-RID display strings, and update 302/304 expected JSON fixtures to match the new decoded ecomms format.
This allows JSON msglog to emit parsed extended communities as ecomms_list objects and suppress legacy ecomms output unless explicitly disabled.
This makes ecomms_list emit singleton values for constrained ECs and arrays for repeatable ones while keeping 302/304 fixtures stable by explicitly disabling ecomms_list in their configs.
@jaredmauch
jaredmauch marked this pull request as draft May 5, 2026 11:05

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants