Table Of Contents
Basic BGP Configuration Task List
Advanced BGP Configuration Task List
Configuring Basic BGP Features
Managing Routing Policy Changes
Resetting a Router Using BGP Dynamic Inbound Soft Reset
Resetting a Router Using BGP Outbound Soft Reset
Configuring BGP Soft Reset Using Stored Routing Policy Information
Configuring BGP Interactions with IGPs
Configuring BGP Route Filtering by Neighbor
Configuring BGP Filtering Using Prefix Lists
How the System Filters Traffic by Prefix List
Configuring a Prefix List Entry
Configuring How Sequence Numbers of Prefix List Entries Are Specified
Deleting a Prefix List or Prefix List Entries
Clearing the Hit Count Table of Prefix List Entries
Configuring BGP Path Filtering by Neighbor
Disabling Next-Hop Processing on BGP Updates
Disabling Next-Hop Processing Using a Specific Address
Disabling Next-Hop Processing Using a Route Map
Configuring the Multi Exit Discriminator Metric
Configuring Advanced BGP Features
Using Route Maps to Modify Updates
Resetting EBGP Connections Immediately upon Link Failure
Configuring Aggregate Addresses
Disabling Automatic Summarization of Network Numbers
Configuring BGP Community Filtering
Specifying the Format for the Community
Configuring BGP Conditional Advertisement
BGP Conditional Advertisement Configuration Task List
Conditional Advertisement of a Set of Routes
Verifying BGP Conditional Advertisement feature
BGP Conditional Advertisement Troubleshooting Tips
Configuring a Routing Domain Confederation
Assigning Options to the Peer Group
Making Neighbors Members of the Peer Group
Disabling a Peer or Peer Group
Modifying Parameters While Updating the IP Routing Table
Setting Administrative Distance
Changing the Default Local Preference Value
Redistributing Network 0.0.0.0
Configuring the Router to Consider a Missing MED as Worst Path
Selecting Path Based on MEDs from Other Autonomous Systems
Configuring the Router to Use the MED to Choose a Path from Sub-AS Paths
Configuring the Router to Use the MED to Choose a Path in a Confederation
Understanding Route Dampening Terms
Monitoring and Maintaining BGP Route Dampening
Monitoring and Maintaining BGP
Clearing Caches, Tables, and Databases
Displaying System and Network Statistics
Logging Changes in Neighbor Status
BGP Neighbor Configuration Examples
BGP Prefix List Filtering Examples
Route Filtering Configuration Example Using a Single Prefix List
Route Filtering Configuration Example Specifying a Group of Prefixes
Added or Deleted Prefix List Entries Examples
Dynamic Inbound Soft Reset Example
Inbound Soft Reset Using Stored Information Example
BGP Path Filtering by Neighbor Example
BGP Community with Route Maps Examples
BGP Conditional Advertisement Configuration Examples
TCP MD5 Authentication for BGP Example
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 Cisco IOS IP and IP Routing Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online. For multiprotocol BGP configuration information and examples, refer to the "Configuring Multiprotocol BGP Extensions for IP Multicast" chapter of the Cisco IOS IP and IP Routing Configuration Guide. For multiprotocol BGP command descriptions, refer to the "Multiprotocol BGP Extensions for IP Multicast Commands" chapter of the Cisco IOS IP and IP Routing Command Reference.
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 next-hop router address is used in the NEXT_HOP attribute, regardless of the autonomous system of that 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.
Note
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 Task List
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 Task List
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."
Configuring Basic BGP Features
The tasks in this section are for configuring basic BGP features.
Enabling BGP Routing
To enable BGP routing, establish a BGP routing process by using the following commands beginning in global configuration mode:
Note
Note
Configuring 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, beginning in router configuration mode:
Router(config-router)# neighbor {ip-address | peer-group-name} remote-as number
Specifies a BGP neighbor.
See the "BGP Neighbor Configuration Examples" section at the end of this chapter for an example of configuring BGP neighbors.
Managing Routing Policy Changes
Routing policies for a peer include all the configurations such as route-map, distribute-list, prefix-list, and filter-list that may impact inbound or outbound routing table updates. Whenever there is a change in the routing policy, the BGP session must be soft cleared, or soft reset, for the new policy to take effect. Performing inbound reset enables the new inbound policy to take effect. Performing outbound reset causes the new local outbound policy take effect without resetting the BGP session. As a new set of updates is sent during outbound policy reset, a new inbound policy of the neighbor can also take effect.
There are two types of reset, hard reset and soft reset. Table 7 lists the advantages and disadvantages hard reset and soft reset.
Table 7 Advantages and Disadvantages of Hard and Soft Resets
hard reset
No memory overhead.
The prefixes in the BGP, IP, and FIB tables provided by the neighbor are lost. Not recommended.
outbound soft reset
No configuration, no storing of routing table updates.
The procedure for an outbound reset is described in the section "Configuring BGP Soft Reset Using Stored Routing Policy Information."
Does not reset inbound routing table updates.
dynamic inbound soft reset
Does not clear the BGP session and cache.
Does not require storing of routing table updates, and has no memory overhead.
Both BGP routers must support the route refresh capability (in Cisco IOS Release 12.1 and later releases).
configured inbound soft reset (uses the neighbor soft-reconfiguration command)
Can be used when both BGP routers do not support the automatic route refresh capability.
Requires preconfiguration.
Stores all received (inbound) routing policy updates without modification; is memory-intensive.
Recommended only when absolutely necessary, such as when both BGP routers do not support the automatic route refresh capability.
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.
A soft reset updates the routing table for inbound and outbound routing updates. Cisco IOS software releases 12.1 and later support soft reset without any prior configuration. This soft reset allows the dynamic exchange of route refresh requests and routing information between BGP routers, and the subsequent re-advertisement of the respective outbound routing table.
•
•
To use soft reset without preconfiguration, both BGP peers must support the soft route refresh capability, which is advertised in the OPEN message sent when the peers establish a TCP session. Routers running Cisco IOS software releases prior to release 12.1 do not support the route refresh capability and must clear the BGP session using the neighbor soft-reconfiguration command, described in "Configuring BGP Soft Reset Using Stored Routing Policy Information." This will have a negative impact upon network operations and should only be used as a last resort.
Resetting a Router Using BGP Dynamic Inbound Soft Reset
If both the local BGP router and the neighbor router support the route refresh capability, you can perform a dynamic soft inbound reset. This type of reset has the following advantages over a soft inbound reset using stored routing update information:
•
•
To determine whether a router supports the route refresh capability, use the show ip bgp neighbors command, beginning in EXEC mode:
If all the BGP routers support the route refresh capability, you can use the dynamic soft reset method for resetting the inbound routing table. To perform a dynamic soft reset of the inbound routing table, use the clear ip bgp command beginning in EXEC mode:
See the "BGP Soft Reset Examples" section at the end of this chapter for examples of both types of BGP soft resets.
Resetting a Router Using BGP Outbound Soft Reset
Outbound soft resets do not require any preconfiguration. Using the keyword soft specifies that a soft reset be performed. To perform an outbound soft reset, use the clear ip bgp command, beginning in EXEC mode:
Configuring BGP Soft Reset Using Stored Routing Policy Information
If all of the BGP routers in the connection do not support the route refresh capability, use the soft reset method that generates a new set of inbound routing table updates from information previously stored. To initiate storage of inbound routing table updates, you must first preconfigure the router using the neighbor soft-reconfiguration command. The clear ip bgp command initiates the soft reset, which generates a new set of inbound routing table updates using the stored information.
Keep in mind that the memory requirements for storing the inbound update information can become quite large.To configure BGP soft reset using stored routing policy information, use the following commands, beginning in router 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.
Verifying BGP Soft Reset
You can verify whether a soft reset is successful by checking information about the routing table and about BGP neighbors.
Step 1
Router# show ip bgpBGP table version is 5, local router ID is 10.0.33.34Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path*> 1.0.0.0 0.0.0.0 0 32768 ?* 2.0.0.0 10.0.33.35 10 0 35 ?*> 0.0.0.0 0 32768 ?* 10.0.0.0 10.0.33.35 10 0 35 ?*> 0.0.0.0 0 32768 ?*> 192.168.0.0/16 10.0.33.35 10 0 35 ?Step 2
Router# show ip bgp neighbors 171.69.232.178BGP neighbor is 172.16.232.178, remote AS 35, external linkBGP version 4, remote router ID 192.168.3.3BGP state = Established, up for 1w1dLast read 00:00:53, hold time is 180, keepalive interval is 60 secondsNeighbor capabilities:Route refresh: advertised and receivedAddress family IPv4 Unicast: advertised and receivedAddress family IPv4 Multicast: advertised and receivedReceived 12519 messages, 0 notifications, 0 in queueSent 12523 messages, 0 notifications, 0 in queueRoute refresh request: received 0, sent 0Minimum time between advertisement runs is 30 secondsFor address family: IPv4 UnicastBGP table version 5, neighbor version 5Index 1, Offset 0, Mask 0x2Community attribute sent to this neighborInbound path policy configuredOutbound path policy configuredRoute map for incoming advertisements is uni-inRoute map for outgoing advertisements is uni-out3 accepted prefixes consume 108 bytesPrefix advertised 6, suppressed 0, withdrawn 0For address family: IPv4 MulticastBGP table version 5, neighbor version 5Index 1, Offset 0, Mask 0x2Inbound path policy configuredOutbound path policy configuredRoute map for incoming advertisements is mul-inRoute map for outgoing advertisements is mul-out3 accepted prefixes consume 108 bytesPrefix advertised 6, suppressed 0, withdrawn 0Connections established 2; dropped 1Last reset 1w1d, due to Peer closed the sessionConnection state is ESTAB, I/O status: 1, unread input bytes: 0Local host: 172.16.232.178, Local port: 179Foreign host: 172.16.232.179, Foreign port: 11002Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)Event Timers (current time is 0x2CF49CF8):Timer Starts Wakeups NextRetrans 12518 0 0x0TimeWait 0 0 0x0AckHold 12514 12281 0x0SendWnd 0 0 0x0KeepAlive 0 0 0x0GiveUp 0 0 0x0PmtuAger 0 0 0x0DeadWait 0 0 0x0iss: 273358651 snduna: 273596614 sndnxt: 273596614 sndwnd: 15434irs: 190480283 rcvnxt: 190718186 rcvwnd: 15491 delrcvwnd: 893SRTT: 300 ms, RTTO: 607 ms, RTV: 3 ms, KRTT: 0 msminRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 msFlags: passive open, nagle, gen tcbsDatagrams (max data segment is 1460 bytes):Rcvd: 24889 (out of order: 0), with data: 12515, total data bytes: 237921Sent: 24963 (retransmit: 0), with data: 12518, total data bytes: 237981
Configuring 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 no synchronization command, beginning in router configuration mode:
Router(config-router)# no synchronization
Disables synchronization between BGP and an IGP.
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. Incorrectly redistributing routes into BGP can result in the loss of critical information, such as the AS-path, that is required for BGP to function properly.
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.
Disabling AS Path Comparison
To prevent the router from considering the as-path length when selecting a route, use the bgp bestpath as-path ignore command, beginning in router configuration mode:
Router(config-router)# bgp bestpath as-path ignore
Configures the router to ignore as-path length in selecting a route.
Configuring BGP Route Filtering by Neighbor
You can filter BGP advertisements in two ways:
•
•
Filtering using prefix lists is described in the "Configuring BGP Filtering Using Prefix Lists" section.
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 neighbor distribute-list command, beginning 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. 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.
Creating a Prefix List
To create a prefix list, use the ip prefix-list command, beginning in router configuration mode:
Router(config-router)# 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 no ip prefix-list command, beginning in router configuration mode:
Router(config-router)# 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.
Configuring a Prefix List Entry
You can add entries to a prefix list individually. To configure an entry in a prefix list, use the ip prefix-list command, beginning in router configuration mode:
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
Configuring 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 no ip prefix-list sequence-number command, beginning in router configuration mode:
Router(config-router)# no ip prefix-list sequence-number
Disables the automatic generation of the sequence numbers for prefix list entries.
To reenable automatic generation of the sequence numbers of prefix list entries, use the ip prefix-list sequence number command, beginning in router configuration mode:
Router(config-router)# 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.
Deleting a Prefix List or Prefix List Entries
To delete a prefix list, use the no ip prefix-list command, beginning in router configuration mode:
You can delete entries from a prefix list individually. To delete an entry in a prefix list, use the no ip prefix-list seq command, beginning in router configuration mode:
Router(config-router)# no ip prefix-list seq seq-value
Deletes an entry in a prefix list.
Note
Showing 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, beginning in EXEC mode:
Clearing the Hit Count Table of Prefix List Entries
To clear the hit count table of prefix list entries, use the clear ip prefix-list command, beginning in EXEC mode:
Router# clear ip prefix-list name [network/len]
Clears the hit count table of the prefix list entries.
Configuring 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 Cisco IOS Dial Services 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.
Disabling 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:
•
•
Disabling 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 neighbor next-hop-self command, beginning in router configuration mode:
Router(config-router)# neighbor {ip-address | peer-group-name} next-hop-self
Disables next-hop processing on BGP updates to a neighbor.
Configuring this command causes the current router to advertise its peering address 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.
Disabling 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.
To configure the neighbor peering address to be used for the next hop address, use the set ip next-hop command, beginning in route map configuration mode:
Configuring 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 neighbor version command, beginning in router configuration mode:
Router(config-router)# neighbor {ip-address | peer-group-name} version value
Specifies the BGP version to use when communicating with a neighbor.
Configuring 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 default-metric command, beginning 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.
Configuring Advanced BGP Features
The tasks in this section are for configuring advanced BGP features.
Using 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 neighbor route-map command, beginning in router configuration mode:
Router(config-router)# neighbor {ip-address | peer-group-name} route-map route-map-name {in | out}
Applies 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.
Resetting 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 bgp fast-external-fallover command, beginning in router configuration mode:
Router(config-router)# bgp fast-external-fallover
Automatically resets EBGP sessions.
Configuring 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, beginning in router configuration mode:
See the "BGP Aggregate Route Examples" section at the end of this chapter for examples of using BGP aggregate routes.
Disabling 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 no auto-summary command, beginning in router configuration mode:
Configuring 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:
