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 network together, enabling end-to-end transport. Scalability and stability are BGP’s 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 it’s path-vector attributes to help in loop prevention. When an update leaves an AS, the AS number is prepended to 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 (to view – #show ip bgp summary).
BGP Database
Lists all networks known by BGP along with their attributes. (to view – #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 sends 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”. Routers that receive 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, let’s 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 and 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 BGP’s 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 aren’t 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 clear ip bgp [ * | neighbor-address] command performs the BGP route refresh.
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 router’s, 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 bgp 65300
R1(config-router)# neighbor 10.1.1.1 remote-as 65300
R1(config-router)# neighbor 10.1.2.1 remote-as 65300
R1(config-router)# neighbor 10.1.3.1 remote-as 65300
Peer group configuration example:
R1(config)# router bgp 65300
R1(config-router)# neighbor MINE peer-group
R1(config-router)# neighbor MINE remote-as 65300
R1(config-router)# neighbor 10.1.1.1 peer-group MINE
R1(config-router)# neighbor 10.1.2.1 peer-group MINE
R1(config-router)# 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 R2′s 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 R2′s 10.1.1.2 interface drops, it still has connectivity to R2′s networks via R3 and R2′s other physical interface. Even though an IGP would still show R2′s 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 R2′s 10.1.1.2 interface fails, R2 will still be reachable.
The update-source command accomplishes this. Here’s an example:
R1(config)# router bgp 65400
R1(config-router)# neighbor 192.168.2.2 remote-as 65400
R1(config-router)# neighbor 192.168.2.2 update-source loopback0
R2(config)# router bgp 65400
R2(config-router)# neighbor 192.168.1.1 remote-as 65400
R2(config-router)# neighbor 192.168.1.1 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 doesn’t 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 bgp 65300
R1(config-router)# neighbor 10.1.1.1 remote-as 65300
R1(config-router)# network 10.1.1.0 255.255.255.0
R1(config-router)# neighbor 10.1.2.1 remote-as 65300
R1(config-router)# 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 hell-bent on 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, let’s 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 bgp 65100
R2(config-router)# neighbor 10.1.1.1 remote-as 65100
R2(config-router)# neighbor 10.2.2.1 remote-as 65100
R2(config-router)# 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 0-4,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. 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
Here’s 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
It’s 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 nit overwhelming if you don’t 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
Here’s 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.
