Inconsistent `BgpElem` timestamps for live RouteViews data?

[JustinLoye]

I ran examples/real_time_routeviews_kafka_openbmp.rs and encountered weird timestamps (drifting by several days) for many BGP elements:

It seems to be a problem with BGPKIT or this example, not RouteViews, because bgpreader produces timestamps with the expected small delay and jitter:

I am able to reproduce this behavior. I tried waiting a few hours and changing the collector.
Could you please take a look?

[digizeph]

Will investigate! Thanks for sharing the data!

[digizeph]

Hi @JustinLoye, I've identified the problem.

Root Cause

• The example was using the wrong timestamp source. It was using: header.timestamp (OpenBMP collector timestamp).
• When it should use: per_peer_header.timestamp (BMP per-peer header timestamp - the BGP event time).

Why This Caused Drift

The OpenBMP collector timestamp reflects when the collector processed the message, not when the BGP event actually occurred. During collector backlogs, restarts, or historical data replays, these timestamps can diverge by seconds, hours, or even days.

Fix Applied

The example now correctly selects the timestamp:

let timestamp = if per_peer_header.timestamp > 0.0 {
    per_peer_header.timestamp  // BGP event time
} else {
    header.timestamp             // Fallback: collection time
};

This ensures BgpElem timestamps reflect when the BGP update/withdrawal actually happened, matching what bgpreader produces. The fix is in examples/real_time_routeviews_kafka_openbmp.rs. Let me know if you see any other issues!

[JustinLoye]

Thanks for taking a look!

I still have the problem... I tried removing the fallback, keeping just per_peer_header.timestamp

[digizeph]

Hmm, i can't reproduce on my end after the fix.