bgp4

6.4.4 Configuring a Peer Group
In BGP, neighboring routers are often configured with the same update policies. For example, the neighboring routers may have the same filtering applied. On Cisco routers, neighboring routers with the same update policies can be grouped into peer groups to simplify configuration and to make updating more efficient and improve performance.

Members of the peer group inherit all the configuration options of the peer group. You can configure the router to override these options for some members if these options affect inbound advertisements but not outbound updates.

Peer groups are more efficient because updates are generated only once per peer group rather than repetitiously for each neighboring router. The generated update is replicated for each neighbor that is part of the internal peer group. Peer groups save processing time in generating the updates for all IBGP neighbors. The peer group name is local to the router on which it is configured, and it is not passed to any other router. Peer groups make the router configuration easier to read and manage.

Use the neighbor peer-group-name peer-group command to create a peer group and define the name for linking similar neighboring routers together.

Use the neighbor ip-address peer-group peer-group-name command to link the address of a neighboring router to a specific peer group name. A neighboring router can be part of only one peer group. This command allows you to enter the peer group name instead of entering the IP address in other commands, for example, to link a policy to the group of neighboring routers. You must enter the neighbor peer-group-name peer-group command before the router will accept this command.

Note
Recent releases of Cisco IOS software contain a BGP Dynamic Update Peer-Groups Using Peer Templates feature to dynamically optimize update groups of neighbors for shared outbound policies. More information on this feature can be found on Cisco.com.

6.4.5 Configuring a Peer Group Example
In Figure , AS 65100 has four routers running IBGP. All these IBGP neighbors are peering with each other using the loopback 0 interface of each, and are using the IP address of their loopback 0 interface as the source IP address for all BGP packets. Each router is using one of its own IP addresses as the next-hop address for each network advertised through BGP. These are outbound policies.

In addition, router C has an outbound distribution list associated with each IBGP neighbor. This outbound filter performs the same function as the distribute-list command that you use for internal routing protocols. However, it is linked to a specific neighbor for use with BGP. The ISP behind router C may be announcing RFC 1918 private address space to router C. Router C does not want to pass these networks to other routers running BGP in AS 65100.

To accomplish this goal, access list 20 might look like the following:

access-list 20 deny 10.0.0.0 0.255.255.255
access-list 20 deny 172.16.0.0 0.31.255.255
access-list 20 deny 192.168.0.0 0.0.255.255
access-list 20 permit any

Notice the configuration of router C when it is not using a peer group. All IBGP neighbors have the outbound distribute list link to them individually. If router C receives a change from AS 65101, it must generate an individual update for each IBGP neighbor and run each update against distribute list 20. If router C has a large number of IBGP neighbors, the processing power needed to inform the IBGP neighbors of the changes in AS 65101 could be extensive. The figure also shows the configuration on router C when it is using a peer group called “internal.” The 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.

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.

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.

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 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.

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.

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.

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:

• Using stored routing update information
• Dynamically

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 | peergroup- name} in command. You do not have to use the soft keyword, because soft reset is automatically assumed.

6.4.12 The debug ip bgp Command
Figure shows partial output from the debug ip bgp updates command on router A after the clear ip bgp command was issued to clear BGP sessions with its IBGP neighbor 10.1.0.2.

After the neighbor adjacency is reestablished, router A creates and sends updates to 10.1.0.2.
he first update highlighted in the figure, “10.1.1.0/24, next 10.1.0.1,” is an update about network 10.1.1.0/24, with a next hop of 10.1.0.1, which is the address of router A.

The second update highlighted in the figure, “10.97.97.0/24, next 172.31.11.4,” is an update about network 10.97.97.0/24, with a next hop of 172.31.11.4, which is the address of one of router A’s EBGP neighbors. The EBGP next-hop address is being carried into IBGP.

Router A later receives updates from 10.1.0.2. The update highlighted in the figure contains a path to two networks: 10.1.2.0/24 and 10.1.0.0/24. The attributes shown in this update are described in the next lesson.

Note
Debugging uses up router resources and should be turned on only when necessary

6.5 Selecting a BGP Path
6.5.1 Characteristics of BGP Attributes
BGP routers send BGP update messages about destination networks to other BGP routers. The update messages contain one or more routes and a set of BGP metrics, which are called path attributes, attached to the routes.

An attribute is either well-known or optional, mandatory or discretionary, and transitive or nontransitive. An attribute may also be partial.

Not all combinations of these characteristics are valid. Path attributes fall into the following four categories:

• Well-known mandatory
• Well-known discretionary
• Optional transitive
• Optional nontransitive

Only optional transitive attributes can be marked as partial.
All BGP routers must recognize a well-known attribute and propagate it to the other BGP neighbors.

Well-known attributes are either mandatory or discretionary. A well-known mandatory attribute must be present in all BGP updates. A well-known discretionary attribute does not have to be present in all BGP updates.

Attributes that are not well-known are called optional. BGP routers do not have to support an optional attribute. Optional attributes are either transitive or nontransitive.

The following statements apply to optional attributes:

• BGP routers that implement the optional attribute may propagate it to the other BGP neighbors, based on its meaning.
• BGP routers that do not implement an optional transitive attribute should pass it to other BGP routers untouched and mark the attribute as partial.
• BGP routers that do not implement an optional nontransitive attribute must delete the attribute and must not pass it to other BGP routers.

6.5.2 BGP Attributes
The following is a list of the common BGP attributes according to categories that they belong to:

