-
Cisco IOS High Availability Command Reference
-
Introduction
-
action cli through configure replace
-
control-plane through debug mpls ldp checkpoint
-
debug mpls ldp graceful-restart through event wdsysmon
-
frame-relay redundancy auto-sync lmi-sequence-numbers through issu set rollback-timer
-
match mpls-label through route-target
-
service call-home through show ip pim interface
-
show ip pim neighbor through show ppp subscriber statistics
-
show pppatm statistics through vrrp timers learn
-
Table Of Contents
mdr download reserve memory image
mpls label protocol (global configuration)
mpls ldp graceful-restart timers forwarding-holding
mpls ldp graceful-restart timers max-recovery
mpls ldp graceful-restart timers neighbor-liveness
mpls traffic-eng fast-reroute timers
nsf ietf helper strict-lsa-checking
match mpls-label
To redistribute routes that include Multiprotocol Label Switching (MPLS) labels if the routes meet the conditions specified in the route map, use the match mpls-label command in route-map configuration mode. To disable this function, use the no form of this command.
match mpls-label
no match mpls-label
Syntax Description
This command has no arguments or keywords.
Command Default
Routes with MPLS labels are not redistributed.
Command Modes
Route-map configuration
Command History
Usage Guidelines
A route map that includes this command can be used in the following instances:
•
With the neighbor route-map in command to manage inbound route maps in BGP
•
Use the route-map global configuration command, and the match and set route map configuration commands, to define the conditions for redistributing routes from one routing protocol into another. Each route-map command has a list of match and set commands associated with it. The match commands specify the match criteria—the conditions under which redistribution is allowed for the current route-map command. The set commands specify the set actions—the particular redistribution actions to perform if the criteria enforced by the match commands are met. The no route-map command deletes the route map.
The match route-map configuration command has multiple formats. The match commands can be given in any order, and all match commands must "pass" to cause the route to be redistributed according to the set actions given with the set commands. The no forms of the match commands remove the specified match criteria.
When you are passing routes through a route map, a route map can have several parts. Any route that does not match at least one match clause relating to a route-map command will be ignored; that is, the route will not be advertised for outbound route maps and will not be accepted for inbound route maps. If you want to modify only some data, you must configure a second route map section with an explicit match specified.
Examples
The following example shows how to create a route map that redistributes routes if the following conditions are met:
•
•
Router(config-router)# route-map incoming permit 10Router(config-route-map)# match ip address 2Router(config-route-map)# match mpls-labelRelated Commands
maximum
To set the maximum number of archive files of the running configuration to be saved in the Cisco IOS configuration archive, use the maximum command in archive configuration mode. To reset this command to its default, use the no form of this command.
maximum number
no maximum number
Syntax Description
number
Maximum number of archive files of the running configuration to be saved in the Cisco IOS configuration archive. You can archive from 1 to 14 configuration files. The default is 10.
Command Default
By default, a maximum of 10 archive files of the running configuration are saved in the Cisco IOS configuration archive.
Command Modes
Archive configuration (config-archive)
Command History
Usage Guidelines
Note
After the maximum number of files are saved in the Cisco IOS configuration archive, the oldest file is automatically deleted when the next, most recent file is saved.
Note
Examples
In the following example, a value of 5 is set as the maximum number of archive files of the running configuration to be saved in the Cisco IOS configuration archive:
configure terminal!archivepath disk0:myconfigmaximum 5endRelated Commands
mdr download reserve memory image
To reserve memory for preloading new software onto line cards that support enhanced Fast Software Upgrade (eFSU), use the mdr download reserve memory image command in privileged EXEC mode. To keep the router from reserving memory on line cards, use the no form of the command.
mdr download reserve memory image {all-slots | slot slot-num}
no mdr download reserve memory image {all-slots | slot slot-num}
Syntax Description
all-slots
Reserves memory for the new software on all installed line cards that support eFSU.
slot slot-num
Reserves memory for the new software on the line card in the specified chassis slot.
Command Default
This command is enabled by default.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
On line cards that support eFSU, the router automatically reserves memory on the line card to store the new software image (decompressed format). During the upgrade, the router preloads new line card software onto supported line cards. The amount of memory needed varies according to line card type.
You can issue the show mdr download image command to display the amount of memory that will be reserved on the line cards that support eFSU.
Although we do not recommend it, you can issue the no mdr download reserve memory image command to keep the router from reserving memory for software preload on the specified line card.
Note
Examples
The following command reserves memory for the new software on the line card installed in slot 6:
Router# mdr download reserve memory image slot 6Related Commands
show mdr download image
Displays the amount of memory that will be reserved for software preload on line cards that support eFSU.
mls ip multicast sso
To configure the stateful switchover (SSO) parameters, use the mls ip multicast sso command in global configuration mode. To return to the default settings, use the no form of this command.
mls ip multicast sso {convergence-time time | leak {interval seconds | percent percentage}}
no mls ip multicast sso {convergence-time time | leak {interval seconds | percent percentage}}
Syntax Description
Command Default
The defaults are as follows:
•
•
•
Command Modes
Global configuration
Command History
12.2(18)SXD
Support for this command was introduced on the Supervisor Engine 720.
12.2(33)SRA
This command was integrated into Cisco IOS Release 12.2(33)SRA.
Usage Guidelines
This command is not supported on Cisco 7600 series routers that are configured with a Supervisor Engine 2.
Examples
This example shows how to set the maximum time to wait for protocol convergence to 300 seconds:
Router(config)# mls ip multicast sso convergence-time 300Router(config)#This example shows how to set the packet-leak interval to 200 seconds:
Router(config)# mls ip multicast sso leak interval 200Router(config)#This example shows how to set the packet-leak percentage to 55 percent:
Router(config)# mls ip multicast sso leak percent 55Router(config)#Related Commands
show mls ip multicast sso
Displays information about multicast high-availability SSO.
mode (redundancy)
To configure the redundancy mode of operation, use the mode command in redundancy configuration mode.
Cisco 7304 Router
mode {rpr | rpr-plus | sso}
Cisco 7500 Series Routers
mode {hsa | rpr | rpr-plus | sso}
Cisco 10000 Series Routers
mode {rpr-plus | sso}
Cisco 12000 Series Routers
mode {rpr | rpr-plus | sso}
Cisco uBR10012 Universal Broadband Router
mode {rpr-plus | sso}
Syntax Description
Command Default
The default mode for the Cisco 7500 series routers is HSA.
The default mode for the Cisco 7304 router and Cisco 10000 series routers is SSO.
The default mode for the Cisco 12000 series routers is RPR.
The default mode for the Cisco uBR10012 universal broadband router is SSO.Command Modes
Redundancy configuration (config-red)
Command History
Usage Guidelines
The mode selected by the mode command in redundancy configuration mode must be fully supported by the image that has been set into both the active and standby Route Processors (RPs). A high availability image must be installed into the RPs before RPR can be configured. Use the hw-module slot image command to specify a high availability image to run on the standby RP.
For Cisco IOS Release 12.2(33)SCA on the Cisco 10000 series routers and the Cisco uBR10012 universal broadband router, the use of SSO redundancy mode is recommended because RPR+ redundancy mode is being removed. If you enable RPR+ redundancy mode, you may see the following message:
********************************************************** Warning, The redundancy mode RPR+ is being deprecated ** and will be removed in future releases. Please change ** mode to SSO: ** redundancy ** mode sso *********************************************************Examples
The following example configures RPR+ redundancy mode on a Cisco 12000 series or Cisco 1000 series router:
Router# mode rpr-plusThe following example sets the mode to HSA on a Cisco 7500 series router:
Router# mode hsaRelated Commands
mpls forwarding bgp
To enable Multiprotocol Label Switching (MPLS) nonstop forwarding on an interface that uses Border Gateway Protocol (BGP) as the label distribution protocol, use the mpls forwarding bgp command in interface configuration mode. To disable MPLS nonstop forwarding on the interface, use the no form of this command.
mpls forwarding bgp
no mpls forwarding bgp
Syntax Description
This command has no arguments or keywords.
Command Default
MPLS nonstop forwarding is not enabled on the interface.
Command Modes
Interface configuration
Command History
Usage Guidelines
Configure this command on the interfaces of the BGP peers that send and receive labels. If this command is not configured on an interface and a stateful switchover occurs, packets received from an interface are dropped until the BGP session is established in the new route processor.
Issue this command to enable nonstop forwarding on interfaces that use BGP to distribute labels for the following types of VPNs:
•
•
Examples
In the following examples, an interface is configured to save BGP labels in the event of a stateful switchover:
Cisco 7000 Series Example
Router(config)# interface Pos1/0Router(config-if)# mpls forwarding bgpCisco 10000 Series Example
Router(config)# interface Pos1/0/0Router(config-if)# mpls forwarding bgpRelated Commands
mpls label protocol (global configuration)
To specify the Label Distribution Protocol (LDP) for a platform, use the mpls label protocol command in global configuration mode. To restore the default LDP, use the no form of this command.
mpls label protocol {ldp | tdp}
no mpls label protocol
Syntax Description
ldp
Specifies that LDP is the default label distribution protocol.
tdp
Specifies that Tag Distribution Protocol (TDP) is the default label distribution protocol.
Command Default
LDP is the default label distribution protocol.
Command Modes
Global configuration
Command History
Usage Guidelines
If neither the global mpls label protocol ldp command nor the interface mpls label protocol ldp command is used, all label distribution sessions use LDP.
Note
Examples
The following command establishes LDP as the label distribution protocol for the platform:
Router(config)# mpls label protocol ldpRelated Commands
mpls ldp graceful-restart
To enable Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) Graceful Restart, use the mpls ldp graceful-restart command in global configuration mode. To disable LDP Graceful Restart, use the no form of this command.
mpls ldp graceful-restart
no mpls ldp graceful-restart
Syntax Description
This command has no arguments or keywords.
Command Default
LDP Graceful Restart is not enabled.
Command Modes
Global configuration
Command History
Usage Guidelines
LDP Graceful Restart must be enabled before an LDP session is established.
Using the no form of the command disables the Graceful Restart functionality on all LDP sessions.
Examples
The command in the following example enables LDP Graceful Restart on a router:
Router(config)# mpls ldp graceful-restartRelated Commands
mpls ldp graceful-restart timers forwarding-holding
To specify the amount of time the Multiprotocol Label Switching (MPLS) forwarding state should be preserved after the control plane restarts, use the mpls ldp graceful-restart timers forwarding-holding command in global configuration mode. To revert to the default timer value, use the no form of this command.
mpls ldp graceful-restart timers forwarding-holding secs
no mpls ldp graceful-restart timers forwarding-holding
Syntax Description
Command Default
After the control plane on the Cisco 7500 and Cisco 10000 series router restarts, the MPLS forwarding state is preserved for 600 seconds.
Command Modes
Global configuration
Command History
Usage Guidelines
Configuring the local forwarding-holding timer to a value less than the IOS FT Reconnect Timeout of 120 seconds may prevent a Label Distribution Protocol (LDP) session from being established. Configure the forwarding-holding timer to less than 120 seconds only if an LDP neighbor has an FT Reconnect Timeout value of less than 120 seconds.
If the timer expires, all entries that are marked stale are deleted.
Examples
In the following example, the MPLS forwarding state is preserved for 300 seconds after the control plane restarts:
Router(config)# mpls ldp graceful-restart timers forwarding-holding 300Related Commands
mpls ldp graceful-restart timers max-recovery
To specify the amount of time a router should hold stale label-Forwarding Equivalence Class (FEC) bindings after a Label Distribution Protocol (LDP) session has been reestablished, use the mpls ldp graceful-restart timers max-recovery command in global configuration mode. To revert to the default timer value, use the no form of this command.
mpls ldp graceful-restart timers max-recovery secs
no mpls ldp graceful-restart timers max-recovery
Syntax Description
Command Default
Stale label-FEC bindings are held for 120 seconds after an LDP session has been reestablished.
Command Modes
Global configuration
Command History
Usage Guidelines
After the timer expires, all stale label-FEC bindings learned from the associated LDP session are removed, which results in the removal of any forwarding table entries that are based on those bindings.
Examples
In the following example, the router should hold stale label-FEC bindings after an LDP session has been reestablished for 180 seconds:
Router(config)# mpls ldp graceful-restart timers max-recovery 180Related Commands
mpls ldp graceful-restart timers neighbor-liveness
To specify the upper bound on the amount of time a router should wait for a Label Distribution Protocol (LDP) session to be reestablished, use the mpls ldp graceful-restart timers neighbor-liveness command in global configuration mode. To revert to the default timer value, use the no form of this command.
mpls ldp graceful-restart timers neighbor-liveness secs
no mpls ldp graceful-restart timers neighbor-liveness
Syntax Description
secs
The amount of time (in seconds) that the router should wait for an LDP session to be reestablished. The default is 120 seconds. The range is 5 to 300 seconds.
Command Default
The default is a maximum of 120 seconds.
Command Modes
Global configuration
Command History
Usage Guidelines
The amount of time a router waits for an LDP session to be reestablished is the lesser of the following values:
•
•
If the router cannot reestablish an LDP session with the neighbor in the time allotted, the router deletes the stale label-FEC bindings received from that neighbor.
Examples
The command in the following example sets the amount of time that the router should wait for an LDP session to be reestablished to 30 seconds:
Router(config)# mpls ldp graceful-restart timers neighbor-liveness 30Related Commands
mpls traffic-eng backup-path
To assign one or more backup tunnels to a protected interface, use the mpls traffic-eng backup-path command in interface configuration mode.
mpls traffic-eng backup-path tunneltunnel-id
Syntax Description
Command Default
No backup tunnels are used if this interface goes down.
Command Modes
Interface configuration
Command History
Usage Guidelines
Enter this command on the interface to be protected (Link Protection), or on the interface whose downstream node is being protected (Node Protection). You can enter this command multiple times to select multiple backup tunnels for a given protected interface. An unlimited number of backup tunnels can be assigned to protect an interface. The only limitation is memory. By entering this command on a physical interface, LSPs using this interface (sending data out of this interface) can use the indicated backup tunnels if there is a link or node failure.
Examples
The following example assigns backup tunnel 34 to interface POS5/0:
Router(config)# interface pos5/0Router(config-if)# mpls traffic-eng backup-path tunnel34Related Commands
tunnel mpls traffic-eng fast-reroute
Enables an MPLS traffic engineering tunnel to use a backup tunnel if there is a link or node failure (provided that a backup tunnel exists).
mpls traffic-eng fast-reroute timers
To specify how often the router considers switching a label switched path (LSP) to a new (better) backup tunnel if additional backup bandwidth becomes available, use the mpls traffic-eng fast-reroute timers command in global configuration mode. To disable this timer, set the seconds value to zero or use the no form of this command.
mpls traffic-eng fast-reroute timers [promotion seconds]
no mpls traffic-eng fast-reroute timers
Syntax Description
Command Default
The timer is running and is set to a frequency of every 300 seconds (5 minutes). If you enter the no mpls traffic-eng fast-reroute timers command, the router returns to this default behavior.
Command Modes
Global configuration
Command History
Examples
In the following example, LSPs are scanned every 2 minutes (120 seconds). The router uses this information to consider if the LSPs should be promoted to a better backup tunnel:
Router(config)# mpls traffic-eng fast-reroute timers promotion 120neighbor ha-mode sso
To configure a Border Gateway Protocol (BGP) neighbor to support BGP nonstop routing (NSR) with stateful switchover (SSO), use the neighbor ha-mode sso command in the appropriate command mode. To remove the configuration, use the no form of this command.
neighbor ip-address ha-mode sso
no neighbor ip-address ha-mode sso
Syntax Description
Command Default
BGP NSR with SSO support is disabled.
Command Modes
Address family configuration
Session-template configurationCommand History
Usage Guidelines
The neighbor ha-mode sso command is used to configure a BGP neighbor to support BGP NSR with SSO. BGP NSR with SSO is disabled by default.
BGP NSR with SSO is supported in BGP peer, BGP peer group, and BGP session template configurations. To configure BGP NSR with SSO in BGP peer and BGP peer group configurations, use the neighbor ha-mode sso command in address family configuration mode for IPv4 VRF address family BGP peer sessions. To include support for Cisco BGP NSR with SSO in a peer session template, use the ha-mode sso command in session-template configuration mode.
Examples
The following example shows how to configure a BGP neighbor to support SSO:
Router(config-router-af)# neighbor 10.3.32.154 ha-mode ssoRelated Commands
show ip bgp vpnv4
Displays VPN address information from the BGP table.
show ip bgp vpnv4 all sso summary
Displays the number of BGP neighbors that support SSO.
neighbor send-label
To enable a Border Gateway Protocol (BGP) router to send Multiprotocol Label Switching (MPLS) labels with BGP routes to a neighboring BGP router, use the neighbor send-label command in address family configuration mode or router configuration mode. To disable this feature, use the no form of this command.
neighbor {ip-address | ipv6-address | peer-group-name} send-label
no neighbor {ip-address | ipv6-address | peer-group-name} send-label
Syntax Description
ip-address
IP address of the neighboring router.
ipv6-address
IPv6 address of the neighboring router.
peer-group-name
Name of a BGP peer group.
Command Default
BGP routers distribute only BGP routes.
Command Modes
Address family configuration
Router configurationCommand History
Usage Guidelines
This command enables a router to use BGP to distribute MPLS labels along with the IPv4 routes to a peer router. You must issue this command on both the local router and the neighboring router.
This command has the following restrictions:
•
•
Use this command in IPv6 address family configuration mode to bind and advertise IPv6 prefix MPLS labels. Using this command in conjunction with the mpls ipv6 source-interface global configuration command allows IPv6 traffic to run over an IPv4 MPLS network without any software or hardware configuration changes in the backbone. Edge routers configured to run both IPv4 and IPv6 forward IPv6 traffic using MPLS and multiprotocol internal BGP (MP-iBGP).
Cisco IOS installs /32 routes for directly connected external BGP (eBGP) peers when the BGP session for such a peer comes up. The /32 routes are installed only when MPLS labels are exchanged between such peers. Directly connected eBGP peers exchange MPLS labels for:
•
•
A single BGP session can include multiple address families. If one of the families exchanges MPLS labels, the /32 neighbor route is installed for the connected peer.
Examples
The following example shows how to enable a router in the autonomous system 65000 to send MPLS labels with BGP routes to the neighbor BGP router at 192.168.0.1:
Router(config)# router bgp 65000Router(config-router)# neighbor 192.168.0.1 remote-as 65001Router(config-router)# neighbor 192.168.0.1 send-labelThe following example shows how to enable a router in the autonomous system 65000 to bind and advertise IPv6 prefix MPLS labels and send the labels with BGP routes to the neighbor BGP router at 192.168.99.70:
Router(config)# router bgp 65000Router(config-router)# neighbor 192.168.99.70 remote-as 65000Router(config-router)# address-family ipv6Router(config-router-af)# neighbor 192.168.99.70 activateRouter(config-router-af)# neighbor 192.168.99.70 send-labelRelated Commands
neighbor activate
Enables the exchange of information with a neighboring router.
nsf (EIGRP)
To enable Cisco nonstop forwarding (NSF) operations for Enhanced Interior Gateway Protocol (EIGRP), use the nsf command in router configuration mode or address-family configuration mode. To disable EIGRP NSF and remove the EIGRP NSF configuration from the running-config file, use the no form of this command.
nsf
no nsf
Syntax Description
This command has no arguments or keywords.
Command Default
EIGRP NSF capability is enabled by default.
Command Modes
Router configuration (config-router)
Address-family configuration (config-router-af)Command History
Usage Guidelines
This command is used to enable or disable EIGRP NSF support on an NSF capable router. EIGRP NSF capability is enabled by default on distributed platforms that run a supporting version of Cisco IOS software.
Examples
The nsf command is used to enable or disable the EIGRP NSF capability. The following example disables NSF capability:
Router# configure terminalRouter(config)# router eigrp 101Router(config-router)# no nsfThe nsf command is used to enable or disable the EIGRP NSF capability. The following EIGRP named configuration example disables NSF capability:
Router(config)# router eigrp virtual-nameRouter(config-router)# address-family ipv4 as 10Router(config-router-af)# no nsfRelated Commands
nsf (IS-IS)
To configure Cisco nonstop forwarding (NSF) operations for Intermediate System-to-Intermediate System (IS-IS), use the nsf command in router configuration IS-IS mode. To remove this command from the configuration file and restore the system to its default condition with respect to this command, use the no form of this command.
nsf [cisco | ietf]
no nsf [cisco | ietf]
Syntax Description
Command Default
NSF is disabled by default.
Command Modes
Router configuration IS-IS
Command History
Usage Guidelines
The user must configure NSF operation only if a router is expected to perform NSF during restart. The optional cisco keyword enables the use of checkpointing to allow the standby route processor (RP) to restore protocol state when an NSF restart occurs.
Examples
The following example enables Cisco proprietary IS-IS NSF operation:
nsf ciscoThe following example enables IETF IS-IS NSF operation:
nsf ietfRelated Commands
nsf (OSPF)
Note
To configure Cisco nonstop forwarding (NSF) operations for Open Shortest Path First (OSPF), use the nsf command in router configuration mode. To disable Cisco NSF for OSPF, use the no form of this command.
nsf [enforce global]
no nsf [enforce global]
Syntax Description
enforce global
(Optional) Cancels NSF restart when non-NSF-aware neighboring networking devices are detected.
Command Default
This command is disabled by default; therefore, NSF operations for OSPF is not configured.
Command Modes
Router configuration (config-router)
Command History
Usage Guidelines
The user must configure NSF operation for OSPF only if a router is expected to perform NSF during restart. For users to have full NSF benefits, all OSPF neighbors of the specified router must be NSF-aware.
If neighbors that are not NSF-aware are detected on a network interface, NSF restart is aborted on the interface; however, NSF restart will continue on other interfaces. This functionality applies to the default NSF mode of operation when NSF is configured.
If the user configures the optional enforce global keywords, NSF restart will be canceled for the entire process when neighbors that are not NSF-aware are detected on any network interface during restart. NSF restart will also be canceled for the entire process if a neighbor adjacency reset is detected on any interface or if an OSPF interface goes down. To revert to the default NSF mode, enter the no nsf enforce global command.
Examples
The following example enters router configuration mode and cancels the NSF restart for the entire OSPF process if neighbors that are not NSF-aware are detected on any network interface during restart:
Router(config)# router ospf 1Router(config-router)# nsf enforce globalRelated Commands
debug ip ospf nsf
Displays debugging messages related to OSPF NSF commands.
router ospf
Enables OSPF routing and places the router in router configuration mode.
nsf cisco
To enable Cisco nonstop forwarding (NSF) operations on a router that is running Open Shortest Path First (OSPF), use the nsf cisco command in router configuration mode. To disable Cisco NSF, use the no form of this command.
nsf cisco [enforce global]
no nsf cisco [enforce global]
Syntax Description
enforce global
(Optional) Cancels NSF restart when non-NSF-aware neighboring networking devices are detected.
Command Default
This command is disabled by default; therefore, Cisco NSF operations are disabled on a router that is running OSPF.
Command Modes
Router configuration (config-router)
Command History
Usage Guidelines
For Cisco IOS Release 12.0(32)S and later releases, the nsf cisco [enforce global] command replaces the nsf [enforce global] command for OSPF.
To enable Cisco NSF on an OSPF router, you need to enter the nsf cisco command. When a router has Cisco NSF enabled, the router is said to be NSF-capable and will operate in graceful restart mode—the OSPF router process performs non-stop forwarding recovery due to a Route Processor (RP) switchover. By default, the neighbor routers of the NSF-capable router will be NSF-aware and will operate in NSF helper mode. When the NSF-capable router is performing graceful restart, the neighbor router helps with the non-stop forwarding recovery.
During the NSF restart process, if neighbors that are not NSF-aware are detected on a network interface, NSF restart is aborted on the interface; however, NSF restart will continue on other interfaces. This functionality applies to the default NSF mode of operation when Cisco NSF is configured. If the user configures the nsf cisco command with the optional enforce global keywords, NSF restart will be canceled for the entire process when neighbors that are not NSF-aware are detected on any network interface during restart. The NSF restart will also be canceled for the entire process when a neighbor adjacency reset is detected on any interface or when an OSPF interface goes down. To revert to the default NSF behavior, enter the no nsf cisco enforce global command.
Examples
The following example enables Cisco NSF on a router and causes the NSF restart to be canceled for the entire OSPF process if neighbors that are not NSF-aware are detected on any network interface during the restart.
router ospf 24nsf cisco enforce globalRelated Commands
nsf cisco helper disable
To disable Cisco nonstop forwarding (NSF) helper mode on a Cisco router that is running Open Shortest Path First (OSPF), use the nsf cisco helper disable command in router configuration mode. To reenable Cisco NSF helper mode, use the no form of this command.
nsf cisco helper disable
no nsf cisco helper disable
Syntax Description
This command has no arguments or keywords.
Command Default
This command is enabled by default; therefore, NSF helper mode is disabled on a Cisco router that is running OSPF.
Command Modes
Router configuration (config-router)
Command History
Usage Guidelines
When a router in an OSPF process has NSF enabled, the router is said to be NSF-capable and will operate in graceful restart mode—the OSPF router process performs nonstop forwarding recovery due to a Route Processor (RP) switchover. By default, the neighboring routers of the NSF-capable router will be NSF-aware and will operate in NSF helper mode. When the NSF-capable router is performing graceful restart, the helper routers assist in the nonstop forwarding recovery process. If you do not want the router to help the restarting neighbor with nonstop forwarding recovery, enter the nsf cisco helper disable command.
Examples
The following example disables NSF helper mode for the Cisco router on OSPF process 3:
router ospf 3nsf cisco helper disableRelated Commands
nsf ietf
To enable IETF nonstop forwarding (NSF) operations on a router that is running Open Shortest Path First (OSPF), use the nsf ietf command in router configuration mode. To disable IETF NSF, use the no form of this command.
nsf ietf [restart-interval seconds]
no nsf ietf [restart-interval seconds]
Syntax Description
restart-interval seconds
(Optional) Specifies length of the graceful restart interval, in seconds. The range is from 1 to 1800. The default is 120.
Command Default
This command is disabled by default; therefore, IETF NSF operations are disabled on a router that is running OSPF.
Command Modes
Router configuration (config-router)
Command History
Usage Guidelines
To enable IETF NSF on an OSPF router, enter the nsf ietf command. When a router has NSF enabled, the router is said to be NSF-capable and will operate in graceful restart mode—the OSPF router process performs nonstop forwarding recovery due to a Route Processor (RP) switchover. By default, the neighbor routers of the NSF-capable router will be NSF-aware and will operate in NSF helper mode. When the NSF-capable router is performing graceful restart, the neighbor router helps in the nonstop forwarding recovery.
Examples
The following example enables IETF NSF (graceful restart) on a router, changing the graceful restart interval to 200 seconds:
router ospf 24nsf ietf restart-interval 200Related Commands
nsf ietf helper disable
To disable Internet Engineering Task Force (IETF) nonstop forwarding (NSF) helper mode on a router that is running Open Shortest Path First (OSPF), use the nsf ietf helper disable command in router configuration mode. To reenable IETF NSF helper mode, use the no form of this command.
nsf ietf helper disable
no nsf ietf helper disable
Syntax Description
This command has no arguments or keywords.
Command Default
This command is disabled by default; therefore, IETF NSF helper mode is enabled on a router that is running OSPF.
Command Modes
Router configuration (config-router)
Command History
Usage Guidelines
When a router in an OSPF process has NSF enabled, the router is said to be NSF-capable and will operate in graceful restart mode—the OSPF router process performs nonstop forwarding recovery due to a Route Processor (RP) switchover. By default, the neighboring routers of the NSF-capable router will be NSF-aware and will operate in NSF helper mode. When the NSF-capable router is performing graceful restart, the helper routers assist in the nonstop forwarding recovery process. If you do not want the router to help the restarting neighbor with nonstop forwarding recovery, enter the nsf ietf helper disable command.
Examples
The following example disables IETF NSF helper mode on a router on OSPF process 4:
router ospf 4nsf ietf helper disableRelated Commands
nsf ietf helper strict-lsa-checking
To enable strict link-state advertisement (LSA) checking on routers in an Open Shortest Path First (OSPF) process, use the nsf ietf helper strict-lsa-checking command in router configuration mode. To disable strict LSA checking, use the no form of this command.
nsf ietf helper strict-lsa-checking
no nsf ietf helper strict-lsa-checking
Syntax Description
This command has no arguments or keywords.
Command Default
This command is disabled by default; therefore, strict LSA checking is not done on routers in an OSPF process.
Command Modes
Router configuration (config-router)
Command History
Usage Guidelines
To enable strict LSA checking on both NSF-aware and NSF-capable routers, enter the nsf ietf helper strict-lsa-checking command. However, strict LSA checking will not become effective until the router becomes a helper router during an IETF graceful restart process. With strict LSA checking enabled, the helper router will terminate the helping process of the restarting router if it detects that there is a change to an LSA that would be flooded to the restarting router or if there is a changed LSA on the retransmission list of the restarting router when the graceful restart process is initiated.
Examples
The following example enables strict LSA checking on a router on OSPF process 12:
router ospf 12nsf ietf helper strict-lsa-checkingRelated Commands
nsf interface wait
To specify how long a Cisco nonstop forwarding (NSF) restart will wait for all interfaces with Intermediate System-to-Intermediate System (IS-IS) adjacencies to come up before completing the restart, use the nsf interface wait command in router configuration IS-IS mode. To remove this command from the configuration file and restore the system to its default condition with respect to this command, use the no form of this command.
nsf interface wait seconds
no nsf interface wait seconds
Syntax Description
Command Default
The default value for the seconds argument is 10.
Command Modes
Router configuration IS-IS
Command History
Usage Guidelines
The nsf interface wait command can be used if Cisco proprietary IS-IS NSF is configured or if Internet Engineering Task Force (IETF) IS-IS NSF is enabled using the nsf t3 manual command. You can use this command if an interface is slow to come up.
Examples
The following example specifies that NSF restart will wait 15 seconds for all interfaces with IS-IS adjacencies to come up before completing the restart:
Router(config)# router isisRouter(config-router)# nsf ciscoRouter(config-router)# nsf interface wait 15Related Commands
nsf interval
To configure the minimum time between Cisco nonstop forwarding (NSF) restart attempts, use the nsf interval command in router configuration Intermediate System-to-Intermediate System (IS-IS) mode. To remove this command from the configuration file and restore the system to its default condition with respect to this command, use the no form of this command.
nsf interval minutes
no nsf interval minutes
Syntax Description
minutes
The length of time in minutes between restart attempts. The valid range is from 0 to 1440 minutes.
Command Default
The default value for the minutes argument is 5.
Command Modes
Router configuration IS-IS
Command History
Usage Guidelines
The nsf interval command can be used with both Cisco proprietary IS-IS NSF and Internet Engineering Task Force (IETF) IS-IS NSF. When you use Cisco proprietary IS-IS NSF, the active route processor (RP) must be up for at least 5 minutes before IS-IS will attempt to perform an NSF restart as part of a stateful switchover.
When you use the nsf command with the ietf keyword, the standby RP must be up for at least 5 minutes before IS-IS will attempt to perform an NSF restart as part of a stateful switchover.
Examples
The following example configures the minimum time between NSF restart attempts to be 2 minutes:
Router(config-router)# router isisRouter(config-router)# nsf ciscoRouter(config-router)# nsf interval 2Related Commands
nsf t3
To specify the methodology used to determine how long Internet Engineering Task Force (IETF) Cisco nonstop forwarding (NSF) will wait for the link-state packet (LSP) database to synchronize before generating overloaded link-state information for itself and flooding that information out to its neighbors, use the nsf t3 command in router configuration IS-IS mode. To remove this command from the configuration file and restore the system to its default condition with respect to this command, use the no form of this command.
nsf t3 {manual seconds | adjacency}
no nsf t3 {manual seconds | adjacency}
Syntax Description
Command Default
The default value for the seconds argument is 30.
Command Modes
Router configuration IS-IS
Command History
Usage Guidelines
When the nsf t3 adjacency command is enabled, the time that IETF NSF waits for the LSP database to synchronize is determined by the adjacency holdtime advertised to the neighbors of the specified RP before switchover. When the nsf t3 manual command is enabled, the specified time in seconds is used.
The nsf t3 manual command can be used only if IETF IS-IS NSF is configured.
Examples
In the following example, the amount of time that IETF NSF waits for the LSP database to synchronize is set to 40 seconds:
nsf t3 manual 40In the following example, the amount of time that IETF NSF waits for the LSP database to synchronize is determined by the adjacency holdtime advertised to the neighbors of the specified RP before switchover:
nsf t3 adjacencyRelated Commands
path (archive configuration)
To specify the location and filename prefix for the files in the Cisco IOS configuration archive, use the path command in archive configuration mode. To disable this function, use the no form of this command.
path url
no path url
Syntax Description
url
URL (accessible by the Cisco IOS file system) used for saving archive files of the running configuration file in the Cisco IOS configuration archive.
Command Default
If this command is not configured, no location or filename prefix is specified for files in the Cisco IOS configuration archive.
Command Modes
Archive configuration (config-archive)
Command History
Usage Guidelines
When this command is entered, an archive file of the running configuration is saved when the archive config, write-memory, or copy running-config startup-config command is entered.
URLs are commonly used to specify files or location on the World Wide Web. On Cisco routers, URLs can be used to specify the location of a file or directory on a router or a remote file server. The path command uses a URL to specify the location and filename prefix for the Cisco IOS configuration archive.
The locations or file systems that you can specify in the url argument are as follows:
•
•
The colon is required in the location format.
The filename of the first archive file is the filename specified in the url argument followed by -1. The filename of the second archive file is the filename specified in the url argument followed by -2 and so on.
Because some file systems are incapable of storing the date and time that a file was written, the filename of the archive file can contain the date, time, and router hostname. To include the router hostname in the archive file filename, enter the characters $h (for example, disk0:$h). To include the date and time in the archive file filename, enter the characters $t.
When a configuration archive operation is attempted on a local file system, the file system is tested to determine if it is writable and if it has sufficient space to save an archive file. If the file system is read-only or if there is not enough space to save an archive file, an error message is displayed.
If you specify the tftp: file server as the location with the path command, you need to create the configuration file on the TFTP file server and change the file's privileges before the archive config command works properly.
Examples
The following example of the path command shows how to specify the hostname, date, and time as the filename prefix for which to save archive files of the running configuration. In this example, the time-period command is also configured to automatically save an archive file of the running configuration every 20 minutes.
configure terminal!archivepath disk0:$h$ttime-period 20endThe following is sample output from the show archive command illustrating the format of the resulting configuration archive filenames.
Router# show archiveThere are currently 3 archive configurations saved.The next archive file will be named routerJan-16-01:12:23.019-4Archive # Name01 disk0:routerJan-16-00:12:23.019-12 disk0:routerJan-16-00:32:23.019-23 disk0:routerJan-16-00:52:23.019-3 <- Most Recent4567891011121314Cisco IOS Configuration Archive on the TFTP File Server
The following example shows how to use the path command to specify the TFTP file server, address 10.48.71.226, as the archive configuration location and router-cfg as the configuration filename. First you create the configuration file on the TFTP server and change the file's privileges, then you can save the configuration file to the configuration archive.
The following example shows the commands to use to create the file and change the file's privileges on the TFTP server (UNIX commands):
> touch router-cfg-1> chmod 777 router-cfg-1The following example show how to create the configuration archive, save the running configuration to the archive, and display the files in the archive:
configure terminal!archivepath tftp://10.48.71.226/router-cfgexitexit!archive configRouter# show archiveThe next archive file will be named tftp://10.48.71.226/router-cfg-2Archive # Name01 tftp://10.48.71.226/router-cfg-1 <- Most Recent234567891011121314The following is sample output from the show archive command if you did not create the configuration file on the TFTP server before attempting to archive the current running configuration file:
configure terminal!archivepath tftp://10.48.71.226/router-cfgexitexitarchive configRouter# show archiveThe next archive file will be named tftp://10.48.71.226/router-cfg-1Archive # Name01234567891011121314Related Commands
profile (call home)
To enter call home profile configuration mode, use the profile command in call home configuration mode. To delete the named destination profile or all destination profiles, use the no form of this command.
profile profile-name
no profile {profile-name | all}
Syntax Description
Command Default
The profile is enabled.
Command Modes
Call home configuration (cfg-call-home)
Command History
Usage Guidelines
Once you enter the profile command, the prompt changes to Router(cfg-call-home-profile)#, and you have access to the destination profile configuration commands as follows:
•
•
–
–
–
•
•
•
•
Examples
The following example shows how to enter call home profile configuration mode:
Router(cfg-call-home)# profile profile1Router(cfg-call-home-profile)#Related Commands
rd
To specify a route distinguisher (RD) for a VPN routing and forwarding (VRF) instance, use the rd command in VRF configuration submode.
rd route-distinguisher
Syntax Description
Command Default
There is no default. An RD must be configured for a VRF to be functional.
Command Modes
VRF configuration submode
Command History
Usage Guidelines
An RD creates routing and forwarding tables and specifies the default route distinguisher for a VPN. The RD is added to the beginning of the customer's IPv4 prefixes to change them into globally unique VPN-IPv4 prefixes.
An RD is either:
•
•
You can enter an RD in either of these formats:
16-bit autonomous-system-number:your 32-bit number
For example, 101:3.32-bit IP address:your 16-bit number
For example, 192.168.122.15:1.Examples
The following example shows how to configure a default RD for two VRFs. It illustrates the use of both autonomous-system-number-relative and IP-address-relative RDs:
Router(config)# ip vrf vrf1Router(config-vrf)# rd 100:3Router (config-vrf)# exitRouter(config)# ip vrf vrf2Router(config-vrf)# rd 10.13.0.12:200Related Commands
redundancy
To enter redundancy configuration mode, use the redundancy command in global configuration mode.
redundancy
Syntax Description
This command has no arguments or keywords.
Command Default
No default behaviors or values.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
Use the redundancy command to enter redundancy configuration mode, where you can define aspects of redundancy such as shelf redundancy for the Cisco AS5800 universal access server.
Cisco 10000 Series Router
Before configuring line card redundancy, install the Y-cables. Before deconfiguring redundancy, remove the Y-cables.
The following restrictions apply to line card redundancy on the Cisco 10000 series router:
•
•
•
Cisco 7600 Series Router
From redundancy configuration mode, you can enter the main CPU submode to manually synchronize the configurations that are used by the two supervisor engines.
From the main CPU submode, you can use the auto-sync command to use all of the redundancy commands that are applicable to the main CPU.
To select the type of redundancy mode, use the mode command.
Nonstop forwarding (NSF) with stateful switchover (SSO) redundancy mode supports IPv4. NSF with SSO redundancy mode does not support IPv6, INternetwork Packet Exchange (IPX), and Multiprotocol Label Switching (MPLS).
Cisco uBR10012 Universal Broadband Router
After you enter redundancy configuration mode, you can use the main-cpu command to enter main-CPU redundancy configuration mode, which allows you to specify which files are synchronized between the active and standby Performance Routing Engine (PRE) modules.
Cisco RF Gateway 10
At the redundancy configuration mode, you can do the following:
•
•
•
•
•
•
Examples
The following example enables redundancy mode:
Router(config)# redundancyRouter(config-red)#The following example assigns the configured router shelf to the redundancy pair designated as 25. This command must be issued on both router shelves in the redundant router-shelf pair:
Router(config)# redundancyRouter(config-red)# failover group-number 25Cisco 10000 Series Router
The following example configures two 4-port channelized T3 half eight line cards that are installed in line card slot 2 for one-to-one redundancy:
Router(config)# redundancyRouter(config-red)# linecard-group 1 y-cableRouter(config-red-lc)# member subslot 2/1 primaryRouter(config-red-lc)# member subslot 2/0 secondaryCisco 7600 Series Router
The following example shows how to enter the main CPU submode:
Router (config)# redundancyRouter (config-r)# main-cpuRouter (config-r-mc)#Cisco uBR10012 Universal Broadband Router
The following example shows how to enter redundancy configuration mode and the commands that are available in that mode on the Cisco uBR10012 router:
Router# config tRouter(config)# redundancyRouter(config-r)# ?Redundancy configuration commands:associate Associate redundant slotsexit Exit from redundancy configuration modemain-cpu Enter main-cpu modeno Negate a command or set its defaultsCisco RF Gateway 10
The following example shows how to enter redundancy configuration mode and its associated commands on the Cisco RFGW-10 chassis:
Router# configure terminalRouter(config)# redundancyRouter(config-red)#?Redundancy configuration commands:default Set a command to its defaultsexit Exit from redundancy configuration modelinecard-group Enter linecard redundancy submodemain-cpu Enter main-cpu modemode redundancy mode for this chassisno Negate a command or set its defaultspolicy redundancy policy enforcementRelated Commands
redundancy force-switchover
To force the standby Route Processor (RP) or Supervisor card to assume the role of the active RP or Supervisor card, use the redundancy force-switchover command in privileged EXEC mode.
redundancy force-switchover [main-cpu]
Syntax Description
Command Default
No default behavior or values.
Command Modes
Privileged EXEC (#)
Command History
Usage Guidelines
Use the redundancy force-switchover command to switch control of a router from the active RP or Supervisor card to the standby RP or Supervisor card. Both the active and standby RPs or Supervisor cards must have a high availability Cisco IOS image installed and must be configured for Route Processor Redundancy (RPR) mode before the redundancy force-switchover command can be used. Before the system switches over, it verifies that the standby RP or Supervisor card is ready to take over.
When you use the redundancy force-switchover command and the current running configuration is different from the startup configuration, the system prompts you to save the running configuration before the switchover is performed.
Note
Note
On Cisco 7600 series routers, the redundancy force-switchover command conducts a manual switchover to the redundant supervisor engine. The redundant supervisor engine becomes the new active supervisor engine running the new Cisco IOS image. The modules are reset and the module software is downloaded from the new active supervisor engine.
The active and redundant supervisor engines do not reset on a Route Processor Redundancy Plus (RPR+) switchover. The old active supervisor engine reboots with the new image and becomes the redundant supervisor engine.
Beginning with Cisco IOS Release 12.2(33)SCA, you can force a Performance Routing Engine (PRE) switchover using the redundancy force-switchover main-cpu command from either the primary or standby PRE. If you force a switchover from the active PRE, both PREs synchronize and the active PRE reloads normally. When you force a switchover from the standby PRE, a crash dump of the active PRE occurs for troubleshooting purposes. Forcing a switchover from the standby PRE should only be done if you cannot access the active PRE.
Examples
The following example shows a switchover from the active RP to the standby RP on a Cisco 7513 router with RPR configured:
Router# configure terminalRouter(config)# hw-module slot 7 image slot0:rsp-pv-mzRouter(config)# hw-module slot 6 image slot0:rsp-pv-mzRouter(config)# slave auto-sync configRouter(config)# redundancyRouter(config-r)# mode rprRouter(config-r)# endRouter# copy running-config startup-configRouter# redundancy force-switchoverThe following example shows how to perform a manual switchover from the active to the standby RP when the running configuration is different from the startup configuration:
Router# redundancy force-switchoverSystem configuration has been modified. Save? [yes/no]:yBuilding configuration.........[OK]Proceed with switchover to standby NSE? [confirm]y00:07:35:%SYS-5-SWITCHOVER:Switchover requestedThe following example shows how to perform a manual switchover from the active to the standby RP when the running configuration is the same as the startup configuration:
Router# redundancy force-switchoverProceed with switchover to standby NSE? [confirm]00:07:35:%SYS-5-SWITCHOVER:Switchover requestedCisco RF Gateway 10
The following example shows how to perform a manual switchover from the active to the standby RP when the running configuration is different from the startup configuration:
Router# redundancy force-switchoverSystem configuration has been modified. Save? [yes/no]:yBuilding configuration.........[OK]Proceed with switchover to standby NSE? [confirm]y00:07:35:%SYS-5-SWITCHOVER:Switchover requestedThe following example shows how to perform a manual switchover from the active to the standby RP when the running configuration is the same as the startup configuration:
Router# redundancy force-switchoverProceed with switchover to standby NSE? [confirm]00:07:35:%SYS-5-SWITCHOVER:Switchover requestedRelated Commands
reload
To reload the operating system, use the reload command in privileged EXEC or diagnostic mode.
reload [/verify | /noverify] [line | in [hhh:mm | mmm [text]] | at hh:mm [text] | cancel]
Syntax Description
Command Modes
Privileged EXEC (#)
Diagnostic (diag)Command History
Usage Guidelines
The reload command halts the system. If the system is set to restart on error, it reboots itself. Use the reload command after configuration information is entered into a file and saved to the startup configuration.
You cannot reload from a virtual terminal if the system is not set up for automatic booting. This restriction prevents the system from using an image stored in the ROM monitor and taking the system out of the remote user's control.
If you modify your configuration file, the system prompts you to save the configuration. During a save operation, the system prompts whether you want to proceed with the save if the CONFIG_FILE variable points to a startup configuration file that no longer exists. If you respond "yes" in this situation, the system enters setup mode upon reload.
When you schedule a reload to occur at a later time (using the in keyword), it must take place within 24 days.
The at keyword can be used only if the system clock has been set on the router (either through Network Time Protocol [NTP], the hardware calendar, or manually). The time is relative to the configured time zone on the router. To schedule reloads across several routers to occur simultaneously, synchronize the time on each router with NTP.
When you specify the reload time using the at keyword, if you specify the month and day, the reload takes place at the specified time and date. If you do not specify the month and day, the reload takes place at the specified time on the current day (if the specified time is later than the current time), or on the next day (if the specified time is earlier than the current time). Specifying 00:00 schedules the reload for midnight. The reload must take place within 24 days.
To display information about a scheduled reload, use the show reload command.
The /verify and /noverify Keywords
If the /verify keyword is specified, the integrity of the image will be verified before it is reloaded onto a router. If verification fails, the image reload will not occur. Image verification is important because it assures the user that the image is protected from accidental corruption, which can occur at any time during transit, starting from the moment the files are generated by Cisco until they reach the user.
The /noverify keyword overrides any global automatic image verification that may be enabled via the file verify auto command.
The warm Keyword
If you issue the reload command after you have configured the warm-reboot global configuration command, a cold reboot will occur. Thus, if you want to reload your system, but do not want to override the warm reboot functionality, you should specify the warm keyword with the reload command. The warm reboot functionality allows a Cisco IOS image to reload without ROM monitor intervention. That is, read-write data is saved in RAM during a cold startup and restored during a warm reboot. Warm rebooting allows the router to reboot quicker than conventional rebooting (where control is transferred to ROM monitor and back to the image) because nothing is copied from flash to RAM.
Examples
The following example shows how to immediately reload the software on the router:
Router# reloadThe following example shows how to reload the software on the router in 10 minutes:
Router# reload in 10Router# Reload scheduled for 11:57:08 PDT Fri Apr 21 1996 (in 10 minutes)Proceed with reload? [confirm]The following example shows how to reload the software on the router at 1:00 p.m. today:
Router# reload at 13:00Router# Reload scheduled for 13:00:00 PDT Fri Apr 21 1996 (in 1 hour and 2 minutes)Proceed with reload? [confirm]The following example shows how to reload the software on the router on April 21 at 2:00 a.m.:
Router# reload at 02:00 apr 21Router# Reload scheduled for 02:00:00 PDT Sat Apr 21 1996 (in 38 hours and 9 minutes)Proceed with reload? [confirm]The following example shows how to cancel a pending reload:
Router# reload cancel%Reload cancelled.The following example shows how to perform a warm reboot at 4:00 today:
Router# reload warm at 4:00
The following example shows how to specify image verification via the /verify keyword before reloading an image onto the router:
Router# reload /verifyVerifying file integrity of bootflash:c7200-kboot-mz.121-8a.E%ERROR:Signature not found in file bootflash:c7200-kboot-mz.121-8a.E.Signature not present. Proceed with verify? [confirm]Verifying file disk0:c7200-js-mz ......................................................................................................................................Done!Embedded Hash MD5 :CFA258948C4ECE52085DCF428A426DCDComputed Hash MD5 :CFA258948C4ECE52085DCF428A426DCDCCO Hash MD5 :44A7B9BDDD9638128C35528466318183Signature VerifiedProceed with reload? [confirm]nRelated Commands
router bgp
To configure the Border Gateway Protocol (BGP) routing process, use the router bgp command in global configuration mode. To remove a BGP routing process, use the no form of this command.
router bgp autonomous-system-number
no router bgp autonomous-system-number
Syntax Description
Command Default
No BGP routing process is enabled by default.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
This command allows you to set up a distributed routing core that automatically guarantees the loop-free exchange of routing information between autonomous systems.
Prior to January 2009, BGP autonomous system numbers that were allocated to companies were 2-octet numbers in the range from 1 to 65535 as described in RFC 4271, A Border Gateway Protocol 4 (BGP-4). Due to increased demand for autonomous system numbers, the Internet Assigned Number Authority (IANA) will start in January 2009 to allocate four-octet autonomous system numbers in the range from 65536 to 4294967295. RFC 5396, Textual Representation of Autonomous System (AS) Numbers, documents three methods of representing autonomous system numbers. Cisco has implemented the following two methods:
•
•
For details about the third method of representing autonomous system numbers, see RFC 5396.
Asdot Only Autonomous System Number Formatting
In Cisco IOS Release 12.0(32)S12, 12.4(24)T, Cisco IOS XE Release 2.3, and later releases, the 4-octet (4-byte) autonomous system numbers are entered and displayed only in asdot notation, for example, 1.10 or 45000.64000. When using regular expressions to match 4-byte autonomous system numbers the asdot format includes a period which is a special character in regular expressions. A backslash must be entered before the period for example, 1\.14, to ensure the regular expression match does not fail. Table 21 shows the format in which 2-byte and 4-byte autonomous system numbers are configured, matched in regular expressions, and displayed in show command output in Cisco IOS images where only asdot formatting is available.
Asplain as Default Autonomous System Number Formatting
In Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases, the Cisco implementation of 4-byte autonomous system numbers uses asplain as the default display format for autonomous system numbers, but you can configure 4-byte autonomous system numbers in both the asplain and asdot format. In addition, the default format for matching 4-byte autonomous system numbers in regular expressions is asplain, so you must ensure that any regular expressions to match 4-byte autonomous system numbers are written in the asplain format. If you want to change the default show command output to display 4-byte autonomous system numbers in the asdot format, use the bgp asnotation dot command under router configuration mode. When the asdot format is enabled as the default, any regular expressions to match 4-byte autonomous system numbers must be written using the asdot format, or the regular expression match will fail. Table 22 and Table 23 show that although you can configure 4-byte autonomous system numbers in either asplain or asdot format, only one format is used to display show command output and control 4-byte autonomous system number matching for regular expressions, and the default is asplain format. To display 4-byte autonomous system numbers in show command output and to control matching for regular expressions in the asdot format, you must configure the bgp asnotation dot command. After enabling the bgp asnotation dot command, a hard reset must be initiated for all BGP sessions by entering the clear ip bgp * command.
Note
Reserved and Private Autonomous System Numbers
In Cisco IOS Release 12.0(32)S12, 12.0(32)SY8, 12.2(33)SRE, 12.2(33)SXI1, 12.4(24)T, Cisco IOS XE Release 2.3 and later releases, the Cisco implementation of BGP supports RFC 4893. RFC 4893 was developed to allow BGP to support a gradual transition from 2-byte autonomous system numbers to 4-byte autonomous system numbers. A new reserved (private) autonomous system number, 23456, was created by RFC 4893 and this number cannot be configured as an autonomous system number in the Cisco IOS CLI.
RFC 5398, Autonomous System (AS) Number Reservation for Documentation Use, describes new reserved autonomous system numbers for documentation purposes. Use of the reserved numbers allow configuration examples to be accurately documented and avoids conflict with production networks if these configurations are literally copied. The reserved numbers are documented in the IANA autonomous system number registry. Reserved 2-byte autonomous system numbers are in the contiguous block, 64496 to 64511 and reserved 4-byte autonomous system numbers are from 65536 to 65551 inclusive.
Private 2-byte autonomous system numbers are still valid in the range from 64512 to 65534 with 65535 being reserved for special use. Private autonomous system numbers can be used for internal routing domains but must be translated for traffic that is routed out to the Internet. BGP should not be configured to advertise private autonomous system numbers to external networks. Cisco IOS software does not remove private autonomous system numbers from routing updates by default. We recommend that ISPs filter private autonomous system numbers.
Note
Examples
The following example configures a BGP process for autonomous system 45000 and configures two external BGP neighbors in different autonomous systems using 2-byte autonomous system numbers:
router bgp 45000neighbor 192.168.1.2 remote-as 40000neighbor 192.168.3.2 remote-as 50000neighbor 192.168.3.2 description finance!address-family ipv4neighbor 192.168.1.2 activateneighbor 192.168.3.2 activateno auto-summaryno synchronizationnetwork 172.17.1.0 mask 255.255.255.0exit-address-familyThe following example configures a BGP process for autonomous system 65538 and configures two external BGP neighbors in different autonomous systems using 4-byte autonomous system numbers in asplain notation. This example is supported in Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases.
router bgp 65538neighbor 192.168.1.2 remote-as 65536neighbor 192.168.3.2 remote-as 65550neighbor 192.168.3.2 description finance!address-family ipv4neighbor 192.168.1.2 activateneighbor 192.168.3.2 activateno auto-summaryno synchronizationnetwork 172.17.1.0 mask 255.255.255.0exit-address-familyThe following example configures a BGP process for autonomous system 1.2 and configures two external BGP neighbors in different autonomous systems using 4-byte autonomous system numbers in asdot notation. This example is supported in Cisco IOS Release 12.0(32)SY8, 12.0(32)S12, 12.2(33)SRE, 12.2(33)SXI1, 12.4(24)T, and Cisco IOS XE Release 2.3, and later releases.
router bgp 1.2neighbor 192.168.1.2 remote-as 1.0neighbor 192.168.3.2 remote-as 1.14neighbor 192.168.3.2 description finance!address-family ipv4neighbor 192.168.1.2 activateneighbor 192.168.3.2 activateno auto-summaryno synchronizationnetwork 172.17.1.0 mask 255.255.255.0exit-address-familyRelated Commands
router eigrp
To configure the Enhanced Interior Gateway Routing Protocol (EIGRP) routing process, use the router eigrp command in global configuration mode. To remove an EIGRP routing process, use the no form of this command.
router eigrp {autonomous-system-number | virtual-instance-name}
no router eigrp {autonomous-system-number | virtual-instance-name}
Syntax Description
Command Default
No EIGRP processes are configured.
Command Modes
Global configuration (config)
Command History
Usage Guidelines
Configuring the router eigrp command with the autonomous-system-number argument creates an EIGRP configuration referred to as autonomous system (AS) configuration. An EIGRP AS configuration creates an EIGRP routing instance that can be used for tagging routing information.
Configuring the router eigrp command with the virtual-instance-name argument creates an EIGRP configuration referred to as EIGRP named configuration. An EIGRP named configuration does not create an EIGRP routing instance by itself. An EIGRP named configuration is a base configuration that is required to define address-family configurations under it that are used for routing.
Examples
The following example configures EIGRP process 109:
Router(config)# router eigrp 109The following example configures an EIGRP address-family routing process and assigns it the name "virtual-name":
Router(config)# router eigrp virtual-nameRelated Commands
router isis
To enable the Intermediate System-to-Intermediate System (IS-IS) routing protocol and to specify an IS-IS process, use the router isis command in global configuration mode. To disable IS-IS routing, use the no form of this command.
router isis area-tag
no router isis area-tag
Syntax Description
Defaults
This command is disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
This command is used to enable routing for an area. An appropriate network entity title (NET) must be configured to specify the area address of the area and system ID of the router. Routing must be enabled on one or more interfaces before adjacencies may be established and dynamic routing is possible.
If you have IS-IS running and at least one International Standards Organization Interior Gateway Routing Protocol (ISO-IGRP) process, the IS-IS process and the ISO-IGRP process cannot both be configured without an area tag. The null tag can be used by only one process. If you run ISO-IGRP and IS-IS, a null tag can be used for IS-IS, but not for ISO-IGRP at the same time. However, each area in an IS-IS multiarea configuration should have a nonnull area tag to facilitate identification of the area.
You can configure only one IS-IS routing process to perform Level 2 (interarea) routing. You can configure this process to perform Level 1 (intra-area) routing at the same time. You can configure up to 29 additional processes as Level 1-only processes. If Level 2 routing is configured on any process, all additional processes are automatically configured as Level 1.
An interface cannot be part of more than one area, except in the case where the associated routing process is performing both Level 1 and Level 2 routing. On media such as WAN media where subinterfaces are supported, different subinterfaces could be configured for different areas.
If Level 2 routing is not desired for a given area, use the is-type command to remove Level 2. Level 2 routing can then be enabled on some other router instance.
Explicit redistribution between IS-IS instances is prohibited (prevented by the parser). In other words, you cannot issue a redistribute isis area-tag command in the context of another IS-IS router instance (router isis area-tag). Redistribution from any other routing protocol into a particular area is possible, and is configured per router instance, as in Cisco IOS software Release 12.0, using the redistribute and route map commands. By default, redistribution is into Level 2.
If multiple Level 1 areas are defined, the Target Address Resolution Protocol (TARP) behaves in the following way:
•
•
•
•
•
•
•
After you enter the router isis command, you can enter the maximum number of paths. There can be from 1 to 32 paths.
Examples
The following example configures IS-IS for IP routing, with system ID 0000.0000.0002 and area ID 01.0001, and enables IS-IS to form adjacencies on Ethernet interface 0 and serial interface 0. The IP prefix assigned to Ethernet interface 0 will be advertised to other IS-IS routers.
router isis tag1net 01.0001.0000.0000.0002is-type level-1!interface ethernet 0ip address 10.1.1.1 255.255.255.0ip router isis!interface serial 0ip unnumbered ethernet0ip router isisThe following example starts IS-IS routing with the optional area-tag argument, where CISCO is the value for the area-tag argument:
router isis CISCOThe following example specifies IS-IS as an IP routing protocol for a process named Finance, and specifies that the Finance process will be routed on Ethernet interface 0 and serial interface 0:
router isis Financenet 49.0001.aaaa.aaaa.aaaa.00interface Ethernet 0ip router isis Financeinterface serial 0ip router isis FinanceThe following example shows usage of the maximum-paths option:
router isismaximum-paths?20Related Commands
router ospf
To configure an Open Shortest Path First (OSPF) routing process, use the router ospf command in global configuration mode. To terminate an OSPF routing process, use the no form of this command.
router ospf process-id [vrf vpn-name]
no router ospf process-id [vrf vpn-name]
Syntax Description
Defaults
No OSPF routing process is defined.
Command Modes
Global configuration
Command History
Usage Guidelines
You can specify multiple OSPF routing processes in each router.
After you enter the router ospf command, you can enter the maximum number of paths. There can be from 1 to 32 paths.
Examples
The following example configures an OSPF routing process and assign a process number of 109:
Router(config)# router ospf 109This example shows a basic OSPF configuration using the router ospf command to configure OSPF VRF instance processes for the VRFs first, second, and third:
Router> enableRouter# configure terminalRouter(config)# router ospf 12 vrf firstRouter(config)# router ospf 13 vrf secondRouter(config)# router ospf 14 vrf thirdRouter(config)# exitThe following example shows usage of the maximum-paths option:
Router> enableRouter# configure terminalRouter(config)# router ospfRouter(config-router)# maximum-paths?Router(config-router)# 20Router(config-router)# exitRelated Commands
network area
Defines the interfaces on which OSPF runs and defines the area ID for those interfaces.
route-target
To create a route-target extended community for a Virtual Private Network (VPN) routing and forwarding (VRF) instance, use the route-target command in VRF configuration submode. To disable the configuration of a route-target community option, use the no form of this command.
route-target {import | export | both} route-target-ext-community
no route-target {import | export | both} route-target-ext-community
Syntax Description
Command Default
A VRF has no route-target extended community attributes associated with it until specified by the route-target command.
Command Modes
VRF configuration submode (config-vrf)
Command History
Usage Guidelines
The route-target command creates lists of import and export route target extended communities for the specified VRF. Enter the command one time for each target community. Learned routes that carry a specific route-target extended community are imported into all VRFs configured with that extended community as an import route target. Routes learned from a VRF site (for example, by Border Gateway Protocol (BGP), Routing Information Protocol (RIP), or static route configuration) contain export route targets for extended communities configured for the VRF added as route attributes to control the VRFs into which the route is imported.
The route target specifies a target VPN extended community. Like a route-distinguisher, an extended community is composed of either an autonomous system number and an arbitrary number or an IP address and an arbitrary number. You can enter the numbers in either of these formats:
•
For example, 101:3.•
For example, 192.168.122.15:1.In Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases, the Cisco implementation of 4-byte autonomous system numbers uses asplain—65538 for example—as the default regular expression match and output display format for autonomous system numbers, but you can configure 4-byte autonomous system numbers in both the asplain format and the asdot format as described in RFC 5396. To change the default regular expression match and output display of 4-byte autonomous system numbers to asdot format, use the bgp asnotation dot command followed by the clear ip bgp * command to perform a hard reset of all current BGP sessions.
In Cisco IOS Release 12.0(32)S12, 12.4(24)T, and Cisco IOS XE Release 2.3, the Cisco implementation of 4-byte autonomous system numbers uses asdot—1.2 for example—as the only configuration format, regular expression match, and output display, with no asplain support.
Examples
The following example shows how to configure route-target extended community attributes for a VRF in IPv4. The result of the command sequence is that VRF named vrf1 has two export extended communities (1000:1 and 1000:2) and two import extended communities (1000:1 and 10.27.0.130:200):
ip vrf vrf1route-target both 1000:1route-target export 1000:2route-target import 10.27.0.130:200The following example shows how to configure route-target extended community attributes for a VRF that includes IPv4 and IPv6 address families:
vrf definition site1rd 1000:1address-family ipv4route-target export 100:1route-target import 100:1address-family ipv6route-target export 200:1route-target import 200:1The following example available in Cisco IOS Release 12.0(32)SY8, 12.0(33)S3, 12.2(33)SRE, 12.2(33)SXI1, Cisco IOS XE Release 2.4, and later releases, shows how to create a VRF with a route-target that uses a 4-byte autonomous system number in asplain format—65537—and how to set the route-target to extended community value 65537:100 for routes that are permitted by the route map.
ip vrf vpn_redrd 64500:100route-target both 65537:100exitroute-map red_map permit 10set extcommunity rt 65537:100endAfter the configuration is completed, use the show route-map command to verify that the extended community is set to the route target containing the 4-byte autonomous system number of 65537.
Router# show route-map red_maproute-map red_map, permit, sequence 10Match clauses:Set clauses:extended community RT:65537:100Policy routing matches: 0 packets, 0 bytesThe following example available in Cisco IOS Release 12.0(32)SY8, Cisco IOS Release 12.0(32)S12, 12.2(33)SRE, 12.2(33)SXI1, 12.4(24)T, Cisco IOS XE Release 2.3, and later releases, shows how to create a VRF with a route-target that uses a 4-byte autonomous system number in asdot format—1.1—and how to set the route-target to extended community value 1.1:100 for routes that are permitted by the route map.
ip vrf vpn_redrd 64500:100route-target both 1.1:100exitroute-map red_map permit 10set extcommunity rt 1.1:100endRelated Commands
