BGP – Part 1: Basic Setup

BGP or Border Gateway Protocol is a pretty big topic, so we will be looking at it over the course of three different posts.

Part one (this post) will cover the background, and basics of iBGP and eBGP peering, as well as route advertisement, part two and part three will cover route advertisements in more detail, as well as covering route injection, route filtering and path attributes.

BGP Background

BGP is an exterior gateway protocol, as opposed to RIP, EIGRP and OSPF which are interior gateway protocols. Version 4 of BGP is the current standard. It is a path vector routing protocol, designed to route between Autonomous Systems (AS’s), and each AS is assigned an Autonomous System Number (ASN).

For BGP to work it must form a peering (a neighbor relationship). There are two types of peers:

  • iBGP (peers within the same AS)
  • eBGP (connecting between separate AS’s)

Once a peer is formed, the neighbors share their full routing table, and after that only forward updates to their peers, which saves on bandwidth and time.

eBGP peers are assumed to be a maximum of one hop away, though this can be bypassed using the ebgp-multihop option with the neighbor command, which we will cover later.

iBGP peers are reliant on the underlying igp (such as RIP, OSPF or EIGRP) to connect the peers together. By default, all iBGP peers must be fully meshed within the AS.

A BGP router can only belong to one AS, and Cisco IOS only allows one BGP process to run.

The AD for routes learned outside the AS (eBGP) is 20. The AD for iBGP and locally originated routes is 200.

Peering messages

BGP uses several message types to communicate between the peers:
OPEN – to initiate the session – contains BGP version which must match, the local AS number and the BGP router ID.
KEEPALIVE – keepalives are sent every 60 seconds, if no replies are received within the hold-time period (180 seconds) the router declares the peer dead.
UPDATE – used to exchange routes
NOTIFICATION – sent when there is a fatal error. BGP session is torn down and reset.

Peering states (BGP Finite-State Machine / FSM)

BGP goes through several states (as do the IGP’s) as a peer is established. These states are:

Idle – initial state
Connect – waits for TCP connection from a remote peer. Results in either OPEN message if successful, or placed in an Active state if unsuccessful.
Active – Attempts to initiate a TCP connection with the peer. If successful results in OPEN message, or if unsuccessful then waits for ConnectRetry timer to expire and goes back to Connect state
OpenSent – Session is established and an OPEN message is sent, once it receives a reply the peer will send a KEEPALIVE
OpenConfirm – BGP listens for a reply KEEPALIVE message
Established – BGP peer session is fully established. UPDATE messages now sent containing the routing information.

Configuring BGP

If you have configured any IGP in the past then the basics of configuring BGP will not offer any surprises.

We start by specifying the AS

RouterB(config)# router bgp 100

Next it is generally good practice to set the router-id. The router-id (if not specified) will use the highest IP address of any loopback interface, and if no loopback interface exists, the highest IP address of any physical interface.

The router id is set using the command “bgp router-id x.x.x.”

Next, we set the neighbors

RouterB(config-router)# neighbor 10.1.1.1 remote-as 100
RouterB(config-router)# neighbor 12.1.1.2 remote-as 400

For stability, we can use a loopback address as the source

RouterB(config-router)# neighbor 12.1.1.2 update-source lo0

RouterC must then point to the loopback ip of routerB

RouterC(config)# router bgp 400
RouterC(config-router)# neighbor 1.1.1.1 remote-as 100

In order to use a loopback address as a source, the peer must have a static route to the other router’s loopback in its routing table.

If we use the loopback as a source then this is more than one hop away. Therefore the multi-hop feature must be used. If the number at the end is omitted then the default of 255 is used:

RouterC(config)# router bgp 400
RouterC(config-router)# neighbor 1.1.1.1 ebgp-multihop 2

BGP authentication

Authentication is very straightforward:

RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 12.1.1.2 password CISCO

Now we have had a quick overview, let’s start configuring!

