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

[Matin Baloochestani via NANOG <nanog () lists nanog org>]

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/MEFEAEAJJDL4MT2EEYE4EPGFPSLUZDTR/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/X5YVWXIDQYX5CZU6JVQNXF4HY4CRZB64/