Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jalmargyyk/ripe-updater/llms.txt

Use this file to discover all available pages before exploring further.

RIPE Updater automates most INETNUM and INET6NUM lifecycle operations, but there are a number of constraints imposed by the RIPE database model, Python’s ipaddress library, and the stateless nature of webhook processing. Understanding these limitations before deploying to production will help you design your NetBox prefix hierarchy and template setup to avoid surprises.
The most common production issue is having both a parent prefix and one of its children flagged with ripe_report=true. This will cause RIPE DB operations to fail with overlap errors. Read the first entry below carefully before enabling ripe_report on any prefix that has sub-prefixes in NetBox.

Parent and child prefix overlap

What happens: If a parent prefix (for example 10.0.0.0/20) and one of its child prefixes (for example 10.0.0.0/24) both have ripe_report=true in NetBox, RIPE Updater will fail when processing one of them. The RIPE database only supports one level of INETNUM or INET6NUM objects below your aggregate. When RIPE Updater tries to create the child object, the RIPE API returns 400 because the parent object already occupies that space — or vice versa.Error you will see: 500 from /update, with Could not create prefix <prefix> in the logs and an overlap-related error from the RIPE REST API.Workaround: Only enable ripe_report=true on one level of your prefix hierarchy. Disable ripe_report on the parent or the child — never both. If you need both represented in RIPE DB, consider restructuring your prefix hierarchy so the ranges do not overlap at the same level below your aggregate.
What happens: If you change a prefix from a smaller block to a larger one — for example, expanding /27 to /26 — RIPE Updater cannot detect that this is an extension of the same allocation. From RIPE Updater’s perspective, the /26 is a brand-new prefix. The original /27 INETNUM object remains in the RIPE database and the new /26 cannot be created because the two ranges overlap.Root cause: NetBox webhooks carry only the new state of the prefix. There is no deterministic way to identify that a prefix was extended rather than replaced, because the previous CIDR is not included in the webhook payload.Workaround:
  1. Set ripe_report=false on the prefix in NetBox and save. RIPE Updater deletes the existing RIPE object.
  2. Change the prefix size in NetBox (e.g. from /27 to /26).
  3. Re-enable ripe_report=true and save. RIPE Updater creates a fresh object for the new prefix.
What happens: The RIPE database allows only one level of INETNUM or INET6NUM objects below your aggregate objects. If your NetBox prefix tree has multiple levels of sub-prefixes all flagged with ripe_report=true, only the top-level children of your aggregates can be created in RIPE DB. Deeper prefixes will result in overlap errors when RIPE Updater attempts to create them.Example: If you have an aggregate 203.0.113.0/24 and prefixes 203.0.113.0/25 and 203.0.113.0/26 both flagged for RIPE reporting, the /26 will fail because it falls inside the /25 INETNUM which is already one level below the aggregate.Workaround: Only flag prefixes at a single depth below each aggregate with ripe_report=true. Use NetBox’s prefix hierarchy for internal organisation, but keep RIPE-reported prefixes to one nesting level below your RIPE aggregate objects.
What happens: When RIPE_DB=TEST, RIPE Updater targets https://rest-test.db.ripe.net/test instead of the live RIPE database. The TEST database does not contain your real maintainer (mnt-by), organisation (org), or person (admin-c, tech-c, abuse-c) objects. Submitting objects with real handles to the TEST database causes 400 errors.How RIPE Updater handles this: When RIPE_DB=TEST is set, RIPE Updater automatically patches these attributes at object generation time using the RIPE_TEST_* variables:
VariableDefaultPatches
RIPE_TEST_MNTTEST-DBM-MNTmnt-by, mnt-ref, mnt-lower, mnt-domains, mnt-routes, mnt-irt
RIPE_TEST_ORGORG-EIPB1-TESTorg
RIPE_TEST_PERSONAA1-TESTadmin-c, tech-c, abuse-c
RIPE_TEST_STATUS_V4ALLOCATED PAstatus on IPv4 objects
RIPE_TEST_STATUS_V6ALLOCATED PAstatus on IPv6 objects
Note: The TEST database is useful for validating template syntax and the overall flow, but the patched attributes mean the resulting objects do not reflect your real RIPE configuration. Always validate with RIPE_DB=RIPE in a staging environment before going to production.
What happens: Prefixes smaller than the configured minimum are silently skipped. RIPE Updater raises ErrorSmallPrefix internally and returns 200 ErrorSmallPrefix, skipping request to NetBox — suppressing webhook retries.The default limits are:
VariableDefaultSkips prefixes with length
SMALLEST_PREFIX_V431greater than /31 (i.e. /32 host routes)
SMALLEST_PREFIX_V6127greater than /127 (i.e. /128 host routes)
Workaround: If you need to manage host routes in RIPE DB, lower the limit:
SMALLEST_PREFIX_V4=32
SMALLEST_PREFIX_V6=128
Be aware that host routes are uncommon in RIPE DB and your RIPE maintainer configuration must support the chosen status value for such objects.
What happens: Prefixes in reserved or non-globally-routable address space are silently skipped. RIPE Updater raises NotRoutedNetwork and returns 200 NotRoutedNetwork, skipping request to NetBox.The following address types are skipped for both IPv4 and IPv6:
  • Loopback127.0.0.0/8, ::1/128
  • Private / RFC191810.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and IPv6 ULA (fc00::/7)
  • Link-local169.254.0.0/16, fe80::/10
  • Multicast224.0.0.0/4, ff00::/8
  • Reserved — any address Python’s ipaddress module marks as reserved
  • Non-global (IPv6 only) — any prefix where is_global returns False
This behaviour is intentional and cannot be disabled via configuration. RIPE Updater is designed to manage publicly registered address space only.Workaround: There is no workaround. If you need internal documentation of RFC1918 space, use NetBox’s built-in prefix documentation features rather than RIPE DB.

Check the GitHub issues page for any newly discovered limitations or bugs that may not yet be reflected in this documentation.

Build docs developers (and LLMs) love