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. For unresolved links, the algorithm can also use published Routing Policy Specification Language (RPSL) policies and BGP Monitoring Protocol (BMP) session metadata. Finally, it checks the results against available Autonomous System Provider Authorization (ASPA) records from the Resource Public Key Infrastructure (RPKI).

This post walks through the inference algorithm, from preparing the routing data to reconciling the resulting relationships, 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

For each of IPv4 and IPv6, 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. We run the relationship inference separately for each address family.

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 the cleaned paths that contain it. The inference rules gather votes for provider-to-customer in either direction from paths eligible for each rule. A link is classified when those votes meet the rule's threshold and other checks.

The remaining rules run in seven steps. Steps 1–5 classify links that earlier steps left unresolved. Step 6 assigns peer-to-peer to any observed links still unresolved, and Step 7 reconciles the completed results with ASPA records. The evidence thresholds are chosen by comparing inferred relationships with real-world observations.

Step 1: Follow paths away from Tier 1

Step 1 starts with paths that pass through a Tier-1 network. It skips the link immediately after the first Tier-1 network in a path: that link may be either peer-to-peer or provider-to-customer. A later step can classify it if it is still unresolved.

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 enough votes from Tier-1-anchored paths agree on that direction. It never makes a Tier-1 network the customer.

Step 2: Check the first link after Tier 1

Step 2 checks an unresolved link between the last Tier-1 network in an AS path and its immediate neighbor. 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:

• The eligible first-hop votes show strong agreement on that direction.
• The link has been observed enough times.
• The proposed customer is not too highly connected.

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 each cleaned AS path. It classifies the network immediately before the route origin as the provider and the origin as the customer only if:

• There are enough eligible last-hop votes for the link.
• Those votes strongly agree on the same customer-provider direction.
• The proposed customer is not a Tier-1 network.
• The proposed customer is not too highly connected.
• The link does not meet the algorithm's core-peer test, which looks for a well-observed link between similarly well-connected networks that is frequently the highest-scoring link on a path.

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: Use BMP session metadata

For an observed link still unclassified after the BGP and RPSL rules, Step 5 can use metadata from active BMP sessions. A full inbound routing feed from a neighbor indicates that the BMP exporter is the neighbor's customer. If the exporter has at least one such provider and also has an active outbound feed toward another neighbor, that other link is inferred as peer-to-peer. A full inbound feed takes precedence over the outbound peer indication for the same link. Conflicting customer-provider assertions are ignored, and a Tier-1 network is never made the customer at this step.

Step 6: Classify the links that remain

Any observed link still unclassified after the BGP, RPSL, and BMP 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, Step 4 found no strict bilateral RPSL result, and Step 5 found no usable BMP result.

Step 7: Reconcile with ASPA records

After every observed link has a relationship, the algorithm checks current ASPA records, if they are available. An ASPA record lists the providers authorized by its customer AS. A direct listing of the other AS as a provider sets the customer-provider direction, even if an earlier step chose a different relationship. If both ASes have ASPA records and neither lists the other, the link becomes peer-to-peer. If an inferred customer has an ASPA record but omits its inferred provider, the link also becomes peer-to-peer unless the other AS directly lists it as a provider.

If both ASes list each other as providers, the algorithm keeps an existing customer-provider direction. If the earlier result was peer-to-peer, it chooses a consistent direction using ASN order. If ASPA data cannot be loaded, this reconciliation is skipped.

When evidence conflicts

Different AS paths can suggest different relationships for the same link. The BGP rules count eligible votes and require enough agreement before classifying a link. If a link remains unresolved, strict bilateral RPSL evidence is checked before BMP metadata and the peer fallback. ASPA records can then change the completed result, including a relationship inferred in an earlier 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, Swisscom's (AS3303) Connectivity view lists its inferred providers under Upstreams. It shows whether each relationship appears in IPv4 or IPv6, alongside ASPA and IRR cross-checks and counts of supporting and conflicting AS paths. The View paths buttons let you inspect the path evidence for each address family.

The inference detail panel shows the address family and explains the final relationship. In this IPv6 example, ASPA provider declarations establish Swisscom (AS3303) as a customer of AS7473 after the earlier inference steps. You can expand the evidence categories to inspect the AS paths and see which step considered each path and whether the path supports or conflicts with the inference.

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