update-source, next-hop-self, and distribute-list 20 out commands are all linked to peer group internal, which in turn is linked to each of the IBGP neighbors. If router C receives a change from AS 65101, it creates a single update and processes it through distribute list 20 once, which saves processing time. The update is replicated for each neighbor that is part of the internal peer group. Thus, the use of peer groups can improve efficiency when processing updates for BGP neighbors that have a common outbound BGP policy. Adding a new neighbor to router C using a peer group with the same policies of the other IBGP neighbors requires adding only a single neighbor statement to link the new neighbor to the peer group internal. Adding that same neighbor to router C without a peer group requires four neighbor statements. Using a peer group also makes the configuration easier to read and change when necessary. If you need to add a new policy, such as a route map, to all IBGP neighbors on router C using a peer group, you only need to link the route map to peer group internal. For router C without a peer group, you need to add the new policy to each neighbor.

Content 6.4 Advanced BGP Configuration and Verification 6.4.6 BGP Peering The show ip bgp summary command is one way to verify the neighbor relationship. Figure presents the output from this command, which contains the following:

BGP router ID: IP address that all other BGP speakers recognize as representing this router.
BGP table version: Increases in increments when the BGP table changes.
Main routing table version: Last version of the BGP database that was injected into the main routing table.
Neighbor: IP address that is used in the neighbor statement with which this router has a relationship.
Version (V): Version of BGP that this router is running with the listed neighbor.
AS: Autonomous system number of the listed neighbor.
Messages received (MsgRcvd): Number of BGP messages that have been received from this neighbor.
Messages sent (MsgSent): Number of BGP messages sent to this neighbor.
Table version (TblVer): BGP table version.
In queue (InQ): Number of messages waiting to be processed from this neighbor.
Out queue (OutQ): Number of messages queued and waiting to be sent to this neighbor. TCP flow control prevents this router from overwhelming a neighbor with a large update.
Up/Down: Length of time that this neighbor has been in the current BGP state (established, active, or idle).
State (established, active, idle, open sent, open confirm, or idle [admin]): BGP state. You can set a neighbor to administratively shut down (admin state) by using the neighbor shutdown router configuration command.
Prefix received (PfxRcd): When the session is in the established state, this value represents the number of BGP network entries received from the listed neighbor.

Content 6.4 Advanced BGP Configuration and Verification 6.4.7 Configuring BGP Authentication You can configure BGP neighbor authentication on a router so that the router authenticates the source of each routing update packet that it receives. This is accomplished by exchanging an authenticating key (sometimes referred to as a password) that is known to both the sending and the receiving router. BGP supports MD5 neighbor authentication. MD5 sends a message digest (also called a hash) that is created using the key and a message. The message digest is then sent instead of the key to prevent the key from being read by an eavesdropper while it is being transmitted. To enable MD5 authentication on a TCP connection between two BGP peers, use the neighbor {ip-address | peer-group-name} password string router configuration command. Figure displays the parameters. You can configure MD5 authentication between two BGP peers, meaning that each segment sent on the TCP connection between the peers is verified. MD5 authentication must be configured with the same password on both BGP peers; otherwise, the connection between them is not made. Configuring MD5 authentication causes Cisco IOS software to generate and check the MD5 digest of every segment sent on the TCP connection. Caution
If the authentication string is configured incorrectly, the BGP peering session is not established. It is recommended that you enter the authentication string carefully and verify that the peering session is established after authentication is configured. If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group inherit the characteristic configured with this command. If a router has a password configured for a neighbor but the neighbor router does not, a message such as the following appears on the console when the routers attempt to send BGP messages between themselves: %TCP-6-BADAUTH: No MD5 digest from 10.1.0.2(179) to 10.1.0.1(20236) Similarly, if the two routers have different passwords configured, a message such as the following appears on the screen: %TCP-6-BADAUTH: Invalid MD5 digest from 10.1.0.1(12293) to 10.1.0.2(179) If you configure or change the password or key used for MD5 authentication between two BGP peers, the local router does not tear down the existing session after you configure the password. The local router attempts to maintain the peering session using the new password until the BGP hold-down timer expires. The default time period is 180 seconds. If the password is not entered or changed on the remote router before the timer expires, the session times out. Note
If you change the hold down value, it takes effect only after the session has been reset. You cannot change the hold-down timer to avoid resetting the BGP session. The example in Figure configures MD5 authentication for the BGP peering session between routers A and B. The same password must be configured on the remote peer before the hold down timer expires.

Content 6.4 Advanced BGP Configuration and Verification 6.4.8 Troubleshooting BGP Use the show ip bgp command to display the BGP topology database (BGP table). Figure displays a partial sample output of the show ip bgp command. The status codes are shown at the beginning of each line of output, and the origin codes are shown at the end of each line. In this output, there is an asterisk (*) in most of the entries in the first column. This means that the next-hop address (in the fifth column) is valid. The next-hop address is not always the router that is directly connected to this router. Other options for the first column are as follows:

s: Specified routes are suppressed (usually because routes have been summarized and only the summary route is being sent).
d: Route is being dampened (penalized) for going up and down too often. Although the route might be up right now, it is not advertised until the penalty has expired.
h: Route is unavailable and is probably down. Historic information about the route exists, but a best route does not exist.
r: Route was not installed in the routing information base (RIB). The reason that the route is not installed can be displayed using the show ip bgp rib-failure command.
S: Route is stale (this symbol is used in the nonstop forwarding-aware router).

The second column shows “>” when BGP has selected the path as the best path to a network. The third column is either blank or shows “i.” If it is blank, BGP learned that route from an external peer. An “i” indicates that an IBGP neighbor advertised this path to the router. The fourth column lists the networks that the router learned. The Next Hop column lists all the next-hop addresses for each route. This column may contain the entry 0.0.0.0, which signifies that this