Simple AS Howto

Introduction

This document is intended to introduce the reader to running a simple AS. This document isn't aimed at those who wish to do complicated engineering or transit other ASes across their network.

Our intention is to configure BGP on our network with our AS number 45000. We will have upstream connections to Level3 (AS3356), Onyx Internet (AS6067) and KPN (AS286). We want to announce our netblocks only to our peers, and build an optimum local routing table using the shortest-path routes from our peers.

Initially we'll assume that there is only one BGP-enabled router on our network, then we'll introduce another router and split the connectivity across both of them.

The diagram above shows how routes should be announced across the network. However, if we merely setup a BGP session to each of our peers we won't announce our netblocks, but we will announce the entire internet to each of our transit providers!

Basic Configuration

In order to announce our netblocks to our peers we need to use 'Network' statements in our BGP configuration combined with static routes to 'nail' our prefixes into the routing table. This is achieved using the following configuration :

If we now bring up our BGP sessions, we'll announce our own netblocks along with the entire internet to all of our peers!

We need to filter our outbound announcements so that we only announce our own routes to our peers. This is done by configuring our peering sessions as below :

Firstly we've created a prefix list which will permit our supernets 20.0.0.0/8 and 21.0.0.0/8. We've then applied this prefix list to our outbound announcements.

This is a very simple configuration, but is sufficient for a number of applications, such as a web farm or mail cluster hosted in a datacentre with multiple connectivity providers.

Multiple Routers

Now we'll add another router to our AS, to introduce some resilience. We'll connect this new router (gw2) to the first (gw1) (and presumably also to the rest of our network) and move the KPN connection to it.

As you can see from the diagram above, our routing tables won't be affected by introducing another router, as they'll distribute routes to eachother using an iBGP session. We're assuming here that our network has a working IGP and our two BGP routers both have working loopback addresses on Loopback0

The configuration for gw1:

The configuration for gw2:

Notice that we've not used the prefix-lists for these peering sessions. That's because we want gw1 and gw2 to send each other the entire routing tables. The update-source directive tells BGP to make the connection from its loopback address. The peer addresses we've used are the Loopback addresses for the routers.

Establishing our BGP sessions to and from our routers loopback addresses is important to keep our network stable, as the session isn't dependant on any single interface being up.