It is beyond the scope of this section to discuss all of the possible
problems that can occur, but a list of possible problems that will be briefly
discussed are:
- A BGP route not getting originated
- Problem in propagating/originating a BGP route to IBGP/EBGP neighbors
- Problem in propagating a BGP route to an IBGP neighbor but not to an EBGP
neighbor
- Problem in propagating an IBGP route to an IBGP/EBGP neighbor
A BGP Route Not Getting Originated
BGP originates IP
prefixes and announces them to neighboring BGP speakers (IBGP and EBGP) so that
the Internet can reach those prefixes. For example, if an IP address associated
with www.cisco.com fails to originate because of a BGP configuration mistake or
lack of protocol requirements, the Internet will never know about the IP
address of www.cisco.com, resulting in no connectivity to this web site.
Therefore, it is essential to look at BGP route-origination issues in detail.
Several causes in failure of BGP route origination exists, the most
common of which are:
- The IP routing table does not have a matching route.
- A configuration error has occurred.
- BGP is autosummarizing to a classful/network boundary.
BGP requires the IP routing table to have an exact matching entry for
the prefix that BGP is trying to advertise using the
network and redistribute commands. The
prefix and mask of the network that BGP is trying to advertise must be
identical in the IP routing table and in the BGP configurations. Figure
shows a
misconfiguration in BGP to adverstise 100.100.100.0/24 using the network
statement. The static route for 100.100.100.0 has a mask of /23, whereas BGP is
configured to advertise /24. Therefore, BGP will not consider /24 as a valid
advertisement because an exact match does not exist in the routing table.
Another cause to consider is BGP autosummarization of classful networks at
major network boundaries. BGP might be trying to redistribute 100.100.100.0/24,
but only 100.0.0.0/8 gets advertised. In most cases it would be desirable to
turn off autosummarization with the no auto-summary
command, so that proper mask routes can be advertised to BGP neighbors.
Problem in Propagating/Originating a BGP Route to IBGP/EBGP
Neighbors
A scenario might arise in which the BGP configuration to
originate and propagate routes looks good, but BGP neighbors are not receiving
the routes. The originator’s BGP table shows all the routes. There is a
possibility that configured distribute-list filters are the cause of the
problem or a problem in the policy routing.
Problem in Propagating a
BGP Route to an IBGP Neighbor But Not to an EBGP Neighbor
In some
cases, certain routes are not propagated to IBGP neighbors, but are propagated
only to EBGP neighbors.
When IBGP speakers in an AS are not fully meshed
and have no route reflector or confederation configuration, any route that is
learned from an IBGP neighbor will not be given to any other IBGP neighbor.
Such routes are advertised only to EBGP neighbors.

Figure
shows the
configuration of the routers R8, R1, and R2. This example shows that the IBGP
network is not fully meshed and that the IBGP-learned route will not be given
to any other IBGP neighbor. Verify this with the show ip
bgp command.
"Not
advertised to any peer" in R1 means that even though R2 is the neighbor,
it is an IBGP neighbor, therefore, 100.100.100.0/24 will not be advertised.
It is essential that IBGP-learned routes are propagated to other BGP
speakers. BGP operators can use three methods to address this problem:
- Use IBGP full mesh.
- Design a route-reflector model.

- Design a confederation model.

Problem in Propagating an IBGP Route to an IBGP/EBGP
Neighbor
A problem might arise in which an IBGP learned route is not
propagated to any BGP neighbor, whether it is an IBGP or EBGP neighbor. One
case could be that when an IBGP-learned route is not synchronized, that route
is not considered as a candidate to advertise to other BGP neighbors. A BGP
route is synchronized only if it has been first learned through an IGP or
static route.
In Cisco IOS Software, BGP advertises only what it
considers the best path to its neighbors. If an IBGP path is not synchronized,
it is not included in the best path calculation. The output of the
show ip bgp command will show unsynchronized routes in the
BGP table.
The solution would be to either turn off synchronization or make the
routes synchronized by redistributing them in the IGP at the router that first
introduced this route into the IBGP domain.