Re: bgpmap.net - free multi-vantage BGP looking glass

[Terry Keeling via NANOG <nanog () lists nanog org>]

Hi Matin,
Merging the two sources is a really useful change, and publishing the raw responses made it easy to check the work. 
Thank you for both.
TLDR:
I ran two lookups (99.145.64.17 and 23.30.160.17), pulled the raw JSON from both sources, and re-ran the merge with a 
short script. The dedup reproduces cleanly, with the same counts the page reports.
The one thing worth knowing when reading the graph is that the red Most Observed path is driven by session count. 
Because every AS path starts with the reporting peer's own ASN, the most observed complete path is really the peer 
network with the most collector sessions. On both lookups that is AS24482, which feeds 11 collectors (11 of 438 
sessions on one lookup, 10 of 440 on the other). Counting the upstream hop by distinct peer networks tells a different 
story: AS1299 leads AS2914 into both origins.
Detailed:
I took the raw responses from both sources for 99.145.64.17 (snapshot fw798u3zxh) and for 23.30.160.17 (snapshot 
xujrj3j4up), re-ran the merge as described on the methodology page, and compared the output.
What checks out: for the AT&T lookup I get 294 RIS sessions and 180 RouteViews sessions after dropping the two default 
routes, 36 duplicates, and 438 merged sessions with 340 unique paths. That matches your summary exactly. All 36 
duplicates have identical paths, and the RouteViews peer ASN always equals the first AS in the path. The Comcast lookup 
also matches what the page showed (440 peers, 338 unique paths, 31 collectors). The dedup is deterministic with RIS 
first, as the doc says.

  1.  Session weighting and the red path. Your methodology page is upfront that AS24482 contributes many sessions, and 
in practice it decides the headline on both of my lookups. On AS7018, all 11 of its sessions report AS24482 > AS2914 > 
AS7018. On AS7922, 10 of its 11 report AS24482 > AS2914 > AS7922, and the other goes via AS6453. Since every path 
begins with the peer's own ASN, no complete path can be shared by two peer networks. I checked, and none of the 338 
Comcast paths are. So ranking complete paths by session count mostly ranks peer networks by how many collectors they 
feed. Other multi-session feeders show the same pattern: AS199524 has 10 sessions, AS49544 has 9 and AS8218 has 6.
  2.  The hop distribution disagrees with the red line. For AS7018, sessions and distinct peer ASNs by the hop before 
the origin are:

AS1299: 97 sessions, 77 ASNs
AS3356: 77 sessions, 58 ASNs
AS174: 55 sessions, 44 ASNs
AS2914: 51 sessions, 32 ASNs
AS3257: 30 sessions, 24 ASNs
For AS7922 it is similar: AS1299 has 89 sessions from 70 ASNs, and AS2914 has 43 sessions from 25 ASNs. The highlighted 
route goes through the fourth-largest upstream on both. Removing AS24482 from AS2914's count on AS7018 leaves 40 
sessions from 31 networks.

  1.  Suggestion: rank paths with the peer's own ASN stripped, counted by distinct peer ASN, and show distinct peer 
ASNs on link labels. On the Comcast lookup, the most common stripped path is AS1299 > AS7922, reported by 48 networks, 
followed by AS3356 (36), AS174 (28) and AS2914 (21). Those counts only include peers whose path is exactly peer, 
transit, origin, which is why they are lower than the per-hop totals above. You wrote that a change like this would be 
a new method version, and I agree. I would keep the session counts and add this alongside them.
  2.  The simplified graph hides more than the page implies. On the Comcast lookup, the four drawn upstreams (AS174, 
1299, 2914, 3356) account for 247 of 440 sessions. The remaining 193 go through upstreams that were not drawn: AS6453 
(32), AS3257 (29), AS6762 (21), AS6461 (17), AS6939 (17), AS12956 (16) and others. These counts include 35 sessions 
where the collector peer is itself adjacent to the origin. AS6453 is well above the reported threshold of 13, so is the 
display capping the number of upstreams per AS? Either way, a line like "drawn edges cover 56% of sessions" would be 
easier to read than a hidden-edge count (the AT&T snapshot reports 408 hidden and 5 shown).
  3.  A few questions on the merge rules:

