DEV Community

IPYE
IPYE

Posted on

My Free /48 Is Filtered: A Triage Checklist That Starts With ROA and IRR

#networking #ipv6 #linux #devops

Disclosure up front: I run IPYE, a company that leases IP space. Most of this article is practical how-to; IPYE appears where a free /48, LOA, or ROA helps you try the work, with a short call to action at the end.

You announced your prefix, the BGP session is up, and parts of the Internet still cannot reach you. The cause is nearly always one of a short list, and the fastest way through is to check them in order, collecting evidence as you go. This checklist is written for a free IPv6 /48 from IPYE, with 2001:db8:100::/48, origin AS64496 and upstream AS64497.

Step 1: confirm what you send

Start on your own router:

vtysh -c 'show bgp ipv6 unicast neighbors 2001:db8:0:1::1 advertised-routes'
birdc show route export upstream1
Enter fullscreen mode Exit fullscreen mode

Use whichever matches your daemon. You should see exactly 2001:db8:100::/48. Common mistakes found here:

  • nothing is advertised, because the aggregate is missing from the routing table (add a blackhole route for it)
  • a /56 or /64 is advertised instead of the /48
  • a typo in the prefix

If the advertisement is wrong, fix it and stop here.

Step 2: check RPKI 

routinator validate --asn 64496 --prefix 2001:db8:100::/48
Enter fullscreen mode Exit fullscreen mode

Or use the RIPEstat RPKI validation widget. Results:

  • Valid: move on.
  • Invalid, wrong origin: the ROA authorises a different ASN. For the free /48 on IPYE's ARIN or APNIC accounts, the ROA follows the ASN set in the dashboard; check that it matches the ASN on your session.
  • Invalid, length: you announce something longer than the ROA's maxLength. Announce the /48 instead.
  • Not found: no ROA covers the prefix. Fewer networks drop not-found routes than invalid ones, but some do.

Networks that perform route origin validation drop invalid routes, which shows up as partial reachability: some networks reach you, others do not.

Step 3: check the IRR

Many upstreams build customer filters from IRR data:

whois -h whois.radb.net -- '-i origin AS64496'
bgpq4 -6 AS64496
Enter fullscreen mode Exit fullscreen mode

If the route6 object is missing or names another origin, the upstream filter may drop your route before it ever leaves their network. The IRRexplorer tool from NLNOG shows IRR and RPKI status together and is a fast cross-check.

Step 4: see what the world sees

Look the prefix up in RIPEstat's routing status and in route collector data from RIPE RIS or RouteViews. Questions to answer:

  • How many collector peers see the route? Very few suggests the upstream is not exporting it widely.
  • Is the AS path what you expect, ending 64497 64496?
  • Does any path show a different origin? That could be a hijack or a stale announcement.

Public looking glasses run by transit networks show whether specific large networks carry your route. If your direct upstream does not show it in their looking glass, the problem is at the first hop.

Step 5: check the data plane

Control plane fine but traffic failing points to forwarding or filtering:

mtr -6 -rwc 20 2001:db8:100::1
tcpdump -ni eth0 icmp6 or host 2001:db8:100::1
Enter fullscreen mode Exit fullscreen mode

Run mtr from an outside host. If traffic reaches your router and replies never arrive, look at your firewall, reverse-path filtering, and the route back: a host with two uplinks may answer through the wrong one, where the source address is filtered.

Step 6: escalate with an evidence packet

When the evidence points to the upstream or a remote network, send one complete message:

Prefix: 2001:db8:100::/48   Origin: AS64496
Advertised to you: yes (output attached)
RPKI: valid (validator output attached)
IRR: route6 present, origin AS64496
Collectors: seen by N peers, missing via your network
Test: mtr from <source> attached
LOA: attached
Enter fullscreen mode Exit fullscreen mode

Fill in the real values from your checks. Attach the LOA from the IPYE portal; network teams check it before changing filters.

Common causes worth rechecking

  1. Upstream export filter not yet updated for a new prefix.
  2. Announcing a longer prefix than the ROA allows.
  3. ASN changed but the announcement moved before validators picked up the new ROA.
  4. Firewall dropping ICMPv6 or inbound traffic.
  5. A stale route6 object with an old origin.

Do this next

Save this list in your runbook and run steps 1 to 3 after every change. If you are setting up from scratch, claim a free /48 from IPYE and run the checklist before telling anyone the prefix is live. Questions: ipye@turnel.com.

About IPYE

IPYE (https://ipye.com) leases IPv4, IPv6 and ASN space with instant setup. Your first IPv6 /48 is free for the first year, a real allocation you can announce on your own ASN, with a LOA from the portal and the ROA created automatically. ASN and region changes apply automatically. IPv4 /24 to /22 leases include LOA, ROA and per-/24 rDNS; WHOIS is editable on IPv6 /44 and larger. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, Frankfurt. Claim your free /48: https://my.ipye.com/products/ipv6-rental. Questions: ipye@turnel.com.

Disclosure: I run IPYE

Top comments (0)