Probable reasons BGP isn't installing a route

Although perhaps only one route to a destination exists, there are a number of reasons BGP might not select it as a "best" route (consequently omitting it from the routing table). Below are some of the most common causes.

Synchronization is enabled and the route is not known by an IGP

If synchronization is enabled, BGP requires each route to be known by an IGP before placing it in the routing table. This is considered legacy behavior and isn't typically enforced on modern networks. Synchronization is easily disabled:

Router(config-router)# no synchronization

In fact, synchronization is disabled by default beginning with IOS release 12.2(8)T.

NEXT_HOP is inaccessible

If the router doesn't know how to reach a route's next hop, a recursive lookup will fail, and the route can't be added to BGP. For example, if a BGP router receives a route for 10.0.0.0/8 with a NEXT_HOP attribute of 192.168.0.1, but doesn't have an entry in its routing table for a subnet containing 192.168.0.1, the received route for 10.0.0.0/8 is useless and won't be installed in the routing table.

AS_PATH includes the local AS

If a route advertised by an external (eBGP) neighbor includes the local AS in its AS_PATH attribute, the route will be rejected. This is a loop prevention mechanism used by BGP, and it is a fundamental concept of the protocol. However, there may be instances when you want to bend this rule and allow such routes anyway. This can be accomplished by appending the allowas-in keyword to a neighbor statement:

Router(config-router)# neighbor 1.2.3.4 allowas-in

As this configuration results in somewhat abnormal BGP behavior, exercise caution to avoid creating routing loops.

Attempting to readvertise iBGP-learned routes to iBGP neighbors

BGP won't advertise a route learned from an internal (iBGP) neighbor to other internal neighbors. To achieve full convergence within an autonomous system, it is recommended to configure mesh adjacencies, or to employ route reflectors or confederations.

Rejection by inbound policy

Routes may be being unintentionally blocked by an inbound route-map applied to the BGP neighbor. This can be inspected by comparing the output of two variations of the show ip bgp neighbor command:

Router# show ip bgp nei 172.16.0.2 received-routes
BGP table version is 6, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
          r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*  192.168.2.0      172.16.0.2             100             0 65200 ?
*  192.168.3.0      172.16.0.2             100             0 65200 ?

Total number of prefixes 2

The first command displays all routes being advertised by the specified neighbor. Note that inbound soft-reconfiguration must be enabled for the neighbor in order for this command to produce any useful output.

Router# show ip bgp nei 172.16.0.2 routes
BGP table version is 6, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
          r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*  192.168.3.0      172.16.0.2             100             0 65200 ?

Total number of prefixes 1

This second command lists all routes from the neighbor which have been entered into the routing table. The above output reveals that only one of the advertised routes (192.168.3.0/24) is being allowed through the inbound routing policy for this neighbor. When this happens, double-check the route-map applied inbound.