Similar to neighbor adjacency establishment, route advertisement issues are commonly due to simple device misconfigurations. In Cisco IOS software, there are 3 (three) ways that can be used to advertise networks when using Border Gateway Protocol. These ways or methods include using the network [network] mask [mask] command, using the aggregate-addresscommand, and using the redistribute [protocol] command. The first two methods are discussed in this section; however, redistribution will be discussed in the following section. In addition, this section will also discuss route advertisement following BGP policy changes.
Route Advertisement with the network Command
The network [network] mask [mask] command is the recommended method for advertising networks when using BGP . When specified with BGP, the behavior of this command differs from when it is used with an IGP, such as OSPF or EIGRP. With an IGP, this command configures the router to install the network into the Link State Database or Topology Table and send out Hellos to discover neighbor routers. With BGP; however, command is used to flag the network as being local to the autonomous system as well as to instruct BGP to advertise the specified network. It does not configure the router to send out Hello packets out of any interfaces that fall within the specified range.
The specified network must be present in the routing table before it will be advertised by BGP. The [mask <mask>] keyword is optional and is required only when BGP is required to advertise either subnets or supernets. For example, to advertise the 10.0.0.0/30 subnet, themask would be required. Excluding the mask and simply entering the network 10.0.0.0command would not result in this subnet being advertised. However, the mask would not be required to advertise the 10.0.0.0/8 network, as long as there was a matching route for this prefix in the routing table. To further clarify this concept, consider the topology illustrated in Figure 7-2:
Fig. 7-2. Understanding the BGP network Command
Referencing Figure 7-2, an external BGP session has been configured between R3 and R3. We will assume that the correct configuration is in place on both routers allowing the session to successfully be established. R4 has a directly connected 10.4.4.0/24 subnet. This is to be advertised via BGP to R3. At this point, the relevant BGP configuration on R4 is as follows:
| R4#show running-config | section bgp router bgp 4 no synchronization bgp router-id 4.4.4.4 bgp log-neighbor-changes network 10.0.0.0 neighbor 3.3.3.3 remote-as 3 neighbor 3.3.3.3 ebgp-multihop 2 neighbor 3.3.3.3 update-source Loopback0 no auto-summary |
At first glance, the configuration appears correct because the 10.4.4.0/24 subnet is encompassed by the 10.0.0.0/8 Classful network as can be seen in the output of the routing table below:
| R4#show ip route 10.0.0.0 longer-prefixes Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2 E1 – OSPF external type 1, E2 – OSPF external type 2 i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2 ia – IS-IS inter area, * – candidate default, U – per-user static route o – ODR, P – periodic downloaded static routeGateway of last resort is not set 10.0.0.0/24 is subnetted, 1 subnets C 10.4.4.0 is directly connected, FastEthernet0/0 |
However, because the operation of the network command differs for BGP, the 10.4.4.0/24 subnet will not be added to the BGP RIB as illustrated in the following output:
| R4#show ip bgp 10.0.0.0 % Network not in table R4# R4#show ip bgpR4# |
In order to have BGP advertise the 10.4.4.0/24 subnet, the correct mask must be specified:
| R4(config)#router bgp 4 R4(config-router)#no network 10.0.0.0 R4(config-router)#network 10.4.4.0 mask 255.255.255.0 R4(config-router)#exit |
Following this re-configuration, the 10.4.4.0/24 subnet appears in the BGP RIB as follows:
| R4#show ip bgp BGP table version is 2, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 10.4.4.0/24 0.0.0.0 0 32768 i |
We can further validate that the prefix is advertised to neighbor 3.3.3.3 using either the show ip bgp [network] [mask] or the show ip bgp neighbors [address] advertised-routescommands. Following is the output of the show ip bgp [network] [mask]command on R4:
| R4#show ip bgp 10.4.4.0 255.255.255.0 BGP routing table entry for 10.4.4.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 Local 0.0.0.0 from 0.0.0.0 (4.4.4.4) Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best |
NOTE: To verify neighbors in update group 1, use the show ip bgp update-group command:
| R4#show ip bgp update-group 1 BGP version 4 update-group 1, external, Address Family: IPv4 Unicast BGP Update version : 2/0, messages 0 Update messages formatted 1, replicated 0 Number of NLRIs in the update sent: max 1, min 1 Minimum time between advertisement runs is 30 seconds Has 1 member (* indicates the members currently being sent updates): 3.3.3.3 |
Alternatively, simply use the show ip bgp neighbors [address] advertised-routes command as previously stated. Following is the output of this command on R4:
| R4#show ip bgp neighbors 3.3.3.3 advertised-routes BGP table version is 2, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 10.4.4.0/24 0.0.0.0 0 32768 iTotal number of prefixes 1 |
Route Advertisement with the aggregate-address Command
There are 2 common problem scenarios that are often encountered when using the aggregate-address command with BGP. The first is that BGP does not advertise the aggregate at all and the second is that BGP advertises the summary and more specific routes as well. In order to troubleshoot either issue, you must have a solid understanding of how route aggregation with BGP works. By default, when the aggregate-address command is used, BGP advertise the summary only if a more specific route encompassed by the summary is present in the routing table. Continuing from the topology illustrated in Figure 7-2, assume the following configuration was implemented on R4:
| R4(config)#router bgp 4 R4(config-router)#aggregate-address 10.0.0.0 255.0.0.0 R4(config-router)#end |
With this configuration, and assuming that the 10.4.4.0/24 subnet is still present in the RIB, BGP will generate and advertise the 10.0.0.0/8 summary address. This can be validated by checking the BGP RIB using the show ip bgp command as follows:
| R4#show ip bgp BGP table version is 3, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 10.0.0.0 0.0.0.0 32768 i *> 10.4.4.0/24 0.0.0.0 0 32768 i |
NOTE: You can view detailed information on the aggregate by appending the network and/or mask to the end of this command as follows:
| R4#show ip bgp 10.0.0.0 255.0.0.0 BGP routing table entry for 10.0.0.0/8, version 7 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 Local, (aggregated by 4 4.4.4.4) 0.0.0.0 from 0.0.0.0 (4.4.4.4) Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best |
In the event that all specific routes included in the aggregate are removed or withdrawn from the routing table, the aggregate will no longer be advertised. For example, if the 10.2.2.0/24 subnet was removed from the routing table by shutting down the FastEthernet0/0 interface on R4, then the aggregate would also be withdrawn and not be advertised.
| R4#debug ip bgp BGP debugging is on for address family: IPv4 Unicast R4#config t Enter configuration commands, one per line. End with CNTL/Z. R4(config)#interface fastethernet0/0 R4(config-if)#shutdown R4(config-if)# *Mar 12 20:45:16.455: BGP(0): Aggregate processing for IPv4 Unicast *Mar 12 20:45:16.455: BGP(0): For aggregate 10.0.0.0/8 *Mar 12 20:45:16.455: BGP(0): 10.0.0.0/8 subtree has an entry 10.0.0.0/8 *Mar 12 20:45:16.455: BGP(0): 10.0.0.0/8 subtree has another entry 10.4.4.0/24 *Mar 12 20:45:16.455: BGP(0): sub-prefix : 10.4.4.0/24Needs to be re-aggregated *Mar 12 20:45:16.455: BGP(0): 10.0.0.0/8 subtree has an entry 10.0.0.0/8 *Mar 12 20:45:16.455: BGP(0): 10.0.0.0/8 subtree has another entry 10.4.4.0/24 *Mar 12 20:45:16.459: BGP(0): 10.0.0.0/8 aggregate is removed *Mar 12 20:45:16.459: BGP(0): Aggregate 10.0.0.0/8 does not have more-specifics |
As previously stated, by default when summarization is configured, BGP will advertise both the summary as well as the more specific prefixes. Continuing with the previous aggregation configuration example, the 10.0.0.0/8 aggregate as well as the 10.2.2.0/24 subnet would be advertised by R4 to peer router R3. Again, this can be validated using the show ip bgp neighbors [address] advertised-routes command as follows:
| R4#show ip bgp neighbors 3.3.3.3 advertised-routes BGP table version is 15, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 10.0.0.0 0.0.0.0 32768 i *> 10.4.4.0/24 0.0.0.0 0 32768 iTotal number of prefixes 2 |
In order to suppress specific prefixes from being advertised, you must manually configure BGP to do so using by appending the summary-only keyword to the aggregate-addresscommand as illustrated in the following output:
| R4(config)#router bgp 4 R4(config-router)#aggregate-address 10.0.0.0 255.0.0.0 summary-only R4(config-router)#end |
Following this configuration, any specific prefixes encompassed by the aggregate are preceded by an ‘s’ indicating that they are being explicitly suppressed as follows:
| R4#show ip bgp BGP table version is 16, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 10.0.0.0 0.0.0.0 32768 i s> 10.4.4.0/24 0.0.0.0 0 32768 i |
Given this configuration, only the 10.0.0.0/8 aggregate is now advertised to R4:
| R4#show ip bgp neighbors 3.3.3.3 advertised-routes BGP table version is 16, local router ID is 4.4.4.4 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes: i – IGP, e – EGP, ? – incompleteNetwork Next Hop Metric LocPrf Weight Path *> 10.0.0.0 0.0.0.0 32768 iTotal number of prefixes 1 |
Route Advertisement Following BGP Policy Reconfiguration
Another common issue with BGP is route advertisement following policy reconfiguration or changes. BGP policies include filtering using tools such as route maps, ACLs and AS_PATH filters. As was stated earlier in this chapter, the BGP Scanner process periodically scans the BGP Routing Information Base (RIB) in order to determine if prefixes and attributes should be deleted and if route map or filter caches should be flushed.
Additionally, the BGP Scanner walks the BGP table and confirms reachability of the next hops, i.e. it validates that next hops are still valid. If the next hop for a prefix is not reachable, all BGP entries that use that next hop are removed from the BGP RIB. By default, the BGP Scanner runs every 60 seconds, which means that it could take up to a minute, or more depending on the number of prefixes and other factors such as resource utilization, for BGP policy changes to be detected and ultimately for networks to be advertised (or withdrawn).
If you have made changes to BGP policy configuration, e.g. route maps and you notice that the network or networks are not being advertised by BGP (assuming the configuration is correct), keep in mind that it may simply be that the BGP Scanner process has yet to incorporate the changes. Therefore, instead of waiting for the BGP Scanner process to run, use the clear ip bgpcommand to immediately apply the configuration changes. The complete syntax of this command is as follows:
clear ip bgp [* | all | <autonomous-system-number> | <address> | peer-group <name>] [in [prefix-filter] | out | slow | soft [in [prefix-filter] | out | slow]]
Table 7-1 lists and describes the keywords that can be used with this command:
| Keyword | Function |
|---|---|
| * | The asterisk (*) resets all BGP peers, i.e. it tears down and resets all BGP sessions. This should be used with extreme caution |
| all | This optional keyword specifies the reset of all address family (AF) sessions, e.g. the ipv4 (IPv4 AF) and ipv6 (IPv6 AF) |
| autonomous-system-number | This specifies the number of the autonomous system in which all BGP peer sessions will be reset |
| address | This specifies that only the identified BGP neighbor will be reset. The value for this argument can either be an IPv4 or IPv6 address |
| peer-group <name> | This specifies that only the identified BGP peer group will be reset. |
| in | This optional initiates inbound reconfiguration. If neither the in nor outkeywords are specified, both inbound and outbound sessions are reset |
| prefix-filter | This optional keyword clears the existing outbound route filter (ORF) prefix list to trigger a new route refresh or soft reconfiguration, which updates the ORF prefix list |
| out | This optional keyword initiates outbound reconfiguration. If neither the in norout keywords are specified, both inbound and outbound sessions are reset |
| slow | This optional keyword clears slow-peer status forcefully and moves it to original update group |
| soft | This optional keyword initiates a soft reset. In other words, using this keyword does not tear down the BGP session |