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.
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.
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.
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.
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
R1# router bgp 109 no synchronization redistribute static neighbor 131.108.1.2 remote-as 109 ip route 100.100.100.0 255.255.255.0 Null0 ip route 131.108.5.0 255.255.255.0 Null0 R1#show ip bgp 100.100.100.0 BGP routing table entry for 100.0.0.0/8, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 131.108.1.2 Local 0.0.0.0 from 0.0.0.0 (1.1.1.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best R1-2503#show ip bgp 131.108.5.0 BGP routing table entry for 131.108.0.0 /16, version 3 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 131.108.1.2 Local 0.0.0.0 from 0.0.0.0 (1.1.1.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
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
R1# router bgp 109 no synchronization redistribute static no auto-summary R1# show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 4 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208 Advertised to non peer-group peers: 131.108.1.2 Local 0.0.0.0 from 0.0.0.0 (1.1.1.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best R1# show ip bgp 131.108.5.0 BGP routing table entry for 131.108.5.0/24, version 6 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208 Advertised to non peer-group peers: 131.108.1.2 Local 0.0.0.0 from 0.0.0.0 (1.1.1.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
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.
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
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. For example, in the following access list, 100.100.100.0 could have any mask—/24, /26, and so on:
access-list 1 permit 100.100.100.0 In the following access list, on the other hand, the mask of 100.100.100.0 must be /24 and nothing else: access-list 101 permit ip host 100.100.100.0 host 255.255.255.0
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.
Figure 15-14 shows the flowchart to follow to fix this problem.
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
R8# router bgp 109 no synchronization network 100.100.100.0 mask 255.255.255.0 neighbor 206.56.89.2 remote-as 109 ip route 100.100.100.0 255.255.255.0 Null0 _____________________________________________________________________________________ R1# router bgp 109 no synchronization neighbor 131.108.1.2 remote-as 109 neighbor 206.56.89.1 remote-as 109 _____________________________________________________________________________________ R2# router bgp 109 no synchronization neighbor 131.108.1.1 remote-as 109
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
R8#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 3 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 206.56.89.2 Local 0.0.0.0 from 0.0.0.0 (8.8.8.8) Origin IGP,metric 0,localpref 100,weight 32768,valid,sourced,local,best _____________________________________________________________________________________ R1#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 9 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer Local 206.56.89.1 from 206.56.89.1 (8.8.8.8) Origin IGP, metric 0, localpref 100, valid, internal, best _____________________________________________________________________________________ R1#show ip bgp summary BGP router identifier 1.1.1.1, local AS number 109 BGP table version is 11, main routing table version 11 1 network entries and 1 paths using 133 bytes of memory 1 BGP path attribute entries using 52 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP activity 24/237 prefixes, 35/34 paths, scan interval 15 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 131.108.1.2 4 109 4304 4319 11 0 0 1d20h 0 206.56.89.1 4 109 108 110 11 0 0 01:44:16 1 _____________________________________________________________________________________ R2#show ip bgp 100.100.100.0 % Network not in table
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.
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
R1# router bgp 109 no synchronization neighbor 131.108.1.2 remote-as 109 neighbor 131.108.1.2 route-reflector-client neighbor 206.56.89.1 remote-as 109 neighbor 206.56.89.1 route-reflector-client
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
R1#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 13 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208 Advertised to non peer-group peers: 131.108.1.2 Local, (Received from a RR-client) 206.56.89.1 from 206.56.89.1 (8.8.8.8) Origin IGP, metric 0, localpref 100, valid, internal, best _____________________________________________________________________________________ R2#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 35 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208 Not advertised to any peer Local 206.56.89.1 from 131.108.1.1 (8.8.8.8) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 8.8.8.8, Cluster list: 1.1.1.1
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.
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
R8# router bgp 65201 bgp confederation identifier 109 bgp confederation peers 65200 65201 network 100.100.100.0 mask 255.255.255.0 neighbor 206.56.89.2 remote-as 65200 ip route 100.100.100.0 255.255.255.0 Null0 _____________________________________________________________________________________ R1# router bgp 65200 bgp confederation identifier 109 bgp confederation peers 65201 65200 neighbor 131.108.1.2 remote-as 6520 neighbor 206.56.89.1 remote-as 65201 _____________________________________________________________________________________ R2# router bgp 65200 no synchronization bgp confederation identifier 109 bgp confederation peers 65200 65201 neighbor 131.108.1.1 remote-as 65200
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#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 206.56.89.2 Local 0.0.0.0 from 0.0.0.0 (8.8.8.8) Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local,best _____________________________________________________________________________________ R1#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 131.108.1.2 (65201) 206.56.89.1 from 206.56.89.1 (8.8.8.8) Origin IGP, metric 0, localpref 100, valid, confed-external, best _____________________________________________________________________________________ R2#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208 Not advertised to any peer (65201) 206.56.89.1 from 131.108.1.1 (1.1.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best
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.
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
R2#show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version Paths: (1 available, no best path) Flag: 0x208 Not advertised to any peer (65201) 206.56.89.1 from 131.108.1.1 (1.1.1.1) Origin IGP, metric 0, localpref 100, valid, internal, not synchronized
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.