Cisco IOS XR Routing Configuration Guide, Release 3.0 - Implementing BGP on Cisco IOS XR Software [Cisco Carrier Routing System]

Table Of Contents

Implementing BGP on Cisco IOS XR Software

Contents

Prerequisites for Implementing BGP on Cisco IOS XR Software

Information About Implementing BGP on Cisco IOS XR Software

BGP Functional Overview

Comparison of Cisco IOS BGP and Cisco IOS XR BGP

Routing Policy in Cisco IOX-XR BGP

Routing Policy Enforcement

BGP Router Identifier

BGP Default Limits

BGP Validation of Local Next-Hop Addresses

Configuration Grouping

Configuration Modes

Inheritance Rules

Inheritance show Commands

Update Groups

BGP Update Generation and Update Groups

BGP Update Group Configuration

How to Implement BGP on Cisco IOS XR Software

Monitoring BGP Update Groups

Configuration Examples for Implementing BGP on Cisco IOS XR Software

BGP Update Groups: Example

Where to Go Next

Additional References

Related Documents

Standards

RFCs

Technical Assistance

Implementing BGP on Cisco IOS XR Software

The Border Gateway Protocol (BGP) is an Exterior Gateway Protocol (EGP) that allows you to create loop-free interdomain routing between autonomous systems. An autonomous system is a set of routers under a single technical administration. Routers in an autonomous system can use multiple Interior Gateway Protocols (IGP) to exchange routing information inside the autonomous system and an EGP to route packets outside the autonomous system.

This module describes information that is unique to BGP for IPv4 and IPv6 implementation in Cisco IOS XR Software.

Feature History for the Implementing BGP on Cisco IOS XR Configuration Module

Release

Modification

Release 2.0

This feature was introduced.

Note For a complete description of the BGP commands listed in this module, refer to the "BGP Commands on Cisco IOS XR Software" module of the Cisco IOS XR Routing Command Reference publication. To locate documentation for other commands that appear in this module, search online in the individual index documents associated with the appropriate software product, such as the IP Security Software Product.

Contents

•Prerequisites for Implementing BGP on Cisco IOS XR Software

•Information About Implementing BGP on Cisco IOS XR Software

•How to Implement BGP on Cisco IOS XR Software

•Configuration Examples for Implementing BGP on Cisco IOS XR Software

•Where to Go Next

•Additional References

Prerequisites for Implementing BGP on Cisco IOS XR Software

You must be a member of a user group associated with the proper task IDs for routing commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide.

Information About Implementing BGP on Cisco IOS XR Software

To implement BGP you need to understand the following concepts:

•BGP Functional Overview

•Comparison of Cisco IOS BGP and Cisco IOS XR BGP

•Routing Policy in Cisco IOX-XR BGP

•Routing Policy Enforcement

•BGP Router Identifier

•BGP Default Limits

•BGP Validation of Local Next-Hop Addresses

•Configuration Grouping

•Update Groups

BGP Functional Overview

BGP uses TCP as its transport protocol. Two BGP routers form a TCP connection between one another (peer routers) and exchange messages to open and confirm the connection parameters.

BGP routers exchange network reachability information. This information is mainly an indication of the full paths (BGP autonomous system numbers) that a route should take in order to reach the destination network. This information helps in construction of a graph that shows which autonomous systems are loop-free and where routing policies can be applied to enforce restrictions on routing behavior.

Any two routers forming a TCP connection to exchange BGP routing information are called peers or neighbors. BGP peers initially exchange their full BGP routing tables. After this exchange, incremental updates are sent as the routing table changes. BGP keeps a version number of the BGP table, which is the same for all of its BGP peers. The version number changes whenever BGP updates the table due to routing information changes. Keepalive packets are sent to ensure that the connection is alive between the BGP peers and notification packets are sent in response to error or special conditions.

Comparison of Cisco IOS BGP and Cisco IOS XR BGP

Many legacy features found in Cisco IOS BGP are not found in Cisco IOS XR BGP. For example, BGP synchronization and BGP autosummary are not found in Cisco IOS XR BGP IPv4 or IPv6. Also, Cisco IOS XR BGP supports update groups and configuration grouping, but does not support peer groups (nor their configuration grouping analog, peer templates).

One important difference between Cisco IOS BGP and Cisco IOS XR BGP is that the latter has a neighbor-based command line interface (CLI). For more information, refer to the "Configuration Grouping" section.

Outbound router filter (ORF) is supported in Cisco IOS Release 12.2(4)T and is supported in Cisco IOS XR software. ORF-capable routers can use ORFs to prevent their peers from sending them routes that they will drop after applying an inbound prefix list. The ORF router sends its inbound prefix list to a neighbor (which must also be ORF-capable), and the neighbor executes the prefix list before sending routes back. Thus, any routes that do not pass the prefix list are not sent. Use of this feature saves bandwidth because less information is sent between the routers.

Graceful restart is supported in recent versions of Cisco IOS software (12.0S) and is supported in Cisco IOS XR software. Graceful restart is the mechanism by which BGP routing peers avoid changes to their forwarding paths following a switchover. If the BGP peer has received this capability, it is aware that the device sending the message is nonstop forwarding (NSF)-capable. Both the NSF-capable router and its BGP peers (NSF-aware peers) need to exchange the graceful restart capability in their OPEN messages, at the time of session establishment. If both peers do not exchange the graceful restart capability, the session will not be graceful restart-capable.

