BGP, or Border Gateway Protocol is an external, dynamic routing protocol.

It is most often used

between ISPs and between enterprises and their service providers. BGP is literally the routing
protocol of the Internet because it connects independent networks together, enabling end-to-end
transport. Scalability and stability are BGPs focus, not speed as a result it behaves very
differently than most other routing protocols.
BGP is recommended whenever multihoming is a requirement (dual ISP connections to different
carriers), when route path manipulation is needed, and in transit Autonomous Systems.

A Quick Overview

Routers running BGP are called BGP speakers.

BGP uses autonomous system numbers to keep track of different administrative
domains. 1-64511 are public, 64512-65535 are private.
BGP is used to connect IGPs, interior gateway protocols like OSPF and EIGRP. Routing
between Autonomous Systems is referred to as interdomain routing.
The administrative distance for eBGP routes is 20, iBGP is 200.
BGP neighbors are called peers and must be statically assigned.
Peers receive incremental, triggered updates as well as keepalives using TCP port 179.
BGP is sometimes referred to as a path-vector protocol because its route to a
network uses AS numbers on the path to the destination.
BGP uses its path-vector attributes to help in loop prevention. When an update leaves an
AS, the AS number is prepended to the update along with all the other AS numbers that
have spread the update.
When a BGP router receives an update, it first scans through the list of AS numbers. If it
sees it own AS number, the update is discarded.

BGP Databases
Like most modern routing protocols, BGP has two separate databases a neighbor database and
a BGP-specific database.
Neighbor Database
Lists all of the configured BGP neighbors
Router# show ip bgp summary

BGP Database
Lists all networks known by BGP along with their attributes.
Router# show ip bgp

BGP Message Types

There are four different BGP message types.
Open
After a BGP neighbor is configured, the router sends an open message to establish peering with
the neighbor.
Update
The type of message used to transfer routing information between peers.
Keepalive
BGP peers send keepalive messages every 60 seconds by default to maintain active neighbor
status.
Notification
If a problem occurs and a BGP peer connection must be dropped, a notification message is sent
and the session is closed.

Internal vs. External

iBGP, or internal BGP is a peering relationship between BGP routers within the same
autonomous system. eBGP, or external BGP describes a peering relationship between BGP
routers in different autonomous systems. It is an important distinction to make.
In the diagram below, R1 and R2 are eBGP peers. R2 and R3 and iBGP peers.

BGP Next-Hop Self

When you have BGP neighbors peering between autonomous systems like R1 and R2 above,
BGP uses the the IP address of the router the update was received from as its next hop. When
a router receives an update from an eBGP neighbor, it must pass the update to its iBGP
neighbors with-out modifying the next hop attribute.
The next-hop IP address is the IP address of the edge router belonging to the next-hop
autonomous system.
For example, lets say R1 sends an update to R2 from its 10.1.1.1 serial interface. R2 must use
keep the next-hop IP set as 10.1.1.1 when it passes the update along to R3, its iBGP peer. The
problem is that R2 does not know about 10.1.1.1 and so it cannot use it as its next hop address.
The neighbor [IP address] next-hop-self command solves the problem by advertising itself as
the next-hop address. In this example, it would be applied to R2 so any updates passed along to
R3 would use an R2 address as the next-hop.
R2(config)# router bgp 65300
R2(config-router)# neighbor 10.2.2.2 next-hop-self
R2(config)# exit

BGPs Synchronization Rule

The BGP synchronization rule states that a BGP router cannot use or forward new route updates
it learns from iBGP peers unless it knows about the network from another source, like an IGP or
static route.
The idea is to prevent using or forwarding on information that is unreliable and cannot be
verified. Remember, BGP prefers reliability and stability over using the newest, fastest route.
This means that iBGP peers will not update each other unless an IGP is running under the
hood. To remove the limitation, use the no synchronization command under BGP configuration
mode. recent versions of IOS have it disabled by default, but it is important topic to understand.

Resetting BGP Sessions

Internet routers running BGP have enormous routing tables. When a filter is applied, like a route
map, changes to BGP attributes occur. Those changes could affect many of the routes already in
the routing table from BGP. Because BGPs network list is usually very long, applying a route
map or prefix list after BGP has converged can be disastrous. The router would have to check
the filter against every possible route and attribute combination.

To make matters worse, if it were to apply the filters and pull routes back from neighbors, those
changes could then cause another reconvergence and on and on. In an effort to avoid that
scenario (BGP loves stability), BGP will only apply attribute and network changes to routes
AFTER the filter has been applied. All existing routes stay unchanged.
If the network administrator decides that the filter needs to be applied to all routes, then the BGP
instance must be reset forcing the entire BGP table to pass through the filter. There are three
ways to do this:

Hard reset
Soft reset
Route refresh

The hard and soft reset options arent discussed here because they are not directly relevant to the
exam. You should know though, that both options are extremely memory-taxing on the router as
all the routes must be recomputed. Route refresh was developed to solve the high memory
problems, while still forcing a reset.
The following command performs the BGP route refresh:
Router# clear ip bgp [ * | neighbor-address]

