Category Archives: BGP

Border Gateway Protocol

BGP Basics – Part 2 Single Upstream Peer

I will be using Vyatta as the routing platform throughout this series of posts, I will go through the details of installing and configuring Vyatta there are plenty of documents on the internet that can help with that. Suffice to say you will need the router installed and configured, and a layer two adjacency to your upstream provider, as this will generally be the case if you are buying transit and it is delivered via a cross connect or similar hand off to your location.

One you have your cross connect and the vlan tagged/trunked to your router’s interface (or the hand off plugged directly into your router) you should be good to go.

To complete the configuration we will need the following information:

  • The carrier/upstream ASN
  • The IP address assigned to your circuit by your upstream
  • Your ASN
  • The address space you wish to announce to the internet

In this example we will use the following information for the configuration; private address space as the prefix we are originating to the internet, private address space for the customer and carriers IP’s as well as private ASN’s, these are only used to illustrate this process they would obviously be different in a real world scenario.

  • Upstream ASN: 65000
  • Carriers IP:
  • Customer IP: (assigned by the carrier to our end of the circuit)
  • Customer ASN: 65001
  • Prefix to announce to the internet:

In Vyatta, like most other network operating systems, there are several steps to bring up a BGP peering and announce routes, but these steps will generally be the basic’s required for most platforms (IOS, Junos etc).

  1. Configure the BGP prefix list
  2. Configure the BGP neighbour
  3. Set a static route to blackhole/null0 for the prefix you are announcing
  4. Announce our address space into BGP

1. Configure the BGP prefix list

I usually attempt to do this as the second step however if you dont complete this step before bringing up the neighbour adjacency BGP will automatically import any routes it is being sent into your router. Usually this is not an issue if you only have one upstream provider as you will be importing either the global routing table, a subset of the global table or a default route. This is generally a question your carrier will ask you before they provision the circuit so you will be aware of this.

However if, for some reason, you want to perform any ingress filtering or alternatively you are configuring a peering session with a downstream router (a customers device perhaps) you may not want to blindly accept any routes immediately when the session is established. For this reason I find configuring the prefix list prior to configuring the neighbour information a bit cleaner.

In configure mode:

set policy prefix-list EXPORT-AS65000 rule 10 action permit
set policy prefix-list EXPORT-AS65000 rule 10 prefix
set policy prefix-list EXPORT-AS65000 rule 10 description “Anounce my prefix to the internet”

The commands above do the following:

create a prefix list called EXPORT-AS65000
match the network and allow this prefix to be announced to the specified neighbour

It is a good idea to name your prefix lists intelligently as a way of documenting your configuration, here we have named this prefix list by the function it is serving (EXPORT) and the ASN it is related to ie: who we are exporting routes to. You can have more than one rule pre prefix list but in this example we will only use one.

In this post we are going to assume that we will be importing whatever routes our upstream provider is going to send us, As I said before, BGP will automaticaly import all routes it is sent, so we will not go through the process of creating an import prefix list.

2. Configure the BGP neighbour

Now we have a prefix list defining the prefixes we want to announce to our neighbour we can go ahead and configure the bgp neighbour itself.

From configure mode:

set protocols bgp 65001 neighbor remote-as 65000
set protocols bgp 65001 neighbor soft-reconfiguration inbound
set protocols bgp 65001 neighbor prefix-list export EXPORT-AS65000
set protocols bgp 65001 neighbor update-source

The above commands do the following:

Tell bgp process that the neighbour IP is
Set the remote as to 65000 (the ASN of our carrier)
Set the neighbour to use the EXPORT-AS65000 prefix list
Set the source interface for bgp updates to (the IP address assigned by our carrier to our end of the circuit)
Configures soft reconfiguration inbound, this allows the bgp process to “refresh” the RIB without hard resetting the bgp session (a hard reset drops the session and all traffic while the neighbour ship re converges).

Soft reconfiguration is useful when making changes to a bgp peering session that is already online and passing traffic, for example, announcing a new prefix or removing an existing prefix announcement.

Once you commit this configuration you should be able to see a bgp neighbour session start and come up. You can check this with the following commands:

run show ip bgp summary

(In Vyatta if you want to run a user exec command from configure mode you can prefix the command with the run keyword).

Here you can see that the BGP session with the neighbour is up but we are yet to start exporting routes to our carrier. As I am configuring this example in a lab I have not created an prefixes to import into our router which is why you cannot see any routes being imported.

