Skip to main content

nColo Regional Provisioning

nColo provides Pro-tier users with routed public IPv4 prefixes. Unlike nSolo (which uses 1:1 NAT), nColo prefixes are pure Layer 3 routed — traffic flows directly to your router over WireGuard with no NAT translation.

This page describes how nColo prefixes are provisioned across Nekotopia's regional hub infrastructure.

Geographic Regions

nColo prefix pools are organised into three geographic regions. Each region has its own IPv4 pool, and users are automatically assigned to the pool closest to their hub.

Region Hubs Prefix PoolOrigin Hub Status
AMER Ohio, Oregon, São Paulo 185.24.72.0/24 Ohio (us-east-2)Active
EMEA London, Frankfurt, Bahrain 185.65.116.0/24 London (eu-west-2)Active
APAC Singapore, Mumbai, Singapore, Tokyo, Sydney TBD185.24.74.0/24 PlannedSingapore (ap-southeast-1)Active

All three prefix pools are BYOIP-provisioned in their respective AWS regions, advertised under AS213811 via BYOASN.

Hub-to-Region Mapping

yet
AWS Region Hub Geo Region nColo Pool Role
us-east-2 Ohio AMER 185.24.72.0/24 Origin — owns the prefix pool
us-west-2 Oregon AMER 185.24.72.0/24 Delegated — routes via Ohio
sa-east-1 São Paulo AMER 185.24.72.0/24 Delegated — routes via Ohio
eu-west-2 London EMEA 185.65.116.0/24 Origin — owns the prefix pool
eu-central-1 Frankfurt EMEA 185.65.116.0/24 Delegated — routes via London
me-south-1 Bahrain EMEA 185.65.116.0/24 Delegated — routes via London
ap-southeast-1 Singapore APAC —185.24.74.0/24 NoOrigin — owns the prefix pool
ap-south-1MumbaiAPAC185.24.74.0/24Delegated — routes via Singapore
ap-northeast-1TokyoAPAC185.24.74.0/24Delegated — routes via Singapore
ap-southeast-2SydneyAPAC185.24.74.0/24Delegated — routes via Singapore

How ProvisioningIt Works

Origin Hubs

WhenOrigin ahubs Pro(Ohio, userLondon, requestsSingapore) anhave the nColo prefix,infrastructure directly provisioned:

  • BYOIP prefix advertised from the systemlocal determinesAWS which pool to allocate from based on the user's current hub:

    Direct Provisioning (Origin Hub)

    If the user is on an origin hub (Ohio or London), provisioning is straightforward:

    1. A prefix is allocated from NetBox (the IPAM system) out of the hub's poolregion
    2. AMikroTik CHR with BGP peering session is created on the hub's MikroTik CHR
    3. A per-customer routing filter ensures the user can only advertise their allocated prefix
    4. The prefix is added to the user's WireGuard peer allowed-address
    5. QoS mangle rules are applied for traffic shaping
    Customer router (private ASN, e.g. 4200000001)
    ↓ BGPcustomers over WireGuard
    • tunnel Hub CHR (AS64512, per-
  • Per-customer prefix filter)filter ↓(only learnedaccept routethe viaallocated BGPprefix)
    • VPC →
  • IGW (gateway route table + BYOIP) ↓ Internet

    Delegated Provisioning (Non-Origin Hub)

    If the user is on a delegated hub (e.g. Oregon, Frankfurt),routing the prefix still comes fromto the originhub hub'sENI

    • pool,
but

Delegated Hubs

Delegated hubs (Oregon, Frankfurt, etc.) do not have their own prefix pool. nColo traffic is policy-routed across the mesh:

  1. Prefix is allocated from the origin hub's pool in NetBox
  2. BGP peering is created on the local (delegated) hub
  3. Policy routing on the local hub marks nColo traffic and routes it via theWireGuard mesh back to the origin hub for BYOIP egress. The customer still peers BGP with their local hub — the delegation is transparent.

    Provisioning Flow

    1. User selects prefix size (/32, /31, /30, /29) in the dashboard
    2. ASystem returnresolves route on the originuser's hub sends inbound traffic back through the mesh to the localcorrect regional origin hub
  4. Prefix 
    Customerallocated routerfrom ↓NetBox IPAM under the regional pool
  5. Private ASN assigned from the region's ASN range
  6. MikroTik provisioned: WG allowed-address, BGP overconnection, WireGuardprefix Localfilter, hubQoS
    7. (Oregon)
  7. User —receives BGP peering +details policyand routesample ↓router mangleconfigs
    8. mark → bridged mesh Origin hub (Ohio) — BYOIP egress ↓ Internet

    The user experience is identical — the prefix works the same way regardless of whether the hub is an origin or delegate.