BGP Configuration
Enabling BGP
Like other routing protocols, BGP must be enabled with the router command. Make sure to
include the AS number.
R1(config)# router bgp autonomous-system-number

BGP Peering
Each neighbor must be statically assigned using the neighbor command. If the AS number
matches the local routers, it is an iBGP connection. If the AS number is different, it is an eBGP
connection.
R1(config-router)# neighbor ip-address remote-as autonomous-system-number

If a router has a long list of directly connected neighbors, the BGP configuration can start to get
long and difficult to follow especially as neighbor policies are applied. Peer groups solve that.

Peer groups are groups of peer neighbors that share a common update policy. Updating an
entire group of neighbor statements can then be done with one command. Much easier for large
BGP networks. Think of a peer group as a logical grouping of routers that are grouped under a
single name to make changes faster and configurations shorter. Like OUs in Active Directory.
Peer groups not only reduce the number of lines of configuration, but they reduce the ease the
overhead of the router. A BGP update process normally runs for each neighbor. If a peer group
is configured, a single update process runs for all routers in the group. Notice that this means
that all of the router inside a peer group must be either all iBGP or eBGP neighbors.

Basic neighbor configuration example:

R1(config)# router
R1(config-router)#
R1(config-router)#
R1(config-router)#

bgp 65300
neighbor 10.1.1.1 remote-as 65300
neighbor 10.1.2.1 remote-as 65300
neighbor 10.1.3.1 remote-as 65300

Peer group configuration example:

R1(config)# router
R1(config-router)#
R1(config-router)#
R1(config-router)#
R1(config-router)#
R1(config-router)#

bgp 65300
neighbor MINE peer-group
neighbor MINE remote-as 65300
neighbor 10.1.1.1 peer-group MINE
neighbor 10.1.2.1 peer-group MINE
neighbor 10.1.3.1 peer-group MINE

BGP Source Address

R1 in the diagram below has two different options when it comes to peering to R2. It can peer to
the physical interface IP address, 10.1.1.2 or it can peer to R2s loopback interface, 192.168.2.2.

If a peer relationship is made using the physical interface as the source address, problems can
occur if the interface goes down. In this scenario, even if R2s 10.1.1.2 interface drops, it still
has connectivity to R2s networks via R3 and R2s other physical interface. Even though an
IGP would still show R2s network as accessible, the BGP peer relationship would drop because
R1 cannot reach its peering address with R2.
Most implementations recommend using a loopback address as the BGP source address for
this reason. Remember that the loopback address must be added to the IGP running for this to
work. This way, if R2s 10.1.1.2 interface fails, R2 will still be reachable. The update-source
command accomplishes this.
Heres an example:
R1(config)# router
R1(config-router)#
R1(config-router)#
R2(config)# router
R2(config-router)#
R2(config-router)#

bgp 65400
neighbor 192.168.2.2
neighbor 192.168.2.2
bgp 65400
neighbor 192.168.1.1
neighbor 192.168.1.1

remote-as 65400
update-source loopback0
remote-as 65400
update-source loopback0

Defining Networks
Network statements in BGP are used differently than in other routing protocols like EIGRP or
OSPF. EIGRP and OSPF use the network statements to define which interfaces you want to
participate in the routing protocol process.

BGP uses network statements to define which networks the local router should advertise. Each
network doesnt have to be originating from the local router, but the network must exist in the
routing table. The optional mask keyword is often recommended as BGP supports subnetting
and supernetting.
Example:
R1(config)# router
R1(config-router)#
R1(config-router)#
R1(config-router)#
R1(config-router)#

bgp 65300
neighbor 10.1.1.1 remote-as 65300
network 10.1.1.0 255.255.255.0
neighbor 10.1.2.1 remote-as 65300
network 10.1.2.0 255.255.255.0

Understand that by default a BGP router will not advertise a network learned from one iBGP
peer to another. This is why iBGP is not a good replacement for an IGP like EIGRP and OSPF.

BGP Path Selection

Unlike most other routing protocols, BGP is not concerned with using the fastest path to a given
destination. Instead, BGP assigns a long list of attributes to each path. Each of these attributes
can be administratively tuned for extremely granular control of route selections.
BGP also does not load balance across links by default. To select the best route, BGP uses the
criteria in the following order:

1. Highest weight
2. Highest local preference
3. Choose routes originated locally
4. Path with the shortest AS path
5. Lowest origin code ( i < e < ? )
6. Lowest MED
7. eBGP route over iBGP route
8. Route with nearest IGP neighbor (lowest IGP metric)
9. Oldest route
10. Neighbor with the lowest router ID
11. Neighbor with the lowest IP address

Controlling Path Selection

The most common method of controlling the attributes listed above is to use route maps. This
allows specific attributes to be changed on specific routes. Before we get into route maps, lets
first discuss the three prominent attributes: weight, local preference, and MED.