We have three AS’s
AS 100:
R1 – IP address 10.1.1.1 – BGP router-id = 1.1.1.1
AS 200:
R2 – IP address 10.1.1.2 / 12.1.1.2 – BGP router-id = 2.2.2.2
R3 – IP address 12.1.1.3 / 12.1.1.4 – BGP router-id = 3.3.3.3
R4 – IP address 12.1.1.5 / 13.1.1.1 – BGP router-id = 4.4.4.4
AS 300:
R5 – IP address 13.1.1.2 – BGP router-id = 5.5.5.5

1. AS 100 and 300 are separate AS’s, connecting to AS 200
2. BGP password authentication will be used between R1 and R2
3. R4’s loopback address will be used for the update-source between R4 and R5
5. We will also need to set up and IGP in AS 200.

bgp basic configuration

We can see by just using the neighbor command that it’s easy to set up eBGP peers, below is the “show run” from R1 and R2:

bgp configuration

bgp configuration

And the others are (at the moment set fairly similarly). Looking at the output from “sh ip bgp summary” we can see that each can see their immediate neighbor:

sh ip bgp

BGP update-source using a loopback

Now let’s configure R4 to use its loopback as the source and get R5 to talk to that IP instead of the 13.1.1.1 address. We add a loopback to each side, and set the update-source on R4 to be lo0

BGP loopbacks

On R5 add a route to 15.1.1.1 using the serial 0/0 interface:

static routing for BGP

Next, we remove the original BGP neighbor statement, and then add one back in, this time using the loopback address on R4, remembering to use the command “neighbor 15.1.1.1 ebgp-multihop 2“.

BGP ebgp-multi-hop

And we confirm that all is still well with the two peers

BGP peers

Usually, you would configure BOTH sides to use the loopback as the update source, this is intended to be for stability after all!

Transit AS and the synchronization rule

So we can see that AS 100 can talk to R2 in AS 200, the three routers in AS 200 can all see each other, and AS 200 and AS 300 are seeing each other as well. But there is no communication between them. AS 200 is acting as a transit AS. If an AS is acting as a transit AS it is governed by the BGP synchronization rule.

The BGP synchronization rule states that all routers in a transit AS (including non-BGP routers) must learn of a route before BGP can advertise it to an external peer.

So let’s add an IGP into the mix and see what happens…

BGP igp reliance

The configurations look like this:

BGP igp configuration

And now we can see from the “sh ip route” command that R5 can see all the way over to R1

routing table

Well, it is in the routing table at any rate, but pings fail. Lets look at the routing table for R1:

Cisco routing table

Well, there is not much in there, which brings us onto the next topic.

Originating prefixes

We have three ways to originate a prefix (advertise a network)

  • Using the network statement
  • Using aggregate-address statements
  • Redistributing from an IGP

Let’s use the network address first.

For this to work, we need to specify which networks we are going to advertise out of R2.

So, on R2 we will add the following statements:

BGP network command

Now let’s have a look at R1…

BGP network command

This looks much better now!

And we can do and end to end ping test to confirm:

ping tests

Issues with advertising a loopback across OSPF

I did encounter one issue. R1 was not picking up the 15.1.1.0/24 network.

BGP advertised loopback

We can see that R3 does not have an issue:

ping loopback bgp

R2 however sees it as a /32 subnet:

r2-15-1

It’s coming in through OSPF, so we can pinpoint the issue pretty quickly.

By default, OSPF will advertise a loopback interface with a /32 mask, even if another mask has been set. It’s defined under RFC2328. We can circumvent this by using the command “ip ospf network point-to-point” in the loopback interface on R4:

r4-ospf-pointtopoint

And now if we look at the tables for R2 and R1…

r2-15-2

r1-15

And we can see that R1 has full end-to-end connectivity!

Troubleshooting

One last thing to add before we wrap this up and get the second part of this trilogy underway is the very useful command “sh ip bgp neighbor <neighbor ip> advertised-routes – it’s great to see what routes are being advertised between peers:

sh-advertised

Very useful. And that’s it for now, you can read part two here.