Announce Leased IP Space from Your Own ASN: LOA, IRR Route Objects, ROA and BGP Propagation Checks

Leased an IPv4 or IPv6 block from IMIDC and want to announce it via BGP from your own ASN at your own data center or another provider? You will need three things: an LOA (Letter of Authorization) from the address holder, IRR route objects (route / route6), and an RPKI ROA. This guide walks through the whole process: what an LOA is, what details to provide, how IRR and ROA fit together, how upstreams filter, and how to confirm propagation with bgp.tools, bgp.he.net and RIPEstat. It is meant for operators who already have an ASN and a BGP session with an upstream.

Step 1: What an LOA Does for BGP Announcements

An LOA is a signed letter from the address holder stating that ASxxx may announce a given prefix. Most transit providers and IXs check before accepting customer prefixes: who owns this space and are you allowed to announce it? An LOA alone is no longer enough, as most upstreams also check IRR and RPKI automatically, so the LOA, IRR route object and ROA must all agree.

Step 2: Details to Provide When Requesting an LOA from IMIDC

Request the LOA through a ticket with the following information. The more complete it is, the faster it is processed:

Prefix(es):        203.0.113.0/24   2001:db8:1000::/48
Origin ASN:        AS64500
Company / holder:  Example Networks Ltd
Upstream(s):       AS64510 (Transit Provider A), AS64520 (IX route server)
Announce from:     2026-10-10
IRR source:        RIPE / RADB
Technical contact: [email protected]

• Prefix: the global table usually accepts IPv4 /24 and IPv6 /48 at most specific; longer prefixes are likely filtered.
• Origin ASN: the ASN you will announce from, and the legal holder of that ASN.
• Upstream: name and ASN of your transit provider(s); some require their name on the LOA.
• Start date: when you plan to announce, so IRR and ROA updates can be scheduled.

Step 3: Create IRR Route Objects (RIPE DB / RADB)

The IRR (Internet Routing Registry) is the set of routing databases that many upstreams use to build prefix filters automatically. For RIPE-region space, route objects live in the RIPE database and need authorization from the address holder, so IMIDC usually creates or authorizes them; non-RIPE space commonly uses RADB. See the guide "Create IRR route objects" for syntax. Verify with whois:

# install whois: Debian/Ubuntu
apt install -y whois
# CentOS/Rocky/AlmaLinux
dnf install -y whois

# route object in the RIPE database
whois -h whois.ripe.net -T route 203.0.113.0/24
whois -h whois.ripe.net -T route6 2001:db8:1000::/48
# route object mirrored / registered in RADB
whois -h whois.radb.net 203.0.113.0/24

Make sure the origin field shows your ASN.

Step 4: Make Sure a ROA Exists to Avoid RPKI Invalid

More and more networks drop RPKI-invalid routes. If a ROA already exists for the block but authorizes a different ASN, your announcement is invalid. Ask in your ticket for a ROA for your ASN, with a maxLength that covers the length you announce. Check the status via RIPEstat:

# RPKI status of origin AS64500 for the prefix (RIPEstat API)
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=203.0.113.0/24" | python3 -m json.tool | grep -E '"status"|"validating_roas"' -A2

valid is what you want; unknown means no ROA and most networks still accept it; invalid must be fixed before announcing.

Step 5: Get Upstream Filters Updated and Originate the Prefix

Upstreams typically generate prefix lists from IRR by your ASN or as-set. Some refresh daily, others need a ticket with the LOA attached. Once confirmed, originate the prefix on your router. BIRD 2 example:

# BIRD 2 example (see the "BGP session" guide for the full config)
protocol static announce_v4 {
    ipv4;
    route 203.0.113.0/24 blackhole;
}

filter export_upstream {
    if net = 203.0.113.0/24 then accept;
    reject;
}

# reload and check
birdc configure
birdc show route export upstream_v4

Step 6: Check Propagation with bgp.tools, bgp.he.net and RIPEstat

Once announced, a prefix usually appears in the global table within minutes. Search it on bgp.tools or bgp.he.net to see the origin ASN, upstream paths and RPKI status; RIPEstat (stat.ripe.net) Routing Status shows how many RIS collectors see it. From the command line:

# who sees the prefix and with which origin (RIPEstat)
curl -s "https://stat.ripe.net/data/routing-status/data.json?resource=203.0.113.0/24" | python3 -m json.tool | head -40
# how many RIS peers see it
curl -s "https://stat.ripe.net/data/visibility/data.json?resource=203.0.113.0/24" | python3 -m json.tool | grep -E '"ris_peers_seeing"|"total_ris_peers"'

# from your router: is the session up and the route exported?
birdc show protocols
# test reachability of an address in the prefix from outside
mtr -rwc 20 203.0.113.1

Typical timeline: once complete details are submitted, LOA and IRR/ROA preparation usually takes a few business days, depending on completeness and review; upstream filter updates take from a few hours to a few days depending on their automation; propagation itself takes minutes; some geolocation databases update more slowly (see the "Geofeed" guide).

FAQ

My prefix does not show up on bgp.tools

Check that the BGP session is Established, the router actually exports the prefix, the upstream has updated its filters (look it up on their looking glass), and RPKI is not invalid.

Can I announce smaller pieces than a /24?

IPv4 prefixes longer than /24 are widely filtered on the internet, so no. Subnet the /24 internally as you like and keep announcing the full /24.

Do I need a new LOA when changing upstream or ASN?

Changing ASN requires a new LOA plus updated IRR route objects and ROA. Changing only the upstream usually just needs the new upstream to update its filters, though some ask for a fresh LOA.

Still stuck? Open a ticket with IMIDC 24/7 technical support: https://www.imidc.com/submitticket.php