IRR Route Objects: Create and Verify IPv4 Records
An IRR route object records an IPv4 prefix and its originating ASN in an Internet Routing Registry. Providers can use these records to generate route filters. Create the object under the holder’s authority, in a source your upstream accepts, and verify the resulting filter before relying on it.
Before creating an object
Have the exact prefix, intended origin ASN, holder approval, registry access and the upstream’s filtering requirements. For leased space, ask the holder to create the object or authorize the appropriate administrator. A lease does not automatically grant database credentials.
The LOA checklist covers documentary permission. A route object is a separate routing-policy record; it does not announce the prefix or replace a RPKI ROA.
Identify the registry your upstream uses
Ask for the provider’s accepted IRR sources and query server. If it uses an AS set, a named group of ASNs or nested sets, confirm which set it expands and whether your origin is included. Creating an aut-num policy object alone is not the same as putting a prefix in a generated filter.
RADB can return its own objects and mirrored records from other databases. Read source: instead of assuming that every answer from its query server is maintained in RADB.
Confirm authority over the prefix and maintainer
The RIPE routing-object authorization guide explains how existing route or address objects control creation. A mnt-routes delegation can authorize routing changes without handing over general account access. Follow the applicable hierarchy and also authenticate the new object’s maintainer.
RIPE does not require authentication against the origin ASN for route-object creation. It does restrict new objects to RIPE-managed address space. Do not apply the RIPE workflow to another region merely because the origin ASN is registered there.
ARIN resources use the eligible organization and contacts in ARIN Online. RADB uses its own maintainer-controlled object-management workflow. Choose the source deliberately; do not publish conflicting copies to evade a failed authorization check.
Publish the prefix-origin record
This illustrative RIPE-style object uses a documentation prefix and ASN. It is not a submission for real address space:
route: 192.0.2.0/24
origin: AS64496
mnt-by: EXAMPLE-MNT
source: RIPEEXAMPLE-MNT must be replaced with a real authorized maintainer, along with the prefix and origin. Supply any additional fields required by the selected registry’s current form. Submit through its authenticated portal or supported API and retain the result.
Two transit providers carrying this same origin do not require two different origins in the object. During an agreed origin migration, separate records can temporarily represent the old and new origins. Plan the corresponding RPKI changes before switching BGP.
Check authoritative and mirrored data
For a RIPE-source object, a read-only exact-match query is:
whois -h whois.ripe.net -- '-r -T route -x 192.0.2.0/24'The example prefix is reserved and need not return a record. Substitute your real prefix and compare route, origin, mnt-by and source with the approved change. Query the upstream’s chosen mirror separately; source publication and mirror refresh are different events.
If the upstream uses bgpq4, reproduce its source selection and AS-set expansion. For example:
bgpq4 -4 -h whois.radb.net -S RIPE -l CUSTOMER_V4 AS64496The bgpq4 project documentation defines these options. This example requests RIPE-source data via a mirror and generates a candidate prefix list. Replace the server, sources and ASN or set with the provider’s inputs. Inspect the output; generating a list locally does not install it on the upstream router.
Confirm the upstream filter and retire stale records
Ask the provider to confirm that the intended prefix and length are in its active customer filter. Follow the announcement runbook to verify accepted and propagated routes.
After an origin change, retain the old record only for the planned transition and rollback period. Coordinate deletion with its maintainer and confirm stale mirror entries have cleared. Changing the primary-key origin generally means creating a new object and retiring the old one, rather than editing an unrelated record.
When publication does not produce acceptance
| Finding | Check before changing anything else |
|---|---|
| Authentication fails | Identify the controlling parent object and applicable maintainer. Have the holder or delegated administrator satisfy the registry’s authorization checks |
| Authoritative record exists, mirror does not show it | Confirm the queried source and mirror update state; do not create a conflicting copy merely to make one query return a result |
| Record is correct, generated AS-set filter omits the prefix | Expand the exact set and accepted sources used by the upstream; check membership and additional filtering |
| Generated list contains the prefix, upstream rejects it | Ask whether that list is installed, and check RPKI, permitted lengths and the actual origin separately |
| IRR names the new origin, ROA still permits only the old origin | Stage matching RPKI authorization before moving BGP; updating the IRR alone does not make the new origin valid |
Record expected output as a checkable statement: “the approved source contains this exact prefix-origin pair” and “the provider’s active filter permits this prefix and length.” A successful object submission or a locally generated prefix list satisfies only part of that chain.
For newly acquired space, the post-transfer checklist connects registry and routing changes. When sourcing space through IPv4 services, establish who maintains routing records and who coordinates provider filters before activation.