-
Network Protocols Configuration Guide, Part 1
-
IP Overview
-
Configuring IP Addressing
-
Configuring IP Services
-
Configuring RSVP
-
Configuring On-Demand Routing
-
Configuring RIP
-
Configuring IGRP
-
Configuring OSPF
-
Configuring IP Enhanced IGRP
-
Configuring Integrated IS-IS
-
Configuring BGP
-
Configuring IP Routing Protocol-Independent Features
-
Configuring IP Multicast Routing
-
Table Of Contents
Advanced BGP Configuration Tasks
Configure BGP Soft Reconfiguration
Configure BGP Interactions with IGPs
Configure BGP Administrative Weights
Configure BGP Route Filtering by Neighbor
Configure BGP Path Filtering by Neighbor
Disable Next-Hop Processing on BGP Updates
Configure the Multi Exit Discriminator Metric
Advanced BGP Configuration Tasks
Use Route Maps to Modify Updates
Reset EBGP Connections Immediately upon Link Failure
Disable Automatic Summarization of Network Numbers
Configure BGP Community Filtering
Configure a Routing Domain Confederation
Assign Options to the Peer Group
Make Neighbors Members of the Peer Group
Modify Parameters While Updating the IP Routing Table
Change the Local Preference Value
Select Path Based on MEDs from Other Autonomous Systems
Understand Route Dampening Terms
Monitor and Maintain BGP Route Dampening
Clear Caches, Tables, and Databases
Display System and Network Statistics
Log Changes in Neighbor Status
BGP Neighbor Configuration Examples
BGP Path Filtering by Neighbor Example
TCP MD5 Authentication for BGP Example
BGP Community with Route Maps Examples
Configuring BGP
This chapter describes how to configure Border Gateway Protocol (BGP). For a complete description of the BGP commands in this chapter, refer to the "BGP Commands" chapter of the Network Protocols Command Reference, Part 1. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
The Border Gateway Protocol, as defined in RFCs 1163 and 1267, is an Exterior Gateway Protocol (EGP). It allows you to set up an interdomain routing system that automatically guarantees the loop-free exchange of routing information between autonomous systems.
For protocol-independent features, see the chapter "Configuring IP Routing Protocol-Independent Features" in this document.
Cisco's BGP Implementation
In BGP, each route consists of a network number, a list of autonomous systems that information has passed through (called the autonomous system path), and a list of other path attributes. We support BGP Versions 2, 3, and 4, as defined in RFCs 1163, 1267, and 1771, respectively.
The primary function of a BGP system is to exchange network reachability information with other BGP systems, including information about the list of autonomous system paths. This information can be used to construct a graph of autonomous system connectivity from which routing loops can be pruned and with which autonomous system-level policy decisions can be enforced.
You can configure the value for the Multi Exit Discriminator (MED) metric attribute using route maps. (The name of this metric for BGP Versions 2 and 3 is INTER_AS_METRIC.) When an update is sent to an IBGP peer, the MED is passed along without any change. This action enables all the peers in the same autonomous system to make a consistent path selection.
A third-party next-hop router address is used in the NEXT_HOP attribute, regardless of the autonomous system of that third-party router. The Cisco IOS software automatically calculates the value for this attribute.
Transitive, optional path attributes are passed along to other BGP-speaking routers.
BGP Version 4 supports classless interdomain routing (CIDR), which lets you reduce the size of your routing tables by creating aggregate routes, resulting in supernets. CIDR eliminates the concept of network classes within BGP and supports the advertising of IP prefixes. CIDR routes can be carried by OSPF, Enhanced IGRP, and ISIS-IP, and RIP.
See the "BGP Route Map Examples" section at the end of this chapter for examples of how to use route maps to redistribute BGP Version 4 routes.
How BGP Selects Paths
A router running Cisco IOS Release 12.0 or later does not select or use an IBGP route unless both of the following are true:
•
the router has a route available to the next-hop router
•
BGP bases its decision process on the attribute values. When faced with multiple routes to the same destination, BGP chooses the best route for routing traffic toward the destination. The following process summarizes how BGP chooses the best route.
1
This is why it is important to have an IGP route to the next hop.
2
3
4
5
For example, a route might be originated by the local router using the network bgp command, or through redistribution from an IGP.
6
7
8
This comparison is only done if the neighboring autonomous system is the same for all routes considered, unless bgp always-compare-med is enabled.
9
All confederation paths are considered internal paths.
10
This means the router will prefer the shortest internal path within the autonomous system to reach the destination (the shortest path to the BGP next-hop).
11
•
•
•
Note
12
The router ID is usually the highest IP address on the router or the loopback (virtual) address, but might be implementation-specific.
BGP Multipath Support
When a BGP speaker learns two identical EBGP paths for a prefix from a neighboring AS, it will choose the path with the lowest route-id as the best path. This best path is installed in the IP routing table. If BGP multipath support is enabled and the EBGP paths are learned from the same neighboring AS, instead of picking one best path, multiple paths are installed in the IP routing table.
During packet switching, depending on the switching mode, either per-packet or per-destination load balancing is performed among the multiple paths. A maximum of six paths is supported. The maximum-paths router configuration command controls the number of paths allowed. By default, BGP will install only one path to the IP routing table.
Basic BGP Configuration Tasks
The BGP configuration tasks are divided into basic and advanced tasks. The first three basic tasks are required to configure BGP; the remaining basic and advanced tasks are optional.
Basic BGP configuration tasks are discussed in the following sections:
•
•
•
•
•
•
•
Advanced BGP Configuration Tasks
Advanced, optional BGP configuration tasks are discussed in the following sections:
•
•
•
•
•
•
•
•
•
For information on configuring features that apply to multiple IP routing protocols (such as redistributing routing information), see the chapter "Configuring IP Routing Protocol-Independent Features."
Enable BGP Routing
To enable BGP routing, establish a BGP routing process by performing the following steps starting in global configuration mode:
Note
Note
Configure BGP Neighbors
Like other Exterior Gateway Protocols (EGPs), BGP must completely understand the relationships it has with its neighbors. BGP supports two kinds of neighbors: internal and external. Internal neighbors are in the same autonomous system; external neighbors are in different autonomous systems. Normally, external neighbors are adjacent to each other and share a subnet, while internal neighbors may be anywhere in the same autonomous system.
To configure BGP neighbors, perform the following task in router configuration mode:
See the "BGP Neighbor Configuration Examples" section at the end of this chapter for an example of configuring BGP neighbors.
Configure BGP Soft Reconfiguration
Whenever there is a change in the policy, the BGP session has to be cleared for the new policy to take effect. Clearing a BGP session causes cache invalidation and results in a tremendous impact on the operation of networks.
Soft reconfiguration allows policies to be configured and activated without clearing the BGP session. Soft reconfiguration can be done on a per-neighbor basis.
•
•
Performing inbound reconfiguration enables the new inbound policy to take effect. Performing outbound reconfiguration causes the new local outbound policy take effect without resetting the BGP session. As a new set of updates is sent during outbound policy reconfiguration, a new inbound policy of the neighbor can also take effect.
In order to generate new inbound updates without resetting the BGP session, the local BGP speaker should store all the received updates without modification, regardless of whether it is accepted or denied by the current inbound policy. This is memory intensive and should be avoided. On the other hand, outbound soft reconfiguration does not have any memory overhead. One could trigger an outbound reconfiguration in the other side of the BGP session to make the new inbound policy take effect.
To allow inbound reconfiguration, BGP should be configured to store all received updates. Outbound reconfiguration does not require preconfiguration.
You can configure the Cisco IOS software to start storing received updates, which is required for inbound BGP soft reconfiguration. Outbound reconfiguration does not require inbound soft reconfiguration to be enabled.
To configure BGP soft configuration, perform the following task in router configuration mode:
Configure BGP soft reconfiguration.
neighbor {ip-address | peer-group-name} soft-reconfiguration inbound
Our implementation of BGP supports BGP Versions 2, 3, and 4. If the neighbor does not accept default Version 4, dynamic version negotiation is implemented to negotiate down to Version 2.
If you specify a BGP peer group by using the peer-group-name argument, all members of the peer group will inherit the characteristic configured with this command.
Reset BGP Connections
Once you have defined two routers to be BGP neighbors, they will form a BGP connection and exchange routing information. If you subsequently change a BGP filter, weight, distance, version, or timer, or make a similar configuration change, you must reset BGP connections for the configuration change to take effect. Perform either of the following tasks in EXEC mode to reset BGP connections:
Reset a particular BGP connection.
clear ip bgp address
Reset all BGP connections.
clear ip bgp *
Configure BGP Interactions with IGPs
If your autonomous system will be passing traffic through it from another autonomous system to a third autonomous system, it is very important that your autonomous system be consistent about the routes that it advertises. For example, if your BGP were to advertise a route before all routers in your network had learned about the route through your IGP, your autonomous system could receive traffic that some routers cannot yet route. To prevent this from happening, BGP must wait until the IGP has propagated routing information across your autonomous system. This causes BGP to be synchronized with the IGP. Synchronization is enabled by default.
In some cases, you do not need synchronization. If you will not be passing traffic from a different autonomous system through your autonomous system, or if all routers in your autonomous system will be running BGP, you can disable synchronization. Disabling this feature can allow you to carry fewer routes in your IGP and allow BGP to converge more quickly. To disable synchronization, perform the following task in router configuration mode:
When you disable synchronization, you should also clear BGP sessions using the clear ip bgp command.
See the "BGP Path Filtering by Neighbor Example" section at the end of this chapter for an example of BGP synchronization.
In general, you will not want to redistribute most BGP routes into your IGP. A common design is to redistribute one or two routes and to make them exterior routes in IGRP, or have your BGP speaker generate a default route for your autonomous system. When redistributing from BGP into IGP, only the routes learned using EBGP get redistributed.
In most circumstances, you also will not want to redistribute your IGP into BGP. Just list the networks in your autonomous system with network router configuration commands and your networks will be advertised. Networks that are listed this way are referred to as local networks and have a BGP origin attribute of "IGP." They must appear in the main IP routing table and can have any source; for example, they can be directly connected or learned via an IGP. The BGP routing process periodically scans the main IP routing table to detect the presence or absence of local networks, updating the BGP routing table as appropriate.
If you do perform redistribution into BGP, you must be very careful about the routes that can be in your IGP, especially if the routes were redistributed from BGP into the IGP elsewhere. This creates a situation where BGP is potentially injecting information into the IGP and then sending such information back into BGP, and vice versa.
Networks that are redistributed into BGP from the EGP protocol will be given the BGP origin attribute "EGP." Other networks that are redistributed into BGP will have the BGP origin attribute of "incomplete." The origin attribute in our implementation is only used in the path selection process.
Configure BGP Administrative Weights
An administrative weight is a number that you can assign to a path so that you can control the path selection process. The administrative weight is local to the router. A weight can be a number from 0 to 65535. Paths that the Cisco IOS software originates have weight 32768 by default; other paths have weight 0. If you have particular neighbors that you want to prefer for most of your traffic, you can assign a higher weight to all routes learned from that neighbor.
Perform the following task in router configuration mode to configure BGP administrative weights:
Specify a weight for all routes from a neighbor.
neighbor {ip-address | peer-group-name} weight weight
In addition, you can assign weights based on autonomous system path access lists. A given weight becomes the weight of the route if the autonomous system path is accepted by the access list. Any number of weight filters are allowed.
To assign weights based on autonomous system path access lists, perform the following tasks starting in global configuration mode:
Configure BGP Route Filtering by Neighbor
If you want to restrict the routing information that the Cisco IOS software learns or advertises, you can filter BGP routing updates to and from particular neighbors. To do this, define an access list and apply it to the updates. Distribute-list filters are applied to network numbers and not autonomous system paths.
To filter BGP routing updates, perform the following task in router configuration mode:
Filter BGP routing updates to/from neighbors as specified in an access list.
neighbor {ip-address | peer-group-name} distribute-list access-list-number | name {in | out}
Configure BGP Path Filtering by Neighbor
In addition to filtering routing updates based on network numbers, you can specify an access list filter on both incoming and outbound updates based on the BGP autonomous system paths. Each filter is an access list based on regular expressions. To do this, define an autonomous system path access list and apply it to updates to and from particular neighbors. See the "Regular Expressions" appendix in the Dial Solutions Command Reference for more information on forming regular expressions.
To configure BGP path filtering, perform the following tasks starting in global configuration mode:
See the "BGP Path Filtering by Neighbor Example" section at the end of this chapter for an example of BGP path filtering by neighbor.
Disable Next-Hop Processing on BGP Updates
You can configure the Cisco IOS software to disable next-hop processing for BGP updates to a neighbor. This might be useful in nonmeshed networks such as Frame Relay or X.25, where BGP neighbors might not have direct access to all other neighbors on the same IP subnet.
To disable next-hop processing, perform the following task in router configuration mode:
Disable next-hop processing on BGP updates to a neighbor.
neighbor {ip-address | peer-group-name} next-hop-self
Configuring this command causes the current router to advertise itself as the next hop for the specified neighbor. Therefore, other BGP neighbors will forward to it packets for that address. This is useful in a nonmeshed environment, since you know that a path exists from the present router to that address. In a fully meshed environment, this is not useful, since it will result in unnecessary extra hops and because there might be a direct access through the fully meshed cloud with fewer hops.
Configure the BGP Version
By default, BGP sessions begin using BGP Version 4 and negotiating downward to earlier versions if necessary. To prevent negotiation and force the BGP version used to communicate with a neighbor, perform the following task in router configuration mode:
Specify the BGP version to use when communicating with a neighbor.
neighbor {ip-address | peer-group-name} version value
Set the Network Weight
Weight is a parameter that affects the best path selection process. To set the absolute weight for a network, perform the following task in router configuration mode:
Configure the Multi Exit Discriminator Metric
BGP uses the Multi Exit Discriminator (MED) metric as a hint to external neighbors about preferred paths. (The name of this metric for BGP Versions 2 and 3 is INTER_AS_METRIC.) You can set the MED of the redistributed routes by performing the following task. All the routes without a MED will also be set to this value. Perform the following task in router configuration mode:
Alternatively, you can set the MED using the route-map command. See the "BGP Route Map Examples" section at the end of this chapter for examples of using BGP route maps.
Advanced BGP Configuration Tasks
This section contains advanced BGP configuration tasks.
Use Route Maps to Modify Updates
You can use a route map on a per-neighbor basis to filter updates and modify various attributes. A route map can be applied to either inbound or outbound updates. Only the routes that pass the route map are sent or accepted in updates.
On both the inbound and the outbound updates, we support matching based on autonomous system path, community, and network numbers. Autonomous system path matching requires the as-path access-list command, community based matching requires the community-list command and network-based matching requires the ip access-list command. Perform the following task in router configuration mode:
Apply a route map to incoming or outgoing routes.
neighbor {ip-address | peer-group-name} route-map route-map-name {in | out}
See the "BGP Route Map Examples" section at the end of this chapter for BGP route-map examples.
Reset EBGP Connections Immediately upon Link Failure
Normally, when a link between external neighbors goes down, the BGP session will not be reset immediately. If you want the EBGP session to be reset as soon as an interface goes down, perform the following task in router configuration mode:
Configure Aggregate Addresses
Classless interdomain routing (CIDR) enables you to create aggregate routes (or supernets) to minimize the size of routing tables. You can configure aggregate routes in BGP either by redistributing an aggregate route into BGP or by using the conditional aggregation feature described in the following task table. An aggregate address will be added to the BGP table if there is at least one more specific entry in the BGP table.
To create an aggregate address in the routing table, perform one or more of the following tasks in router configuration mode:
See the "BGP Aggregate Route Examples" section at the end of this chapter for examples of using BGP aggregate routes.
Disable Automatic Summarization of Network Numbers
In BGP Version 3, when a subnet is redistributed from an IGP into BGP, only the network route is injected into the BGP table. By default, this automatic summarization is enabled. To disable automatic network number summarization, perform the following task in router configuration mode:
Configure BGP Community Filtering
BGP supports transit policies via controlled distribution of routing information. The distribution of routing information is based on one of the following three values:
•
•
•
The COMMUNITIES attribute is a way to group destinations into communities and apply routing decisions based on the communities. This method simplifies a BGP speaker's configuration that controls distribution of routing information.
A community is a group of destinations that share some common attribute. Each destination can belong to multiple communities. Autonomous system administrators can define to which communities a destination belongs. By default, all destinations belong to the general Internet community. The community is carried as the COMMUNITIES attribute.
The COMMUNITIES attribute is an optional, transitive, global attribute in the numerical range from 1 to 4,294,967,200. Along with Internet community, there are a few predefined, well-known communities, as follows:
•
•
•
Based on the community, you can control which routing information to accept, prefer, or distribute to other neighbors. A BGP speaker can set, append, or modify the community of a route when you learn, advertise, or redistribute routes. When routes are aggregated, the resulting aggregate has a COMMUNITIES attribute that contains all communities from all the initial routes.
You can use community lists to create groups of communities to use in a match clause of a route map. Just like an access list, a series of community lists can be created. Statements are checked until a match is found. As soon as one statement is satisfied, the test is concluded.
To create a community list, perform the following task in global configuration mode:
Create a community list.
ip community-list community-list-number {permit | deny} community-number
To set the COMMUNITIES attribute and match clauses based on communities, see the match community-list and set community commands in the "Redistribute Routing Information" section in the "Configuring IP Routing Protocol-Independent Features" chapter.
By default, no COMMUNITIES attribute is sent to a neighbor. You can specify that the COMMUNITIES attribute be sent to the neighbor at an IP address by performing the following task in router configuration mode:
Specify that the COMMUNITIES attribute be sent to the neighbor at this IP address.
neighbor {ip-address | peer-group-name} send-community
Configure a Routing Domain Confederation
One way to reduce the IBGP mesh is to divide an autonomous system into multiple autonomous systems and group them into a single confederation. To the outside world, the confederation looks like a single autonomous system. Each autonomous system is fully meshed within itself, and has a few connections to other autonomous systems in the same confederation. Even though the peers in different autonomous systems have EBGP sessions, they exchange routing information as if they were IBGP peers. Specifically, the next-hop, MED, and local preference information is preserved. This enables to us to retain a single Interior Gateway Protocol (IGP) for all of the autonomous systems.
To configure a BGP confederation, you must specify a confederation identifier. To the outside world, the group of autonomous systems will look like a single autonomous system with the confederation identifier as the autonomous system number. To configure a BGP confederation identifier, perform the following tasks in router configuration mode:
In order to treat the neighbors from other autonomous systems within the confederation as special EBGP peers, perform the following task in router configuration mode:
Specify the autonomous systems that belong to the confederation.
bgp confederation peers autonomous-system [autonomous-system ...]
See the "BGP Confederation Example" section at the end of this chapter for an example configuration of several peers in a confederation.
For an alternative way to reduce the IBGP mesh, see the next section, "Configure a Route Reflector."
Configure a Route Reflector
BGP requires that all of the IBGP speakers be fully meshed. However, this requirement does not scale when there are many IBGP speakers. Instead of configuring a confederation, another way to reduce the IBGP mesh is to configure a route reflector.
illustrates a simple IBGP configuration with three IBGP speakers (Routers A, B, and C). Without route reflectors, when Router A receives a route from an external neighbor, it must advertise it to both Routers B and C. Routers B and C do not readvertise the IBGP learned route to other IBGP speakers because the routers do not pass routes learned from internal neighbors on to other internal neighbors, thus preventing a routing information loop.
Figure 25 Three Fully Meshed IBGP Speakers
With route reflectors, all IBGP speakers need not be fully meshed because there is a method to pass learned routes to neighbors. In this model, an internal BGP peer is configured to be a route reflector responsible for passing IBGP learned routes to a set of IBGP neighbors. In , Router B is configured as a route reflector. When the route reflector receives routes advertised from Router A, it advertises them to Router C, and vice versa. This scheme eliminates the need for the IBGP session between Routers A and C.
Figure 26 Simple BGP Model with a Route Reflector
The internal peers of the route reflector are divided into two groups: client peers and all the other routers in the autonomous system (nonclient peers). A route reflector reflects routes between these two groups. The route reflector and its client peers form a cluster. The nonclient peers must be fully meshed with each other, but the client peers need not be fully meshed. The clients in the cluster do not communicate with IBGP speakers outside their cluster.
illustrates a more complex route reflector scheme. Router A is the route reflector in a cluster with Routers B, C, and D. Routers E, F, and G are fully meshed, nonclient routers.
Figure 27 More Complex BGP Route Reflector Model
When the route reflector receives an advertised route, depending on the neighbor, it does the following:
•
•
•
To configure a route reflector and its clients, perform the following task in router configuration mode:
Configure the local router as a BGP route reflector and the specified neighbor as a client.
neighbor ip-address route-reflector-client
Along with route reflector-aware BGP speakers, it is possible to have BGP speakers that do not understand the concept of route reflectors. They can be members of either client or nonclient groups. This allows easy, gradual migration from the old BGP model to the route reflector model. Initially, you could create a single cluster with a route reflector and a few clients. All the other IBGP speakers could be nonclient peers to the route reflector and then more clusters could be created gradually.
An autonomous system can have multiple route reflectors. A route reflector treats other route reflectors just like other IBGP speakers. A route reflector can be configured to have other route reflectors in a client group or nonclient group. In a simple configuration, the backbone could be divided into many clusters. Each route reflector would be configured with other route reflectors as nonclient peers (thus, all the route reflectors will be fully meshed). The clients are configured to maintain IBGP sessions with only the route reflector in their cluster.
Usually a cluster of clients will have a single route reflector. In that case, the cluster is identified by the router ID of the route reflector. To increase redundancy and avoid a single point of failure, a cluster might have more than one route reflector. In this case, all route reflectors in the cluster must be configured with the 4-byte cluster ID so that a route reflector can recognize updates from route reflectors in the same cluster. All the route reflectors serving a cluster should be fully meshed and all of them should have identical sets of client and nonclient peers.
If the cluster has more than one route reflector, configure the cluster ID by performing the following task in router configuration mode:
Use the show ip bgp command to display the originator ID and the cluster-list attributes.
By default, the clients of a route reflector are not required to be fully meshed and the routes from a client are reflected to other clients. However, if the clients are fully meshed, the route reflector does not need to reflect routes to clients. To disable client-to-client route reflection, perform the following task in router configuration mode:
Note
As the IBGP learned routes are reflected, it is possible for routing information to loop. The route reflector model has the following mechanisms to avoid routing loops:
•
•
•
Configure Neighbor Options
There are many ways to customize a BGP neighbor, and these customized features can also be applied to a peer group. To avoid documenting each option twice (for both neighbors and peer groups), all of the supported neighbor options appear in the next section, "Configure BGP Peer Groups" under "Assign Options to the Peer Group."
To provide BGP routing information to a large number of neighbors, you can configure BGP to accept neighbors based on an access list. If a neighbor attempts to initiate a BGP connection, its address must be accepted by the access list for the connection to be accepted. If you do this, the router will not attempt to initiate a BGP connection to these neighbors, so the neighbors must be explicitly configured to initiate the BGP connection. If no access list is specified, all connections are accepted.
Specify an access list of BGP neighbors by performing the following task in router configuration mode:
Configure BGP Peer Groups
Often, in a BGP speaker, many neighbors are configured with the same update policies (that is, the same outbound route maps, distribute lists, filter lists, update source, and so on). Neighbors with the same update policies can be grouped into peer groups to simplify configuration and, more importantly, to make updating more efficient. When you have many peers, this approach is highly recommended.
The three steps to configure a BGP peer group, described in the following sections, are:
Step 1
Step 2
Step 3
Create the Peer Group
To create a BGP peer group, perform the following task in router configuration mode:
Assign Options to the Peer Group
After you create a peer group, you configure the peer group with neighbor commands. By default, members of the peer group inherit all the configuration options of the peer group. Members can also be configured to override the options that do not affect outbound updates.
Peer group members will always inherit the following: remote-as (if configured), version, update-source, out-route-map, out-filter-list, out-dist-list, minimum-advertisement-interval, and next-hop-self. All the peer group members will inherit changes made to the peer group.
Note
To assign configuration options to an individual neighbor, specify any of the following commands using the IP address. To assign the options to a peer group, specify any of the commands using the peer group name. Perform any of these tasks in router configuration mode.
If a peer group is not configured with a remote-as, the members can be configured with the neighbor remote-as command. This allows you to create peer groups containing EBGP neighbors.
You can customize inbound policies for peer group members, (using, for example, a distribute list, route map, or filter list) because one identical copy of an update is sent to every member of a group. Therefore, neighbor options related to outgoing updates cannot be customized for peer group members.
External BGP peers normally must reside on a directly connected network. Sometimes it is useful to relax this restriction in order to test BGP; do so by specifying the neighbor ebgp-multihop command.
For internal BGP, you might want to allow your BGP connections to stay up regardless of which interface is used to reach a neighbor. To do this, you first configure a loopback interface and assign it an IP address. Next, configure the BGP update source to be the loopback interface. Finally, configure your neighbor to use the address on the loopback interface. Now the IBGP session will be up as long as there is a route, regardless of any interface.
You can set the minimum interval of time between BGP routing updates.
You can invoke MD5 authentication between two BGP peers, meaning that each segment sent on the TCP connection between them is verified. This feature must be configured with the same password on both BGP peers; otherwise, the connection between them will not be made. The authentication feature uses the MD5 algorithm. Invoking authentication causes the Cisco IOS software to generate and check the MD5 digest of every segment sent on the TCP connection. If authentication is invoked and a segment fails authentication, then a message appears on the console.
See the "TCP MD5 Authentication for BGP Example" at the end of this chapter for an example of enabling MD5 authentication.
Make Neighbors Members of the Peer Group
Finally, to configure a BGP neighbor to be a member of that BGP peer group, perform the following task in router configuration mode, using the same peer group name:
Make a BGP neighbor a member of the peer group.
neighbor ip-address peer-group peer-group-name
See the "BGP Peer Group Examples" section at the end of this chapter for examples of IBGP and EBGP peer groups.
Indicate Backdoor Routes
You can indicate which networks are reachable by using a backdoor route that the border router should use. A backdoor network is treated as a local network, except that it is not advertised. To configure backdoor routes, perform the following task in router configuration mode:
Modify Parameters While Updating the IP Routing Table
By default, when a BGP route is put into the IP routing table, the MED is converted to an IP route metric, the BGP next hop is used as the next hop for the IP route, and the tag is not set. However, you can use a route map to perform mapping. To modify metric and tag information when the IP routing table is updated with BGP learned routes, perform the following task in router configuration mode:
Apply a route map to routes when updating the IP routing table.
table-map route-map name
Set Administrative Distance
Administrative distance is a measure of the preference of different routing protocols. BGP uses three different administrative distances: external, internal, and local. Routes learned through external BGP are given the external distance, routes learned with internal BGP are given the internal distance, and routes that are part of this autonomous system are given the local distance. To assign a BGP administrative distance, perform the following task in router configuration mode:
Assign a BGP administrative distance.
distance bgp external-distance internal-distance local-distance
Changing the administrative distance of BGP routes is considered dangerous and generally is not recommended. The external distance should be lower than any other dynamic routing protocol, and the internal and local distances should be higher than any other dynamic routing protocol.
Adjust BGP Timers
BGP uses certain timers to control periodic activities such as the sending of keepalive messages, and the interval after not receiving a keepalive message after which the Cisco IOS software declares a peer dead. By default, the keepalive timer is 60 seconds, and the holdtime timer is 180 seconds. You can adjust these timers. When a connection is started, BGP will negotiate the hold time with the neighbor. The smaller of the two hold times will be chosen. The keepalive timer is then set based on the negotiated hold time and the configured keepalive time. To adjust BGP timers for all neighbors, use the following command in router configuration mode:
To adjust BTP keepalive and holdtime timeres for a specific neighbor, use the following command in router configuration mode:
neighbor [ip-address | peer group-name] timers keepalive holdtime
Sets the keepalive and holdtime timers (in seconds) for the specified peer or peer group.
Note
To clear the timers for a BGP neighbor or peer group, use the no form of the neighbor timers command.
Change the Local Preference Value
You can define a particular path as more preferable or less preferable than other paths by changing the default local preference value of 100. To assign a different default local preference value, perform the following task in router configuration mode:
You can use route maps to change the default local preference of specific paths. See the "BGP Route Map Examples" section at the end of this chapter for examples when used with BGP route maps.
Redistribute Network 0.0.0.0
By default, you are not allowed to redistribute network 0.0.0.0. To permit the redistribution of network 0.0.0.0, perform the following task in router configuration mode:
Select Path Based on MEDs from Other Autonomous Systems
The MED is one of the parameters that is considered when selecting the best path among many alternative paths. The path with a lower MED is preferred over a path with a higher MED.
By default, during the best-path selection process, MED comparison is done only among paths from the same autonomous system. You can allow comparison of MEDs among paths regardless of the autonomous system from which the paths are received. To do so, perform the following task in router configuration mode:
Allow the comparison of MEDs for paths from neighbors in different autonomous systems.
bgp always-compare-med
Configure Route Dampening
Route dampening is a BGP feature designed to minimize the propagation of flapping routes across an internetwork. A route is considered to be flapping when it is repeatedly available, then unavailable, then available, then unavailable, and so on.
For example, consider a network with three BGP autonomous systems: AS 1, AS 2, and AS 3. Suppose the route to network A in AS 1 flaps (it becomes unavailable). Under circumstances without route dampening, AS 1's EBGP neighbor to AS 2 sends a Withdraw message to AS 2. The border router in AS 2, in turn, propagates the Withdraw to AS 3. When the route to network A reappears, AS 1 sends an Advertisement to AS 2, which sends it to AS 3. If the route to network A repeatedly becomes unavailable, then available, many Withdrawals and Advertisements are sent. This is a problem in an internetwork connected to the Internet because a route flap in the Internet backbone usually involves many routes.
Note
Minimize Flapping
The route dampening feature minimizes the flapping problem as follows. Suppose again that the route to network A flaps. The router in AS 2 (where route dampening is enabled) assigns network A a penalty of 1000 and moves it to "history" state. The router in AS 2 continues to advertise the status of the route to neighbors. The penalties are cumulative. When the route flaps so often that the penalty exceeds a configurable suppress limit, the router stops advertising the route to network A, regardless of how many times it flaps. Thus, the route is dampened.
The penalty placed on network A is decayed until the reuse limit is reached, upon which the route is once again advertised. At half of the reuse limit, the dampening information for the route to network A is removed.
Understand Route Dampening Terms
The following terms are used when describing route dampening:
•
•
•
•
•
•
•
•
The routes external to an AS learned via IBGP are not dampened. This policy prevent the IBGP peers from having a higher penalty for routes external to the AS.
Enable Route Dampening
To enable BGP route dampening, perform the following task in global configuration mode:
To change the default values of various dampening factors, perform the following task in global configuration mode:
Change the default values of route dampening factors.
bgp dampening half-life reuse suppress max-suppress [route-map map]
Monitor and Maintain BGP Route Dampening
You can monitor the flaps of all the paths that are flapping. The statistics will be deleted once the route is not suppressed and is stable for at least one half-life. To display flap statistics, perform the following tasks in EXEC mode:
To clear BGP flap statistics (thus making it less likely that the route will be dampened), perform the following tasks in EXEC mode:
Note
Once a route is dampened, you can display BGP route dampening information, including the time remaining before the dampened routes will be unsuppressed. To display the information, perform the following task in EXEC mode:
Display the dampened routes, including the time remaining before they will be unsuppressed.
show ip bgp dampened-paths
You can clear BGP route dampening information and unsuppress any suppressed routes by performing the following task in EXEC mode:
Clear route dampening information and unsuppress the suppressed routes.
clear ip bgp dampening [address mask]
Monitor and Maintain BGP
You can remove all contents of a particular cache, table, or database. You also can display specific statistics. The following sections describe each of these tasks.
Clear Caches, Tables, and Databases
You can remove all contents of a particular cache, table, or database. Clearing a cache, table, or database can become necessary when the contents of the particular structure have become, or are suspected to be, invalid.
The following table lists the tasks associated with clearing caches, tables, and databases for BGP. Perform these tasks in EXEC mode:
Reset a particular BGP connection.
clear ip bgp address
Reset all BGP connections.
clear ip bgp *
Remove all members of a BGP peer group.
clear ip bgp peer-group tag
Display System and Network Statistics
You can display specific statistics such as the contents of BGP routing tables, caches, and databases. Information provided can be used to determine resource utilization and solve network problems. You can also display information about node reachability and discover the routing path your device's packets are taking through the network.
To display various routing statistics, perform the following tasks in EXEC mode:
