Troubleshooting BGP Route Advertisement /Origination and Receiving

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.

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. This section addresses a mix of simple and complicated problems seen in BGP route advertisement/origination and receiving.

The following is a list of problems discussed in this section related to BGP route originating and advertisement:

  • 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

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.

Troubleshooting BGP Route Advertisement Origination and Receiving fig 15.9

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

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

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

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.

Troubleshooting BGP Route Advertisement Origination and Receiving fig 15.10

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

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

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:

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

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

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

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.

BGP Route Not Getting Originated—Cause: BGP Is Autosummarizing to Classful/Network Boundary

Sometimes, classful networks are advertised in BGP when other routing protocols are redistributed in BGP. For example, BGP might be trying to redistribute 100.100.100.0/24, but only 100.0.0.0/8 gets advertised. Another example could be that 131.108.0.0/16 is advertised where 131.108.5.0/24 was redistributed.

BGP autosummarizes subnetted routes to their network boundaries when redistributed into BGP from any other routing protocol. For example, subnetted Class A routes automatically are summarized to the Class A mask /8 when redistributed in BGP from any other protocol.

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

Troubleshooting BGP Route Advertisement Origination and Receiving fig 15.11

Debugs and Verification
Example 15-30 shows an example in which R1 has a static route for 100.100.100.0/24 and 131.108.5.0/24. Notice that these are subnetted Class A and B routes, respectively.

When these static routes are redistributed in BGP, BGP autosummarizes them to their natural class masks, which are /8 and /16 respectively.

Example 15-30 shows the relative configuration in R1 to redistribute these static routes in BGP; it also displays the BGP table output for these advertisements.

Example 15-30 Configuring Redistribution of Static Routes in BGP

Note the mask in the output. /24 static routes are summarized to the network boundary of Class A and Class B, respectively.

Solution
IP prefixes need to be advertised with their original masks. One exception is when manual summarization is done. The problem of BGP advertising classful networks after redistribution can be overcome by disabling the autosummarization feature in BGP.

Example 15-31 shows the necessary configuration to achieve this; it also shows the BGP advertisement in the BGP table after this change.

Example 15-31 Disabling Autosummarization in BGP

Note the masks in the output—they are exactly what there were configured originally.

In most cases, it would be desirable to turn off autosummarization so that proper mask routes can be advertised to BGP neighbors. Autosummarization plays a role only when any other protocol routes are redistributed into BGP. Because it is not common practice to redistribute other protocols into BGP, the autosummarization feature is not used much.

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.

When implementing BGP in Cisco IOS Software, operators have many options to configure filters to control which routes to propagate to which neighbors. These filters could be fairly straightforward or could get very complex. Minor errors can result in undesirable route denial or advertisement to BGP speakers.

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

Troubleshooting BGP Route Advertisement Origination and Receiving fig 15.12

Debugs and Verification
Chapter 14 discusses using filters in BGP. Discussing every single filter is outside the scope of this book; however, some of most commonly seen real-world filtering mistakes and misconceptions are discussed.

Using a distribute list allows for standard access lists (1 to 99) and extended access lists (100 to 199). Example 15-32 gives a sample configuration of both.

Example 15-32 Sample Distribute List Configuration Using Standard and Extended Access Lists

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. For example, in the following access list, 100.100.100.0 could have any mask—/24, /26, and so on:

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.

It is beyond the scope of this book to go over each filtering method that Cisco offers, but refer to the section, “Troubleshooting BGP Filtering.”

Solution
As discussed in Chapter 14, 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.

Problem in Propagating BGP Route to IBGP Neighbor but Not to EBGP Neighbor—Cause: BGP Route Was from Another IBGP Speaker
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, as illustrated in Figure 15-13. Chapter 14 explains using route reflectors and confederations. You also can find information on this topic in the “Troubleshooting BGP When Route Reflectors Are Used” section, later in this chapter.

Troubleshooting BGP Route Advertisement Origination and Receiving fig 15.13

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

Troubleshooting BGP Route Advertisement Origination and Receiving fig 15.14

Debugs and Verification
Example 15-33 shows the necessary configuration to have an IBGP relationship between R8 to R1 and R1 to R2. This example also shows a sample configuration of R8 advertising 100.100.100.0/24 to R1.

Example 15-33 Configuring an IBGP Relationship Between R8/R1 and R1/R2

Example 15-33 shows that the IBGP network is not fully meshed and that the IBGP-learned route will not be given to any other IBGP neighbor.

