Problem: 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 a 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 exist, the most common of which are as follows :

• The IP routing table does not have a matching route.

• A configuration error has occurred.

• BGP is autosummarizing to a classful/network boundary.

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.

Figure 15-9 shows the flowchart to follow to fix this problem.

Figure 15-9. Problem-Resolution Flowchart

Debugs and Verification

This section assumes that there are no mistakes in BGP configuration.

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

Example 15-22 shows that BGP is configured to advertise 100.100.100.0/24 but fails to do so because the routing table does not contain an exact match for the prefix advertised.

Example 15-22 Routing Table Lacks the Exact Prefix That BGP Is Trying to Advertise

 router bgp 109  no synchronization  network 100.100.100.0 mask 255.255.255.0  neighbor 131.108.1.2 remote-as 109 R1#  show ip route 100.100.100.0  %  Network not in table  R1#  show ip bgp 100.100.100.0  % Network not in table 

BGP does not consider 100.100.100.0/24 as a candidate to advertise because its exact match does not exist in the IP routing table. The highlighted portion of Example 15-22 shows that the IP routing table does not have 100.100.100.0/24; therefore, BGP failed to create an entry even though it was properly configured.

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

This is another scenario in which BGP fails to originate an IP prefix, even with proper configuration. The BGP configuration is the same as the configuration in Example 15-22. Example 15-23 shows a mismatch between the prefix mask in the IP routing table entry and the BGP configuration.

Example 15-23 Mismatch Between Prefix Mask in IP Routing Table Entry and BGP Configuration

 R1#  show ip route 100.100.100.0  Routing entry for  100.100.100.0/23  Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks:   * directly connected, via Null0       Route metric is 0, traffic share count is 1 R1#  show ip bgp 100.100.100.0  % Network not in table 

Again, BGP does not consider 100.100.100.0/24 as a candidate to advertise. Although the route exists in the IP routing table, the mask differs . The IP routing table entry for 100.100.100.0 has a mask of /23, whereas BGP configuration has a mask of /24.

The advertised BGP route must appear in the BGP table of the originator router before receipt by BGP neighbors.

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.

To advertise 100.100.100.0/24, for example, a sample static route and corresponding BGP would look like Example 15-24.

Example 15-24 Static Route Configuration to Match BGP Advertisement

  ip route 100.100.100.0 255.255.255.0 null 0   router bgp 109  network 100.100.100.0 mask 255.255.255.0 

As Example 15-24 demonstrates , null 0 is used as a next hop of the static route. No traffic should ever follow this static route because it will be sent to the bit bucket. It is assumed that a more specific route of 100.100.100.0/24 exists in the IP routing table.

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.

Figure 15-10 shows the flowchart to follow to fix this problem.

Figure 15-10. Problem-Resolution Flowchart

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.

In Cisco IOS Software, BGP requires the configuration to have proper BGP syntax and commands to advertise any route to IBGP/EBGP neighbors.

Cases 1, 2, and 3 that follow show misconfiguration of BGP in advertising 100.100.100.0/24 in all methods .

Case 1: BGP Prefix Origination with the network Statement

Example 15-25 shows a misconfiguration in BGP to advertise 100.100.100.0/24 using the network statement.

Example 15-25 Improperly Configuring BGP to Advertise 100.100.100.0/24 Using the network Statement

  router bgp 109   no synchronization   network 100.100.100.0    mask 255.255.255.0    neighbor 131.108.1.2 remote-as 109  ip route 100.100.100.0  255.255.254.0  null 0 

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.

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

Example 15-26 shows the correct configuration of BGP to advertise 100.100.100.0/24, but this configuration fails to create an advertisement in BGP. 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.

Example 15-26 Configuring BGP to Advertise 100.100.100.0/24 Using the aggregate-address Statement

  router bgp 109   no synchronization   aggregate-address 100.100.100.0 255.255.255.0  neighbor 131.108.1.2 remote-as 109 

The configuration in Example 15-26 assumes that BGP already contains 100.100.100.0/24 or a higher mask in its table. The aggregate-address configuration will fail if this condition fails, resulting in the following output:

 R1#  show ip bgp 100.100.100.0  % Network not in table 

The output in Example 15-27 reveals that a more specific route of 100.100.100.0/24 exists as 100.100.100.128/25 in the BGP table.

Example 15-27 A More Specific BGP Routing Table Entry Exists

 R1#  show ip bgp 100.100.100.128 255.255.255.128  BGP routing table entry for  100.100.100.128/25  , version 4 Paths: (1 available, best #1)  Advertised to non peer-group peers:   172.16.126.2   Local     0.0.0.0 from 0.0.0.0 (172.21.53.142)      Origin IGP, metric 0, localpref 100, weight 32768, valid,sourced, local,  best 

The goal is to summarize all 100.100.100. x BGP advertisements into 100.100.100.0/24 and to advertise only this summarized route to BGP neighbors.

The configuration in Example 15-28 demonstrates how an aggregate address can be used to generate a summarized route of 100.100.100.0/24.

Example 15-28 Aggregate Address Creates a Summarized IP Prefix in BGP

 R1#  router bgp 109   network 100.100.100.128 mask 255.255.255.128   aggregate-address 100.100.100.0 255.255.255.0 summary-only  R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 3 Paths: (1 available, best #1)  Advertised to non peer-group peers: 172.16.126.2 Local, (  aggregated by 109  172.21.53.142) 0.0.0.0 from 0.0.0.0 (172.21.53.142) Origin IGP, localpref 100, weight 32768, valid,  aggregated  , local,        atomic-aggregate,best 

The highlighted portion shows that AS 109 is doing the aggregation of 100.100.100.0/24.

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.

Example 15-29 shows a sample OSPF redistribution example.

Example 15-29 OSPF Redistribution Example in BGP

  router bgp 109   no synchronization  redistribute ospf 100 metric 2 match internal external 1 external 2 

The redistribution commands in Example 15-29 redistributes into BGP any OSPF route in the IP routing table that is internal (OSPF intra- or interarea), or external (OSPF E1 and E2) to any route with a MED of 2.

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.

Typically, BGP operators create static routes for the network blocks that they intend to originate in BGP and use Case 1 or Case 2 to originate those routes.