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.
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:
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:
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
On R5 add a route to 15.1.1.1 using the serial 0/0 interface:
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“.
And we confirm that all is still well with the two 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…
The configurations look like this:
And now we can see from the “sh ip route” command that R5 can see all the way over to R1
Well, it is in the routing table at any rate, but pings fail. Lets look at the routing table for R1:
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:
Now let’s have a look at R1…
This looks much better now!
And we can do and end to end ping test to confirm:
Issues with advertising a loopback across OSPF
I did encounter one issue. R1 was not picking up the 15.1.1.0/24 network.
We can see that R3 does not have an issue:
R2 however sees it as a /32 subnet:
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:
And now if we look at the tables for R2 and R1…
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:
Very useful. And that’s it for now, you can read part two here.
