01
Registry
Owns ASNs, prefixes, anycast addresses, zones, certificates and peering agreements.
REQUESTED STATE// NETWORK INFRASTRUCTURE
HubN
A private network project for experimenting with BGP, DNS, certificates, RPKI and the software around them.
Core ideaParticipant-operated private network
Control planeRegistry-driven
TrustCA, DNSSEC and RPKI
ImplementationRust, Go and automation
// OBSERVED ROUTING
A network I can still follow end to end
HubN is a private network where participants run autonomous systems, receive address and naming resources and establish real routing relationships. It uses many of the same ideas as a public network, but at a size where I can still follow what every part is doing.
It began with allocation, configuration and documentation projects. It has since grown services for registry state, routing visibility, certificate-backed identity, DNS, route-origin authorization, provisioning and deployment.
LOOKING GLASS / TOPOLOGY24 AS TEST LAB
// SERVICE GRAPH
Registry and network services
HubN is not one daemon. It is a collection of systems which have to agree without pretending they all own the same state.
02
Portal
Turns ownership, policy and limits into a usable workflow instead of exposing the Registry API directly.
PARTICIPANT CONTROL03
DNS
Coordinators and authoritative roots publish the private hierarchy, DNSSEC chain and signed reverse delegations.
NAMING PLANE04
CA + RKV
Issues service and identity certificates while long-lived signing keys stay away from ordinary workloads.
MACHINE IDENTITY05
RPKI
Turns Registry routing intent into signed ROAs and publishes coherent object generations over RRDP.
ORIGIN AUTHORITY06
WHOIS + IRR
Publishes registration data and feeds the prefix filters used by generated BGP configurations.
POLICY INPUT07
Looking Glass
Collects routes, session state and topology without pretending configured must mean established.
OBSERVED STATE08
Automation
Handles certificate activation, deployments and the repetitive gaps between otherwise separate services.
RECONCILIATION// PARTICIPANT PATH
From resource request to live route
The portal carries a participant from identity and allocations to negotiated transport, rendered configuration and independent observation.
- 01
Claim resources
Create a handle, request an ASN and address space, then publish naming and certificate intent under explicit ownership limits.
- 02
Negotiate peering
Two ASNs agree on bilateral peering or transit and choose direct transport, WireGuard or IPsec without replacing working links unnecessarily.
- 03
Render policy
The portal generates guides for BIRD2, FRR, VyOS or Pathvector using the agreed transport, IRR data and route-origin policy.
- 04
Observe reality
An isolated lab drives the real portal, deploys both sides and checks tunnels, BGP, filters, RPKI transitions and collector visibility.
// RECONCILIATION MODEL
State synchronization and reconciliation
The Registry is authoritative for allocations and requested state. Operational truth stays with the system which actually owns it. Updates are recorded through a transactional outbox and delivered at least once; consumers tolerate duplicates, while periodic full passes repair anything missed during a longer outage.
Keeping these states separate is more honest than one green badge. A request can be accepted while transport is pending. A tunnel can be up while BGP is down. BGP can be established before the collector has seen it.
REQUESTED STATEOBSERVED STATE
Peering acceptedTransport pending
Transport configuredTunnel established
BGP requestedSession established
Prefix authorizedCollector visibility
Certificates, DNSSEC and RPKI
X.509
Certificates
Who is this machine?Service identity follows a CA and remote signing path designed to keep long-lived keys away from ordinary application workloads.
DNSSEC
Naming
Is this answer authentic?The private root and reverse hierarchy publish signed generations and verify complete candidate zones before replacing live data.
RPKI
Routing
Who may originate this prefix?Signed route-origin objects move as coherent generations so manifests, CRLs, snapshots and deltas cannot describe different worlds.
PUBLICATION BOUNDARY
This page documents architecture and lessons. It intentionally does not publish source code, an operational map, credentials, private endpoints or a live inventory. The implementation and operational material remain private.
HubN is where most of my networking, systems programming and automation experiments eventually meet. It is never really finished; there is always another failure to test or manual step which has become annoying enough to automate.