The BGP session is the easy step. What decides whether your route reaches anyone is the LOA, the IRR objects, and a ROA whose max length is not quietly authorising somebody else to originate your more-specifics.
To announce your own IP space you need three things that have nothing to do with configuring a router: an autonomous system number, a prefix you are entitled to, and paperwork that lets the rest of the internet believe both. The BGP session is the last step and the easiest one. Everything that makes an announcement actually propagate happens in registries beforehand, and skipping any of it produces the same symptom — the session comes up, the route goes nowhere.
An ASN. Issued by your regional internet registry. In the RIPE region that means being an LIR or sponsored by one, and justifying that you will multihome or otherwise need a distinct routing policy.
A prefix. Either allocated to you by the registry, or assigned to you by someone else who authorises you to announce it. The practical minimum sizes are set by other networks' filters, not by the protocol: /24 for IPv4 and /48 for IPv6 are the longest prefixes that propagate globally. Anything longer is filtered by a large share of the internet and will reach almost nobody.
An upstream willing to accept it. A transit provider, or the network at the facility where you colocate. They need to configure their side, and they will ask for documentation before they do.
If the prefix is not registered directly to you, the upstream needs written authorisation from the holder saying you may announce it, naming the prefix, the origin ASN and a validity period. Providers ask for this because announcing someone else's space without it is what a hijack looks like from the outside. Expect it to be signed by the registered holder, not by you.
Internet routing registries hold the machine-readable version of "this ASN may originate this prefix". In the RIPE database that is a route object for IPv4 and a route6 object for IPv6:
route: 192.0.2.0/24
origin: AS64496
mnt-by: MAINT-EXAMPLE
source: RIPE
Many upstreams and exchanges build their prefix filters directly from IRR data, usually by expanding an AS-SET that lists your ASN. Two consequences:
Ask your upstream which registry they read and which AS-SET they expand. Publishing to the wrong registry is a common and invisible mistake.
A Route Origin Authorisation is a cryptographically signed statement that a given ASN may originate a given prefix, and it is now the check that decides whether a large part of the internet accepts your route at all. Networks running route origin validation drop RPKI-invalid announcements outright — we do, and so does everyone we peer with under our peering policy.
Create it through your registry's portal — for RIPE members, the hosted certificate authority in the RIPE NCC dashboard. A ROA has three fields:
| Field | Value | Note |
|---|---|---|
| Prefix | 192.0.2.0/24 | the space you hold |
| Origin ASN | AS64496 | the AS that will announce it |
| Max length | 24 | see below |
Max length is where people get hurt. Setting it longer than the prefix you actually announce authorises anyone to originate more-specific routes inside your space and have them validate. Set max length equal to the prefix length unless you genuinely announce more specifics, and if you do, set it to the longest one you actually use.
The other trap is ordering. A ROA that covers your prefix with a different origin ASN makes your announcement invalid — worse than having no ROA at all, because unsigned space is merely unknown while wrongly signed space is actively rejected. If you are changing which ASN originates a prefix, create the new ROA before you move the announcement.
Not required to announce, required to be taken seriously. Networks check it before agreeing to peer, and an empty or stale record is the most common reason a peering request is ignored. List your ASN, your facilities and exchanges, your prefix counts and a NOC contact that answers.
With the paperwork in place, the BGP configuration is unremarkable. Agree with your upstream on:
Filter on your own side too. Reject bogons, reject prefixes longer than /24 and /48, and reject your own space arriving back at you. Assume the other side has made a mistake, because eventually someone will.
The session being up tells you nothing about whether the world sees your route.
If the route is visible from your upstream and nowhere else, the answer is almost always a filter that has not been rebuilt yet, or an IRR object in a registry your upstream does not read. If it is visible nowhere, check the ROA first — an invalid is silent by design.
Once it is up, the path your traffic takes stops being your provider's business alone and becomes yours: which upstreams you prefer, which peers you use, and how you balance between them is what having your own ASN buys. The trade-offs are in peering vs transit.
A /24 for IPv4 and a /48 for IPv6, in practice. The protocol permits longer, but so many networks filter longer prefixes that an announcement below those sizes will not reach a usable share of the internet.
Not always. A provider can announce your prefix from their ASN with a letter of authorisation and a matching ROA, which is simpler and adequate when you have a single upstream. You need your own ASN once you want to multihome or set your own routing policy.
The session comes up in minutes. Global propagation usually completes within an hour once filters permit the prefix, but the filters themselves are frequently rebuilt on a daily cycle, so plan for a day between paperwork and traffic.
Networks performing origin validation drop your route as invalid. This is a harder failure than having no ROA, because unsigned space is treated as unknown and still accepted by most networks, while invalid space is rejected on purpose. Verify validity before you rely on the announcement.
Get the ASN and prefix first, then the LOA, IRR objects and ROA, and only then ask for the session — in that order, the turn-up is uneventful. Our own AS25198 requirements for peers, including the IRR and RPKI expectations, are on the peering policy page, and the backbone that would carry your announcement is described on the network page.
A broken AAAA record does not take a site down, it makes it slower for everyone who has IPv6. The prefix you get, the static configuration to prefer, the three things that break it, and how to prove it works.
A stock kernel moves a few gigabits and then flattens. The bandwidth-delay arithmetic behind it, the sysctl ceilings to raise, the NIC queue work that follows, and the nginx settings that stop copying bytes.
Eight 12 TB drives give you 96 TB raw and four sensible ways to arrange them. What each level costs in capacity, what it buys in redundancy, and how long a rebuild really takes.