Is your own range worth the paperwork?
It is when the addresses matter more than the machine behind them. Addresses a host assigns you stay with that host when you leave. Your own range goes with you.
| Your situation | What to do |
|---|---|
| Customers allow-list your addresses in their firewalls | Own range: you can change host without asking each of them |
| You want one address to survive losing a city | Own range, plus the second-site plan below, if we can confirm a session in both cities |
| You just need several addresses on one server | Skip this. Up to 8 IPv4 are on the custom server configurator |
What to have in hand before you ask
- A range big enough to route. RFC 7454 records that IPv4 routes longer than /24 and IPv6 routes longer than /48 are generally neither announced nor accepted, and says those values may change.
- An AS number. Check your registry's rule early. ARIN's policy says any organisation may be issued one on request. RIPE's says a network must be multihomed (generally, connected to more than one other network) to qualify.
- A ROA. A Route Origin Authorisation is a signed record of which AS may originate a prefix. You create it in your registry's RPKI dashboard.
- A route object. The older public record of the same idea, kept in an Internet Routing Registry. RFC 7454 describes networks building prefix filters from these, so a missing object can leave you filtered with no error on your side.
- Written permission, if the range isn't yours. With leased space the holder has to publish the ROA and route object naming your AS. Ask us whether we also need a signed letter of authorisation from the holder.
Publish the records in the right order
Records first, announcement last. Under RFC 6811 a route no ROA covers is NotFound, one matching a ROA is Valid, and one covered by a ROA but matching none is Invalid. That last state is the trap: if your range already has a ROA for your old network, announcing from a new AS is Invalid until the new ROA exists.
- Add the new ROA beside any old one. One match is enough for Valid, so both can stand while traffic moves.
- Set the maximum length to the exact prefix. RFC 9319 advises avoiding maxLength except in specific cases, because a wide setting lets someone forge your origin on a smaller slice of your range.
- Create the route object, with your AS as origin.
- Run this check from any Linux machine. It stops unless both records are visible.
P=203.0.113.0/24 # your prefix
A=64500 # your AS number, digits only
S=$(curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=$A&prefix=$P" | python3 -c 'import sys,json; print(json.load(sys.stdin)["data"]["status"])')
if [ "$S" = valid ] && whois -h whois.radb.net "$P" | awk -v p="$P" -v o="AS$A" -v c=2 '/^route6?:/{r=$c} /^origin:/{g=toupper($c)} /^source:/{if(r==p && g==o && $c!="RPKI")f=1} END{exit !f}'; then
echo "ROA valid and route object found: ready to ask for the session"
else
echo "STOP: RPKI status is '$S' or the route object is missing"
fi203.0.113.0/24 and AS 64500 are reserved for documentation. The lookup needs the whois package. The check ignores the RPKI-generated entries RADb shows and needs an exact match on your prefix. New records can take a while to appear, so run it again later if you get STOP straight after creating them.
What we do, and what to settle with us first
Our part is short: send us your prefix and AS number, and we set up a BGP session to announce it. That is all our public pages promise, so settle the rest in chat before you order: which cities can carry a session for you, whether we want a letter of authorisation, and whether the session runs on your server or on our side. If you plan on two cities, ask about the second one by name.
Pick the machine for the day a routing change goes wrong. You can lose your network path to your own server, and then only a console gets you back. Rack servers and blades include one that works with the system down, while most small Moonshot cartridges offer power control only. The dedicated range lists the lines, and the five cities shows where each is built.
A safe minimum if the session runs on your server
If we agree that your server speaks BGP itself, FRRouting is a free option. This sketch sends one prefix and accepts nothing back. Everything in it is an example, and the neighbour details come from us.
! /etc/frr/frr.conf (also set bgpd=yes in /etc/frr/daemons)
ip prefix-list MINE seq 5 permit 203.0.113.0/24
route-map OUT permit 10
match ip address prefix-list MINE
route-map IN deny 10
router bgp 64500
neighbor 192.0.2.1 remote-as 64496
address-family ipv4 unicast
network 203.0.113.0/24
neighbor 192.0.2.1 route-map IN in
neighbor 192.0.2.1 route-map OUT out
exit-address-familyTwo FRR behaviours catch people out. By default an eBGP session with no outbound filter announces nothing, so the route-maps are required. And since version 7.4 the network line only works if the route exists on the machine, so put an address from the range on the loopback (ip addr add 203.0.113.1/24 dev lo) and make that permanent. Then vtysh -c "show ip bgp neighbors 192.0.2.1 advertised-routes" must list your prefix and nothing else.
Your services must listen on the new addresses too, and outgoing connections keep using the address we assigned until you change the source address yourself.
Read the route from both sides
Use two views, because each can mislead alone. Our public looking glass at primcast.com/lg runs BGP lookups, ping, traceroute and mtr from New York and Bucharest, and shows what our edge sees from its carriers: Cogent and Pilot Fiber in New York, Cogent in Bucharest. Try show ip bgp on a well-known prefix before you order, to learn what a normal answer looks like. For the outside view, the RIPEstat looking glass shows paths gathered by RIPE's route collectors. Ask us whether your prefix will show in our looking glass, and rely on the outside view if it won't.
| What you see | What it usually means | Next step |
|---|---|---|
| Nothing at our edge | Session down, or the prefix isn't being sent | Check the session and any outbound filter, or ask us |
| At our edge, missing outside | Filtered further upstream | Recheck the route object and ROA, then tell us |
| The path ends in the wrong AS | Your old network still announces it | Withdraw it there first |
| Route fine, pings unanswered | Address not on the server, or your firewall | Look at the server |
Failing over to a second city
This applies only once we've confirmed a session in both cities. The health check and rehearsal below also assume the sessions run on your own servers. If they run on our side, ask us how a failover would be triggered. The usual design announces the same prefix from both and makes the standby less attractive by repeating your AS in its path, called prepending. If the main site goes dark, its session times out, the route is withdrawn and traffic shifts to the longer path. Three things can spoil that:
- BGP doesn't know your application. If the server stays up and the database dies, the session stays open and traffic keeps arriving. Tie the announcement to a health check that shuts the session down.
- Prepending is a hint. Every network chooses its own path, so some traffic may reach the standby on a normal day. It has to answer properly.
- Addresses move, data doesn't. The standby needs its own fresh copy of whatever the service holds.
Rehearse it in a quiet window. In vtysh, run configure terminal, then router bgp 64500, then neighbor 192.0.2.1 shutdown on the main site. Watch the route change in the RIPEstat looking glass and ping from an outside network. Afterwards, no neighbor 192.0.2.1 shutdown at the same prompt brings it back. Our looking glass runs from New York and Bucharest only, so if your confirmed cities differ, rely on the outside view alone.
Questions people ask
- What are the default BGP timers?
- RFC 4271 suggests a hold time of 90 seconds and a keepalive of a third of that, and the two sides use the lower hold time offered. Operators often choose other values. In FRR they're set per neighbour with
neighbor PEER timers, but agree any change with us first. - Does your clean-address check cover my range?
- Read it as covering the addresses we hand you. A range you bring arrives with its own history, so look it up against the public blocklists yourself before you announce it, especially if it's leased.
- Can I use leased addresses?
- Often, if the holder publishes the ROA and route object naming your AS, but ask us before you sign a lease. Have the lease say who maintains those records, because a withdrawn ROA can take your service down with it.