Output from zebra-dump-parser and bgpreader are different

[ACodingfreak]

Hi All,

I am downloading below MRT file from RIS and trying to parse it via zebra-dump-parser and pybgpstream
wget https://data.ris.ripe.net/rrc00/2023.01/updates.20230120.1420.gz

As you can see in below output, according to zebra-dump-parser we have one BGP update containing 3 announced prefixes. But in the case of bgpreader it is split into 3 different BGP updates instead of 1. Is this right behavior ?

Output from zebra-dump-parser

TYPE: BGP4MP/BGP4MP_MESSAGE_AS4 AFI_IP
FROM: 23.129.32.61
TO: 193.0.4.28
BGP PACKET TYPE: UPDATE
ORIGIN: IGP
AS_PATH: 49134 53356 6939 265264 52976 16397 15830 265264 52976
NEXT_HOP: 23.129.32.61
ANNOUNCED: 200.169.64.0/24
ANNOUNCED: 200.169.67.0/24
ANNOUNCED: 200.169.65.0/24

Output from bgpreader

U|A|1674224400.000000|singlefile|singlefile|||49134|23.129.32.61|200.169.64.0/24|23.129.32.61|49134 53356 6939 265264 52976 16397 15830 265264 52976|52976|||
U|A|1674224400.000000|singlefile|singlefile|||49134|23.129.32.61|200.169.67.0/24|23.129.32.61|49134 53356 6939 265264 52976 16397 15830 265264 52976|52976|||
U|A|1674224400.000000|singlefile|singlefile|||49134|23.129.32.61|200.169.65.0/24|23.129.32.61|49134 53356 6939 265264 52976 16397 15830 265264 52976|52976|||

[alistairking]

Yes, this is by design.
BGPStream decomposes a single update ("record" in BGPStream terminology) into one "elem" per prefix -- this is because almost nobody cares about processing the update itself, they care about the prefixes contained in the update.
If you really care about the way the prefixes were packed together by the router, then you can iterate over records and for each record, iterate over its elems (this is what is happening under the hood when you iterate over a stream in pybgpstream).
You can read more about this here: https://bgpstream.caida.org/docs/encoding

[ACodingfreak]

Thanks @alistairking

Let me try iterating through BGPRecords instead of BGPElems.