nColo¶

nColo is the Pro-tier BGP-routed-prefix add-on. We allocate you a small public IPv4 prefix from one of our registry-held pools — /32, /31, /30, or /29 — and route it to your CPE through the Torus tunnel. Every IP in that prefix is yours to use: bind it to a host, NAT to a service, run a router behind it, announce it onwards. We don't NAT it. We don't switch it. We route it.

This page is the HOWTO for what you do once the prefix is allocated, with a worked MikroTik RouterOS configuration. If you've never run BGP before, the static path at the bottom of this page is the easier alternative.

What "routed, not switched" actually means¶

A typical home setup is switched: your ISP gives you one public IP, your router NATs the whole household behind it, and inbound connections to your one IP are translated by port back to a specific device. The internet only knows about your single edge address.

nColo is routed. The internet learns — via BGP from our hub — that your entire allocated prefix lives at the other end of your WireGuard tunnel. Every IP in your block is independently reachable. You can:

Put 185.x.y.1 on your MikroTik bridge, 185.x.y.2 on a vintage SGI, 185.x.y.3 on a mailserver, all visible to the world at once.
Run another router behind your CPE and re-announce a sub-allocation onwards.
Use one IP for outbound NAT and reserve the rest as inbound destinations.

There's no port-forwarding table. There's no NAT. There's also no built-in firewall. Anything you bind to one of those addresses is on the internet the moment it answers a SYN. Security is on you.

Two ways to use your prefix¶

The picker offers two routing modes when you allocate. The same prefix is delivered either way; what differs is how your router learns about it.

Static mode (no BGP) — recommended if you've never run BGP¶

The hub installs a static route on our side pointing your prefix at your WireGuard tunnel. On your end you add the prefix to your WireGuard interface's Address field and assign IPs from it to whatever you want.

That's the entire configuration.

BGP mode (default) — full dynamic routing¶

You run a BGP session over WireGuard to our hub. You advertise your prefix to us; we advertise a default route plus other nColo customers' prefixes back to you. Sessions come up and down automatically; if your tunnel flaps, BGP re-converges in seconds without manual intervention.

BGP is the right pick — and the default in the picker — if:

You want failure isolation — when your tunnel goes down, the route disappears from our hub instead of black-holing
You're announcing the prefix onwards to a downstream network
You want east-west reachability to other nColo customers on the same hub (BGP customers on a hub exchange routes through a shared output-filter chain; static-mode allocations and customers on other hubs are not reachable east-west today)
You enjoy this kind of thing

Cross-hub reachability — east/west is real (as of 2026-05-17)

The looking-glass route server (lg.ring.nekotopia.io) now acts as an iBGP route reflector for the nColo fabric. BGP-mode customer prefixes announced on any hub propagate to every other hub via the LG, with RFC 4456 cluster-list loop prevention. So a customer on a Singapore hub can reach a customer on a London hub's nColo /29 directly across the Torus mesh, without hairpinning through the public internet. The path: traffic enters at any hub, BGP lookup picks the hub the destination customer terminates on, the inter-hub bridged mesh forwards across regions, the destination hub delivers via WG.