If the BGP session is lost during a Route Processor (RP) switchover or BGP process restart, the NSF-aware BGP peer marks all the routes associated with the NSF-capable router as stale; however, it continues to use these routes to make forwarding decisions for a set period of time. This functionality means that no packets are lost while the newly active RP is waiting for convergence of the routing information with its BGP peers.

After a failover event occurs, the NSF-capable router reestablishes the session with the BGP peer. In establishing the new session, it sends a new graceful restart message that identifies the NSF-capable router as having restarted.

At this point, the routing information is exchanged between the two BGP peers. Once this exchange is complete, the NSF-capable device uses the newly received routing information to update the RIB and the Forwarding Information Base (FIB) with the new forwarding information. The NSF-aware device uses the network information to remove stale routes from its BGP table. The BGP protocol is then fully converged.

If a BGP peer does not support the graceful restart capability, it will ignore the graceful restart capability in an OPEN message but will establish a BGP session with the NSF-capable device. This functionality will allow interoperability with non-NSF-aware BGP peers (and without NSF functionality), but the BGP session with non-NSF-aware BGP peers will not be graceful restart-capable.

Routing Policy in Cisco IOX-XR BGP

An important difference between Cisco IOS software and Cisco IOS XR software is in the application of routing policy for BGP. In Cisco IOS software, route maps, prefix lists, and AS-path filter lists are used to filter and modify BGP routes. These tools are used in various configuration and show commands in BGP. For example, they can be used to set inbound and outbound policy on a BGP neighbor, to set policy when routes are installed in the RIB, when routes are redistributed into BGP, or when aggregates are formed.

In Cisco IOS XR software, most route map usage is replaced by the routing policy language (RPL). More details about RPL can be found in Implementing Routing Policy Language in Cisco IOS XR Software. Table 1, Table 2, and Table 3 map route map commands once used with BGP to the RPL commands now used in their place. For full details of each command, please refer to the "BGP Commands on Cisco IOS XR Software" module of the Cisco IOS XR Routing Command Reference publication.s

Table 1 Mapping Route Map Commands in Neighbor Address-Family Configuration Submode to Routing Policy Commands

Route Map Command

Replaced by Routing Policy Command

advertise-map map {exist-map | non-exist-map} map

Retained—no replacement

default-originate route-map name

default-originate policy name

filter-list number [in | out]

policy name [in | out]

prefix-list name in

Retained—no replacement

prefix-list name out

policy name out

route-map name {in | out}

policy name {in | out}

unsuppress-map name

Retained—no replacement

Table 2 Mapping Route Map Commands in Global Address-Family Configuration Submode to Routing Policy Commands

Route Map Command

Replaced by Routing Policy Command

aggregate-address prefix advertise-map name

aggregate-address prefix policy name

aggregate-address prefix attribute-map name

aggregate-address prefix policy name

aggregate-address prefix suppress-map name

aggregate-address prefix policy name

bgp dampening route-map name

bgp dampening policy name

network prefix route-map name

network prefix policy name

redistribute protocol route-map name

redistribute protocol policy name

table-policy name

New command

Table 3 Mapping Route Map show Commands to Routing Policy show Commands

Route Map Command

Replaced by Routing Policy Command

show bgp community-list number

show bgp route-policy name

show bgp filter-list number

show bgp route-policy name

show bgp flap-statistics filter-list number

Retained—no replacement

show bgp prefix-list name

show bgp route-policy name

show bgp policy filter-list num

show bgp policy route-policy name

show bgp policy prefix-list name

show bgp policy route-policy name

show bgp policy route-map name

show bgp policy route-policy name

show bgp policy unsuppress-map name

Retained—no replacement

show bgp route-map name

show bgp route-policy name

One clear command—clear bgp flap-statistics filter-list number—is retained. No replacement is found in the RPL commands.

For the most part, using RPL is similar to using route maps. One important difference is that more verification is done with RPL to ensure that the policy is appropriate for the place in which it is being used. For instance, you cannot use an RPL policy in BGP if it has not been defined (using the route-policy command). Similarly, if a route policy tries to set the OSPF tag parameter, you cannot use it in BGP. Also, if a route policy sets the traffic-index parameter, you cannot use it as an inbound neighbor policy (because the traffic-index parameter applies only to routes being installed into the RIB). For full details, refer to Implementing Routing Policy Language in Cisco IOS XR Software.

Routing Policy Enforcement

External BGP (eBGP) neighbors must have an inbound and an outbound policy configured. If no policy is configured, no routes will be accepted from the neighbor, nor will any routes be advertised to it. This added security measure ensures that routes cannot accidentally be accepted or advertised in the case where a configuration error results in the intended policy being rejected.

Note This enforcement affects only eBGP neighbors (neighbors in a different autonomous system than this networking device). For internal BGP (iBGP) neighbors (neighbors in the same autonomous system), all routes will be accepted or advertised if there is no policy.

