Content

| 5.9 |  | Troubleshooting BGP |
| 5.9.2 |  | Troubleshooting BGP route advertisements |

Another common problem that BGP operators face occurs in BGP route advertisement/origination and receiving. BGP originates routes only by configuration. However, it needs no configuration in receiving routes.

Larger ISPs originate new BGP routes for their customers on a daily basis, whereas small-enterprise BGP networks mostly configure BGP route origination upon first setup. Problems in route originating can occur because of either configuration mistakes or a lack of BGP protocol understanding.

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:

1. Use IBGP full mesh.
2. Design a route-reflector model.
3. 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.