• Well-known mandatory attributes
o Autonomous system path
o Next hop
o Origin

• Well-known discretionary attributes
o Local preference
o Atomic aggregate

• Optional transitive attribute
o Aggregator

• Optional nontransitive attribute
o Multi-exit discriminator (MED)

Note
In addition, Cisco defines a weight attribute for BGP. The weight is configured locally on a router and is not propagated to any other BGP routers.

Note
The attributes in this list are detailed in the following topics, except for the atomic aggregate and aggregator attributes. These two attributes relate to BGP summarization (or aggregation), and you can find more information on them on Cisco.com

Interactive Media Activity
Point and Click: Classify the Attributes

6.5.3 AS Path Attribute
The AS path is a well-known mandatory attribute. Whenever a route update passes through an autonomous system, the autonomous system number is prepended (added) to that update when it is advertised to the next EBGP neighbor.

The AS path attribute is actually the list of autonomous system numbers that a route has traversed to reach a destination, with the number of the autonomous system that originated the route at the end of the list.

In Figure , router A in AS 64520 advertises network 192.168.1.0. When that route traverses AS 65500, router C prepends its own autonomous system number to it. When 192.168.1.0
reaches router B, it has two autonomous system numbers attached to it. From router B’s
perspective, the path to reach 192.168.1.0 is (65500, 64520).

A similar process applies for the paths to networks 192.168.2.0 and 192.168.3.0. The path from router A to 192.168.2.0 is (65500, 65000), which means traverse AS 65500 and then AS 65000. Router C must traverse path (65000) to reach 192.168.2.0, and path (64520) to reach
192.168.1.0.

6.5.4 Next-Hop Attribute
The BGP next-hop attribute is a well-known mandatory attribute that indicates the next-hop IP
address that is to be used to reach a destination.
BGP routes autonomous system by autonomous system, not router by router. The next-hop attribute defines the IP address of the border router that should be used as the next hop to the destination.

For EBGP, the next hop is the IP address of the neighbor that sent the update. In Figure , router A advertises 172.16.0.0 to router B, with a next hop of 10.10.10.3, and router B advertises 172.20.0.0 to router A, with a next hop of 10.10.10.1.

For IBGP, the protocol states that the next hop that is advertised by EBGP should be carried into IBGP. Because of that rule, router B advertises 172.16.0.0 to its IBGP peer router C with a next hop of 10.10.10.3 (router A’s address). Therefore, router C knows that the next hop to reach 172.16.0.0 is 10.10.10.3, not 172.20.10.1, as you might expect.

It is very important for router C to know how to reach the 10.10.10.0 subnet, either via an IGP or a static route. Otherwise, it will drop packets destined to 172.16.0.0, because it cannot get to the next-hop address for that network.

Alternatively, router B can change the next-hop attribute to itself if you use the neighbor next-hop-self command.

6.5.5 Origin Attribute
The origin attribute defines the origin of the path information. The origin attribute can be one of these three values:

• IGP: The route is interior to the originating autonomous system. This value normally results when the network command is used to advertise the route via BGP. An origin of IGP is indicated with an “i” in the BGP table.

• EGP: The route has been learned via EGP. This value is indicated with an “e” in the BGP table. EGP is considered a historical routing protocol and is not supported on the Internet because it performs only classful routing and does not support classless interdomain routing.

• Incomplete: The origin of the route is unknown or has been learned by some other means. This value usually results when a route is redistributed into BGP. An incomplete origin is indicated with a question mark (?) in the BGP table.

Figure shows example output of the show ip bgp command. The origin code, reflecting the origin attribute, is in the last column at the end of each line. In this example, all origin codes are “i,” indicating an origin attribute of IGP; the routes are interior to the originating autonomous system.

6.5.6 Local Preference Attribute
Local preference is a well-known discretionary attribute that provides an indication to routers in the autonomous system about which path is preferred to exit the autonomous system. A path with a higher local preference is preferred.

The local preference is an attribute that is configured on a router and exchanged among routers within the same autonomous system only. The default value for local preference on a Cisco router is 100.

In Figure , AS 64520 receives updates about network 172.16.0.0 from two directions. The local preference on router A for network 172.16.0.0 is set to 200, and the local preference on router B for network 172.16.0.0 is set to 150.

Because the local preference information is exchanged within AS 64520, all traffic in AS 64520 addressed to network 172.16.0.0 is sent to router A as an exit point from autonomous system 64520 (because of its higher local preference).

6.5.7 MED Attribute
The MED attribute, also called the metric, is an optional nontransitive attribute.
The MED is an indication to EBGP neighbors about the preferred path into an autonomous system. The MED attribute is a dynamic way to influence another autonomous system about which path that it should choose to reach a certain route in their autonomous system when multiple entry points exist. A lower metric is preferred.

Unlike local preference, the MED is exchanged between autonomous systems. The MED is sent to EBGP peers. Those routers propagate the MED within their autonomous system, and the routers within the autonomous system use the MED but do not pass it on to the next autonomous system. When the same update is passed on to another autonomous system, the metric is set back to the default of 0.

MED influences inbound traffic to an autonomous system, and local preference influences outbound traffic.
By default, a router compares the MED attribute only for paths from neighbors in the same autonomous system.

Note
The MED attribute means that BGP is the only protocol that can affect how routes are sent into an autonomous system.

In Figure , the router B MED attribute is set to 150, and the router C MED attribute is set to 200. When router A receives updates from routers B and C, it chooses router B as the best next hop because its MED of 150 is less than router C.