BGP router identifier, local AS number 65001
IPv4 Unicast - max multipaths: ebgp 1 ibgp 1
RIB entries 1, using 64 bytes of memory
Peers 1, using 2524 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd        4 65000      22      31        0    0    0 00:17:17        0

3. Set static route to blackhole/null0

We need to set a static route to blackhole for the prefix that we are originating to the internet. We do this to create an aggregate or summary route (according to google). This is necessary because BGP will only advertise routes that are in the routing table and a static route to blackhole/null0 will accomplish this.

Add a static route to blackhole with the following command:

set protocols static route blackhole

4. Announce prefix into BGP

The last step is to announce the prefix with the bgp network command. This tells BGP which network to advertise:

set protocols bgp 65001 network

You should now be able to see networks being advertised by the Customer router to the Carriers router. We can confirm this by running the following command on the customer router:

show ip bgp neighbors advertised-routes

If this has been done correctly you will see the following output:

BGP table version is 0, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>                 0         32768 i

Total number of prefixes 1

We can see also check that the carriers router is receiving our prefixes with the following command, usually you will not have access to your upstreams router to be able to check this, in this case you would use your carriers looking glass (or a another carriers looking glass if they don’t provide one), this is a website that will query a carriers router/route server and return the output to the page as if you were running the command directly on the carriers equipment.

Here is the output from our carriers router:

vyatta@Carrier:~$show ip bgp neighbors received-routes

BGP table version is 0, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>                 0             0 65001 i

Total number of prefixes 1

There we have it we now have a basic BGP peering session established and we are successfully advertising our prefix to our upstream who is then passing this onto the internet at large.

Footnote: Apologies for the spelling conflicts, particularly neighbour and neighbor. I am Australian and we spell this word differently to Americans which is the reason for the use of the “u” throughout the text. However so as to not confuse anyone reading the configuration examples I have left this out and used the American spelling because this is the way it is implemented in the Vyatta syntax.

BGP Basics – Part 1

In this series of posts I will be taking you through what BGP is, how to configure a peering session, how to advertise your public address space and hopefully a other things like how to use community tags and route maps.

What is BGP?

BGP stands for border gateway protocol and is the exterior routing protocol used to exchange routes between autonomous systems (networks) which form the internet today.

With BGP one network will peer with another “upstream” network and announce the downstream networks public IP address space to the upstream network, which in turn will propogate these routes to their upstream provider and the internet (usually).

What do we need to bring up a BGP peer?

To bring up a bgp session we need the following three things:

  • Portable address space and ASN assigned by an RIR (regional internet registry)
  • A router capable of running the BGP process
  • Someone to peer with (establish a bgp session)

How do you get an AS number?

RIR’s are responsible for assigning public address space per region, there are five RIR’s:

When an organisation applies for and is granted portable address space, they are assigned an AS number (autonomous system number). The AS number identifies the public address space and the organisation responsible for originating these routes onto the internet.

Which routers support BGP?

Most non consumer routers will support BGP in some form, however to receive a full global routing table you will need a device with enough memory and CPU to both hold the downloaded routes and compute the best path for each and store in memeory (if receiving multiple feeds).

Most organisations that use BGP will be multi-homed, meaning they will have two separate internet connections each with a BGP session to its respective upstream provider, receiving a full global table from each peer, this is generally for redundancy should one of the internet connections fail. From both these BGP feeds a single BGP table is computed installing the routes with the best path to each destination. When one of the internet connections fails the failed sessions routes are removed from the local table and the less prefered paths installed.

In this series of articles I will using Vyatta to demonstrate how to configure BGP, running Vyatta in a VM has sufficient resources to run BGP to one or two upstream providers (or more).

Who do we peer with?

When you set out to purchase a connection to the internet (transit link) this is the time you would discuss with your ISP the possibility of talking to them via BGP. If they allow this they will generally give you the option of receiving a full global routing table or just a default route to the internet. With a default route all traffic will match this route and be sent to the ISP regardless of the destination.

If you choose a default route, this can greatly simplify the model of router needed as you will not need a powerful CPU and lots of memory because you will only be receiving a single route. Most of the time, however, if you want to use BGP you would be multi-homed (or be connected to multiple peering points in addition to transit links) and want to receive the full global routing table from each peer to determine the best path to a destination.

In the next article we will go into how to configure a bgp peering session.