Hub Change Behaviour

WhenYouChangeHubs

Moving between hubs affects your nColo allocation differently depending on whether you're staying within the same geographic region:

(e.g.

Your prefix is

(e.g.

Your

region'spoolvia the dashboard

This is by design — a 185.24.72.0/24 (AMER) prefix cannot be routed from London (EMEA) infrastructure. You'll receive a prefix from 185.65.116.0/24 instead.

nSolo on Hub Change

Move TypeExampleWhat Happens
Same Regionregion Ohio → Oregon)Oregon Prefix preserved. The system automatically:

  1. Deprovisions BGP peeringDeprovisioned from the old hub
    2. hub,
  2. Re-provisions BGP peeringre-provisioned on the new hub
  3. Sets up delegation routing if the new hub doesn't own the pool
  4. Updates the allocation record with your new WireGuard IP

This is seamless — you keep the same prefix, same ASN, same configuration. Your router just needs to re-establish the BGP session after reconnecting to the new hub.
Cross Regionregion Ohio → London)London Prefix prefix is released. Because each geographic region has its own prefix pool:

  1. The old prefix is deprovisioned from the old hub
  2. The NetBox allocation is freedreleased (theAMER prefix→ returnsEMEA). toUser the pool)
  3. You can allocateallocates a new prefix from yourEMEA newpool.

nSolo (dedicated NAT IP) is always released on any hub change, regardlessas of region. The EIPit is tied to the old hub's NAT infrastructure and cannot follow you. You can allocate a new dedicated IP from the dashboard after switching hubs.infrastructure.

Available Prefix SizesPricing

Cost
Size IPs MonthlyPrice Per-IP
/32 1 $55/mo$5.00
/31 2 $99/mo$4.50
/30 4 $1212/mo$3.00
/29 8 $2020/mo$2.50

Pricing is the same across all regionsregions. andSelf-service, all hubs. The tier gates accesshonour-based (Pro required), but the price is the same everywhere.model as bandwidth selection).

BGP Configuration

Each nColo usercustomer receives:

  • A private 4-byte ASN (e.g. 4200000001 for AMER,EMEA, 4200100001 for Ohio-specific)AMER, 4200200001 for APAC)
  • TheHub hub's peer IPASN: (AS64512
  • Hub peer IP: the WireGuard gateway address)
    • of
  • Thethe hub'slocal ASN (AS64512)hub

SampleThe MikroTikdashboard RouterOSprovides configuration:

/routing/bgp/connection add name=nekotopia-ncolo \
  remote.address=<HUB_PEER_IP> remote.as=64512 \
  local.address=<YOUR_WG_IP> local.role=ebgp \
  hold-time=90s keepalive-time=30s

/routing/filter/rule add chain=ncolo-out \
  rule="if (dst == <YOUR_PREFIX>) { accept } else { reject }"

Full BGP details (including sampleready-to-paste configs for FRRMikroTik RouterOS, FRRouting, and BIRD)BIRD.

BYOIP Infrastructure

RegionPrefixAWS RegionIPAM PoolEC2 PoolASN
EMEA185.65.116.0/24eu-west-2ipam-pool-05345e5d2df4d7166ipv4pool-ec2-0c0b4b0a21448be79AS213811
AMER185.24.72.0/24us-east-2ipam-pool-06905f53940df17e4ipv4pool-ec2-01d3da50d8626f435AS213811
APAC185.24.74.0/24ap-southeast-1ipam-pool-08c5c1d00b22bd4f1ipv4pool-ec2-044ee5c5992f681e0AS213811

All prefixes are availableregistered inwith theRIPE dashboardNCC afterwith allocation.appropriate geolocation (geoloc:) and geofeed entries. The geofeed CSV is served at https://www.nekotopia.io/geofeed.csv.

Reserve Capacity

The parent RIPE allocation 185.24.72.0/22 provides four /24 blocks:

PrefixAssignmentStatus
185.24.72.0/24AMER (Ohio)Active
185.24.73.0/24AMER expansionReserved
185.24.74.0/24APAC (Singapore)Active
185.24.75.0/24APAC expansionReserved
Back to top