Your first BGP session: what to prepare before announcing your own prefix

Announcing your own prefix for the first time is mostly preparation. The BGP configuration itself is short; the work is making sure the registry, the routing databases, your upstream and your filters all agree before you turn it on. This checklist covers what to have in place, roughly in the order you’ll need it.

Is the prefix ready to be announced?

Start with the address space itself.

• Size. Prefixes longer than /24 for IPv4 or /48 for IPv6 are widely filtered, so plan to announce at least that size.
• Authorisation. If you hold the space, you’re set. If it’s leased, you need the holder’s written authorisation, usually a letter of authorisation (LOA) naming your ASN and the prefix. Many upstreams ask to see it.
• History. Check whether anyone else still announces the prefix, such as a previous user, and whether it appears on blacklists. A prefix that is still routed elsewhere, or that carries a poor reputation, causes trouble from day one.
• Geolocation. Geolocation databases sometimes place new prefixes in the wrong country. Publishing a geofeed file and referencing it from the inetnum’s geofeed: attribute gives providers an authoritative source to correct this.

Are the routing registries right?

Your upstream will very likely check two systems before accepting your route.

IRR. Create a route (or route6) object in the RIPE Database naming your prefix and your ASN as origin. If you’ll have downstream customers, create an as-set listing their ASNs and give its name to your upstream. Many transit providers rebuild their prefix filters from IRR data on a schedule rather than instantly, so create the objects well before the session date.

RPKI. Create a ROA authorising your ASN to originate the prefix. Set the maximum length to the prefix length you actually announce unless you have a reason not to; a loose maximum length lets someone else originate more-specific routes that would still validate. If the space is leased, the holder creates the ROA. Networks performing route origin validation drop RPKI-invalid announcements, so a wrong ROA is worse than none.

What do you need from your upstream?

Ask your transit provider or peer for:

• their ASN and the session IP addresses on both sides, for IPv4 and IPv6;
• whether they use a TCP MD5 password or TCP-AO, and how they’ll share it;
• what they’ll send you: a full table, a default route only, or their customer routes;
• the maximum number of prefixes they’ll accept from you, and what happens if you exceed it;
• the BGP communities they support, for example for blackholing, prepending or local preference;
• anything they need first, such as an LOA or IRR objects, and how long their filter updates take.

Agree a turn-up time when someone from their NOC is available, and share a contact for your side.

How should you set up the router and filters?

The filters matter more than any other part of the configuration, in both directions.

Outbound. Announce only your own prefixes, using an explicit prefix list. Never pass routes learned from one upstream to another, or you become a transit path for traffic you never intended to carry. RFC 8212 specifies that eBGP sessions exchange no routes until a policy is configured, and some implementations behave this way by default; treat it as the safe baseline.

Inbound.

• Drop bogons, your own prefixes, and prefixes that are too long.
• Enable route origin validation and reject RPKI-invalid routes.
• Set a maximum-prefix limit on each session.

The route itself. Most BGP implementations only announce a prefix that exists in the routing table. Add a static or null route for the aggregate so the announcement stays stable when internal routes change.

Check that the router has enough memory if you’ll take full tables, and set up monitoring of session state and received and sent prefix counts before you go live, not afterwards.

How do you verify the announcement?

Once the session is established:

1. Confirm you are sending exactly the prefixes you expect and nothing else.
2. Check visibility from outside with public looking glasses, RIPEstat or bgp.tools, allowing time for propagation.
3. Confirm the route shows as RPKI-valid.
4. Test reachability in both directions from hosts outside your network.
5. Check that reverse DNS resolves for addresses used for mail or customer-facing services.

Keep a short change log of what was configured and when. If something breaks later, it shortens the investigation. When you add a second upstream, repeat the same checks for that session rather than assuming the first one’s settings carry over.

How TACS can help

TACS prepares the registry side of a first announcement, including route objects, ROAs, LOAs and reverse DNS, for space you hold or lease from us. See ASN if you still need a number or Lease IPv4 for address space, and our Infrastructure management team can help with the router configuration and monitoring.