BGP & Routing

BGP Prefix Inspector

Analyze any IPv4 or IPv6 CIDR prefix — origin ASN, RPKI validity, peer visibility, and 30-day routing history from RIPE NCC.

Analyze Prefix

About BGP Prefix Analysis

A BGP prefix (CIDR block) is the fundamental unit of routing information exchanged between Autonomous Systems on the internet. Each prefix has an origin AS that announces ownership and reachability of that address block.

Key Metrics Explained

Origin ASN: The Autonomous System that first originates the prefix into BGP, typically the organization that owns the IP block.
RPKI Status: Whether a Route Origin Authorization (ROA) certificate exists and validates the origin ASN and prefix length.
Peer Count: Number of RIPE NCC Route Collectors (RRCs) that observe this prefix, indicating routing propagation breadth.
Routing History: Timeline of origin changes over 30 days, useful for detecting route hijacks or legitimate transfers.

Why Prefix Analysis Matters

BGP prefix analysis is essential for network security teams investigating route hijacks, validating RPKI deployment, and understanding IP address ownership. Tools like this query RIPE NCC's Routing Information Service (RIS) to provide real-time global routing visibility.

Expert guide · BGP Prefix Inspector

What it does

The BGP Prefix Inspector takes a prefix such as 193.0.0.0/21 or 2001:db8::/32 and queries RIPEstat for its routing state as observed by the RIPE NCC Routing Information Service. It shows the origin ASN and holder, whether the prefix is currently announced, an RPKI status, how many RIS peers carry the route, and a table of up to twenty of those peers with their ASN, peering IP, collector and country.

Why it matters

Post-change verification: After announcing a new block or moving it to a different upstream, the peer count tells you within minutes whether the world actually sees it.
Filtering diagnosis: A prefix that dozens of RIS peers carry but a specific network does not is almost always being filtered there, by IRR, RPKI or prefix length.
Leased space checks: Before using a block bought or rented on the transfer market, confirm it is not still announced by its previous holder or by an unexpected origin.
Customer onboarding: An ISP accepting a customer's prefix can confirm its current origin and RPKI state before adding it to filters, avoiding a surprise invalid.
Incident scoping: During an outage, a sudden drop in peers for one prefix narrows the problem to a withdrawal or a filtering change rather than a data-plane fault.

How to read the results

Origin ASN and holder: The first origin RIPEstat reports for the prefix and its registered name; if several origins exist (MOAS) only the first is shown here.
Announced: Whether RIS currently sees any route for the resource; false means no collector peer carries it, which can be intentional for unused space.
RPKI Status: valid when a ROA authorizes the origin and length, invalid when a ROA covers the prefix but does not match, and anything else is shown as No ROA found; for a precise check with a chosen origin use the RPKI Validator.
Peer Count: The number of RIS collector sessions whose tables contain the route; a widely propagated prefix is seen by most full-table peers, while a low count suggests filtering.
Peers table: The first twenty peers with peer ASN, peer IP, RRC collector (for example rrc00 or rrc15) and country, useful to see which regions or networks are missing.

Technical background

Routers forward packets using longest-prefix match: if a table holds both 203.0.113.0/22 and 203.0.113.0/24, traffic to 203.0.113.10 follows the /24. That simple rule drives most of what you see when inspecting a prefix. Networks announce aggregates to keep the global table small and add more-specifics for traffic engineering, for example sending one /24 through a particular provider, or as a defense, so a hijacker announcing the aggregate cannot win. The cost is table growth for everyone, which is why operators cap what they accept. In practice /24 is the longest IPv4 prefix and /48 the longest IPv6 prefix that propagate widely; a /25 or a /56 will be dropped by most networks even if your upstream accepts it.

The Routing Information Service, run by RIPE NCC since 2001, operates route collectors (rrc00 in Amsterdam is multihop and global, others sit at exchanges such as rrc15 in São Paulo) that peer with hundreds of networks and record their full routing tables and every update. RIPEstat exposes that data through APIs; this tool uses prefix-overview for origin, holder and announcement status, rpki-validation for the RPKI state, and bgp-state for the list of peers that currently carry the route. Peer count is therefore a visibility metric: it reflects how many independent vantage points have the route in their table right now.

Low visibility usually has one of four causes. The prefix is longer than /24 or /48 and gets filtered. The upstream builds customer filters from IRR data and no route object exists for the prefix and origin. The route is RPKI invalid, often because a ROA was created for the aggregate with a maxLength that does not include the more-specific being announced, and the growing number of networks enforcing Route Origin Validation drop it. Or the announcement is scoped on purpose with communities such as no-export or provider-specific tags.

