Reasons that route advertisement fails between BGP peers are as follows:
- Next-Hop Check Failure
- Bad Network Design
- Validity Check Failure
- BGP Communities
- Route filtering
Most of these issues can be found by using the following:
- BGP Loc-RIB: Just because a route is missing from the Global RIB, it does not mean the route did not make it into the router’s BGP table.
- Examine the BGP Loc-RIB to see if the prefix exists in the BGP table. It is possible that the route installed in the BGP table but did not install into the RIB. Viewing the local BGP table is the first step in troubleshooting any missing route.
- show bgp afi safi
- BGP Adj-RIB-in: The BGP Loc-RIB table contains only valid routes that passed the router’s inbound route policies.
- Examining the BGP Adj-RIB-in table verifies whether the peer received the NLRI. If the peer received it, the local inbound route policy prevents the route from installing into the Loc-RIB table.
- Inbound Soft Configuration is required to view the BGP Adj-RIB-in table, because the table is purged by default after all inbound route-policy processing has occurred.
- BGP Adj-RIB-out: Viewing the BGP Adj-RIB-out table on the advertising router verifies that the route was advertised and provides a list of the BGP PAs that were included with the route.
- In the event that the route is not present in the advertising router’s BGP Adj-RIB-out table, check the advertising router’s BGP Loc-RIB table to verify the prefix exists there.
- Assuming the prefix is in the Loc-RIB table, but not in the Adj-RIB-out table, then the outbound route policies are preventing the advertisement of the route.
- Contents of the BGP Adj-RIB-out are viewed with the command show bgp afi safi neighbor-ip-address [prefix/prefix-length] advertised-routes.
- Viewing BGP Neighbor Sessions: The information contained in the BGP neighbor session varies from platform to platform, but still provides a lot of useful information, such as the number of prefixes advertised, session and address-family options, the route maps/route filters/route policy applied specifically for that neighbor. The BGP neighbor session is displayed with the command show bgp afi safi neighbor ip-address.
- Debug Commands: Debug commands provide the most amount of information about BGP.
- On IOS nodes, BGP update debugs are enabled with the command debug bgp afi safi updates [in | out] [detail].
- On IOS XR nodes, BGP update debugs are enabled with the command debug bgp update [afi afi safi] [in | out].
- On NX-OS nodes, BGP update debugs are enabled with the command debug bgp updates [in | out].
This topology is used to demonstrate how to troubleshoot the various reasons a route could be missing from the routing table.
- R1 is advertising the 10.0.0.0/8 aggregate prefix.
- R1 is advertising the 10.1.1.0/24 prefix.
- R2 is advertising the 10.2.2.0/24 prefix.
Next-Hop Check Failures
- R3 is missing the 10.0.0.0/8 network and the 10.1.1.0/24 network from the RIB.
- Both of the missing routes are advertised from R1.
The first step is to check the R3’s Loc-RIB BGP table. The 10.0.0.0/8 network and the 10.1.1.0/24 network are present, but notice that both entries are missing the best path marker >.
Displaying an explicit network prefix with the command show bgp afi safi prefix/prefix-length, provides some clarity for why the NLRI was not selected as a best path.
In the output, the next-hop 10.1.12.1 is inaccessible. Let’s verify that the next-hop exists on the router with the command show ip route next-hop-IP-address.
The next-hop IP address is not available in the RIB. There are multiple solutions to this issue that include the following:
- R2 advertises the peering link (10.1.12.0/24) into BGP.
- R3 is adjacent to R2 and receives the route with a next-hop of 10.1.23.2, which is in R3’s RIB as a directly connected route. The 10.1.12.1 next-hop IP address would then be resolvable through a recursive lookup.
- Establish an IGP routing protocol within AS200 (R2, R3, and R4) and advertise the peering link (R1–R2) in OSPF, but make the peering link interface passive in OSPF.
- On R2 configure the next-hop-self feature in the address-family for the BGP peering with R3.
- All EBGP routes (that is, routes learned from R1) would then use R2 as their next-hop for any routes learned from R2.
Validity Check Failure
BGP performs a validity check upon receipt of prefixes. Specifically, BGP is looking for indicators of a loop, such as:
- Identifying the router’s ASN in the AS-Path
- Identifying the router’s RID in as the Route-Originator ID
- Identifying the router’s RID as the Cluster ID
The AS-Path (BGP attribute AS_PATH) is used as a loop prevention mechanism. The AS-Path is not prepended as a NLRI is advertised to other IBGP peers. Some common scenarios for a router to identify its ASN in an NLRI’s AS-Path are as follows:
- AS-Prepending: Industry standards dictate that the AS being prepended should be owned by your organization. However, some organizations may prepend a route with an ASN that they do not own. This is done for malicious purposes or unintentionally.
- Route Aggregation: Default behavior for route aggregation is to not include any BGP attributes of the smaller routes that are being aggregated, which adds the atomic aggregate BGP attribute. The loss of path visibility could result in route feedback when an organization advertises an aggregate route that includes a smaller network that is advertised from your network. If the as-set keyword is used with the aggregation command, all the BGP attributes of the routes being summarized are included. This includes the AS-Path.
After configuring the as-set keyword on R1, R1 includes the PAs from the smaller aggregate routes. For example, the 10.2.2.0/24 network that is being learned on R1 from AS200 would be aggregated into the 10.0.0.0/8 aggregate with the AS200 as part of the AS-Path.
Detecting a router’s ASN in a route that is received from a peer can be accomplished by the following:
- Viewing the BGP session on IOS routers.
- Viewing the network routes that are advertised to the router.
- Enabling debugging for BGP updates, which will indicate the AS-Path loop.
R2 displays the BGP neighbor session details for R1. After examining the IPv4 address-family, routes were denied for an AS_PATH loop. It is important to note that the count of routes is a cumulative count of route advertisements throughout the life of that BGP session.
The second method is to list the routes on R1 that were advertised to R2 that include the ASN of R2 (200). The 10.0.0.0/8 route includes the AS-Path of 200.
The third method is to enable BGP debugging on R2 and initiate an inbound BGP soft-refresh.
Another potential reason a NLRI fails the validity check is if the Originator-ID or Cluster-ID matches the receiving router’s RID. The Originator-ID is populated by a route-reflector (RR) with the advertising router’s RID, and the Cluster-ID is populated by the RR. The default Cluster-ID setting is the RR’s RID, unless it is specifically set, which is done for certain design scenarios. Checking the Originator-ID or Cluster-ID is considered a loop prevention mechanism.
Assume that in the sample topology, that R4’s BGP RID was configured to 192.168.2.2, which unknowingly matches R2’s BGP RID.