In the following example, for an eBGP neighbor, if all routes should be accepted and advertised with no modifications, configure a simple pass-all policy:
RP/0/0/CPU0:router# configuration
RP/0/0/CPU0:router(config)# route-policy pass-all
RP/0/0/CPU0:router(config-rpl)# pass
RP/0/0/CPU0:router(config-rpl)# end-policy
RP/0/0/CPU0:router(config)# commit
Use the policy command in the neighbor address-family configuration mode to apply the pass-all policy to a neighbor. The following example allows all IPv4 unicast routes to be received from neighbor 192.168.40.42, and advertises all IPv4 unicast routes back to it:
RP/0/0/CPU0:router(config)# router bgp 1
RP/0/0/CPU0:router(config-bgp)# neighbor 192.168.40.24
RP/0/0/CPU0:router(config-bgp-nbr)# remote-as 2
RP/0/0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
RP/0/0/CPU0:router(config-bgp-nbr-af)# policy pass-all in
RP/0/0/CPU0:router(config-bgp-nbr-af)# policy pass-all out
RP/0/0/CPU0:router(config-bgp-nbr-af)# commit
Use the show bgp summary command to display eBGP neighbors that do not have both an inbound and outbound policy for every active address family. In the following example, such eBGP neighbors are indicated in the output with an exclamation (!) mark:
RP/0/0/CPU0:router# show bgp summary
BGP router identifier 0.0.0.0, local AS number 1
BGP generic scan interval 60 secs
BGP main routing table version 1
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process         RecvTblVer    bRIB/RIB  SendTblVer
Speaker                  1           1           1
Some configured eBGP neighbors do not have any policy
configured (for some address family, either inbound or
outbound). Such neighbors will default to sending and/or
receiving no routes. These neighbors are marked with '!' in
the output below. Use 'show bgp neighbor <neighbor>'
for full details
Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  St/PfxRcd
10.0.0.1          0     2       0       0        0    0    0 00:00:00 Idle!
10.0.0.2          0     2       0       0        0    0    0 00:00:00 Idle
BGP Router Identifier

In order for neighbor sessions to be established, BGP must be assigned a router ID. The router ID is sent to BGP peers in the OPEN message when a BGP session is established.

BGP attempts to obtain a router ID in the following ways (in order of preference):

•By means of the address configured using the bgp router-id command in router configuration mode.

•By assigning a primary IPv4 address to the interface specified using the bgp router-id command in router configuration mode.

Note If the specified interface does not have an IPv4 address, or is not up, BGP will fail to obtain a router ID.

•By using the address specified with the router-id command in global configuration mode.

•By using the primary IPv4 address to the interface specified with the router-id command in global configuration mode.

•By using the highest IPv4 address on a loopback interface in the system.

If none of these methods for obtaining a router ID succeeds, BGP cannot obtain a router ID and cannot establish any peering sessions with BGP neighbors. In such instances, an error message is entered in the system log, and the show bgp summary command will display a router ID of 0.0.0.0.

After BGP has obtained router ID, it continues to use it even if a better router ID becomes available. This avoids unnecessary flapping for all the BGP sessions. However, if the router ID currently in use becomes invalid (because the interface goes down or its configuration is changed), BGP selects a new router ID (using the rules described) and all established peering sessions are reset.

It is strongly recommended that the bgp router-id command is configured to prevent unnecessary changes to the router ID (and consequent flapping of BGP sessions).

BGP Default Limits

Cisco IOS XR BGP imposes maximum limits on the number of neighbors that can be configured on the router and on the maximum number of prefixes that will be accepted from a peer for a given address family. This limitation safeguards the router from resource depletion caused by misconfiguration, either locally or on the remote neighbor. The following limits apply to BGP configurations:

•The maximum number of peers that can be configured is 1024. This number cannot be changed through configuration. Any attempt to configure additional peers beyond the limit will fail.

•In order to prevent a peer from flooding BGP with advertisements, a limit is placed on the number of prefixes that will be accepted from a peer for each supported address family. The default limits can be overridden through configuration of the maximum-prefix limit command for the peer for the appropriate address family. The following default limits are used if the user does not configure the maximum number of prefixes for the address family:

–512K (524,288) prefixes for IPv4 unicast.

–128K (131,072) prefixes for IPv4 multicast.

–128K (131,072) prefixes for IPv6 unicast.

A cease notification message will be sent to the neighbor and the peering with the neighbor will be terminated when the number of prefixes received from the peer for a given address family exceeds the maximum limit (either set by default or configured by the user) for that address family.

It is possible that the maximum number of prefixes for a neighbor for a given address family has been configured after the peering with the neighbor has been established and a certain number of prefixes have already been received from the neighbor for that address family. A cease notification message will be sent to the neighbor and peering with the neighbor will be terminated immediately after the configuration if the configured maximum number of prefixes is less than the number of prefixes that have already been received from the neighbor for the address family.

BGP Validation of Local Next-Hop Addresses

When Cisco IOS XR BGP receives a route advertisement from a neighbor, it validates the next-hop address contained in the route by verifying that the next-hop address is not the same as an IP address assigned to an interface on this router (for example, a local address). If the received next-hop address is a local address, the update is dropped. However, if the next-hop address is set to a local address by the configured inbound policy, the update is not dropped, is treated as a valid next-hop address, and is processed normally in Cisco IOS XR BGP. This means that the router will advertise to its neighbors that it has a route to the prefix, but any traffic received for that prefix will be dropped.

This "blackholing" effect is often used to automatically protect against Denial of Service (DOS) attacks on user hosts. An inbound policy is configured that sets the next hop to a local address (for example, the address of a loopback interface) when a route with a particular community is received. When a user finds that a host is under a DOS attack, a BGP advertisement is sent or the attacked host's address with the special community attached. This causes the Internet service provider (ISP) router to install a route with a local next hop for that address that drops all traffic destined for it.

Configuration Grouping

Cisco IOS XR BGP configuration grouping has the following significant CLI changes from the BGP Cisco IOS software Release 12.2 configuration grouping:

•Cisco IOS XR software has a new submode available for neighbors. It is not necessary for every command to have a "neighbor x.x.x.x" prefix.

