Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.
"My prefix is announced but nobody can reach it" is one of the most common BGP support questions, and the answer is almost never found by staring at your own router. You need outside views of the routing system. This article walks through a repeatable order of checks using public tools: route collectors (RIPE RIS, RouteViews), RIPEstat, bgp.tools, and the looking glasses that many networks publish. Examples use documentation values (AS64496, 2001:db8:abcd::/48).
First, split the problem in two
Reachability has two halves, and they fail differently:
- Control plane: does the world have a route to your prefix, with your ASN as origin?
- Data plane: if packets arrive, does a host answer, and can the replies get back?
Check the control plane first. If outside vantage points see no route, nothing downstream matters. If they do see it, the problem is usually on your side of the edge.
Step 1: Is the prefix visible at all?
Search for the exact prefix in RIPEstat (the "Routing status" and "BGP looking glass" widgets) or on the bgp.tools prefix page. You want to see:
- The prefix listed as announced, with your ASN as the origin.
- It is seen by many collector peers, not just one or two. A prefix seen by only a handful of peers has usually been accepted by one upstream and stopped there, often because of a filter further along.
- The first-seen/last-seen or routing history is sensible. A prefix that appears and disappears repeatedly points to a flapping session or a flapping static route feeding the export.
If it is missing entirely, go back to your router: is the session Established, is the route in the export table (show route export or the equivalent), and does your export policy actually match the prefix and its length?
Step 2: Read the AS path
Every route in a looking glass shows an AS path, read from the neighbor on the left to the origin on the right. For example:
AS_PATH: 64510 64497 64496
means the observer learned the route via AS64510, which learned it from AS64497, which learned it from the origin AS64496. Things to look for:
- The origin (rightmost) AS is yours. A different origin means someone else is announcing the prefix, or a provider is originating on your behalf, and ROA/IRR data may not match.
- Unexpected intermediate ASNs. If your path goes through a network you do not buy transit from, you may have a leak or a surprising peering relationship.
- Excessive prepending. A heavily prepended path loses to shorter alternatives, which can move traffic in ways you did not intend.
Step 3: Compare vantage points
Run the same lookup from several looking glasses: one in your upstream's network, one at a large transit network, one on a different continent. The pattern tells you where the problem is:
- Visible at your upstream, nowhere else: the upstream is not exporting you onward. Usually an IRR or prefix-filter update is pending, or the prefix was not on their customer filter.
- Visible widely but missing in one network: that network is filtering you, commonly because of RPKI-invalid status, a missing or mismatched IRR object, or a prefix length they do not accept.
Step 4: Check RPKI and IRR status
Both RIPEstat and bgp.tools show RPKI validation state for the prefix and origin pair. Invalid is the one that bites: networks doing route origin validation (RFC 6811) commonly drop it. Invalid means a ROA covers the prefix but the origin ASN differs or the announced length exceeds maxLength. NotFound means no ROA exists and is usually still accepted. Then check that an IRR route6 object exists with your origin ASN, because many providers still build prefix lists from IRR data.
Step 5: Check the length
Large networks commonly filter IPv6 announcements more specific than /48 and IPv4 announcements more specific than /24. This is convention, not a protocol rule, but it is widely followed. If you announce a /56 or a /25, expect it to be absent from most looking glasses. Also look for more-specific prefixes announced by someone else: they win longest-prefix match regardless of your announcement.
Step 6: Use the looking glass for the data plane
Most looking glasses allow ping and traceroute as well as show route. From a vantage point that has a valid route:
- Ping and traceroute to a specific address inside the prefix, not the network address.
- See where the trace stops. If it reaches your upstream and then dies, check that the address is actually configured and that the route inside your network points to it.
- Test the return path: from your host, traceroute back to the looking glass's source. Asymmetric routing is normal, but a missing or filtered return route makes everything look broken.
Step 7: Local causes once the control plane is clean
If the world has a valid route and paths look right, work through the usual suspects:
- Nothing owns the address. Announcing a prefix that points at no configured host is the classic case. Check the address is assigned and the router has a route toward it.
- Host or edge firewall dropping inbound traffic, especially ICMPv6, which IPv6 needs for neighbor discovery and path MTU discovery.
- IPv6 not enabled on the session or on the service itself (a listener bound only to IPv4).
Report what you saw
Write down the result of each step. Provider support teams respond much faster to "prefix X is seen by upstream Y but not by network Z, path below" than to "BGP is broken."
About IPYE
IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space. A /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled for you. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.
Disclosure: I run IPYE
Top comments (0)