Table Of Contents
Advanced BGP Configuration Tasks
Configure BGP Soft Reconfiguration
Configure BGP Interactions with IGPs
Configure BGP Route Filtering by Neighbor
Configuring BGP Filtering Using Prefix Lists
How the System Filters Traffic by Prefix List
Configure How Sequence Numbers of Prefix List Entries Are Specified
Delete a Prefix List or Prefix List Entries
Clear the Hit Count Table of Prefix List Entries
Configure BGP Path Filtering by Neighbor
Disable Next-Hop Processing on BGP Updates
Disable Next-Hop Processing Using a Specific Address
Disable Next-Hop Processing Using a Route Map
Configure the Multi Exit Discriminator Metric
Configure Advanced BGP Features
Use Route Maps to Modify Updates
Reset EBGP Connections Immediately upon Link Failure
Disable Automatic Summarization of Network Numbers
Configure BGP Community Filtering
Specify the Format for the Community
Configuring BGP Conditional Advertisement
The Size of the Global BGP Table Is Reduced
Better Inbound Traffic Control
BGP Conditional Advertisement Configuration Task List
Conditional Advertisement of a Set of Routes
Verifying BGP Conditional Advertisement feature
BGP Conditional Advertisement Troubleshooting Tips
Configure a Routing Domain Confederation
Assign Options to the Peer Group
Make Neighbors Members of the Peer Group
Disabling a Peer or Peer Group
Modify Parameters While Updating the IP Routing Table
Change the Local Preference Value
Configure the Router to Consider a Missing MED as Worst Path
Select Path Based on MEDs from Other Autonomous Systems
Configure the Router to Use the MED to Choose a Path from Sub-AS Paths
Configure the Router to Use the MED to Choose a Path in a Confederation
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
Configure Route Filtering Using a Prefix List
Configure Route Filtering by Specifying a Group of Prefixes
Adding or Deleting Prefix List Entries
BGP Path Filtering by Neighbor Example
BGP Conditional Advertisement Configuration Examples
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 provides 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 reachable destination (network or prefix), 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 autonomous system path is used to ensure loop free paths through the internetwork. The other path attributes are used to enforce autonomous system level policies, such as which exit point to use or which autonomous systems may be used to transit traffic to other autonomous systems. A description of some of the other path attributes available are given in the following paragraphs.
The Multiple Exit Discriminator (MED, also called the INTER_AS_METRIC in BGP versions 2 and 3) is used to provide a hint about which entrance point an autonomous system would like other autonomous system to use. When an update is sent to an iBGP peer, the MED is passed along without any change. This action enables all the speakers in the same autonomous system to make a consistent path selection.
The NEXT_HOP attribute is used to provide the address packets destined to this prefix should be forwarded to. It is, by default, set to the address of the eBGP peer which first advertises this prefix into the autonomous system, and is not changed when the prefix is advertised to iBGP peers. The Cisco IOS software automatically calculates the value for this attribute.
The Local Preference attribute is used by the BGP speakers in an autonomous system to determine the best path out of the autonomous system to a given destination. This attribute is usually set at the autonomous system border using a route map or some other technique.
Transitive, optional path attributes are passed along to other BGP-speaking routers.
In addition to the attributes that BGP carries in updates, 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 version 2.
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.
•
BGP bases it's decision first on whether a path is loop free, then on the policies indicated by the path attributes along with the policies configured on the router. The following summarized how BGP chooses the best path to a given destination.
1
If the only route you have to the next hop indicated in the NEXT_HOP attribute of a prefix is learned through iBGP, the route will oscillate in the routing table. It will be installed by BGP, then removed about 60 seconds later, only to be reinstalled momentarily after it is deleted.
2
3
4
Note
For example, a route might be originated by the local router using the network (BGP) or aggregate-address command, or through redistribution from an IGP. BGP prefers local routes originated by network (BGP) and redistribute commands over local aggregates originated by the aggregate-address command.
5
•
•
•
6
7
A comparison is only done if the neighboring autonomous system is the same for all routes considered. Also note the following:
•
•
•
•
•
8
All confederation routes are considered internal routes.
9
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).
10
•
•
•
Note
11
This step minimizes route flap in that a newer route will not displace an older route even if the newer route is the preferred route based on the additional criteria discussed below.
If any of the following additional criteria are met, this step is skipped:
•
•
•
12
The router ID is usually the highest IP address on the router or the loopback (virtual) address, but might be implementation-specific. You can configure a fixed router ID by using the bgp router-id command.
If a route contains route reflector attributes, the originator ID is substituted for the router ID in the route selection process.
13
The minimum cluster ID length attribute applies to BGP route reflector environments only.
14
The BGP neighbor configuration uses this IP address. The IP address corresponds to the remote peer used in the TCP connection with the local router.
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 two 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."
Configure Basic BGP Features
The tasks in this section are for configuring basic BGP features.
Enable BGP Routing
To enable BGP routing, establish a BGP routing process by using the following commands beginning 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. Therefore, this task is required.
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, use the following command 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 is recommended; it is 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, use the following command in router configuration mode:
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. Use either of the following commands in EXEC mode to reset BGP connections:
clear ip bgp address
Reset a particular BGP connection.
clear ip bgp *
Reset all BGP connections.
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, use the following command 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.
Configuring BGP Weights
A 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. Any path that a Cisco router originates will have a default weight of 32768; 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.
Weights can be assigned 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. Weights can only be assigned via route maps.
Disable AS Path Comparison
To prevent the router from considering the as-path length when selecting a route, use the following command in router configuration mode:
bgp bestpath as-path ignore
Configures the router to ignore as-path length in selecting a route.
Configure BGP Route Filtering by Neighbor
You can filter BGP advertisements in two ways:
•
•
Filtering using prefix lists is described in "Configuring BGP Filtering Using Prefix Lists".
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, you can either define an access list or a prefix list and apply it to the updates.
Note
To filter BGP routing updates, use the following command in router configuration mode:
Note
Configuring BGP Filtering Using Prefix Lists
Prefix lists can be used as an alternative to access lists in many BGP route filtering commands. "How the System Filters Traffic by Prefix List" describes the way prefix list filtering works.
The advantages of using prefix lists are:
•
•
Filtering using extended access lists does not support incremental updates.
•
The command-line interface for using access lists to filter BGP updates is difficult to understand and use, since it uses the packet filtering format.
•
Before using a prefix list in a command, you must set up a prefix list, and you may want to assign sequence numbers to the entries in the prefix list.
How the System Filters Traffic by Prefix List
Filtering by prefix list involves matching the prefixes of routes with those listed in the prefix list. When there is a match, the route is used. The matching is similar to that of the access list. More specifically, whether a prefix is permitted or denied is based upon the following rules:
•
•
•
The router begins the search at the top of the prefix list, with the sequence number 1. Once a match or deny occurs, the router does not need to go through the rest of the prefix list. For efficiency, you may want to put the most common matches or denies near the top of the list, using the argument seq in the ip prefix-list command. The show commands always include the sequence numbers in their output.
Sequence numbers are generated automatically unless you disable this automatic generation. If you disable the automatic generation of sequence numbers, you must specify the sequence number for each entry using the seq-value argument of the ip prefix-list command.
Regardless of whether the default sequence numbers are used in configuring a prefix list, a sequence number does not need to be specified when removing a configuration entry.
Show commands include the sequence numbers in their output.
Create a Prefix List
To create a prefix list, use the following command in router configuration mode:
ip prefix-list list-name [seq seq-value] deny|permit network/len [ge ge-value] [le le-value]
Creates a prefix list with the name specified for list-name.
Note
To remove a prefix list and all of its entries, use the following command in router configuration mode:
no ip prefix-list list-name [seq seq-value] deny|permit network/len [ge ge-value] [le le-value]
Removes a prefix list with the name specified for list-name.
Configure a Prefix List Entry
You can add entries to a prefix list individually. To configure an entry in a prefix list, use the following command in router configuration mode:
ip prefix-list list-name seq seq-value deny|permit network/len [ge ge-value] [le le-value]
Creates an entry in a prefix list and assigns a sequence number to the entry.
The optional keywords ge and le can be used to specify the range of the prefix length to be matched for prefixes that are more specific than network/len. An exact match is assumed when neither ge nor le is specified. The range is assumed to be from ge-value to 32 if only the ge attribute is specified, and from len to le-value if only the le attribute is specified.
A specified ge-value and/or le-value must satisfy the following condition:
len < ge-value <= le-value <= 32For example, to deny all prefixes matching /24 in 128.0.0.0/8, you would use:
ip prefix-list abc deny 128.0.0.0/8 ge 24 le 24
Note
Configure How Sequence Numbers of Prefix List Entries Are Specified
By default, the sequence numbers are automatically generated when you create a prefix list entry. Sequence numbers can be suppressed with the command no ip prefix-list sequence-number. Sequence values are generated in increments of 5. The first sequence value generated in a prefix list would be 5, then 10, then 15, and so on. If you specify a value for an entry and then do not specify values for subsequent entries, the assigned (generated) sequence values are incremented in units of five. For example, if you specify that the first entry in the prefix list have a sequence value of 3, and then do not specify sequence values for the other entries, the automatically generated numbers will be 8, 13, 18, and so on.
To disable the automatic generation of sequence numbers, use the following command:
no ip prefix-list sequence-number
Disables the automatic generation of the sequence numbers for prefix list entries.
To re-enable automatic generation of the sequence numbers of prefix list entries, use the following command in router configuration mode:
ip prefix-list sequence-number
Enables the automatic generation of the sequence numbers of prefix list entries. The default is enable.
If you disable automatic generation of sequence numbers in a prefix list, you must specify the sequence number for each entry using the seq-value argument of the ip prefix-list command.
Regardless of whether the default sequence numbers are used in configuring a prefix list, a sequence number does not need to be specified when de-configuring an entry. Show commands include the sequence numbers in their output.
Delete a Prefix List or Prefix List Entries
To delete a prefix list, use the following command in router configuration mode:
You can delete entries from a prefix list individually. To delete an entry in a prefix list, use the following command in router configuration mode:
Note
Show Prefix Entries
To display information about prefix tables, prefix table entries, the policy associated with a node, or specific information about an entry, use the following commands:
Clear the Hit Count Table of Prefix List Entries
To clear the hit count table of prefix list entries, use the following command in EXEC mode:
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, use the following commands beginning 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. There are two ways to disable next-hop processing:
•
•
Disable Next-Hop Processing Using a Specific Address
To disable next-hop processing and provide a specific address to be used instead of the next-hop address, use the following command in router configuration mode:
neighbor {ip-address | peer-group-name} next-hop-self
Disable next-hop processing on BGP updates to a neighbor.
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.
Disable Next-Hop Processing Using a Route Map
To override the inbound next hop setting for BGP routes and specify that the next hop of the matching routes is to be the IP address of the remote peer, or to set the peering address of the local router to be the next hop of the matching routes, use the neighbor next-hop-self command.
This approach is less cumbersome that configuring a specific address to be the next hop for BGP routes, especially at major interconnects, since each
To configure the neighbor peering address to be used for the next hop address, use the following route map configuration command:
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, use the following command in router configuration mode:
neighbor {ip-address | peer-group-name} version value
Specify the BGP version to use when communicating with a neighbor.
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. Use the following command 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.
Configure Advanced BGP Features
The tasks in this section are for configuring advanced BGP features.
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. Use the following command in router configuration mode:
neighbor {ip-address | peer-group-name} route-map route-map-name {in | out}
Apply a route map to incoming or outgoing routes.
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, use the following command 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, use one or more of the following commands 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, use the following command 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, use the following command in global configuration mode:
ip community-list community-list-number {permit | deny} community-number
Create a community list.
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 using the following command in router configuration mode:
To remove communities from the community attribute of an inbound or outbound update using a route map to filter and determine the communities to be deleted, use the following command in router configuration mode:
set comm-list list-num delete
Removes communities in a community attribute that match a standard or extended community list.
Note
Specify the Format for the Community
A BGP community is displayed in a two-part format two bytes long in the show ip bgp community command output, as well as wherever communities are displayed in the router configuration, such as router maps and community lists. In the most recent version of the RFC for BGP, a community is of the form AA:NN, where the first part is the AS number and the second part is a 2 byte number.The Cisco default community format is in the format NNAA.
To display BGP communities in the new format, use the following command in global configuration mode:
ip bgp-community new-format
Displays and parses BGP BGP communities in the format AA:NN.
Configuring BGP Conditional Advertisement
The BGP advertises routes from its routing table to external peers (peers in different autonomous systems) by default. The BGP Conditional Advertisement feature provides additional control of route advertisement depending on the existence of other prefixes in the BGP table. Normally, routes are propagated regardless of the existence of a different path. The BGP Conditional Advertisement feature uses the non-exist-map and the advertise-map to track routes by the route prefix. If a route prefix is not present in the non-exist-map, the route specified by the advertise-map is announced. The announced route is installed to the BGP routing table as a locally originated route and will behave as a locally originated route. The announced route will be originated by BGP only if the corresponding route exists in the BGP table. After the prefix is locally originated by BGP, BGP will advertise the prefix to internal and external peers. If the route prefix is present, the route in the advertise-map is not announced.
This feature can be useful in a multihomed network, in which some prefixes are to be advertised to one of the providers, only if information from the other provider is missing. This condition would indicate a failure in the peering session, or partial reachability.
Note
The Size of the Global BGP Table Is Reduced
If the same information is advertised to all providers in a multihomed environment, the information is duplicated in the global BGP table. When the BGP Conditional Advertisement feature is used, only partial routes are advertised to each provider, and the size of the global BGP table is not increased with redundant information.
Better Inbound Traffic Control
The user can guarantee the path that inbound traffic will follow because only specific paths are advertised to providers.
Note
BGP Conditional Advertisement Configuration Task List
See the following section for configuration tasks for the BGP Conditional Advertisement feature. Each task in the list indicates if the task is optional or required.
•
•
•
•
Conditional Advertisement of a Set of Routes
To conditionally advertise a set of routes, use the following commands begining in router configuration mode:
See the "BGP Conditional Advertisement Configuration Examples" section at the end of this chapter for an example configuration of BGP conditional advertisement.
Verifying BGP Conditional Advertisement feature
To verify that the BGP Condition Advertisement feature has been configured, use the show ip bgp neighbor command. The show ip bgp neighbor EXEC command will show the status of the BGP Conditional Advertisement feature as initialized or uninitialized.
The following example shows output from the show ip bgp neighbor EXEC command:
router# show ip bgp neigbor 172.17.1.1BGP neighbor is 172.17.1.1, remote AS 65200, internal linkDescription:link to boston as 65200BGP version 4, remote router ID 31.1.1.1BGP state = Established, up for 01:04:30Last read 00:00:30, hold time is 180, keepalive interval is 60 secondsNeighbor capabilities:Route refresh:advertised and receivedAddress family IPv4 Unicast:advertised and receivedReceived 83 messages, 0 notifications, 0 in queueSent 78 messages, 0 notifications, 0 in queueRoute refresh request:received 0, sent 0Minimum time between advertisement runs is 5 secondsFor address family:IPv4 UnicastBGP table version 18, neighbor version 18Index 2, Offset 0, Mask 0x4Inbound soft reconfiguration allowedNEXT_HOP is always this routerCommunity attribute sent to this neighborCondition-map old-route, Advertise-map new-route, status:Uninitialized2 accepted prefixes consume 72 bytesPrefix advertised 7, suppressed 0, withdrawn 4Connections established 1; dropped 0Last reset 01:05:29, due to Soft reconfig changeBGP Conditional Advertisement Troubleshooting Tips
This section provides troubleshooting information for the BGP conditional advertisement feature.
The BGP Conditional Advertisement feature is based on the nonexistence of a prefix and the advertisement of another. Normally, only two problems can occur:
•
•
The same method of troubleshooting is used for both problems:
•
•
The user needs to ensure that all of the characteristics specified in the route maps match the routes in the BGP table.
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, use the following command in router configuration mode:
In order to treat the neighbors from other autonomous systems within the confederation as special EBGP peers, use the following command in router configuration mode:
bgp confederation peers autonomous-system [autonomous-system ...]
Specify the autonomous systems that belong to the confederation.
See the "BGP Conditional Advertisement Configuration Examples" 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 30 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 31 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 32 More Complex BGP Route Reflector Model
When the route reflector receives an advertised route, depending on the neighbor, it does the following:
•
•
•
