bgpmap.net - free multi-vantage BGP looking glass
Hi all, Wanted to share a small side project: bgpmap.net, a free BGP looking glass with a visual AS-path map. Data comes from RIPE RIS via RIPEstat, shown from multiple vantage points in one view. No signup, free to use. Honest disclaimer: this is my first website and a learning project, so keep expectations modest. Not trying to replace bgp.tools or anything close to it. I built it because I wanted a cleaner way to compare AS paths across vantage points. If anyone has a minute to try it, I'd appreciate feedback on anything that looks wrong in the data, features you'd actually use, or rough edges in the UI. Thanks, Matin https://bgpmap.net
On 17/09/2026 21:03, Matin Baloochestani via NANOG wrote: Nice tool and well thought out. The red link is described as "Most Observed AS-PATH" yet I have a /24 that has only 11 peer count (with all other paths having larger peer counts) yet is marked as red: https://bgpmap.net/s/vpjmtb8tig Or am I missing something? Thanks, Hank
Hi all,
Wanted to share a small side project: bgpmap.net, a free BGP looking glass with a visual AS-path map. Data comes from RIPE RIS via RIPEstat, shown from multiple vantage points in one view. No signup, free to use.
Honest disclaimer: this is my first website and a learning project, so keep expectations modest. Not trying to replace bgp.tools or anything close to it. I built it because I wanted a cleaner way to compare AS paths across vantage points.
If anyone has a minute to try it, I'd appreciate feedback on anything that looks wrong in the data, features you'd actually use, or rough edges in the UI.
Thanks, Matin https://bgpmap.net _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3IBZTYUU...
I don't want to hijack this thread, but I thought some feedback could be useful for everyone. We have also been working on an open-source tool based on RIPE NCC's BGP data. It supports both historical monitoring (going back to July 2024) and live monitoring, and also shows RPKI status. Here are a few examples: - Recent hijack targeting Hetzner: https://www.ihr.live/en/bgp-monitor?prefix=162.55.80.0/24&data-source=bgplay&start-time=2026-08-28T12:00&end-time=2026-08-30T12:00&rrcs=0&message=111 - North-Korean AS mishap with RPKI: https://www.ihr.live/en/bgp-monitor?prefix=175.45.176.0/24&data-source=bgplay&start-time=2025-03-18T00:00&end-time=2025-03-20T00:00&rrcs=3,6&message=0 We'd love to hear feedback from operators! Cheers, Romain ________________________________________ From: Hank Nussbacher via NANOG <nanog@lists.nanog.org> Sent: Friday, September 18, 2026 14:16 To: North American Network Operators Group Cc: Matin Baloochestani; Hank Nussbacher Subject: Re: bgpmap.net - free multi-vantage BGP looking glass On 17/09/2026 21:03, Matin Baloochestani via NANOG wrote: Nice tool and well thought out. The red link is described as "Most Observed AS-PATH" yet I have a /24 that has only 11 peer count (with all other paths having larger peer counts) yet is marked as red: https://bgpmap.net/s/vpjmtb8tig Or am I missing something? Thanks, Hank
Hi all,
Wanted to share a small side project: bgpmap.net, a free BGP looking glass with a visual AS-path map. Data comes from RIPE RIS via RIPEstat, shown from multiple vantage points in one view. No signup, free to use.
Honest disclaimer: this is my first website and a learning project, so keep expectations modest. Not trying to replace bgp.tools or anything close to it. I built it because I wanted a cleaner way to compare AS paths across vantage points.
If anyone has a minute to try it, I'd appreciate feedback on anything that looks wrong in the data, features you'd actually use, or rough edges in the UI.
Thanks, Matin https://bgpmap.net _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3IBZTYUU...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/YMV6LY2Z...
Hi Hank, Thanks, and fair question. Those two numbers measure different things. "Most Observed AS-PATH" counts exact full paths -- here "24482 35280 378", seen by 11 peers. The edge labels count how many peers cross that edge. The 25 peers on AS1299 -> AS35280 are split across several different full paths ("6830 1299 35280 378", "3491 1299 35280 378", ...), which is why that 25 never turns into a single winning path. Each peer reports the path as it saw it, so the leftmost ASN varies from peer to peer -- 259 unique paths from 349 peers in this snapshot. But you're right that the red highlight oversells it. Painting a 3% path red next to edges showing 25/18/15 makes it look like the "main" path, which it isn't. That's a display problem on my side. The computation stays as-is; I'll rework the presentation early next week -- most likely only highlighting when the top path actually has a meaningful share, and labeling the rest more honestly. I'll share what I come up with here. If you have a preference for how it should read when the winner's share is this small, I'd appreciate your take. Thanks again, Matin
Hi Romain, Thanks for sharing -- I'll take a closer look at IHR. I'd value your feedback on bgpmap.net too, given the overlap. Matin
Not to discourage you, but this largely duplicates HE's AS route propagation graph. On Thu, Sep 17, 2026 at 2:26 PM Matin Baloochestani via NANOG < nanog@lists.nanog.org> wrote:
Hi all,
Wanted to share a small side project: bgpmap.net, a free BGP looking glass with a visual AS-path map. Data comes from RIPE RIS via RIPEstat, shown from multiple vantage points in one view. No signup, free to use.
Honest disclaimer: this is my first website and a learning project, so keep expectations modest. Not trying to replace bgp.tools or anything close to it. I built it because I wanted a cleaner way to compare AS paths across vantage points.
If anyone has a minute to try it, I'd appreciate feedback on anything that looks wrong in the data, features you'd actually use, or rough edges in the UI.
Thanks, Matin https://bgpmap.net _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/3IBZTYUU...
On Fri, 18 Sep 2026, Tom Beecher via NANOG wrote:
Not to discourage you, but this largely duplicates HE's AS route propagation graph.
On Thu, Sep 17, 2026 at 2:26 PM Matin Baloochestani via NANOG < nanog@lists.nanog.org> wrote:
Thanks, Matin https://bgpmap.net
One difference though is, bgp.he.net has the "Graph v4" and "Graph v6" tabs, but does this by ASN. Matin's tool does the graphing by prefix. It might be nice to include in the output, when the lookup was done using an IP with no mask, the prefix that was found that matched the supplied IP. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Yes it does. Personally, I don't find a single prefix visualization helpful, as it will mostly duplicate the general AS propagation graph. It might be interesting if it could do "compare AS graphs for prefix FOO and BAR" or something like that, but generally you are going to do that muh quicker on a CLI or with grep/awk fu. On Fri, Sep 18, 2026 at 11:12 AM Jon Lewis via NANOG <nanog@lists.nanog.org> wrote:
On Fri, 18 Sep 2026, Tom Beecher via NANOG wrote:
Not to discourage you, but this largely duplicates HE's AS route propagation graph.
On Thu, Sep 17, 2026 at 2:26 PM Matin Baloochestani via NANOG < nanog@lists.nanog.org> wrote:
Thanks, Matin https://bgpmap.net
One difference though is, bgp.he.net has the "Graph v4" and "Graph v6" tabs, but does this by ASN. Matin's tool does the graphing by prefix. It might be nice to include in the output, when the lookup was done using an IP with no mask, the prefix that was found that matched the supplied IP.
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/R7LQ3XIU...
Hi Tom, Fair point, and thanks for the pointer. I should have mentioned this in my first email: the idea came from bgpmap.sdv.fr (SdV, AS8839). My team used it almost daily for troubleshooting our own network (AS49556) -- it was genuinely useful to us. A few weeks ago it started returning 403 Forbidden, which pushed me to build our own. No intention to compete with anyone here -- HE's tools are great and have been around long before us. This is just a small tool I built for our own troubleshooting and decided to share. It draws the per-prefix map from many vantage points -- that's the part we were missing. It's still new, so feedback is welcome. Matin
Hi Jon, You're completely right, and that's very good feedback. I'll add the matched prefix to the output in the next update. Matin
That's fair for networks where an AS's prefixes mostly share the same paths. In my experience it isn't always the case -- we run 50+ prefixes and regularly steer individual ranges (tagging to shift a path, announcing some prefixes only to certain upstreams), so each prefix can end up with quite a different path. That's when a per-prefix view actually helps. Matin
On 20 September 2026 09:18:15 CEST, Matin via NANOG <nanog@lists.nanog.org> wrote:
Hi Jon,
You're completely right, and that's very good feedback. I'll add the matched prefix to the output in the next update.
Matin _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GDSG527Z...
Please don't connect Claude directly to the NANOG meeting list.
Ha! I don't actually use Claude. Gemini is my grammar assistant :) English isn't my first language, but the typos are all mine. On Mon, Sep 21, 2026 at 1:27 AM Kevin Tillery via NANOG < nanog@lists.nanog.org> wrote:
On 20 September 2026 09:18:15 CEST, Matin via NANOG <nanog@lists.nanog.org> wrote:
Hi Jon,
You're completely right, and that's very good feedback. I'll add the matched prefix to the output in the next update.
Matin _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GDSG527Z...
Please don't connect Claude directly to the NANOG meeting list. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KIZICYTC...
On Fri, Sep 18, 2026 at 11:11:16AM -0000, Matin via NANOG <nanog@lists.nanog.org> wrote a message of 28 lines which said:
"Most Observed AS-PATH" counts exact full paths -- here "24482 35280 378", seen by 11 peers. The edge labels count how many peers cross that edge. The 25 peers on AS1299 -> AS35280 are split across several different full paths ("6830 1299 35280 378", "3491 1299 35280 378", ...), which is why that 25 never turns into a single winning path.
Then <https://bgpmap.net/s/5j6fybd3dg> is not clear. "24482 12322" has 11 RIS peers, but "6939 3356 12322" has 33. Why isn't it in red?
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 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 (8.8.8.8) https://bgpmap.net/s/zx293h38md and https://bgpmap.net/s/nef7mu8jbr (a /27 seen only by one RouteViews peer in Sydney, invisible to RIS) The merge rules are documented here: https://bgpmap.net/methodology#sources Feedback is very welcome, especially on the merge logic. Thank you, Matin
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>
Hi Terry, Sorry it took me almost a week to get back to you. It was a busy week, but honestly the main reason is that I didn't want to reply until I was sure, and checking it properly took me longer than I thought. Thank you for this. You pulled the raw JSON and rebuilt the whole merge with your own script, which is a lot of work for someone else's tool. Good to hear the dedup and the counts matched. You were right about the red line. Every path starts with the reporting peer's own AS, so the old line was basically the path of whoever feeds the most collectors. To be sure, I tested it on our own network. Our upstream lets us pick the international carrier per prefix with a community, So yesterday, I took a /24 with no customers on it and moved it between carriers for a few hours, taking snapshots every few minutes. When one carrier had almost all the paths, both methods showed the same thing. When traffic was split, the old line showed the wrong carrier in all 5 snapshots and your way showed the right one in all 5. So it's live now as method 2.0. The red line drops the peer's AS and counts each network once, and the page also shows the share of each upstream. That second part matters right after a switch, when even the new line can lag for a minute. The graph now also says which upstreams the 4-per-AS limit hides, which is why AS6453 wasn't drawn in your example. Old snapshots keep their old line. https://bgpmap.net/methodology#red-line Thanks again, really appreciate it. Matin On Mon, Oct 5, 2026 at 5:16 PM Terry Keeling <tkeeling@infranetworks.com> wrote:
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.
3. 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. 4. 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). 5. 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
[image: Logo image] *Terry Keeling* CISSP, CySA+, OSCP IT Security & Infrastructure 2 Batterymarch Park, Suite 102, Quincy, MA 02169 <https://www.google.com/maps/search/2+Batterymarch+Park,+Suite+102,+Quincy,+MA+02169?entry=gmail&source=g> InfraNet Solutions Inc. <https://www.infranetworks.com/> | Email Support <+support@infranetworks.com> W: 781-356-5858 x236 | D: 617-729-3070 tkeeling@infranetworks.com | Book time to meet with me! <https://outlook.office.com/bookwithme/user/8ec238638d8943799bb9f23989cf7f02%40infranetworks.com/meetingtype/ae33aefe-04f0-4560-a188-a86e8182f1b7?anonymous>
[image: Facebook: infranetworks] <https://www.facebook.com/infranetworks> [image: X: infranetworks] <https://twitter.com/infranetworks> [image: Instagram: infranetfriends] <https://www.instagram.com/infranetfriends> [image: LinkedIn: infranet-solutions] <https://www.linkedin.com/company/infranet-solutions>
------------------------------ *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 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 (8.8.8.8)
https://bgpmap.net/s/zx293h38md and https://bgpmap.net/s/nef7mu8jbr (a /27 seen only by one RouteViews
peer in Sydney, invisible to RIS)
The merge rules are documented here:
https://bgpmap.net/methodology#sources
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/MEFEAEAJ...
participants (9)
-
Hank Nussbacher -
Jon Lewis -
Kevin Tillery -
matiinbaloochestani＠gmail.com -
Matin Baloochestani
-
Romain Fontugne -
Stephane Bortzmeyer -
Terry Keeling -
Tom Beecher