Cisco IOS XR Routing Configuration Guide for the Cisco CRS Router, Release 6.1.x
- Implementing
BGP [Cisco Carrier Routing System] - Cisco
Cisco IOS XR Routing Configuration Guide for the Cisco CRS Router, Release 6.1.x
Book Contents
Book Contents
Available Languages
Download Options
Book Title
Cisco IOS XR Routing Configuration Guide for the Cisco CRS Router, Release 6.1.x
Chapter Title
Implementing
View with Adobe Reader on a variety of devices
Chapter: Implementing
Chapter Contents
Implementing
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 (IGPs) to
exchange routing information inside the autonomous system and an EGP to route
packets outside the autonomous system.
This module provides
the conceptual and configuration information for BGP on Cisco IOS XR software.
For more information
on the Cisco IOS XR software
and complete descriptions of the BGP commands listed in this
module, see
section of this module. To locate documentation for other commands that might
appear while performing a configuration task, search online in the
Cisco IOS XR
software master command index.
Feature History
for Implementing BGP
Modification
Prerequisites for Implementing BGP
You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
Information About Implementing BGP
To implement BGP, you need to understand the following concepts:
BGP Functional
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 to
reach the destination network. This information helps construct 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.
For information on
configuring BGP to distribute Multiprotocol Label Switching (MPLS) Layer 3
virtual private network (VPN) information, see the Cisco IOS XR Multiprotocol
Label Switching Configuration Guide for the Cisco CRS-1 Router.
For information on
BGP support for Bidirectional Forwarding Detection (BFD), see the
Cisco IOS XR
Interface and Hardware Configuration Guide for the Cisco CRS-1 Router and
Cisco IOS XR
Interface and Hardware Command Reference for the Cisco CRS-1 Router.
BGP Router Identifier
For BGP sessions between neighbors 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 using the highest IPv4 address on a loopback interface in the system if the router is booted with saved loopback address configuration.
By using the primary IPv4 address of the first loopback address that gets configured if there are not any in the saved configuration.
If none of these methods for obtaining a router ID succeeds, BGP does not have a router ID and cannot establish any peering sessions with BGP neighbors. In such an instance, an error message is entered in the system log, and the show bgp summary command displays a router ID of 0.0.0.0.
After BGP has obtained a router ID, it continues to use it even if a better router ID becomes available. This usage avoids unnecessary flapping for all 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.
We strongly recommend that the bgp router-id command is configured to prevent unnecessary changes to the router ID (and consequent flapping of BGP sessions).
BGP Maximum Prefix -
Discard Extra Paths
IOS XR BGP
maximum-prefix feature imposes a maximum limit on the number of prefixes that
are received from a neighbor for a given address family. Whenever the number of
prefixes received exceeds the maximum number configured, the BGP session is
terminated, which is the default behavior, after sending a cease notification
to the neighbor. The session is down until a manual clear is performed by the
user. The session can be resumed by using the
command. It is possible to configure a period after which the session can be
automatically brought up by using the
maximum-prefix
command with the
keyword. The maximum prefix limit can be configured by the user. Default limits
are used if the user does not configure the maximum number of prefixes for the
address family. For default limits, refer to
Discard Extra Paths
An option to discard
extra paths is added to the maximum-prefix configuration. Configuring the
discard extra paths option drops all excess prefixes received from the neighbor
when the prefixes exceed the configured maximum value. This drop does not,
however, result in session flap.
The benefits of
discard extra paths option are:
Limits the memory
footstamp of BGP.
flapping of the peer if the paths exceed the set limit.
When the discard extra
paths configuration is removed, BGP sends a route-refresh message to the
neighbor if it supports th otherwise the session is
On the same lines, the
following describes the actions when the maximum prefix value is changed:
If the maximum
value alone is changed, a route-refresh message is sourced, if applicable.
If the new maximum
value is greater than the current prefix count state, the new prefix states are
If the new maximum
value is less than the current prefix count state, then some existing prefixes
are deleted to match the new configured state value.
There is currently no
way to control which prefixes are deleted.
For detailed
configuration steps, see
Restrictions
These restrictions
apply to the discard extra paths feature:
When the router
drops prefixes, it is inconsistent with the rest of the network, resulting in
possible routing loops.
If prefixes are
dropped, the standby and active BGP sessions may drop different prefixes.
Consequently, an NSR switchover results in inconsistent BGP tables.
The discard extra
paths configuration cannot co-exist with the
reconfig configuration.
BGP Default
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 are 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 default
maximum number of peers that can be configured is 4000. The default can be
changed using the
maximum neighbor command. The
range is 1 to 15000. Any attempt to configure additional
peers beyond the maximum limit or set the maximum limit to a number that is
less than the number of peers currently configured will fail.
To prevent a peer from
flooding BGP with advertisements, a limit is placed on the number of prefixes
that are 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:
IPv4 Unicast:
Labeled-unicast: 131072
IPv4 Tunnel:
Unicast: 524288
Labeled-unicast: 131072
Multicast: 131072
Multicast: 131072
IPv4 MVPN: 2097152
Unicast: 2097152
Unicast: 1048576
L2VPN EVPN:
notification message is sent to the neighbor and the peering with the neighbor
is 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 is sent to the neighbor
and peering with the neighbor is terminated immediately after the configuration
if the configured maximum number of prefixes is fewer than the number of
prefixes that have already been received from the neighbor for the address
BGP Next Hop
BGP receives
notifications from the Routing Information Base (RIB) when next-hop information
changes (event-driven notifications). BGP obtains next-hop information from the
Determine whether
a next hop is reachable.
Find the fully
recursed IGP metric to the next hop (used in the best-path calculation).
Validate the
received next hops.
Calculate the
outgoing next hops.
Verify the
reachability and connectedness of neighbors.
BGP is notified when
any of the following events occurs:
Next hop becomes
unreachable
Next hop becomes
Fully recursed IGP
metric to the next hop changes
First hop IP
address or first hop interface change
Next hop becomes
Next hop becomes
unconnected
Next hop becomes a
local address
Next hop becomes a
nonlocal address
Reachability and
recursed metric events trigger a best-path recalculation.
Event notifications
from the RIB are classified as critical and noncritical. Notifications for
critical and noncritical events are sent in separate batches. However, a
noncritical event is sent along with the critical events if the noncritical
event is pending and there is a request to read the critical events.
Critical events
are related to the reachability (reachable and unreachable), connectivity
(connected and unconnected), and locality (local and nonlocal) of the next
hops. Notifications for these events are not delayed.
Noncritical events
include only the IGP metric changes. These events are sent at an interval of 3
seconds. A metric change event is batched and sent 3 seconds after the last one
The next-hop trigger
delay for critical and noncritical events can be configured to specify a
minimum batching interval for critical and noncritical events using the
trigger-delay command. The trigger delay is address family dependent.
The BGP next-hop
tracking feature allows you to specify that BGP routes are resolved using only
next hops whose routes have the following characteristics:
To avoid the
aggregate routes, the prefix length must be greater than a specified value.
The source
protocol must be from a selected list, ensuring that BGP routes are not used to
resolve next hops that could lead to oscillation.
This route policy
filtering is possible because RIB identifies the source protocol of route that
resolved a next hop as well as the mask length associated with the route. The
route-policy command is used to specify the route-policy.
For information on
route policy filtering for next hops using the next-hop attach point, see the
Implementing
Routing Policy Language on
Cisco IOS XR
Software module of
Cisco IOS XR
Configuration
Guide (this
publication).
Next Hop as the IPv6 Address of Peering Interface
BGP can carry IPv6 prefixes over an IPv4 session. The next hop for the IPv6 prefixes can be set through a nexthop policy. In the event that the policy is not configured, the nexthops are set as the IPv6 address of the peering interface (IPv6 neighbor interface or IPv6 update source interface, if any one of the interfaces is configured).
If the nexthop policy is not configured and neither the IPv6 neighbor interface nor the IPv6 update source interface is configured, the next hop is the IPv4 mapped IPv6 address.
Scoped IPv4/VPNv4 Table
To determine which
address family to process, a next-hop notification is received by first
de-referencing the gateway context associated with the next hop, then looking
into the gateway context to determine which address families are using the
gateway context. The IPv4 unicast
address families share the same gateway context, because they are
registered with the IPv4 unicast table in the RIB. As a result,
the global IPv4 unicast table
VPNv4 table are
processed when an IPv4 unicast next-hop notification is received
from the RIB. A mask is maintained in the next hop, indicating
whether the next
hop belongs to IPv4 unicast or VPNv4 unicast, or
both. This scoped table walk localizes the processing in the appropriate
address family table.
Reordered Address
Family Processing
Cisco IOS XR software walks address family tables based on
the numeric value of the address family. When a next-hop notification batch is
received, the order of address family processing is reordered to the following
IPv4 tunnel
VPNv4 unicast
VPNv6 unicast
IPv4 labeled
IPv4 unicast
IPv4 multicast
IPv6 unicast
IPv6 multicast
IPv6 labeled unicast
New Thread for Next-Hop Processing
The critical-event thread in the spkr process handles only next-hop, Bidirectional Forwarding Detection (BFD), and fast-external-failover (FEF) notifications. This critical-event thread ensures that BGP convergence is not adversely impacted by other events that may take a significant amount of time.
show, clear, and
debug Commands
nexthops command provides statistical information about next-hop
notifications, the amount of time spent in processing those notifications, and
details about each next hop registered with the RIB. The
nexthop performance-statistics command ensures that the cumulative
statistics associated with the processing part of the next-hop
command can be cleared to help in monitoring. The
nexthop registration command performs an asynchronous registration of
the next hop with the RIB. See the
BGP Commands on
Cisco IOS XR Software
Cisco IOS XR Routing Command Reference for the Cisco CRS
Routerfor information on the next-hop
clear commands.
nexthop command displays information on next-hop processing. The
out keyword
provides debug information only about BGP registration of next hops with RIB.
keyword displays debug information about next-hop notifications
received from RIB. The
keyword displays debug information about next-hop notifications
sent to the RIB. See the
BGP Debug Commands
Cisco IOS XR Software
Cisco IOS XR
Routing Debug Command Reference for the Cisco CRS-1 Router
Autonomous System Number Formats in BGP
Autonomous system numbers (ASNs) are globally unique identifiers used to identify autonomous systems (ASs) and enable ASs to exchange exterior routing information between neighboring ASs. A unique ASN is allocated to each AS for use in BGP routing. ASNs are encoded as 2-byte numbers and 4-byte numbers in BGP.
2-byte Autonomous System Number Format
The 2-byte ASNs are represented in asplain notation. The 2-byte range is 1 to 65535.
4-byte Autonomous System Number Format
To prepare for the eventual exhaustion of 2-byte Autonomous System Numbers (ASNs), BGP has the capability to support 4-byte ASNs. The 4-byte ASNs are represented both in asplain and asdot notations.
The byte range for 4-byte ASNs in asplain notation is 1-. The AS is represented as a 4-byte decimal number. The 4-byte ASN asplain representation is defined in .
For 4-byte ASNs in asdot format, the 4-byte range is 1.0 to
and the format is:
high-order-16-bit-value-in-decimal . low-order-16-bit-value-in-decimal
The BGP 4-byte ASN capability is used to propagate 4-byte-based AS path information across BGP speakers that do not support 4-byte AS numbers. See
for information on increasing the size of an ASN from 2 bytes to 4 bytes. AS is represented as a 4-byte decimal number
as-format Command
The as-format command configures the ASN notation to asdot. The default value, if the as-format command is not configured, is asplain.
BGP Configuration
BGP in Cisco IOS XR software follows a neighbor-based configuration model that requires that all configurations for a particular neighbor be grouped in one place under the neighbor configuration. Peer groups are not supported for either sharing configuration between neighbors or for sharing update messages. The concept of peer group has been replaced by a set of configuration groups to be used as templates in BGP configuration and automatically generated update groups to share update messages between neighbors.
Configuration Modes
BGP configurations are grouped into modes. The following sections show how to enter some of the BGP configuration modes. From a mode, you can enter the
command to display the commands available in that mode.
Router Configuration Mode
The following example shows 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)#
Router Address
Family Configuration Mode
The following example
shows how to enter router address family configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 112
RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-af)#
Neighbor Configuration Mode
The following example shows 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 how to enter neighbor address family configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 112
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)#
VRF Configuration Mode
The following example shows how to enter VPN routing and forwarding (VRF) configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# vrf vrf_A
RP/0/RP0/CPU0:router(config-bgp-vrf)#
VRF Address Family Configuration Mode
The following example shows how to enter VRF address family configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 112
RP/0/RP0/CPU0:router(config-bgp)# vrf vrf_A
RP/0/RP0/CPU0:router(config-bgp-vrf)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-vrf-af)#
Configuring Resilient Per-CE Label Allocation Mode Under VRF Address Family
Perform this task to configure resilient per-ce label allocation mode under VRF address family.
Resilient per-CE 6PE label allocation is not supported on CRS-1 and CRS-3 routers, but supported only on CRS-X routers.
SUMMARY STEPS1.
router bgpas-number
vrfvrf-instance
address-family {ipv4 | ipv6} unicast
label mode per-ce
Do one of the following:
DETAILED STEPSStep 1
configure Example:
RP/0/RP0/CPU0:router# configure
RP/0/RP0/CPU0:router(config)#
Enters global configuration mode.
router bgpas-number Example:
RP/0/RP0/CPU0:router(config)# router bgp 666
RP/0/RP0/CPU0:router(config-bgp)#
Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process.
vrfvrf-instance Example:
RP/0/RP0/CPU0:router(config-bgp)# vrf vrf-pe
RP/0/RP0/CPU0:router(config-bgp-vrf)#
Configures a VRF instance.
address-family {ipv4 | ipv6} unicast Example:
RP/0/RP0/CPU0:router(config-bgp-vrf)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-vrf-af)#
Specifies either an IPv4 or IPv6 address family unicast and enters address family configuration submode.
label mode per-ce Example:
RP/0/RP0/CPU0:router(config-bgp-vrf-af)# label mode per-ce
RP/0/RP0/CPU0:router(config-bgp-vrf-af)#
Configures resilient per-ce label allocation mode.
Do one of the following:
RP/0/RP0/CPU0:router(config-bgp-vrf-af)# end
RP/0/RP0/CPU0:router(config-bgp-vrf-af)# commit
Saves configuration changes.
When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting(yes/no/cancel)?[cancel]:
Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Configuring Resilient Per-CE Label Allocation Mode Using a Route-Policy
Perform this task to configure resilient per-ce label allocation mode using a route-policy.
Resilient per-CE 6PE label allocation is not supported on CRS-1 and CRS-3 routers, but supported only on CRS-X routers.
SUMMARY STEPS1.
route-policypolicy-name
set label mode per-ce
Do one of the following:
DETAILED STEPSStep 1
configure Example:
RP/0/RP0/CPU0:router# configure
RP/0/RP0/CPU0:router(config)#
Enters global configuration mode.
route-policypolicy-name Example:
RP/0/RP0/CPU0:router(config)# route-policy route1
RP/0/RP0/CPU0:router(config-rpl)#
Creates a route policy and enters route policy configuration mode.
set label mode per-ce Example:
RP/0/RP0/CPU0:router(config-rpl)# set label mode per-ce
RP/0/RP0/CPU0:router(config-rpl)#
Configures resilient per-ce label allocation mode.
Do one of the following:
RP/0/RP0/CPU0:router(config-rpl)# end
RP/0/RP0/CPU0:router(config-rpl)# commit
Saves configuration changes.
When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting(yes/no/cancel)?[cancel]:
Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
VRF Neighbor Configuration Mode
The following example shows how to enter VRF neighbor configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# vrf vrf_A
RP/0/RP0/CPU0:router(config-bgp-vrf)# neighbor 11.0.1.2
RP/0/RP0/CPU0:router(config-bgp-vrf-nbr)#
VRF Neighbor Address Family Configuration Mode
The following example shows how to enter VRF neighbor address family configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 112
RP/0/RP0/CPU0:router(config-bgp)# vrf vrf_A
RP/0/RP0/CPU0:router(config-bgp-vrf)# neighbor 11.0.1.2
RP/0/RP0/CPU0:router(config-bgp-vrf-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-vrf-nbr-af)#
VPNv4 Address Family Configuration Mode
The following example shows how to enter VPNv4 address family configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 152
RP/0/RP0/CPU0:router(config-bgp)# address-family vpnv4 unicast
RP/0/RP0/CPU0:router(config-bgp-af)#
VPNv6 Address Family Configuration Mode
The following example shows how to enter VPNv6 address family configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 150
RP/0/RP0/CPU0:router(config-bgp)# address-family vpnv6 unicast
RP/0/RP0/CPU0:router(config-bgp-af)#
L2VPN Address Family Configuration Mode
The following example shows how to enter L2VPN address family configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 100
RP/0/RP0/CPU0:router(config-bgp)# address-family l2vpn vpls-vpws
RP/0/RP0/CPU0:router(config-bgp-af)#
Cisco IOS XR BGP uses a neighbor submode to make it
possible to enter configurations without having to prefix every configuration
keyword and the neighbor address:
Cisco IOS XR software has a submode available for
neighbors in which it is not necessary for every command to have a “neighbor
x.x.x.x” prefix:
Cisco IOS XR software, the configuration is as
RP/0/RP0/CPU0:router(config-bgp)# neighbor 192.23.1.2
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 2002
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
An address family
configuration submode inside the neighbor configuration submode is available
for entering address family-specific neighbor configurations. In
Cisco IOS XR software, the configuration is as
RP/0/RP0/CPU0:router(config-bgp)# neighbor 2002::2
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 2023
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv6 unicast
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# next-hop-self
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# route-policy one in
You must enter
neighbor-specific IPv4, IPv6, VPNv4, or VPNv6 commands in neighbor
address-family configuration submode. In
Cisco IOS XR software, the configuration is as follows:
RP/0/RP0/CPU0:router(config)# router bgp 109
RP/0/RP0/CPU0:router(config-bgp)# neighbor 192.168.40.24
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 1
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# maximum-prefix 1000
You must enter
neighbor-specific IPv4 and IPv6 commands in VRF neighbor address-family
configuration submode. In
Cisco IOS XR software, the configuration is as follows:
RP/0/RP0/CPU0:router(config)# router bgp 110
RP/0/RP0/CPU0:router(config-bgp)# vrf vrf_A
RP/0/RP0/CPU0:router(config-bgp-vrf)# neighbor 11.0.1.2
RP/0/RP0/CPU0:router(config-bgp-vrf-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-vrf-nbr-af)# route-policy pass all in
Configuration
session-group, and neighbor-group
configuration commands provide template support for the neighbor configuration
Cisco IOS XR software.
af-group command is used to group address
family-specific neighbor commands within an IPv4, IPv6,
VPNv4,or VPNv6 address family. Neighbors that have the same
address family configuration are able to use the address family group
(af-group) name for their address family-specific configuration. A neighbor
inherits the configuration from an address family group by way of the
command. If a neighbor is configured to use an address family group, the
neighbor (by default) inherits the entire configuration from the address family
group. However, a neighbor does not inherit all of the configuration from the
address family group if items are explicitly configured for the neighbor. The
address family group configuration is entered under the BGP router
configuration mode. The following example shows 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 unicast
RP/0/RP0/CPU0:router(config-bgp-afgrp)#
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
command. If a neighbor is configured to use a session group, the neighbor (by
default) inherits the entire configuration of the session group. A neighbor
does not inherit all of the configuration from a session group if a
configuration is done directly on that neighbor. The following example shows
how to enter session group configuration mode:
RP/0/RP0/CPU0:router# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# session-group session1
RP/0/RP0/CPU0:router(config-bgp-sngrp)#
neighbor-group command helps you apply the same
configuration to one or more neighbors. Neighbor groups can include session
groups and address family groups and can comprise the complete configuration
for a neighbor. After a neighbor group is configured, a neighbor can inherit
the configuration of the group using the
command. If a neighbor is configured to use a neighbor group, the neighbor
inherits the entire BGP configuration of the neighbor group.
The following example
shows how to enter neighbor group configuration mode:
RP/0/RP0/CPU0:router(config)# router bgp 123
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group nbrgroup1
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)#
The following example
shows 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)#
However, a
neighbor does not inherit all of the configuration from the neighbor group if
items are explicitly configured for the neighbor. In addition, some part of the
configuration of the neighbor group 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
neighbor commands), and define the
use command for the address family group and session
group commands.
Template Inheritance Rules
In Cisco IOS XR software, BGP neighbors or groups inherit configuration from other configuration 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.
If a neighbor uses a session group and a neighbor group, the configurations in the session group are preferred over the global address family configurations in the neighbor group.
For address family-dependent 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 group inheritance rules are numbered in order of precedence as follows:
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:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group AS_1
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# advertisement-interval 15
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor 10.1.1.1
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 1
RP/0/RP0/CPU0:router(config-bgp-nbr)# use neighbor-group AS_1
RP/0/RP0/CPU0:router(config-bgp-nbr)# advertisement-interval 20
The following output from the show bgp neighbors command shows that the advertisement interval used is 20 seconds:
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 inboun 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.
Otherwise, if an item is configured to be inherited from a session-group or neighbor-group and on the neighbor directly, then the configuration on the neighbor is used. If a neighbor is configured to be inherited from session-group or af-group, but no directly configured value, then the value in the session-group or af-group is used. 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:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# session-group AS_2
RP/0/RP0/CPU0:router(config-bgp-sngrp)# advertisement-interval 15
RP/0/RP0/CPU0:router(config-bgp-sngrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group AS_1
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# advertisement-interval 20
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor 192.168.0.1
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 1
RP/0/RP0/CPU0:router(config-bgp-nbr)# use session-group AS_2
RP/0/RP0/CPU0:router(config-bgp-nbr)# use neighbor-group AS_1
The following output from the show bgp neighbors command shows that the advertisement interval used is 15 seconds:
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 inboun 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.
Otherwise, if the neighbor uses a neighbor group and does not use a session group or address family group, the configuration value can be obtained from the neighbor group either directly or through inheritance. In the example that follows, the advertisement interval from the neighbor group is used because it is not configured directly on the neighbor and no session group is used:
RP/0/RP0/CPU0:router(config)# router bgp 150
RP/0/RP0/CPU0:router(config-bgp)# session-group AS_2
RP/0/RP0/CPU0:router(config-bgp-sngrp)# advertisement-interval 20
RP/0/RP0/CPU0:router(config-bgp-sngrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group AS_1
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# advertisement-interval 15
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor 192.168.1.1
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 1
RP/0/RP0/CPU0:router(config-bgp-nbr)# use neighbor-group AS_1
The following output from the show bgp neighbors command shows that the advertisement interval used is 15 seconds:
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 wit 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 shows how to set the advertisement interval to 15 (from the session group) and 25 (from the neighbor group). The advertisement interval set in the session group overrides the one set in the neighbor group. The inbound policy is set to POLICY_1 from the neighbor group.
RP/0/RP0/CPU0:routerconfig)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# session-group ADV
RP/0/RP0/CPU0:router(config-bgp-sngrp)# advertisement-interval 15
RP/0/RP0/CPU0:router(config-bgp-sngrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group ADV_2
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# advertisement-interval 25
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbrgrp-af)# route-policy POLICY_1 in
RP/0/RP0/CPU0:router(config-bgp-nbrgrp-af)# exit
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor 192.168.2.2
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 1
RP/0/RP0/CPU0:router(config-bgp-nbr)# use session-group ADV
RP/0/RP0/CPU0:router(config-bgp-nbr)# use neighbor-group ADV_2
The following output from the show bgp neighbors command shows that the advertisement interval used is 15 seconds:
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 inboun 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.
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:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group AS_1
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# remote-as 1
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group adv_15
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# remote-as 10
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# advertisement-interval 15
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor 10.0.101.5
RP/0/RP0/CPU0:router(config-bgp-nbr)# use neighbor-group AS_1
RP/0/RP0/CPU0:router(config-bgp-nbr)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor 10.0.101.10
RP/0/RP0/CPU0:router(config-bgp-nbr)# use neighbor-group adv_15
The following output from the show bgp neighbors command shows that the advertisement interval used is 30 seconds:
RP/0/RP0/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 inboun 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.
Viewing Inherited Configurations
You can use the following show commands to view BGP inherited configurations:
command to display information about the BGP configuration for
neighbors.
configuration keyword to display the effective
configuration for the neighbor, including any settings that have been inherited
from session groups, neighbor groups, or address family groups used by this
inheritance keyword to display the session groups,
neighbor groups, and address family groups from which this neighbor is capable
of inheriting configuration.
neighbors command examples that follow are based on this sample
configuration:
RP/0/RP0/CPU0:router(config)# router bgp 142
RP/0/RP0/CPU0:router(config-bgp)# af-group GROUP_3 address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-afgrp)# next-hop-self
RP/0/RP0/CPU0:router(config-bgp-afgrp)# route-policy POLICY_1 in
RP/0/RP0/CPU0:router(config-bgp-afgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# session-group GROUP_2
RP/0/RP0/CPU0:router(config-bgp-sngrp)# advertisement-interval 15
RP/0/RP0/CPU0:router(config-bgp-sngrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group GROUP_1
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# use session-group GROUP_2
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# ebgp-multihop 3
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbrgrp-af)# weight 100
RP/0/RP0/CPU0:router(config-bgp-nbrgrp-af)# send-community-ebgp
RP/0/RP0/CPU0:router(config-bgp-nbrgrp-af)# exit
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor 192.168.0.1
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 2
RP/0/RP0/CPU0:router(config-bgp-nbr)# use neighbor-group GROUP_1
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# use af-group GROUP_3
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# weight 200
The following example
displays sample output from the
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/RP0/CPU0:router# show bgp neighbors 192.168.0.1 inheritance
n:GROUP_1 s:GROUP_2
IPv4 Unicast:
IPv4 Multicast: n:GROUP_1
The following example
displays sample output from the
neighbors command using the
configuration
keyword. The example shows from where each item of configuration
was inherited, 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/RP0/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]
route-policy POLICY_1
[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 keyword to display the effective configuration for the address family group, including any settings that have been inherited from address family groups used by this address family group.
Use the inheritance keyword to display the address family groups from which this address family group is capable of inheriting configuration.
Use the users keyword to display the neighbors, neighbor groups, and address family groups that inherit configuration from this address family group.
The show bgp af-group sample commands that follow are based on this sample configuration:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# af-group GROUP_3 address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-afgrp)# remove-private-as
RP/0/RP0/CPU0:router(config-bgp-afgrp)# route-policy POLICY_1 in
RP/0/RP0/CPU0:router(config-bgp-afgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# af-group GROUP_1 address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-afgrp)# use af-group GROUP_2
RP/0/RP0/CPU0:router(config-bgp-afgrp)# maximum-prefix 2500 75 warning-only
RP/0/RP0/CPU0:router(config-bgp-afgrp)# default-originate
RP/0/RP0/CPU0:router(config-bgp-afgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# af-group GROUP_2 address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-afgrp)# use af-group GROUP_3
RP/0/RP0/CPU0:router(config-bgp-afgrp)# send-community-ebgp
RP/0/RP0/CPU0:router(config-bgp-afgrp)# send-extended-community-ebgp
RP/0/RP0/CPU0:router(config-bgp-afgrp)# capability orf prefix both
The following example displays sample output from the
show bgp af-group
command using the
configuration
keyword. This example shows from where each configuration item was inherited. 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/RP0/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
route-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
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
session-group
session-group command to display session groups:
configuration keyword to display the effective
configuration for the session group, including any settings that have been
inherited from session groups used by this session group.
inheritance keyword to display the session groups from
which this session group is capable of inheriting configuration.
users keyword to display the session groups, neighbor
groups, and neighbors that inherit configuration from this session group.
The output from the
session-group command is based on the following session group
configuration:
RP/0/RP0/CPU0:router(config)# router bgp 113
RP/0/RP0/CPU0:router(config-bgp)# session-group GROUP_1
RP/0/RP0/CPU0:router(config-bgp-sngrp)# use session-group GROUP_2
RP/0/RP0/CPU0:router(config-bgp-sngrp)# update-source Loopback 0
RP/0/RP0/CPU0:router(config-bgp-sngrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# session-group GROUP_2
RP/0/RP0/CPU0:router(config-bgp-sngrp)# use session-group GROUP_3
RP/0/RP0/CPU0:router(config-bgp-sngrp)# ebgp-multihop 2
RP/0/RP0/CPU0:router(config-bgp-sngrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# session-group GROUP_3
RP/0/RP0/CPU0:router(config-bgp-sngrp)# dmz-link-bandwidth
The following is
sample output from the
session-group command with the
configuration
keyword in
configuration
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 []
dmz-link-bandwidth
[s:GROUP_2 s:GROUP_3]
The following is
sample output from the
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
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
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 keyword 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 keyword to display the address family groups, session groups, and neighbor groups from which this neighbor group is capable of inheriting configuration.
Use the users keyword to display the neighbors and neighbor groups that inherit configuration from this neighbor group.
The examples are based on the following group configuration:
RP/0/RP0/CPU0:router(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# af-group GROUP_3 address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-afgrp)# remove-private-as
RP/0/RP0/CPU0:router(config-bgp-afgrp)# soft-reconfiguration inbound
RP/0/RP0/CPU0:router(config-bgp-afgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# af-group GROUP_2 address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-afgrp)# use af-group GROUP_3
RP/0/RP0/CPU0:router(config-bgp-afgrp)# send-community-ebgp
RP/0/RP0/CPU0:router(config-bgp-afgrp)# send-extended-community-ebgp
RP/0/RP0/CPU0:router(config-bgp-afgrp)# capability orf prefix both
RP/0/RP0/CPU0:router(config-bgp-afgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# session-group GROUP_3
RP/0/RP0/CPU0:router(config-bgp-sngrp)# timers 30 90
RP/0/RP0/CPU0:router(config-bgp-sngrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group GROUP_1
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# remote-as 1982
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# use neighbor-group GROUP_2
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbrgrp-af)# exit
RP/0/RP0/CPU0:router(config-nbrgrp)# exit
RP/0/RP0/CPU0:router(config-bgp)# neighbor-group GROUP_2
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# use session-group GROUP_3
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# address-family ipv4 unicast
RP/0/RP0/CPU0:routerconfig-bgp-nbrgrp-af)# use af-group GROUP_2
RP/0/RP0/CPU0:router(config-bgp-nbrgrp-af)# 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 command. In the output shown previously, the remote autonomous system 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 address family group GROUP_3:
RP/0/RP0/CPU0:router# 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
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
keyword. 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
IPv4 Unicast: n:GROUP_1
No Default Address Family
BGP does not support the concept of a default address family. An address family must be explicitly configured under the BGP router configuration for the address family to be activated in BGP. Similarly, an address family must be explicitly configured under a neighbor for the BGP session to be activated under that address family. It is not required to have any address family configured under the BGP router configuration level for a neighbor to be configured. However, it is a requirement to have an address family configured at the BGP router configuration level for the address family to be configured under a neighbor.
Neighbor Address Family Combinations
For default VRF, starting from Cisco IOS XR Software Release 6.2.x, both IPv4 Unicast and IPv4 Labeled-unicast address families are supported under the same neighbor.
For non-default VRF, both IPv4 Unicast and IPv4 Labeled-unicast address families are not supported under the same neighbor. However, the configuration is accepted on the Cisco ASR 9000 Series Router with the following error:
bgp[1051]: %ROUTING-BGP-4-INCOMPATIBLE_AFI : IPv4 Unicast and IPv4 Labeled-unicast Address families together are not supported under the same neighbor.
Routing Policy
Enforcement
External BGP (eBGP)
neighbors must have an inbound and outbound policy configured. If no policy is
configured, no routes are accepted from the neighbor, nor are any routes
advertised to it. This added security measure ensures that routes cannot
accidentally be accepted or advertised in the case of a configuration omission
This enforcement
affects only eBGP neighbors (neighbors in a different autonomous system than
this router). For internal BGP (iBGP) neighbors (neighbors in the same
autonomous system), all routes are accepted or advertised if there is no
In the following
example, for an eBGP neighbor, if all routes should be accepted and advertised
with no modifications, a simple pass-all policy is configured:
RP/0/RP0/CPU0:router(config)# route-policy pass-all
RP/0/RP0/CPU0:router(config-rpl)# pass
RP/0/RP0/CPU0:router(config-rpl)# end-policy
RP/0/RP0/CPU0:router(config)# commit
route-policy
command in the neighbor address-family configuration mode to
apply the pass-all policy to a neighbor. The following example shows how to
allow all IPv4 unicast routes to be received from neighbor 192.168.40.42 and
advertise all IPv4 unicast routes back to it:
RP/0/RP0/CPU0:router(config)# router bgp 1
RP/0/RP0/CPU0:router(config-bgp)# neighbor 192.168.40.24
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as 21
RP/0/RP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# route-policy pass-all in
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# route-policy pass-all out
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# commit
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
RP/0/RP0/CPU0:router# show bgp all all summary
Address Family: IPv4 Unicast
============================
BGP router identifier 10.0.0.1, local AS number 1
BGP generic scan interval 60 secs
BGP main routing table version 41
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
RecvTblVer
SendTblVer
AS MsgRcvd MsgSent
InQ OutQ Up/Down
10.0.101.1
0 15:15:08
10.0.101.2
0 00:00:00 Idle
Address Family: IPv4 Multicast
==============================
BGP router identifier 10.0.0.1, 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.
RecvTblVer
SendTblVer
Some configured eBGP neighbors do not have both inbound and
outbound policies configured for IPv4 Multicast address family.
These neighbors will default to sending and/or receiving no
routes and are marked with ’!’ in the output below. Use the
’show bgp neighbor &nbr_address&’ command for details.
AS MsgRcvd MsgSent
InQ OutQ Up/Down
10.0.101.2
0 00:00:00 Idle!
Address Family: IPv6 Unicast
============================
BGP router identifier 10.0.0.1, local AS number 1
BGP generic scan interval 60 secs
BGP main routing table version 2
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
RecvTblVer
SendTblVer
AS MsgRcvd MsgSent
InQ OutQ Up/Down
0 15:15:11
0 00:00:00 Idle
Address Family: IPv6 Multicast
==============================
BGP router identifier 10.0.0.1, 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.
RecvTblVer
SendTblVer
Some configured eBGP neighbors do not have both inbound and
outbound policies configured for IPv6 Multicast address family.
These neighbors will default to sending and/or receiving no
routes and are marked with ’!’ in the output below. Use the
’show bgp neighbor &nbr_address&’ command for details.
AS MsgRcvd MsgSent
InQ OutQ Up/Down
0 15:15:11
0 00:00:00 Idle!
Table Policy
The table policy
feature in BGP allows you to configure traffic index values on routes as they
are installed in the global routing table. This feature is enabled using the
table-policy command and supports the BGP policy
accounting feature.
BGP policy accounting
uses traffic indices that are set on BGP routes to track various counters. See
Implementing Routing Policy
on Cisco IOS XR Software
module in the
Cisco IOS XR Routing Configuration Guide for the Cisco CRS
Router for details on table policy use. See
Cisco Express Forwarding
Commands on Cisco IOS XR Software
module in the
Cisco IOS XR IP Addresses and
Services Command Reference for the Cisco CRS Router for details on BGP policy
accounting.
Table policy also
provides the ability to drop routes from the RIB based on match criteria. This
feature can be useful in certain applications and should be used with caution
as it can easily create a routing ‘black hole’ where BGP advertises routes to
neighbors that BGP does not install in its global routing table and forwarding
Update Groups
The BGP Update Groups feature contains an algorithm that dynamically calculates and optimizes update groups of neighbors that share outbound policies and can share the update messages. 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
The BGP Update Groups feature separates BGP update generation from neighbor 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. Update group-based message generation occurs automatically and independently.
BGP Update Group
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 contains commands for monitoring BGP update
The BGP cost community
is a nontransitive extended community attribute that is passed to internal BGP
(iBGP) and confederation peers but not to external BGP (eBGP) peers. The cost
community feature allows you to customize the local route preference and
influence the best-path selection process by assigning cost values to specific
routes. The extended community format defines generic points of insertion (POI)
that influence the best-path decision at different points in the best-path
algorithm.
The cost community
attribute is applied to internal routes by configuring the
extcommunity cost command in a route policy. See the
Routing Policy
Language Commands on
Cisco IOS XR Software
Cisco IOS XR
Routing Command
Reference for information on the
extcommunity cost command. The cost community set clause is
configured with a cost community ID number (0–255) and cost community number
(0–). The cost community number determines the preference for the
path. The path with the lowest cost community number is preferred. Paths that
are not specifically configured with the cost community number are assigned a
default cost community number of
(the midpoint between 0 and
) and evaluated by the best-path selection process accordingly. When
two paths have been configured with the same cost community number, the path
selection process prefers the path with the lowest cost community ID. The
cost-extended community attribute is propagated to iBGP peers when extended
community exchange is enabled.
The following commands
include the
route-policy
keyword, which you can use to apply a route policy that is
configured with the cost community set clause:
aggregate-address
redistribute
How BGP Cost Community Influences the Best Path Selection Process
The cost community attribute influences the BGP best-path selection process at the point of insertion (POI). By default, the POI follows the Interior Gateway Protocol (IGP) metric comparison. When BGP receives multiple paths to the same destination, it uses the best-path selection process to determine which path is the best path. BGP automatically makes the decision and installs the best path in the routing table. The POI allows you to assign a preference to a specific path when multiple equal cost paths are available. If the POI is not valid for local best-path selection, the cost community attribute is silently ignored.
Cost communities are sorted first by POI then by community ID. Multiple paths can be configured with the cost community attribute for the same POI. The path with the lowest cost community ID is considered first. In other words, all cost community paths for a specific POI are considered, starting with the one with the lowest cost community. Paths that do not contain the cost community cost (for the POI and community ID being evaluated) are assigned the default community cost value (). If the cost community values are equal, then cost community comparison proceeds to the next lowest community ID for this POI.
To select the path with the lower cost community, simultaneously walk through the cost communities of both paths. This is done by maintaining two pointers to the cost community chain, one for each path, and advancing both pointers to the next applicable cost community at each step of the walk for the given POI, in order of community ID, and stop when a best path is chosen or the comparison is a tie. At each step of the walk, the following checks are done:
If neither pointer refers to a cost community,
Elseif a cost community is found for one path but not for the other,
Choose the path with cost co
Elseif the Community ID from one path is less than the other,
Choose the path with the lesser Community ID
Elseif the Cost from one path is less than the other,
Choose the path with the lesser C
Else Continue.
Paths that are not configured with the cost community attribute are considered by the best-path selection process to have the default cost value (half of the maximum value [] or ).
Applying the cost community attribute at the POI allows you to assign a value to a path originated or learned by a peer in any part of the local autonomous system or confederation. The cost community can be used as a “tie breaker” during the best-path selection process. Multiple instances of the cost community can be configured for separate equal cost paths within the same autonomous system or confederation. For example, a lower cost community value can be applied to a specific exit path in a network with multiple equal cost exit points, and the specific exit path is preferred by the BGP best-path selection process. See the scenario described in.
The cost community comparison in BGP is enabled by default. Use the bgp bestpath cost-community ignore command to disable the comparison.
See for information on the BGP best-path selection process.
Cost Community Support for Aggregate Routes and Multipaths
The BGP cost community feature supports aggregat