Introduction

There is no complete and accurate public list of business relationships between networks. The AS relationships shown in our AS Explorer dashboard are therefore inferred rather than directly verified. They indicate whether two connected Autonomous Systems (ASes) have a customer-provider or peer-to-peer relationship. These estimates rely primarily on the AS paths visible in BGP data and, for some unresolved links, on published Routing Policy Specification Language (RPSL) policies.

This post walks through the inference algorithm, from preparing the routing data to classifying the links that remain unresolved, with an example for each step.

These results are estimates, not ground truth. More observations usually improve confidence, but unusual routing can still produce a wrong result.

🌐 If you operate a network, contributing routing data helps us infer your network's AS relationships more accurately. You can connect and contribute data through our Personal dashboard, using a simple, fully automated setup process. Watch our YouTube walkthrough to see how to get started.

Data collection, preparation and initialisation

We combine unique BGP paths from the current computation day and the five preceding days, using data collected by bgproutes.io, RIPE RIS, and RouteViews. We remove unusable paths and IXP route-server ASNs.

Then, a directly observed link between two known Tier-1 networks is classified as peer-to-peer. Tier-1 networks are assumed to have no providers, so a customer-provider relationship between them would contradict that starting assumption.

Next, we identify each directly observed AS-to-AS link and examine every cleaned path that contains it. The inference rules use these paths to gather evidence for each possible relationship: peer-to-peer, or provider-to-customer in either direction. For BGP-based decisions, we count how often the paths support each result. The relationship supported by the majority of paths wins when it meets the checks described below.

The remaining rules run in five steps, numbered 1 through 5. Later steps handle links that earlier steps did not classify; they can also use published RPSL policies when the BGP evidence is insufficient. The thresholds used below were chosen by comparing the inferred relationships with real-world observations and selecting the values that maximize the algorithm's accuracy.

Step 1: Follow paths away from Tier 1

Step 1 starts with paths that pass through a Tier-1 network. The first link away from Tier 1 may be either peer-to-peer or provider-to-customer, so Step 1 leaves it for Step 2.

Under the algorithm's routing-policy assumption, either type of first link can only be followed by provider-to-customer links. Step 1 therefore classifies each still-unclassified link beyond the first as provider-to-customer, in the direction away from Tier 1, when at least half of the AS paths containing that link support this direction.

Step 2: Check the first link after Tier 1

Step 2 returns to the link between the last Tier-1 network in an AS path and its immediate neighbor. Step 1 left this link unclassified because the two networks could be peers, or the neighbor could be a customer.

Step 2 classifies the Tier-1 network as the provider and its neighbor as the customer only if:

• At least 75% of the AS paths containing the link support that direction.
• The link appears in at least 5 AS paths.
• The proposed customer has no more than 200 observed neighbors.

The neighbor limit makes this rule conservative: a large network connected to a Tier-1 may instead be its peer.

Step 3: Check the link before the route origin

Step 3 examines the final link in AS paths containing more than four ASes. It classifies the network immediately before the route origin as the provider and the origin as the customer only if:

• The link appears in at least 30 AS paths.
• It is the final link in at least 99% of the AS paths containing it.
• The proposed customer is not a Tier-1 network.
• The proposed customer has no more than 1,000 observed neighbors.

If any condition fails, the link remains unclassified for the next step.

Step 4: Check RPSL policies from both networks

For each link still unclassified after the BGP-based steps, Step 4 examines the Routing Policy Specification Language (RPSL) policies published by both connected networks.

It assigns a customer-provider relationship only when both networks provide usable policy evidence that agrees on one clear direction. It ignores peer-to-peer, ambiguous, one-sided, malformed, or conflicting policy results. A Tier-1 network is never classified as the customer.

Step 5: Classify the links that remain

Any observed link still unclassified after the BGP and RPSL customer-provider rules is classified as peer-to-peer.

This is a fallback: it means Steps 1–3 did not find enough BGP evidence for either customer-provider direction and Step 4 found no strict bilateral RPSL result.

When evidence conflicts

Different AS paths can suggest different relationships for the same link. The algorithm counts how often each result appears and applies the percentage required by the current step. If the BGP evidence is insufficient, it checks strict bilateral RPSL evidence before using the final peer step.

The inference is recomputed daily as new BGP data arrives.

Explore an inference in the AS Explorer

You can inspect these results in the AS Explorer. For example, the Upstreams tab for Swisscom (AS3303) lists networks inferred to be its providers. Each row has a Detail button that opens an explanation of how bgproutes.io inferred that relationship.

The detail panel explains the rule behind an inference and shows how many cleaned AS paths support the relationship or its opposite. Below the explanation, you can expand the list of AS paths used as evidence. This lets you inspect the observations behind a result and understand why the algorithm classified the link as it did.

For bug reports or questions, contact us at contact@bgproutes.io.