Hi Hank, We simply record what is announced in the global table as seen by our 50+ collectors. It's not a question of trust or otherwise. ;-) If it is announced, and our collectors see it, it's real. Looks like F5 needs to check that the route really has been withdrawn - while they think they might have withdrawn it, what about the other ASNs in the path between them and the collector that sees it? Sadly it seems to be getting more common for some BGP implementations (and indeed ASes) to "hold on" to routes that have been withdrawn, for whatever reasons they have for doing this. These ghost routes (and paths) are seen in the various BGP toolkits that use RouteViews data; there is not a lot we can do to help fix (we can reset our BGP sessions to the peers we hear the route from, to no avail), and we always suggest to ask the ASNs that are holding on to those announcements why they are doing so. But rest assured, RouteViews is not "incorrect". If you announce it, we see it. Our recommendation is to chase down the problem in the path between the origin and our collector. :-) Best wishes! philip -- Hank Nussbacher via NANOG wrote on 3/3/2026 16:13:
Hi,
We had F5 announce a /24 on our behalf. We then asked F5 to withdraw that /24. Route-views showed the /24 still being announced via an F5 path. F5 claims that route-views is incorrect and the route had been properly withdrawn. They state that public route collectors (including route-views) reflect what their individual collector peers are seeing at a given moment. Due to propagation timing, peer refresh intervals, and collector update cycles, visibility across different monitoring platforms is not always perfectly synchronized in real time.
Have others seen this type of issues from route-views?
Thanks,
Hank
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/ nanog@lists.nanog.org/message/GF6SKJK2X3NCOELFTAHZOTRO62DH5G6O/