Example 15-34 shows BGP table output from R8, R1, and R2, respectively. R8 is adver-tising 100.100.100.0/24, which shows up in its BGP table and in R1’s table. In the output of R1, notice the highlighted output “Not advertised to any peer.” Although R1 and R2 are IBGP neighbors, R1 does not advertise 100.100.100.0/24 to R2 and it is learned from another IBGP neighbor, R8.

Example 15-34 R8, R1, and R2 BGP Tables Show That an IBGP-Learned Route in R1 Will Not Be Given to IBGP Neighbor R2

In the output of R1, “Not advertised to any peer” means that even though R2 is the neighbor, it is an IBGP neighbor and 100.100.100.0/24 will not be advertised. This rule comes from RFC 1771 section 9.2.1, titled “Internal Updates”:

When a BGP speaker receives an UPDATE message from another BGP speaker located in its own autonomous system, the receiving BGP speaker shall not re-distribute the routing information contained in that UPDATE message to other BGP speakers located in its own autonomous system.

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.

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. Therefore, savvy BGP operators typically do not choose this method. Chapter 14 explains this is greater detail.

Designing a Route-Reflector Model

RFC 1966 discusses a model to avoid IBGP full mesh by introducing the concept of route-reflector servers and route-reflector clients.

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. In Figure 15-15, R1 act as the server and R8 and R2 act as clients. R1, R2, and R8 form a cluster. Refer to Chapter 14 to undersatnd Route-Reflection in detail.

Troubleshooting BGP Route Advertisement Origination and Receiving fig 15.15

shows the relevant configuration to make R1 the route-reflector. Route-reflector clients need no additional configuration other than what is already shown in Example 15-33.

Example 15-35 Configuring R1 as the Route Reflector and R2 and R8 as Route-Reflector Clients

The output in Example 15-36 shows that R1 receives 100.100.100.0/24 from R8 and advertises to R2 (131.108.1.2). Notice that this was not the case in the original problem in Figure 15-13. Example 15-36 also shows that R2 receives 100.100.100.0/24 from R1.

Example 15-36 BGP Table Output to Display How Route Reflectors Solved the IBGP Update Failure Problem

The highlighted section in R1’s output shows that it is advertising 100.100.100.0/24 to R2, its IBGP neighbor, which was not the case in Example 15-34.

Designing 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. Refer to Chapter 14 to understand Confederation in detail.

Figure 15-16 shows that R1 and R2 are combined in a sub-AS and that R8 is in its own sub-AS.

Troubleshooting BGP Route Advertisement Origination and Receiving fig 15.16

highlights all the changes in the configuration of Routers R1, R2, and R8.

Example 15-37 Configuring the Network of R1, R2, and R8 as a Confederation Model

Example 15-37 shows a significant change in BGP configuration of Routers R1, R2, and R8. When a BGP network migrates to a confederation, all routers need configuration changes. In Example 15-37, confederation identifier represents that real AS of the net-work; the confederation peers command lists the peering confederation sub-AS in the BGP network. The confederation sub-AS is configured with the router bgp command. All BGP updates sent to other confederations are sent with a confederation sub-AS list similar to the AS_PATH list, but updates to EBGP neighbors are sent with the real AS number. A prefix received from the outside confederation sub-AS is advertised to all confederation neighbors, internal or external, resulting in prefix propagation—this was not possible in partially meshed IBGP. To the outside world, a confederation has no value because it is a technique used locally in the BGP network to reduce an IBGP mesh.

Example 15-38 shows the output of the BGP table from each router.

Example 15-38 BGP Tables from the Routers in a BGP Confederation

R8 is advertising 100.100.100.0/24 to R1. In R1’s output, the highlighted line shows the confederation sub-AS, 65201, that 100.100.100.0/24 update has traversed. This is the sub-AS that has R8 in it. R1 advertises this update to R2 because this update came from another confederation sub-AS. This setup sidesteps the need for a full mesh of R1, R2, and R8, which otherwise was needed to propagate 100.100.100.0/24 from R8 to R2.

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. As you remember from previous discussions in Chapter 14, a BGP route is synchronized only if it has been learned through an IGP or a static route first.

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.

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

Troubleshooting BGP Route Advertisement Origination and Receiving fig 15.17

Debugs and Verification
Refer back to Chapter 14 for details about the rules for synchronization.

Example 15-39 shows how an unsynchronized route would appear in BGP table.

Example 15-39 BGP Table with Unsynchronized Route

The highlighted output in Example 15-39 shows that R2 did not consider 100.100.100.0/24 as synchronized and failed to install it in the routing table; therefore, it did not advertise the route to any peer.

Solution
As discussed in Chapter 14, 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. The following selection has an example to accomplish this.

About the author

Prasanna

Leave a Comment