Skip to main content
BGP & Routing

IP BGP Lookup

Instantly look up the BGP routing context for any IP address — originating ASN, covering prefix, RPKI validity, peer visibility, and network operator details.

Advertisement · Anuncio

Lookup IP Address
About IP BGP Lookup

Every public IP address is reachable on the internet via BGP routes announced by Autonomous Systems. When you look up an IP, you're querying the global routing table to find which AS "owns" that address block and how widely the route is propagated.

Understanding BGP Routing for an IP

  • Longest Prefix Match: BGP routers use the most-specific (longest) matching prefix. An IP like 8.8.8.8 might match both 8.0.0.0/8 and 8.8.8.0/24 — the /24 wins.
  • AS Path: The sequence of ASNs a packet traverses to reach its destination, used to detect loops and apply routing policy.
  • RPKI Validity: Route Origin Authorization certificates cryptographically bind a prefix to its authorized origin ASN, preventing route hijacks.
  • Peer Visibility: More route collector peers seeing a prefix means broader global propagation and higher confidence in the route.

Use Cases

Network engineers use IP BGP lookups to investigate suspicious traffic sources, verify that their own IP blocks are correctly announced, identify BGP hijacks in real-time, and research the network infrastructure behind any IP address.

Expert guide · IP BGP Lookup

What it does

IP BGP Lookup starts from a single address, the kind you find in a firewall log or an abuse report, and tells you which route on the Internet carries traffic to it. It asks RIPEstat for the most specific announced prefix covering the IP and its origin ASN, then in parallel fetches the RPKI state of that prefix and origin, the AS name, description and country, and the number of RIPE RIS collector peers that currently see the route.

Why it matters

  • Incident response: Turning an attacking IP into its covering prefix and origin network tells you whether to contact a hosting company, a residential ISP or a cloud provider, and what scope a block would have.
  • Unrouted sources: Traffic from an address that has no route at all cannot receive replies, which strongly suggests spoofing and changes how you mitigate.
  • Service dependency mapping: Looking up the IPs behind a SaaS endpoint reveals which cloud or CDN actually serves it, and whether its route is RPKI-protected.
  • Troubleshooting reachability: If customers in one region cannot reach an address, a low peer count or an invalid RPKI state points to a routing cause rather than an application one.
  • Verifying your own addresses: Checking a server IP after a migration confirms that the expected prefix and origin carry it and not an old aggregate from a previous provider.

How to read the results

  • Covering Prefix: The most specific announced route that contains the IP; this is the route routers actually use for it, even if a larger aggregate also exists.
  • Origin ASN: The AS that originates that prefix; for cloud and hosting addresses this is the provider's ASN, not the customer renting the IP.
  • Network Description and Country: AS-level information from RIPEstat; country is where the AS is registered, not necessarily where the address is used.
  • RPKI Status: valid when a ROA authorizes this origin and prefix length, invalid when a ROA contradicts it, otherwise shown as no ROA found.
  • Peer Count: How many RIS collector peers carry the covering prefix; compare it with a well-known address to judge whether visibility is normal.
  • No route found: The IP is not inside any announced prefix seen by RIS, typical of unused, internal or bogon space.

Technical background

Every IP packet on the Internet is forwarded by matching its destination against routing tables and choosing the longest matching prefix. So the question 'who routes this IP' has a precise answer: the most specific prefix in the global table that contains it, and the AS that originates that prefix. For 8.8.8.8 that is 8.8.8.0/24 originated by AS15169, even though Google also announces larger blocks. This tool performs that lookup against data collected by the RIPE NCC Routing Information Service, which peers with hundreds of networks and records what they see.

That routing view complements, but does not replace, the registry view. Registration records in ARIN, LACNIC or the other RIRs say who holds a block. Routing says who announces it right now. The two differ routinely: a provider announces an aggregate that contains addresses reassigned to customers, a company leases space to another network, or a cloud provider originates addresses that thousands of tenants use. When investigating abuse, the origin ASN identifies the network that can act, and the registry record identifies the abuse contact; check both.

Several patterns are worth recognizing. Anycast addresses, like public DNS resolvers and CDN front ends, are announced from many locations with the same origin, so the lookup shows one prefix and one ASN even though the server answering you is nearby. Addresses with no covering route either belong to unused space or are bogons; if they show up as sources in your logs, the packets were almost certainly spoofed, because no reply could ever reach them. Addresses inside a prefix whose RPKI state is invalid may be reachable from some networks and not others, because ROV-enforcing networks drop the route while others accept it.

