This section of the Toolbox describes what a network operator needs to do next.

So far we have assumed that the dear reader is a newcomer to peering. The story so far has explained all the terminology and what Internet resources are required.

This section is all about simple deployment scenarios newcomers will likely encounter.

• Single Upstream with Private Peer

Most network operators first encounter with peering is when they have a simple connection to their upstream provider. This connection usually involves the operator having a static default route configured on the link to the upstream, with the upstream pointing a default route to their customer.

There are two possible cases here:

1. Adding the peering, retaining static route to upstream
2. Adding the peering, introducing BGP with the upstream

If we are not already using our own address space, then we need to consider first how to go about deploying it.

We already have obtained our own address space and ASN for the network. As noted elsewhere, most upstream providers forbid the use of their address space for connecting with any other operator. Renumbering a network is beyond the scope of the Toolbox, but there are many published documents and guides on how to do this. At a high level, the steps are:

1. Create your Route Object for your address space, using your upstream provider's ASN
2. Create your ROA for your address space, using your upstream provider's ASN
3. Provide a Letter of Authority (LOA) to your upstream provider requesting their peers and transits accept and propagate your address space (some providers request this, so it is good to be prepared)
4. Organise with the upstream (transit provider) for the address space to be announced globally and routed to you
5. Renumber the network (change dynamic pools, and use secondary addressing if needed)
6. Withdraw the old address space
7. Return the old address space to the upstream

Once our own address space is in use for the network, BGP needs to deployed internally (IBGP) across the network (at least for the devices in the core and border of the network). If the network is just of a single router, no IBGP is needed.

There are many online guides on how to deploy IBGP so will not be covered here. The assumption is that an interior routing protocol like OSPF or ISIS is already operating - if it is not, then this will also need to be deployed before IBGP can be deployed. The AS number that BGP requires is the one already obtained from the Regional Internet Registry.

The final step is to deploy EBGP with the brand new peer. With BGP already running on the border/peering router, all that needs to be done is a session added to talk to the new neighbour.

First we create our BGP policy:

• outbound we announce just our address block, so a prefix filter allowing our address block out to our peer is sufficient here
• inbound we accept just the prefixes our peer will send us, so another prefix filter allowing those in from our peer is sufficient here

And then we set up the EBGP session with our direct peer.

The prefixes learned will be propagated by the IBGP across the network, and all devices connected will now have a direct path to the peer.

Here we go one step further.

The address space still needs to be deployed, IBGP needs to be set up across the backbone, and EBGP needs to be set up with the peer. These three steps were described in the previous section.

Enabling EBGP with the upstream will now make the network operator's ASN visible to the global Internet. There are very distinct steps to enabling this.

First we need to discuss with the upstream provider about setting up the EBGP session.

This content is sourced from many contributors, including:

• Value of Peering Presentation - Philip Smith
• Network Startup Resource Center
• Input from Mark Tinka, Kurt Erik Lindqvist, etc

Back to Home page