In Cisco IOS XR software, the configuration is as follows:
Router(config-bgp-af)# neighbor 192.23.1.2
Router(config-bgp-nbr)# remote-as 2002
Router(config-bgp-nbr)# address-family ipv4 multicast
•A new address family configuration submode inside the neighbor configuration submode is available for entering address family-specific neighbor configurations. This new submode replaces the ability in Cisco IOS Release 12.2 to enter neighbor address-family configuration mode in the global address-family submode. In Cisco IOS XR, the configuration is as follows:
Router(config-bgp-af)# neighbor 2002::2
Router(config-bgp-nbr)# remote-as 2002
Router(config-bgp-nbr)# address-family ipv6 unicast
Router(config-bgp-nbr-af)# next-hop-self
Router(config-bgp-nbr-af)# policy one in
•You must enter neighbor-specific IPv4 unicast commands in neighbor address-family configuration submode. This submode replaces the ability in Cisco IOS Release 12.2 to enter IPv4 unicast commands directly in neighbor configuration submode. In Cisco IOS XR software, the configuration is as follows:
Router(config-bgp)# router bgp 109
Router(config-bgp)# neighbor 192.168.40.24
Router(config-bgp-nbr)# remote-as 1
Router(config-bgp-nbr)# address-family ipv4 unicast
Router(config-bgp-nbr-af)# maximum-prefix 1000
•Commands relating to a peer group found in Cisco IOS Release 12.2 have been removed from Cisco IOS XR software. Instead, the af-group, session-group, and neighbor-group configuration commands are added to support the neighbor in Cisco IOS XR software:

–The af-group command is used to group address family-specific neighbor commands within an IPv4 or IPv6 address family. Neighbors that have the same address family configuration are able to use the address family group name for their address family-specific configuration. A neighbor inherits the configuration from an address family group by way of the use command. If a neighbor is configured to use an address family group, the neighbor will (by default) inherit the entire configuration from the address family group. However, a neighbor will not inherit all of the configuration from the address family group if items are explicitly configured for the neighbor.

–The session-group command allows you to create a session group from which neighbors can inherit address family-independent configuration. A neighbor inherits the configuration from a session group by way of the use command. If a neighbor is configured to use a session group, the neighbor (by default) inherits the session group's entire configuration. A neighbor does not inherit all the configuration from a session group if a configuration is done directly on that neighbor.

–The neighbor-group command helps you apply the same configuration to one or more neighbors. Neighbor groups can include session groups and address family groups. This additional flexibility can create a complete configuration for a neighbor. Once a neighbor group is configured, each neighbor can inherit the configuration through the use command. If a neighbor is configured to use a neighbor group, the neighbor (by default) inherits the neighbor group's entire BGP configuration.

–However, a neighbor will not inherit all of the configuration from the neighbor group if items are explicitly configured for the neighbor. In addition, some part of the neighbor group's configuration could be hidden if a session group or address family group was also being used.

Configuration grouping has the following effects in Cisco IOS XR software:

•Commands entered at the session group level define address family-independent commands (the same commands as in the neighbor submode).

•Commands entered at the address family-group level define address family-dependent commands for a specified address family (the same commands as in the neighbor-address family configuration submode).

•Commands entered at the neighbor group level define address family-independent commands and address family-dependent commands for each address family (the same as all available neighbor commands), and the use command for the address family group and session group commands.

Configuration Modes

The following sections show you how to enter each of the configuration modes. From there, you can enter the ? command to display the commands available in that mode.

Router Configuration Mode

The following example shows you how to enter router configuration mode:
RP/0/RP0/CPU0:router# configuration
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# 
Global Address Family Configuration Mode

The following example shows you how to enter global address family configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 multicast
RP/0/RP0/CPU0:router(config-bgp-af)#
Neighbor Configuration Mode

The following example shows you how to enter neighbor configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# neighbor 10.0.0.1
RP/0/RP0/CPU0:router(config-bgp-nbr)#
Neighbor Address Family Configuration Mode

The following example shows you how to enter neighbor address family configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# neighbor 10.0.0.1
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbr-af)#
Address Family Group Configuration Mode

The following example shows you how to enter address family group configuration mode.
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# af-group afmcast1 address-family ipv4 multicast
RP/0/RP0/CPU0:router(config-bgp-afgrp)#
Session Group Configuration Mode

The following example shows you how to enter session group configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# session-group session1
RP/0/RP0/CPU0:router(config-bgp-sngrp)# 
Neighbor Group Configuration Mode

The following example shows you how to enter neighbor group configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group nbrgroup1
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)#
Neighbor Group Address Family Configuration Mode

The following example shows you how to enter neighbor group address family configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group nbrgroup1
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbrgrp-af)#
Inheritance Rules

Certain inheritance rules differ from those in Cisco IOS Release 12.2 in the manner that neighbors or groups inherit configuration from other neighbors or groups.

For address family-independent configurations:

•Neighbors can inherit from session groups and neighbor groups.

•Neighbor groups can inherit from session groups and other neighbor groups.

•Session groups can inherit from other session groups.

For address family-specific configurations:

•Address family groups can inherit from other address family groups.

•Neighbor groups can inherit from address family groups and other neighbor groups.

•Neighbors can inherit from address family groups and neighbor groups.

Configuration rules are numbered as follows:

1. If the item is configured directly on the neighbor, that value is used. In the example that follows, the advertisement interval is configured both on the neighbor group and neighbor configuration and the advertisement interval being used is from the neighbor configuration:
router bgp 140
  neighbor-group AS_1
    advertisement-interval 15
  !
  neighbor 10.1.1.1
	remote-as 1
    use neighbor-group AS_1
    advertisement-interval 20
  !
