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 BGP peer (a neighbor relationship). There are two types of peers:
- iBGP (peers within the same AS)
- eBGP (connecting between separate AS's)
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 with in 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.
BGP 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.
BGP 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 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 bgp 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 the highest IP address of any physical interface.
The BGP 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 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
BGP 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 over view, 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 its easy to set up BGP ebgp peers, below is the "show run" from R1 and R2:
BGP update-source using a loopback
Now lets 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:
And we confirm that all is still well with the two 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!
BGP Transit AS and the BGP 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 lets 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, there is not much in there, which brings us onto the next topic.
Originating prefixes in BGP
We have three ways to originate a prefix (advertise a network) into BGP- Using the network statement
- Using aggregate-address statements
- Redistributing an IGP into BGP
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 lets have a look at R1...
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:
Its coming in through OSPF, so we can pinpoint the issue pretty quickly (i.e. we know that its not a BGP issue).
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!
I'd like to thank my colleague Muhammed for his help in this last bit. he's also going for his CCIE at the moment and to this useful post on OSPF advertising a loopback with a /32 subnet.
Troubleshooting BGP
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 - its great to see what routes are being advertised between peers:
Very useful. And that's it for now, you can read part two here.