The peer count gives a quick visibility check. A healthy, globally announced prefix is seen by most full-table RIS peers. A much lower number suggests the route is filtered somewhere, is too specific, or was announced only recently. Combined with the RPKI state, it is often enough to explain why a destination is reachable from one region and not from another.

Keep the limits in mind. RIS sees the Internet from its peers' perspective, which is broad but not complete, and the AS country is administrative data. For physical location, rely on latency measurements or geofeeds published by the operator under RFC 8805.

Common errors and how to fix them

Problem Blocking an entire origin ASN or large aggregate because one IP in it attacked you.
Fix Block the specific IP or the covering /24 at most, and report to the origin network's abuse contact; large cloud and ISP ASNs carry millions of unrelated users.
Problem Reporting abuse to the cloud provider's ASN contact when the IP belongs to a reassigned customer with its own abuse desk.
Fix Combine this routing lookup with a registry query (RDAP) for the same IP; use the most specific abuse contact, and the provider only if the customer does not respond.
Problem Assuming an unrouted source IP in logs is a real host that can be contacted.
Fix Treat traffic from unrouted or bogon sources as spoofed: filter it at the edge with BCP 38-style rules and use flow data to identify the ingress interface instead.
Problem Reading the AS country as the user's location for compliance or fraud decisions.
Fix Use the AS country only as a hint. Multinational and cloud networks register in one country and operate everywhere; rely on latency or published geofeeds for location.
Problem Seeing an unexpected origin for your own server IP after a migration and ignoring it.
Fix Check whether the old provider still announces an aggregate covering your new space, ask them to withdraw it, and publish a ROA for the correct origin so the stale route becomes invalid.

Do it from the command line

macOS

# Covering prefix and origin for an IP
curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=8.8.8.8" | python3 -m json.tool | grep -E '"resource"|"asn"|holder'
# Path your own traffic takes, with AS numbers per hop
traceroute -a 8.8.8.8

Windows

# Origin ASN and covering prefix via RIPEstat
(Invoke-RestMethod "https://stat.ripe.net/data/prefix-overview/data.json?resource=8.8.8.8").data | Select-Object resource,announced,asns
# Hop-by-hop path
tracert -d 8.8.8.8

Linux

# Origin through DNS, quick and scriptable
dig +short 8.8.8.8.origin.asn.cymru.com TXT
# Traceroute with AS lookups per hop
mtr -z -r -c 5 8.8.8.8
# Which route does your own router use for the address (FRRouting)
vtysh -c 'show ip bgp 8.8.8.8'

Frequently asked questions

How do I find which network an IP address belongs to?

There are two answers. The routing answer is the origin ASN of the most specific BGP prefix that covers the IP, which is what this tool shows and identifies the network that carries the traffic. The registry answer is the organization recorded by the RIR for the block, shown by RDAP or WHOIS. They usually match for ISPs and often differ for cloud, hosting or leased space.

Why does an IP show no route found?

No prefix covering it is announced in the global BGP table as seen by RIPE's collectors. That is normal for private and other bogon ranges, for registered space the holder does not use, and for addresses recently withdrawn. If a public service you depend on suddenly shows no route, its provider has withdrawn or lost the announcement, and nobody outside can reach it.

Why do I see the cloud provider's ASN instead of the company using the IP?

Cloud and hosting providers announce their address pools from their own ASNs and assign individual IPs to customers. The routing table never contains the customer's identity. To find the customer you need the provider's abuse process or, sometimes, a reassignment record in the registry. The same applies to CDNs, where the IP you reach belongs to the CDN, not the website owner.

Can an IP be reachable from some countries but not others?

Yes. If its prefix is RPKI invalid, networks that enforce ROV drop it while others still accept it. A prefix longer than /24 may be accepted only near the originating network. A provider-specific community can also limit propagation on purpose. The peer count and RPKI status in this lookup are the quickest way to check whether one of those causes applies.

What does peer count mean for a single IP?

It is the number of RIPE RIS collector peers whose routing tables contain the prefix that covers the IP. Each peer is an independent network, so the number approximates how widely the route has propagated. Popular, well-announced prefixes are seen by most full-table peers; a noticeably smaller number points to filtering, a recent announcement or an intentionally limited scope.

100-Day Max Lifespan
155d 5h 20m 15s
PQC Migration Target
1178d 5h 20m 15s