Establishing a BGP Session with RackGenius

This article explains how to establish an eBGP session with RackGenius so you can announce your own ASN and IP space through our network. It covers what you need before requesting a session, how our sessions are configured, our filtering requirements, and exactly what to include in your ticket so we can provision both the IPv4 and IPv6 sessions on the first pass.

In a hurry? Jump to the Ticket Submission Checklist at the bottom of this article, fill in the copy-and-paste template, and open a ticket. Everything above the checklist is background.

Who this is for

You need a BGP session with us if you hold your own Autonomous System Number and want to announce your own IP prefixes (PA or PI space) across our upstreams and peering. Typical cases:

• IP transit customers announcing their allocated IPv4 and IPv6 space.
• Colocation customers in 123Net DC1 (Detroit) or DC4 (Grand Rapids) delivering their own prefixes over a cross-connect.
• Downstream networks buying transit that also want to receive routes from us for their own routing decisions.
• VPS and dedicated server customers looking to bring their network to RackGenius.

If you only need usable IP addresses on a server and are not running your own ASN, you do not need a BGP session. A standard IP assignment or a routed subnet covers that case.

Prerequisites

Before you request a session, confirm the following. Missing any of these is the most common reason a request stalls.

• Your own ASN. A 16-bit or 32-bit ASN registered to you at an RIR (ARIN, RIPE, APNIC, etc.).
• IP space you are authorized to announce. Either space allocated or assigned directly to your ASN, or space you hold a valid Letter of Authorization for. See Letters of Authorization below.
• An active service that carries the session. A transit port, a cross-connect into our gear at DC4, or a VLAN on an existing service. The BGP session rides on top of a delivered Layer 2/Layer 3 path, so that path has to exist first.
• A router that speaks eBGP. Any standards-compliant router (Arista, Cisco, Juniper, MikroTik, VyOS, BIRD, FRR, etc.). You are responsible for configuring your side.
• Published IRR objects for every prefix you intend to announce. We build prefix filters from IRR. See Route Filtering.

How our sessions are configured

Our defaults are listed below. Anything marked adjustable can be changed on request in your ticket.

Sessions are terminated on our Arista EOS edge.

Route filtering (IRR + RPKI)

We filter every customer session. Announcements that do not pass are dropped. Two things must be in order before your prefixes will be accepted:

1. IRR objects

Publish a route: object for every IPv4 prefix and a route6: object for every IPv6 prefix, each with the correct origin: ASN, in an IRR database (RADB, ARIN, RIPE, ALTDB, etc.). If you announce more-specifics, each more-specific needs its own object or must be covered by your policy. If you have an as-set / AS-SET macro, give us its name so we can build against it as your announcements grow.

We rebuild prefix filters from IRR on a schedule. New or changed objects are picked up automatically, but there is a propagation delay. If you add a prefix and need it accepted quickly, note it in a ticket.

2. RPKI ROAs

We perform RPKI Origin Validation. Create ROAs at your RIR authorizing ASyour-asn to originate each prefix at the correct max length. Routes that evaluate as RPKI-invalid are rejected. RPKI-unknown is accepted but you should aim for valid. A common mistake is a ROA max length that is shorter than the prefixes you actually announce, which makes your more-specifics invalid.

Rule of thumb: the prefix must be RPKI-valid and covered by an IRR object with the matching origin ASN, or it will not be installed.

Letters of Authorization

You need to supply an LOA when you are announcing space that is not directly and obviously registered to your announcing ASN. That includes:

• Space assigned to you by RackGenius that you want to originate from your own ASN.
• Space held by a parent organization or a customer of yours, announced under your ASN.
• Any block where WHOIS does not make the authorization self-evident.

The LOA should identify the exact prefix(es), your ASN, the authorizing party, and be signed by someone with authority over the block. Send it to [email protected] or attach it to your ticket. We may also require it for our own upstreams before your routes propagate globally.

BGP communities

Routes carried in our network are tagged with informational communities so you can see where a prefix entered. If you take a full table from us, these are visible on the routes you receive:

Action communities for traffic engineering (selective prepend, no-advertise to a specific upstream, and remote-triggered blackhole) are supported. Contact us for the full action-community list if you plan to steer outbound announcements per upstream.

Note: confirm the blackhole community and action-community values with our team before relying on them. The values above are subject to change.

After the session is established

• Looking glass: verify your prefixes are seen and check paths at lg-mi.rackgenius.com.
• Adding prefixes later: publish the IRR object and ROA, then open a ticket if you need the filter refreshed ahead of the scheduled rebuild, or if the new prefix would exceed your max-prefix cap.
• Session flaps or filtering issues: open a ticket with your side's session state and, if you can, the specific prefix that is not being accepted.

Ticket submission checklist

Open a ticket to our peering team (or reply on your provisioning ticket) with the items below. Copy the template, fill it in, and paste it into the ticket. The more complete this is, the faster both sessions come up.

What to include

1. Your ASN.
2. Prefixes to announce: every IPv4 and IPv6 prefix with its length. List more specifics if you announce them.
3. IRR confirmation: the database your route/route6 objects live in, and your as-set name if you have one.
4. RPKI status: confirm ROAs exist for each prefix at the correct max length.
5. Max-prefix expectation: how many prefixes you expect to announce per family now, so we set the cap with headroom.
6. What you want from us: full table, default only, or both.
7. LOA: attached, if you are announcing space not obviously registered to your ASN (see the LOA section).
8. Session options: MD5 (and secret, or ask us to set one), BFD, multihop: only if you need them. Otherwise, we use the defaults.
9. Which service carries the session: the transit port, VPS, dedicated server, cross-connect ID, VLAN, or colo service the session should ride on, and the site (Grand Rapids or Detroit).
10. NOC and abuse contact: email and/or phone for your network, plus your PeeringDB record if you have one.
11. Router platform: vendor/OS, for our reference only.

Our side: if you have no IP space with us, we assign the point-to-point link addressing (IPv4 /31 and IPv6 /127); if you already hold an assignment with us, we use addressing from that. We configure both sessions against your IRR-derived filters with RPKI validation, apply your max-prefix caps, and send you our AS32002 peer IPs once built. You configure your end to match.

Questions before you submit? Reach our peering desk at [email protected] or open a ticket, and we will help scope it.