!
The following output from the show bgp neighbors command shows that the advertisement interval used is 20:
RP/0/RP0/CPU0:router# show bgp neighbors 10.1.1.1
BGP neighbor is 10.1.1.1, remote AS 1, local AS 140, external link
 Remote router ID 0.0.0.0
  BGP state = Idle
  Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
  Received 0 messages, 0 notifications, 0 in queue
  Sent 0 messages, 0 notifications, 0 in queue
  Minimum time between advertisement runs is 20 seconds
 For Address Family: IPv4 Unicast
  BGP neighbor version 0
  Update group: 0.1
  eBGP neighbor with no inbound or outbound policy; defaults to 'drop'
  Route refresh request: received 0, sent 0
  0 accepted prefixes
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 524288
  Threshold for warning message 75%
  Connections established 0; dropped 0
  Last reset 00:00:14, due to BGP neighbor initialized
  External BGP neighbor not directly connected.
2. Otherwise, if the neighbor belongs to a session group or address family group, the configuration value is obtained from the session group or address family group. In the example that follows, the advertisement interval is configured on a neighbor group and a session group and the advertisement interval value being used is from the session group:
router bgp 140
 session-group AS_2
  advertisement-interval 15
 !
 neighbor-group AS_1
  advertisement-interval 20
 !
 neighbor 192.168.0.1
  remote-as 1
  use session-group AS_2
  use neighbor-group AS_1
 !
!
RP/0/RP0/CPU0:router# show bgp neighbors 192.168.0.1
BGP neighbor is 192.168.0.1, remote AS 1, local AS 140, external link
 Remote router ID 0.0.0.0
  BGP state = Idle
  Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
  Received 0 messages, 0 notifications, 0 in queue
  Sent 0 messages, 0 notifications, 0 in queue
  Minimum time between advertisement runs is 15 seconds
 For Address Family: IPv4 Unicast
  BGP neighbor version 0
  Update group: 0.1
  eBGP neighbor with no inbound or outbound policy; defaults to 'drop'
  Route refresh request: received 0, sent 0
  0 accepted prefixes
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 524288
  Threshold for warning message 75%
  Connections established 0; dropped 0
  Last reset 00:03:23, due to BGP neighbor initialized
  External BGP neighbor not directly connected.
3. Otherwise, if the neighbor uses a neighbor group, and does not use a session group or af-group, the configuration value is obtained from the neighbor group. In the example that follows, the advertisement interval from the neighbor group is being used because it is not configured directly on the neighbor and no session group is used:
router bgp 150
 session-group AS_2
  advertisement-interval 20
 !
 neighbor-group AS_1
  advertisement-interval 15
 !
neighbor 192.168.1.1
 remote-as 1
 use neighbor-group AS_1
 !
!
RP/0/RP0/CPU0:router# show bgp neighbors 192.168.1.1
BGP neighbor is 192.168.2.2, remote AS 1, local AS 140, external link
 Remote router ID 0.0.0.0
  BGP state = Idle
  Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
  Received 0 messages, 0 notifications, 0 in queue
  Sent 0 messages, 0 notifications, 0 in queue
  Minimum time between advertisement runs is 15 seconds
 For Address Family: IPv4 Unicast
  BGP neighbor version 0
  Update group: 0.1
  eBGP neighbor with no outbound policy; defaults to 'drop'
  Route refresh request: received 0, sent 0
  Inbound path policy configured
  Policy for incoming advertisements is POLICY_1
  0 accepted prefixes
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 524288
  Threshold for warning message 75%
  Connections established 0; dropped 0
  Last reset 00:01:14, due to BGP neighbor initialized
  External BGP neighbor not directly connected.
To illustrate the same rule, the following example sets the advertisement interval to 15 (from the session group). The timers are set to the default (60/180) because the neighbor uses a session group, thus hiding the timers command in the neighbor group. The inbound policy is set to POLICY_1 from the neighbor group.
router bgp 140
  session-group ADV
    advertisement-interval 15
  !
  neighbor-group TIMER
    timers 10 30
    address-family ipv4 unicast
      policy POLICY_1 in
    !
  !
  neighbor 192.168.2.2
    remote-as 1
    use session-group ADV
    use neighbor-group TIMER
  !
! 
RP/0/RP0/CPU0:router# show bgp neighbors 192.168.2.2
BGP neighbor is 192.168.2.2, remote AS 1, local AS 140, external link
 Remote router ID 0.0.0.0
  BGP state = Idle
  Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
  Received 0 messages, 0 notifications, 0 in queue
  Sent 0 messages, 0 notifications, 0 in queue
  Minimum time between advertisement runs is 15 seconds
 For Address Family: IPv4 Unicast
  BGP neighbor version 0
  Update group: 0.1
  eBGP neighbor with no inbound or outbound policy; defaults to 'drop'
  Route refresh request: received 0, sent 0
  0 accepted prefixes
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 524288
  Threshold for warning message 75%
  Connections established 0; dropped 0
  Last reset 00:02:03, due to BGP neighbor initialized
  External BGP neighbor not directly connected.
4. Otherwise, the default value is used. In the example that follows, neighbor 10.0.101.5 has the minimum time between advertisement runs set to 30 seconds (default) because the neighbor is not configured to use the neighbor configuration or the neighbor group configuration:
router bgp 140
 neighbor-group AS_1
  remote-as 1
 !
 neighbor-group adv_15
  remote-as 10
  advertisement-interval 15
 !
 neighbor 10.0.101.5
  use neighbor-group AS_1
 !
 neighbor 10.0.101.10
  use neighbor-group adv_15
 !