Registration and routing are separate layers. The holder shown comes from the ASN's registration, not from the prefix's registration record, and the block itself might be registered to a different organization if the space is leased. Comparing the origin seen here with the ARIN or LACNIC record and with published ROAs is the quickest way to spot unauthorized announcements and forgotten leases.

Expect a short delay after changes. Collector peers learn routes within seconds, but RIPEstat's state views refresh periodically, so wait several minutes before deciding an announcement did not propagate.

Common errors and how to fix them

Problem Announcing a /25 or /26 to steer traffic or to protect a small service, and it never shows up outside the upstream.: Fix Announce at least a /24 in IPv4 (/48 in IPv6). For DDoS mitigation of a single host, use your provider's remote-triggered blackhole community, often the RFC 7999 BLACKHOLE value 65535:666, which is meant to stay inside the provider.
Problem A new prefix shows only a handful of peers even though the session with the upstream is up.: Fix Create route or route6 objects in your RIR's IRR (or the one your upstream uses) for the exact prefix and origin, and ask the upstream to refresh its filters; many transit providers rebuild filters only once a day.
Problem A more-specific /24 appears with a low peer count and RPKI invalid while the aggregate is valid.: Fix The ROA covers the aggregate with maxLength equal to its own length. Add a ROA for the /24 with the same origin instead of raising maxLength broadly.
Problem A leased block still shows the previous lessee's ASN as origin.: Fix Ask the block holder to update or revoke the old ROA, have the previous user withdraw the announcement, and create a ROA for your ASN before you start announcing.
Problem Checking visibility seconds after announcing and assuming failure.: Fix Allow several minutes for collector state to refresh, and confirm locally first with your router's advertised-routes output to the upstream.

Do it from the command line

macOS

# Origin and announcement status of a prefix
curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=193.0.0.0/21" | python3 -m json.tool | head -30
# Is there an IRR route object for it?
whois -h whois.radb.net 193.0.0.0/21

Windows

# Number of RIS peers that carry the route
((Invoke-RestMethod "https://stat.ripe.net/data/bgp-state/data.json?resource=193.0.0.0/21").data.bgp_state).Count
# Who has originated it over time
(Invoke-RestMethod "https://stat.ripe.net/data/routing-history/data.json?resource=193.0.0.0/21").data.by_origin | Select-Object origin

Linux

# Paths seen by RIS peers (first five)
curl -s "https://stat.ripe.net/data/bgp-state/data.json?resource=193.0.0.0/21" | jq -r '.data.bgp_state[:5][] | .path | map(tostring) | join(" ")'
# Build a prefix filter from IRR data for a customer AS
bgpq4 -4 -l CUSTOMER-IN AS3333

Frequently asked questions

Why is my /25 prefix not visible on the Internet?

Because most networks reject IPv4 routes longer than /24 to protect their routing tables, and your upstream's peers will drop it even if your upstream accepts it. The fix is to announce a /24 or shorter. If you only have a smaller block, it has to be announced by your provider as part of its aggregate, with traffic reaching you over your provider's network.

What does peer count mean in a BGP prefix lookup?

It is the number of route-collector sessions whose routing table currently contains the prefix. Each peer is a separate network feeding its view to the RIPE NCC collectors, so a high count means the route has propagated broadly. Compare it with similar well-announced prefixes; a much lower count indicates filtering somewhere, often due to IRR, RPKI or prefix length.

How long does a new BGP announcement take to propagate?

BGP itself converges in seconds to a few minutes once your upstream accepts the route. The usual delay is administrative: many transit providers regenerate customer filters from IRR data on a schedule, sometimes daily, so a prefix without a pre-existing route object may not be accepted until the next run. Create IRR objects and ROAs before you announce.

Why does a prefix show a different holder than the IP registration?

The holder here is the name of the origin ASN's organization, while the IP registration names whoever holds the block at the registry. They differ when space is leased, when a provider announces addresses assigned to a customer, or when a company uses separate legal entities for its network and its address holdings. Different does not automatically mean unauthorized.

Should I deaggregate my prefix into /24s?

Only with a reason. Announcing /24s can protect against more-specific hijacks and helps steer traffic across providers, but it adds routes to every router on the Internet and each one needs its own ROA. A common compromise is to announce the aggregate plus /24s only for critical services, with ROAs that list each prefix explicitly rather than a broad maxLength.