notes: Troubleshooting BGP Route Advertisement /Origination and Receiving

Another common problem after neighbor relationship issues 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.

1.  Problem: BGP Route Not Getting Originated
 

1.a  BGP Route Not Getting Originated—Cause: IP Routing Table Does Not Have a Matching Route

BGP requires the IP routing table to have an exact matching entry for the prefix that BGP is trying to advertise using network and redistribute command. 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 configuration. BGP will fail to originate any prefix related to this network if this discrepancy exists.

debugs and verification:

Case 1: Matching Route Does Not Exist in the Routing Table

show ip route a.b.c.d

show ip bgp a.b.c.d

Case 2: Route Exists in the IP Routing Table but Masks Differ from What Is in the IP Routing Table and What Is in the BGP Configuration

Solution:

Identical advertising BGP routes must exist in the IP routing table when network and redistribute commands are used. The IP routing table learns such routes either dynam-ically through a routing protocol or by a static route.

Commonly, BGP operators define a static route for the prefix being advertised. This way, the IP routing table is guaranteed to have a valid IP routing table entry of the advertised prefix.

ip route 100.100.100.0 255.255.255.0 null 0  

note: be carefull of using a null route, null route is used just to have an exact match, It is assumed that a more specific route of 100.100.100.0/24 exists in the IP routing table.

1.b.  BGP Route Not Getting Originated—Cause: Configuration Error

Configuration mistakes often cause BGP failure to advertise IP prefixes. Multiple ways to originate IP prefixes in BGP exist, and each method requires strict syntax in configuration. Therefore, it is essential that BGP operators thoroughly understand Cisco IOS Software configuration guidelines.

 Debugs and verification:

Three ways exist to originate prefixes in BGP:

  - Use a network statement.

  - Use an aggregate statement.

  - Redistribute other protocol/static routes in BGP

Case 1: BGP Prefix Origination with the network Statement

-  an exact match does not exist in the routing table.

Case 2: BGP Prefix Origination with the aggregate-address Command

- The explanation behind this failure is that the aggregate-address configuration requires the BGP table to contain at least one route that is more specific than the aggregate.

Case 3: BGP Prefix Origination by Redistributing Dynamic Protocols or Static Routes

- You can configure BGP to redistribute any dynamic routing protocol, such as OSPF, or static routes to originate any route. Cisco IOS Software strictly checks such a configuration and expects configuration guidelines to be met for the advertisement of any redistributed route.

solution:

All three methods commonly are used, but Cases 1 and 2 offer the most stability in BGP advertisement. Case 3 requires redistribution of an IP routing table learned by some other IGP protocol or static routes in BGP. Any flapping in IGP or static routes results in BGP churn.

2.  Problem in Propagating/Originating BGP Route to IBGP/EBGP Neighbors—Cause: Misconfigured Filters
 

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 filters are the cause of the problem.

Debugs and Verifications:

Using a distribute list allows for standard access lists (1 to 99) and extended access lists (100 to 199). 

R1# access-list 1 permit 100.100.100.0  

router bgp 109  

no synchronization  

neighbor 131.108.1.2 remote-as 109  

neighbor 131.108.1.2 distribute-list 1 out 

R1# access-list 101 permit ip host 100.100.100.0 host 255.255.255.0 

router bgp 109  

no synchronization  

neighbor 131.108.1.2 remote-as 109 

neighbor 131.108.1.2 distribute-list 101 out 

One common mistake that operators make is not realizing that there is an implicit deny at the end of each access list. All networks are denied except for those that are explicitly permitted in the access list. Also, standard and extended access lists are treated differently when it comes to BGP filters. In standard access lists, the mask portion is not checked and only the prefix portion is checked.

Similarly, when other methods are applied to filter BGP updates—namely, filter lists, prefix lists, route maps, distribute lists, and so on—care must be taken to understand the behavior of each method.

Solution:  

there are several other ways to filter BGP updates, and care must be taken in terms of what exactly is configured. Each kind of filter offers the power to control the BGP advertisement, but improper or incorrect use can result in incorrect or incomplete advertisements.

3.  Problem in Propagating BGP Route to IBGP Neighbor but Not to EBGP Neighbor—Cause: BGP Route Was from Another IBGP Speaker

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

debugs and verification:

show ip bgp a.b.c.d

Solution:

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.

a.  Use IBGP full mesh

Having an IBGP full mesh is unacceptable even in a small ISP network.

For larger ISPs that maintain several hundred BGP speakers, IBGP full mesh would harm them more than providing benefit. 

b.   Design a route-reflector model.

Servers peer BGP with all clients in the cluster. A cluster is a set of servers and clients. Clients peer BGP only with servers. Clients advertise BGP updates to servers, and servers then reflect them to other clients.  

c.  Design a confederation model.

RFC 1965 explains how an AS confederation for BGP can avoid full IBGP mesh. With confederations, the BGP network is divided into small sub–autonomous systems. These sub–autonomous systems are connected to other sub–autonomous systems. These sub–autonomous systems need not be fully meshed. BGP speakers within a sub–autonomous system must have a full mesh of IBGP. If the number of sub–autonomous systems grows to a large number of IBGP speakers, sub–autonomous system IBGP speakers use route reflectors. All routers take a configuration change when moved from an IBGP model to a confederation model.

4.  Problem in Propagating IBGP Route to IBGP/EBGP Neighbor—Cause: IBGP Route Was Not Synchronized

A scenario might arise in which an IBGP learned route is not propagated to any BGP neighbor, whether IBGP or EBGP. 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.

verification:

show ip bgp a.b.c.d  -- in the output shows not synchronized.

Solution:

either turn off synchronization or make the routes synchronized by redistributing them in the IGP at the router that first introduced this route in IBGP domain.