!
RP/0/0/CPU0:router# show bgp neighbors 10.0.101.5
BGP neighbor is 10.0.101.5, remote AS 1, local AS 140, external link
 Remote router ID 0.0.0.0
  BGP state = Idle
  Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
  Received 0 messages, 0 notifications, 0 in queue
  Sent 0 messages, 0 notifications, 0 in queue
  Minimum time between advertisement runs is 30 seconds
 For Address Family: IPv4 Unicast
  BGP neighbor version 0
  Update group: 0.2
  eBGP neighbor with no inbound or outbound policy; defaults to 'drop'
  Route refresh request: received 0, sent 0
  0 accepted prefixes
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 524288
  Threshold for warning message 75%
  Connections established 0; dropped 0
  Last reset 00:00:25, due to BGP neighbor initialized
  External BGP neighbor not directly connected.
The inheritance rules used when groups are inheriting configuration from other groups are the same as the rules given for neighbors inheriting from groups.

Inheritance show Commands

You can use the commands described in the following sections to monitor BGP inheritance information:

•show bgp neighbors

•show bgp af-group

•show bgp session-group

•show bgp neighbor-group

show bgp neighbors

Use the show bgp neighbors command to display information about the BGP configuration for neighbors.

•Use the configuration option to display the effective configuration for the neighbor, including any settings that have been inherited from session groups, neighbor groups, or af-groups used by this neighbor.

•Use the inheritance option to display the session groups, neighbor groups, and af-groups from which this neighbor inherits configuration settings.

The show bgp neighbors command examples that follow are based on the this sample configuration:
af-group GROUP_3 address-family ipv4 unicast
 next-hop-self
 policy POLICY_1 in
!
session-group GROUP_2
 advertisement-interval 15
!
neighbor-group GROUP_1
 use session-group GROUP_2
 ebgp-multihop 3
 address-family ipv4 unicast
  weight 100
  send-community-ebgp
 !
 address-family ipv4 multicast
  default-originate
 !
!
neighbor 192.168.0.1
 remote-as 2
 use neighbor-group GROUP_1
 address-family ipv4 unicast
  use af-group GROUP_3
  weight 200
 !
!
The following example displays sample output from the show bgp neighbors command using the inheritance keyword. The example shows that the neighbor inherits session parameters from neighbor group GROUP_1, which in turn inherits from session group GROUP_2. The neighbor inherits IPv4 unicast parameters from address family group GROUP_3 and IPv4 multicast parameters from neighbor group GROUP_1:
RP/0/0/CPU0:router# show bgp neighbors 192.168.0.1 inheritance 
  Session:        n:GROUP_1 s:GROUP_2
  IPv4 Unicast:   a:GROUP_3
  IPv4 Multicast: n:GROUP_1
The following example displays sample output from the show bgp neighbors command using the configuration keyword. The example shows where each item of configuration was inherited from, or if it was configured directly on the neighbor (indicated by [ ]). For example, the ebgp-multihop 3 command was inherited from neighbor group GROUP_1 and the next-hop-self command was inherited from the address family group GROUP_3:
RP/0/0/CPU0:router# show bgp neighbors 192.168.0.1 configuration 
neighbor 192.168.0.1
 remote-as 2                   []
 advertisement-interval 15     [n:GROUP_1 s:GROUP_2]
 ebgp-multihop 3               [n:GROUP_1]
 address-family ipv4 unicast   []
  next-hop-self                [a:GROUP_3]
  policy POLICY_1    in        [a:GROUP_3]
  weight 200                   []
 address-family ipv4 multicast [n:GROUP_1]
  default-originate            [n:GROUP_1]
show bgp af-group

Use the show bgp af-group command to display address family groups:

•Use the configuration option to display the effective configuration for the af-group, including any settings that have been inherited from af-groups used by this af-group.

•Use the inheritance option to display the af-groups from which this af-group inherits configuration settings.

•Use the users option to display the neighbors, neighbor groups, and af-groups that inherit configuration from this af-group.

The show bgp af-group command examples that follow are based on the this sample configuration:
af-group GROUP_3 address-family ipv4 unicast
 remove-private-as
 policy POLICY_1 in
!
af-group GROUP_1 address-family ipv4 unicast
 use af-group GROUP_2
 maximum-prefix 2500 75 warning-only
 default-originate
!
af-group GROUP_2 address-family ipv4 unicast
 use af-group GROUP_3
 send-community-ebgp
 send-extended-community-ebgp
 capability orf prefix-list both
!
The following example displays sample output from the show bgp af-group command using the configuration keyword. This example shows where each configuration item was inherited from. The default-originate command was configured directly on this address family group (indicated by [ ]). The remove-private-as command was inherited from address family group GROUP_2, which in turn inherited from address family group GROUP_3:
RP/0/0/CPU0:router# show bgp af-group GROUP_1 configuration 
af-group GROUP_1 address-family ipv4 unicast
  capability orf prefix-list both           [a:GROUP_2]
  default-originate                         []
  maximum-prefix 2500 75 warning-only       []
  policy POLICY_1 in                        [a:GROUP_2 a:GROUP_3]
  remove-private-AS                         [a:GROUP_2 a:GROUP_3]
  send-community-ebgp                       [a:GROUP_2]
  send-extended-community-ebgp              [a:GROUP_2]