Weight
On Cisco routers, weight is the most influential BGP attribute. The weight attribute is
proprietary to Cisco and is normally used to select an exit interface when multiple paths lead to
the same destination. Weight is local and is not sent to other routers. It can be a value between
0-65,535. 0 is the default. In the example below, if you want R2 to prefer to use R1 when
sending traffic to 192.168.20.0 then the weight attribute could raised on R2 for R1.

R2(config)# router
R2(config-router)#
R2(config-router)#
R2(config-router)#

bgp 65100
neighbor 10.1.1.1 remote-as 65100
neighbor 10.2.2.1 remote-as 65100
neighbor 10.1.1.1 weight 100

Local Preference
Local preference is not proprietary to Cisco and can be used in a similar fashion to weight. It can
be set for the entire router or for a specific prefix. Local preferences can range from 04,294,967,295, with 100 being the default value. Unlike weight, local preference is propagated
to iBGP neighbors.
Using the diagram above, if an administrator wanted R2 to use R1 when sending traffic to
192.168.20.0, the configuration would look something like this:
R1(config)# router bgp 65100
R1(config-router)# bgp default local-preference 500

After the local preference is raised on R1, it will be shared with R2 and R2 will begin using it as
its best path to the distant network (assuming the weight is the same of course). If you want to set

the local preference on specif prefixes, route maps are usually the best option. Below is an
example of the local preference being set using a route map:
R7(config)# router bgp 200
R7(config-router)# neighbor 10.10.10.1 remote-as 100
R7(config-router)# neighbor 10.10.10.1 route-map lp_example in
R2(config-router)# exit
R7(config)# access-list 7 permit 10.30.30.0 0.0.0.255
R7(config)# route-map lp_example permit 10
R7(config-rmap)# match ip address 7
R7(config-rmap)# set local-preference 300
R7(config-rmap)# exit
R7(config)# route-map lp_example permit 20
R7(config-rmap)# set local-preference 100

MED

The MED attribute, or multi-exit discriminator is used to influence which path external
neighbors use to enter an AS. MED is also much farther down on the attribute list, so
attributes like weight, local preference, AS path length, and origin are used first. The default
MED value is 0 and a lower value is preferred. A common scenario for MED is when a company
has two connections to the same ISP for internet.
Weight or local preference could be used to send outgoing traffic on the higher bandwidth link,
but local preference is not shared with routers outside an AS. MED could be set on one router
so ISP routers prefer that path in.
To set the MED on all routes:
R1(config-router)# default-metric value

Heres an example using a route map to influence incoming paths to 10.30.30.0/24 using MED:
R7(config)# router bgp 200
R7(config-router)# neighbor 10.10.10.1 remote-as 200
R7(config-router)# neighbor 10.10.10.1 route-map med_example out
R2(config-router)# exit
R7(config)# access-list 7 permit 10.30.30.0 0.0.0.255
R7(config)# route-map med_example permit 10
R7(config-rmap)# match ip address 7
R7(config-rmap)# set metric 50
R7(config-rmap)# exit
R7(config)# route-map med_example permit 20
R7(config-rmap)# set metric 150

Verification

Its important that you understand and are able to interpret to results of the show ip bgp
command output. It displays the contents of the local BGP topology database- including the
attributes assigned to each network. It is perhaps the most important BGP verification and
troubleshooting tool!
Because BGP uses many attributes and sources routes in a number of ways, the output of the
show ip bgp command can be a bit overwhelming if you dont know what you are looking for.
R1# show ip bgp
BGP table version is 21, local router ID is 10.0.22.24
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Metric LocPrf Weight Path
*> 10.1.0.0
0.0.0.0
0
32768 ?
* 10.2.0.0
10.0.22.25
10
0 25 ?
*>
0.0.0.0
0
32768 ?
* 10.0.0.0
10.0.22.25
10
0 25 ?
*>
0.0.0.0
0
32768 ?
*> 192.168.0.0/16
10.0.22.25
10
0 25 ?

Attributes
Heres a breakdown of some important fields you should consider remembering:
* - An asterisk in the first column means that the route has a valid next hop.
s (suppressed) BGP is not advertising the network, usually because it is part of a summarized
route.
> - Indicates the best route for a particular destination. These will end up in the routing table.
i (internal) - If the third column has an i in it, it means the network was learned from an iBGP
neighbor. If it is blank, it means the network was learned from an external source.
0.0.0.0 - The fifth column shows the next hop address for each route. A 0.0.0.0 indicates the
local router originated the route (examples include a network command entered locally or a
network an IGP redistributed into BGP on the router)
Metric (MED value) The column titled Metric represents the configured MED values. Recall
that 0 is the default and if another value exists, lower is preferred.
i/?- The last column displays information on how BGP originally learned the route. In the
example above, ? is used for each route meaning they were all redistributed routes into BGP
from an IGP. The other option is a question mark, which indicates that network commands were
used to configure the route.