For feedback and comments:
documentation.feedback@alcatel-lucent.com

Table of Contents Previous Next PDF


CLI Usage
In This Chapter
This chapter provides information about using the command-line interface (CLI).
Topics in this chapter include:
CLI Structure
Alcatel-Lucent’s SR OS CLI is a command-driven interface accessible through the console, Telnet and secure shell (SSH). The CLI can be used for configuration and management of SR OS routers.
The SR OS CLI command tree is a hierarchical inverted tree. At the highest level is the ROOT level. Below this level are other tree levels with the major command groups; for example, configuration commands and show commands are levels below ROOT.
The CLI is organized so related commands with the same scope are at the same level or in the same context. Sublevels or subcontexts have related commands with a more refined scope.
Figure 1 and Figure 2 examples display the major contexts for router configuration, and it is not a definitive list.
Figure 1: Root Commands
Figure 2: Operational Root Commands
Navigating in the CLI
The following sections describe additional navigational and syntax information.
 
CLI Contexts
Use the CLI to access, configure, and manage Alcatel-Lucent’s SR OS routers. CLI commands are entered at the command line prompt. Access to specific CLI commands is controlled by the permissions set by your system administrator. Entering a CLI command makes navigation possible from one command context (or level) to another.
When you initially enter a CLI session, you are in the ROOT context. Navigate to another level by entering the name of successively lower contexts. For example, enter either the configure or show commands at the ROOT context to navigate to the config or show context, respectively. For example, at the command prompt (#), enter config. The active context displays in the command prompt.
A:ALA-12# config
A:ALA-12>config#
In a given CLI context, enter commands at that context level by simply entering the text. It is also possible to include a command in a lower context as long as the command is formatted in the proper command and parameter syntax.
The following example shows two methods to navigate to a service SDP ingress level:
Method 1:
A:ALA-12# configure service epipe 6 spoke-sdp 2:6 ingress
*A:ALA-12>config>service>epipe>spoke-sdp>ingress#
Method 2:
A:ALA-12>config# service
A:ALA-12>config>service# epipe 6
*A:ALA-12>config>service>epipe# spoke-sdp 2:6
*A:ALA-12>config>service>epipe>spoke-sdp# ingress
*A:ALA-12>config>service>epipe>spoke-sdp>ingress#
The CLI returns an error message when the syntax is incorrect.
*A:ALA-12>config# rooter
Error: Bad command.
 
Basic CLI Commands
The console control commands are the commands that are used for navigating within the CLI and displaying information about the console session. Most of these commands are implemented as global commands. They can be entered at any level in the CLI hierarchy with the exception of the password command which must be entered at the ROOT level. The console control commands are listed in Table 3.
 
The list of all system global commands is displayed by entering help globals in the CLI. For example:
*A:ALA-12>config>service# help globals
back            - Go back a level in the command tree
      echo            - Echo the text that is typed in
      enable-admin    - Enable the user to become a system administrator
      exec            - Execute a file - use -echo to show the commands and
                        prompts on the screen
      exit            - Exit to intermediate mode - use option all to exit to
                        root prompt
      help            - Display help
      history         - Show command history
      info            - Display configuration for the present node
      logout          - Log off this system
      mrinfo          - Request multicast router information
      mstat           - Trace multicast path from a source to a receiver and
                        display multicast packet rate and loss information
      mtrace          - Trace multicast path from a source to a receiver
      oam             + OAM Test Suite
      ping            - Verify the reachability of a remote host
      pwc             - Show the present working context
      sleep           - Sleep for specified number of seconds
      ssh             - SSH to a host
      telnet          - Telnet to a host
      traceroute      - Determine the route to a destination address
      tree            - Display command tree structure from the context of
                        execution
      write           - Write text to another user
*A:ALA-12>config>service#
Table 4 lists describes command syntax symbols.
sdp sdp-id [{gre|mpls}]
Commands in bold indicate commands and keywords.
Commands in italics indicate command options.
 
CLI Environment Commands
The CLI environment commands are found in the root>environment context of the CLI tree and controls session preferences for a single CLI session. The CLI environment commands are listed in Table 5.
Enables or disables the use of a create parameter check.
 
CLI Monitor Commands
Monitor commands display specified statistical information related to the monitor subject (such as filter, port, QoS, router, service, and VRRP) at a configurable interval until a count is reached. The CLI monitor commands are found in the root>monitor context of the CLI tree.
The monitor command output displays a snapshot of the current statistics. The output display refreshes with subsequent statistical information at each configured interval and is displayed as a delta to the previous display.
The <Ctrl-c> keystroke interrupts a monitoring process. Monitor command configurations cannot be saved. You must enter the command for each monitoring session. Note that if the maximum limits are configured, you can monitor the statistical information for a maximum of 60 * 999 sec ~ 1000 minutes.
The CLI monitor command contexts are listed in Table 6.
Getting Help in the CLI
The help system commands and the? key display different types of help in the CLI. Table 7 lists the different help commands.
 
The tree and tree detail system commands are help commands useful when searching for a command in a lower-level context.
The following example displays a partial list of the tree and tree detail command output entered for the router node.
The CLI Command Prompt
By default, the CLI command prompt indicates the device being accessed and the current CLI context. For example, the prompt: A:ALA-1>config>router>if# indicates the active context, the user is on the device with hostname ALA-1 in the configure>router>interface context. In the prompt, the separator used between contexts is the “> symbol.
At the end of the prompt, there is either a pound sign (“#) or a dollar sign (“$). A “#” at the end of the prompt indicates the context is an existing context. A “$” at the end of the prompt indicates the context has been newly created. New contexts are newly created for logical entities when the user first navigates into the context.
Since there can be a large number of sublevels in the CLI, the environment command reduced-prompt no of nodes in prompt allows the user to control the number of levels displayed in the prompt.
All special characters (#, $, etc.) must be enclosed within double quotes, otherwise it is seen as a comment character and all characters on the command line following the # are ignored. For example:
*A:ALA-1>config>router# interface "primary#1"
When changes are made to the configuration file a “*” appears in the prompt string (*A:ALA-1) indicating that the changes have not been saved. When an admin save command is executed the “*” disappears. This behavior is controlled in the saved-ind-prompt command in the environment context.
Displaying Configuration Contexts
The info and info detail commands display configuration for the current level. The info command displays non-default configurations. The info detail command displays the entire configuration for the current level, including defaults. The following example shows the output that displays using the info command and the output that displays using the info detail command.
*A:ALA-1>config>router# interface system
*A:ALA-1>config>router>if# info
----------------------------------------------
            address 10.10.0.1/32
----------------------------------------------
*A:ALA-1>config>router>if# 
 
 
*A:ALA-1>config>router>if# info detail
----------------------------------------------
            address 10.10.10.103/32 broadcast host-ones
            no description
            no arp-timeout
            no allow-directed-broadcasts
            tos-marking-state trusted
            no local-proxy-arp
            no proxy-arp
            icmp
                mask-reply
                redirects 100 10
                unreachables 100 10
                ttl-expired 100 10
            exit
            no mac
            no ntp-broadcast
            no cflowd
            no shutdown
----------------------------------------------
*A:ALA-1>config>router>if#
EXEC Files
The exec command allows you to execute a text file of CLI commands as if it were typed at a console device.
The exec command and the associated exec files can be used to conveniently execute a number of commands that are always executed together in the same order. For example, an exec command can be used by a user to define a set of commonly used standard command aliases.
The echo command can be used within an exec command file to display messages on screen while the file executes.
CLI Script Control
SR OS provides centralized script management for CLI scripts that are used by CRON and the Event Handling System (EHS). A set of script policies and script objects can be configured to control the following items and more:
If the scripts are located on local compact flash devices then the user must ensure that the scripts are on the compact flash devices of both CPMs so that operation of EHS continues as expected if a CPM switchover occurs.
A single script can be executing at one time. A table (SNMP smRunTable in the DISMAN-SCRIPT-MIB) is used as both an input queue of scripts waiting to be executed as well as for storage of records for completed scripts. If the input queue is full then the script request is discarded.
Entering CLI Commands
 
Command Completion
The CLI supports both command abbreviation and command completion. If the keystrokes entered are enough to match a valid command, the CLI displays the remainder of the command syntax when the <Tab> key or space bar is pressed. When typing a command, the <Tab> key or space bar invokes auto-completion. If the keystrokes entered are definite, auto-completion will complete the command. If the letters are not sufficient to identify a specific command, pressing the <Tab> key or space bar will display commands matching the letters entered.
System commands are available in all CLI context levels.
 
Unordered Parameters
In a given context, the CLI accepts command parameters in any order as long as the command is formatted in the proper command keyword and parameter syntax. Command completion will still work as long as enough recognizable characters of the command are entered.
The following output shows different static-route command syntax and an example of the command usage.
*A:ALA-12>config>router# static-route ?
- [no] static-route {<ip-prefix/mask>|<ip-prefix> <netmask>} [preference <preference>]
[metric <metric>] [tag <tag>] [enable|disable] next-hop <ip-address|ip-int-name>
- [no] static-route {<ip-prefix/mask>|<ip-prefix> <netmask>} [preference <preference>]
[metric <metric>] [tag <tag>] [enable|disable] indirect <ip-address> [ldp
[disallow-igp]]
- [no] static-route {<ip-prefix/mask>|<ip-prefix> <netmask>} [preference <preference>]
[metric <metric>] [tag <tag>] [enable|disable] black-hole
*A:ALA-12>config>router# static-route preference 1 10.1.0.0/16 metric
 
Editing Keystrokes
When entering a command, special keystrokes allow for editing of the command. Table 8 lists the command editing keystrokes.
 
 
Absolute Paths
CLI commands can be executed in any context by specifying the full path from the CLI root. To execute an out-of-context command enter a forward slash “/” or backward slash “\ at the beginning of the command line. The forward slash “/” or backward slash “\” cannot be used with the environment alias command.The commands are interpreted as absolute path. Spaces between the slash and the first command will return an error. Commands that are already global (such as ping, telnet, exit, back, etc.) cannot be executed with a forward slash “/” or backward slash “\ at the beginning of the command line.
*A:ALA-12# configure router 
*A:ALA-12>config>router# interface system address 1.2.3.4 
*A:ALA-12>config>router# /admin save 
*A:ALA-12>config>router# \clear router interface 
*A:ALA-12>config>router# 
The command may or may not change the current context depending on whether or not it is a leaf command. This is the same behavior the CLI performs when CLI commands are entered individually, for example:
*A:ALA-12# admin 
*A:ALA-12>admin# save
or
*A:ALA-12# admin save
*A:ALA-12# 
 
Note that an absolute path command behaves the same as manually entering a series of command line instructions and parameters.
For example, beginning in an IES context service ID 4 (IES 4),
CLI Syntax: config>service>ies> /clear card 1
behaves the same as the following series of commands.
Example: config>service>ies>exit all
clear card 1
configure service ies 4
(returns you to your starting point)
config>service>ies
If the command takes you to a different context, the following occurs:
CLI Syntax: config>service>ies>/configure service ies 5 create
becomes
Example: config>service>ies>exit all
configure service vpls 5 create
config>service>vpls>
 
History
The CLI maintains a history of the most recently entered commands. The history command displays the most recently entered CLI commands.
*A:ALA-1# history 
   1 environment terminal length 48 
   2 environment no create 
   3 show version 
   4 configure port 1/1/1 
   5 info 
   6 \configure router isis 
   7 \port 1/1/2
   8 con port 1/1/2
   9 \con port 1/1/2
  10 \configure router bgp 
  11 info 
  12 \configure system login-control 
  13 info 
  14 history 
  15 show version 
  16 history 
*A:ALA-1# !3
Entering Numerical Ranges
The SR OS CLI allows the use of a single numerical range as an argument in the command line. A range in a CLI command is limited to positive integers and is denoted with two numbers enclosed in square brackets with two periods (“..”) between the numbers:
where x and y are positive integers and y-x is less than 1000.
For example, it is possible to shut down ports 1 through 10 in Slot 1 on MDA 1. A port is denoted with “slot/mda/port”, where slot is the slot number, mda is the MDA number and port is the port number. To shut down ports 1 through 10 on Slot 1 and MDA 1, the command is entered as follows:
configure port 1/1/[1..10] shutdown
<Ctrl-C> can be used to abort the execution of a range command.
Specifying a range in the CLI does have limitations. These limitations are summarized in Table 9.
In the CLI, enclosing a string in quotation marks (“string”) causes the string to be treated literally and as a single parameter. For example, several commands in the CLI allow the configuration of a descriptive string. If the string is more than one word and includes spaces, it must be enclosed in quotation marks. A range that is enclosed in quotes is also treated literally. For example,
Pipe/Match
The SR OS supports the pipe feature to search one or more files for a given character string or pattern.
Note: When using the pipe/match command the variables and attributes must be spelled correctly. The attributes following the command and must come before the expression/pattern. The following displays examples of the pipe/match command to complete different tasks:
admin display-config | match “echo” > cf1:\test\echo_list.txt
admin display-config | match invert-match “echo”
admin display-config | match max-count 1 “vpls”
admin display-config | match post-lines 999999 interface
admin display-config | match interface | count
Command syntax:
match pattern context {parents | children | all} [ignore-case] [max-count lines-count] [expression]
match pattern [ignore-case] [invert-match] [pre-lines pre-lines] [post-lines lines-count] [max-count lines-count] [expression]
where:
pattern         string or regular expression
context         keyword:  display context associated with the matching line
parents         keyword:  display parent context information
children        keyword:  display child context information
all             keyword:  display both parent and child context information
ignore-case     keyword
max-count       keyword:  display only a specific number of instances of matching lines
lines-count     1 — 2147483647
expression      keyword:  pattern is interpreted as a regular expression
invert-match    keyword
pre-lines       keyword:  display some lines prior to the matching line
pre-lines       0 — 100
post-lines      keyword:  display some lines after the matching line
lines-count     1 — 2147483647
 
 
For example:
A:Dut-C# show log log-id 98 | match ignore-case "sdp bind"
"Status of SDP Bind 101:1002 in service 1001 (customer 1) changed to admin=up oper=up flags="
"Processing of a SDP state change event is finished and the status of all affected SDP Bindings on SDP 101 has been updated."
 
 
A:Dut-C# show log log-id 98 | match max-count 1 "service 1001"
"Status of service 1001 (customer 1) changed to administrative state: up, operational state: up"
 
 
 
A:Dut-C# admin display-config | match post-lines 5 max-count 2 expression "OSPF.*Config"
echo "OSPFv2 Configuration"
#--------------------------------------------------
        ospf
            timers
                spf-wait 1000 1000 1000
            exit
echo "OSPFv2 (Inst: 1) Configuration"
#--------------------------------------------------
        ospf 1
            asbr
            router-id 1.0.0.1
            export "testall"
*A:Dut# admin display-config | match debug_mirror
            profile "debug_mirror"
 
 
*A:Dut# admin display-config | match context parent debug_mirror
#--------------------------------------------------
    system
        security
            profile "debug_mirror"
 
 
*A:Dut# admin display-config | match context all debug_mirror
#--------------------------------------------------
    system
        security
            profile "debug_mirror"
                default-action deny-all
                entry 10
                exit
 
 
*A:Dut# show log event-control | match ignore-case pre-lines 10 SyncStatus
L  2016 tmnxLogOnlyEventThrottled        MA  gen          0           0
MCPATH:
   2001 tmnxMcPathSrcGrpBlkHole          MI  gen          0           0
   2002 tmnxMcPathSrcGrpBlkHoleClear     MI  gen          0           0
   2003 tmnxMcPathAvailBwLimitReached    MI  gen          0           0
   2004 tmnxMcPathAvailBwValWithinRange  MI  gen          0           0
MC_REDUNDANCY:
   2001 tmnxMcRedundancyPeerStateChanged WA  gen          0           0
   2002 tmnxMcRedundancyMismatchDetected WA  gen          0           0
   2003 tmnxMcRedundancyMismatchResolved WA  gen          0           0
   2004 tmnxMcPeerSyncStatusChanged      WA  gen          0           0
Table 10 describes regular expression symbols and interpretation (similar to what is used for route policy regexp matching). Table 11 describes special characters.
Pipe/Count
SR OS supports a pipe/count command (...| count) that provides a count of the number of lines that would have otherwise been displayed. The pipe/count command is particularly useful when used in conjunction with the pipe/match command in order to count the number of output lines that match a specified pattern.
For example:
*A:dut-c# show service service-using vprn
 
===============================================================================
Services [vprn]
===============================================================================
ServiceId    Type      Adm  Opr  CustomerId Service Name
-------------------------------------------------------------------------------
1            VPRN      Down Down 1
44           VPRN      Up   Up   1
100          VPRN      Down Down 1
102          VPRN      Up   Up   1
235          VPRN      Down Down 1
1000         VPRN      Down Down 1000
-------------------------------------------------------------------------------
Matching Services : 6
-------------------------------------------------------------------------------
===============================================================================
*A:dut-c# show service service-using vprn | match Down | count
Count: 4 lines
*A:dut-c#
 
Redirection
The SR OS upports redirection (“>”) which allows the operator to store the output of a CLI command as a local or remote file. Redirection of output can be used to automatically store results of commands in files (both local and remote).
‘ping <customer_ip> > cf3cf1:/ping/result.txt’
‘ping <customer_ip> > ftp://ron@ftp.alcatel.com/ping/result.txt’
In some cases only part of the output might be applicable. The pipe/match and redirection commands can be combined:
ping 10.0.0.1 | match expression “time.\d+” > cf3cf1:/ping/time.txt
This records only the RTT portion (including the word “time”).
VI Editor
Note that “vi”sual editor (vi) is a file editor that can edit any ASCII file. This includes configuration, exec files, BOF and any other ASCII file on the system.
VT100 terminal mode is supported. However, if a different terminal mode is configured there will no noticeable negative effect.
When a configuration file is changed, a validation check is executed to see if the user is allowed to view or perform configuration changes. When a user is modifying the configuration file using the vi editor these checks do not occur. Because of this, the vi editor is only available to a user with administrator privileges. Should others require access to the vi editor, their profile must be modified allow the access. Access permission for the file directory where the file resides must be performed before a user can opens, read, or write a file processing command. If a user does not have permission to access the directory then the operation must be denied.
When opening a file, a resource check verifies that sufficient resources are available to process that file. If there are not enough resources, then the operation is denied and the operator is informed of that event.
Multiple sessions are allowed and are limited only by the memory resources available on the node.
 
Summary of vi Commands
The vi editor operates in two modes:
In the this mode, each character entered is a command that does something to the text file being edited; a character typed in the command mode may even cause the vi editor to enter the insert mode.
In the insert mode, every character typed is added to the text in the file. Hitting the Esc (Escape) key turns off the insert mode.
 
Using the vi Commands
Use the following commands to start and end vi edit sessions, move around in a file, enter new text, modify, move, and delete old text, as well as read from and write to files other files. Although there are numerous vi commands, only a few are usually sufficient to vi users. The following tables list vi commands.
 
Specify a buffer to be used any of the commands using buffers. Follow the " character with a letter or a number, which corresponds to a buffer.
Deletes text. “dd” deletes the current line. A count deletes that many lines. Whatever is deleted is placed into the buffer specified with the " command. If no buffer is specified, then the general buffer is used.
Yank text, putting the result into a buffer. yy yanks the current line. Entering a number yanks that many lines. The buffer can be specified with the " command. If no buffer is specified, then the general buffer is used.
 
 
 
Redraw the screen with the following options. z<return> puts the current line on the top of the screen; z. puts the current line on the center of the screen; and z- puts the current line on the bottom of the screen. If you specify a count before the z command, it changes the current line to the line specified. For example, 16z. puts line 16 on the center of the screen.
 
Table 16: Replacing Text
Change until cc changes the current line. A count changes that many lines.
 
 
Repeat the last search given by / or ?, except in the reverse direction.
Search the current line backwards for the character specified after the T command, and move to the column after the if it's found.
Search the current line for the character specified after the f command. If found, move the cursor to the position.
Search the current line for the character specified after the t command, and move to the column before the character if it's found.
 
 
Shift the lines up to where to the left by one shiftwidth. << shifts the current line to the left, and can be specified with a count.
Shift the lines up to where to the right by one shiftwidth. >> shifts the current line to the right, and can be specified with a count.
 
 
 
EX Commands
The vi editor is built upon another editor, called EX. The EX editor only edits by line. From the vi editor you use the : command to start entering an EX command. This list given here is not complete, but the commands given are the more commonly used. If more than one line is to be modified by certain commands (such as :s and :w ) the range must be specified before the command. For example, to substitute lines 3 through 15, the command is :3,15s/from/this/g.
 
Table 21: EX commands  
Abbreviation. If a word is typed in vi corresponding to string1, the editor automatically inserts the corresponding words. For example, the abbreviation :ab usa United States of America would insert the words, United States of America whenever the word usa is typed in.
Quit vi. If there have been changes made, the editor will issue a warning message.
Quit vi without saving changes.
Sets some customizing options to vi and EX. The :set all command gives all the possible options.
Configuration Rollback
The Configuration Rollback feature provides the ability to “undo” configuration and reverts back to previous router configuration states while minimizing impacts to services.
This feature gives the operator better control and visibility over the router configurations and reduces operational risk while increasing flexibility and providing powerful recovery options.
Configuration Rollback is useful in cases where configuration changes are made but the operator later decides to not keep the changes (for example, experimentation or when problems are identified in the configuration during actual network operation).
The advantage of this feature are the following:
With the rollback feature, the operator can smoothly revert to previous configurations.
Configuration parameters that changed (or items that changed configuration have dependencies on) are first removed (revert to default), and the previous values are then restored (can be briefly service impacting in changed areas).
A history of changes is preserved (checkpoint ids) that allows rollback to different points, as well as examination of changes made as shown in Figure 3.
Figure 3: Rollback Operation
 
Feature Behavior
The following list describes detailed behavior and CLI usage of the rollback feature:
admin>rollback# save [comment <comment-string>]
comment-string: an 255 char comment associated with the checkpoint
file-url.rb    <--- latest rollback file
file-url.rb.1
file-url.rb.9  <--- oldest rollback file
When a rollback save is executed, the system shifts the file suffix of all the previous checkpoints by 1 (new id = old id + 1). If there are already as many checkpoint files as the maximum number supported then the last checkpoint file is deleted.
The location and name of the rollback checkpoint files is configurable to be local (on compact flash) or remote. The file-url must not contain a suffix (just a path/directory + filename). The suffix for rollback checkpoint files is “.rb” and is automatically appended to rollback checkpoint files.
config>system>rollback# rollback-location <file-url>
admin>redundancy# rollback-sync
Note: The automatic sync only causes the ONE new checkpoint file to be copied to both CFs (the other 9 checkpoints are not automatically copied from active to standby but that can be done manually with admin red rollback-sync).
config>redundancy# [no] rollback-sync
config red sync {boot-env|config}” and “admin red sync {boot-env|config}” do not apply to rollback checkpoint files. These commands do not manually or automatically sync rollback checkpoint files. The dedicated rollback-sync commands must be used to sync rollback checkpoint files.
admin>rollback# delete {latest-rb|<checkpoint-id>}
As shown in Figure 4, support for rolling back to a previous configuration (a saved rollback checkpoint) with minimal impact on services. The previous configuration will be loaded and take operational effect:
admin>rollback# revert [latest-rb|<checkpoint-id>]
Figure 4: Configuration Rollback
The boot-good-exec or bad-exec are not automatically executed after a rollback.
If the currently active config contains configure port 5/1/1 dwdm tdcm dispersion -1000 and the rollback checkpoint contains configure port 5/1/1 dwdm tdcm dispersion -1010, then the operational dispersion will transition from -1000, to 0 and then back to -1010 for port 5/1/1 which will cause a traffic interruption.
a rollback is not guaranteed to work if hardware was removed or changed (for example, IOM was removed, or MDA was swapped for a different MDA type).
the SR | SS capability of a card (configure card capability sr|ess)
Rollback is supported even after an admin reboot is performed (or changes the primary config in the bof is changed and an admin reboot is performed). Admin reboot does not “break the chain” for rollback.
Lawful Intercept configuration under the config>li branch is not affected by a rollback or rescue. LI configuration is not saved in the rollback checkpoint or rescue file, and a rollback revert does not touch any config under the config>li branch.
If max-nbr-mac-addr is reduced as part of the revert and the number of mac addresses in the forwarding database is greater than the max-nbr-mac-addr, then the rollback is aborted (before any actions are taken) and an informative error message is provided. The operator must take actions to remove the mac addresses if they wish to proceed with the rollback.
If a force-switchover command (for example, tools perform service id 1 endpoint "x" force-switchover spoke-sdp-fec 1) has been applied to a spoke-sdp-fec of a dynamic multi-segment pseudo wire, and a rollback revert needs to change the admin state of the spoke-sdp-fec (for example, to modify spoke-sdp-fec parameters that may be dependant on admin state), then the rollback revert will automatically remove the force-switchover and the node will revert to whatever is the best spoke-sdp in the redundant set.
Configuration changes that require a shutdown and then no-shutdown to be done by an operator in order to take operational effect also need this manual shut/no-shut to be performed by the operator in order to take operational effect after a rollback if the rollback changes those configuration items. Some examples include:
Configuration changes to an msap-policy that normally requires a tools perform subscriber-mgmt eval-msap command to take operational effect on subscribers that are already active. Rollback will change the msap-policy configuration, but if it is required to have the configuration changes applied to the active subscribers then the operator will have to run the eval-msap tools command.
Any uncommitted changes (that is, the begin command was entered, some changes made, but the commit command was never entered) in the following areas will be lost/cleared when a rollback revert is initiated:
Some card and mda commands require a reboot, remove or rebuild of an entire card or MDA. When these commands need to be executed as part of a rollback, the impacted cards/mdas will be listed in a warning and the operator will be prompted with a single y/n prompt to decide whether to proceed or not. This prompting will not occur for a rollback initiated via SNMP, nor if the operator uses the now keyword with the rollback revert command. Some examples of card and mda commands that may cause a prompt are:
 
Rollback and SNMP
SR OS has SNMP support for Rollback status and control. See the TIMETRA-SYSTEM-MIB for details (for example, items such as tmnxSysRollbackStarted).
When the SR OS router is doing a rollback revert, SNMP managers will see a tmnxSysRollbackStarted trap, then a rapid set of “config change” traps, and then finally, the tmnxSysRollbackStatusChange trap.
During the period when an SR OS router is processing a rollback revert, both CLI commands (from other users) and SNMP commands will continue to be processed.
 
Rescue Configuration
A special rescue configuration checkpoint can be created that an operator can rollback revert to at any time. The rescue configuration has its own keyword (rescue) and does not use the same rolling suffix indices as the normal rollback checkpoints. This allows the operator to easily return to the rescue configuration state without having to consider a checkpoint index, and ensures that the rescue checkpoint is always available (does not roll off the bottom of the list of checkpoints).
The operator should define a basic rescue configuration that is known to work and give correct management access to the node.
The location and filename of the rescue file are configurable. SR-OS appends an “.rc” suffix to the specified rescue filename.
 
Operational Guidelines
The following points offer some operational guidance on the usage of rollback.
Both admin save and rollback save should be performed periodically:
Use admin save to backup a complete configuration file that can be used during router reboot.
Use rollback-save to create a rollback checkpoint.
A new rescue-save must be created when hardware is changed.
Do not continue to repeat the rollback save, rollback save, rollback save over the course of weeks/months without also doing executing an occasional admin save. In a serious situation, use one of the saved configs to use as the primary config for an admin reboot.
Software Upgrade: It is recommended to create a Rollback Checkpoint (admin rollback save), in addition to saving the configuration (admin save), after an upgrade has been performed and the system is operating as expected. This will ensure a good checkpoint fully compatible with the new release is available at a point shortly after the upgrade.
When a new backup CPM is commissioned, the user execute the admin redundancy rollback-sync command to copy the entire set of rollback files from the active CPM cf to the new standby CPM cf. If the operator wants the system to automatically copy new rollback checkpoints to both cfs whenever a new checkpoint is created, then the config redundancy rollback-sync should be configured.
If a warning prompt (y/n) is displayed when a rollback revert is initiated, it is highly suggested to respond no to the warning prompt the first time, save a rollback checkpoint before attempting this rollback revert, and then executing the revert again and responding yes. If the rollback encounters problems then a revert to the saved checkpoint can be used to go back to the initial configuration state.
 
 
Transactional Configuration
Transactional configuration allows an operator to edit a candidate configuration (a set of configuration changes) without actually causing operational changes in the router (the active or operational configuration). Once the candidate configuration is complete the operator can explicitly commit the changes and cause the entire new configuration to become active.
Transactional configuration gives the operator better control and visibility over their router configurations and reduce operational risk while increasing flexibility.
Transactional Configuration and Configuration Rollback support combine to provide the operational model depicted in Figure 5.
Figure 5: Router Configuration with Rollback and Transactions
 
Basic Operation
In order to edit the candidate configuration the operator must first enter the candidate edit mode (edit-cfg). The operator can enter and quit the configuration mode as many times as they wish before finally committing the candidate.
In edit-cfg mode the operator builds a set candidate configuration changes using the same CLI tree as standard (line-by-line non-transactional) configuration. Tab completion and keyword syntax checking is available.
Just as there is a single operational active configuration that can be modified simultaneously by multiple users in SR OS, there is also a single global candidate configuration instance. All users make changes in the same global candidate configuration and a commit operation by any user will commit the changes made by all users.
Users have the ability to exclusively create a candidate configuration by blocking other users (and sessions of the same user) from entering edit-cfg mode.
If a commit operation is successful then all of the candidate changes will take operational effect and the candidate is cleared. If there is an error in the processing of the commit, or a ‘commit confirmed’ is not confirmed and an auto-revert occurs, then the router will return to a configuration state with none of the candidate changes applied. The operator can then continue editing the candidate and try a commit later.
All commands in the candidate configuration must be in the correct order for a commit to be successful. Configuration that depends on other candidate objects must be placed after those objects in the candidate. A set of candidate editing commands (copy, insert, etc) are available to correct and reorder the candidate configuration.
The edit-cfg mode is primarily intended for building a candidate configuration while navigating the configure branch of CLI. Many CLI commands in branches other than configure are supported while in edit-cfg mode, but access to some CLI branches and command are blocked including the:
exec command
enable-admin command
admin branch
bof branch
debug branch
tools branch
The candidate configuration can be saved to a file and subsequently loaded into a candidate configuration. A saved candidate is similar to, but not the same as an SR OS config file generated with an admin save command. The saved candidate cannot be used in general as a configuration file and may not exec without failures.
There is no SNMP access to the candidate configuration and no SNMP management of candidates although any configuration changes done via a transaction are reported via the standard SR OS SNMP change traps and basic candidate status information is available via SNMP.
Failure of a commit may be due to one or more of several reasons including:
Error messages that will help the operator to take necessary actions to correct the candidate are provided for commit failures.
Standard line-by-line (immediate operational effect upon pushing the enter/return key) non-transactional CLI and SNMP commands are not blocked during the creation/editing of a candidate or the processing of a commit. These commands take immediate effect as normal.
 
Transactions and Rollback
By default, the SR OS will automatically create a new rollback checkpoint after a commit operation. The rollback checkpoint will include the new configuration changes made by the commit. An optional no-checkpoint keyword can be used to avoid the auto-creation of a rollback checkpoint after a commit. If the commit fails then no new rollback checkpoint is created.
When the commit confirmed option is used then a rollback checkpoint is created after the processing of the commit and will exist whether the commit is automatically reverted or not.
Transactional configuration relies on the rollback mechanism to operate. Any commands and configuration that is not supported in a rollback revert are also not supported in edit-cfg mode (examples include changes to chassis-mode or the existence of time-of-day suites).
 
Authorization
Authorization works transparently in edit-cfg mode and no unique/new local profile or TACACS+ permissions rules are required (other than allowing access to the candidate branch). For example: if an operator has permissions to access the configure filter context then they will automatically also have access to the configure filter context when in edit-cfg mode.
The candidate load and save operations (if the operator’s profile allows access to the candidate load and save commands) will load and save only those items that the user is authorized to access.
The candidate view will only display the items that the user is authorized to access.
The various candidate editing commands (such as adding lines, removing lines, delete, etc) only allow operations on items that the user is authorized to access.
The candidate commit and discard operations (along with rollback revert) operate on the entire candidate and impact all items (authorization does not apply).