The following example displays sample output from the show bgp af-group command using the users keyword:
RP/0/RP0/CPU0:router# show bgp af-group GROUP_2 users
IPv4 Unicast: a:GROUP_1
The following example displays sample output from the show bgp af-group command using the inheritance keyword. This shows that the specified address family group GROUP_1 directly uses the GROUP_2 address family group, which in turn uses the GROUP_3 address family group:
RP/0/RP0/CPU0:router# show bgp af-group GROUP_1 inheritance 
IPv4 Unicast: a:GROUP_2 a:GROUP_3
show bgp session-group

Use the show bgp session-group command to display session groups:

•Use the configuration option to display the effective configuration for the session group, including any settings that have been inherited from session groups used by this session group.

•Use the inheritance option to display the session groups from which this session group inherits configuration settings.

•Use the users option to display the session groups, neighbor groups, and neighbors that inherit configuration from this session group.

The following is sample output from the show bgp session-group command with the configuration option in EXEC mode. The examples are based on the following session group configuration:
session-group GROUP_1
  use session-group GROUP_2
  update-source Loopback 0
 !
 session-group GROUP_2
  use session-group GROUP_3
  ebgp-multihop 2
 !
 session-group GROUP_3
  dmzlink-bw
 !
The following is sample output from the show bgp session-group command with the configuration keyword in EXEC mode:
RP/0/RP0/CPU0:router# show bgp session-group GROUP_1 configuration          
session-group GROUP_1
 ebgp-multihop 2         [s:GROUP_2]
 update-source Loopback0 []
 dmzlink-bw              [s:GROUP_2 s:GROUP_3]
The following is sample output from the show bgp session-group command with the inheritance keyword showing that the GROUP_1 session group inherits session parameters from the GROUP_3 and GROUP_2 session groups:
RP/0/RP0/CPU0:router# show bgp session-group GROUP_1 inheritance 
Session: s:GROUP_2 s:GROUP_3
The following is sample output from the show bgp session-group command with the users keyword showing that both the GROUP_1 and GROUP_2 session groups inherit session parameters from the GROUP_3 session group:
RP/0/RP0/CPU0:router# show bgp session-group GROUP_3 users
Session: s:GROUP_1 s:GROUP_2
show bgp neighbor-group

Use the show bgp neighbor-group command to display neighbor groups:

•Use the configuration option to display the effective configuration for the neighbor group, including any settings that have been inherited from neighbor groups used by this neighbor group.

•Use the inheritance option to display the af-groups, session groups, and neighbor groups from which this neighbor group inherits configuration settings.

•Use the users option to display the neighbors and neighbor groups that inherit configuration from this neighbor group.

The examples are based on the following group configuration:
af-group GROUP_3 address-family ipv4 unicast
 remove-private-as
 soft-reconfiguration inbound
!
af-group GROUP_2 address-family ipv4 unicast
 use af-group GROUP_3
 send-community-ebgp
 send-extended-community-ebgp
 capability orf prefix-list both
!
session-group GROUP_3
 timers 30 90
!
neighbor-group GROUP_1
 remote-as 1982
 use neighbor-group GROUP_2
 address-family ipv4 unicast
 !
!
neighbor-group GROUP_2
 use session-group GROUP_3
 address-family ipv4 unicast
  use af-group GROUP_2
  weight 100
 !
!
The following is sample output from the show bgp neighbor-group command with the configuration keyword. The configuration setting source is shown to the right of each configuration command. In the output shown previously, the remote autonomous systems is configured directly on neighbor group GROUP_1, and the send community setting is inherited from neighbor group GROUP_2, which in turn inherits the setting from af-group GROUP_3:
RP/0/RP0/CPU0# show bgp neighbor-group GROUP_1 configuration 
   neighbor-group GROUP_1
    remote-as 1982                   []
    timers 30 90                     [n:GROUP_2 s:GROUP_3]
    address-family ipv4 unicast      []
     capability orf prefix-list both [n:GROUP_2 a:GROUP_2]
     remove-private-AS               [n:GROUP_2 a:GROUP_2 a:GROUP_3]
     send-community-ebgp             [n:GROUP_2 a:GROUP_2]
     send-extended-community-ebgp    [n:GROUP_2 a:GROUP_2]
     soft-reconfiguration inbound    [n:GROUP_2 a:GROUP_2 a:GROUP_3]
     weight 100                      [n:GROUP_2]
The following is sample output from the show bgp neighbor-group command with the inheritance keyword. This output shows that the specified neighbor group GROUP_1 inherits session (address family-independent) configuration parameters from neighbor group GROUP_2. Neighbor group GROUP_2 inherits its session parameters from session group GROUP_3. It also shows that the GROUP_1 neighbor group inherits IPv4 unicast configuration parameters from the GROUP_2 neighbor group, which in turn inherits them from the GROUP_2 address family group, which itself inherits them from the GROUP_3 address family group:
RP/0/RP0/CPU0:router# show bgp neighbor-group GROUP_1 inheritance
    Session:      n:GROUP-2 s:GROUP_3
    IPv4 Unicast: n:GROUP_2 a:GROUP_2 a:GROUP_3
The following is sample output from the show bgp neighbor-group command with the users option. This output shows that the GROUP_1 neighbor group inherits session (address family-independent configuration parameters) from the GROUP_2 neighbor group. The GROUP_1 neighbor group also inherits IPv4 unicast configuration parameters from the GROUP_2 neighbor group:
RP/0/RP0/CPU0:router# show bgp neighbor-group GROUP_2 users
Session:      n:GROUP_1
IPv4 Unicast: n:GROUP_1
Update Groups