a. Dedup is keyed on peer IP alone. That works well on IXP LANs, where most of my duplicates sit (30 of 36, at AMS-IX, 
LINX, IX.br, NAPAfrica and Singapore). Would keying on peer IP plus peer ASN be safer for multihop peers using private 
addresses?
b. For a bare IP, is the dedup per peer or per peer and prefix? If one session shows a /24 in RouteViews and only the 
covering /16 in RIS, does the RIS copy win and hide the more specific? Neither of my lookups exercised this, so I could 
not test it.
c. "36 seen by more than one" includes one RouteViews-to-RouteViews duplicate (103.247.3.36 on route-views4 and 
route-views5), so the actual RIS and RouteViews overlap is 35. It might be worth separating the two in the summary.
d. The snapshot time is a single value, identical for both sources in my AT&T lookup. Is there a way to show how far 
behind real time the RouteViews API data can be, compared with RIS?
e. The page says prepending is collapsed, and also that the Most Observed path is the exact complete path. Which form 
is used for the ranking? It made no difference to the path counts in either of my lookups, but it could elsewhere. 
AS_SET handling isn't mentioned either.
Overall the merge holds up well against the raw data. The weighting and the display are the parts I would look at. I'm 
happy to share the scripts if they're useful, and thanks again for building this and asking for feedback in the open.
Respectfully,
Terry Keeling, Counter of Peers, Doubter of Red Lines


________________________________
From: Matin via NANOG <nanog () lists nanog org>
Sent: Monday, October 5, 2026 3:43 AM
To: nanog () lists nanog org <nanog () lists nanog org>
Cc: matiinbaloochestani () gmail com <matiinbaloochestani () gmail com>
Subject: Re: bgpmap.net - free multi-vantage BGP looking glass

Hi everyone, A short update on bgpmap.net, which I introduced here a few weeks ago: every lookup now queries RIPE RIS 
and the RouteViews API in parallel and merges the paths into a single graph. Peers
[cid:inky-injection-inliner-6f42d488d348cfcd86bff9497caf9f6a]
External (nanog () lists nanog org<mailto:nanog () lists nanog org>)
[cid:inky-injection-inliner-023b0474c934d83d8d52155624827a68]
  Graymail<removed-link>  Spam<removed-link>  Phish<removed-link>  More...<removed-link>


Hi everyone,



A short update on 
bgpmap.net<https://shared.outlook.inky.com/link?domain=bgpmap.net&t=h.eJw9zEEKwyAURdGtBMdFUWPVjLIVjV8rJhrU0kHp3lsz6OzxDtw3etYdLRN69H4uhNhwHubEGTq6TSgNic21SHoC2GMOa8y-mp-_Sk0Nb-Ugs3WOb17OSgswlBnPleNWK6cAmBWESk2pujMhMaNMUzXaMNrZ5BLWPbbe8LVxqWGo--v1fL6XvzP7.MEUCIQD-ydSjGdyaeWpYiPHsiJJUQbURZwsqx5ppbaJ6IQWOswIgJoqu3D7T4pe6-IIxmbML7rH69OK1FfwJzZ5ZVfibUmo>,
 which I introduced here a few weeks

ago: every lookup now queries RIPE RIS and the RouteViews API in

parallel and merges the paths into a single graph. Peers that feed

both projects are counted once. Each result shows how many peers

came from each source, and the raw responses from both can be

downloaded.



Two examples:

https://bgpmap.net/s/5zxyhbbtdj<https://shared.outlook.inky.com/link?domain=bgpmap.net&t=h.eJw9jMsOgyAUBX_FsG4goFToyl8BLyJVwXBp-kr_vcVFdydnJvMmt7ySS0PmUna8MGb9vpmdRlcYMvl6PGdrC1zJqSFL9QICBlYW59YQ_RDilM1Pvqe8IB3TxjoL0I5T3yktneHCTK2C1moFyjlhJeO95lydheyp4EJzVduutqOJyQ9rwIL02DRlXyn86fF8vi5FOU0.MEUCIQCZQq3hktcooN2exlsnhnIGEnyfMTRXepfUQnjrFnuLcwIgNrgOkg_yLx8TpK2LABXA7QvOIT-Fj3m9xksDHW5YV38>
 (8.8.8.8)

