Your first ASN: making the first BGP session boring

Your first BGP session should be boring. The interesting first sessions are the ones where a typo in a policy announces something you don't own, or accepts a full table into a router that can't hold it, at 2am, learned from a forum post.

Here's what you need, in the order most people get it.

1. APNIC membership

Your registry account in the Asia-Pacific. Everything else hangs off it. Fees are on APNIC's pricing page.

2. An ASN

Your network's identity in BGP. It's what your upstreams and peers will see as the origin of your routes.

3. Address space

IPv4 prefixes no more specific than a /24, and IPv6 no more specific than a /48, are generally accepted for global routing. Eligible APNIC members can apply for up to a /23 of IPv4 under its current policy; existing resources and authorised transfers are the other options.

Addresses you were given by a previous provider usually aren't yours to take. Check before you plan a migration around them.

4. ROAs

A Route Origin Authorisation is a signed record saying your ASN may originate your prefix. Networks that validate RPKI, including ours, use them to decide whether to believe your announcement. Create them in MyAPNIC before your first session, for every prefix you'll announce, with the maximum length you actually intend to use.

5. IRR route objects

Upstreams and peers build their filters from routing registries. A route object for each prefix, with your ASN as the origin, is how they know to accept it. Without one, a careful upstream will drop your announcement, and a careful upstream is the kind you want.

6. A router and a written policy

Filters, preferences and failover, written down before go-live. At minimum:

• Announce only your own prefixes. An explicit prefix list, and reject everything else.
• Decide what you accept. A default route, or the full table? A full table needs a router with the memory for it.
• Plan for the second upstream even if you only have one today.

The outbound side is the part that matters most for everyone else on the internet. In Junos it can be as small as this, using a documentation prefix:

policy-options {
    prefix-list OUR-PREFIXES {
        203.0.113.0/24;
    }
    policy-statement TO-UPSTREAM {
        term ours {
            from {
                prefix-list-filter OUR-PREFIXES exact;
            }
            then accept;
        }
        term everything-else {
            then reject;
        }
    }
}

Small, explicit, and impossible to accidentally leak someone else's routes through.

7. The first session

Then, and only then, bring up the session: one upstream, full table or default, IPv4 and IPv6. Check what you're announcing, check what they're accepting, and check the result from outside with a public tool such as bgp.he.net or RIPEstat.

When that's been boring for a while, add a second upstream and exchange peering.

Getting help

Transit from AS152590 is full table, IPv4 and IPv6, with route origin validation, and the engineer who configures your session is the one you talk to. If you'd like someone to review your plan before anything goes live, that's what network engineering is for. The Your first ASN page has the rest, or send us your plan.