Static-mode allocations also propagate (we redistribute the hub's static routes into BGP via the ncolo-rs template), so static-mode customers are visible in the looking glass and reachable east/west too. Static-mode customers don't learn peer routes themselves (no BGP session on their end) so to actually USE east/west they'd need to put the broader pool subnets into their WG AllowedIPs.

After a BGP-mode allocation, your nColo card on the dashboard shows a BGP setup — sample router configs panel with tabs for MikroTik / FRR / BIRD. Each tab is the same configuration we walk through below, but with your specific prefix, customer ASN, hub IP, and WG IP pre-filled. Copy with one click.

Static-mode setup (MikroTik)¶

Five minutes, two commands.

Add the prefix to your WireGuard interface. Open Winbox or terminal:
```
/interface wireguard
set [find name=wg-routed] addresses=YOUR_PREFIX,10.254.100.X/32
```
Replace YOUR_PREFIX with what the dashboard allocated (e.g. 185.24.74.8/29) and 10.254.100.X/32 with the overlay address you already had. Keep both, comma-separated.
Assign an IP from the prefix to whatever you want to expose. Example: bind the first usable IP to your bridge so devices behind the MikroTik can be addressed from outside:
```
/ip address
add address=185.24.74.9/29 interface=bridge-local
```
Verify. From the internet, ping 185.24.74.9 should answer. If it doesn't, jump to the troubleshooting section.

That's static mode. You're done.

BGP-mode setup (MikroTik RouterOS v7)¶

This is the full path. When you flip the mode toggle to BGP in the dashboard, your allocation page shows a sample config tailored to your prefix, ASN, and hub IP. The block below is the template — every placeholder in ${...} is filled in automatically when you view it live in your dashboard.

# nColo BGP — MikroTik RouterOS v7
#
# Prefix:   ${prefix}            e.g. 185.24.74.8/29
# Your ASN: ${customerAsn}       a 4-byte private ASN we allocate you
# Hub:      ${hubPeerIp} AS ${hubAsn}
# Your WG:  ${customerWgIp}

# 1. Blackhole route — anchors the prefix in your routing table
#    so BGP has something to announce
/ip/route
add dst-address=${prefix} type=blackhole \
    comment="nColo: BGP announcement for ${prefix}"

# 2. Output filter — only announce your allocated prefix
/routing/filter/rule
add chain=ncolo-out \
    rule="if (dst == ${prefix}) { accept } else { reject }"

# 3. Input filter — accept default route + other nColo customer prefixes
/routing/filter/rule
add chain=ncolo-in \
    rule="if (dst == 0.0.0.0/0 || dst in 185.65.116.0/24 || dst in 185.24.72.0/22 || dst in 193.143.16.0/23) { accept } else { reject }"

# 4. BGP peering to Nekotopia hub
/routing/bgp/connection
add name=ncolo-nekotopia afi=ip as=${customerAsn} \
    remote.address=${hubPeerIp} remote.as=${hubAsn} \
    local.address=${customerWgIp} local.role=ebgp \
    routing-table=main output.filter-chain=ncolo-out \
    input.filter-chain=ncolo-in \
    comment="nColo peering"

What each section does¶

Blackhole route. BGP can only announce something that exists in your routing table. The blackhole gives the prefix a destination on your side that satisfies BGP without sending real traffic anywhere yet. Traffic to those IPs lands on the blackhole until you add real /ip address entries or further routes.
Output filter. Belt-and-braces protection: even if you accidentally type a route into your table, the filter ensures only your allocated prefix is ever advertised to us. The hub also filters inbound — we won't accept anything else — but two layers is good practice.
Input filter. What you accept from us. The default rule accepts:
- 0.0.0.0/0 — default route to the internet (you can drop this if you already have an upstream)
- 185.65.116.0/24 — London nColo pool (peer customers)
- 185.24.72.0/22 — APAC nColo pool
- 193.143.16.0/23 — nSolo pool (lets you reach other Nekotopia members directly)

Adjust to taste. If you only care about the default route and don't want east-west to other customers, narrow this down.

BGP session. afi=ip means IPv4 unicast. role=ebgp because your ASN is private and ours is private — formally external. local.address is critical: it must be your overlay address (the 10.254.100.X one), not a LAN IP, or the session won't establish because the hub doesn't see that source.

What you're allowed to announce¶

The hub's input filter for your BGP session only accepts prefixes you actually hold. As of v1 that means:

Your nColo prefix (e.g. 185.24.74.0/29)
Your Torus overlay IP as a /32 (e.g. 10.254.21.101/32)

Anything else is silently rejected by the hub. You can announce all the routes you want from your CPE — the hub takes the ones it knows are yours and drops the rest. So configuring a more aggressive announcement on your end (e.g. announcing a /24 that contains your /29) is harmless but won't propagate.

The Torus /32 announcement is what makes your overlay IP show up in the looking glass alongside your nColo prefix. It also gives you a BGP-derived east/west path to your overlay IP as a backup to the existing WG-mesh path.

BFD — sub-second failover (optional)¶

By default, BGP detects a dead neighbor via its hold timer — 180 seconds with the defaults we ship. That's fine for steady-state but slow on a flap. Enabling BFD (Bidirectional Forwarding Detection) drops detection time to roughly 1 second by exchanging small UDP probes outside the BGP control plane.

On the BGP setup panel of your nColo card, there's a BFD — sub-second failover toggle. Flip it on, click Apply, and the hub-side connection gains use-bfd=yes. The sample configs refresh to include the matching BFD line for each dialect — paste and you're done.

Per dialect:

MikroTik: use-bfd=yes on the BGP connection (RouterOS handles the BFD session config from /routing/bfd/configuration defaults)
FRR: neighbor <hub-ip> bfd under router bgp
BIRD 2: bfd on; inside the protocol bgp block (plus a protocol bfd { ... } block elsewhere in your config to actually run the BFD daemon)

Both ends must run BFD. If you enable it on our side but not yours, the BGP session stays up (BFD just doesn't run) — but you lose the fast-failover benefit. If you enable it on your side but not ours, your CPE may see negotiation timeouts depending on its strict-mode setting.

Tunnel-flap behaviour: with BFD enabled, when your WireGuard tunnel goes down, your prefix announcement is withdrawn from our hub within ~1 second instead of ~3 minutes. The looking glass reflects the withdrawal almost immediately. When the tunnel comes back, BGP re-establishes within seconds and your prefix is re-announced.

MD5 authentication (optional, recommended)¶

The BGP session between your CPE and the Nekotopia hub runs over your WireGuard tunnel, so the underlying transport is already encrypted and source-authenticated. But if anything ever compromised the tunnel itself (a stolen device, a leaked key), an attacker could potentially impersonate you and inject prefixes via the existing BGP peer assertion. TCP-MD5 (RFC 2385) is the conventional defense: a shared secret signs every BGP packet, and mismatched keys cause an immediate TCP RST.

Nekotopia supports MD5 auth on BGP-mode allocations. On the BGP setup panel of your nColo card, there's an MD5 BGP auth toggle and a password field. Set a key (8–80 characters), click Apply, and the hub-side connection's tcp-md5-key is updated. The sample router configs on the same panel automatically include the matching key line — copy as usual.

When MD5 is enabled, the dialect lines look like this:

MikroTik: tcp-md5-key="<your password>" appended to the BGP connection
FRR: neighbor <hub-ip> password <your password> inside the router bgp block
BIRD 2: password "<your password>"; inside the protocol bgp block

Brief outage. Changing the key resets the BGP TCP session — your prefix announcement is unavailable for a few seconds until both sides reconverge. Plan rotations for a quiet window.

Storage. We keep the shared key on the allocation record so the sample config tab can show it back. Treat it as a secret of the same sensitivity as your WireGuard private key.

To disable: untick the toggle, click Apply. The key is removed on both sides; sample configs drop the auth lines. Don't forget to remove it from your router config too — leaving a stale tcp-md5-key set on your end will block the session from coming back up.

Verifying BGP is up¶

/routing/bgp/session/print

You want to see:

state: established

If you see connect, active, opensent, or openconfirm — the session is negotiating. Wait 30 seconds.

If it stays in idle or repeatedly re-enters connect:

Confirm local.address matches your WireGuard overlay IP exactly.
Confirm the WG tunnel itself is up — /interface wireguard/peers/print should show recent handshakes.
Confirm your firewall on the WG interface isn't blocking TCP/179.

Once established, check what you're learning and announcing:

/routing/bgp/advertisements/print
/routing/route/print where bgp

You should see your prefix in the advertisements output, and a default route (0.0.0.0/0) — plus optionally the other nColo prefixes — in your route table.

Firewall — the part you absolutely must not skip¶

Your prefix is globally reachable from the internet the moment BGP comes up. Anything you bind to those IPs is online with no NAT or hub-side filter to hide behind.

Minimum baseline on the MikroTik:

/ip firewall filter
add chain=input action=drop \
    in-interface=wg-routed \
    dst-address=YOUR_PREFIX \
    comment="nColo: drop unsolicited inbound to the router itself"

add chain=forward action=drop \
    in-interface=wg-routed \
    connection-state=invalid \
    comment="nColo: drop invalid forwarded"

add chain=forward action=accept \
    in-interface=wg-routed \
    connection-state=established,related \
    comment="nColo: accept return traffic"

# Then a permissive rule for whatever specific services you want to expose, e.g.:
add chain=forward action=accept \
    in-interface=wg-routed \
    dst-address=185.24.74.9 dst-port=443 protocol=tcp \
    comment="HTTPS to webserver"

The principle: default-deny inbound, explicitly accept only what you've decided to publish.

Moving between hubs¶

The nColo allocation knows about hub moves. What happens depends on whether you cross a geographic region (EMEA, AMER, APAC) or just move between hubs in the same region.

Same region (e.g. London → Frankfurt)¶

Your prefix follows you. When you change hubs from the dashboard, the system:

Removes the static route (or BGP session, for BGP-mode) from your old hub
Re-installs it on your new hub against your new WireGuard IP — the same prefix, same mode, no re-allocation
If the new hub doesn't own your regional pool directly, it sets up delegated routing back to the origin hub on your behalf — invisible to you

You don't need to release first. Your DNS records, firewall rules, and announcements all keep working.

Cross-region (e.g. Singapore → London)¶

The prefix has to be released. Pools are region-pinned at the upstream announcement layer — Singapore's 185.24.74.0/24 is announced from a Singapore-side router; routing return traffic via London would create asymmetric paths that don't converge cleanly. The system handles this safely:

Old-hub provisioning is torn down
The prefix is returned to the NetBox pool
You get a dashboard message: "nColo prefix released — allocate a new one from your regional pool"
Open the picker on the new hub and allocate a fresh prefix from the new region's pool

Heads up: if you have public DNS pointing at the old prefix, that DNS now points at nothing until you allocate a replacement and update the records.

If re-provision fails¶

If the new hub can't accept the allocation for any reason (rare), the system releases the prefix cleanly rather than leaving you in a half-state. The dashboard shows: "nColo prefix released due to re-provision failure — please re-allocate". Open the picker and allocate again.

Switching modes (static ↔ BGP)¶

You can switch modes in place without releasing the prefix. On your nColo card there's a Routing mode row showing the current mode (BGP or static) and a Switch to … button.

What the switch does

The prefix stays the same. Your WG overlay IP stays the same. Your QoS shaping stays the same. Your DNS doesn't need to be touched.
Static → BGP: the static route on the hub is removed and a BGP session is established to your router. The card refreshes to show a BGP setup — sample router configs panel with your prefix / ASN / hub-peer / WG IP pre-filled. Paste the config into your router and BGP comes up within ~30 seconds.
BGP → Static: the BGP session and per-customer filter chains on the hub are torn down and replaced with a plain static route pointing at your WG IP. The card refreshes to show the simpler static setup instructions. Remove the BGP config from your router after the switch (it'll just sit idle if you forget, but it's tidier to clean up).

Brief outage — single-digit seconds. Inbound traffic to your prefix pauses while the hub deprovisions the old plumbing and installs the new. Existing TCP connections will usually survive on conntrack; UDP heartbeats may blip.

ASN is preserved — if you switch BGP → static and later switch back, you get the same customer ASN you had the first time. No churn.

Rollback — if installing the new plumbing fails on the hub for any reason, we restore the previous mode automatically rather than leaving you with neither. You'll see a switch failure in the dashboard and your card stays in the original mode.

If you genuinely need a different prefix as well as a different mode, release first and re-allocate.

Common questions¶

Q: Can I run a webserver on one IP and SSH on another, in the same prefix? Yes. Each address in the prefix is independent. Bind each service to its specific IP at the OS level (Listen 185.24.74.9:443 in Apache, Address=185.24.74.10 on your sshd config, etc.).

Q: What if my ISP drops UDP/51820? Can BGP still work? BGP runs over the WireGuard tunnel, not over the public internet directly. If your WG tunnel is up, BGP will work, regardless of what your ISP does to UDP otherwise.

Q: Can I use my own ASN instead of the one Nekotopia allocates? Yes. The hub's filter only validates the prefix, not the ASN you wrap it in. Replace ${customerAsn} with your own — public or private.

Q: I'm in Singapore but my prefix is from the London pool. Why? The picker shows you the pool tied to your hub region. The Singapore pool is 185.24.74.0/24; the London pool is 185.65.116.0/24. If you appear to be allocated from the wrong pool, your VPN config's hubId doesn't match where you actually live — message the admin and we'll move you.

Q: How fast does BGP converge if my tunnel flaps? With default timers — hold-time 180s, keepalive 60s — about three minutes to declare the session dead. You can lower hold-time to 30s and keepalive to 10s if you want faster failover, but be aware that aggressive timers also cause more false negatives over flaky links.

Troubleshooting¶

Symptom	Likely cause
`ping <your-IP>` from the internet fails, BGP is `established`	Firewall on your MikroTik dropping inbound — check `/ip firewall filter`
BGP session stuck in `connect`, never `established`	`local.address` doesn't match your real overlay IP, or `wg-routed` is down
BGP session keeps flapping every few minutes	WireGuard handshakes failing — check `/interface wireguard peers print stats`. Usually MTU. Try `mtu=1380` on the wg interface.
BGP is up but you can't reach the internet from inside the prefix	Missing default route — either `0.0.0.0/0` is being filtered out of input, or you didn't accept it. Check `ncolo-in` filter rule.
You see only your own prefix and the default route, no other customers	Working as intended unless you specifically want east-west; we don't push other customers by default if you don't have the broader pool entries in your inbound filter

Torus tiers — how Pro differs from Plus
nLAN — private inter-member networking on top of the same WG tunnel
Jumphost tunnel — for exposing a single port without taking a full prefix
Admin-side: see admin/ncolo.md for the operational view of the pool, prefix availability, and force-release procedure

FRR or BIRD instead of MikroTik?

The BGP setup panel on your nColo card has tabs for MikroTik / FRR / BIRD — same logic, same filters, in the dialect of those daemons. Pick the right tab and click Copy.