https://bgpmap.net/s/zx293h38md<https://shared.outlook.inky.com/link?domain=bgpmap.net&t=h.eJw9jEEOgyAUBa9iWDf8AFrBlVcBPyJRwQCmTZvevcVFdy9vJvMmZ9rI0JCllCMPAMYduz5osAUyvJ5ciUXIHcmtIWv1fMbsoazWbj640Yc56Z_8iGnNdIo7tAZRTHPfStVZzbiehURhlERpLTcdsF4xJu-86ylnXDFZ27a2gw7RjZvPJdNr05hcpfin1_P5ArF2OHM.MEQCICGswJEtlX1xmIPrAKQMGxyNRowMjHVNaZ903AmLq99wAiB135A4rRaksmqyi-M_grM6S4nXVb6ZoGSRFbLi_3NdLg>
 and 
https://bgpmap.net/s/nef7mu8jbr<https://shared.outlook.inky.com/link?domain=bgpmap.net&t=h.eJw9jEEOgyAUBa9iWDcQUAu48iogH0pVMHxMF03v3uKiu5c3k3mTs2xk6sij1gMnxmw4dnPQBJUhS-DlfqqnLeTWkbV5ER1GVleALaYwx-SL-cmvXFakS97ZYJ3rFy8HpUcwXBjfK9dbrZwCEHZkXGrO1V2MkgouNFetDa2dTMph3iJWpNemuYRG3Z9ez-cLBks5Bw.MEUCIQCPnylcSQaQ7dKD3DCLTumE0qXMiEJqxptehJtlWHooFwIgXPiV4vVSVLRnPp_dck4di3_3z12BwCI6Nt6REM9Yr_M>
 (a /27 seen only by one RouteViews

peer in Sydney, invisible to RIS)



The merge rules are documented here:

https://bgpmap.net/methodology#sources<https://shared.outlook.inky.com/link?domain=bgpmap.net&t=h.eJw9jEEOgyAURK9i6LaBgFrBlVcB-SIR-QYwTdP07i0uupvMm3lvcqZAxoaspRx5ZMy4Y9cHjVDYDmVFiwHd65bxTDNkcm_IVuc-2-xZ2QCCj27ycUn693li2jKdcWedsbadl6GTqgfNhV5aaVujpJUAwvSMD4pz-RD9QAUXisvqhuqOOqKbgs8l0ytTTK5S-6dX8_kCXpk8bw.MEYCIQD4lnbCRUl5MC_ZVtLwUGcl0Lo4YqRbNk5GUtXDtxN7rQIhAOG2o2oy1-HiMkbmoFijT2X1HSmLMf4OJNTEDks4ezNs>



Feedback is very welcome, especially on the merge logic.



Thank you,

Matin

_______________________________________________

NANOG mailing list

https://lists.nanog.org/archives/list/nanog () lists nanog 
org/message/MEFEAEAJJDL4MT2EEYE4EPGFPSLUZDTR/<https://shared.outlook.inky.com/link?domain=lists.nanog.org&t=h.eJxtjrFugzAURX8l8hzxZAPFZAoSTiSUSFGbDslm8INYgIn83Hao8u8RDB2qrPdcnXt_2Zcf2GbFbiHcaQMwWAoUOe2mLpp8B9o3N_uNtABY8u3_zohEukM4qp0qVFFV5SE5noVSF5Wo0353-jh8XsvzO7D1ivXzmiVDFkKPOFjXba1rvXYYfibfU9RMIyS1MXHTZonMU9Rc6DaWJq5zaSSiqFPgWc65fBNpFgkuci5nN87ulx9nav7okjyemUBQxg.MEYCIQCoWYvGZKsFpR5GKBGSyNYZ-imzhlMx5nrvF-BPyc9bnwIhAIDQlhqgxsdaHnQ1yteMDBU_wtBVzkr-LHNHWWt0TCvw>
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/HPIEUCRUEEPFJRLRMKUIAVGPEVKD6JAF/