router is the originator of the route. The three columns to the left of the Path column list three BGP path attributes that are associated with the path: metric (multi-exit discriminator [MED]), local preference, and weight. The column with the Path header may contain a sequence of autonomous systems in the path. From left to right, the first autonomous system listed is the adjacent autonomous system that this network was learned from. The last number (the rightmost autonomous system number) is the originating autonomous system of this network. The autonomous system numbers between these two represent the exact path that a packet takes back to the originating autonomous system. If the path column is blank, the route is from the current autonomous system. The last column signifies how this route was entered into BGP on the original router. If the last column contains an “i”, the originating router probably used a network statement to introduce this network into BGP. If the character is an “e,” the originating router learned this network from EGP, which is the historical predecessor to BGP. A question mark (?) signifies that BGP cannot absolutely verify the availability of this network because it is redistributed from an IGP into BGP. Use the show ip bgp rib-failure command to display BGP routes that were not installed in the RIB and the reason that they were not installed. The example in Figure shows that the displayed routes were not installed because a route or routes with a better administrative distance already exist in the RIB.
Content 6.4 Advanced BGP Configuration and Verification 6.4.9 Clearing the BGP Session BGP can potentially handle huge volumes of routing information. When a policy configuration change occurs, the router cannot go through the huge table of BGP information and recalculate which entry is no longer valid in the local table. Nor can the router determine which routes should be withdrawn from a neighbor. There is an obvious risk that the first configuration change will be immediately followed by a second, which would cause the whole process to start all over again. To avoid such a problem, Cisco IOS software applies changes only to those updates that are received or transmitted after the BGP policy configuration change has been performed. The new policy, enforced by the new filters, is applied only on routes that are received or sent after the change. A network administrator who would like the policy change to be applied to all routes, must trigger an update to force the router to let all routes pass through the new filter. If the filter is applied on outgoing information, the router has to resend the BGP table through the new filter. If the filter is applied on incoming information, the router needs its neighbor to resend its BGP table so that it passes through the new filters. There are three ways to trigger an update: with a hard reset, soft reset, or route refresh.
Content 6.4 Advanced BGP Configuration and Verification 6.4.10 Hard Reset of BGP Sessions Resetting a session is a method of informing neighbors of a policy change. If BGP sessions are reset, all information received on those sessions is invalidated and removed from the BGP table. Also, the remote neighbor detects a BGP session down state and invalidates the routes that were received. After 30 to 60 seconds, the BGP sessions are reestablished automatically, and the BGP table is exchanged again but through the new filters. However, resetting the BGP session disrupts packet forwarding. The two commands shown in Figure both cause a hard reset of the BGP neighbors that are involved. A hard reset means that the router issuing either of these commands closes the appropriate TCP connections, reestablishes those TCP sessions as appropriate, and resends all information to each of the neighbors affected by the particular command that is used. The clear ip bgp * command causes the BGP forwarding table on the router that issued this command to be completely deleted, and all networks must be relearned from every neighbor. If a router has multiple neighbors, this action is a very dramatic event. This command forces all neighbors to resend their entire tables simultaneously. You should use this command with extreme caution, and it is not normally used in a production environment. For example, consider a situation in which router A has eight neighbors, and each neighbor has a full Internet table of about 32 MB in size. If router A issues the clear ip bgp * command, all eight routers resend their 32 MB tables at the same time. To hold all these updates, router A would need 256 MB of RAM, and would also need to be able to process all of this information. Processing 256 MB of updates would take a considerable number of CPU cycles, further delaying the routing of user data. If the clear ip bgp [neighbor-address] command is used instead, one neighbor is reset at a time. The impact is less severe on the router that is issuing this command. However, it takes longer to change policy for all the neighbors, because each must be done individually rather than all at once as with the clear ip bgp * command. The clear ip bgp [neighbor-address] command still performs a hard reset and must reestablish the TCP session with the specified address, but it affects only a single neighbor at a time.
Content 6.4 Advanced BGP Configuration and Verification 6.4.11 Soft Reset of BGP Sessions The clear ip bgp soft out command causes BGP to do a soft reset for outbound updates. The router issuing the command does not reset the BGP session. Instead, the router creates a new update and sends the entire table to the specified neighbors. This update includes withdrawal commands for the networks that the other neighbor will no longer see based on the new outbound policy. Note
The soft keyword is optional; clear ip bgp out does a soft reset for outbound updates. There are two ways to perform an inbound soft reconfiguration: Enter the neighbor command to inform BGP to save all updates that were learned from the neighbor specified. The BGP router retains an unfiltered table of what that neighbor has sent. When the inbound policy is changed, use the clear ip bgp command. The stored unfiltered table generates new inbound updates, and the results are placed in the BGP forwarding database. Thus, if you make changes, you do not have to force the other side to resend everything. Cisco IOS Software Release 12.0(2)S and 12.0(6)T introduced a BGP soft reset enhancement feature, also known as route refresh, that provides automatic support for dynamic soft reset of inbound BGP routing table updates, and is not dependent upon stored routing table update information. The clear ip bgp soft in command implements this feature. This method requires no preconfiguration and needs significantly less memory than the previous soft method for inbound routing table updates. Note
The clear ip bgp soft command performs a soft reconfiguration of both inbound and outbound updates. The soft in option generates new inbound updates without resetting the BGP session, but it can be memory-intensive. BGP does not allow a router to force another BGP speaker to resend its entire table. If you change the inbound BGP policy and you do not want to complete a hard reset, configure the router to perform a soft reconfiguration. Note
To determine whether a BGP router supports this route refresh capability, use the show ip bgp neighbors command. The following message is displayed in the output if the router supports the route refresh capability: Received route refresh capability from peer. If all BGP routers support route refresh, use the clear ip bgp {* | address | peer-group-name} in command. You do not have to use the soft keyword, because soft reset is