The BGP Update Groups feature introduces a new algorithm that dynamically calculates and optimizes update groups of neighbors that share outbound policies and can share the update messages. Until recently in Cisco IOS software, BGP update messages were grouped based on peer group configurations. This method of grouping updates limited outbound policies and specific-session configurations. The BGP Update Groups feature separates update group replication from peer group configuration, improving convergence time and flexibility of neighbor configuration.

To use this feature, you must understand the following concepts:

•BGP Update Generation and Update Groups

•BGP Update Group Configuration

BGP Update Generation and Update Groups

BGP update messages in Cisco IOS software were grouped based on peer-group configurations. This method of grouping neighbors for BGP update message generation reduced the amount of system processing resources needed to scan the routing table. This method, however, had the following limitations:

•All neighbors that shared the peer group configuration also had to share the outbound routing policies.

•All neighbors that could share the update messages had to belong to the peer group and address family. Neighbors configured in different peer groups could not share the update messages.

These limitations existed to balance optimal update generation and replication against peer group configuration. These limitations also caused the network operator to configure smaller peer groups, which reduced the efficiency of update message generation.

The BGP Update Groups feature separates BGP update generation from peer configuration. The BGP Update Groups feature introduces an algorithm that dynamically calculates BGP update group membership based on outbound routing policies. This feature does not require any configuration by the network operator. Optimal BGP update message generation occurs automatically and independently. BGP neighbor configuration is no longer restricted by outbound routing policies.

BGP Update Group Configuration

The BGP Update Group feature requires no configuration and occurs automatically. When a change to the configuration occurs, the router automatically recalculates update group memberships and applies the changes.

For the best optimization of BGP update group generation, we recommend that the network operator keeps outbound routing policy the same for neighbors that have similar outbound policies. This feature introduces new commands for monitoring BGP update groups. For more information about the new commands, see the "Monitoring BGP Update Groups" section.

How to Implement BGP on Cisco IOS XR Software

Basic BGP configuration in Cisco IOS XR is the same as basic BGP configuration in Cisco IOS Release 12.2. The following BGP configuration task is significantly different:

•Monitoring BGP Update Groups

Monitoring BGP Update Groups

This task displays information related to the processing of BGP update groups.

SUMMARY STEPS

1. show bgp update-group [{ipv4 | ipv6 | all}{unicast | multicast | all]} update-group [neighbor ip-address | process id.index [summary | performance-statistics]]

DETAILED STEPS
Command or Action

Purpose
Step 1
show bgp [{ipv4 | ipv6 | all}{unicast | multicast | all]} update-group [neighbor ip-address | process id.index [summary | performance-statistics]]
Example:

RP/0/RP0/CPU0:router# show bgp update-group
Displays information about BGP update groups.

•The process-id.index argument is used to select a particular update group to display and is specified as follows: process id (dot) index. Process ID range is from 0 to 254. Index range is from 0 to 4294967295.

•The ip-address argument is used to display the update groups to which that neighbor belongs.

•The summary keyword is used to display summary information for neighbors in a particular update group.

•If no argument is specified, this command will display information for all update groups (for the specified address family).

•The performance-statistics keyword is used to display performance statistics for an update group.
Configuration Examples for Implementing BGP on Cisco IOS XR Software

This section provides the following configuration example:

•BGP Update Groups: Example

BGP Update Groups: Example
The following is sample output from the show bgp update-group command executed in EXEC mode:
RP/0/RP0/CPU0:router# show bgp update-group
Update group for IPv4 Unicast, index 0.1:
  Attributes:
    Outbound Route map:rm
    Minimum advertisement interval:30
  Messages formatted:2, replicated:2
  Neighbors in this update group:
    10.0.101.92
Update group for IPv4 Unicast, index 0.2:
  Attributes:
    Minimum advertisement interval:30
  Messages formatted:2, replicated:2
  Neighbors in this update group:
    10.0.101.91
Where to Go Next

For detailed information about BGP commands, refer to the Cisco IOS XR Routing Command Reference document.

Additional References

The following sections provide references related to implementing BGP for Cisco IOS XR software.

Related Documents

Related Topic

Document Title

BGP commands

Cisco IOS XR Routing Command Reference

BGP deployment

BGP Case Studies

BGP RFCs and internet drafts

Locate under the BGP IETF working group NB: IDR

Cisco CRS-1 Series Carrier Routing System Router Interface

Cisco CRS-1 Series Carrier Routing System Router Interface Configuration Guide

Cisco CRS-1 Series Carrier Routing System Craft Web Interface (CWI)

Cisco CRS-1 Series Carrier Routing System Craft Web Interface (CWI) Configuration

Standards

Standards

Title

No new or modified standards are supported by the features in this document, and support for existing standards has not been modified by the features in this document.

—

RFCs

RFCs

Title

RFC 1657

Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2

RFC 1771

A Border Gateway Protocol 4

RFC 1997

BGP Communities Attribute

RFC 2385

Protection of BGP Sessions via the TCP MD5 Signature Option

RFC 2439

BGP Route Flap Damping

RFC 2545

Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing

RFC 2796

BGP Route Reflection - An Alternative to Full Mesh IBGP

RFC 2858

Multiprotocol Extensions for BGP-4

RFC 2918

Route Refresh Capability for BGP-4

RFC 3065

Autonomous System Confederations for BGP

RFC 3392

Capabilities Advertisement with BGP-4

Technical Assistance

Description

Link

Technical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/public/support/tac/home.shtml