Reading upstream diversity in Cloudflare Radar
The AS routing view sits on top of observed BGP paths, not a live map of every transit relationship. That matters because transit concentration can look flatter or wider depending on which RouteViews collectors are included and how many paths are surfaced at once. A single ASN can look neatly diversified one moment and oddly lopsided the next if the observed path mix changes.
The useful part is the distinction between direct upstreams and longer path segments towards Tier-1 networks. The first tells you who carries traffic. The second shows how those paths reach the top of the BGP hierarchy. If you are trying to spot dependence on one provider, the upstream chart is usually the faster read. If you are trying to understand transit shape, the path view does the heavier lifting.
How Radar turns RouteViews snapshots into an AS routing picture
Radar builds the view from RouteViews RIB snapshots, then unions the selected collectors into one picture. That gives broad coverage, but it also means the result reflects what those collectors saw, not every path in the global table. For AS-level connectivity, the paths are aggregated across all announced prefixes for the queried ASN, which keeps the display manageable and hides a lot of repetition.
The default view is tuned for readability. Full path detail is there behind the show full paths toggle, which is where the less tidy stuff appears. That is useful when the abbreviated graph looks too clean to be trusted. A single ASN can have several observed route segments to the same Tier-1 network, and the short view will not show every last variation.
The same data is exposed through the BGP API too. One endpoint returns ordered AS path segments used to reach Tier-1 networks, with path counts, peer counts, and contributing collectors. Another returns upstream timeseries, with the share of observed paths carried by each direct upstream over time. Both can be narrowed with collector and ipVersion parameters, which is handy when one collector is doing something odd and you want the mess isolated.
Reading the upstream providers chart without overcounting stability
The upstream providers chart is a stacked area view of the share of observed paths carried by each direct upstream. It looks calm when one provider dominates and messy when several split the load. Neither look should be mistaken for firm truth. The chart is only as broad as the collectors and prefixes represented in the RouteViews snapshots behind it.
Series handling matters here too. Up to ten upstreams get their own lines, and the rest are folded into Other. That is fine for keeping the chart usable, but it does hide long tails. An ASN with a lot of small transit relationships can look more concentrated than it really is, simply because the minor carriers disappear into the catch-all bucket.
That makes the chart better for watching change than for counting every provider. A rising Other line can mean genuine diversification, or it can mean the ASN has too many small paths for the display to name. A flat dominant series can mean stable routing, or it can mean the same upstream is visible in the collectors Radar happened to union that day. Boring graphs are often the ones with the most caveats.
Checking IPv4 and IPv6 paths against the same ASN
IPv4 and IPv6 do not have to behave the same way, even when they belong to the same ASN. Radar lets you switch address family, which is where differences in upstream choice and path shape become obvious enough to matter. An ASN can be tightly concentrated in IPv4 and spread across a different set of providers in IPv6, or the other way round.
That split is worth checking before drawing clean conclusions about transit concentration. A single ASN page can make one family look stable and the other look oddly fragmented. If you only inspect one side, you miss the bit that makes the routing picture awkward in the first place. Dual-stack visibility is useful precisely because it exposes those mismatches.
For a practical check, compare the same ASN in both address families and watch for three things: which upstreams appear in each view, whether the full path set changes, and whether one family collapses into a small number of dominant carriers. If the difference is large, treat the ASN as having separate routing behaviour rather than one neat transit story.
