Professional Documents
Culture Documents
Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public
domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
q g g g y g g y y
iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco
Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Empowering the Internet Generation,
Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ
Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing,
ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StrataView Plus, TeleRouter, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered
trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship
between Cisco and any other company. (0502R)
Preface xi
Contents RC-1
Contents RC-83
Contents RC-127
Contents RC-195
Contents RC-205
Contents RC-247
This is the preface for the Cisco IOS XR Routing Configuration Guide.
The preface contains the following sections:
• Document Revision History, page xi
• Obtaining Documentation, page xii
• Documentation Feedback, page xiii
• Cisco Product Security Overview, page xiii
• Obtaining Technical Assistance, page xiv
• Obtaining Additional Publications and Information, page xv
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several
ways to obtain technical assistance and other technical resources. These sections explain how to obtain
technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation at this URL:
http://www.cisco.com/techsupport
You can access the Cisco website at this URL:
http://www.cisco.com
You can access international Cisco websites at this URL:
http://www.cisco.com/public/countries_languages.shtml
Ordering Documentation
Beginning June 30, 2005, registered Cisco.com users may order Cisco documentation at the Product
Documentation Store in the Cisco Marketplace at this URL:
http://www.cisco.com/go/marketplace/
Nonregistered Cisco.com users can order technical documentation from 8:00 a.m. to 5:00 p.m.
(0800 to 1700) PDT by calling 1 866 463-3487 in the United States and Canada, or elsewhere by
calling 011 408 519-5055. You can also order documentation by e-mail at
tech-doc-store-mkpl@external.cisco.com or by fax at 1 408 519-5001 in the United States and Canada,
or elsewhere at 011 408 519-5001.
Documentation Feedback
You can rate and provide feedback about Cisco technical documents by completing the online feedback
form that appears with the technical documents on Cisco.com.
You can send comments about Cisco documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your
document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive
information that you send to Cisco. PSIRT can work from encrypted information that is compatible with
PGP versions 2.x through 8.x.
Never use a revoked or an expired encryption key. The correct public key to use in your correspondence
with PSIRT is the one linked in the Contact Summary section of the Security Vulnerability Policy page
at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
The link on this page has the current PGP key ID in use.
Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting
a web or phone request for service. You can access the CPI tool from the Cisco Technical Support &
Documentation website by clicking the Tools & Resources link under Documentation & Tools. Choose
Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco
Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by
product ID or model name; by tree view; or for certain products, by copying and pasting show command
output. Search results show an illustration of your product with the serial number label location
highlighted. Locate the serial number label on your product and record the information before placing a
service call.
• Cisco Press publishes a wide range of general networking, training and certification titles. Both new
and experienced users will benefit from these publications. For current Cisco Press titles and other
information, go to Cisco Press at this URL:
http://www.ciscopress.com
• Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and
networking investments. Each quarter, Packet delivers coverage of the latest industry trends,
technology breakthroughs, and Cisco products and solutions, as well as network deployment and
troubleshooting tips, configuration examples, customer case studies, certification and training
information, and links to scores of in-depth online resources. You can access Packet magazine at
this URL:
http://www.cisco.com/packet
• iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies
learn how they can use technology to increase revenue, streamline their business, and expand
services. The publication identifies the challenges facing these companies and the technologies to
help solve them, using real-world case studies and business strategies to help readers make sound
technology investment decisions. You can access iQ Magazine at this URL:
http://www.cisco.com/go/iqmagazine
or view the digital edition at this URL:
http://ciscoiq.texterity.com/ciscoiq/sample/
• Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering
professionals involved in designing, developing, and operating public and private internets and
intranets. You can access the Internet Protocol Journal at this URL:
http://www.cisco.com/ipj
• Networking products offered by Cisco Systems, as well as customer support services, can be
obtained at this URL:
http://www.cisco.com/en/US/products/index.html
• Networking Professionals Connection is an interactive website for networking professionals to share
questions, suggestions, and information about networking products and technologies with Cisco
experts and other networking professionals. Join a discussion at this URL:
http://www.cisco.com/discuss/networking
• World-class networking training is available from Cisco. You can view current offerings at
this URL:
http://www.cisco.com/en/US/learning/index.html
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 IP Version 4 (IPv4) and IP Version 6 (IPv6)
implementation in Cisco IOS XR Software.
Note For more information about BGP on the Cisco IOS XR software and complete descriptions of the BGP
commands listed in this module, you can see the “Related Documents” section of this module. To locate
documentation for other commands that might appear while executing a configuration task, search online
in the Cisco IOS XR software master command index.
Contents
• Prerequisites for Implementing BGP on Cisco IOS XR Software, page RC-2
• Information About Implementing BGP on Cisco IOS XR Software, page RC-2
• How to Implement BGP on Cisco IOS XR Software, page RC-27
• Configuration Examples for Implementing BGP on Cisco IOS XR Software, page RC-76
• Where to Go Next, page RC-79
• Additional References, page RC-80
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 if the
router is booted with the saved router-id command and if the ID from this command is available
when the last saved loopback configuration is applied.
• By using the primary IPv4 address on the interface specified with the router-id command in global
configuration mode if the box is booted with the saved router-id command in global configuration
mode and if the router ID is up by the time all saved loopback configurations are applied.
• 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 Configuration
Cisco IOS XR BGP 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.
BGP configurations are grouped into four major categories:
– Router Configuration Mode
– Global Address Family Configuration Mode
– Neighbor Configuration Mode
– Neighbor Address Family Configuration Mode
Configuration Modes
The following sections show how to enter each of the configuration modes. From a mode, you can enter
the ? command to display the commands available in that mode.
The following example shows 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)#
The following example shows 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)#
Neighbor Submode
Cisco IOS XR BGP uses a neighbor submode to make it possible to enter configurations without having
to prefix every configuration with the neighbor 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.
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
• An address family configuration submode inside the neighbor configuration submode is available
for entering address family-specific neighbor configurations. 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)# route-policy one in
• You must enter neighbor-specific IPv4 or IPv6 commands in neighbor address-family 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
Configuration Templates
The af-group, session-group, and neighbor-group configuration commands provide template support
for the neighbor configuration 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 (af-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 (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 multicast
RP/0/RP0/CPU0:router(config-bgp-afgrp)#
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 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(config)# router bgp 140
RP/0/RP0/CPU0:router(config-bgp)# session-group session1
RP/0/RP0/CPU0:router(config-bgp-sngrp)#
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 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 use 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 140
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 available neighbor
commands), and define the use command for the address family group and session group commands.
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
2. Otherwise, if the neighbor uses a session group or address family group, the configuration value is
obtained from the session group or address family group. If the address family group or session
group has a parent and an item is configured on the parent, the parent configuration is used. If the
item is not configured on the parent, but is configured on the parent ‘s parent, the configuration of
the parent’s parent is used, and so on. 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:
3. 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:
The following output from the show bgp neighbors command shows that the advertisement interval
used is 15 seconds:
To illustrate the same rule, the following example shows how to set 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.
RP/0/RP0/CPU0:router(config)# 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 TIMER
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# timers 10 30
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# route-policy POLICY_1 in
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 TIMER
The following output from the show bgp neighbors command shows that the advertisement interval
used is 15 seconds:
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:
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-nbrgrp)# 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:
The inheritance rules used when groups are inheriting configuration from other groups are the same
as the rules given for neighbors inheriting from groups.
Template Inheritance
You can use the following show commands described to monitor BGP inheritance information:
• show bgp neighbors, page RC-11
• show bgp af-group, page RC-12
• show bgp session-group, page RC-13
• show bgp neighbor-group, page RC-14
Use the show bgp neighbors command to display information about the BGP configuration for
neighbors.
• Use the 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 neighbor.
• Use the inheritance keyword to display the session groups, neighbor groups, and address family
groups from which this neighbor is capable of inheriting configuration .
The show bgp neighbors command examples that follow are based on the 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)# next-hop-self
RP/0/RP0/CPU0:router(config-bgp-afgrp)# route-policy POLICY_1 in
RP/0/RP0/CPU0:router(config-bgp0afgrp)# 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)# address-family ipv4 multicast
RP/0/RP0/CPU0:router(config-bgp-nbrgrp-af)# default-originate
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 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/RP0/CPU0:router# show bgp neighbors 192.168.0.1 inheritance
The following example displays sample output from the show bgp 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 in [a:GROUP_3]
weight 200 []
address-family ipv4 multicast [n:GROUP_1]
default-originate [n:GROUP_1]
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 command examples that follow are based on the 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-list 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
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
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
The following is sample output from the show bgp session-group command with the configuration
keyword in EXEC mode:
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 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
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
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
The following is sample output from the show bgp neighbor-group command with the users 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
Session: n:GROUP_1
IPv4 Unicast: n:GROUP_1
Note 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 policy.
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
Use the route-policy (BGP) 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 2
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
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/RP0/CPU0:router# show bgp all all summary
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 for details on table policy use. See the Cisco
Express Forwarding Commands on Cisco IOS XR Software module in the Cisco IOS XR IP Addresses
and Services Command Reference 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 but in the forwarding table .
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, page RC-18
• BGP Update Group, page RC-18
Note The order of comparison determined by Part 2 is important because the comparison operation is not
transitive; that is, if three paths, A, B, and C exist, such that when A and B are compared, A is better,
and when B and C are compared, B is better, it is not necessarily the case that when A and C are
compared, A is better. This nontransitivity arises because the multi exit discriminator (MED) is
compared only among paths from the same neighboring autonomous system (AS) and not among all
paths.
Note Steps 1 through 4 implement the “Degree of Preference” calculation from Section 9.1.1 of
draft-ietf-idr-bgp4-24.txt.
5. If the paths have unequal AS path lengths, the path with the shorter AS path is chosen. This step is
skipped if bgp bestpath as-path ignore command is configured. Note: when calculating the length
of the AS path, confederation segments are ignored, and AS sets count as 1. (See Section 9.1.2.2a
of draft-ietf-idr-bgp4-24.txt.)
6. If the paths have different origins, the path with the lower origin is selected. Interior Gateway
Protocol (IGP) is considered lower than EGP, which is considered lower than INCOMPLETE. (See
Section 9.1.2.2b of draft-ietf-idr-bgp4-24.txt.)
7. If appropriate, the MED of the paths is compared. If they are unequal, the path with the lower MED
is chosen.
A number of configuration options exist that affect whether or not this step is performed. In general,
the MED is compared if both paths were received from neighbors in the same AS; otherwise the
MED comparison is skipped. However, this behavior is modified by certain configuration options,
and there are also some corner cases to consider. (See Section 9.1.2.2c of draft-ietf-idr-bgp4-24.txt.)
If the bgp bestpath med always command is configured, then the MED comparison is always
performed, regardless of neighbor AS in the paths. Otherwise, MED comparison depends on the AS
paths of the two paths being compared, as follows:
a. If a path has no AS path or the AS path starts with an AS_SET, then the path is considered to
be internal, and the MED is compared with other internal paths
b. If the AS path starts with an AS_SEQUENCE, then the neighbor AS is the first AS number in
the sequence, and the MED is compared with other paths that have the same neighbor AS
c. If the AS path contains only confederation segments or starts with confederation segments
followed by an AS_SET, then the MED is not compared with any other path unless the bgp
bestpath med confed command is configured. In that case, the path is considered internal and
the MED is compared with other internal paths.
d. If the AS path starts with confederation segments followed by an AS_SEQUENCE, then the
neighbor AS is the first AS number in the AS_SEQUENCE, and the MED is compared with
other paths that have the same neighbor AS.
Note: if no MED attribute was received with the path, then the MED is considered to be 0 unless the
bgp bestpath med missing-as-worst command is configured. In that case, if no MED attribute was
received, the MED is considered to be the highest possible value.
8. If one path is received from an external peer and the other is received from an internal (or
confederation) peer, the path from the external peer is chosen. (See Section 9.1.2.2d of
draft-ietf-idr-bgp4-24.txt.)
9. If the paths have different IGP metrics to their next hops, the path with the lower IGP metric is
chosen. (See Section 9.1.2.2e of draft-ietf-idr-bgp4-24.txt.)
10. If all path parameters in steps 1 through 10 are the same, then the router IDs are compared. If the
path was received with an originator attribute, then that is used as the router ID to compare;
otherwise, the router ID of the neighbor from which the path was received is used. If the paths have
different router IDs, the path with the lower router ID is chosen. Note: where the originator is used
as the router ID, it is possible to have two paths with the same router ID. It is also possible to have
two BGP sessions with the same peer router, and therefore receive two paths with the same router
ID. (See Section 9.1.2.2f of draft-ietf-idr-bgp4-24.txt.)
11. If the paths have different cluster lengths, the path with the shorter cluster length is selected. If a
path was not received with a cluster list attribute, it is considered to have a cluster length of 0.
12. Finally, the path received from the neighbor with the lower IP address is chosen. Locally generated
paths (for example, redistributed paths) are considered to have a neighbor IP address of 0. (See
Section 9.1.2.2g of draft-ietf-idr-bgp4-24.txt.)
Order of Comparisons
The second part of the BGP best path algorithm implementation determines the order in which the paths
should be compared. The order of comparison is determined as follows:
1. The paths are partitioned into groups such that within each group the MED can be compared among
all paths. The same rules as in the “Comparing Pairs of Paths” section on page RC-19 are used to
determine whether MED can be compared between any two paths. Normally, this comparison results
in one group for each neighbor AS. If the bgp bestpath med always command is configured, then
there is just one group containing all the paths.
2. The best path in each group is determined. Determining the best path is achieved by iterating through
all paths in the group and keeping track of the best one seen so far. Each path is compared with the
best-so-far, and if it is better, it becomes the new best-so-far and is compared with the next path in
the group.
3. A set of paths is formed containing the best path selected from each group in step 2. The overall best
path is selected from this set of paths, by iterating through them as in step 2.
Note This suppression behavior does not comply with the IETF Networking Working Group
draft-ietf-idr-bgp4-24.txt document, but is specified in the IETF Networking Working Group
draft-ietf-idr-avoid-transition-00.txt document.
The suppression behavior can be turned off by configuring the bgp bestpath compare-routerid
command. If this command is configured, the new best path is always preferred to the existing one.
Otherwise, the following steps are used to determine whether the best path change can be suppressed:
1. If the existing best path is no longer valid, the change cannot be suppressed.
2. If either the existing or new best paths were received from internal (or confederation) peers or were
locally generated (for example, by redistribution), then the change cannot be suppressed. That is,
suppression is possible only if both paths were received from external peers.
3. If the paths were received from the same peer (the paths would have the same router-id), the change
cannot be suppressed. The router ID is calculated using rules in the “Comparing Pairs of Paths”
section on page RC-19.
4. If the paths have different weights, local preferences, origins, or IGP metrics to their next hops, then
the change cannot be suppressed. Note that all of these values are calculated using the rules in the
“Comparing Pairs of Paths” section on page RC-19.
5. If the paths have different-length AS paths and the bgp bestpath as-path ignore command is not
configured, then the change cannot be suppressed. Again, the AS path length is calculated using the
rules in the “Comparing Pairs of Paths” section on page RC-19.
6. If the MED of the paths can be compared and the MEDs are different, then the change cannot be
suppressed. The decision as to whether the MEDs can be compared is exactly the same as the rules
in the “Comparing Pairs of Paths” section on page RC-19, as is the calculation of the MED value.
7. If all path parameters in steps 1 through 6 do not apply, the change can be suppressed.
Multiprotocol BGP
Multiprotocol BGP is an enhanced BGP that carries routing information for multiple network layer
protocols and IP multicast routes. BGP carries two sets of routes, one set for unicast routing and one set
for multicast routing. The routes associated with multicast routing are used by the Protocol Independent
Multicast (PIM) feature to build data distribution trees.
Multiprotocol BGP is useful when you want a link dedicated to multicast traffic, perhaps to limit which
resources are used for which traffic. Multiprotocol BGP allows you to have a unicast routing topology
different from a multicast routing topology providing more control over your network and resources.
In BGP, the only way to perform interdomain multicast routing was to use the BGP infrastructure that
was in place for unicast routing. Perhaps you want all multicast traffic exchanged at one network access
point (NAP). If those routers were not multicast capable, or there were differing policies for which you
wanted multicast traffic to flow, multicast routing could not be supported without multiprotocol BGP.
Note It is possible to configure BGP peers that exchange both unicast and multicast network layer reachability
information (NLRI), but you cannot connect multiprotocol BGP clouds with a BGP cloud. That is, you
cannot redistribute multiprotocol BGP routes into BGP.
Figure 1 illustrates simple unicast and multicast topologies that are incongruent, and therefore are not
possible without multiprotocol BGP.
Autonomous systems 100, 200, and 300 are each connected to two NAPs that are FDDI rings. One is
used for unicast peering (and therefore the exchange of unicast traffic). The Multicast Friendly
Interconnect (MFI) ring is used for multicast peering (and therefore the exchange of multicast traffic).
Each router is unicast and multicast capable.
FDDI FDDI
Unicast MFI
Figure 2 is a topology of unicast-only routers and multicast-only routers. The two routers on the left are
unicast-only routers (that is, they do not support or are not configured to perform multicast routing). The
two routers on the right are multicast-only routers. Routers A and B support both unicast and multicast
routing. The unicast-only and multicast-only routers are connected to a single NAP.
In Figure 2, only unicast traffic can travel from Router A to the unicast routers to Router B and back.
Multicast traffic could not flow on that path, so another routing table is required. Multicast traffic uses
the path from Router A to the multicast routers to Router B and back.
Figure 2 illustrates a multiprotocol BGP environment with a separate unicast route and multicast route
from Router A to Router B. Multiprotocol BGP allows these routes to be incongruent. Both of the
autonomous systems must be configured for internal multiprotocol BGP (IMBGP) in the figure.
A multicast routing protocol, such as PIM, uses the multicast BGP database to perform Reverse Path
Forwarding (RPF) lookups for multicast-capable sources. Thus, packets can be sent and accepted on the
multicast topology but not on the unicast topology.
Router B
AS 200
Unicast Multicast
router router
IMBGP
NAP
Unicast IMBGP Multicast
router router
AS 100
Router A
Route Dampening
Route dampening is a BGP feature that minimizes the propagation of flapping routes across an
internetwork. A route is considered to be flapping when it is repeatedly available, then unavailable, then
available, then unavailable, and so on.
For example, consider a network with three BGP autonomous systems: autonomous system 1,
autonomous system 2, and autonomous system 3. Suppose the route to network A in autonomous system
1 flaps (it becomes unavailable). Under circumstances without route dampening, the eBGP neighbor of
autonomous system 1 to autonomous system 2 sends a withdraw message to autonomous system 2. The
border router in autonomous system 2, in turn, propagates the withdrawal message to autonomous
system 3. When the route to network A reappears, autonomous system 1 sends an advertisement message
to autonomous system 2, which sends it to autonomous system 3. If the route to network A repeatedly
becomes unavailable, then available, many withdrawal and advertisement messages are sent. Route
flapping is a problem in an internetwork connected to the Internet because a route flap in the Internet
backbone usually involves many routes.
Note No penalty is applied to a BGP peer reset when route dampening is enabled. Although the reset
withdraws the route, no penalty is applied in this instance, even if route flap dampening is enabled.
Minimizing Flapping
The route dampening feature minimizes the flapping problem as follows. Suppose again that the route
to network A flaps. The router in autonomous system 2 (in which route dampening is enabled) assigns
network A a penalty of 1000 and moves it to history state. The router in autonomous system 2 continues
to advertise the status of the route to neighbors. The penalties are cumulative. When the route flaps so
often that the penalty exceeds a configurable suppression limit, the router stops advertising the route to
network A, regardless of how many times it flaps. Thus, the route is dampened.
The penalty placed on network A is decayed until the reuse limit is reached, upon which the route is once
again advertised. At half of the reuse limit, the dampening information for the route to network A is
removed.
Fully meshed
autonomous
system
Router C
Routes
Routes not
Routes advertised
Router A advertised Router A
External Routes
BGP
speaker
Router B
S4217
With route reflectors, all iBGP speakers need not be fully meshed because there is a method to pass
learned routes to neighbors. In this model, an iBGP peer is configured to be a route reflector responsible
for passing iBGP learned routes to a set of iBGP neighbors. In Figure 4, Router B is configured as a route
reflector. When the route reflector receives routes advertised from Router A, it advertises them to Router
C, and vice versa. This scheme eliminates the need for the iBGP session between routers A and C.
Routes
Router A Router C
Router A
External
BGP Routes
speaker Reflected
S4219
routes
Router B
Route
reflector
The internal peers of the route reflector are divided into two groups: client peers and all other routers in
the autonomous system (nonclient peers). A route reflector reflects routes between these two groups.
The route reflector and its client peers form a cluster. The nonclient peers must be fully meshed with
each other, but the client peers need not be fully meshed. The clients in the cluster do not communicate
with iBGP speakers outside their cluster.
Partially meshed
autonomous system
Nonclient
Route reflector Router G
Nonclient
Routes
Router A Router A Router F
advertised
External
BGP
speaker Nonclient
Cluster Router E
S4218
Router B Router C Router D
Client Client Client
Figure 5 illustrates a more complex route reflector scheme. Router A is the route reflector in a cluster
with routers B, C, and D. Routers E, F, and G are fully meshed, nonclient routers.
When the route reflector receives an advertised route, depending on the neighbor, it takes the following
actions:
• A route from an external BGP speaker is advertised to all clients and nonclient peers.
• A route from a nonclient peer is advertised to all clients.
• A route from a client is advertised to all clients and nonclient peers. Hence, the clients need not be
fully meshed.
Along with route reflector-aware BGP speakers, it is possible to have BGP speakers that do not
understand the concept of route reflectors. They can be members of either client or nonclient groups,
allowing an easy and gradual migration from the old BGP model to the route reflector model. Initially,
you could create a single cluster with a route reflector and a few clients. All other iBGP speakers could
be nonclient peers to the route reflector and then more clusters could be created gradually.
An autonomous system can have multiple route reflectors. A route reflector treats other route reflectors
just like other iBGP speakers. A route reflector can be configured to have other route reflectors in a client
group or nonclient group. In a simple configuration, the backbone could be divided into many clusters.
Each route reflector would be configured with other route reflectors as nonclient peers (thus, all route
reflectors are fully meshed). The clients are configured to maintain iBGP sessions with only the route
reflector in their cluster.
Usually, a cluster of clients has a single route reflector. In that case, the cluster is identified by the router
ID of the route reflector. To increase redundancy and avoid a single point of failure, a cluster might have
more than one route reflector. In this case, all route reflectors in the cluster must be configured with the
cluster ID so that a route reflector can recognize updates from route reflectors in the same cluster. All
route reflectors serving a cluster should be fully meshed and all of them should have identical sets of
client and nonclient peers.
By default, the clients of a route reflector are not required to be fully meshed and the routes from a client
are reflected to other clients. However, if the clients are fully meshed, the route reflector need not reflect
routes to clients.
As the iBGP learned routes are reflected, routing information may loop. The route reflector model has
the following mechanisms to avoid routing loops:
• Originator ID is an optional, nontransitive BGP attribute. It is a 4-byte attributed created by a route
reflector. The attribute carries the router ID of the originator of the route in the local autonomous
system. Therefore, if a misconfiguration causes routing information to come back to the originator,
the information is ignored.
• Cluster-list is an optional, nontransitive BGP attribute. It is a sequence of cluster IDs that the route
has passed. When a route reflector reflects a route from its clients to nonclient peers, and vice versa,
it appends the local cluster ID to the cluster-list. If the cluster-list is empty, a new cluster-list is
created. Using this attribute, a route reflector can identify if routing information is looped back to
the same cluster due to misconfiguration. If the local cluster ID is found in the cluster-list, the
advertisement is ignored.
Note At least one neighbor and at least one address family must be configured to enable BGP routing. At least
one neighbor with both a remote AS and an address family must be configured globally using the
address family and remote as commands.
Prerequisites
BGP must be able to obtain a router identifier (for example, a configured loopback address). At least,
one address family must be configured in the BGP router configuration and the same address family must
also be configured under the neighbor.
Restrictions
If the neighbor is configured as an external BGP (eBGP) peer, you must configure an inbound and
outbound route policy on the neighbor using the route-policy command.
SUMMARY STEPS
1. configure
2. route-policy name
3. end-policy
4. end
or
commit
5. configure
6. router bgp autonomous-system-number
7. bgp router-id {ip-address | interface-type interface-instance}
8. neighbor ip-address
9. remote-as autonomous-system-number
10. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
11. route-policy route-policy-name {in | out}
12. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 route-policy name (Optional) Defines a route policy named drop-as-1234 and
enters route policy configuration mode.
Example:
RP/0/RP0/CPU0:router(config)# route-policy
drop-as-1234
RP/0/RP0/CPU0:router(config-rpl)# if as-path
passes-through '1234' then
RP/0/RP0/CPU0:router(config-rpl)# apply
check-communities
RP/0/RP0/CPU0:router(config-rpl)# else
RP/0/RP0/CPU0:router(config-rpl)# pass
RP/0/RP0/CPU0:router(config-rpl)# endif
Example:
RP/0/RP0/CPU0:router# configure
Step 6 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 7 bgp router-id {ip-address | interface-type Configures the local router with a router id of
interface-instance} 192.168.70.24.
Example:
RP/0/RP0/CPU0:router(config-bgp)# bgp router-id
192.168.70.24
Step 8 neighbor ip-address Places the router in neighbor configuration mode for BGP
routing and configures the neighbor IP address
172.168.40.24 as a BGP peer.
Example:
RP/0/RP0/CPU0:router(config-bgp)# neighbor
172.168.40.24
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)#
address-family ipv4 unicast
Step 11 route-policy route-policy-name {in | out} (Optional) Applies the In-Ipv4 policy to inbound IPv4
unicast routes.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr-af)#
route-policy In-Ipv4 in
Step 12 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# commit 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.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. bgp confederation identifier autonomous-system-number
4. bgp confederation peers autonomous-system-number
5. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 bgp confederation identifier Specifies a BGP confederation identifier of 5.
autonomous-system-number
Example:
RP/0/RP0/CPU0:router(config-bgp)# bgp
confederation identifier 5
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. timers bgp keepalive hold-time
4. neighbor ip-address
5. timers keepalive hold-time
6. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 timers bgp keepalive hold-time Sets a default keepalive time of 30 seconds and a default
hold time of 90 seconds for all neighbors.
Example:
RP/0/RP0/CPU0:router(config-bgp)# timers bgp 30
90
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. bgp default local-preference value
4. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 bgp default local-preference value Sets the default local preference value from the default of
100 to 200, making it a more preferable path.
Example:
RP/0/RP0/CPU0:router(config-bgp)# bgp default
local-preference 200
Step 4 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp)# commit 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.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. default-metric value
4. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 default-metric value Sets the default metric to 10, which is used to set the MED
to advertise to peers for routes that do not already have a
metric set (routes that were received with no MED
Example:
RP/0/RP0/CPU0:router(config-bgp)# default
attribute).
metric 10
Step 4 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp)# commit 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.
Restrictions
The clear bgp command must be used for the newly configured weight to take effect.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. neighbor ip-address
4. remote-as autonomous-system-number
5. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
6. weight weight-value
7. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 neighbor ip-address Places the router in neighbor configuration mode for BGP
routing and configures the neighbor IP address
172.168.40.24 as a BGP peer.
Example:
RP/0/RP0/CPU0:router(config-bgp)# neighbor
172.168.40.24
Step 4 remote-as autonomous-system-number Creates a neighbor and assigns it a remote autonomous
system number of 2002.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as
2002
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)#
address-family ipv4 unicast
Step 6 weight weight-value Assigns a weight of 41150 to all IPv4 unicast routes learned
through 172.168.40.24.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# weight
41150
Step 7 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# commit 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.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. bgp bestpath med missing-as-worst
4. bgp bestpath med always
5. bgp bestpath med confed
6. bgp bestpath as-path ignore
7. bgp bestpath compare-routerid
8. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 bgp bestpath med missing-as-worst Directs the BGP software to consider a missing MED
attribute in a path as having a value of infinity, making this
path the least desirable path.
Example:
RP/0/RP0/CPU0:router(config-bgp)# bgp bestpath
med missing-as-worst
Step 4 bgp bestpath med always Configures the BGP speaker in autonomous system 120 to
compare MEDs among alternative paths, regardless of the
autonomous system from which the paths are received.
Example:
RP/0/RP0/CPU0:router(config-bgp)# bgp bestpath
med always
Step 5 bgp bestpath med confed Enables BGP software to compare MED values for paths
learned from confederation peers.
Example:
RP/0/RP0/CPU0:router(config-bgp)# bgp bestpath
med confed
Step 6 bgp bestpath as-path ignore Configures the BGP software to ignore the autonomous
system length when performing best path selection.
Example:
RP/0/RP0/CPU0:router(config-bgp)# bgp bestpath
as-path ignore
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
4. network {ip-address /prefix-length | ip-address mask} backdoor
5. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 address-family {ipv4 unicast | ipv4 multicast | Enters global address family configuration mode for the
ipv6 unicast | ipv6 multicast} IPv4 address family.
Example:
RP/0/RP0/CPU0:router(config-bgp)#
address-family ipv4 unicast
Step 4 network {ip-address /prefix-length | ip-address Configures the local router to originate and advertise the
mask} backdoor IPv4 unicast network 172.20.0.0/16.
Example:
RP/0/RP0/CPU0:router(config-bgp-af)# network
172.20.0.0/16
Step 5 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp-af)# commit 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.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
4. aggregate-address address/mask-length [as-set] [as-confed-set] [summary-only] [route-policy
route-policy-name]
5. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 address-family {ipv4 unicast | ipv4 multicast | Enters global address family configuration mode for the
ipv6 unicast | ipv6 multicast} IPv4 address family.
Example:
RP/0/RP0/CPU0:router(config-bgp)#
address-family ipv4 unicast
Note Use of the bgp redistribute-internal command requires the clear route * command to be issued to
reinstall all BGP routes into the IP routing table.
Caution Redistributing iBGP routes into IGPs may cause routing loops to form within an autonomous system.
Use this command with caution.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. bgp redistribute-internal
4. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 bgp redistribute-internal Allows the redistribution of iBGP routes into an IGP, such
as IS-IS or OSPF.
Example:
RP/0/RP0/CPU0:router(config-bgp)# bgp
redistribute-internal
Step 4 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp)# commit 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.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
4. redistribute connected [metric metric-value] [route-policy route-policy-name]
or
redistribute isis process-id [level {1 | 1-inter-area | 2}] [metric metric-value] [route-policy
route-policy-name]
or
redistribute ospf process-id [match {external [1 | 2] | internal | nssa-external [1 | 2]]} [metric
metric-value] [route-policy route-policy-name]
or
redistribute ospfv3 process-id [match {external [1 | 2] | internal | nssa-external [1 | 2]]} [metric
metric-value] [route-policy route-policy-name]
or
redistribute static [metric metric-value] [route-policy route-policy-name]
5. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 address-family {ipv4 unicast | ipv4 multicast | Enters global address family configuration mode for the
ipv6 unicast | ipv6 multicast} IPv4 address family.
Example:
RP/0/RP0/CPU0:router(config-bgp)#
address-family ipv4 unicast
Example:
RP/0/RP0/CPU0:router(config-bgp-af)#
redistribute ospf 110
Step 5 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp-af)# commit 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.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
4. bgp dampening [half-life [reuse suppress max-suppress-time] | route-policy route-policy-name]
5. end
or
commit
6. show bgp [ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}]
flap-statistics
7. show bgp [ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}]
flap-statistics regexp regular-expression
8. show bgp [ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}]
flap-statistics route-policy route-policy-name
9. show bgp [ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}]
flap-statistics {ip-address [{mask | /prefix-length}
10. show bgp [ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}]
flap-statistics {ip-address [{mask | /prefix-length} [longer-prefixes]]
11. clear bgp {ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}}
flap-statistics
12. clear bgp {ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}}
flap-statistics regexp regular-expression
13. clear bgp {ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}}
flap-statistics route-policy route-policy-name
14. clear bgp {ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}}
flap-statistics network/mask-length
15. clear bgp {ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}}
flap-statistics ip-address
16. show bgp [ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}]
dampened-paths
17. clear bgp {ipv4 {unicast | multicast | all} | ipv6 {unicast | all} | all {unicast | multicast | all}}
dampening [ip-address/mask-length]
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 address-family {ipv4 unicast | ipv4 multicast | Enters global address family configuration mode for the
ipv6 unicast | ipv6 multicast} IPv4 address family.
Example:
RP/0/RP0/CPU0:router(config-bgp)#
address-family ipv4 unicast
Step 4 bgp dampening [half-life [reuse suppress Configures BGP dampening for the IPv4 address family.
max-suppress-time] | route-policy The half-life argument is set to 30, the reuse argument is set
route-policy-name]
to 1500, the suppress argument is set to 10000, and the
max-suppress-time argument is set to 120.
Example:
RP/0/RP0/CPU0:router(config-bgp-af)# bgp
dampening 30 1500 10000 120
Step 5 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp-af)# commit 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.
Example:
RP/0/RP0/CPU0:router# show bgp flap statistics
Step 7 show bgp [ipv4 {unicast | multicast | all} | Displays BGP flap statistics for all paths that match the
ipv6 {unicast | all} | all {unicast | multicast regular expression _1$.
| all}] flap-statistics regexp
regular-expression
Example:
RP/0/RP0/CPU0:router# show bgp flap-statistics
regexp _1$
Step 8 show bgp [ipv4 {unicast | multicast | all} | Displays BGP flap statistics for route policy policy_A.
ipv6 {unicast | all} | all {unicast | multicast
| all}] flap-statistics route-policy
route-policy-name
Example:
RP/0/RP0/CPU0:router(config)# show bgp
flap-statistics route-policy policy_A
Step 9 show bgp [ipv4 {unicast | multicast | all} | Displays BGP flap statistics for neighbor 172.20.1.1.
ipv6 {unicast | all} | all {unicast | multicast
| all}] flap-statistics {ip-address [{mask |
/prefix-length}
Example:
RP/0/RP0/CPU0:router# show bgp flap-statistics
172.20.1.1
Step 10 show bgp [ipv4 {unicast | multicast | all} | Displays BGP flap statistics for more specific entries for
ipv6 {unicast | all} | all {unicast | multicast neighbor 172.20.1.1.
| all}] flap-statistics {ip-address [{mask |
/prefix-length} [longer-prefixes]
Example:
RP/0/RP0/CPU0:router# show bgp flap-statistics
172.20.1.1 longer-prefixes
Step 11 clear bgp {ipv4 {unicast | multicast | all} | Clears BGP flap statistics for all routes.
ipv6 {unicast | all} | all {unicast | multicast
| all}} flap-statistics
Example:
RP/0/RP0/CPU0:router# clear bgp all all
flap-statistics
Example:
RP/0/RP0/CPU0:router# clear bgp ipv4 unicast
flap-statistics _1$
Step 13 clear bgp {ipv4 {unicast | multicast | all} | Clears BGP flap statistics for route policy policy_A.
ipv6 {unicast | all} | all {unicast | multicast
| all}} flap-statistics route-policy
route-policy-nane
Example:
RP/0/RP0/CPU0:router# clear bgp ipv4 unicast
flap-statistics route-policy policy_A
Step 14 clear bgp {ipv4 {unicast | multicast | all} | Clears BGP flap statistics for network 192.168.40.0/24.
ipv6 {unicast | all} | all {unicast | multicast
| all}} flap-statistics network/mask-length
Example:
RP/0/RP0/CPU0:router# clear bgp ipv4 unicast
flap-statistics 192.168.40.0/24
Step 15 clear bgp {ipv4 {unicast | multicast | all} | Clears BGP flap statistics for routes received from this
ipv6 {unicast | all} | all {unicast | multicast neighbor 172.20.1.1.
| all}} flap-statistics ip-address
Example:
RP/0/RP0/CPU0:router# clear bgp ipv4 unicast
flap-statistics 172.20.1.1
Step 16 show bgp [ipv4 {unicast | multicast | all} | Displays the dampened routes, including the time
ipv6 {unicast | all} | all {unicast | multicast remaining before they are unsuppressed.
| all}] dampened-paths
Example:
RP/0/RP0/CPU0:router# show bgp dampened paths
Step 17 clear bgp {ipv4 {unicast | multicast | all} | Clears route dampening information and unsuppresses the
ipv6 {unicast | all} | all {unicast | multicast suppressed routes.
| all}} dampening [ip-address/mask-length]
Example:
RP/0/RP0/CPU0:router# clear bgp dampening
Prerequisites
See the Implementing Routing Policy on Cisco IOS XR Software module of the Cisco IOS XR Routing
Configuration Guide for a list of the supported attributes and operations that are valid for table policy
filtering.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
4. table-policy policy-name
5. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 address-family {ipv4 unicast | ipv4 multicast | Enters global address family configuration mode for the
ipv6 unicast | ipv6 multicast} IPv4 address family.
Example:
RP/0/RP0/CPU0:router(config-bgp)#
address-family ipv4 unicast
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
4. distance bgp external-distance internal-distance local-distance
5. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 address-family {ipv4 unicast | ipv4 multicast | Enters global address family configuration mode for the
ipv6 unicast | ipv6 multicast} IPv4 address family.
Example:
RP/0/RP0/CPU0:router(config-bgp)#
address-family ipv4 unicast
Step 4 distance bgp external-distance Sets the external, internal, and local administrative
internal-distance local-distance distances to prefer one class of routes over another. The
higher the value, the lower the trust rating. The
Example: external-distance argument is set to 20, the
RP/0/RP0/CPU0:router(config-bgp-af)# distance internal-distance argument is set to 20, and the
bgp 20 20 200 local-distance argument is set to 200.
Step 5 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp-af)# commit 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.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. neighbor-group name
4. remote-as autonomous-system-number
5. advertisement-interval seconds
6. description text
7. dmz-link-bandwidth
8. ebgp-multihop [ttl-value]
9. local-as autonomous-system-number
10. password {clear | encrypted} password
11. password-disable
12. receive-buffer-size socket-size [bgp-size]
13. send-buffer-size socket-size [bgp-size]
14. timers keepalive hold-time
15. ttl-security
16. update-source interface-type interface-number
17. exit
18. neighbor ip-address
19. use neighbor-group group-name
20. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 neighbor-group name Places the router in neighbor group configuration mode.
Example:
RP/0/RP0/CPU0:router(config-bgp)#
neighbor-group nbr-grp-A
Step 4 remote-as autonomous-system-number Creates a neighbor and assigns it a remote autonomous
system number of 2002.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)#
remote-as 2002
Step 5 advertisement-interval seconds (Optional) Sets the minimum time between sending BGP
routing updates to 10 seconds.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)#
advertisement-interval 10
Step 6 description text (Optional) Configures the description “Neighbor on BGP
120” for neighbor group nbr-grp-A.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)#
description Neighbor on BGP 120
Step 7 dmz-link-bandwidth (Optional) Advertises the bandwidth of links on router bgp
120.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)#
dmz-link-bandwidth
Step 8 ebgp-multihop [ttl-value] (Optional) Allows a BGP connection to neighbor group
nbr-grp-A.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)#
ebgp-multihop
Step 9 local-as autonomous-system-number (Optional) Specifies that BGP use autonomous system 30
for the purpose of peering with neighbor group nbr-grp-A.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)#
local-as 30
Example:
RP/0/RP0/CPU0:router(config-bgp-nbrgrp)# exit
Step 18 neighbor ip-address Places the router in neighbor configuration mode for BGP
routing and configures the neighbor IP address
172.168.40.24 as a BGP peer.
Example:
RP/0/RP0/CPU0:router(config-bgp)# neighbor
172.168.40.24
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. neighbor ip-address
4. remote-as autonomous-system-number
5. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
6. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 neighbor ip-address Places the router in neighbor configuration mode for BGP
routing and configures the neighbor IP address
172.168.40.24 as a BGP peer.
Example:
RP/0/RP0/CPU0:router(config-bgp)# neighbor
172.168.40.24
Step 4 remote-as autonomous-system-number Creates a neighbor and assigns it a remote autonomous
system number of 2002.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as
2002
Step 5 address-family {ipv4 unicast | ipv4 multicast | Enters neighbor address family configuration mode for the
ipv6 unicast | ipv6 multicast} IPv4 address family.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)#
address-family ipv4 unicast
Step 6 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# commit 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.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. bgp cluster-id cluster-id
4. neighbor ip-address
5. remote-as autonomous-system-number
6. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
7. route-reflector-client
8. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 bgp cluster-id cluster-id Configures the local router as one of the route reflectors
serving the cluster. It is configured with the cluster ID of
192.168.70.1 to identify the cluster.
Example:
RP/0/RP0/CPU0:router(config-bgp)# bgp
cluster-id 192.168.70.1
RP/0/RP0/CPU0:router(config-bgp)# neighbor
172.168.40.24
Step 5 remote-as autonomous-system-number Creates a neighbor and assigns it a remote autonomous
system number of 2002.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as
2002
Step 6 address-family {ipv4 unicast | ipv4 multicast | Enters neighbor address family configuration mode for the
ipv6 unicast | ipv6 multicast} IPv4 address family.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)#
address-family ipv4 unicast
Step 7 route-reflector-client Configures the router as a BGP route reflector and
configures the neighbor 172.168.40.24 as its client.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr-af)#
route-reflector-client
Step 8 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# commit 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.
Prerequisites
See the Implementing Routing Policy on Cisco IOS XR Software module of the Cisco IOS XR Routing
Configuration Guide for a list of the supported attributes and operations that are valid for inbound and
outbound neighbor policy filtering.
SUMMARY STEPS
1. configure
2. route-policy name
3. end-policy
4. router bgp autonomous-system-number
5. neighbor ip-address
6. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
7. route-policy route-policy-name {in | out}
8. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 route-policy name (Optional) Defines a route policy named drop-as-1234 and
enters route policy configuration mode.
Example:
RP/0/RP0/CPU0:router(config)# route-policy
drop-as-1234
RP/0/RP0/CPU0:router(config-rpl)# if as-path
passes-through '1234' then
RP/0/RP0/CPU0:router(config-rpl)# apply
check-communities
RP/0/RP0/CPU0:router(config-rpl)# else
RP/0/RP0/CPU0:router(config-rpl)# pass
RP/0/RP0/CPU0:router(config-rpl)# endif
Step 3 end-policy (Optional) Ends the definition of a route policy and exits
route policy configuration mode.
Example:
RP/0/RP0/CPU0:router(config-rpl)# end-policy
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)#
address-family ipv4 unicast
Step 7 route-policy route-policy-name {in | out} Applies the In-Ipv4 policy to inbound IPv4 unicast routes.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr-af)#
route-policy In-Ipv4 in
Step 8 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# commit 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.
Note Next hop processing can be disabled for address family group, neighbor group, or neighbor address
family.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. neighbor ip-address
4. remote-as autonomous-system-number
5. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
6. next-hop-self
7. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 neighbor ip-address Places the router in neighbor configuration mode for BGP
routing and configures the neighbor IP address
172.168.40.24 as a BGP peer.
Example:
RP/0/RP0/CPU0:router(config-bgp)# neighbor
172.168.40.24
Step 4 remote-as autonomous-system-number Creates a neighbor and assigns it a remote autonomous
system number of 2002.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as
2002
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)#
address-family ipv4 unicast
Step 6 next-hop-self Sets the next hop attribute for all IPv4 unicast routes
advertised to neighbor 172.168.40.24 to the address of the
local router. Disabling the calculation of the best next hop
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr-af)#
to use when advertising a route causes all routes to be
next-hop-self advertised with the local network device as the next hop.
Step 7 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp-nbr-af)# commit 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.
Note If the send-community-ebgp command is configured for a neighbor group or address family group, all
neighbors using the group inherit the configuration. Configuring the command specifically for a
neighbor overrides inherited values.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. neighbor ip-address
4. remote-as autonomous-system-number
5. address-family {ipv4 unicast | ipv4 multicast | ipv6 unicast | ipv6 multicast}
6. send-community-ebgp
7. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 neighbor ip-address Places the router in neighbor configuration mode for BGP
routing and configures the neighbor IP address
172.168.40.24 as a BGP peer.
Example:
RP/0/RP0/CPU0:router(config-bgp)# neighbor
172.168.40.24
Step 4 remote-as autonomous-system-number Creates a neighbor and assigns it a remote autonomous
system number of 2002.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)# remote-as
2002
Step 5 address-family {ipv4 unicast | ipv4 multicast | Enters neighbor address family configuration mode for the
ipv6 unicast | ipv6 multicast} IPv4 address family.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)#
address-family ipv4 unicast
Note Storing updates from a neighbor works only if either the neighbor is route refresh capable or if the
soft-reconfiguration inbound command is configured. Even if the neighbor is route refresh capable and
the soft-reconfiguration inbound command is configured, the original routes are not stored unless the
always option is used with the command. The original routes can be easily retrieved with a route refresh
request. Route refresh sends a request to the peer to resend its routing information. The
soft-reconfiguration inbound command stores all paths received from the peer in an unmodified form
and refers to these stored paths during the clear. Soft reconfiguration is memory intensive.
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. neighbor ip-address
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 neighbor ip-address Places the router in neighbor configuration mode for BGP
routing and configures the neighbor IP address
172.168.40.24 as a BGP peer.
Example:
RP/0/RP0/CPU0:router(config-bgp)# neighbor
172.168.40.24
Step 4 address-family {ipv4 unicast | ipv4 multicast | Enters neighbor address family configuration mode for the
ipv6 unicast | ipv6 multicast} IPv4 address family.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)#
address-family ipv4 unicast
SUMMARY STEPS
1. configure
2. router bgp autonomous-system-number
3. neighbor ip-address
4. shutdown
5. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp autonomous-system-number Enters BGP configuration mode allowing you to configure
the BGP routing process.
Example:
RP/0/RP0/CPU0:router(config)# router bgp 120
Step 3 neighbor ip-address Places the router in neighbor configuration mode for BGP
routing and configures the neighbor IP address
172.168.40.24 as a BGP peer.
Example:
RP/0/RP0/CPU0:router(config-bgp)# neighbor
172.168.40.24
Step 4 shutdown Disables all active sessions for neighbor 172.168.40.24.
Example:
RP/0/RP0/CPU0:router(config-bgp-nbr)# shutdown
Step 5 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-bgp-nbr)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-bgp-nbr)# commit 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.
SUMMARY STEPS
DETAILED STEPS
SUMMARY STEPS
DETAILED STEPS
SUMMARY STEPS
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# clear bgp 10.0.0.3
SUMMARY STEPS
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# clear bgp 172.20.1.1
Step 2 clear bgp external Clears all external peers.
Example:
RP/0/RP0/CPU0:router# clear bgp external
Step 3 clear bgp * Clears all BGP neighbors.
Example:
RP/0/RP0/CPU0:router# clear bgp *
SUMMARY STEPS
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# show bgp count-only
Step 3 show bgp community community-list [exact-match] Displays routes that match the BGP community 1081:5.
Example:
RP/0/RP0/CPU0:router# show bgp community 1081:5
exact-match
Step 4 show bgp regexp regular-expression Displays routes that match the autonomous system path
regular expression "^3 ".
Example:
RP/0/RP0/CPU0:router# show bgp regexp "^3 "
Step 5 show bgp Displays entries in the BGP routing table.
Example:
RP/0/RP0/CPU0:router# show bgp
Step 6 show bgp neighbors ip-address Displays information about the BGP connection to neighbor
[advertised-routes | dampened-routes | 10.0.101.1.
flap-statistics | performance-statistics |
received prefix-filter | routes] • The advertised-routes keyword displays all routes the
router advertised to the neighbor.
Example: • The dampened-routes keyword displays the dampened
RP/0/RP0/CPU0:router# show bgp neighbors routes that are learned from the neighbor.
10.0.101.1
• The flap-statistics keyword displays flap statistics of
the routes learned from the neighbor.
• The performance-statistics keyword displays
performance statistics relating to work done by the
BGP process for this neighbor.
• The received prefix-filter keyword and argument
display the received prefix list filter.
• The routes keyword displays routes learned from the
neighbor.
Example:
RP/0/RP0/CPU0:router# show bgp paths
Step 8 show bgp neighbor-group group-name Displays the effective configuration for neighbor group
configuration group_1, including any configuration inherited by this
neighbor group.
Example:
RP/0/RP0/CPU0:router# show bgp neighbor-group
group_1 configuration
Step 9 show bgp summary Displays the status of all BGP connections.
Example:
RP/0/RP0/CPU0:router# show bgp summary
SUMMARY STEPS
1. show bgp [{ipv4 | ipv6 | all} {unicast | multicast | all]} update-group [neighbor ip-address |
process-id.index [summary | performance-statistics]]
DETAILED STEPS
route-policy pass-all
pass
end-policy
route-policy set_next_hop_agg_v4
set next-hop 10.0.0.1
end-policy
route-policy set_next_hop_static_v4
if (destination in static) then
set next-hop 10.1.0.1
else
drop
endif
end-policy
route-policy set_next_hop_agg_v6
set next-hop 2003::121
end-policy
route-policy set_next_hop_static_v6
if (destination in static) then
set next-hop 2011::121
else
drop
endif
end-policy
router bgp 65000
bgp fast-external-fallover disable
bgp confederation peers
65001
65002
bgp confederation identifier 1
bgp router-id 1.1.1.1
address-family ipv4 unicast
aggregate-address 10.2.0.0/24 route-policy set_next_hop_agg_v4
aggregate-address 10.3.0.0/24
redistribute static route-policy set_next_hop_static_v4
In a BGP speaker in autonomous system 6002, the peers from autonomous systems 6001 and 6003 are
configured as special eBGP peers. Peer 170.70.70.1 is a normal iBGP peer and peer 199.99.99.2 is a
normal eBGP peer from autonomous system 700.
router bgp 6002
bgp confederation identifier 666
bgp confederation peers 6001 6003
neighbor 170.70.70.1
remote-as 6002
neighbor 171.69.232.57
remote-as 6001
neighbor 171.69.232.56
remote-as 6003
neighbor 199.99.99.2
remote-as 700
In a BGP speaker in autonomous system 6003, the peers from autonomous systems 6001 and 6002 are
configured as special eBGP peers. Peer 200.200.200.200 is a normal eBGP peer from autonomous
system 701.
router bgp 6003
bgp confederation identifier 666
bgp confederation peers 6001 6002
neighbor 171.69.232.57
remote-as 6001
neighbor 171.69.232.55
remote-as 6002
neighbor 200.200.200.200
remote-as 701
The following is a part of the configuration from the BGP speaker 200.200.200.205 from autonomous
system 701 in the same example. Neighbor 171.69.232.56 is configured as a normal eBGP speaker from
autonomous system 666. The internal division of the autonomous system into multiple autonomous
systems is not known to the peers external to the confederation.
router bgp 701
neighbor 171.69.232.56
remote-as 666
neighbor 200.200.200.205
remote-as 701
Where to Go Next
For detailed information about BGP commands, see 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: complete command syntax, command Cisco IOS XR Routing Command Reference, Release 3.2
modes, command history, defaults, usage guidelines,
and examples
Standards
Standards Title
draft-ietf-idr-bgp4-26.txt A Border Gateway Protocol 4, by Y. Rekhter, T.Li, S. Hares
draft-ietf-idr-bgp4-mib-15.txt Definitions of Managed Objects for the Fourth Version of Border
Gateway Protocol (BGP-4), by J. Hass and S. Hares
draft-ietf-idr-cease-subcode-05.txt Subcodes for BGP Cease Notification Message, by Enke Chen, V.
Gillet
MIBs
MIBs MIBs Link
• BGP4-MIB To locate and download MIBs for selected platforms using
Cisco IOS XR software, use the Cisco MIB Locator found at the
• CISCO-BGP4-MIB
following URL:
http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
RFCs Title
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
RFCs Title
RFC 3065 Autonomous System Confederations for BGP
RFC 3392 Capabilities Advertisement with BGP-4
Technical Assistance
Description Link
The Cisco Technical Support website contains http://www.cisco.com/techsupport
thousands of 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.
Note For more information about IS-IS on the Cisco IOS XR software and complete descriptions of the IS-IS
commands listed in this module, you can refer to the “Related Documents” section of this module. To
locate documentation for other commands that might appear while of executing a configuration task,
search online in the Cisco IOS XR software master command index.
Contents
• Prerequisites for Implementing IS-IS on Cisco IOS XR Software, page RC-84
• Restrictions for Implementing IS-IS on Cisco IOS XR Software, page RC-84
• Information About Implementing IS-IS on Cisco IOS XR Software, page RC-84
• How to Implement IS-IS on Cisco IOS XR Software, page RC-91
• Configuration Examples for Implementing IS-IS on Cisco IOS XR Software, page RC-122
• Where to Go Next, page RC-124
• Additional References, page RC-124
IS-IS Interfaces
IS-IS interfaces can be configured as one of the following types:
• active—advertises connected prefixes and forms adjacencies. This is the default for interfaces.
• passive—advertises connected prefixes but does not form adjacencies. The passive command is
used to configure interfaces as passive. Passive interfaces should be used sparingly for important
prefixes such as loopback addresses that need to be injected into the IS-IS domain. If many
connected prefixes need to be advertised then the redistribution of connected routes with the
appropriate policy should be used instead.
• suppressed—does not advertise connected prefixes but forms adjacencies. The suppress command
is used to configure interfaces as suppressed.
• shutdown—does not advertise connected prefixes and does not form adjacencies. The shutdown
command is used to disable interfaces without removing the IS-IS configuration.
Multitopology Configuration
Cisco IOS XR software supports multitopology for IPv6 IS-IS unless single topology is explicitly
configured in IPv6 address-family configuration mode.
Note IS-IS supports IP routing and not Open Systems Interconnection (OSI) Connectionless Network Service
(CLNS) routing.
When single-topology support for IPv6 is used, only narrow link metrics, also known as old-style type,
length, and value (TLV) arguments, may be employed. During single-topology operation, one shortest
path first (SPF) computation for each level is used to compute both IPv4 and IPv6 routes. Using a single
SPF is possible because both IPv4 IS-IS and IPv6 IS-IS routing protocols share a common link topology.
Because multitopology is the default behavior in the software, you must explicitly configure IPv6 to use
the same topology as IPv4 enable single-topology IPv6. Configure the single-topology command in
IPv6 router address family configuration submode of the IS-IS router stanza.
Nonstop Forwarding
On Cisco IOS XR software, NSF minimizes the amount of time a network is unavailable to its users
following a route processor (RP) failover. The main objective of NSF is to continue forwarding IP
packets and perform a graceful restart following an RP failover.
When a router restarts, all routing peers of that device usually detect that the device went down and then
came back up. This transition results in what is called a routing flap, which could spread across multiple
routing domains. Routing flaps caused by routing restarts create routing instabilities, which are
detrimental to the overall network performance. NSF helps to suppress routing flaps in NSF-aware
devices, thus reducing network instability.
NSF allows for the forwarding of data packets to continue along known routes while the routing protocol
information is being restored following an RP failover. When the NSF feature is configured, peer
networking devices do not experience routing flaps. Data traffic is forwarded through intelligent line
cards or dual forwarding processors (FPs) while the standby RP assumes control from the failed active
RP during a failover. The ability of line cards and FPs to remain up through a failover and to be kept
current with the Forwarding Information Base (FIB) on the active RP is key to NSF operation.
When the Cisco IOS XR router running IS-IS routing performs an RP failover, the router must perform
two tasks to resynchronize its link-state database with its IS-IS neighbors. First, it must relearn the
available IS-IS neighbors on the network without causing a reset of the neighbor relationship. Second,
it must reacquire the contents of the link-state database for the network.
The IS-IS NSF feature offers two options when configuring NSF:
• IETF NSF
• Cisco NSF
If neighbor routers on a network segment are NSF aware, meaning that neighbor routers are running a
software version that supports the IETF Internet draft for router restartability, they assist an IETF NSF
router that is restarting. With IETF NSF, neighbor routers provide adjacency and link-state information
to help rebuild the routing information following a failover.
In Cisco IOS XR software, Cisco NSF checkpoints (stores persistently) all the state necessary to recover
from a restart without requiring any special cooperation from neighboring routers. The state is recovered
from the neighboring routers, but only using the standard features of the IS-IS routing protocol. This
capability makes Cisco NSF suitable for use in networks in which other routers have not used the IETF
standard implementation of NSF.
Note If you configure IETF NSF on the Cisco IOS XR router and a neighbor router does not support IETF
NSF, the affected adjacencies flap, but nonstop forwarding is maintained to all neighbors that do support
IETF NSF. A restart reverts to a cold start if no neighbors support IETF NSF.
Multi-Instance IS-IS
You may configure as many IS-IS instances as system resources (memory and interfaces) allow. Each
interface may be associated with only a single IS-IS instance, and MPLS may be enabled for only a
single IS-IS instance. Cisco IOS XR software prevents the double-booking of an interface by two
instances at configuration time—two instances of MPLS configuration causes an error.
Because the Routing Information Base (RIB) treats each of the IS-IS instances as equal routing clients,
you must be careful when redistributing routes between IS-IS instances. The RIB does not know to prefer
Level 1 routes over Level 2 routes. For this reason, if you are running Level 1 and Level 2 instances, you
must enforce the preference by configuring different administrative distances for the two instances.
Default Routes
You can force a default route into an IS-IS routing domain. Whenever you specifically configure
redistribution of routes into an IS-IS routing domain, the Cisco IOS XR software does not, by default,
redistribute the default route into the IS-IS routing domain. The default-information originate
command generates a default route into IS-IS, which can be controlled by a route map. You can use the
route map to identify the level into which the default route is to be announced, and you can specify other
filtering options configurable under a route map. You can use a route map to conditionally advertise the
default route, depending on the existence of another route in the routing table of the router.
Caution If the connectivity for the Level 2 instance is lost, the attached bit in the Level 1 instance LSP would
continue sending traffic to the Level 2 instance and cause the traffic to be dropped.
Multicast-Intact Feature
The multicast-intact feature provides the ability to run multicast routing (PIM) when IGP shortcuts are
configured and active on the router. Both OSPFv2 and IS-IS support the multicast-intact feature.
You can enable multicast-intact in the IGP when multicast routing protocols (PIM) are configured and
IGP shortcuts are configured on the router. IGP shortcuts are MPLS tunnels that are exposed to IGP. The
IGPs route the IP traffic over these tunnels to destinations that are downstream from the egress router of
the tunnel (from an SPF perspective). PIM cannot use IGP shortcuts for propagating PIM joins because
reverse path forwarding (RPF) cannot work across a unidirectional tunnel.
When you enable multicast-intact on an IGP, the IGP publishes a parallel or alternate set of equal-cost
next-hops for use by PIM. These next-hops are called mcast-intact next-hops. The mcast-intact
next-hops have the following attributes:
• They are guaranteed not to contain any IGP shortcuts.
• They are not used for unicast routing but are used only by PIM to look up an IPv4 next-hop to a PIM
source.
• They are not published to the FIB.
• When multicast-intact is enabled on an IGP, all IPv4 destinations that were learned through
link-state advertisements are published with a set equal-cost mcast-intact next-hops to the RIB. This
attribute applies even when the native next-hops have no IGP shortcuts.
• In IS-IS, the max-paths limit is applied by counting both the native and mcast-intact next-hops
together. (In OSPFv2, the behavior is slightly different.)
Note To save configuration changes, you must commit changes when the system prompts you.
Note Configuring the routing level in Step 4 is optional, but is highly recommended to establish the proper
level of adjacencies.
Prerequisites
Although you can configure IS-IS before you configure an IP address, no IS-IS routing occurs until at
least one IP address is configured.
SUMMARY STEPS
1. configure
2. router isis instance-id
3. net network-entity-title
4. is-type {level-1 | level-1-2 | level-2-only}
5. end
or
commit
6. show isis [instance instance-id] protocol
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router isis instance-id Enables IS-IS routing for the specified routing instance, and
places the router in router configuration mode.
Example: • By default, all IS-IS instances are automatically
RP/0/RP0/CPU0:router(config)# router isis isp Level 1 and Level 2. You can change the level of
routing to be performed by a particular routing instance
using the is-type router configuration command.
Step 3 net network-entity-title Configures network entity titles (NETs) for the routing
instance.
Example: • Specify a NET for each routing instance if you are
RP/0/RP0/CPU0:router(config-isis)# net configuring multi-instance IS-IS. You can specify a
47.0004.004d.0001.0001.0c11.1110.00 name for a NET and for an address.
• This example configures a router with area ID
47.0004.004d.0001 and system ID 0001.0c11.1110.00.
• To specify more than one area address, specify
additional NETs. Although the area address portion of
the NET differs, the systemID portion of the NET must
match exactly for all of the configured items.
Step 4 is-type {level-1 | level-1-2 | level-2-only} (Optional) Configures the system type (area or backbone
router).
Example: • By default, every IS-IS instance acts as a level-1-2
RP/0/RP0/CPU0:router(config-isis)# is-type router.
level-2-only
• The level-1 keyword configures the software to perform
Level 1 (intra-area) routing only. Only Level 1
adjacencies are established. The software learns about
destinations inside its area only. Any packets
containing destinations outside the area are sent to the
nearest level-1-2 router in the area.
• The level-2-only keyword configures the software to
perform Level 2 (backbone) routing only, and the router
establishes only Level 2 adjacencies, either with other
Level 2-only routers or with level-1-2 routers.
• The level-1-2 keyword configures the software to
perform both Level 1 and Level 2 routing. Both Level 1
and Level 2 adjacencies are established. The router acts
as a border router between the Level 2 backbone and its
Level 1 area.
Restrictions
To enable the router to run in single-topology mode, configure each of the IS-IS interfaces with all of
the address families enabled and “single-topology” in the address-family IPv6 unicast in the IS-IS router
stanza. You can use either the IPv6 address family or both IPv4 and IPv6 address families, but your
configuration must represent the set of all active address families on the router. In addition, you should
explicitly enable single-topology operation by configuring it in the IPv6 router address family submode.
Exceptions to these instructions exist:
1. If the address-family stanza in the IS-IS process contains the adjacency-check disable command,
then an interface is not required to have the address family enabled.
2. If the interface is configured to Level 2 only. (This exception permits the running of IPv4 and IPv6
areas.)
3. The single-topology command is not valid in the ipv4 address-family submode.
The default metric style for single topology is narrow metrics. However, you can use either wide metrics
or narrow metrics. How to configure them depends on how single topology is configured. If both IPv4
and IPv6 are enabled and single topology is configured, the metric style is configured in the
address-family ipv4 stanza. You may configure the metric style in the address-family ipv6 stanza, but
it is ignored in this case. If only IPv6 is enabled and single topology is configured, then the metric style
is configured in the address-family ipv6 stanza.
SUMMARY STEPS
1. configure
2. interface type number
3. ipv4 address address mask
or
ipv6 address ipv6-prefix/prefix-length [eui-64]
or
ipv6 address ipv6-address {/prefix-length | link-local}
or
ipv6 enable
4. exit
5. router isis instance-id
6. net network-entity-title
7. address-family ipv6 [unicast]
8. single-topology
9. exit
10. interface type instance
11. circuit-type {level-1 | level-1-2 | level-2-only}
12. address-family {ipv4 | ipv6} [unicast]
13. end
or
commit
14. show isis [instance instance-id] interface [type instance] [detail] [level {1 | 2}]
15. show isis [instance instance-id] topology [systemid system-id] [level {1 | 2}] [summary]
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 interface type number Enters interface configuration mode.
Example:
RP/0/RP0/CPU0:router(config)# interface POS
0/1/0/3
Step 3 ipv4 address address mask Defines the IPv4 address for the interface. An IP address is
or required on all interfaces in an area enabled for IS-IS if any
ipv6 address ipv6-prefix/prefix-length [eui-64] one interface is configured for IS-IS routing.
or or
ipv6 address ipv6-address {/prefix-length
| link-local}
Specifies an IPv6 network assigned to the interface and
or enables IPv6 processing on the interface with the eui-64
keyword.
ipv6 enable
or
Example:
RP/0/RP0/CPU0:router(config-isis)# interface
POS 0/1/0/3
Example:
RP/0/RP0/CPU0:router# show isis interface
POS0/1/0/1
Step 15 show isis [instance instance-id] topology (Optional) Displays a list of connected routers in all areas.
[systemid system-id] [level {1 | 2}] [summary]
Example:
RP/0/RP0/CPU0:router# show isis topology
SUMMARY STEPS
1. configure
2. interface type instance
3. ipv4 address address mask
or
ipv6 address ipv6-prefix/prefix-length [eui-64]
or
ipv6 address ipv6-address {/prefix-length | link-local}
or
ipv6 enable
4. exit
5. router isis instance-id
6. net network-entity-title
7. interface type instance
8. address-family ipv4 [unicast]
9. exit
10. address-family ipv6 [unicast]
11. end
or
commit
12. show isis [instance instance-id] interface [type number] [brief | detail] [level {1 | 2}]
13. show isis [instance instance-id] topology [systemid system-id] [level {1 | 2}] [ipv4 | ipv6]
[summary] [unicast]
14. show isis [instance instance-id] adjacency [level {1 | 2}] [interface-type interface-instance]
[detail] [systemid system-id]
15. show isis adjacency-log [level {1 | 2}]
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 interface type instance Enters interface configuration mode.
Example:
RP/0/RP0/CPU0:router(config)# interface POS
0/1/0/3
Step 3 ipv4 address address mask Defines the IPv4 address for the interface.
or
• An IP address is required on all interfaces in an area
ipv6 address ipv6-prefix/prefix-length [eui-64] enabled for IS-IS if any one interface is configured for
or IS-IS routing.
ipv6 address ipv6-address {/prefix-length |
link-local}
or
or Specifies an IPv6 network assigned to the interface and
ipv6 enable
enables IPv6 processing on the interface.
or
Example:
RP/0/RP0/CPU0:router(config-if)# ipv4 address Specifies an IPv6 address assigned to the interface and
10.0.1.3 255.255.255.0 enables IPv6 processing on the interface.
or or
RP/0/RP0/CPU0:router(config-if)# ipv6 address
3ffe:1234:c18:1::/64 eui-64
Automatically configures an IPv6 link-local address on the
or interface while also enabling the interface for IPv6
processing.
RP/0/RP0/CPU0:router(config-if)# ipv6 address
FE80::260:3EFF:FE11:6770 link-local • The link-local address can be used to communicate
or only with nodes on the same link.
RP/0/RP0/CPU0:router(config-if)# ipv6 enable • Specifying the ipv6 address ipv6-prefix/prefix-length
interface configuration command without the eui-64
keyword configures site-local and global IPv6
addresses.
• Specifying the ipv6 address ipv6-prefix/prefix-length
command with the eui-64 keyword configures
site-local and global IPv6 addresses with an interface
ID in the low-order 64 bits of the IPv6 address. Only the
64-bit network prefix for the address needs to be
specified; the last 64 bits are automatically computed
from the interface ID.
• Specifying the ipv6 address command with the
link-local keyword configures a link-local address on
the interface that is used instead of the link-local
address that is automatically configured when IPv6 is
enabled on the interface.
Example:
RP/0/RP0/CPU0:router(config-isis)# interface
POS 0/1/0/4
Step 8 address-family ipv4 [unicast] Specifies the IPv4 address family and enters interface
address family configuration mode.
Example: • This example specifies the unicast IPv4 address family.
RP/0/RP0/CPU0:router(config-isis-if)#
address-family ipv4 unicast
Step 9 exit Exits interface configuration mode, and returns the router to
interface configuration mode.
Example:
RP/0/RP0/CPU0:router(config-if)# exit
Step 10 address-family ipv6 [unicast] Specifies the IPv6 address family and enters interface
address family configuration mode.
Example: • This example specifies the unicast IPv6 address family.
RP/0/RP0/CPU0:router(config-isis-if)#
address-family ipv6 unicast
Example:
RP/0/RP0/CPU0:router# show isis interface POS
0/1/0/1 brief
Step 13 show isis [instance instance-id] topology (Optional) Displays a list of connected routers in all areas.
[systemid system-id] [level {1 | 2}] [ipv4 |
ipv6] [summary] [unicast]
Example:
RP/0/RP0/CPU0:router# show isis topology
Step 14 show isis [instance instance-id] adjacency (Optional) Displays state information about established
[level {1 | 2}] [interface-type adjacencies.
interface-instance] [detail] [systemid
system-id]
Example::
RP/0/RP0/CPU0:router# show isis adjacency
Step 15 show isis adjacency-log [level {1 | 2}] (Optional) Displays the history of recent adjacency state
transitions.
Example:
RP/0/RP0/CPU0:router# show isis adjacency-log
level 1
SUMMARY STEPS
1. configure
2. router isis instance-id
3. lsp-refresh-interval seconds [level {1 | 2}]
4. lsp-check-interval seconds [level {1 | 2}]
5. lsp-gen-interval {[initial-wait initial | secondary-wait secondary | maximum-wait maximum]
...}[level {1 | 2}]
6. lsp-mtu bytes [level {1 | 2}]
7. max-lsp-lifetime seconds [level {1 | 2}]
8. ignore-lsp-errors disable
9. interface type instance
10. lsp-interval milliseconds [level {1 | 2}]
11. csnp-interval seconds [level {1 | 2}]
12. retransmit-interval seconds [level {1 | 2}]
13. retransmit-throttle-interval milliseconds [level {1 | 2}]
14. mesh-group {number | blocked}
15. end
or
commit
16. show isis interface [type instance | level {1 | 2}] [brief]
17. show isis [instance instance-id] database [level {1 | 2}] [detail | summary | verbose] [* | lsp-id]
18. show isis [instance instance-id] lsp-log [level {1 | 2}]
19. show isis database-log [level {1 | 2}]
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router isis instance-id Enables IS-IS routing for the specified routing instance, and
places the router in router configuration mode.
Example: • You can change the level of routing to be performed by
RP/0/RP0/CPU0:router(config)# router isis isp a particular routing instance using the is-type router
configuration command.
Step 3 lsp-refresh-interval seconds [level {1 | 2}] (Optional) Sets the time between regeneration of LSPs that
contain different sequence numbers
Example: • The refresh interval should always be set lower than the
RP/0/RP0/CPU0:router(config-isis)# max-lsp-lifetime command.
lsp-refresh-interval 10800
Step 4 lsp-check-interval seconds [level {1 | 2}] (Optional) Configures the time between periodic checks of
the entire database to validate the checksums of the LSPs in
the database.
Example:
RP/0/RP0/CPU0:router(config-isis)# • This operation is costly in terms of CPU and so should
lsp-check-interval 240 be configured to occur infrequently.
Step 5 lsp-gen-interval {[ initial-wait initial | (Optional) Reduces the rate of LSP generation during
secondary-wait secondary | maximum-wait periods of instability in the network. Helps reduce the CPU
maximum ] ...}[level { 1 | 2 }]
load on the router and number of LSP transmissions to its
IS-IS neighbors.
Example: • During prolonged periods of network instability,
RP/0/RP0/CPU0:router(config-isis)#
repeated recalculation of LSPs can cause an increased
lsp-gen-interval maximum-wait 15 initial-wait 5
CPU load on the local router. Further, the flooding of
these recalculated LSPs to the other Intermediate
Systems in the network causes increased traffic and can
result in other routers having to spend more time
running route calculations.
Step 6 lsp-mtu bytes [level {1 | 2}] (Optional) Sets the maximum transmission unit (MTU) size
of LSPs.
Example:
RP/0/RP0/CPU0:router(config-isis)# lsp-mtu 1300
Step 7 max-lsp-lifetime seconds [level {1 | 2}] (Optional) Sets the initial lifetime given to an LSP
originated by the router.
Example: • This is the amount of time that the LSP persists in the
RP/0/RP0/CPU0:router(config-isis)# database of a neighbor unless the LSP is regenerated or
max-lsp-lifetime 11000 refreshed.
Example:
RP/0/RP0/CPU0:router(config-isis)# interface
POS 0/1/0/3
Step 10 lsp-interval milliseconds [level {1 | 2}] (Optional) Configures the amount of time between each
LSP sent on an interface.
Example:
RP/0/RP0/CPU0:router(config-isis-if)#
lsp-interval 100
Step 11 csnp-interval seconds [level {1 | 2}] (Optional) Configures the interval at which periodic CSNP
packets are sent on broadcast interfaces.
Example: • Sending more frequent CSNPs means that adjacent
RP/0/RP0/CPU0:router(config-isis-if)# routers must work harder to receive them.
csnp-interval 30 level 1
• Sending less frequent CSNP means that differences in
the adjacent routers may persist longer.
Step 12 retransmit-interval seconds [level {1 | 2}] (Optional) Configures the amount of time that the sending
router waits for an acknowledgment before it considers that
the LSP was not received and subsequently resends.
Example:
RP/0/RP0/CPU0:router(config-isis-if)#
retransmit-interval 60
Step 13 retransmit-throttle-interval milliseconds (Optional) Configures the amount of time between
[level {1 | 2}] retransmissions on each LSP on a point-to-point interface.
• This time is usually greater than or equal to the
Example: lsp-interval command time because the reason for lost
RP/0/RP0/CPU0:router(config-isis-if)# LSPs may be that a neighboring router is busy. A longer
retransmit-throttle-interval 1000
interval gives the neighbor more time to receive
transmissions.
Step 14 mesh-group {number | blocked} (Optional) Optimizes LSP flooding in NBMA networks
with highly meshed, point-to-point topologies.
Example: • This command is appropriate only for an NBMA
RP/0/RP0/CPU0:router(config-isis-if)# network with highly meshed, point-to-point topologies.
mesh-group blocked
Example:
RP/0/RP0/CPU0:router# show isis interface
POS0/1/0/1 brief
Step 17 show isis [instance instance-id] database (Optional) Displays the IS-IS LSP database.
[level {1 | 2}] [detail | summary | verbose] [*
| lsp-id]
Example:
RP/0/RP0/CPU0:router# show isis database
level 1
Step 18 show isis [instance instance-id] lsp-log [level (Optional) Displays LSP log information.
{1 | 2}]
Example:
RP/0/RP0/CPU0:router# show isis lsp-log
Step 19 show isis database-log [level {1 | 2}] (Optional) Display IS-IS database log information.
Example:
RP/0/RP0/CPU0:router# show isis database-log
level 1
SUMMARY STEPS
1. configure
2. router isis instance-id
3. nsf {cisco | ietf}
4. nsf interface-expires number
5. nsf interface-timer seconds
6. nsf lifetime seconds
7. end
or
commit
8. show running-config [command]
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router isis instance-id Enables IS-IS routing for the specified routing instance, and
places the router in router configuration mode.
Example: • You can change the level of routing to be performed by
RP/0/RP0/CPU0:router(config)# router isis isp a particular routing instance using the is-type router
configuration command.
Step 3 nsf {cisco | ietf} Enables NSF on the next restart.
• Enter the cisco keyword to run IS-IS in heterogeneous
Example: networks that might not have adjacent NSF-aware
RP/0/RP0/CPU0:router(config-isis)# nsf ietf networking devices.
• Enter the ietf keyword to enable IS-IS in homogeneous
networks where all adjacent networking devices
support IETF draft-based restartability.
SUMMARY STEPS
1. configure
2. router isis instance-id
3. lsp-password {hmac-md5 | text} {clear | encrypted} password [level {1 | 2}] [send-only] [snp
send-only]
4. interface type instance
5. hello-password {hmac-md5 | text} {clear | encrypted} password [level {1 | 2}] [send-only]
6. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router isis instance-id Enables IS-IS routing for the specified routing instance, and
places the router in router configuration mode.
Example: • You can change the level of routing to be performed by
RP/0/RP0/CPU0:router(config)# router isis isp a particular routing instance using the is-type
command.
Example:
RP/0/RP0/CPU0:router(config-isis)# interface
POS 0/1/0/3
Example:
RP/0/RP0/CPU1:router(config-isis-if)#
hello-password text clear mypassword
Step 6 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-isis-if)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-isis-if)# commit 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.
Prerequisite
Your network must support the following Cisco IOS XR software features before you enable MPLS TE
for IS-IS on your router:
• MPLS
• IP Cisco Express Forwarding (CEF)
Note You must enter the commands in the following task list on every IS-IS router in the traffic-engineered
portion of your network.
Restrictions
MPLS traffic engineering currently supports only a single IS-IS level and does not support routing and
signaling of LSPs over unnumbered IP links. Therefore, do not configure the feature over those links.
SUMMARY STEPS
1. configure
2. router isis instance-id
3. address-family {ipv4 | ipv6} [unicast]
4. mpls traffic-eng level {1 | 2}
5. mpls traffic-eng router-id {ip-address | interface-name}
6. metric-style wide [level {1 | 2}]
7. end
or
commit
8. show isis [instance instance-id] mpls traffic-eng tunnel
9. show isis [instance instance-id] mpls traffic-eng adjacency-log
10. show isis [instance instance-id] mpls traffic-eng advertisements
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router isis instance-id Enables IS-IS routing for the specified routing instance, and
places the router in router configuration mode.
Example: • You can change the level of routing to be performed by
RP/0/RP0/CPU0:router(config)# router isis isp a particular routing instance using the is-type router
configuration command.
Step 3 address-family {ipv4 | ipv6} [unicast] Specifies the IPv4 or IPv6 address family, and enters router
address family configuration mode.
Example: • This example specifies the unicast IPv6 address family.
RP/0/RP0/CPU0:router(config-isis)#
address-family ipv6 unicast
Step 4 mpls traffic-eng level {1 | 2} Configures a router running IS-IS to flood MPLS TE link
information into the indicated IS-IS level.
Example:
RP/0/RP0/CPU0:router(config-isis-af)# mpls
traffic-eng level 1
Example:
RP/0/RP0/CPU0:router# show isis instance isp
mpls traffic-eng tunnel
Step 9 show isis [instance instance-id] mpls (Optional) Displays a log of MPLS TE IS-IS adjacency
traffic-eng adjacency-log changes.
Example:
RP/0/RP0/CPU0:router# show isis instance isp
mpls traffic-eng adjacency-log
Step 10 show isis [instance instance-id] mpls (Optional) Displays the latest flooded record from MPLS
traffic-eng advertisements TE.
Example:
RP/0/RP0/CPU0:router# show isis instance isp
mpls traffic-eng advertisements
SUMMARY STEPS
1. configure
2. router isis instance-id
3. log adjacency changes
4. interface type number
5. hello-padding {disable | sometimes} [level {1 | 2}]
6. hello-interval seconds [level {1 | 2}]
7. hello-multiplier multiplier [level {1 | 2}]
8. hello-password {hmac-md5 | text} {clear | encrypted} password [level {1 | 2}] [send-only]
9. end
or
commit
10. show isis [instance instance-id] adjacency [interface-type interface-instance] [detail] [systemid
system-id]
11. show isis adjacency-log
12. show isis [instance instance-id] interface [type instance] [brief | detail] [level {1 | 2}]
13. show isis [instance instance-id] neighbors [interface-type interface-instance] [summary] [detail]
[systemid system-id]
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router isis instance-id Enables IS-IS routing for the specified routing instance,
and places the router in router configuration mode.
Example: • You can change the level of routing to be performed
RP/0/RP0/CPU0:router(config)# router isis isp by a particular routing instance using the is-type
command.
Step 3 log adjacency changes Generates a log message when an IS-IS adjacency
changes state (up or down).
Example:
RP/0/RP0/CPU0:router(config-isis)# log adjacency
changes
Step 4 interface type number Enters interface configuration mode.
Example:
RP/0/RP0/CPU0:router(config-isis)# interface POS
0/1/0/3
Step 5 hello-padding {disable | sometimes} [level {1 | Configures padding on IS-IS hello PDUs for all IS-IS
2}] interfaces on the router.
• Hello padding applies to only this interface and not
Example: to all interfaces.
RP/0/RP0/CPU0:router(config-isis-if)# hello-paddi
ng sometimes
Step 6 hello-interval seconds [level {1 | 2}] Specifies the length of time between hello packets that
the software sends.
Example:
RP/0/RP0/CPU0:router(config-isis-if)#
hello-interval 6
Step 7 hello-multiplier multiplier [level {1 | 2}] Specifies the number of IS-IS hello packets a neighbor
must miss before the router should declare the adjacency
as down.
Example:
RP/0/RP0/CPU0:router(config-isis-if)# • A higher value increases the networks tolerance for
hello-multiplier 10 dropped packets, but also may increase the amount
of time required to detect the failure of an adjacent
router.
• Conversely, not detecting the failure of an adjacent
router can result in greater packet loss.
Example:
RP/0/RP0/CPU0:router# show isis instance isp
adjacency ipv4
Step 11 show isis adjacency-log (Optional) Displays a log of the most recent adjacency
state transitions.
Example:
RP/0/RP0/CPU1:router# show isis adjacency-log
Example:
RP/0/RP0/CPU0:router# show isis interface POS
0/1/0/1 brief
Step 13 show isis [instance instance-id] neighbors (Optional) Displays information about IS-IS neighbors.
[interface-type interface-instance] [summary]
[detail] [systemid system-id]
Example:
RP/0/RP0/CPU0:router# show isis neighbors summary
SUMMARY STEPS
1. configure
2. router isis instance-id
3. address-family {ipv4 | ipv6} [unicast]
4. spf-interval {[initial-wait initial | secondary-wait secondary | maximum-wait maximum]
...}[level {1 | 2}]
5. ispf [startup-delay seconds] [level {1 | 2}]
6. ispf startup-delay seconds [level {1 | 2}]
7. end
or
commit
8. show isis [instance instance-id] spf-log [level {1 | 2}] [ipv4 | ipv6] [unicast] [ispf | fspf | prc]
[detail] [internal] [last number | first number]
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router isis instance-id Enables IS-IS routing for the specified routing instance, and
places the router in router configuration mode.
Example: • You can change the level of routing to be performed by
RP/0/RP0/CPU0:router(config)# router isis isp a particular routing instance using the is-type router
configuration command.
Step 3 address-family {ipv4 | ipv6} [unicast] Specifies the IPv4 or IPv6 address family, and enters router
address family configuration mode.
Example: • This example specifies the unicast IPv6 address family.
RP/0/RP0/CPU0:router(config-isis)#
address-family ipv6 unicast
Step 4 spf-interval { [initial-wait initial | (Optional) Controls the minimum time between successive
secondary-wait secondary | maximum-wait SPF calculations.
maximum] ...} [level {1 | 2}]
• This value imposes a delay in the SPF computation
after an event trigger and enforces a minimum elapsed
Example: time between SPF runs.
RP/0/RP0/CPU0:router(config-isis-af)#
spf-interval initial-wait 10 maximum-wait 30 • If this value is configured too low, the router can lose
too many CPU resources when the network is unstable.
• Configuring the value too high delays changes in the
network topology that result in lost packets.
• The SPF interval does not apply to the running of the
ISPF because that algorithm runs immediately on
receiving a changed LSP.
Step 5 ispf [startup-delay seconds] [level {1 | 2}] (Optional) Configures incremental IS-IS ISPF to calculate
network topology.
Example:
RP/0/RP0/CPU0:router(config-isis-af)# ispf
Step 6 ispf startup-delay seconds [level {1 | 2}] (Optional) Configures the time delay between the starting
of the IS-IS instance and the activation of ISPF.
Example:
RP/0/RP0/CPU0:router(config-isis-af)# ispf
startup-delay 600
Example:
RP/0/RP0/CPU0:router# show isis instance 1
spf-log ipv4
Summary Steps
1. configure
2. router isis instance-id
3. address-family {ipv4 | ipv6} [unicast]
4. mpls traffic-eng multicast-intact
5. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router isis instance-id Enables IS-IS routing for the specified routing process, and
places the router in router configuration mode. In this
example, the IS-IS instance is called isp.
Example:
RP/0/RP0/CPU0:router(config)# router isis isp
Step 3 address-family {ipv4 | ipv6} [unicast] Specifies the IPv4 or IPv6 address family, and enters router
address family configuration mode. This example specifies
the unicast IPv4 address family.
Example:
RP/0/RP0/CPU0:router(config-isis)#
address-family ipv4
Step 4 mpls traffic-eng multicast-intact Enables multicast-intact.
Example:
RP/0/RP0/CPU0:router(config-isis)# mpls
traffic-eng multicast-intact
Step 5 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-isis-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-isis-af)# commit 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.
SUMMARY STEPS
1. configure
2. router isis instance-id
3. set-overload-bit [on-startup {delay | wait-for-bgp}] [level {1 | 2}]
4. address-family {ipv4 | ipv6} [unicast]
5. default-information originate [route-map map-name]
6. redistribute isis instance [level-1 | level-2 | level-1-2] [metric metric] [metric-type {internal |
external}] policy policy-name]
7. summary-prefix [address/prefix-length] [level {1 | 2}]
or
summary-prefix [ipv6-prefix/prefix-length] [level {1 | 2}]
8. maximum-paths route-number
9. distance weight [address/prefix-length [route-list-name]]
10. set-attached-bit
11. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router isis instance-id Enables IS-IS routing for the specified routing process, and
places the router in router configuration mode.
Example: • By default, all IS-IS instances are automatically
RP/0/RP0/CPU0:router(config)# router isis isp Level 1 and Level 2. You can change the level of
routing to be performed by a particular routing instance
using the is-type command.
Step 3 set-overload-bit [ on-startup {delay | (Optional) Sets the overload bit.
wait-for-bgp}] [level {1 | 2}]
Note The configured overload bit behavior does not apply
to NSF restarts because the NSF restart does not set
Example: the overload bit during restart.
RP/0/RP0/CPU0:router(config-isis)#
set-overload-bit
Step 4 address-family {ipv4 | ipv6} [unicast] Specifies the IPv4 or IPv6 address family, and enters router
address family configuration mode.
Example: • This example specifies the unicast IPv6 address family.
RP/0/RP0/CPU0:router(config-isis)#
address-family ipv6 unicast
Where to Go Next
To implement more IP routing protocols, see the following document modules:
• Implementing OSPF on Cisco IOS XR Software
• Implementing BGP on Cisco IOS XR Software
Additional References
The following sections provide references related to implementing IS-IS on Cisco IOS XR software.
Related Documents
Related Topic Document Title
IS-IS commands: complete command syntax, Cisco IOS XR Routing Command Reference, Release 3.2
command modes, command history, defaults, usage
guidelines, and examples
MPLS TE feature information Implementing MPLS Traffic Engineering on Cisco IOS XR Software
module in the Cisco IOS XR Multiprotocol Label Switching
Configuration Guide, Release 3.2
Standards
Standards Title
Draft-ietf-isis-ipv6-05.txt Routing IPv6 with IS-IS, by Christian E. Hopps
Draft-ietf-isis-wg-multi-topology-06.txt M-ISIS: Multi Topology (MT) Routing in IS-IS, by Tony Przygienda,
Naiming Shen, and Nischal Sheth
Draft-ietf-isis-traffic-05.txt IS-IS Extensions for Traffic Engineering, by Henk Smit and Toni Li
Draft-ietf-isis-restart-04.txt Restart Signalling for IS-IS, by M. Shand and Les Ginsberg
Draft-ietf-isis-igp-p2p-over-lan-05.txt Point-to-point operation over LAN in link-state routing protocols, by
Naiming Shen
MIBs
MIBs MIBs Link
There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using
Cisco IOS XR software, use the Cisco MIB Locator found at the
following URL:
http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
RFCs Title
RFC 1142 OSI IS-IS Intra-domain Routing Protocol
RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
RFC 2763 Dynamic Hostname Exchange Mechanism for IS-IS
RFC 2966 Domain-wide Prefix Distribution with Two-Level IS-IS
RFC 2973 IS-IS Mesh Groups
RFC 3277 IS-IS Transient Blackhole Avoidance
RFC 3373 Three-Way Handshake for IS-IS Point-to-Point Adjacencies
RFC 3567 IS-IS Cryptographic Authentication
Technical Assistance
Description Link
The Cisco Technical Support website contains http://www.cisco.com/techsupport
thousands of 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.
Open Shortest Path First (OSPF) is an Interior Gateway Protocol (IGP) developed by the OSPF working
group of the Internet Engineering Task Force (IETF). Designed expressly for IP networks, OSPF
supports IP subnetting and tagging of externally derived routing information. OSPF also allows packet
authentication and uses IP multicast when sending and receiving packets.
Implementing OSPF version 3 (OSPFv3) expands on OSPF Version 2, to provide support for IPv6
routing prefixes.
This module describes the concepts and tasks you need to implement both versions of OSPF on your
Cisco IOS XR router. The term “OSPF” implies both versions of the routing protocol, unless otherwise
noted.
Note For more information about OSPF on the Cisco IOS XR software and complete descriptions of the OSPF
commands listed in this module, see the “Related Documents” section of this module. To locate
documentation for other commands that might appear during execution of a configuration task, search
online in the Cisco IOS XR software master command index.
Contents
• Prerequisites for Implementing OSPF on Cisco IOS XR Software, page RC-128
• Information About Implementing OSPF on Cisco IOS XR Software, page RC-128
• How to Implement OSPF on Cisco IOS XR Software, page RC-144
• Configuration Examples for Implementing OSPF on Cisco IOS XR Software, page RC-187
• Where to Go Next, page RC-192
• Additional References, page RC-193
OSPF typically requires coordination among many internal routers: Area Border Routers (ABRs), which
are routers attached to multiple areas, and Autonomous System Border Routers (ASBRs) that export
reroutes from other sources (for example, IS-IS, BGP, or static routes) into the OSPF topology. At a
minimum, OSPF-based routers or access servers can be configured with all default parameter values, no
authentication, and interfaces assigned to areas. If you intend to customize your environment, you must
ensure coordinated configurations of all routers.
Tip Understanding hierarchical CLI and CLI inheritance saves you considerable configuration time. See the
“Configuring Authentication at Different Hierarchical Levels for OSPF Version 2” section on
page RC-155 to understand how to implement these fundamentals. In addition, Cisco IOS XR examples
are provided in the “Configuration Examples for Implementing OSPF on Cisco IOS XR Software”
section on page RC-187.
OSPF Domain
(BGP autonomous Area 0
system 109) backbone
R3
Area 2 Area 1
stub area
ABR 2 ABR 1
R1
R2
ASBR 1
88721
Autonomous Systems
The autonomous system is a collection of networks, under the same administrative control, that share
routing information with each other. An autonomous system is also referred to as a routing domain.
Figure 6 shows two autonomous systems: A and B. An autonomous system can consist of one or more
OSPF areas.
Areas
Areas allow the subdivision of an autonomous system into smaller, more manageable networks or sets
of adjacent networks. As shown in Figure 6, autonomous system A consists of three areas: Area 0, Area
1, and Area 2.
OSPF hides the topology of an area from the rest of the autonomous system. The network topology for
an area is visible only to routers inside that area. When OSPF routing is within an area, it is called
intra-area routing. This routing limits the amount of link-state information flood into the network,
reducing routing traffic. It also reduces the size of the topology information in each router, conserving
processing and memory requirements in each router.
Also, the routers within an area cannot see the detailed network topology outside the area. Because of
this restricted view of topological information, you can control traffic flow between areas and reduce
routing traffic when the entire autonomous system is a single routing domain.
Backbone Area
A backbone area is responsible for distributing routing information between multiple areas of an
autonomous system. OSPF routing occurring outside of an area is called interarea routing.
The backbone itself has all properties of an area. It consists of ABRs, routers, and networks only on the
backbone. As shown in Figure 6, Area 0 is an OSPF backbone area. Any OSPF backbone area has a
reserved area ID of 0.0.0.0.
Stub Area
A stub area is an area that does not accept or detailed network information external to the area. A stub
area typically has only one router that interfaces the area to the rest of the autonomous system. The stub
ABR advertises a single default route to external destinations into the stub area. Routers within a stub
area use this route for destinations outside the area and the autonomous system. This relationship
conserves LSA database space that would otherwise be used to store external LSAs flooded into the area.
In Figure 6, Area 2 is a stub area that is reached only through ABR 2. Area 0 cannot be a stub area.
NSSA is similar to the stub area. NSSA does not flood Type 5 external LSAs from the core into the area,
but can import autonomous system external routes in a limited fashion within the area.
NSSA allows importing of Type 7 autonomous system external routes within an NSSA area by
redistribution. These Type 7 LSAs are translated into Type 5 LSAs by NSSA ABRs, which are flooded
throughout the whole routing domain. Summarization and filtering are supported during the translation.
Use NSSA to simplify administration if you are a network administrator that must connect a central site
using OSPF to a remote site that is using a different routing protocol.
Before NSSA, the connection between the corporate site border router and remote router could not be
run as an OSPF stub area because routes for the remote site could not be redistributed into a stub area,
and two routing protocols needed to be maintained. A simple protocol like RIP was usually run and
handled the redistribution. With NSSA, you can extend OSPF to cover the remote connection by
defining the area between the corporate router and remote router as an NSSA. Area 0 cannot be an
NSSA.
Routers
The OSPF network is composed of ABRs, ASBRs, and interior routers.
ABRs are routers with multiple interfaces that connect directly to networks in two or more areas. An
ABR runs a separate copy of the OSPF algorithm and maintains separate routing data for each area that
is attached to, including the backbone area. ABRs also send configuration summaries for their attached
areas to the backbone area, which then distributes this information to other OSPF areas in the
autonomous system. In Figure 6, there are two ABRs. ABR 1 interfaces Area 1 to the backbone area.
ABR 2 interfaces the backbone Area 0 to Area 2, a stub area.
ASBRs provide connectivity from one autonomous system to another system. ASBRs exchange their
autonomous system routing information with boundary routers in other autonomous systems. Every
router inside an autonomous system knows how to reach the boundary routers for its autonomous
system.
ASBRs can import external routing information from other protocols like BGP and redistribute them as
AS-external (ASE) Type 5 LSAs to the OSPF network. If the Cisco IOS XR router is an ASBR, you can
configure it to advertise VIP addresses for content as autonomous system external routes. In this way,
ASBRs flood information about external networks to routers within the OSPF network.
ASBR routes can be advertised as a Type 1 or Type 2 ASE. The difference between Type 1 and Type 2
is how the cost is calculated. For a Type 2 ASE, only the external cost (metric) is considered when
multiple paths to the same destination are compared. For a Type 1 ASE, the combination of the external
cost and cost to reach the ASBR is used. Type 2 external cost is the default and is always more costly
than an OSPF route and used only if no OSPF route exists.
Interior Routers
The interior routers (such as R1 in Figure 6) attached to one area (for example, all the interfaces reside
in the same area).
• The primary IPv4 address of the interface specified by the OSPF router-id command.
• The 32-bit numeric value specified by the router-id command in global configuration mode. (This
value must be an IPv4 address assigned to an interface on this router.)
• By using the highest IPv4 address on a loopback interface in the system if the router is booted with
saved loopback address configuration.
• The primary IPv4 address of an interface over which this OSPF process is running.
We recommend that the router ID be set by the router-id command in router configuration mode.
Separate OSPF processes could share the same router ID, in which case they cannot reside in the same
OSPF routing domain.
Plain text authentication (also known as Type 1 authentication) uses a password that travels on the
physical medium and is easily visible to someone that does not have access permission and could use
the password to infiltrate a network. Therefore, plain text authentication does not provide security. It
might protect against a faulty implementation of OSPF or a misconfigured OSPF interface trying to send
erroneous OSPF packets.
MD5 Authentication
MD5 authentication provides a means of security. No password travels on the physical medium. Instead,
the router uses MD5 to produce a message digest of the OSPF packet plus the key, which is sent on the
physical medium. Using MD5 authentication prevents a router from accepting unauthorized or
deliberately malicious routing updates, which could compromise your network security by diverting
your traffic.
Note MD5 authentication supports multiple keys, requiring that a key number be associated with a key.
Authentication Strategies
Authentication can be specified for an entire process or area, or on an interface or a virtual link. An
interface or virtual link can be configured for only one type of authentication, not both. Authentication
configured for an interface or virtual link overrides authentication configured for the area or process.
If you intend for all interfaces in an area to use the same type of authentication, you can configure fewer
commands if you use the area authentication command (and specify the message-digest keyword if
you want the entire area to use MD5 authentication). This strategy requires fewer commands than
specifying authentication for each interface.
Key Rollover
To support the changing of a plain text key or MD5 key in an operational network without disrupting
OSPF adjacencies (and hence the topology), a key rollover mechanism is supported. As a network
administrator configures the new key into the multiple networking devices that communicate, some time
exists when different devices are using both a new key and an old key. If an interface is configured with
a new key, the software sends two copies of the same packet, each authenticated by the old key and new
key. The software tracks which devices start using the new key, and the software stops sending duplicate
packets after it detects that all of its neighbors are using the new key. The software then discards the old
key. The network administrator must then remove the old key from each the configuration file of each
router.
The software looks at the priority of the routers on the segment to determine which routers are the DR
and BDR. The router with the highest priority is elected the DR. If there is a tie, then the router with the
higher router ID takes precedence. After the DR is elected, the BDR is elected the same way. A router
with a router priority set to zero is ineligible to become the DR or BDR.
• Network LSA (Type 2)—Describes the link state and cost information for all routers attached to a
multiaccess network segment. This LSA lists all OSPF routers that have interfaces attached to the
network segment. Only the elected designated router for the network segment can generate and track
the network LSA for the segment. In OSPFv3, network LSAs have no address information and are
network-protocol-independent.
• Interarea-prefix LSA for ABRs (Type 3)—Advertises internal networks to routers in other areas
(interarea routes). Type 3 LSAs may represent a single network or set of networks aggregated into
one prefix. Only ABRs generate Type 3 LSAs. In OSPFv3, addresses for these LSAs are expressed
as “prefix and prefix length” instead of “address and mask.” The default route is expressed as a
prefix with length 0.
• Interarea-router LSA for ASBRs (Type 4)—Advertises an ASBR and the cost to reach it. Routers
that are trying to reach an external network use these advertisements to determine the best path to
the next hop. ABRs generate Type 4 LSAs.
• Autonomous system external LSA (Type 5)—Redistributes routes from another autonomous
system, usually from a different routing protocol into OSPF. In OSPFv3, addresses for these LSAs
are expressed as “prefix and prefix length” instead of “address and mask.” The default route is
expressed as a prefix with length 0.
• Link LSA (Type 8)—Has link-local flooding scope and is never flooded beyond the link with which
it is associated. Link LSAs provide the link-local address of the router to all other routers attached
to the link or network segment, inform other routers attached to the link of a list of IPv6 prefixes to
associate with the link, and allow the router to assert a collection of Options bits to associate with
the network LSA that is originated for the link.
• Intra-area-prefix LSAs (Type 9)—A router can originate multiple intra-area-prefix LSAs for every
router or transit network, each with a unique link-state ID. The link-state ID for each
intra-area-prefix LSA describes its association to either the router LSA or network LSA and
contains prefixes for stub and transit networks.
An address prefix occurs in almost all newly defined LSAs. The prefix is represented by three fields:
Prefix Length, Prefix Options, and Address Prefix. In OSPFv3, addresses for these LSAs are expressed
as “prefix and prefix length” instead of “address and mask.” The default route is expressed as a prefix
with length 0.
Inter-area-prefix and intra-area-prefix LSAs carry all IPv6 prefix information that, in IPv4, is included
in router LSAs and network LSAs. The Options field in certain LSAs (router LSAs, network LSAs,
interarea-router LSAs, and link LSAs) has been expanded to 24 bits to provide support for OSPF in IPv6.
In OSPFv3, the sole function of link-state ID in interarea-prefix LSAs, interarea-router LSAs, and
autonomous system external LSAs is to identify individual pieces of the link-state database. All
addresses or router IDs that are expressed by the link-state ID in OSPF Version 2 are carried in the body
of the LSA in OSPFv3.
In the case in which an area cannot be connected to Area 0, you must configure a virtual link between
that area and Area 0. The two endpoints of a virtual link are ABRs, and the virtual link must be
configured in both routers. The common nonbackbone area to which the two routers belong is called a
transit area. A virtual link specifies the transit area and the router ID of the other virtual endpoint (the
other ABR).
A virtual link cannot be configured through a stub area or NSSA.
Figure 7 illustrates a virtual link from Area 3 to Area 0.
Area 0
Backbone
Area 1 Area 3
Transit Area
ASBR 1
88722
ASBR 2
The interval at which the SPF calculations occur is chosen dynamically and based on the frequency of
topology changes in the network. The chosen interval is within the boundary of the user-specified value
ranges. If network topology is unstable, SPF throttling calculates SPF scheduling intervals to be longer
until topology becomes stable.
SPF calculations occur at the interval set by the timers throttle spf command. The wait interval
indicates the amount of time to wait until the next SPF calculation occurs. Each wait interval after that
calculation is twice as long as the previous interval until the interval reaches the maximum wait time
specified.
The SPF timing can be better explained using an example. In this example, the start interval is set at
5 milliseconds (ms), initial wait interval at 1000 ms, and maximum wait time at 90,000 ms.
timers spf 5 1000 90000
Figure 8 shows the intervals at which the SPF calculations occur as long as at least one topology change
event is received in a given wait interval.
88278
5 ms 2000 ms 8000 ms 32000 ms 90000 ms
1000 ms 4000 ms 16000 ms 64000 ms
Notice that the wait interval between SPF calculations doubles when at least one topology change event
is received during the previous wait interval. After the maximum wait time is reached, the wait interval
remains the same until the topology stabilizes and no event is received in that interval.
If the first topology change event is received after the current wait interval, the SPF calculation is
delayed by the amount of time specified as the start interval. The subsequent wait intervals continue to
follow the dynamic pattern.
If the first topology change event occurs after the maximum wait interval begins, the SPF calculation is
again scheduled at the start interval and subsequent wait intervals are reset according to the parameters
specified in the timers throttle spf command. Notice in Figure 9 that a topology change event was
received after the start of the maximum wait time interval and that the SPF intervals have been reset.
88279
SPF scheduled at
start interval
through intelligent line cards while the standby Route Processor (RP) assumes control from the failed
RP. The ability of line cards to remain up through a failover and to be kept current with the Forwarding
Information Base (FIB) on the active RP is key to Cisco IOS XR NSF operation.
Routing protocols, such as OSPF, run only on the active RP or DRP and receive routing updates from
their neighbor routers. When an OSPF NSF-capable router performs an RP failover, it must perform two
tasks to resynchronize its link-state database with its OSPF neighbors. First, it must relearn the available
OSPF neighbors on the network without causing a reset of the neighbor relationship. Second, it must
reacquire the contents of the link-state database for the network.
As quickly as possible after an RP failover, the NSF-capable router sends an OSPF NSF signal to
neighboring NSF-aware devices. This signal is in the form of a link-local LSA generated by the
failed-over router. Neighbor networking devices recognize this signal as a cue that the neighbor
relationship with this router should not be reset. As the NSF-capable router receives signals from other
routers on the network, it can begin to rebuild its neighbor list.
After neighbor relationships are re-established, the NSF-capable router begins to resynchronize its
database with all of its NSF-aware neighbors. At this point, the routing information is exchanged
between the OSPF neighbors. After this exchange is completed, the NSF-capable device uses the routing
information to remove stale routes, update the RIB, and update the FIB with the new forwarding
information. OSPF on the router as well as the OSPF neighbors are now fully converged.
Note The standardized IETF version of NSF, known as OSPF graceful restart (RFC 3623) is also supported.
Restart Mode
When the OSPFv3 process starts up, it determines whether it must attempt a graceful restart. The
determination is based on whether graceful restart was previously enabled. (OSPFv3 does not attempt a
graceful restart upon the first-time startup of the router.) When OSPFv3 graceful restart is enabled, it
changes the purge timer in the RIB to a non-zero value. See Configuring OSPFv3 Graceful Restart,
page RC-181, for descriptions of how to enable and configure the Graceful Restart feature.
During a graceful restart, the router does not populate OSPFv3 routes in the RIB. It tries to bring up full
adjacencies with the fully-adjacent neighbors that OSPFv3 had before the restart. Eventually, the
OSPFv3 process indicates to the RIB that it has converged either for the purpose of terminating the
graceful restart (for any reason) or because it has completed the graceful restart.
The following are general details about restart mode. More detailed information on behavior and certain
restrictions and requirements appear in the Graceful Restart Requirements and Restrictions section.
• If the OSPFv3 attempts a restart too soon after the most recent restart, the OSPFv3 process is most
likely crashing repeatedly, so the new graceful restart stops running. To control the period between
allowable graceful restarts, use the graceful-restart interval command. A description of how to set
this time period appears in the section Configuring the Minimum Time Required Between Restarts,
page RC-183.
• When OSFPv3 starts a graceful restart with the first interface that comes up, a timer starts running
to limit the duration (or lifetime) of the graceful restart. You can configure this period with the
graceful-restart lifetime command. On each interface that comes up, a grace LSA (type 11) is
flooded to indicate to the neighboring routers that this router is attempting graceful restart. The
neighbors enter into helper mode.
• The designated router and backup designated router check of the hello packet received from the
restarting neighbor is bypassed because it might not be valid.
Helper Mode
Helper mode is enabled by default. When a (helper) router receives a grace LSA (type 11) from a router
that is attempting a graceful restart, the following events occur:
• If helper mode has been disabled through the graceful-restart helper disable command, the router
drops the LSA packet.
• If helper mode is enabled, the router enters helper mode if all of the following conditions are met.
– The local router itself is not attempting a graceful restart.
– The local (helping) router has full adjacency with the sending neighbor.
– The value of lsage (link state age) in the received LSA is less than the requested grace period.
– The sender of the grace LSA is the same as the originator of the grace LSA.
• Upon entering helper mode, a router performs its helper function for a specific period of time. This
time period is the lifetime value from the router that is in restart mode—minus the value of lsage in
the received grace LSA. If the graceful restart succeeds in time, the helper’s timer is stopped before
it expires. If the helper’s timer does expire, the adjacency to the restarting router is brought down,
and normal OSPFv3 functionality resumes.
• The dead timer is not honored by the router that is in helper mode.
• A router in helper mode ceases to perform the helper function in any of the following cases:
– The helper router is able to bring up a FULL adjacency with the restarting router.
– The local timer for the helper function expires.
• If graceful restart is enabled, the adjacency creation time of all the neighbors is saved in the system
database (SysDB). The purpose for saving the creation time is so that OSPFv3 can use the original
adjacency creation time to display the uptime for that neighbor after the restart.
Multicast-Intact Feature
The multicast-intact feature provides the ability to run multicast routing (PIM) when IGP shortcuts are
configured and active on the router. Both OSPFv2 and IS-IS support the multicast-intact feature.
You can enable multicast-intact in the IGP when multicast routing protocols (PIM) are configured and
IGP shortcuts are configured on the router. IGP shortcuts are MPLS tunnels that are exposed to IGP. The
IGPs routes IP traffic over these tunnels to destinations that are downstream from the egress router of
the tunnel (from an SPF perspective). PIM cannot use IGP shortcuts for propagating PIM joins because
reverse path forwarding (RPF) cannot work across a unidirectional tunnel.
When you enable multicast-intact on an IGP, the IGP publishes a parallel or alternate set of equal-cost
next-hops for use by PIM. These next-hops are called mcast-intact next-hops. The mcast-intact
next-hops have the following attributes:
• They are guaranteed not to contain any IGP shortcuts.
• They are not used for unicast routing but are used only by PIM to look up an IPv4 next-hop to a PIM
source.
• They are not published to the FIB.
• When multicast-intact is enabled on an IGP, all IPv4 destinations that were learned through
link-state advertisements are published with a set equal-cost mcast-intact next-hops to the RIB. This
attribute applies even when the native next-hops have no IGP shortcuts.
• In OSPF, the max-paths (number of equal-cost next-hops) limit is applied separately to the native
and mcast-intact next-hops. The number of equal cost mcast-intact next-hops is the same as that
configured for the native next-hops. (In IS-IS, the behavior is slightly different.)
Enabling OSPF
This task explains how to perform the minimum OSPF configuration on your router that is to enable an
OSPF process with a router ID, configure a backbone or nonbackbone area, and then assign one or more
interfaces on which OSPF runs.
Prerequisites
Although you can configure OSPF before you configure an IP address, no OSPF routing occurs until at
least one IP address is configured.
SUMMARY STEPS
1. configure
2. router ospf process-name
or
router ospfv3 process-name
3. router-id {ipv4-address | interface-type interface-instance}
4. area area-id
5. interface type instance
6. Repeat Step 5 for each interface that use OSPF.
7. log adjacency changes [detail] [enable | disable]
8. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router ospf process-name Enables OSPF routing for the specified routing process, and
or places the router in router configuration mode.
router ospfv3 process-name or
Enables OSPFv3 routing for the specified routing process,
Example: and places the router in router ospfv3 configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf 1
or Note The process-name argument is any alphanumeric
string no longer than 40 characters.
RP/0/RP0/CPU0:router(config)# router ospfv3 1
Step 3 router-id {ipv4-address | interface-type Configures a router ID for the OSPF process.
interface-instance}
Note We recommend using a stable IP address as the
router ID.
Example:
RP/0/RP0/CPU0:router(config-ospf)# router-id
192.168.4.3
Step 4 area area-id Enters area configuration mode and configures an area for
the OSPF process.
Example: • Backbone areas have an area ID of 0.
RP/0/RP0/CPU0:router(config-ospf)# area 0
• Nonbackbone areas have a nonzero area ID.
• The area-id argument can be entered in dotted-decimal
or IPv4 address notation, such as area 1000 or
area 0.0.3.232. However, you must choose one form or
the other for an area. We recommend using the IPv4
address notation.
Step 5 interface type instance Enters interface configuration mode and associates one or
more interfaces for the area configured in Step 4.
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# interface
POS 0/1/0/3
Step 6 Repeat Step 5 for each interface that uses OSPF. —
SUMMARY STEPS
1. configure
2. router ospf process-name
or
router ospfv3 process-name
3. router-id {ipv4-address | interface-type interface-instance}
4. area area-id
5. stub [no-summary]
or
nssa [no-redistribution] [default-information-originate] [no-summary]
6. stub
or
nssa
7. default-cost cost
8. end
or
commit
9. Repeat this task on all other routers in the stub area or NSSA.
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router ospf process-name Enables OSPF routing for the specified routing process, and
or places the router in router configuration mode.
router ospfv3 process-name or
Enables OSPFv3 routing for the specified routing process,
Example: and places the router in router ospfv3 configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf 1
or Note The process-name argument is any alphanumeric
string no longer than 40 characters.
RP/0/RP0/CPU0:router(config)# router ospfv3 1
Step 3 router-id {ipv4-address | interface-type Configures a router ID for the OSPF process.
interface-instance}
Note We recommend using a stable IP address as the
router ID.
Example:
RP/0/RP0/CPU0:router(config-ospf)# router-id
192.168.4.3
Step 4 area area-id Enters area configuration mode and configures a
nonbackbone area for the OSPF process.
Example: • The area-id argument can be entered in dotted-decimal
RP/0/RP0/CPU0:router(config-ospf)# area 1 or IPv4 address notation, such as area 1000 or
area 0.0.3.232. However, you must choose one form or
the other for an area. We recommend using the IPv4
address notation.
Prerequisites
Configuring NBMA networks as either broadcast or nonbroadcast assumes that there are virtual circuits
from every router to every other router or a fully meshed network.
SUMMARY STEPS
1. configure
2. router ospf process-name
or
router ospfv3 process-name
3. router-id {ipv4-address | interface-type interface-instance}
4. area area-id
5. network {broadcast | non-broadcast | {point-to-multipoint [non-broadcast] | point-to-point}}
6. dead-interval seconds
7. hello-interval seconds
8. interface type number
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router ospf process-name Enables OSPF routing for the specified routing process, and
or places the router in router configuration mode.
router ospfv3 process-name or
Enables OSPFv3 routing for the specified routing process,
Example: and places the router in router ospfv3 configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf 1
or Note The process-name argument is any alphanumeric
string no longer than 40 characters.
RP/0/RP0/CPU0:router(config)# router ospfv3 1
Step 3 router-id {ipv4-address | interface-type Configures a router ID for the OSPF process.
interface-instance}
Note We recommend using a stable IP address as the
router ID.
Example:
RP/0/RP0/CPU0:router(config-ospf)# router-id
192.168.4.3
Step 4 area area-id Enters area configuration mode and configures an area for
the OSPF process.
Example: • This example configures a backbone area.
RP/0/RP0/CPU0:router(config-ospf)# area 0
• The area-id argument can be entered in dotted-decimal
or IPv4 address notation, such as area 1000 or
area 0.0.3.232. However, you must choose one form or
the other for an area. We recommend using the IPv4
address notation.
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# network
non-broadcast
Step 6 dead-interval seconds (Optional) Sets the time to wait for a hello packet from a
neighbor before declaring the neighbor down.
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)#
dead-interval 40
Step 7 hello-interval seconds (Optional) Specifies the interval between hello packets that
OSPF sends on the interface.
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)#
hello-interval 10
Step 8 interface type instance Enters interface configuration mode and associates one or
more interfaces for the area configured in Step 4.
Example: • In this example, the interface inherits the nonbroadcast
RP/0/RP0/CPU0:router(config-ospf-ar)# interface network type and the hello and dead intervals from the
POS 0/2/0/0 areas because the values are not set at the interface
level.
Example:
RP/0/RP0/CPU0:router(config-ospf-ar-if)# exit
Step 12 interface type instance Enters interface configuration mode and associates one or
more interfaces for the area configured in Step 4.
Example: • In this example, the interface inherits the nonbroadcast
RP/0/RP0/CPU0:router(config-ospf-ar)# interface network type and the hello and dead intervals from the
POS 0/3/0/1 areas because the values are not set at the interface
level.
Note Authentication configured at the interface level overrides authentication configured at the area level and
the router process level. If an interface does not have authentication specifically configured, the interface
inherits the authentication parameter value from a higher hierarchical level. See the “OSPF Hierarchical
CLI and CLI Inheritance” section on page RC-131 for more information about hierarchy and inheritance.
Prerequisites
If you choose to configure authentication, you must first decide whether to configure plain text or MD5
authentication, and whether the authentication applies to all interfaces in a process, an entire area, or
specific interfaces. See the “Route Authentication Methods for OSPF Version 2” section on
page RC-135 for information about each type of authentication and when you should use a specific
method for your network.
SUMMARY STEPS
1. configure
2. router ospf process-name
3. router-id {ipv4-address | interface-type interface-instance}
4. authentication [message-digest | null]
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router ospf process-name Enables OSPF routing for the specified routing process, and
places the router in router configuration mode.
Example: Note The process-name argument is any alphanumeric
RP/0/RP0/CPU0:router(config)# router ospf 1 string no longer than 40 characters.
Step 3 router-id {ipv4-address | interface-type Configures a router ID for the OSPF process.
interface-instance}
Example:
RP/0/RP0/CPU0:router(config-ospf)# router-id
192.168.4.3
Step 4 authentication [message-digest | null] Enables MD5 authentication for the OSPF process.
• This authentication type applies to the entire router
Example: process unless overridden by a lower hierarchical level
RP/0/RP0/CPU0:router(config-ospf)# such as the area or interface.
authentication message-digest
Step 5 message-digest-key key-id md5 {key | clear key Specifies the MD5 authentication key for the OSPF process.
| encrypted key}
• The neighbor routers must have the same key identifier.
Example:
RP/0/RP0/CPU0:router(config-ospf)#
message-digest-key 4 md5 yourkey
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# exit
Step 10 area area-id Enters area configuration mode and configures a
nonbackbone area 1 for the OSPF process.
Example: • The area-id argument can be entered in dotted-decimal
RP/0/RP0/CPU0:router(config-ospf)# area 1 or IPv4 address notation, such as area 1000 or
area 0.0.3.232. However, you must choose one form or
the other for an area. We recommend using the IPv4
address notation.
Step 11 authentication [message-digest | null] Enables Type 1 (plain text) authentication that provides no
security.
Example: • The example specifies plain text authentication (by not
RP/0/RP0/CPU0:router(config-ospf-ar)# specifying a keyword). Use the authentication-key
authentication interface command to specify the plain text password.
Step 12 interface type instance Enters interface configuration mode and associates one or
more interfaces to the nonbackbone area 1 specified in
Step 7.
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# interface • All interfaces configured inherit the authentication
POS 0/1/0/0 parameter values configured for area 1.
Step 13 Repeat Step 12 for each interface that must —
communicate, using the same authentication.
Step 14 interface type instance Enters interface configuration mode and associates one or
more interfaces to a different authentication type.
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# interface
POS 0/3/0/0
Controlling the Frequency that the Same LSA Is Originated or Accepted for
OSPF
This task explains how to tune the convergence time of OSPF routes in the routing table when many
LSAs need to be flooded in a very short time interval.
SUMMARY STEPS
1. configure
2. router ospf process-name
or
router ospfv3 process-name
3. router-id {ipv4-address | interface-type interface-instance}
4. Do Step 5, Step 6 or both to control the frequency that the same LSA is originated or accepted.
5. timers lsa gen-interval seconds
6. timers lsa min-arrival seconds
7. timers lsa group-pacing seconds
8. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router ospf process-name Enables OSPF routing for the specified routing process, and
or places the router in router configuration mode.
router ospfv3 process-name or
Enables OSPFv3 routing for the specified routing process,
Example: and places the router in router ospfv3 configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf 1
or Note The process-name argument is any alphanumeric
string no longer than 40 characters.
RP/0/RP0/CPU0:router(config)# router ospfv3 1
Step 3 router-id {ipv4-address | interface-type Configures a router ID for the OSPF process.
interface-instance}
Note We recommend using a stable IP address as the
router ID.
Example:
RP/0/RP0/CPU0:router(config-ospf)# router-id
192.168.4.3
Step 4 Perform Step 5 or Step 6 or both to control the —
frequency that the same LSA is originated or accepted.
Step 5 timers lsa gen-interval seconds Changes the minimum interval between the same OSPF
LSAs that the router originates.
Example: • The default is 5 seconds for both OSPF and OSPFv3.
RP/0/RP0/CPU0:router(config-ospf)# timers lsa
gen-interval 10
Step 6 timers lsa min-arrival seconds Limits the frequency that new processes of any particular
OSPF Version 2 LSA can be accepted during flooding.
Example: • The default is 1 second.
RP/0/RP0/CPU0:router(config-ospf)# timers lsa
min-arrival 2
Note After you explicitly configure area parameter values, they are inherited by all interfaces bound to that
area—unless you override the values and configure them explicitly for the interface. An example is
provided in the “Virtual Link Configured with MD5 Authentication for OSPF Version 2: Example”
section on page RC-192.
Prerequisites
Meet the following prerequisites before you create a virtual link with MD5 authentication to area 0:
• Have the router ID of the neighbor router at the opposite end of the link to configure the local router.
You can use the show ospf or show ospfv3 command on the remote end to get its router ID.
• For a virtual link to be successful, you need a stable router ID at each end of the virtual link. You
do not want them to be subject to change, which could happen if they are assigned by default (See
the “OSPF Process and Router ID” section on page RC-134 for an explanation of how the router ID
is determined.) Therefore, we recommend that you perform one of the following tasks before
configuring a virtual link:
– Use the router-id command to set the router ID. This strategy is preferable.
– Configure a loopback interface so that the router has a stable router ID.
• Before configuring your virtual link for OSPF Version 2, you must decide whether to configure plain
text authentication, MD5 authentication, or no authentication (which is the default). Your decision
determines whether you need to perform additional tasks related to authentication.
Note If you decide to configure plain text authentication or no authentication, see the authentication
command provided in the OSPF Commands on Cisco IOS XR Software module in the Cisco IOS XR
Routing Command Reference.
SUMMARY STEPS
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 3 router ospf process-name Enables OSPF routing for the specified routing process, and
or places the router in router configuration mode.
router ospfv3 process-name or
Enables OSPFv3 routing for the specified routing process,
Example: and places the router in router ospfv3 configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf 1
or Note The process-name argument is any alphanumeric
string no longer than 40 characters.
RP/0/RP0/CPU0:router(config)# router ospfv3 1
Step 4 router-id {ipv4-address | interface-type Configures a router ID for the OSPF process.
interface-instance}
Note We recommend using a stable IPv4 address as the
router ID.
Example:
RP/0/RP0/CPU0:router(config-ospf)# router-id
192.168.4.3
Step 5 area area-id Enters area configuration mode and configures a
nonbackbone area for the OSPF process.
Example: • The area-id argument can be entered in dotted-decimal
RP/0/RP0/CPU0:router(config-ospf)# area 1 or IPv4 address notation, such as area 1000 or
area 0.0.3.232. However, you must choose one form or
the other for an area. We recommend using the IPv4
address notation.
Step 6 virtual-link router-id Defines an OSPF virtual link.
• See the “Virtual Link and Transit Area for OSPF”
Example: section on page RC-138.
RP/0/RP0/CPU0:router(config-ospf-ar)# virtual
link 10.3.4.5
Step 7 authentication message-digest Selects MD5 authentication for this virtual link.
Example:
RP/0/RP0/CPU0:router(config-ospf-ar-vl)#
authentication message-digest
Example:
RP/0/RP0/CPU0:router# show ospf 1 2
virtual-links
or
RP/0/RP0/CPU0:router# show ospfv3 1
virtual-links
Examples
In the following example, the show ospfv3 virtual links EXEC command verifies that the OSPF_VL0
virtual link to the OSPFv3 neighbor is up, the ID of the virtual link interface is 2, and the IPv6 address
of the virtual link endpoint is 2003:3000::1.
RP/0/RP0/CPU0:router# show ospfv3 virtual-links
SUMMARY STEPS
1. configure
2. router ospf process-name
or
router ospfv3 process-name
3. router-id {ipv4-address | interface-type interface-instance}
4. area area-id
5. range ip-address mask [advertise | not-advertise]
or
range ipv6-prefix/prefix-length [advertise | not-advertise]
6. interface type instance
7. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router ospf process-name Enables OSPF routing for the specified routing process, and
or places the router in router configuration mode.
router ospfv3 process-name or
Enables OSPFv3 routing for the specified routing process,
Example: and places the router in router ospfv3 configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf 1
or Note The process-name argument is any alphanumeric
string no longer than 40 characters.
RP/0/RP0/CPU0:router(config)# router ospfv3 1
Step 3 router-id {ipv4-address | interface-type Configures a router ID for the OSPF process.
interface-instance}
Note We recommend using a stable IPv4 address as the
router ID.
Example:
RP/0/RP0/CPU0:router(config-ospf)# router-id
192.168.4.3
Step 4 area area-id Enters area configuration mode and configures a
nonbackbone area for the OSPF process.
Example: • The area-id argument can be entered in dotted-decimal
RP/0/RP0/CPU0:router(config-ospf)# area 0 or IPv4 address notation, such as area 1000 or
area 0.0.3.232. However, you must choose one form or
the other for an area. We recommend using the IPv4
address notation.
Step 5 range ip-address mask [advertise | Consolidates and summarizes OSPF routes at an area
not-advertise] boundary.
or
• The advertise keyword causes the software to advertise
range ipv6-prefix/prefix-length [advertise |
not-advertise]
the address range of subnetworks in a Type 3 summary
LSA.
• The not-advertise keyword causes the software to
Example:
suppress the Type 3 summary LSA, and the
RP/0/RP0/CPU0:router(config-ospf-ar)# range
192.168.0.0 255.255.0.0 advertise subnetworks in the range remain hidden from other
or areas.
• In the first example, all subnetworks for network
192.168.0.0 are summarized and advertised by the
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# range ABR into areas outside the backbone.
4004:f000::/32 advertise • In the second example, two or more IPv4 interfaces are
covered by a 192.x.x network.
Prerequisites
For information about configuring routing policy, see the Implementing Routing Policy on Cisco IOS XR
Software module.
SUMMARY STEPS
1. configure
2. router ospf process-name
or
router ospfv3 process-name
3. router-id {ipv4-address | interface-type interface-instance}
4. redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [metric metric-value] [metric-type
type-value] [match {internal | external [1 | 2} | nssa-external [1 | 2}] [tag tag-value] [route-map
map-tag | policy policy-tag]
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router ospf process-name Enables OSPF routing for the specified routing process, and
or places the router in router configuration mode.
router ospfv3 process-name or
Enables OSPFv3 routing for the specified routing process,
Example: and places the router in router ospfv3 configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf 1
or Note The process-name argument is any alphanumeric
string no longer than 40 characters.
RP/0/RP0/CPU0:router(config)# router ospfv3 1
Step 3 router-id {ipv4-address | interface-type Configures a router ID for the OSPF process.
interface-instance}
Note We recommend using a stable IPv4 address as the
router ID.
Example:
RP/0/RP0/CPU0:router(config-ospf)# router-id
192.168.4.3
Prerequisites
See the “OSPF Shortest Path First Throttling” section on page RC-139 for information about OSPF SPF
throttling.
SUMMARY STEPS
1. configure
2. router ospf process-name
or
router ospfv3 process-name
3. router-id {ipv4-address | interface-type interface-instance}
4. timers throttle spf spf-start spf-hold spf-max-wait
5. area area-id
6. interface type instance
7. end
or
commit
8. show ospf [process-name]
or
show ospfv3 [process-name]
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router ospf process-name Enables OSPF routing for the specified routing process, and
or places the router in router configuration mode.
router ospfv3 process-name or
Enables OSPFv3 routing for the specified routing process,
Example: and places the router in router ospfv3 configuration mode.
RP/0/RP0/CPU0:router(config)# router ospf 1
or Note The process-name argument is any alphanumeric
string no longer than 40 characters.
RP/0/RP0/CPU0:router(config)# router ospfv3 1
Example:
RP/0/RP0/CPU0:router(config-ospf)# timers
throttle spf 10 4800 90000
Step 5 area area-id Enters area configuration mode and configures a backbone
area.
Example: • The area-id argument can be entered in dotted-decimal
RP/0/RP0/CPU0:router(config-ospf)# area 0 or IPv4 address notation, such as area 1000 or
area 0.0.3.232. However, you must choose one form or
the other for an area. We recommend using the IPv4
address notation.
Step 6 interface type instance Enters interface configuration mode and associates one or
more interfaces to the area.
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# interface
POS 0/1/0/3
Example:
RP/0/RP0/CPU0:router# show ospf 1
or
RP/0/RP0/CPU0:router# show ospfv3 2
Examples
In the following example, the show ospf EXEC command is used to verify that the initial SPF schedule
delay time, minimum hold time, and maximum wait time are configured correctly. Additional details are
displayed about the OSPF process, such as the router type and redistribution of routes.
RP/0/RP0/CPU0:router# show ospf 1
Note For a description of each output display field, see the show ospf command in the OSPF Commands on
Cisco IOS XR Software module in the Cisco IOS XR Routing Command Reference document.
Prerequisites
OSPF NSF requires that all neighbor networking devices be NSF aware, which happens automatically
after you install the Cisco IOS XR image on the router. If an NSF-capable router discovers that it has
non-NSF-aware neighbors on a particular network segment, it disables NSF capabilities for that
segment. Other network segments composed entirely of NSF-capable or NSF-aware routers continue to
provide NSF capabilities.
See the “Nonstop Forwarding for OSPF Version 2” section on page RC-140 for conceptual information.
Restrictions
The following are restrictions when configuring nonstop forwarding:
• OSPF Cisco NSF for virtual links is not supported.
• Neighbors must be NSF aware.
SUMMARY STEPS
1. configure
2. router ospf process-name
3. router-id {ipv4-address | interface-type interface-instance}
4. nsf
or
nsf enforce global
5. nsf interval seconds
6. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router ospf process-name Enables OSPF routing for the specified routing process, and
places the router in router configuration mode.
Example: Note The process-name argument is any alphanumeric
RP/0/RP0/CPU0:router(config)# router ospf 1 string no longer than 40 characters.
Step 3 router-id {ipv4-address | interface-type Configures a router ID for the OSPF process.
interface-instance}
Note We recommend using a stable IPv4 address as the
router ID.
Example:
RP/0/RP0/CPU0:router(config-ospf)# router-id
192.168.4.3
Step 4 nsf Enables OSPF NSF operations.
or
• Use the nsf command without the optional enforce and
nsf enforce global global keywords to abort the NSF restart mechanism on
the interfaces of detected non-NSF neighbors and allow
Example: NSF neighbors to function properly.
RP/0/RP0/CPU0:router(config-ospf)# nsf • Use the nsf command with the optional enforce and
or global keywords if the router is expected to perform
RP/0/RP0/CPU0:router(config-ospf)# nsf enforce NSF during restart. However, if non-NSF neighbors are
global detected, NSF restart is canceled for the entire OSPF
process.
Prerequisites
Your network must support the following Cisco IOS XR features before you enable MPLS TE for OSPF
on your router:
• MPLS
• IP Cisco Express Forwarding (CEF)
Note You must enter the commands in the following task on every OSPF router in the traffic-engineered
portion of your network.
Restrictions
MPLS traffic engineering currently supports only a single OSPF area.
SUMMARY STEPS
1. configure
2. router ospf process-name
3. router-id {ipv4-address | interface-type interface-instance}
4. mpls traffic-eng area area-id
5. mpls traffic-eng router-id {ip-address | interface-type interface-instance}
6. area area-id
7. interface type instance
8. end
or
commit
9. show ospf [process-name] [area-id] mpls traffic-eng {link | fragment}
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router ospf process-name Enables OSPF routing for the specified routing process, and
places the router in router configuration mode.
Example: Note The process-name argument is any alphanumeric
RP/0/RP0/CPU0:router(config)# router ospf 1 string no longer than 40 characters.
Step 3 router-id {ipv4-address | interface-type Configures a router ID for the OSPF process.
interface-instance}
Note We recommend using a stable IPv4 address as the
router ID.
Example:
RP/0/RP0/CPU0:router(config-ospf)# router-id
192.168.4.3
Step 4 mpls traffic-eng area area-id Configures the OSPF area for MPLS TE.
Example:
RP/0/RP0/CPU0:router(config-ospf)# mpls
traffic-eng area 0
Example:
RP/0/RP0/CPU0:router# show ospf 1 0 mpls
traffic-eng link
Examples
This section provides the following output examples:
• Sample Output for the show ospf Command Before Configuring MPLS TE, page RC-178
• Sample Output for the show ospf mpls traffic-eng Command, page RC-179
• Sample Output for the show ospf Command After Configuring MPLS TE, page RC-180
Sample Output for the show ospf Command Before Configuring MPLS TE
In the following example, the show route ospf EXEC command verifies that POS interface 0/3/0/0 exists
and MPLS TE is not configured:
RP/0/RP0/CPU0:router# show route ospf 1 0
In the following example, the show ospf mpls traffic-eng EXEC command verifies that the MPLS TE
links on area instance 3 are configured correctly:
RP/0/RP0/CPU0:router# show ospf mpls traffic-eng link
Sample Output for the show ospf Command After Configuring MPLS TE
In the following example, the show route ospf EXEC command verifies that the MPLS TE tunnels
replaced POS interface 0/3/0/0 and that configuration was performed correctly:
RP/0/RP0/CPU0:router# show route ospf 1 0
Note To execute OSPFv3 commands for this task, replace ospf with ospfv3 in Steps 1 through 7.
SUMMARY STEPS
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# show ospf group1
border-routers
Example:
RP/0/RP0/CPU0:router# show ospf 100 flood-list
interface pos 0/3/0/0
Step 5 show ospf [process-name] [area-id] neighbor (Optional) Displays OSPF neighbor information on an
[interface-type interface-instance] individual interface basis.
[neighbor-id] [detail]
Example:
RP/0/RP0/CPU0:router# show ospf 100 neighbor
Step 6 clear ospf [process-name] process (Optional) Resets an OSPF router process without stopping
and restarting it.
Example:
RP/0/RP0/CPU0:router# clear ospf 100 process
Step 7 clear ospf [process-name] statistics [neighbor (Optional) Clears the OSPF statistics of neighbor state
[interface-type interface-instance] transitions.
[ip-address]]
Example:
RP/0/RP0/CPU0:router# clear ospf 100 statistics
SUMMARY STEPS
1. configuration
2. router ospfv3
3. graceful-restart
DETAILED STEPS
Example:
RP/0/RP0/CPU0:single10-hfr#config
RP/0/RP0/CPU0:single10-hfr(config)
Step 2 router ospfv3 process-name Enters router configuration mode for OSPFv3. The process
name is a WORD that uniquely identifies an OSPF routing
process. The process name is any alphanumeric string no
Example:
RP/0/RP0/CPU0:single10-hfr(config)# router
longer than 40 characters without spaces.
ospfv3 test
Step 3 graceful-restart Enable graceful restart on the current router.
Example:
RP/0/RP0/CPU0:single10-hfr(config-ospfv3)#grace
ful-restart
SUMMARY STEPS
1. configuration
2. router ospfv3
3. graceful-restart lifetime
DETAILED STEPS
Example:
RP/0/RP0/CPU0:single10-hfr#config
RP/0/RP0/CPU0:single10-hfr(config)
Step 2 router ospfv3 <process-name> Enters router configuration mode for OSPFv3. The process
name is a WORD that uniquely identifies an OSPF routing
process. The process name is any alphanumeric string no
Example:
RP/0/RP0/CPU0:single10-hfr(config)# router
longer than 40 characters without spaces.
ospfv3 test
Step 3 graceful-restart lifetime Specifies a maximum duration for a graceful restart.
Example:
RP/0/RP0/CPU0:single10-hfr(config-ospfv3)#grace
ful-restart lifetime 120
SUMMARY STEPS
1. configuration
2. router ospfv3
3. graceful-restart interval
DETAILED STEPS
Example:
RP/0/RP0/CPU0:single10-hfr#config
RP/0/RP0/CPU0:single10-hfr(config)
Step 2 router ospfv3 <process-name> Enters router configuration mode for OSPFv3. The process
name is a WORD that uniquely identifies an OSPF routing
process. The process name is any alphanumeric string no
Example:
RP/0/RP0/CPU0:single10-hfr(config)# router
longer than 40 characters without spaces.
ospfv3 test
Step 3 graceful-restart interval <seconds> Specifies the interval (minimal time) between graceful
restarts on the current router.
Example:
RP/0/RP0/CPU0:single10-hfr(config-ospfv3)#grace
ful-restart interval 120
SUMMARY STEPS
1. configuration
2. router ospfv3
3. graceful-restart helper [disable]
DETAILED STEPS
Example:
RP/0/RP0/CPU0:single10-hfr#config
RP/0/RP0/CPU0:single10-hfr(config)
Step 2 router ospfv3 <process-name> Enters router configuration mode for OSPFv3. The process
name is a WORD that uniquely identifies an OSPF routing
process. The process name is any alphanumeric string no
Example:
RP/0/RP0/CPU0:single10-hfr(config)# router
longer than 40 characters without spaces.
ospfv3 test
Step 3 graceful-restart helper Disables the helper capability.
Example:
RP/0/RP0/CPU0:single10-hfr(config-ospfv3)#grace
ful-restart helper disable
RP/0/0/CPU0:LA#
Summary Steps
1. configure
2. router ospf instance-id
3. mpls traffic-eng multicast-intact
4. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router ospf instance-id Enables OSPF routing for the specified routing process, and
places the router in router configuration mode. In this
example, the OSPF instance is called isp.
Example:
RP/0/RP0/CPU0:router(config)# router ospf isp
Example:
RP/0/RP0/CPU0:router(config-isis)# mpls
traffic-eng multicast-intact
Step 4 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config-isis-af)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config-isis-af)# commit 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.
The following example shows how OSPF interface parameters are configured for an area in
Cisco IOS XR software.
In Cisco IOS XR software, OSPF interface-specific parameters are configured in interface configuration
mode and explicitly defined for area 0. In addition, the ip ospf keywords are no longer required.
The following example shows the hierarchical CLI structure of Cisco IOS XR software.
In Cisco IOS XR software, OSPF areas must be explicitly configured, and interfaces configured under
the area configuration mode are explicitly bound to that area. In this example, interface 10.1.2.0/24 is
bound to area 0 and interface 10.1.3.0/24 is bound to area 1.
router ospf 1
router-id 10.2.3.4
area 0
interface POS 0/3/0/0
!
area 1
interface POS 0/3/0/1
!
!
router ospfv3 1
router-id 10.0.0.217
redistribute bgp 42
redistribute bgp 1956
distribute-list prefix-list list1 out bgp 42
distribute-list prefix-list list2 out bgp 1956
area 1
interface POS 0/2/0/0
ABR 1 Configuration
router ospfv3 1
router-id 10.0.0.217
area 0
interface POS 0/2/0/1
area 1
virtual-link 10.0.0.212
interface POS 0/2/0/0
ABR 2 Configuration
router ospfv3 1
router-id 10.0.0.212
area 0
interface POS 0/3/0/1
area 1
virtual-link 10.0.0.217
interface POS 0/2/0/0
Virtual Link Configured with MD5 Authentication for OSPF Version 2: Example
The following examples show how to configure a virtual link to your backbone and apply MD5
authentication. You must perform the steps described on both ABRs at each end of the virtual link.
After you explicitly configure the ABRs, the configuration is inherited by all interfaces bound to that
area—unless you override the values and configure them explicitly for the interface.
To understand virtual links, see the “Virtual Link and Transit Area for OSPF” section on page RC-138.
In this example, all interfaces on router ABR1 use MD5 authentication:
router ospf ABR1
router-id 10.10.10.10
authentication message-digest
message-digest-key 100 md5 0 cisco
area 0
interface pos 0/2/0/1
interface pos 0/3/0/0
area 1
interface pos 0/3/0/1
virtual-link 10.10.5.5
!
!
In this example, only area 1 interfaces on router ABR3 use MD5 authentication:
router ospf ABR2
router-id 10.10.5.5
area 0
area 1
authentication message-digest
message-digest-key 100 md5 0 cisco
interface pos 0/9/0/1
virtual-link 10.10.10.10
area 3
interface Loopback 0
interface pos 0/9/0/0
!
!
Where to Go Next
To configure route maps through the RPL for OSPF Version 2, see the Implementing Routing Policy on
Cisco IOS XR Software document.
To build an MPLS TE topology, create tunnels, and configure forwarding over the tunnel for OSPF
Version 2; see the Cisco IOS XR MPLS Configuration Guide.
Additional References
The following sections provide references related to implementing OSPF on Cisco IOS XR software.
Related Documents
Related Topic Document Title
OSPF and OSPFv3 commands: complete command Cisco IOS XR Routing Command Reference, Release 32
syntax, command modes, command history, defaults,
usage guidelines, and examples
MPLS TE feature information Implementing MPLS Traffic Engineering on Cisco IOS XR Software
module in the Cisco IOS XR MPLS Configuration Guide, Release
3.2
Standards
Standards Title
No new or modified standards are supported by this —
feature, and support for existing standards has not been
modified by this feature.
MIBs
MIBs MIBs Link
• OSPF-MIB To locate and download MIBs for selected platforms using
Cisco IOS XR software, use the Cisco MIB Locator found at the
following URL:
http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
RFCs Title
RFC 1587 Not so Stubby Area (NSSA)
RFC 1793 OSPF over demand circuit
RFC 2328 OSPF Version 2
RFC 2740 OSPFv3
RFC 3623 Graceful OSPF Restart (OSPFv2)
Technical Assistance
Description Link
The Cisco Technical Support website contains http://www.cisco.com/techsupport
thousands of 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.
Routing Information Base (RIB) is a distributed collection of information about routing connectivity
among all nodes of a network.
Each router maintains a RIB containing the routing information for that router. RIB stores the best routes
from all routing protocols that are running on the system.
This module describes the tasks you need to perform to implement and monitor RIB on your
Cisco IOS XR network.
Note For more information about RIB on the Cisco IOS XR software and complete descriptions of RIB
commands listed in this module, see the “Related Documents” of this module. To locate documentation
for other commands that might appear during the execution of a configuration task, search online in the
Cisco IOS XR software master command index.
Feature History for Implementing and Monitoring RIB on Cisco IOS XR Software
Release Modification
Release 2.0 This feature was introduced on the Cisco CRS-1.
Release 3.0 No modification.
Release 3.2 Support was added for the Cisco XR 12000 Series Router.
Contents
• Prerequisites for Implementing RIB on Cisco IOS XR Software, page RC-196
• Information About RIB Configuration, page RC-196
• How to Deploy and Monitor RIB, page RC-198
• Configuration Examples for RIB Monitoring, page RC-200
• Where to Go Next, page RC-202
• Additional References, page RC-203
Overview of RIB
Each routing protocol selects its own set of best routes and installs those routes and their attributes in
RIB. RIB stores these routes and selects the best ones from among all routing protocols. Those routes
are downloaded to the line cards for use in forwarding packets. The acronym RIB is used both to refer
to RIB processes and the collection of route data contained within RIB.
Within a protocol, routes are selected based on the metrics in use by that protocol. A protocol downloads
its best routes (lowest or tied metric) to RIB. RIB selects the best overall route by comparing the
administrative distance of the associated protocol.
The administrative distance for some routing protocols (for instance IS-IS, OSPF, and BGP) can be
changed. See the protocol-specific documentation for the proper method to change the administrative
distance of that protocol.
Note Changing the administrative distance of a protocol on some but not all routers can lead to routing loops
and other undesirable behavior. Doing so is not recommended.
SUMMARY STEPS
DETAILED STEPS
SUMMARY STEPS
1. show route [protocol [instance]] [afi-all | ipv4 | ipv6] [unicast | multicast | safi-all] [ip-address
[mask]]
2. show route [afi-all | ipv4 | ipv6] [unicast | multicast | safi-all] backup [ip-address]
3. show route [afi-all | ipv4 | ipv6] [unicast | multicast | safi-all] best-local ip-address
4. show route [afi-all | ipv4 | ipv6] [unicast | multicast | safi-all] connected
5. show route [afi-all | ipv4 | ipv6] [unicast | multicast | safi-all] local [interface]
6. show route [afi-all | ipv4 | ipv6] [unicast | multicast | safi-all] ip-address mask longer-prefixes
7. show route [afi-all | ipv4 | ipv6] [unicast | multicast | safi-all] next-hop ip-address
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# show route list list1 bgp
aspo ipv4 unicast 192.168.111/8
Step 2 show route [afi-all | ipv4 | ipv6] [unicast | Displays backup routes in RIB.
multicast | safi-all] backup [ip-address]
Example:
RP/0/RP0/CPU0:router# show route ipv4 unicast
backup 192.168.111/8
Step 3 show route [afi-all | ipv4 | ipv6] [unicast | Displays the best-local address to use for return packets
multicast | safi-all] best-local ip-address from the given destination.
Example:
RP/0/RP0/CPU0:router# show route ipv4 unicast
best-local 192.168.111/8
Step 4 show route [afi-all | ipv4 | ipv6] [unicast | Displays the current connected routes of the routing table.
multicast | safi-all] connected
Example:
RP/0/RP0/CPU0:router# show route ipv4 unicast
connected
Step 5 show route [afi-all | ipv4 | ipv6] [unicast | Displays local routes for receive entries in the routing table.
multicast | safi-all] local [interface]
Example:
RP/0/RP0/CPU0:router# show route ipv4 unicast
local
Example:
RP/0/RP0/CPU0:router# show route ipv4 unicast
192.168.111/8 longer-prefixes
Step 7 show route [afi-all | ipv4 | ipv6] [unicast | Displays the next hop gateway or host to a destination
multicast | safi-all] next-hop ip-address address.
Example:
RP/0/RP0/CPU0:router# show route ipv4 unicast
next-hop 192.168.1.34
Where to Go Next
For additional information on the protocols that interact with RIB, you may want to see the following
publications:
• Implementing BGP on Cisco IOS XR Software
• Implementing IS-IS on Cisco IOS XR Software
• Implementing OSPF on Cisco IOS XR Software
• RIB Commands on Cisco IOS XR Software
Additional References
The following sections provide references related to implementing RIB on Cisco IOS XR software:
Related Documents
Related Topic Document Title
Routing Information Base commands: complete RIB Commands on Cisco IOS XR Software in the Cisco IOS XR
command syntax, command modes, command history, Routing Command Reference, Release 3.2
defaults, usage guidelines, and examples
BGP commands: complete command syntax, command BGP Commands on Cisco IOS XR Software, in the Cisco IOS XR
modes, command history, defaults, usage guidelines, Routing Command Reference, Release 3.2
and examples
IS-IS commands: complete command syntax, IS-IS Commands on Cisco IOS XR Software in the Cisco IOS XR
command modes, command history, defaults, usage Routing Command Reference, Release 3.2
guidelines, and examples
OSPF commands: complete command syntax, OSPF Commands on Cisco IOS XR Software in the Cisco IOS XR
command modes, command history, defaults, usage Routing Command Reference, Release 3.2
guidelines, and examples
OSPFv3 commands: complete command syntax, OSPFv3 Commands on Cisco IOS XR Software in the Cisco IOS XR
command modes, command history, defaults, usage Routing Command Reference, Release 3.2
guidelines, and examples
Multicast commands: complete command syntax, Cisco IOS XR Multicast Command Reference, Release 3.2
command modes, command history, defaults, usage
guidelines, and examples
Multicast configuration: complete command syntax, Cisco IOS XR Multicast Configuration Guide, Release 3.2
command modes, command history, defaults, usage
guidelines, and examples
Standards
Standards Title
No new or modified standards are supported by this —
feature, and support for existing standards has not been
modified by this feature.
MIBs
MIBs MIBs Link
• IP-FORWARD-MIB To locate and download MIBs for selected platforms using
Cisco IOS XR software, use the Cisco MIB Locator found at the
• RFC1213-MIB
following URL:
http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
RFCs Title
No new or modified RFCs are supported by this —
feature, and support for existing RFCs has not been
modified by this feature.
Technical Assistance
Description Link
The Cisco Technical Support website contains http://www.cisco.com/techsupport
thousands of 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.
A routing policy instructs the router to inspect routes, filter them, and potentially modify their attributes
as they are accepted from a peer, advertised to a peer, or redistributed from one routing protocol to
another. Routing protocols make decisions to advertise, aggregate, discard, distribute, export, hold,
import, redistribute and otherwise modify routes based on configured routing policy.
The routing policy language (RPL) has been designed to provide a single, straightforward language in
which all routing policy needs can be expressed. RPL was designed to support large-scale routing
configurations. It greatly reduces the redundancy inherent in previous routing policy configuration
methods. RPL has been designed to streamline routing policy configuration, to reduce system resources
required to store and process these configurations, and to simplify troubleshooting.
Note For more information about routing policy on the Cisco IOS XR software and complete descriptions of
the routing policy commands listed in this module, see the “Related Documents” section of this module.
To locate documentation for other commands that might appear during execution of a configuration task,
search online in the Cisco IOS XR software master command index.
Contents
• Prerequisites for Implementing Routing Policy, page RC-206
• Information About Implementing Routing Policy, page RC-206
• How to Implement Routing Policy, page RC-237
• Configuration Examples for Implementing Routing Policy, page RC-241
• Additional References, page RC-244
policy. For example, three policies that are identical in every way except for the local preference value
they set can be represented as one common parameterized policy that takes the varying local preference
value as a parameter to the policy.
The policy language introduces the notion of sets. Sets are containers of similar data that can be used in
route attribute matching and setting operations. Four set types exist: prefix-sets, community-sets,
as-path-sets, and extcommunity-sets. These sets hold groupings of IPv4 or IPv6 prefixes, community
values, AS path regular expressions, and extended community values, respectively. Sets are simply
containers of data. Most sets also have an inline variant. An inline set allows for small enumerations of
values to be used directly in a policy rather than having to refer to a named set. Prefix lists, community
lists, and AS path lists must be maintained even when only one or two items are in the list. An inline set
in RPL allows the user to place small sets of values directly in the policy body without having to refer
to a named set.
Decision making, such as accept and deny, is explicitly controlled by the policy definitions themselves.
RPL combines matching operators, which may use set data, with the traditional Boolean logic operators
and, or, and not into complex conditional expressions. All matching operations return a true or false
result. The execution of these conditional expressions and their associated actions can then be controlled
by using simple if then, elseif, and else structures, which allow the evaluation paths through the policy
to be fully specified by the user.
Names
The policy language provides two kinds of persistent, namable objects: sets and policies. Definition of
these objects is bracketed by beginning and ending command lines. For example, to define a policy
named test, the configuration syntax would look similar to the following:
route-policy test
[ . . . policy statements . . . ]
end-policy
Legal names for policy objects can be any sequence of the upper- and lowercase alphabetic characters;
the numerals 0 to 9; and the punctuation characters period, hyphen, and underscore. A name must begin
with a letter or numeral.
Sets
In this context, the term set is used in its mathematical sense to mean an unordered collection of unique
elements. The policy language provides sets as a container for groups of values for matching purposes.
Sets are used in conditional expressions. The elements of the set are separated by commas. Null (empty)
sets are not allowed.
Four kinds of sets exist: as-path-set, community-set, extcommunity-set, and prefix-set. You may want to
perform comparisons against a small number of elements, such as two or three community values, for
example. To allow for these comparisons, the user can enumerate these values directly. These
enumerations are referred to as inline sets. Functionally, inline sets are equivalent to named sets, but
allow for simple tests to be inline. Thus, comparisons do not require that a separate named set be
maintained when only one or two elements are being compared. See the set types described in the
following sections for the syntax. In general, the syntax for an inline set is a comma-separated list
route-policy sample
if community matches-any test-communities then
set local-preference 100
endif
end-policy
Both of these policies are functionally equivalent, but the inline form does not require the configuration
of the community set just to store the six values. You can choose the form appropriate to the
configuration context. In the following sections, examples of both the named set version and the inline
form are provided where appropriate.
as-path-set
An AS path set comprises operations for matching an AS path attribute. The only matching operation is
a regular expression match.
This AS path set comprises two elements. When used in a matching operation, this AS path set matches
any route whose AS path ends with either the autonomous system (AS) number 42 or 127.
To remove the named AS path set, use the no as-path-set aset1 command-line interface (CLI) command.
This set matches the same AS paths as the previously named set, but does not require the extra effort of
creating a named set separate from the policy that uses it.
community-set
A community-set holds community values for matching against the BGP community attribute. A
community is a 32-bit quantity. Integer community values must be split in half and expressed as two
unsigned decimal integers in the range from 0 to 65535, separated by a colon. Single 32-bit community
values are not allowed. The following is the named set form:
The inline form of a community-set also supports parameterization. Each 16-bit portion of the
community may be parameterized. See the “Parameterization” section on page RC-214 for more
information.
RPL provides symbolic names for the standard well-known community values: internet is 0:0, no-export
is 65535:65281, no-advertise is 65535:65282, and local-as is 65535:65283.
RPL also provides a facility for using wildcards in community specifications. A wildcard is specified by
inserting an asterisk (*) in place of one of the 16-bit portions of the community specification; the
wildcard indicates that any value for that portion of the community matches. Thus, the following policy
matches all communities in which the autonomous system part of the community is 123:
community-set cset3
123:*
end-set
Every community set must contain at least one community value. Empty community sets are invalid and
are rejected.
extcommunity-set
Named Form
extcommunity-set extcomm-set1
RT:1.2.3.4:666,
RT:1234:666,
SoO:1.2.3.4:777,
SoO :4567:777
end-set
Inline Form
(RT:1.2.3.4:666, RT:1234:6667, SoO:1.2.3.4:777, SoO:45678:777)
(RT:$ipaddr:666, RT:1234:$tag, SoO:1.2.3.4:777, SoO:$tag2:777)
As with community sets, the inline form supports parameterization within parameterized policies. Either
portion of the extended community value can be parameterized.
Every extended community-set must contain at least one extended community value. Empty extended
community-sets are invalid and rejected.
prefix-set
A prefix-set holds IPv4 or IPv6 prefix match specifications, each of which has four parts: an address, a
mask length, a minimum matching length, and a maximum matching length. The address is required, but
the other three parts are optional. The address is a standard dotted-decimal IPv4 or colon-separated
hexadecimal IPv6 address. The mask length, if present, is a nonnegative decimal integer in the range
from 0 to 32 (0 to 128 for IPv6) following the address and separated from it by a slash. The optional
minimum matching length follows the address and optional mask length and is expressed as the keyword
ge (mnemonic for greater than or equal to), followed by a nonnegative decimal integer in the range from
0 to 32 (0 to 128 for IPv6). The optional maximum matching length follows the rest and is expressed by
the keyword le (mnemonic for less than or equal to), followed by yet another nonnegative decimal integer
in the range from 0 to 32 (0 to 128 for IPv6). A syntactic shortcut for specifying an exact length for
prefixes to match is the eq keyword (mnemonic for equal to).
If a prefix match specification has no mask length, then the default mask length is 32 for IPv4 and 128
for IPv6. The default minimum matching length is the mask length. If a minimum matching length is
specified, then the default maximum matching length is 32 for IPv4 and 128 for IPv6. Otherwise, if
neither minimum nor maximum is specified, the default maximum is the mask length.
The prefix-set itself is a comma-separated list of prefix match specifications. The following are
examples:
prefix-set legal-ipv4-prefix-examples
10.0.1.1,
10.0.2.0/24,
10.0.3.0/24 ge 28,
10.0.4.0/24 le 28,
10.0.5.0/24 ge 26 le 30,
10.0.6.0/24 eq 28
end-set
prefix-set legal-ipv6-prefix-examples
2001:0:0:1::/64,
2001:0:0:2::/64 ge 96,
2001:0:0:2::/64 ge 96 le 100,
2001:0:0:2::/64 eq 100
end-set
The first element of the prefix-set matches only one possible value, 10.0.1.1/32 or the host address
10.0.1.1. The second element matches only one possible value, 10.0.2.0/24. The third element matches
a range of prefix values, from 10.0.3.0/28 to 10.0.3.255/32. The fourth element matches a range of
values, from 10.0.4.0/24 to 10.0.4.240/28. The fifth element matches prefixes in the range from
10.0.5.0/26 to 10.0.5.252/30. The sixth element matches any prefix of length 28 in the range from
10.0.6.0/28 through 10.0.6.240/28.
Neither the minimum length nor maximum length is valid without a mask length. The maximum length
must be at least the mask length. For IPv4, the minimum length must be less than 32, the maximum
length of an IPv4 prefix. For IPv6, the minimum length must be less than 128, the maximum length of
an IPv6 prefix. The maximum length must be equal to or greater than the minimum length.
route-policy quickstart-drop
drop
end-policy
route-policy ignore_path_as
if as-path in ignore_path then
drop
else
pass
endif
end-policy
router bgp 2
neighbor 10.0.1.2 address-family ipv4 unicast policy ignore_path_as in
route-policy quickstart-localpref
if community matches-any quickstart-communities then
set local-preference 31
endif
pass
end-policy
Persistent Remarks
The following example shows how comments are placed in the policy to clarify the meaning of the
entries in the set and the statements in the policy. The remarks are persistent, meaning they remain
attached to the policy. For example, remarks are displayed in the output of the show running-config
command. Adding remarks to the policy makes the policy easier to understand, modify at a later date,
and troubleshoot if an unexpected behavior occurs.
prefix-set rfc1918
# These are the networks defined as private in RFC1918 (including
# all subnets thereof)
10.0.0.0/8 ge 8,
172.16.0.0/12 ge 12,
192.168.0.0/16 ge 16
end-set
route-policy quickstart-remarks
# Handle routes to RFC1918 networks
if destination in rfc1918 then
# Set the community such that we do not export the route
set community (no-export) additive
endif
end-policy
Policy Definitions
Policy definitions create named sequences of policy statements. A policy definition consists of the CLI
route-policy keyword followed by a name, a sequence of policy statements, and the end-policy
keyword. For example, the following policy drops any route it encounters:
route-policy drop-everything
drop
end-policy
The name serves as a handle for binding the policy to protocols. To remove a policy definition, issue the
no route-policy name command.
Policies may also refer to other policies such that common blocks of policy can be reused. This reference
to other policies is accomplished by using the apply statement, as shown in the following example:
route-policy check-as-1234
if as-path passes-through ‘1234’ then
apply drop-everything
else
pass
endif
end-policy
The apply statement indicates that the policy drop-everything should be executed if the route under
consideration passed through autonomous system 1234 before it is received. If a route that has
autonomous system 1234 in its AS path is received, the route is dropped; otherwise, the route is accepted
without modification. This policy is an example of a hierarchical policy. Thus, the semantics of the apply
statement are just as if the applied policy were cut and pasted into the applying policy:
route-policy check-as-1234-prime
if as-path passes-through '1234' then
drop
else
pass
endif
end-policy
You may have as many levels of hierarchy as desired. However, many levels may be difficult to maintain
and understand.
Parameterization
In addition to supporting reuse of policies using the apply statement, policies can be defined that allow
for parameterization of some of the attributes. The following example shows how to define a
parameterized policy named param-example. In this case, the policy takes one parameter, $mytag.
Parameters always begin with a dollar sign and consist otherwise of any alphanumeric characters.
Parameters can be substituted into any attribute that takes a parameter.
In the following example, a 16-bit community tag is used as a parameter:
route-policy param-example ($mytag)
set community (1234:$mytag) additive
end-policy
This parameterized policy can then be reused with different parameterizations, as shown in the following
example. In this manner, policies that share a common structure but use different values in some of their
individual statements can be modularized. For details on which attributes can be parameterized, see the
individual attribute sections.
route-policy origin-10
if as-path originates-from ‘10’ then
apply param-example(10)
else
pass
endif
end-policy
route-policy origin-20
if as-path originates-from ‘20’ then
apply param-example(20)
else
pass
endif
end-policy
The parameterized policy param-example provides a policy definition that is expanded with the values
provided as the parameters in the apply statement. Note that the policy hierarchy is always maintained,
Thus, if the definition of param-example changes, then the behavior of origin_10 and origin_20 changes
to match.
The effect of the origin-10 policy is that it adds the community 1234:10 to all routes that pass through
this policy and have an AS path indicating the route originated from autonomous system 10. The
origin-20 policy is similar except that it adds to community 1234:20 for routes originating from
autonomous system 20.
if fully parenthesized to display the order of evaluation, would look like this:
(med eq 10 and (not destination in (10.1.3.0/24))) or community matches-any ([10..25]:35)
The inner not applies only to the destination test; the and combines the result of the not expression with
the Multi Exit Discriminator (MED) test; and the or combines that result with the community test. If the
order of operations are rearranged:
not med eq 10 and destination in (10.1.3.0/24) or community matches-any ([10..25]:35)
then the expression, fully parenthesized, would look like the following:
((not med eq 10) and destination in (10.1.3.0/24)) or community matches-any ([10..25]:35)
This example is trivial, but the feature is not. It is possible to write a policy that effectively changes the
value for an attribute. For example:
set med 8
if community matches-any cs1 then
set local-preference 122
if community matches-any cs2 then
set med 12
endif
endif
The result is a route with a MED of 8, unless the community list of the route matches both cs1 and cs2,
in which case the result is a route with a MED of 12.
In the case in which the attribute being modified can contain only one value, it is easy to think of this
case as the last statement wins. However, a few attributes can contain multiple values and the result of
multiple actions on the attribute is cumulative rather than as a replacement. The first of these cases is the
use of the additive keyword on community and extended community evaluation. Consider a policy of
the form:
route-policy community-add
set community (10:23)
set community (10:24) additive
set community (10:25) additive
end-policy
This policy sets the community string on the route to contain all three community values: 10:23, 10:24,
and 10:25.
The second of these cases is AS path prepending. Consider a policy of the form:
route-policy prepend-example
prepend as-path 2 3
prepend as-path 666 2
end-policy
This policy prepends the following to the AS path (666 666 2 2 2). This prepending is a result of all
actions being taken and to AS path being an attribute that contains an array of values rather than a simple
scalar value.
if med eq 12 then
set med 42
if med eq 42 then
drop
endif
endif
This policy never executes the drop statement because the second test (med eq 42) sees the original,
unmodified value of the MED in the route. Because the MED has to be 12 to get to the second test, the
second test always returns false.
route-policy one
apply two
end-policy
It may appear that policy one drops all routes because it neither contains an explicit pass statement nor
modifies a route attribute. However, the applied policy does set an attribute for some routes and this
disposition is passed along to policy one. The result is that policy one passes routes with destinations in
network 10, and drops all others.
Control Flow
Policy statements are processed sequentially in the order in which they appear in the configuration.
Policies that hierarchically reference other policy blocks are processed as if the referenced policy blocks
had been directly substituted inline. For example, if the following policies are defined:
route-policy one
set weight 100
end-policy
route-policy two
set med 200
end-policy
route-policy three
apply two
set community (2:666) additive
end-policy
route-policy four
apply one
apply three
pass
end-policy
Note The pass statement is not required and can be removed to represent the equivalent policy in another way.
Policy Verification
Several different types of verification occur when policies are being defined and used.
Range Checking
As policies are being defined, some simple verifications, such as range checking of values, is done. For
example, the MED that is being set is checked to verify that it is in a proper range for the MED attribute.
However, this range checking cannot cover parameter specifications because they may not have defined
values yet. These parameter specifications are verified when a policy is attached to an attach point. The
policy repository also verifies that there are no recursive definitions of policy, and that parameter
numbers are correct. At attach time, all policies must be well formed. All sets and policies that they
reference must be defined and have valid values. Likewise, any parameter values must also be in the
proper ranges.
As long as a given policy is not attached at an attach point, the policy is allowed to refer to nonexistent
sets and policies, which allows for freedom of workflow. You can build configurations that reference sets
or policy blocks that are not yet defined, and then can later fill in those undefined policies and sets,
thereby achieving much greater flexibility in policy definition. Every piece of policy you want to
reference while defining a policy need not exist in the configuration. Thus, a user can define a policy
sample that references the policy bar using an apply statement even if the policy bar does not exist.
Similarly, a user can enter a policy statement that refers to a nonexistent set.
However, the existence of all referenced policies and sets is enforced when a policy is attached. If you
attempt to attach the policy sample with the reference to an undefined policy bar at an inbound BGP
policy using the neighbor 1.2.3.4 address-family ipv4 unicast policy sample in command, the
configuration attempt is rejected because the policy bar does not exist.
Likewise, you cannot remove a route policy or set that is currently in use at an attach point because this
removal would result in an undefined reference. An attempt to remove a route policy or set that is
currently in use results in an error message to the user.
A condition exists that is referred to as a null policy in which the policy bar exists but has no statements,
actions, or dispositions in it. In other words, the policy bar does exist as follows:
route-policy bar
end-policy
This is a valid policy block. It effectively forces all routes to be dropped because it is a policy block that
never modifies a route, nor does it include the pass statement. Thus, the default action of drop for the
policy block is followed.
Policies that are in use do, on occasion, need to be modified. Traditionally, configuration changes are
done by completely removing the relevant configuration and then re-entering it. However, this allows for
a window of time in which no policy is attached and the default action takes place. RPL provides a
mechanism for an atomic change so that if a policy is redeclared, or edited using the emacs editor, the
new configuration is applied immediately, which allows for policies that are in use to be changed without
having a window of time in which no policy is applied at the given attach point.
The policy repository knows which attributes, actions, and comparisons are valid at each attach point.
When a policy is attached, these actions and comparisons are verified against the capabilities of that
particular attach point. Take, for example, the following policy definition:
route-policy bad
set med 100
set level level-1-2
set cost 200
end-policy
This policy attempts to perform actions to set the BGP attribute med, IS-IS attribute level, and OSPF
attribute cost. The system allows you to define such a policy, but it does not allow you to attach such a
policy. If you had defined the policy bad and then attempted to attach it as an inbound BGP policy using
the BGP configuration statement neighbor 1.2.3.4 address-family ipv4 unicast route-policy bad in the
system would reject this configuration attempt. This rejection results from the verification process
checking the policy and realizing that while BGP could set the MED, it has no way of setting the level
or cost as the level and cost are attributes of IS-IS and OSPF, respectively. Instead of silently omitting
the actions that cannot be done, the system generates an error to the user. Likewise, a valid policy in use
at an attach point cannot be modified in such a way as to introduce an attempt to modify a nonexistent
attribute or to compare against a nonexistent attribute. The verifiers test for nonexistent attributes and
reject such a configuration attempt.
Policy Statements
Four types of policy statements exist: remark, disposition (drop and pass), action (set), and if
(comparator).
Remark
A remark is text attached to policy configuration but otherwise ignored by the policy language parser.
Remarks are useful for documenting parts of a policy. The syntax for a remark is text that has each line
prepended with a pound sign (#):
# This is a simple one-line remark.
# This
# is a remark
# comprising multiple
# lines.
In general, remarks are used between complete statements or elements of a set. Remarks are not
supported in the middle of statements or within an inline set definition.
Unlike traditional !-comments in the CLI, RPL remarks persist through reboots and when configurations
are saved to disk or a TFTP server and then loaded back onto the router.
Disposition
By default, a route is dropped at the end of policy processing unless either the policy modifies a route
attribute or it passes the route by means of an explicit pass statement. For example, the following policy
drops all routes because it neither modifies the attribute of any route nor explicitly passes it.
route-policy EMPTY
end-policy
Whereas the following policies pass all routes that they evaluate.
route-policy PASS-ALL
pass
end-policy
route-policy SET-LPREF
set local-preference 200
end-policy
In addition to being implicitly dropped, a route may be dropped by an explicit drop statement. Drop
statements cause a route to be dropped immediately so that no further policy processing is done. Note
also that a drop statement overrides any previously processed pass statements or attribute modifications.
For example, the following policy drops all routes. The first pass statement is executed, but is then
immediately overridden by the drop statement. The second pass statement never gets executed.
route-policy DROP-EXAMPLE
pass
drop
pass
end-policy
When one policy applies another, it is as if the applied policy were copied into the right place in the
applying policy, and then the same drop-and-pass semantics are put into effect. For example, policies
ONE and TWO are equivalent to policy ONE-PRIME:
route-policy ONE
apply route-policy two
if as-path neighbor-is '123' then
pass
endif
end-policy
route-policy TWO
if destination in (10.0.0.0/16 le 32) then
drop
endif
end-policy
route-policy ONE-PRIME
if destination in (10.0.0.0/16 le 32) then
drop
endif
if as-path neighbor-is '123' then
pass
endif
end-policy
Because the effect of an explicit drop statement is immediate, routes in 10.0.0.0/16 le 32 are dropped
without any further policy processing. Other routes are then considered to see if they were advertised by
autonomous system 123. If they were advertised, they are passed; otherwise, they are implicitly dropped
at the end of all policy processing.
Action
An action is a sequence of primitive operations that modify a route. Most actions, but not all, are
distinguished by the set keyword. In a route policy, actions can be grouped together. For example, the
following is a route policy comprising three actions:
route-policy actions
set med 217
set community (12:34) additive
delete community in (12:56)
end-policy
If
In its simplest form, an if statement uses a conditional expression to decide which actions or dispositions
should be taken for the given route. For example:
if as-path in as-path-set-1 then
drop
endif
The example indicates that any routes whose AS path is in the set as-path-set-1 are dropped. The contents
of the then clause may be an arbitrary sequence of policy statements.
The following example contains two action statements:
if origin is igp then
set med 42
prepend as-path 73 5
endif
The CLI provides support for the exit command as an alternative to the endif command.
The if statement also permits an else clause, which is executed if the if condition is false:
if med eq 8 then
set community (12:34) additive
else
set community (12:56) additive
endif
The policy language also provides syntax, using the elseif keyword, to string together a sequence of tests:
if med eq 150 then
set local-preference 10
elseif med eq 200 then
set local-preference 60
elseif med eq 250 then
set local-preference 110
else
set local-preference 0
endif
The statements within an if statement may themselves be if statements, as shown in the following
example:
if community matches-any (12:34,56:78) then
if med eq 150 then
drop
endif
set local-preference 100
endif
This policy example sets the value of the local preference attribute to 100 on any route that has a
community value of 12:34 or 56:78 associated with it. However, if any of these routes has a MED value
of 150, then these routes with either the community value of 12:34 or 56:78 and a MED of 150 are
dropped.
Boolean Conditions
In the previous section describing the if statement, all of the examples use simple Boolean conditions
that evaluate to either true or false. RPL also provides a way to build compound conditions from simple
conditions by means of Boolean operators.
Three Boolean operators exist: negation (not), conjunction (and), and disjunction (or). In the policy
language, negation has the highest precedence, followed by conjunction, and then by disjunction.
Parentheses may be used to group compound conditions to override precedence or to improve
readability.
The following simple condition:
med eq 42
is true only if the value of the MED in the route is 42, otherwise it is false.
A simple condition may also be negated using the not operator:
not next-hop in (10.0.2.2)
A compound condition takes either of two forms. It can be a simple expression followed by the and
operator, itself followed by a simple condition:
med eq 42 and next-hop in (10.0.2.2)
A compound condition may also be a simpler expression followed by the or operator and then another
simple condition:
origin is igp or origin is incomplete
The parentheses may serve to make the grouping of subconditions more readable, or they may force the
evaluation of a subcondition as a unit.
In the following example, the highest-precedence not operator applies only to the destination test, the
and operator combines the result of the not expression with the community test, and the or operator
combines that result with the MED test.
med eq 10 or not destination in (10.1.3.0/24) and community matches-any
([12..34]:[56..78])
With a set of parentheses to express the precedence, the result is the following:
med eq 10 or ((not destination in (10.1.3.0/24)) and community matches-any
([12..34]:[56..78])
The left conjunction is a compound condition enclosed in parentheses. The first simple condition of the
inner compound condition tests the value of the origin attribute; if it is Interior Gateway Protocol (IGP),
then the inner compound condition is true. Otherwise, the evaluation moves on to test the value of the
origin attribute again, and if it is incomplete, then the inner compound condition is true. Otherwise, the
evaluation moves to check the next component condition, which is a negation of a simple condition.
apply
As discussed in the sections on policy definitions and parameterization of policies, the apply command
executes another policy (either parameterized or unparameterized) from within another policy, which
allows for the reuse of common blocks of policy. When combined with the ability to parameterize
common blocks of policy, the apply command becomes a powerful tool for reducing repetitive
configuration.
Attach Points
Policies do not become useful until they are applied to routes, and for policies to be applied to routes
they need to be made known to routing protocols. In BGP, for example, there are several situations where
policies can be used, the most common of these is defining import and export policy. The policy attach
point is the point in which an association is formed between a specific protocol entity, in this case a BGP
neighbor, and a specific named policy. It is important to note that a verification step happens at this point.
Each time a policy is attached, the given policy and any policies it may apply are checked to ensure that
the policy can be validly used at that attach point. For example, if a user defines a policy that sets the
IS-IS level attribute and then attempts to attach this policy as an inbound BGP policy, the attempt would
be rejected because BGP routes do not carry IS-IS attributes. Likewise, when policies are modified that
are in use, the attempt to modify the policy is verified against all current uses of the policy to ensure that
the modification is compatible with the current uses.
Each protocol has a distinct definition of the set of attributes (commands) that compose a route. For
example, BGP routes may have a community attribute, which is undefined in OSPF. Routes in IS-IS have
a level attribute, which is unknown to BGP. Routes carried internally in the RIB may have a tag attribute.
When a policy is attached to a protocol, the protocol checks the policy to ensure the policy operates using
route attributes known to the protocol. If the protocol uses unknown attributes, then the protocol rejects
the attachment. For example, OSPF rejects attachment of a policy that tests the values of BGP
communities.
The situation is made more complex by the fact that each protocol has access to at least two distinct route
types. In addition to native protocol routes, for example BGP or IS-IS, some protocol policy attach points
operate on RIB routes, which is the common central representation. Using BGP as an example, the
protocol provides an attach point to apply policy to routes redistributed from the RIB to BGP. An attach
point dealing with two different kinds of routes permits a mix of operations: RIB attribute operations for
matching and BGP attribute operations for setting.
Note The protocol configuration rejects attempts to attach policies that perform unsupported operations.
The following sections describe the protocol attach points, including information on the attributes
(commands) and operations that are valid for each attach point.
• BGP Policy Attach Points, page RC-224
• OSPF Policy Attach Points, page RC-231
• OSPFv3 Policy Attach Points, page RC-232
• IS-IS Policy Attach Points, page RC-234
See the Cisco IOS XR Routing Command Reference for more information on the attributes and
operations.
Aggregation
The aggregation attach point generates an aggregate route to be advertised based on the conditional
presence of subcomponents of that aggregate. Policies attached at this attach point are also able to set
any of the valid BGP attributes on the aggregated routes. For example, the policy could set a community
value or a MED on the aggregate that is generated. The specified aggregate is generated if any routes
evaluated by the named policy pass the policy. More specifics of the aggregate are filtered using the
suppress-route keyword. Any actions taken to set attributes in the route affect attributes on the
aggregate.
In the policy language, the configuration is controlled by which routes pass the policy. The suppress map
was used to selectively filter or suppress specific components of the aggregate when the summary-only
flag is not set. In other words, when the aggregate and more specific components are being sent, some
of the more specific components can be filtered using a suppress map. In the policy language, this is
controlled by selecting the route and setting the suppress flag. The attribute-map allowed the user to set
specific attributes on the aggregated route. In the policy language, setting attributes on the aggregated
route is controlled by normal action operations.
In the following example, the aggregate address 10.0.0.0/8 is generated if there are any component routes
in the range 10.0.0.0/8 ge 8 le 25 except for 10.2.0.0/24. Because summary-only is not set, all
components of the aggregate are advertised. However, the specific component 10.1.0.0 are suppressed.
route-policy sample
if destination in (10.0.0.0/8 ge 8 le 25) then
set community (10:33)
endif
if destination in (10.2.0.0/24) then
drop
endif
if destination in (10.1.0.0/24) then
suppress-route
endif
end-policy
router bgp 2
address-family ipv4
aggregate-address 10.0.0.0/8 policy sample
.
.
.
Dampening
The dampening attach point controls the default route-dampening behavior within BGP. Unless
overridden by a more specific policy on the associate peer, all routes in BGP apply the associated policy
to set their dampening attributes.
The following policy sets dampening values for BGP IPv4 unicast routes. Those routes that are more
specific than a /25 take longer to recover after they have been dampened than routes that are less specific
than /25.
route-policy sample_damp
if destination in (0.0.0.0/0 ge 25) then
set dampening halflife 30 others default
else
set dampening halflife 20 others default
endif
end-policy
router bgp 2
address-family ipv4 unicast
bgp dampening policy sample_damp
.
.
.
Default Originate
The default originate attach point allows the default route (0.0.0.0/0) to be conditionally generated and
advertised to a peer, based on the presence of other routes. It accomplishes this configuration by
evaluating the associated policy against routes in the Routing Information Base (RIB). If any routes pass
the policy, the default route is generated and sent to the relevant peer.
The following policy generates and sends a default-route to the BGP neighbor 10.0.0.1 if any routes that
match 10.0.0.0/8 ge 8 le 32 are present in the RIB.
route-policy sample-originate
if rib-has-route in (10.0.0.0/8 ge 8 le 32) then
pass
endif
end-policy
router bgp 2
neighbor 10.0.0.1
remote-as 3
address-family ipv4 unicast
default-originate policy sample-originate
.
.
.
Note The current implementation of default origination policy permits matching only on destination address.
Neighbor Export
The neighbor export attach point selects the BGP routes to send to a given peer or group of peers. The
routes are selected by running the set of possible BGP routes through the associated policy. Any routes
that pass the policy are then sent as updates to the peer or group of peers. The routes that are sent may
have had their BGP attributes altered by the policy that has been applied.
The following policy sends all BGP routes to neighbor 10.0.0.5. Routes that are tagged with any
community in the range 2:100 to 2:200 are sent with a MED of 100 and a community of 2:666. The rest
of the routes are sent with a MED of 200 and a community of 2:200.
route-policy sample-export
if community matches-any (2:[100-200]) then
set med 100
set community (2:666)
else
set med 200
set community (2:200)
endif
end-policy
router bgp 2
neighbor 10.0.0.5
remote-as 3
address-family ipv4 unicast
route-policy sample-export out
.
.
.
Neighbor Import
The neighbor import attach point controls the reception of routes from a specific peer. All routes that are
received by a peer are run through the attached policy. Any routes that pass the attached policy are passed
to the BGP Routing Information Base (BRIB) as possible candidates for selection as best path routes.
When a BGP import policy is modified, it is necessary to rerun all the routes that have been received
from that peer against the new policy. The modified policy may now discard routes that were previously
allowed through, allow through previously discarded routes, or change the way the routes are modified.
A new configuration option in BGP (bgp auto-policy-soft-reset) that allows this modification to happen
automatically in cases for which either soft reconfiguration is configured or the BGP route-refresh
capability has been negotiated.
The following example shows how to receive routes from neighbor 10.0.0.1. Any routes received with
the community 3:100 have their local preference set to 100 and their community tag set to 2:666. All
other routes received from this peer have their local preference set to 200 and their community tag set to
2:200.
route-policy sample_import
if community matches-any (3:100) then
set local-preference 100
set community (2:666)
else
set local-preference 200
set community (2:200)
endif
end-policy
router bgp 2
neighbor 10.0.0.1
remote-as 3
address-family ipv4 unicast
route-policy sample_import in
.
.
.
Network
The network attach point controls the injection of routes from the RIB into BGP. A route policy attached
at this point is able to set any of the valid BGP attributes on the routes that are being injected.
The following example shows a route policy attached at the network attach point that sets the well-known
community no-export for any routes more specific than /24:
route-policy NetworkControl
if destination in (0.0.0.0/0 ge 25) then
set community (no-export) additive
endif
end-policy
router bgp 2
address-family ipv4 unicast
network 172.16.0.5/27 route-policy NetworkControl
Redistribute
The redistribute attach point allows routes from other sources to be advertised by BGP. The policy
attached at this point is able to set any of the valid BGP attributes on the routes that are being
redistributed. Likewise, selection operators allow a user to control what route sources are being
redistributed and which routes from those sources.
The following example shows how to redistribute all routes from OSPF instance 12 into BGP. If OSPF
were carrying a default route, it is dropped. Routes carrying a tag of 10 have their local preference set
to 300 and the community value of 2:666 and no-advertise attached. All other routes have their local
preference set to 200 and a community value of 2:100 set.
route-policy sample_redistribute
if destination in (0.0.0.0/0) then
drop
endif
if tag eq 10 then
set local-preference 300
set community (2:666, no-advertise)
else
set local-preference 200
set community (2:100)
endif
end-policy
router bgp 2
address-family ipv4 unicast
redistribute ospf 12 route-policy sample_redistribute
.
.
Show bgp
The show bgp attach point allows the user to display selected BGP routes that pass the given policy. Any
routes that are not dropped by the attached policy are displayed in a manner similar to the output of the
show ip bgp command.
In the following example, the show bgp route-policy command is used to display any BGP routes
carrying a MED of 5:
route-policy sample-display
if med eq 5 then
pass
endif
end-policy
!
show bgp route-policy sample-display
A show bgp policy route-policy command also exists, which runs all routes in the RIB past the named
policy as if the RIB were an outbound BGP policy. This command then displays what each route looked
like before it was modified and after it was modified, as shown in the following example:
RP/0/RP0/CPU0:router# show rpl route-policy test2
route-policy test2
if (destination in (10.0.0.0/8 ge 8 le 32)) then
set med 333
endif
end-policy
!
RP/0/RP0/CPU0:router# show bgp
Path info:
neighbor:10.0.1.2 neighbor router id:10.0.1.2
valid external best
Attributes after inbound policy was applied:
next hop:10.0.1.2
MET ORG AS
origin:incomplete neighbor as:3 metric:10
aspath:3
Attributes after outbound policy was applied:
next hop:10.0.1.2
MET ORG AS
origin:incomplete neighbor as:3 metric:333
aspath:2 3
...
Table Policy
The table policy attach point allows the user to configure traffic-index values on routes as they are
installed into the global routing table. This attach point supports the BGP policy accounting feature.
BGP policy accounting uses the traffic indexes that are set on the BGP routes to track various counters.
This way, router operators can select different sets of BGP route attributes using the matching operations
and then set different traffic indexes for each different class of route they are interested in tracking.
The following example shows how to set the traffic index to 10 in IPv4 unicast routes that originated
from autonomous system 10. Likewise, any IPv4 unicast routes that originated from autonomous system
11 have their traffic index set to 11 when they are installed into the FIB. These traffic indexes are then
used to count traffic being forwarded on these routes in line cards by enabling the BGP policy accounting
counters on the interfaces of interest.
route-policy sample-table
if as-path originates-from ‘10’ then
set traffic-index 10
elseif as-path originates-from ‘11’ then
set traffic-index 11
endif
end-policy
router bgp 2
address-family ipv4 unicast
table-policy sample-table
.
.
.
Some BGP route attributes are inaccessible from some BGP attach points for various reasons. For
example, the set med igp-cost only command makes sense when there is a configured igp-cost to
provide a source value. Table 4 summarizes which operations are valid and where they are valid.
Default Originate
The default originate attach point allows the user to conditionally inject the default route 0.0.0.0/0 into
the OSPF link-state database, which is done by evaluating the attached policy. If any routes in the local
RIB pass the policy, then the default route is inserted into the link-state database.
The following example shows how to generate a default route if any of the routes that match 10.0.0.0/8
ge 8 le 25 are present in the RIB:
route-policy ospf-originate
if rib-has-route in (10.0.0.0/8 ge 8 le 25) then
pass
endif
end-policy
router ospf 1
default-information originate policy ospf-originate
.
.
.
Redistribute
The redistribute attach point within OSPF injects routes from other routing protocol sources into the
OSPF link-state database, which is done by selecting the route types it wants to import from each
protocol. It then sets the OSPF parameters of cost and metric type. The policy can control how the routes
are injected into OSPF by using the set level command.
The following example shows how to redistribute routes from IS-IS instance instance_10 into OSPF
instance 1 using the policy OSPF-redist. The policy sets the metric type to type-2 for all redistributed
routes. IS-IS routes with a tag of 10 have their cost set to 100, and IS-IS routes with a tag of 20 have
their OSPF cost set to 200. Any IS-IS routes not carrying a tag of either 10 or 20 are not be redistributed
into the OSPF link-state database.
route-policy OSPF-redist
set metric-type type-2
if tag eq 10 then
set cost 100
elseif tag eq 20 then
set cost 200
else
drop
endif
end-policy
router ospf 1
redistribute isis instance_10 policy OSPF-redist
.
.
.
Default Originate
The default originate attach point allows the user to conditionally inject the default route 0::/0 into the
OSPFv3 link-state database, which is done by evaluating the attached policy. If any routes in the local
RIB pass the policy, then the default route is inserted into the link-state database.
The following example shows how to generate a default route if any of the routes that match 2001::/96
are present in the RIB:
route-policy ospfv3-originate
if rib-has-route in (2001::/96) then
pass
endif
end-policy
router ospfv3 1
default-information originate policy ospfv3-originate
.
.
.
Redistribute
The redistribute attach point within OSPFv3 injects routes from other routing protocol sources into the
OSPFv3 link-state database, which is done by selecting the route types it wants to import from each
protocol. It then sets the OSPFv3 parameters of cost and metric type. The policy can control how the
routes are injected into OSPFv3 by using the metric type command.
The following example shows how to redistribute routes from BGP instance instance_15 into OSPF
instance 1 using the policy OSPFv3-redist. The policy sets the metric type to type-2 for all redistributed
routes. BGP routes with a tag of 10 have their cost set to 100, and BGP routes with a tag of 20 have their
OSPFv3 cost set to 200. Any BGP routes not carrying a tag of either 10 or 20 are not be redistributed
into the OSPFv3 link-state database.
route-policy OSPFv3-redist
set metric-type type-2
if tag eq 10 then
set cost 100
elseif tag eq 20 then
set cost 200
else
drop
endif
end-policy
router ospfv3 1
redistribute bgp instance_15 policy OSPFv3-redist
.
.
.
Redistribute
The redistribute attach point within IS-IS allows routes from other protocols to be readvertised by IS-IS.
The policy is a set of control structures for selecting the types of routes that a user wants to redistribute
into IS-IS. The policy can also control which IS-IS level the routes are injected into and at what metric
values.
The following example shows how to redistribute routes from IS-IS instance 1 into IS-IS instance
instance_10 using the policy ISIS-redist. This policy sets the level to level-1-2 for all redistributed
routes. OSPF routes with a tag of 10 have their metric set to 100, and IS-IS routes with a tag of 20 have
their IS-IS metric set to 200. Any IS-IS routes not carrying a tag of either 10 or 20 are not be redistributed
into the IS-IS database.
route-policy ISIS-redist
set level level-1-2
if tag eq 10 then
set metric 100
elseif tag eq 20 then
set metric 200
else
drop
endif
end-policy
Note A route policy or set that is in use at an attach point cannot be removed because this removal would result
in an undefined reference. An attempt to remove a route policy or set that is in use at an attach point
results in an error message to the user.
To edit the contents of a routing policy, use the following CLI command in EXEC mode:
edit {route-policy | prefix-set | as-path-set | community-set | extended-community-set}
name
A copy of the route policy is copied to a temporary file and the editor is launched. After editing, save
the changes by using the save-buffer command, C-X C-S (Control-X Control-S). To exit the editor, use
the quit command, Control-X Control-C. When you quit the editor, the buffer is committed. If there are
no parse errors, the configuration is committed:
RP/0/RP0/CPU0:router#
If there are parse errors, you are asked whether editing should continue:
RP/0/RP0/CPU0:router#edit route-policy policy_B
== MicroEMACS 3.8b () == rpl_edit.141738
route-policy policy_B
set metric-type type_1
if destination in (2001::/8) then
drop
endif
end-policy
!
== MicroEMACS 3.8b () == rpl_edit.141738 ==
Parsing.
105 bytes parsed in 1 sec (103)bytes/sec
If you answer yes, the editor continues on the text buffer from where you left off. If you answer no, the
running configuration is not changed and the editing session is ended.
The CLI allows you to enter and delete route policy statements. You can complete a policy configuration
block by entering applicable commands such as end-policy or end-set. Alternatively, the CLI interpreter
allows you to use the exit command to complete a policy configuration block. The abort command is
used to discard the current policy configuration and return to global configuration mode.
Note If you want to modify an existing routing policy using the command-line interface (CLI), you must
redefine the policy by completing this task.
SUMMARY STEPS
1. configure
2. route-policy name
3. end-policy
4. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 route-policy name Enters route-policy configuration mode.
• After the route-policy has been entered, a group of
Example: commands can be entered to define the route-policy.
RP/0/RP0/CPU0:router(config)# route-policy
sample1
Prerequisites
A routing policy must be preconfigured and well defined prior to it being applied at an attach point. If a
policy is not predefined, an error message is generated stating that the policy is not defined.
SUMMARY STEPS
1. configure
2. router bgp as-number
3. neighbor ip-address
4. address-family {ipv4 | ipv6} {multicast | unicast}
5. route-policy route-policy-name {in | out}
6. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 router bgp as-number Configures a BGP routing process and enters router
configuration mode.
Example: • The as-number argument identifies the
RP/0/RP0/CPU0:router(config)# router bgp 125 autonomous system in which the router resides.
Valid values are from 0 to 65535. Private
autonomous system numbers that can be used in
internal networks range from 64512 to 65535.
Step 3 neighbor ip-address Specifies a neighbor IP address.
Example:
RP/0/RP0/CPU0:router(config-bgp)# neighbor
10.0.0.20
Step 4 address-family {ipv4 | ipv6} {multicast | unicast} Specifies the address family, the version of IP that is
in use, and either multicast or unicast.
Example: • Enters address family configuration mode.
RP/0/RP0/CPU0:router(config-bgp-nbr)#
address-family ipv4 unicast
SUMMARY STEPS
DETAILED STEPS
configure
route-policy sample1
if destination in test then
drop
else
set med 200
set community (2:100) additive
endif
end-policy
end
show config running route-policy sample1
Building configuration...
route-policy sample1
if destination in test then
drop
else
set med 200
set community (2:100) additive
endif
end-policy
prefix-set rfc1918
10.0.0.0/8 le 32,
172.16.0.0/12 le 32,
192.168.0.0/16 le 32
end-set
route-policy inbound-tx
if destination in too-specific or destination in rfc1918 then
drop
endif
set med 1000
set local-preference 90
set community (2:1001) additive
if community matches-any ([101..106]:202) then
prepend as-path 2 2
set community (2:666) additive
if med is 666 or med is 225 then
set origin incomplete
else
set origin igp
endif
else
set community (2:999) additive
endif
end-policy
router bgp 2
neighbor 10.0.1.2 address-family ipv4 unicast route-policy inbound-tx in
pass
endif
end-policy
!
route-policy common-inbound
apply filter-bogons
set origin igp
set community (2:333)
end-policy
!
route-policy set-lpref-prepend($lpref,$as,$prependcnt)
set local-preference $lpref
prepend as-path $as $prependcnt
end-policy
Translating Cisco IOS Route Maps to Cisco IOS XR Routing Policy Language:
Example
RPL performs the same functions as route-maps. See the Converting Cisco IOS Configurations to
Cisco IOS XR Configurations guide.
Additional References
The following sections provide references related to implementing RPL.
Related Documents
Related Topic Document Title
Routing policy language commands: complete Routing Policy Language Commands on Cisco IOS XR Software,
command syntax, command modes, command history, Release 3.2
defaults, usage guidelines, and examples
Regular expression syntax “Understanding Regular Expressions, Special Characters and
Patterns” appendix in the Cisco IOS XR Getting Started Guide
Standards
Standards Title
Draft-ietf-idr-bgp4-26.txt A Border Gateway Protocol 4, by Y. Rekhter, T.Li, S. Hares
MIBs
MIBs MIBs Link
There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using
Cisco IOS XR software, use the Cisco MIB Locator found at the
following URL:
http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
RFCs Title
No new or modified RFCs are supported by this —
feature, and support for existing RFCs has not been
modified by this feature.
Technical Assistance
Description Link
The Cisco Technical Support website contains http://www.cisco.com/techsupport
thousands of 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.
Static routes are user-defined routes that cause packets moving between a source and a destination to
take a specified path. Static routes can be important if the Cisco IOS XR software cannot build a route
to a particular destination. They are useful for specifying a gateway of last resort to which all unroutable
packets are sent.
This module describes the tasks you need to implement static routes on your Cisco IOS XR network.
Note For more information about static routes on the Cisco IOS XR software and complete descriptions of the
static routes commands listed in this module, see the “Related Documents” section of this module. To
locate documentation for other commands that might appear while executing a configuration task, search
online in the Cisco IOS XR software master command index.
Contents
• Prerequisites for Implementing Static Routes on Cisco IOS XR Software, page RC-248
• Information About Implementing Static Routes on Cisco IOS XR Software, page RC-248
• How to Implement Static Routes on Cisco IOS XR Software, page RC-250
• Configuration Examples, page RC-255
• Where to Go Next, page RC-255
• Additional References, page RC-256
routes. For example, you could have routes installed by the Open Shortest Path First (OSPF) protocol
with an administrative distance of 120. To have a static route that would be overridden by an OSPF
dynamic route, specify an administrative distance greater than 120.
Directly attached static routes are candidates for insertion in the routing table only if they refer to a valid
interface; that is, an interface that is both up and has IPv4 or IPv6 enabled on it.
A recursive static route is valid (that is, it is a candidate for insertion in the routing table) only when the
specified next hop resolves, either directly or indirectly, to a valid output interface, provided the route
does not self-recurse, and the recursion depth does not exceed the maximum IPv6 forwarding recursion
depth.
A route self-recurses if it is itself used to resolve its own next hop. If a static route becomes
self-recursive, RIB sends a notification to static routes to withdraw the recursive route.
The following example shows how to define a recursive IPv6 static route:
RP/0/RP0/CPU0:router(config)# route ipv6 unicast 2001:0DB8::/32 2001:0DB8:3000::1
This static route is not inserted into the IPv6 routing table because it is self-recursive. The next hop of
the static route, 2001:0DB8:3000:1, resolves through the BGP route 2001:0DB8:3000:0/16, which is
itself a recursive route (that is, it only specifies a next hop). The next hop of the BGP route,
2001:0DB8::0104, resolves through the static route. Therefore, the static route would be used to resolve
its own next hop.
It is not normally useful to manually configure a self-recursive static route, although it is not prohibited.
However, a recursive static route that has been inserted in the routing table may become self-recursive
as a result of some transient change in the network learned through a dynamic routing protocol. If this
occurs, the fact that the static route has become self-recursive will be detected and it will be removed
from the routing table, although not from the configuration. A subsequent network change may cause
the static route to no longer be self-recursive, in which case it will be re-inserted in the routing table.
A fully specified route is valid (that is, a candidate for insertion into the routing table) when the specified
interface is IPv4 or IPv6 enabled and up.
Any of the three types of static routes can be used as a floating static route. A floating static route must
be configured with an administrative distance that is greater than the administrative distance of the
dynamic routing protocol because routes with smaller administrative distances are preferred.
Note By default, static routes have smaller administrative distances than dynamic routes, so static routes
preferred to dynamic routes.
SUMMARY STEPS
1. configure
2. route {ipv4 | ipv6} {unicast | multicast} prefix mask {ip-address | interface-type
interface-instance} [distance] [tag tag] [permanent]
3. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 route {ipv4 | ipv6} {unicast | multicast} Configures an administrative distance of 110.
prefix mask {ip-address | interface-type
interface-instance} [distance] [tag tag] • This example shows how to route packets for network
[permanent] 10.0.0.0 through to a router at 172.20.16.6 if dynamic
information with administrative distance less than 110
is not available.
Example:
RP/0/RP0/CPU0:router(config)# route ipv4
unicast 10.0.0.0/8 172.20.16.6 110
Step 3 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config)# commit 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.
SUMMARY STEPS
1. configure
2. route {ipv4 | ipv6} {unicast | multicast} prefix mask {ip-address | interface-type
interface-instance} [distance] [tag tag] [permanent]
3. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 route {ipv4 | ipv6} {unicast | multicast} In this example, a floating static IPv6 route is being
prefix mask {ip-address | interface-type configured. An administrative distance of 201 is configured
interface-instance} [distance] [tag tag]
[permanent] Default administrative distances are as follows:
• Connected interface—0
Example: • Static route—1
RP/0/RP0/CPU0:router(config)# route ipv6
unicast 2001:0DB8::/32 2001:0DB8:3000::1 201
Step 3 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config)# commit 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.
Restrictions
The number of static routes that can be configured on a router for a given address family is limited by
default to 4000. The limit can be raised or lowered using the route maximum command. Note that if
you use the route maximum command to reduce the configured maximum allowed number of static
routes for a given address family below the number of static routes currently configured, the change is
rejected. In addition, understand the following behavior: If you commit a batch of routes that would,
when grouped, push the number of static routes configured above the maximum allowed, the first n
routes in the batch are accepted. The number previously configured is accepted, and the remainder are
rejected. The n argument is the difference between the maximum number allowed and number previously
configured.
SUMMARY STEPS
1. configure
2. route maximum {ipv4 | ipv6} value
3. end
or
commit
DETAILED STEPS
Example:
RP/0/RP0/CPU0:router# configure
Step 2 route maximum {ipv4 | ipv6} value Changes the maximum number of allowable static routes.
• Specify IPv4 or IPv6 address prefixes.
Example: • Specify the maximum number of static routes for the
RP/0/RP0/CPU0:router(config)# route maximum
ipv4 10000
given address family. The range is from 1 to 128000.
• This example sets the maximum number of static IPv4
routes to 10000.
Step 3 end Saves configuration changes.
or
• When you issue the end command, the system prompts
commit you to commit changes:
Uncommitted changes found, commit them before
Example: exiting(yes/no/cancel)?
RP/0/RP0/CPU0:router(config)# end [cancel]:
or
– Entering yes saves configuration changes to the
RP/0/RP0/CPU0:router(config)# commit 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.
Configuration Examples
This section provides the following configuration examples:
• Configuring Traffic Discard: Example
• Configuring a Fixed Default Route: Example
• Configuring a Floating Static Route: Example
Where to Go Next
For additional information on static routes, routing protocols, and RIB, consult the following
publications:
• Implementing and Monitoring RIB on Cisco IOS XR Software
• Implementing BGP on Cisco IOS XR Software
• Implementing IS-IS on Cisco IOS XR Software
• Implementing OSPF on Cisco IOS XR Software
• Implementing OSPFv3 on Cisco IOS XR Software
• RIB Commands on Cisco IOS XR Software
Additional References
The following sections provide references related to implementing static routes on Cisco IOS XR
software.
Related Documents
Related Topic Document Title
Static routes commands: complete command syntax, Static and Utility Routing Commands on Cisco IOS XR Software,
command modes, command history, defaults, usage Release 3.2
guidelines, and examples
Standards
Standards Title
No new or modified standards are supported by this —
feature, and support for existing standards has not been
modified by this feature.
MIBs
MIBs MIBs Link
There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using
Cisco IOS XR software, use the Cisco MIB Locator found at the
following URL:
http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
RFCs Title
No new or modified RFCs are supported by this —
feature, and support for existing RFCs has not been
modified by this feature.
Technical Assistance
Description Link
The Cisco Technical Support website contains http://www.cisco.com/techsupport
thousands of 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.
Draft-ietf-isis-traffic-05.txt, IS-IS Extensions for Traffic show isis mpls traffic-eng adjacency-log
Engineering RC-124 command RC-112
Draft-ietf-isis-wg-multi-topology-06.txt, M-ISIS show isis mpls traffic-eng advertisements
command RC-112
Multi Topology (MT) Routing in IS-IS RC-124
show isis neighbors command RC-116
show isis spf-log command RC-118
E show isis topology command RC-97
show running-config command RC-107
ebgp-multihop command RC-56
end-policy command RC-30
EXEC mode RC-13 G
clear bgp flap statistics command RC-50
graceful-restart helper command RC-142
clear bgp flap statistics reexp command RC-51
graceful-restart interval command RC-142
clear bgp flap statistics route-policy command RC-51
graceful-restart lifetime command RC-142
clear bgp soft in command RC-71
clear bgp soft out command RC-72
clear ospf command RC-181 H
clear ospfv3 command RC-181
hello-interval (IS-IS) command RC-114
show bgp af-group command RC-12, RC-13
hello interval (OSPF) command RC-152
show bgp cidr-only command RC-74
hello-multiplier command RC-114
show bgp community command RC-74
hello-padding command RC-114
show bgp count-only command RC-74
hello-password command RC-110, RC-115
show bgp flap-statistics command RC-50
show bgp flap statistics reexp command RC-50
show bgp flap statistics route-policy command RC-50 I
show bgp inheritance command RC-12
ignore-lsp-errors command RC-104
show bgp neighbor command RC-11
inheritance
show bgp neighbor-group command RC-14, RC-75
configurations (BGP) RC-7
show bgp neighbors command RC-74
monitoring RC-11
show bgp paths command RC-75
password-disable command RC-57 RFC 3373, Three-Way Handshake for IS-IS Point-to-Point
Adjacencies RC-125
point-to-point networks RC-135
RFC 3392, Capabilities Advertisement with BGP-4 RC-81
policy, modifying
RFC 3567, IS-IS Cryptopgraphic Authentication RC-125
attached RC-235
RFC 3623, OSPFv3 RC-193
nonattached RC-235
RIB (Routing Information Base)
administrative distance RC-197
R data structures in BGP and other protocols RC-196
deploying RC-198
range command RC-165
description RC-195
receive-buffer-size command RC-57
examples RC-200
redistribute command RC-47, RC-168
functional overview RC-196
redistribute isis command RC-121
IPv4 and IPv6 support RC-197
retransmit-interval command RC-104
monitoring RC-198
retransmit-throttle-interval command RC-104
prerequisites RC-196
RFC 1142, OSI IS-IS Intra-domain Routing
Protocol RC-125 route dampening RC-23
RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and route-policy (BGP) command RC-31, RC-63
Dual Environments RC-125 route-policy command RC-29, RC-62
RFC 1587, Not So Stubby Area (NSSA) RC-193 route-policy pass-all command RC-16
RFC 1793, OSPF over demand circuit RC-193 route policy submode RC-29
RFC 1997, BGP Communities Attribute RC-80 end-policy command RC-30
RFC 2328, OSPF Version 2 RC-130, RC-193 See route-policy command
RFC 2385, Protection of BGP Sessions via the TCP MD5 router bgp command RC-5
Signature Option RC-80
router bgp neighbor group address family configuration
RFC 2439, BGP Route Flap Damping RC-80 mode
RFC 2545, Use of BGP-4 Multiprotocol Extensions for address family command RC-6
IPv6 Inter-Domain Routing RC-80
route redistribution (OSPFv2, OSPFv3) RC-139
RFC 2740, OSPFv3 RC-193
route-reflector-client command RC-61
RFC 2740 OSPFv3 RC-130
route reflectors RC-24
RFC 2763, Dynamic Hostname Exchange Mechanism for
IS-IS RC-125 router-id command RC-146
RFC 2796, BGP Route Reflection - An Alternative to Full router isis address family submode
Mesh IBGP RC-80 default-information originate command RC-121
RFC 2858, Multiprotocol Extensions for BGP-4 RC-80 distance command RC-121
RFC 2918, Route Refresh Capability for BGP-4 RC-80 ispf command RC-117
RFC 2966, Domain-wide Prefix Distribution with ispf startup-delay command RC-117
Two-Level IS-IS RC-125
maximum-paths command RC-121
RFC 2973, IS-IS Mesh Groups RC-125
metric-style wide command RC-112
show isis database command RC-105 timers lsa min-interval command RC-159
show isis database-log command RC-105 timers throttle spf command RC-171
show isis interface command RC-116 ttl-security command RC-57
show isis lsp-log command RC-105
show isis mpls command RC-112
U
show isis mpls traffic-eng adjacency-log
command RC-112 update groups
show isis mpls traffic-eng advertisements BGP configuration RC-18
command RC-112
BGP update generation RC-18
show isis neighbors command RC-116
monitor RC-75
show isis spf-log command RC-118
update-source command RC-57
show isis topology command RC-97
use command RC-58
show ospf command RC-162
show ospfv3 command RC-162
show running-config command RC-107 V
shutdown command RC-70
virtual link
single-topology
transit area (OSPFv2) RC-138
command RC-96
virtual-link command RC-162
configuring example RC-122
IPv6 support RC-87
set SPF interval RC-116 W
soft-reconfiguration inbound always command RC-69
weight command RC-39
spf-interval command RC-117
SPF throttling, configuring
OSPFv2 (Open Shortest Path First Version 2) RC-170
static route
Cisco IOS static route and Cisco IOS XR static route
differences RC-247
stub area RC-133
stub area types, configuring (OSPFv3) RC-147
stub command RC-149
summary-prefix command RC-121, RC-169