Cisco ASR 5000 Series, ASR 5500 Administration Manual

Page 1

ASR 5500 System Administration Guide, StarOS Release 21.4

First Published: 2017-11-22

Americas Headquarters

Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883

Page 2

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright©1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: http://

www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership

relationship between Cisco and any other company. (1110R)

Page 3

Preface

CHAPTER 1

About this Guide xxix

Conventions Used xxix

About this Guide

This preface describes the ASR 5500 System Administration Guide, how it is organized and its document conventions.

The System Administration Guide describes how to generally configure and maintain StarOS running on an ASR 5500 platform. It also includes information on monitoring system performance and troubleshooting.

Conventions Used, page xxix

•

Conventions Used

The following tables describe the conventions used throughout this documentation.

DescriptionNotice Type

Provides information about important features or instructions.Information Note

Warning

Text represented as a screen

display

Alerts you of potential damage to a program, device, or system.Caution

Alerts you of potential personal injury or fatality. May also alert you of potential electrical hazards.

DescriptionTypeface Conventions

This typeface represents displays that appear on your terminal screen, for example:

ASR 5500 System Administration Guide, StarOS Release 21.4

xxix

Page 30

MIOs and DPCs

The ASR 5500 supports a variety of Management Input/Output and Data Processing Card types.

The currently supported Management Input/Output card types include:

xxx

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 31

About this Guide

Contacting Customer Support

Management Input/Output (MIO)

•

Universal Management Input/Output (UMIO)

•

Management Input/Output version 2 (MIO2)

•

MIO and UMIO card types differ only by the UMIO requirement for a Universal chassis license. The MIO2 is only supported on ASR 5500 running StarOS release 20.0+.

The currently supported Data Processing Card types include:

Data Processing Card (DPC)

•

Universal Data Processing Card (UDPC)

•

Data Processing Card version 2 (DPC2)

•

Universal Data Processing Card version 2 (UDPC2)

•

DPC and UDPC card types differ only by the UDPC requirement for a Universal chassis license. DPC2 and UDPC2 card types differ only by the UDPC2 requirement for a Universal chassis license. The DPC2/UDPC2 is only supported on ASR 5500 running StarOS release 18.2+.

When reference is made to an MIO card or DPC in this guide, it is presumed to apply to all types of these cards as identified above.

Contacting Customer Support

Use the information in this section to contact customer support.

Refer to the support area of http://www.cisco.com for up-to-date product documentation or to submit a service request. A valid username and password are required to access this site. Please contact your Cisco sales or service representative for additional information.

ASR 5500 System Administration Guide, StarOS Release 21.4

xxxi

Page 32

Contacting Customer Support

About this Guide

xxxii

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 33

CHAPTER 1

System Operation and Configuration

The ASR 5500 is designed to provide subscriber management services for Mobile Packet Core networks.

Before you connect to the command line interface (CLI) and begin system configuration, you must understand how the system supports these services. This chapter provides terminology and background information to consider before you configure the system.

System Management Overview, page 1

•

Terminology, page 3

•

Trusted Builds, page 6

•

How the System Selects Contexts, page 7

•

Understanding the ASR 5500 Boot Process, page 10

•

Understanding Configuration Files, page 11

•

IP Address Notation, page 13

•

Alphanumeric Strings, page 14

•

System Management Overview

ASR 5500 management capabilities reflect the requirements of the Telecommunications Management Network (TMN) model for network element (NE) and element management system (EMS) functions. The system also supports external element management applications via standards-based protocols (CORBA and SNMPv1, v2). Wireless operators can readily integrate the ASR 5500 into their overall network, service, and business management systems. All management is performed out-of-band for security and to maintain system performance.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 34

System Management Overview

There are multiple ways to manage the system either locally or remotely using its out-of-band management interfaces.

Figure 1: System Management Interfaces

System Operation and Configuration

Management options include:

Local login through the Console port on the MIO/MIO2 card using an RS-232 Console connection

•

(RJ45) directly or indirectly via a terminal server

Remote login using Telnet, and Secure Shell (SSH) access to the CLI through the MIO/MIO2 card's

•

Ethernet management interfaces:

Two autosensing RJ45 10/100/1000Base-T (IEEE 802.3ab) shielded twisted-pair (STP) ports

◦

Important

In release 20.0 and higher Trusted StarOS builds, the Telnet and FTP options are not available.

The MIO2 card also supports two 10 GbE ports that accept 10GBase-SR fiber optic-to-electrical signal

•

Small Form-Factor Pluggable (SFP+) transceivers. These ports are intended for local context only offload of data records and bulk statistics.

Support for Common Object Request Broker Architecture (CORBA) via an Object Request Broker

•

Element Manager (ORBEM) interface and Simple Network Management Protocol version 1 (SNMPv1) and version 2 (SNMPv2) for fault management

Authentication via RADIUS/Diameter or TACACS+

•

The StarOS CLI provides complete Fault, Configuration, Accounting, Performance, and Security (FCAPS) capabilities as described in the remaining chapters of this guide.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 35

System Operation and Configuration

Terminology

Important

Terminology

This section defines important terms used throughout this guide.

Contexts

A context is a logical grouping or mapping of configuration parameters that pertain to various physical ports, logical IP interfaces, and services. A context can be thought of as a virtual private network (VPN).

The system supports the configuration of multiple contexts. Each context is configured and operates independently of the others. Once a context has been created, administrative users can configure services, logical IP interfaces, and subscribers for that context and then bind the logical interfaces to physical ports.

You can also assign a domain alias to a context; if a subscriber's domain name matches one of the configured alias names for a context, that context is used.

Ports

By default StarOS supports local Console access to the CLI via the RS-232 Console port for initial system configuration.

Important

Ports are the physical connectors on line cards that support remote access and subscriber traffic. Port configuration includes traffic profiles, data encapsulation methods, media type, and other information for physical connectivity between the system and the rest of the network.

Ports are identified by the chassis slot number for the Management Input/Output (MIO/UMIO/MIO2) card, followed by the physical connector number. For example, Port 5/10 identifies connector number 10 on the MIO/UMIO/MIO2 card in slot 5.

Associate ports with contexts through bindings. For additional information on bindings, refer to the Bindings section below. You can configure each physical port to support multiple logical IP interfaces, each with up to 17 IP addresses (one primary and up to 16 secondaries).

For complete information on line cards and port assignments, refer to the ASR 5500 Installation Guide.

UMIO cards and UDPC/UDPC2s are direct replacements for MIO cards and DPC/DPC2s. However, a special Universal PID license must be purchased and installed on the chassis for each installed UMIO and UDPC/UDPC2. Contact your Cisco account representative for additional licensing information.

Throughout this guide, any reference to an MIO card or DPC is assumed to also refer to the UMIO and UDPC/UDPC2 respectively.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 36

Logical Interfaces

You must associate a port with a StarOS virtual circuit or tunnel called a logical interface before the port can allow the flow of user data.Within StarOS, a logical interface is a named interface associated with a virtual router instance that provides higher-layer protocol transport, such as Layer 3 IP addressing. Interfaces are configured as part of VPN contexts and are independent from the physical ports that will be used to bridge the virtual interfaces to the network.

Logical interfaces are associated with ethernet+ppp+tunnel addresses and are bound to a specific port during the configuration process. Logical interfaces are also associated with services through bindings. Services are bound to an IP address that is configured for a particular logical interface. When associated, the interface takes on the characteristics of the functions enabled by the service.

There are several types of logical interfaces to configure to support Simple and Mobile IP data applications. These are briefly defined below.

Management Interface

System Operation and Configuration

Bindings

This interface provides the point of attachment to the management network. The interface supports remote access to the StarOS command line interface (CLI). It also supports event notification via the Simple Network Management Protocol (SNMP).

Define management interfaces in the local context and bind them to the ports on the Management Input/Output (MIO/UMIO/MIO2) cards.

A binding is an association between elements within the system. There are two types of bindings: static and dynamic.

Static binding is accomplished through system configuration. Static bindings associate:

A specific logical interface (configured within a particular context) to a physical port. Once the interface

•

is bound, traffic can flow through the context as if it were any physically-defined circuit. Static bindings support any encapsulation method over any interface and port type.

A service to an IP address assigned to a logical interface within the same context. This allows the interface

•

to take on the characteristics (that is, support the protocols) required by the service.

Dynamic binding associates a subscriber to a specific egress context based on the configuration of their profile or system parameters. This provides a higher degree of deployment flexibility, as it allows a wireless carrier to support multiple services and facilitates seamless connections to multiple networks.

Management ports can only be bound in the local context. Traffic or subscriber ports can only be bound in a non-local context.

Services

ASR 5500 System Administration Guide, StarOS Release 21.4

Configure services within a context to enable certain functionality. The following are examples of services you can configure on the system, subject to licensing availability and platform type:

Gateway GPRS Support Node (GGSN) services

•

Page 37

System Operation and Configuration

Serving GPRS Support Node (SGSN) Services

•

Packet Data Serving Node (PDSN) services

•

Home Agent (HA) services

•

Layer 2 Tunneling Protocol Access Concentrator (LAC) services

•

Dynamic Host Control Protocol (DHCP) services

•

Mobility Management Entity (MME) Services

•

PDN Gateway (P-GW) Services

•

Serving Gateway (S-GW) Services

•

Intelligent Policy Control Function (IPCF) Services (PCC-Service, PCC-Policy, PCC-AF)

•

AAA Servers

Authentication, Authorization and Accounting (AAA) servers store profiles, perform authentication, and maintain accounting records for each mobile data subscriber. The AAA servers communicate with the system over an AAA interface. The system supports the configuration of up to 128 interfaces to AAA servers.

It is important to note that for Mobile IP, there can be Foreign AAA (FAAA) and Home AAA (HAAA) servers. FAAA servers typically reside in the carrier's network. HAAA servers could be owned and controlled by either the carrier or the home network. If the HAAA server is owned and controlled by the home network, accounting data is transferred to the carrier via an AAA proxy server.

Subscribers

Important

Subscribers

Mobile IP support depends on the availability and purchase of a license bundle that includes Home Agent (HA).

Subscribers are the end-users of the service; they gain access to the Internet, their home network, or a public network through the system.

There are three primary types of subscribers:

RADIUS-based Subscribers: The most common type of subscriber, these users are identified by their

•

International Mobile Subscriber Identity (IMSI) number, an Electronic Serial Number (ESN), or by their domain name or user name. They are configured on and authenticated by a RADIUS AAA server.

Upon successful authentication, various attributes that are contained in the subscriber profile are returned. The attributes dictate such things as session parameter settings (for example, protocol settings and IP address assignment method), and what privileges the subscriber has.

Important

Attribute settings received by the system from a RADIUS AAA server take precedence over local-subscriber attributes and parameters configured on the system.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 38

Trusted Builds

System Operation and Configuration

Local Subscribers: These are subscribers, primarily used for testing purposes, that are configured and

•

authenticated within a specific context. Unlike RADIUS-based subscribers, the local subscriber's user profile (containing attributes like those used by RADIUS-based subscribers) is configured within the context where they are created.

When local subscriber profiles are first created, attributes for that subscriber are set to the system's default settings. The same default settings are applied to all subscriber profiles, including the subscriber named default which is created automatically by the system for each system context. When configuring local profile attributes, the changes are made on a subscriber-by-subscriber basis.

•

Trusted Builds

A Trusted build is a starfile image from which non-secure or low security features have been deleted or disabled. However, the binaries in the Trusted starfile image are are identical to those found in other starfiles for a particular StarOS release-build number. In general, a Trusted build is more restrictive than a Normal build image.

You can identify whether your platform is running a Trusted build via the Exec mode show version command. The output of the command displays the word "Trusted" as part of the image description text.

The following non-secure programs and features are disabled/removed from a Trusted build:

Important

Management Subscribers: A management user is an authorized user who can monitor, control, and configure the system through the CLI. Management is performed either locally, through the system Console port, or remotely through the use of the Telnet or secure shell (SSH) protocols. Management users are typically configured as a local subscriber within the Local context, which is used exclusively for system management and administration. As with a local subscriber, a management subscriber's user profile is configured within the context where the subscriber was created (in this case, the Local context). However, management subscribers may also be authenticated remotely via RADIUS, if an AAA configuration exists within the local context, or TACACS+.

Attributes configured for local subscribers take precedence over context-level parameters. However, they could be over-ridden by attributes returned from a RADIUS AAA server.

Telnet

•

FTP (File Transfer Protocol)

•

Local user database access

•

tcpdump utility

•

rlogin (Remote Login) utility and rlogind (Remote Login daemon)

•

rsh (Remote Shell) and rcp (Remote Copy) utilities

•

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 39

System Operation and Configuration

How the System Selects Contexts

This section describes the process that determines which context to use for context-level administrative users or subscriber sessions. Understanding this process allows you to better plan your configuration in terms of how many contexts and interfaces you need to configure.

Context Selection for Context-level Administrative User Sessions

The system comes configured with a context called local that you use specifically for management purposes. The context selection process for context-level administrative users (those configured within a context) is simplified because the management ports on the MIO are associated only with the Local context. Therefore, the source and destination contexts for a context-level administrative user responsible for managing the entire system should always be the local context.

A context-level administrative user can be created in a non-local context. These management accounts have privileges only in the context in which they are created. This type of management account can connect directly to a port in the context in which they belong, if local connectivity is enabled (SSHD, for example) in that context.

For all FTP or SFTP connections, you must connect through an MIO management interface. If you SFTP or FTP as a non-local context account, you must use the username syntax of username@contextname.

In release 20.0 and higher Trusted StarOS builds, FTP is not supported.Important

The context selection process becomes more involved if you are configuring the system to provide local authentication or work with a AAA server to authenticate the context-level administrative user.

The system gives you the flexibility to configure context-level administrative users locally (meaning that their profile will be configured and stored in its own memory), or remotely on an AAA server. If a locally-configured user attempts to log onto the system, the system performs the authentication. If you have configured the user profile on an AAA server, the system must determine how to contact the AAA server to perform authentication. It does this by determining the AAA context for the session.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 40

Context Selection for Context-level Administrative User Sessions

The following table and flowchart describe the process that the system uses to select an AAA context for a context-level administrative user. Items in the table correspond to the circled numbers in the flowchart.

Figure 2: Context-level Administrative User AAA Context

System Operation and Configuration

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 41

System Operation and Configuration

Table 1: Context-level Administrative User AAA Context Selection

DescriptionItem

Context Selection for Context-level Administrative User Sessions

During authentication, the system determines whether local authentication is enabled in the local context.

If it is, the system attempts to authenticate the administrative user in the local context. If it is not, proceed to item 2 in this table.

If the administrative user's username is configured, authentication is performed by using the AAA configuration within the local context. If not, proceed to item 2 in this table.

If local authentication is disabled on the system or if the administrative user's username is not configured in the local context, the system determines if a domain was received as part of the username.

If there is a domain and it matches the name of a configured context or domain, the systems uses the AAA configuration within that context.

If there is a domain and it does not match the name of a configured context or domain, Go to item 4 in this table.

If there is no domain as part of the username, go to item 3 in this table.

If there was no domain specified in the username or the domain is not recognized, the system determines whether an AAA Administrator Default Domain is configured.

If the default domain is configured and it matches a configured context, the AAA configuration within the AAA Administrator Default Domain context is used.

If the default domain is not configured or does not match a configured context or domain, go to item 4 item below.

If a domain was specified as part of the username but it did not match a configured context, or if a domain was not specified as part of the username, the system determines if the AAA Administrator Last Resort context parameter is configured.

If a last resort, context is configured and it matches a configured context, the AAA configuration within that context is used.

If a last resort context is not configured or does not match a configured context or domain, the AAA configuration within the local context is used.

In Release 21.4 and higher (Trusted builds only):

Users can only access the system through their respective context interface.

•

If the user attempts to log in to their respective context through a different context interface, that user

•

will be rejected.

Irrespective of whether the users are configured in any context with 'authorized-keys' or 'allowusers',

•

with this feature these users will be rejected if they attempt to log in via any other context interface other than their own context interface.

Users configured in any non-local context are required to specify which context they are trying to log

•

in to. For example:

ssh username@ctx_name@ctx_ip_addrs

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 42

Context Selection for Subscriber Sessions

The context selection process for a subscriber session is more involved than that for the administrative users. Subscriber session context selection information for specific products is located in the Administration Guide for the individual product.

Understanding the ASR 5500 Boot Process

Part of the configuration process requires that you allocate hardware resources for processing and redundancy. Therefore, before you configure the system, it is important to understand the boot process which determines how the hardware components are brought on line.

The following flowchart shows each step in the startup process. For additional information about system configuration files, refer to the Understanding Configuration Files section.

Figure 3: ASR 5500 Process Flowchart

System Operation and Configuration

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 43

System Operation and Configuration

The following steps describe the system's boot process:

Understanding Configuration Files

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7 Step 8

Step 9

When power is first applied to the chassis, or after a reboot, only the MIO/UMIO/MIO2s in slot 5 and slot 6 receive power.

During the startup process, the MIO/UMIO/MIO2 performs a series of power-on self tests (POSTs) to ensure that its hardware is operational.

If the MIO/UMIO/MIO2 in slot 5 successfully executes all POSTs, it becomes the active MIO. The MIO in slot 6 becomes the standby card. If there is a problem with the MIO in slot 5, the MIO in slot 6 becomes the active MIO.

The active MIO/UMIO/MIO2 begins loading the operating system software image designated in the boot stack. The boot stack entries are contained in the boot.sys file that resides on flash memory on the MIO/UMIO. The standby MIO/UMIO/MIO2 observes the active card startup. If the file on the active MIO/UMIO/MIO2 is loads normally, the standby MIO/UMIO boots from the active card image. If the active MIO/UMIO experiences problems during this phase, the standby MIO/UMIO/MIO2 loads its software image designated by its own boot stack entry in its boot.sys file and takes over control of the system as the active MIO/UMIO/MIO2.

After the software image is loaded into its memory, the active MIO/UMIO/MIO2 determines whether other cards are installed in the chassis by applying power to the other chassis slots and signalling them. If the chassis slot contains a card, power is left On to that slot. All empty slots are powered off. If no MIOs are installed or if both fail to boot successfully, no other card installed in the system will boot.

When power is applied to the DPC/UDPCs or DPC2/UDPC2s installed in the system, they each perform their own series of POSTs.

After successful POST, each DPC/UDPC or DPC2/UDPC2 enters standby mode.

After entering the standby mode, each of the control processors (CPs) on the DPC/UDPCs or DPC2/UDPC2s communicate with the active MIO/UMIO/MIO2 to receive the appropriate code.

Upon successful loading of the software image, the system loads a configuration file designated in the boot stack (boot.sys file). If this is the first time the system is powered on and there is no configuration file, the active MIO/UMIO/MIO2 invokes the system's Quick Setup wizard. Use the Quick Setup wizard to configure basic system parameters for communication across the management network. The wizard creates a configuration file (system.cfg) that you can use as a starting point for subsequent configurations. This allows you to configure the system automatically by applying the configuration file during any subsequent boot. For additional information about system configuration files, refer to the Understanding Configuration Files section.

Understanding Configuration Files

The system supports the use of a file or script to modify configurable parameters. Using a file for offline system configuration reduces the time it takes to configure parameters on multiple systems.

A system configuration file is an ASCII text file that contains commands and configuration parameters. When you apply the configuration file, the system parses through the file line-by-line, testing the syntax and executing the command. If the syntax is incorrect, a message is displayed to the CLI and the system proceeds to the next command. Lines that begin with # are considered remarks and are ignored.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 44

Understanding Configuration Files

System Operation and Configuration

Important

Pipes ( | ), used with the grep and more keywords, can potentially cause errors in configuration file processing. Therefore, the system automatically ignores keywords with pipes during processing.

Always save configuration files in UNIX format. Failure to do so can result in errors that prevent configuration file processing.

The commands and configuration data within the file are organized and formatted just as they would be if they were being entered at the CLI prompt. For example, if you wanted to create a context called source in the CLI, you would enter the following commands at their respective prompts:

[local]host_name# config [local]host_name(config)# context source [source]host_name(config-ctx)# end

To create a context called source using a configuration file, you would use a text editor to create a new file that consists of the following:

config

context source end

There are several important things to consider when using configuration files:

The system automatically applies a configuration file at the end of the boot process. After the system

•

boots up for the first time, a configuration file that you have created and that is tailored to your network needs, can be applied. To make the system use your configuration file, modify the system's boot parameters according to the instructions located in Software Management Operations.

In addition to being applied during the boot process, you can also apply configuration files manually at

•

any time by executing the appropriate commands at the CLI prompt. Refer to the instructions in Software Management Operations.

Important

When you apply a configuration file after the boot process, the file does not delete the configuration loaded as part of the boot process. Only those commands that are duplicated are overwritten.

Configuration files can be stored in any of the following locations:

•

USB Memory Stick: Supported via a USB port on the active MIO (/usb1).

•

Network Server: Any workstation or server on the network that the system can access using the

•

Secure File Transfer Protocol (SFTP). This is recommended for large network deployments in which multiple systems require the same configuration.

/flash: a solid-state device with limited storage.

•

/hd-raid: internal RAID storage.

•

Each time you save configuration changes you made during a CLI session, you can save those settings

•

to a file which you can use as a configuration file.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 45

System Operation and Configuration

IP Address Notation

When configuring a port interface via the CLI you must enter an IP address. The CLI always accepts an IPv4 address, and in some cases accepts an IPv6 address as an alternative.

For some configuration commands, the CLI also accepts CIDR notation. Always view the online Help for the CLI command to verify acceptable forms of IP address notation.

IPv4 Dotted-Decimal Notation

An Internet Protocol Version 4 (IPv4) address consists of 32 bits divided into four octets. These four octets are written in decimal numbers, ranging from 0 to 255, and are concatenated as a character string with full stop delimiters (dots) between each number.

For example, the address of the loopback interface, usually assigned the host name localhost, is 127.0.0.1. It consists of the four binary octets 01111111, 00000000, 00000000, and 00000001, forming the full 32-bit address.

IPv4 allows 32 bits for an Internet Protocol address and can, therefore, support 232(4,294,967,296) addresses.

IP Address Notation

IPv6 Colon-Separated-Hexadecimal Notation

An Internet Protocol Version 6 (IPv6) address has two logical parts: a 64-bit network prefix, and a 64-bit host address part. An IPv6 address is represented by eight groups of 16-bit hexadecimal values separated by colons (:).

A typical example of a full IPv6 address is 2001:0db8:85a3:0000:0000:8a2e:0370:7334

The hexadecimal digits are case-insensitive.

The 128-bit IPv6 address can be abbreviated with the following rules:

Leading zeroes within a 16-bit value may be omitted. For example, the address

•

fe80:0000:0000:0000:0202:b3ff:fe1e:8329 may be written as fe80:0:0:0:202:b3ff:fe1e:8329

One group of consecutive zeroes within an address may be replaced by a double colon. For example,

•

fe80:0:0:0:202:b3ff:fe1e:8329 becomes fe80::202:b3ff:fe1e:8329

IPv6 allows 128 bits for an Internet Protocol address and can support 2 (340,282,366,920,938,000,000,000,000,000,000,000,000) internet addresses.

CIDR Notation

Classless Inter-Domain Routing (CIDR) notation is a compact specification of an Internet Protocol address and its associated routing prefix. It is used for both IPv4 and IPv6 addressing in networking architectures.

CIDR is a bitwise, prefix-based standard for the interpretation of IP addresses. It facilitates routing by allowing blocks of addresses to be grouped into single routing table entries. These groups (CIDR blocks) share an initial sequence of bits in the binary representation of their IP addresses.

128

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 46

Alphanumeric Strings

System Operation and Configuration

CIDR notation is constructed from the IP address and the prefix size, the latter being the number of leading 1 bits of the routing prefix. The IP address is expressed according to the standards of IPv4 or IPv6. It is followed by a separator character, the slash (/) character, and the prefix size expressed as a decimal number.

The address may denote a single, distinct, interface address or the beginning address of an entire network. In the latter case the CIDR notation specifies the address block allocation of the network. The maximum size of the network is given by the number of addresses that are possible with the remaining, least-significant bits below the prefix. This is often called the host identifier.

For example:

the address specification 192.168.100.1/24 represents the given IPv4 address and its associated routing

•

prefix 192.168.100.0, or equivalently, its subnet mask 255.255.255.0.

the IPv4 block 192.168.0.0/22 represents the 1024 IPv4 addresses from 192.168.0.0 to 192.168.3.255.

•

the IPv6 block 2001:DB8::/48 represents the IPv6 addresses from 2001:DB8:0:0:0:0:0:0 to

•

2001:DB8:0:FFFF:FFFF:FFFF:FFFF:FFFF.

::1/128 represents the IPv6 loopback address. Its prefix size is 128, the size of the address itself, indicating

•

that this facility consists of only this one address.

The number of addresses of a subnet defined by the mask or prefix can be calculated as 2 which the address size for IPv4 is 32 and for IPv6 is 128. For example, in IPv4, a mask of /29 gives 2 23= 8 addresses.

Alphanumeric Strings

Some CLI commands require the entry of an alphanumeric string to define a value. The string is a contiguous collection of alphanumeric characters with a defined minimum and maximum length (number of characters).

Character Set

The alphanumeric character set is a combination of alphabetic (Latin letters) and/or numeric (Arabic digits) characters. The set consists of the numbers 0 to 9, letters A to Z (uppercase) and a to z (lowercase). The underscore character ( _ ) and dash/hyphen (-) are also considered to be members of the alphanumeric set of characters.

Blank spaces (whitespaces or SPACE characters) should mostly be avoided in alphanumeric strings, except in certain ruledef formats, such as time/date stamps.

Do not use any of the following "special" characters in an alphanumeric string except as noted below:

& (ampersand)

•

' (apostrophe)

•

address size - mask

32-29

, in

< > (arrow brackets) [see exception below]

•

* (asterisk) [see wildcard exception below]

•

{ } (braces)

•

[ ] (brackets)

•

$ (dollar sign) [see wildcard exception below]

•

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 47

System Operation and Configuration

! (exclamation point) [see exception below]

•

( ) [parentheses]

•

% (percent) [see exception below]

•

# (pound sign) [see exception below]

•

? (question mark)

•

• ' (quotation mark – single)

• " (quotation mark – double)

; (semicolon)

•

• \ (slash – backward) [see exception below]

• / (slash – forward) [see exception below]

~ (tilde)

•

| (vertical bar) [see exception below]

•

Character Set

The following characters may appear in strings entered in ruledefs, APNs, license keys and other configuration/display parameters:

< > (arrow brackets) [less than or greater than]

•

* (asterisk) [wildcard]

•

: (colon)

•

$ (dollar sign) [wildcard]

•

. (dot)

•

= (equals sign)

•

! (exclamation point)

•

% (percent)

•

• / (slash – forward)

| (vertical bar)

•

The following characters may be used to delimit the domain from the user name for global AAA functions:

@ (at sign)

•

- (dash or hyphen)

•

# (hash or pound sign)

•

% [percent]

•

• \ (slash – backward) [must be entered as double slash "\\"]

• / (slash – forward)

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 48

Quoted Strings

If descriptive text requires the use of spaces between words, the string must be entered within double quotation marks (" "). For example:

interface "Rack 3 Chassis 1 port 5/2"

System Operation and Configuration

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 49

Getting Started

ASR 5500 Configuration, page 17

•

Using the ASR 5500 Quick Setup Wizard, page 17

•

Using the CLI for Initial Configuration, page 24

•

Configuring System Administrative Users, page 26

•

Configuring the System for Remote Access, page 27

•

Configuring SSH Options, page 29

•

Configuring the Management Interface with a Second IP Address, page 39

•

ASR 5500 Configuration

Following the successful installation of the system hardware, you must configure a set of software parameters and then save these settings in a system configuration file that is launched whenever the system is reloaded.

The first time power is applied to the system, the active Management Input/Output (MIO/UMIO//MIO2) card (typically the one installed in chassis slot 5) automatically launches a Quick Setup Wizard on its console port. This wizard guides you through the initial configuration of the system.

The serial console port (logical port 3) is located on the front panel of the MIO card.

You can choose not to use the wizard and perform the initial configuration by issuing commands via the command line interface (CLI). You can manually launch the wizard by running the setup command in the Exec mode. Refer to the Command Line Interface Reference for details.

CHAPTER 2

Using the ASR 5500 Quick Setup Wizard

The Quick Setup Wizard consists of three parts:

Configuring a context-level security administrator and hostname

•

Configuring the Ethernet interface for out-of-band (OOB) management

•

Configuring the system for remote CLI access

•

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 50

The Quick Setup Wizard

The Quick Setup Wizard consists of a series of questions that prompt you for input before proceeding to the next question. Some prompts may be skipped depending on previous responses or whether a particular function is supported in the StarOS release.

The following is a sample of the Quick Setup Wizard with responses that are designed to show most of the questions.

[local]<host_name># setup

1. Do you wish to continue with the Quick Setup Wizard[yes/no]: yes

2. Enable basic configuration[yes/no]: yes

3. Change chassis key value - WARNING: old configuration scripts will become invalid after key change[yes/no]: no

5. Create new tech-support password[yes/no]: yes

6. New tech-support password: <ts_password>

7. local context administrator username[admin]: <admin_name>

8. local context administrator password: <admin_password>

9. confirm local context administrator password: <admin_password>

10. hostname[<host_name>]: <host_name>

11. Create single dedicated LI context[yes/no]: no

13. Enable segregated LI configuration[yes/no]: yes

14. Enable LOCAL interface[yes/no]: yes

17. LOCAL Out of band Ip Address: <ip_address>

18. LOCAL Out of band subnet mask: <subnet_mask>

19. Default gateway Ip Address: <gw_ip_address>

20. Enable remote access[yes/no]: yes

21. Enable sshd[yes/no]: yes

22. Enter a default SSH key size[2048/3072/4096/5120/7168/9216]: 2048

23. Enable sftp server[yes/no]: yes

24. Enable telnetd[yes/no]: no

25. Enable ftpd[yes/no]: no Do you want to review your selections[no/yes]: no Do you want to view the configuration script created[yes/no]: yes <configuration_script_output> Do you want to apply configuration script created[yes/no]: no [local]<host_name>#

Getting Started

Table 2: Quick Setup Wizard Questions

Enter or exit the wizard.1

Description/NotesTaskQues.

Enter no at the prompt to automatically be directed to the command line interface (CLI). Proceed to

Using the CLI for Initial Configuration, on page 24

for instructions on performing an initial system configuration with the CLI.

Enter setup at the command prompt to re-invoke the wizard.

Enter yes to create a basic configuration file.Enable a basic configuration.2

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 51

Getting Started

The Quick Setup Wizard

Description/NotesTaskQues.

8, 9

Change chassis key value.3

Create a tech-support password.5, 6

Configure an administrative username for the system.

Configure an administrative password for the system.

A unique chassis key is configured at the factory for each system. This key is used to decrypt encrypted passwords found in generated configuration files. The system administrator can create a unique chassis key that will be used to encrypt passwords stored in configuration files.

Enter yes to set a new chassis key. Refer to the instructions in System Settings. Additional information can be found in the System Security chapter.

See Enabling Password for Access to CLI-test commands in the System Security chapter for additional information.

The name of the default administrative user configured through the wizard is admin.

Administrative username is an alphanumeric string of 1 through 32 characters that is case sensitive.

Administrative user password is an alphanumeric string of 1 through 63 characters that is case sensitive. For release 21.0 and later, you can enter 127 characters for the password.

The hostname appears in the StarOS CLI prompt.Change the hostname for the system.10

Create a single Dedicated-LI context.11

Before creating a Dedicated LI context, refer to the Lawful Intercept Configuration Guide. Once created, a Dedicated LI context cannot be undone.

Enable segregated LI Configuration.13

Before segregating system and LI configurations, refer to the Lawful Intercept Configuration Guide.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 52

The Quick Setup Wizard

Getting Started

Description/NotesTaskQues.

14, 17, 18

Configure a single Management Input/Output (MIO/UMIO/MIO2) out-of-band management interface for out-of-band system management.

Enable remote access.20

Traffic on the management LAN is not transferred over the same media as user data and control signaling.

For security reasons, it is recommended that management functions be maintained on a separate network from user data and control signaling.

MIO port 1 (mio1) is the 1000Base-T default management port.

MIO port 2 (mio2) is available as a secondary management port.

Use the RJ-45 interfaces to connect the system to the management network with CAT5 Ethernet cable.

Configure an IP address and subnet mask for the interface.

Enter an IP address.Configure a default gateway for the interface.19

Enter yes to allow remote access to this system.

Instructions for configuring the second management interface on the MIO can be found in the System Settings chapter.

21–23

Enable SSH remote access protocols for accessing the system.

Enable remote access via telnet.24

Secure Shell (SSH) uses TCP port number 22 by default, if enabled.

In Release 19.0 and prior releases, SSH V1 and/or V2 are supported. If SSH is enabled, you can also enable SSH File Transfer Protocol (SFTP) server functionality.

In Release 19.2 and higher, you can specify the SSH key size. The SSH v2-RSA key generation uses that key size value.

Note: For maximum security, use only SSH v2.

In Release 19.2 and higher, only SSH v2 is supported.

Secure File Transfer Protocol (SFTP) uses TCP port number 22 by default, if enabled [subsystem sftp].

Note: For maximum system security, do not enable telnet protocol.

Note: In release 20.0 and higher Trusted StarOS builds, telnet is not supported.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 53

Getting Started

The Quick Setup Wizard

Description/NotesTaskQues.

—

Enable FTP access to the system.25

Review and/or modify the configuration of previous prompts.

Review the configure script created by the wizard based on your inputs.

Apply the configuration file to the system.

File Transfer Protocol (FTP) uses TCP port number 21 by default, if enabled.

Note: For maximum system security, do not enable FTP.

Note: in release 20.0 and higher Trusted StarOS builds, FTP is not supported.

Enter the number of the prompt to be modified.

Configure the parameter.

Optional. Repeat step 1 and step 2 to modify additional settings.

Enter "done" when you have completed all changes.

An example of a created script is displayed in the example below. Variables are displayed in italics (variable).

Once applied, the parameter configuration is automatically saved to the system.cfg file stored in MIO/UMIO/MIO2 flash memory.

Do you want to view the configuration script created[yes/no]: y config

system hostname hostname context local

administrator admin_name password passwd interface mio1

ip address ip_address subnet #exit

ip route 0.0.0.0 0.0.0.0 gw_address mio1 ssh key v1_key ssh key v2_rsa_key ssh key v2_dsa_key

server sshd subsystem sftp #exit no server telnetd no server ftpd #exit port ethernet 5/1 bind interface mio1 local no shutdown

#exit end Do you want to apply configuration script created[yes/no]:

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 54

The Quick Setup Wizard

Getting Started

Important

Once configuration using the wizard is complete, proceed to instructions on how to configure other system parameters.

Figure 4: MIO Interfaces

USB port2Console port [Port 3]1

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 55

Getting Started

The Quick Setup Wizard

10 GbE ports, DC-1 [Ports 10 – 19]

1 GbE ports (1000Base-T) [Ports 1 and 2]5

Figure 5: MIO2 Interfaces

10 GbE ports, DC-2 [Ports 20 – 29]

10GbE ports, DC-1 [Ports 12 and 13]2100 GbE ports, DC-1 [Ports 10 and 11]1

Console port [Port 3]4USB port3

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 56

Using the CLI for Initial Configuration

1 GbE ports (1000Base-T) [Ports 1 and 2]5

Using the CLI for Initial Configuration

The initial configuration consists of the following:

Configuring a context-level security administrator and hostname

•

Configuring the Ethernet interface on the MIO/UMIO/MIO2 card

•

Configuring the system for remote CLI access via Telnet, SSH, or FTP (secured or unsecured)

•

In release 20.0 and higher Trusted StarOS builds, FTP and telnet are not supported.Important

Getting Started

10GbE ports, DC-2 [Ports 22 and 23]7100 GbE ports, DC-2 [Ports 20 and 21]6

Step 1

Step 2

Step 3

Step 4

This section provides instructions for performing these tasks using the CLI.

At the CLI prompt, enter:

[local]host_name# configure [local]host_name(config)#

Enter the context configuration mode by entering the following command:

[local]host_name(config)# context local [local]host_name(config-ctx)#

The local context is the system's management context. Contexts allow you to logically group services or interfaces. A single context can consist of multiple services and can be bound to multiple interfaces.

Enter the following command to configure a context-level security administrator for the system:

administrator user_name [ encrypted ] password password | [ ecs ] [ expiry-date date_time ] [ ftp ] [ li-administration ] [ nocli ] [ noecs ] [ timeout-absolute timeout_absolute [ timeout-min-absolute timeout_min_absolute ] [ timeout-idle timeout_idle [ timeout-min-idle timeout_min_idle

You must configure a context-level security administrator during the initial configuration. After you complete the initial configuration process and end the CLI session, if you have not configured a security administrator, CLI access will be locked. For complete information about the commands in this section, see the Context Configuration Mode Commands chapter of the Command Line Interface Reference.

Note

For security reasons, li-administration accounts must be restricted for use only with Lawful Intercept (LI) functionality and not for general system administration. Only security administrators and administrators can provision LI privileges. To ensure security in accordance with Law Enforcement Agency (LEA) standards, LI administrative users must access the system using the Secure Shell (SSH) protocol only. LI privileges can be optionally configured for use within a single context system-wide. For additional information, see the Lawful Intercept Configuration Guide.

Enter the following command at the prompt to exit the context configuration mode:

[local]host_name(config-ctx)# exit [local]host_name(config)#

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 57

Getting Started

Using the CLI for Initial Configuration

Step 5

Step 6

Enter the following command to configure a hostname by which the system will be recognized on the network:

[local]host_name(config)# system hostname host_name

host_name is the name by which the system will be recognized on the network. The hostname is an alphanumeric string

of 1 through 63 characters that is case sensitive.

Configure the network interfaces on the MIO/UMIO/MIO2 using the following instructions:

a) Enter the context configuration mode by entering the following commands:

[local]host_name(config)# context local [local]host_name(config-ctx)#

b) Enter the following command to specify a name for the interface:

[local]host_name(config-ctx)# interface interface_name

interface_name is the name of the interface expressed as an alphanumeric string of 1 through 79 characters that is

case sensitive. The following prompt appears as the system enters the Ethernet Interface Configuration mode:

[local]host_name(config-if-eth)#

c) Configure an IP address for the interface configured in the previous step by entering the following command:

{ ip address | ipv6 address } ipaddress subnetmask

If you are executing this command to correct an address or subnet that was mis-configured with the Quick Setup Wizard, you must verify the default route and port binding configuration. Use step 11 and step 6 of this procedure. If there are issues, perform steps 7e through 7k to reconfigure the information.

d) Enter the following command to exit the Ethernet interface configuration mode:

[local]host_name(config-if-eth)# exit [local]host_name(config-ctx)#

e) Configure a static route, if required, to point the system to a default gateway. Entering the following command:

{ ip | ipv6 } route gw_address interface_name

f) Enter the following to exit from the context configuration mode:

[local]host_name(config-ctx)# exit [local]host_name(config)#

g) Enter the Ethernet Port Configuration mode:

port ethernet slot#/port#

h) Bind the port to the interface that you created in step 7b. Binding associates the port and all of its settings to the

interface. Enter the following command:

[local]host_name(config-port-<slot#/port#>)# bind interface interface_name local [local]host_name(config-port-<slot#/port#>)# no shutdown

interface_name is the name of the interface that you configured in step 7b.

i) Exit the Ethernet Interface Configuration mode by entering the command:

[local]host_name(config-port-<slot#/port#>)# exit [local]host_name(config)#

Important

Refer below for instructions on configuring the MIO/UMIO/MIO2 management interface with a second IP address.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 58

Configuring System Administrative Users

This section describes some of the security features that allow security administrators to control user accounts.

Limiting the Number of Concurrent CLI Sessions

Security administrators can limit the number of concurrent interactive CLI sessions. Limiting the number of concurrent interactive sessions reduces the consumption of system-wide resources. It also prevents a user from potentially accessing sensitive user in formation which is already in use.

Most privileged accounts do not require multiple concurrent logins.

Configuring the maximum number of sessions is recommended for all privileged accounts.Important

Security administrators can limit the number of concurrent interactive CLI sessions with three different ways depending on the authentication method which his used for that particular user account. StarOS supports three login authentication methods:

Getting Started

TACACS+ Server users

•

Local-User users

•

AAA Context users

•

For additional information on configuring the maximum number of sessions for TACACS+ Server users, see

Operation. For additional information on configuring the maximum number of sessions for Local-User users

and AAA context users, see Configuring Context-level Administrative Users.

Each authentication method must be configured separately because each of the three authentication methods can use the same user name.

Automatic Logout of CLI Sessions

Security administrators can configure an automatic logout of certain user accounts. Limiting the number of minutes that an interactive CLI session can be in use reduces the consumption of system-wide resources. It also prevents a user from potentially accessing a user account in a terminal window which is left idle. All authentication methods described in this section support both the idle session timeout technique and the absolute session timeout technique.

Most privileged accounts do not require an indefinite login timeout limit.

Configuring the session timeout is strongly recommended for all privileged accounts.Important

The idle timeout and session timeout fields in the show tacacs summary and show tacacs session id commands allow administrators to configure an automatic logout of certain accounts.

Session Timeout: allows a security administrator to specify the maximum amount of minutes that a user can be logged in to a session before the session is automatically disconnected.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 59

Getting Started

Configuring the System for Remote Access

Idle Timeout: allows a security administrator to specify the maximum amount of minutes that a session can remain in an idle state before the session is automatically disconnected.

Important

The session timeout and idle timeout fields are not exclusive. If both are specified, then the idle timeout should always be lower than the session timeout since a lower session timeout will always be reached first.

For additional information on configuring the maximum number of minutes that an interactive CLI session can be in use, see the idle-sessions threshold command and the clear tacacs sessions CLI command in the

CLI Reference and the show tacacs summary and show tacacs session id in the Statistics and Counter Reference.

Configuring the System for Remote Access

Configure the system for remote access. An administrative user may access the system from a remote location over a local area network (LAN) or wide area network (WAN):

Telnet

•

Secure Shell (SSH)

•

File Transfer Protocol (FTP) (secured or unsecured)

•

Trivial File Transfer Protocol (TFTP)

•

Important

If there are two simultaneous telnet sessions, and one administrator deletes the context into which the other administrator is logged, the administrator in the deleted context will not be automatically kicked into the local context. Although the deleted context will still appear in the CLI prompt, context specific commands will generate errors.

Step 1

Step 2

For maximum security, use SSH v2.Important

In release 20.0 and higher Trusted StarOS builds, FTP and telnet are not supported.Important

Enter the context configuration mode by entering the following command:

[local]host_name(config)# context local [local]host_name(config-ctx)#

If desired, configure the system to allow Telnet access:

[local]host_name(config-ctx)# server telnetd

For maximum system security, you should not enable telnet.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 60

Configuring the System for Remote Access

Getting Started

Step 3

Step 4

Step 5

Step 6

Configure the system to allow SSH access:

[local]host_name(config-ctx)# ssh generate key [ type { v1-rsa | v2-rsa | v2-dsa } ]

v2-rsa is the recommended key type.

In StarOS 19.2 and higher, the v1-rsa keyword has been removed from and the v2-dsa keyword has been concealed within the Context Configuration mode ssh generate CLI command. A keyword that was supported in a previous release may be concealed in subsequent releases. StarOS continues to parse concealed keywords in existing scripts and configuration files created in a previous release. But the concealed keyword no longer appears in the command syntax for use in new scripts or configuration files. Entering a question mark (?) will not display a concealed keyword as part of the Help text. A removed keyword generates an error message when parsed.

[local]host_name(config-ctx)# ssh generate key type v2-rsa

Configure the system to support SFTP:

[local]host_name(config-ctx)# server sshd [local]host_name(config-sshd)# subsystem sftp [local]host_name(config-sshd)# exit

For additional information about SSH, see Configuring SSH Options, on page 29

Configure the system to allow FTP access, if desired, by entering the following command:

[local]host_name(config-ctx)# server ftpd

For maximum system security, you should not enable FTP. In release 20.0 and higher Trusted StarOS builds, FTP is not supported

Exit the configuration mode by entering the following command:

[local]host_name(config-ctx)# end [local]host_name#

Step 7

Verify the configuration by entering the following command:

[local]host_name# show configuration

The CLI output should be similar to the sample output:

context local

interface interface_name

ip address ipaddress subnetmask

exit

subscriber default

exit

administrator admin_name password admin_password

no server telnetd

no server ftpd

ssh generate key

server sshd

subsystem sftp

exit

port ethernet 5/1

bind interface interface_name local

exit

port ethernet 5/1

no shutdown

exit

snmp engine-id local 800007e580ed826c191ded2d3d

end

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 61

Getting Started

Configuring SSH Options

Step 8

Step 9

Step 10

Verify the configuration of the IP routes by entering the following command:

[local]host_name# show ip route

The CLI output should be similar to the sample output:

"*" indicates the Best or Used route.

Destination Nexthop Protocol Prec Cost Interface

*0.0.0.0/0 ipaddress static 1 0 mio1 *network 0.0.0.0 connected 0 0 mio1

Verify the interface binding by entering the following command:

[local]host_name# show ip interface name interface_name

interface_name> is the name of the interface that was configured in step 7b.The CLI output should be similar to the

sample output:

Intf Name: mio1

Intf Type: Broadcast

Description:

IP State: UP (Bound to 5/1 untagged, ifIndex 83951617) IP Address: ipaddress Subnet Mask: subnetmask Bcast Address: bcastaddress MTU: 1500

Resoln Type: ARP ARP timeout: 3600 secs

Number of Secondary Addresses: 0

Save your configuration as described in Verifying and Saving Your Configuration.

Configuring SSH Options

SSHv2 RSA is the only version of SSH supported under StarOS. Keywords previously supported for SSHv1 RSA and SSHv2 DSA have been removed from or concealed within the StarOS CLI.

Important

A keyword that was supported in a previous release may be concealed in subsequent releases. StarOS continues to parse concealed keywords in existing scripts and configuration files created in a previous release. But the concealed keyword no longer appears in the command syntax for use in new scripts or configuration files. Entering a question mark (?) will not display a concealed keyword as part of the Help text. Removed keywords generate an error message when parsed.

Version 1 of the SSH protocol is now obsolete due to security vulnerabilities. The v1-rsa keyword has been removed for the Context Configuration mode ssh command. Running a script or configuration that uses the SSHv1-RSA key returns an error message and generates an event log. The output of the error message is shown below:

CLI print failure Failure: SSH V1 contains multiple structural vulnerabilities and is no longer considered secure. Therefore we don't support v1-rsa SSH key any longer, please generate a new v2-rsa key to replace this old one.

If the system boots from a configuration that contains the v1-rsa key, you can expect a boot failure when logging in through SSH. The workaround is to log in via the Console port, re-generate a new ssh v2-rsa key, and configure server sshd. It will then be possible to log in via ssh.

The v2-dsa keyword is now concealed for the Context Configuration mode ssh command

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 62

SSH Host Keys

Setting SSH Key Size

Getting Started

The v1-rsa keyword has been removed from the Exec mode show ssh key CLI command.

SSH key-based authentication uses two keys, one "public" key that anyone is allowed to see, and another "private" key that only the owner is allowed to see. You create a key pair, securely store the private key on the device you want to log in from, and store the public key on the system (ASR 5500) that you wish to log into.

SSH host keys are generated within a specified StarOS context. The context is associated with a user interface.

You set or remove an administrative user name having authorized keys for access to the sshd server associated with context.

The Global Configuration mode ssh key-size CLI command configures the key size for SSH key generation for all contexts (RSA host key only).

Step 1

Step 2

Enter the Global Configuration mode.

[local]host_name# configure [local]host_name(config)#

Specify the bit size for SSH keys.

[local]host_name(config)# ssh key-size { 2048 | 3072 | 4096 | 5120 | 6144 | 7168 | 9216 }

The default bit size for SSH keys is 2048 bits.

Configuring SSH Key Generation Wait Time

SSH keys can only be generated after a configurable time interval has expired since the last key generation. The ssh key-gen wait-time command specifies this wait time in seconds. The default interval is 300 seconds (5 minutes).

Step 1

Step 2

Enter the context configuration mode.

[local]host_name(config)# context context_name

[local]host_name(config-ctx)#

Specify the wait time interval.

[local]host_name(config-ctx)# ssh key-gen wait-time seconds [local]host_name(config-ctx)#

Notes:

seconds is specified as an integer from 0 through 86400. Default = 300

•

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 63

Getting Started

Specifying SSH Encryption Ciphers

The SSH Configuration mode ciphers CLI command configures the cipher priority list in sshd for SSH symmetric encryption. It changes the cipher options for that context.

SSH Host Keys

Step 1

Step 2

Enter the SSH Configuration mode.

[local]host_name(config-ctx)# server sshd

Specify the desired encryption algorithms.

[local]host_name(config-sshd)# ciphers algorithms

Notes:

algorithms is a string of 1 through 511 alphanumeric characters that specifies the algorithm(s) to be used as a single

•

string of comma-separated variables (no spaces) in priority order (left to right) from those shown below:

• blowfish-cbc – symmetric-key block cipher, Cipher Block Chaining, (CBC)

• 3des-cbc – Triple Data Encryption Standard, CBC

• aes128-cbc – Advanced Encryption Standard (AES), 128-bit key size, CBC

• aes128-ctr – AES, 128-bit key size, Counter-mode encryption (CTR)

• aes192-ctr – AES, 192-bit key size, CTR

• aes256-ctr – AES, 256-bit key size, CTR

• aes128-gcm@openssh.com – AES, 128-bit key size, Galois Counter Mode [GCM], OpenSSH

• aes256-gcm@openssh.com – AES, 256-bit key size, GCM, OpenSSH

• chacha20-poly1305@openssh.com – ChaCha20 symmetric cipher, Poly1305 cryptographic Message

Authentication Code [MAC], OpenSSH

Step 3

The default string for algorithms in a Normal build is:

blowfish-cbc,3des-cbc,aes128-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,

chacha20-poly1305@openssh.com

The default string for algorithms in a Trusted build is:

aes256-ctr,aes192-ctr,aes128-ctr

Exit the SSH Configuration mode.

[local]host_name(config-sshd)# end [local]host_name#

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 64

Authorized SSH User Access

Generating SSH Keys

The ssh generate command generates a public/private key pair which is to be used by the SSH server. The v1-rsa keyword has been removed from and the v2-dsa keyword concealed within the ssh generate CLI

command. The only keyword available for generating SSH keys is v2-rsa.

The generated key pair remains in use until the command is issued again.Important

Getting Started

Step 1

Step 2

Enter the context configuration mode:

[local]host_name(config)# context context_name [local]host_name(config-ctx)#

Generate an SSH key pair.

[local]host_name(config-ctx)# ssh generate key type v2-rsa [local]host_name(config-ctx)#

Setting SSH Key Pair

Specify the SSH key pair parameters.

[local]host_name(config-ctx)# ssh key data length octets type v2-rsa

Notes:

data is the encrypted key expressed as an alphanumeric string of 1 through 1023 characters

•

length octets is the length of the encrypted key in octets expressed as an integer from 0 through 65535

•

The ssh key command sets the public/private key pair to be used by the system. The v2-dsa keyword is concealed in the ssh key command.

type specifies the key type; v2-rsa is the only supported type.

•

Important

For releases prior to 20.0, StarOS supports a maximum of 64 configurable authorized SSH keys. For release 20.0 and higher, StarOS supports a maximum of 200 configurable authorized SSH keys.

Authorized SSH User Access

You must authorize users to access a StarOS context from a specific host with an SSH authentication-key pair.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 65

Getting Started

Authorizing SSH User Access

The SSH Configuration mode authorized-key command grants user access to a context from a specified host.

SSH User Login Restrictions

Step 1

Step 2

Go to the SSH Configuration mode.

[local]host_name(config-ctx)# server sshd

[local]host_name(config-sshd)#

Specify administrative user access via the authorized-key command.

[local]host_name(config-sshd)# authorized-key username user_name host host_ip [ type { v2-dsa | v2-rsa } ]

Notes:

username user_name specifies an existing StarOS administrator user name as having authorized keys for access

•

to the sshd server. The user_name is expressed as an alphanumeric string of 1 through 255 characters. User names should have been previously created via the Context Configuration mode administrator command using the nopassword option to prevent bypassing of the sshd keys. Refer to the System Settings chapter for additional information on creating administrators.

host host_ip specifies the IP address of an SSH host having the authorization keys for this username. The IP address

•

must be in IPv4 dotted-decimal or IPv6 colon-separated-hexadecimal notation.

type specifies the key type; v2-rsa is the only supported type.

•

SSH User Login Restrictions

An administrator can restrict SSH access to the StarOS CLI to a "white list" of allowed users. Access to a service may be restricted to only those users having a legitimate need. Only explicitly allowed users will be able connect to a host via SSH. The user name may optionally include a specific source IP address.

The AllowUsers list consists of user name patterns, separated by space. If the pattern takes the form 'USER' then login is restricted for that user. If pattern is in the format 'USER@IP_ADDRESS' then USER and IP address are separately checked, restricting logins to those users from the specified IP address.

The default is to allow unrestricted access by any user.

Creating an Allowed Users List

The allowusers add command allows an administrator to create a list of users who may log into the StarOS CLI.

Step 1

Enter the context configuration mode.

[local]host_name(config)# context context_name [local]host_name(config-ctx)#

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 66

SSH User Login Authentication

Getting Started

Step 2

Step 3

Step 4

Go to the SSH Configuration mode.

[local]host_name(config-ctx)# server sshd

Configure the SSH user list.

[local]host_name(config-sshd)# allowusers add user_list

user_list specifies a list of user name patterns, separated by spaces, as an alphanumeric string of 1 through 999 characters.

If the pattern takes the form 'USER' then login is restricted for that user.

If the pattern is in the format 'USER@IP_ADDRESS' then user name and IP address are separately checked, restricting logins to those users from that particular IP address.

If the pattern is in the format 'USER@<context>@IP_ADDRESS' then user name, StarOS context and IP address are separately checked, restricting logins to those users associated with the specific context from that particular IP address.

The following limits apply to the user_list:

The maximum length of this string is 3000 bytes including spaces.

•

The maximum number of AllowUsers, which is counted by spaces, is 256, which is consistent with the limit from

•

OpenSSH.

Important

If you exceed either of the above limits, an error message is displayed. The message prompts you to use a regular expression pattern to shorten the string, or remove all the allowusers with no allowusers add or default allowusers add and re-configure.

For additional information, see the SSH Configuration Mode Commands chapter in the Command Line Interface Reference.

Exit the SSH Configuration mode.

[local]host_name(config-sshd)# end [local]host_name#

SSH User Login Authentication

StarOS authenticates SSH user login attempts via authorized-key/user-account pairings for the following scenarios:

User tries to login with local context username through local context (VPN) interface with authorized-key

•

configured on local context.

User tries to login with non-local context username through non-local context interface with

•

authorized-key configured on non-local context.

User tries to login with local context username through non-local context interface with authorized-key

•

configured on local context.

User tries to login with non-local context username through local context interface with authorized-key

•

configured on non-local context.

A failure to authenticate based on the current system configuration prevents the login and generates an error message.

StarOS does not permit users with different user IDs but having the same public SSH key to login to an unauthorized context. Authentication of the user takes into account the authorized-key/user-account pairing.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 67

Getting Started

Secure Session Logout

Important

For StarOS release 21.0 onwards, a user cannot access the /flash directory if the user logs in from a non-local context.

Secure Session Logout

When StarOS is disconnected from an SSH client, the default behavior has sshd terminate the CLI or SFTP session in about 45 seconds (using default parameters). Two SSH Configuration mode CLI commands allow you to disable or modify this default sshd disconnect behavior.

Important

For higher security, Cisco recommends at least a client-alive-countmax of 2 and client-alive-interval of

5. Smaller session logout values may lead to occasional ssh session logouts. Adjust values to balance security and user friendliness.

The client-active-countmax command sets the number of client-alive messages which may be sent without sshd receiving any messages back from the SSH client (default =3). If this threshold is reached while the client-alive messages are being sent, sshd disconnects the SSH client thus terminating the session.

The client-alive-interval command sets a timeout interval in seconds (default = 15) after which if no data has been received from the SSH client, sshd sends a message through the encrypted channel to request a response from the client. The number of times that the message is sent is determined by the client-alive-countmax parameter. The approximate amount of time before sshd disconnects an SSH client disconnect = client-alive-countmax X client-alive-interval.

The client-alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive.

The client-alive messages are sent through the encrypted channel and, therefore, are not spoofable.Important

These parameter apply to SSH protocol version 2 only.Important

Changing Default sshd Secure Session Logout Parameters

The following command sequence modifies the default settings for the ClientAliveCountmax (default = 3) and ClientAliveInterval (default = 15 seconds) parameters.

Step 1

Step 2

Enter the context configuration mode.

[local]host_name# configure

Go to the SSH Configuration mode.

[local]host_name(config)# context context_name

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 68

SSH Client Login to External Servers

Getting Started

Step 3

Step 4

Step 5

Set the ClientAliveCountmax parameter to 2.

[local]host_name(config-sshd)# client-alive-countmax 2

Set the ClientAliveInterval parameter to 5 seconds.

[local]host_name(config-sshd)# client-alive-interval 5

Exit the SSH Configuration mode.

[local]host_name(config-sshd)# end [local]host_name#

SSH Client Login to External Servers

StarOS supports public key authentication for SSH/SFTP access from the StarOS gateway to external servers. You configure this feature by generating SSH client key pairs and pushing the client public key to external servers

By default StarOS only supports username-password authentication to external servers.Note

Setting SSH Client Ciphers

Step 1

Step 2

The SSH Client Configuration mode ciphers CLI command configures the cipher priority list when logging into an external server.

Enter the SSH Client Configuration mode.

[local]host_name(config)# client ssh

Specify the desired encryption algorithms.

[local]host_name(config-ssh)# ciphers algorithms

Notes:

algorithms is a string of 1 through 511 alphanumeric characters that specifies the algorithm(s) to be used as a single

•

string of comma-separated variables (no spaces) in priority order (left to right) from those shown below:

• blowfish-cbc – symmetric-key block cipher, Cipher Block Chaining, (CBC)

• 3des-cbc – Triple Data Encryption Standard, CBC

• aes128-cbc – Advanced Encryption Standard (AES), 128-bit key size, CBC

• aes128-ctr – AES, 128-bit key size, Counter-mode encryption (CTR)

• aes192-ctr – AES, 192-bit key size, CTR

• aes256-ctr – AES, 256-bit key size, CTR

• aes128-gcm@openssh.com – AES, 128-bit key size, Galois Counter Mode [GCM], OpenSSH

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 69

Getting Started

The default string for algorithms in a Normal build is:

aes256-ctr,aes192-ctr,aes128-ctr,aes256-gcm@openssh.com,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,

blowfish-cbc,3des-cbc,aes128-cbc

The default string for algorithms in a Trusted build is:

aes256-ctr,aes192-ctr,aes128-ctr

SSH Client Login to External Servers

• aes256-gcm@openssh.com – AES, 256-bit key size, GCM, OpenSSH

• chacha20-poly1305@openssh.com – ChaCha20 symmetric cipher, Poly1305 cryptographic Message

Authentication Code [MAC], OpenSSH

Step 3

Exit the SSH Client Configuration mode.

[local]host_name(config-ssh)# end [local]host_name#

Setting Preferred Authentication Methods

The SSH Client Configuration mode preferredauthentications CLI command configures the preferred methods of authentication.

Step 1

Step 2

Enter the SSH Client Configuration mode.

[local]host_name(config)# client ssh

Specify the preferred authentication methods.

[local]host_name(config-ssh)# preferredauthentications methods

Notes:

• methods – specifies the preferred methods of authentication to be used as a single string of comma-separated

variables (no spaces) in priority order (left to right) from those shown below:

• publickey – authentication via SSH v2-RSA protocol.

Step 3

• keyboard-interactive – request for an arbitrary number of pieces of information. For each piece of information

the server sends the label of the prompt.

• password – simple request for a single password

• default – resets the value of methods to: publickey,password

Exit the SSH Client Configuration mode.

[local]host_name(config-ssh)# exit [local]host_name(config)#

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 70

SSH Client Login to External Servers

Generating SSH Client Key Pair

You use commands in the SSH Client Configuration mode to specify a private key and generate the SSH client key pair.

Getting Started

Step 1

Step 2

Step 3

Step 4

Step 5

Enter the SSH client configuration mode.

[local]host_name(config)# client ssh [local]host_name(config-ssh)#

Enter SSH private key information and key type.

[local]host_name(config-ssh)# ssh key private_key_string length key_length [ type v2-rsa ] [local]host_name(config-ssh)#

key private_key_string specifies a private key value as an alphanumeric string of 1 through 4499 characters.

length key_length specifies the length of the key in bytes as an integer from 0 through 65535.

type v2-rsa specifies the SSH client key type. The only supported SSH client key type is v2-rsa.

Generate SSH client key pair.

[local]host_name(config-ssh)# ssh generate key [ type v2-rsa ] [local]host_name(config-ssh)#

type v2-rsa specifies the SSH client key type. The only supported SSH client key type is v2-rsa.

Verify that the SSH client key has been generated.

[local]host_name(config-ssh)# do show ssh client key

Exit the SSH Client Configuration mode.

[local]host_name(config-ssh)# exit [local]host_name(config)#

Pushing an SSH Client Public Key to an External Server

You must push the SSH client public key to an external server to support SSH/SFTP access to that server.

Step 1

From the Exec mode run the push ssh-key command.

[local]host_name# push ssh-key { host_name | host_ip_address } user username [ context context_name ] [local]host_name#

host_name specifies the remote server using its logical host name which must be resolved via DNS lookup. It is expressed as an alphanumeric string of 1 to 127 characters.

host_ip_address is expressed in IPv4 dotted-decimal or IPv6 colon-separated-hexadecimal notation.

user username specifies a valid username on the external server as an alphanumeric string of 1 to 79 characters.

context context_name specifies a valid context name. The context name is optional. If it is not provided the current

context is used for processing.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 71

Getting Started

Enabling NETCONF

Step 2 Step 3

Repeat Step 1 to support SSH/SFTP access on other external servers.

Test SSH client login to an external server.

local]host_name# ssh { hostname | ip_address } user username port port_number

Enabling NETCONF

An SSH key is a requirement before NETCONF protocol and the ConfD engine can be enabled in support of Cisco Network Service Orchestrator (NSO).

Refer to the NETCONF and ConfD appendix in this guide for detailed information on how to enable NETCONF.

Configuring the Management Interface with a Second IP Address

If necessary, you can configure a second IP address on the MIO/UMIO/MIO2 management interface.

Step 1

Enter the configuration mode by entering the following command at the prompt:

[local]host_name# configure [local]host_name(config)#

Step 2

Step 3

Step 4

Step 5

Step 6

Enter the following to enter the context configuration mode:

[local]host_name(config)# context local [local]host-name(config-ctx)#

Enter the interface slot number and port number by entering the following command:

[local]host_name(config-ctx)# 5/1 [local]host_name(config-if-eth)#

Enter the secondary IP address and subnet mask by entering the following command:

[local]host_name(config-if-eth)# { ip | ipv } address ipaddress subnet_mask secondary

Exit the configuration mode by entering the following command:

[local]host_name(config-if-eth)# end

Confirm the interface IP addresses by entering the following command:

[local]host_name# show config context local

The CLI output should look similar to this example:

config

context local

interface interface_name

ip address ipaddress subnetmask ip address ipaddress subnetmask secondary

#exit

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 72

Configuring the Management Interface with a Second IP Address

Getting Started

Step 7

Save your configuration as described in Verifying and Saving Your Configuration.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 73

CHAPTER 3

System Settings

This chapter provides instructions for configuring the following StarOS options.

It is assumed that the procedures to initially configure the system as described in Getting Started have been completed.

Important

The commands used in the configuration examples in this section are the most likely-used commands and/or keyword options. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information.

Configuring a Second Management Interface, page 42

•

Verifying and Saving Your Interface and Port Configuration, page 42

•

Configuring System Timing, page 43

•

Configuring SF Boot Configuration Pause, page 47

•

Enabling CLI Timestamping, page 47

•

Configuring CLI Confirmation Prompts, page 48

•

Configuring System Administrative Users, page 50

•

Configuring TACACS+ for System Administrative Users, page 60

•

Separating Authentication Methods, page 64

•

Configuring a Chassis Key, page 66

•

Configuring MIO/UMIO/MIO2 Port Redundancy, page 68

•

Configuring Data Processing Card Availability, page 72

•

Enabling Automatic Reset of FSC Fabric, page 73

•

Configuring ASR 5500 Link Aggregation, page 73

•

Configuring a Demux Card, page 80

•

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 74

Configuring a Second Management Interface

Refer to Getting Started for instructions on configuring a system management interface on the Management Input/Output (MIO/UMIO/MIO2) card. This section provides described how to configure a second management interface.

Use the following example to configure a second management interface:

configure

context local

interface interface_name

ip address ipaddress subnetmask exit

ip route 0.0.0.0 0.0.0.0 gw_address interface_name

exit port ethernet slot#/port#

bind interface interface_name local

no shutdown

media rj45

end

Notes:

System Settings

For port ethernet slot#, use the actual chassis slot in which the active MIO/UMIO/MIO2 resides (slot

•

number 5 or 6).

Enter IP addresses using IPv4 dotted-decimal or IPv6 colon-separated-hexadecimal notation.

•

• For port ethernet port#, use the physical port on the MIO/UMIO/MIO2 card – port 1 or 2.

The MIO/UMIO/MIO2 is equipped with RJ-45 (1000Base-T copper) interfaces. The RJ-45 interfaces

•

connect the system to the management network via CAT3 or CAT5 Ethernet cable.

Option: In the Ethernet Port configuration mode, configure the port speed, if needed, by entering the

•

medium command. Refer to the Command Line Interface Reference for a complete explanation of this command.

In the { ip | ipv6 } route command, other keyword options, instead of the gateway IP address, are

•

available and include: next-hop IP address, point-to-point, and tunnel.

Verifying and Saving Your Interface and Port Configuration

Verify that your interface configuration settings are correct by entering the following command:

show ip interface

The output from this command should be similar to that shown below. In this example an interface named mgmt2 was configured in the local context.

Intf Name: mgmt2 Intf Type: Broadcast Description: management2 VRF: None IP State: UP (Bound to 5/2) IP Address: 192.168.100.3 Subnet Mask: 255.255.255.0 Bcast Address: 192.168.100.255 MTU: 1500 Resoln Type: ARP ARP timeout: 60 secs L3 monitor LC-port switchover: Disabled Number of Secondary Addresses: 0

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 75

System Settings

Verify that the port configuration settings are correct by entering the following command:

show configuration port slot#/port#

slot# is the chassis slot number of the line card where the physical port resides. slot# is either 5 or 6. port# is

the number of the port (either 1 or 2).

This following command produces an output similar to the one shown below. It displays the configuration of port 2 of the MIO/UMIO/MIO2 installed in chassis slot 5. In this example, the port is bound to an interface called mgmt2.

config

port ethernet 5/2

description management2 no shutdown bind interface mgmt2 local

end

Save your configuration as described in the Verifying and Saving Your Configuration chapter.

Configuring System Timing

The system is equipped with a clock that supplies the timestamp for statistical counters, accounting records, logging, and event notification. After the initial configuration of the system clock, you can configure the system to communicate with one or more Network Time Protocol (NTP) server(s) to ensure that the clock is always accurate.

In the event of a power outage, the clock is maintained with an accuracy of + one minute per month for up to 10 years. This ensures that when power is restored, the system is ready to process sessions and generate accounting, log, and event data with accurate timestamps.

In addition to configuring the timing source, you must configure the system's time zone.

Setting the System Clock and Time Zone

Use the following command example to configure the system clock and time zone:

clock set date:time configure

clock timezone timezone [ local ]

end

Notes:

Enter the date and time in the format YYYY:MM:DD:HH:mm or YYYY:MM:DD:HH:mm:ss.

•

Refer to the online Help for the clock timezone command for a complete list of supported time zones.

•

The optional local keyword indicates that the time zone specified is the local timezone.

•

Daylight Savings Time is automatically adjusted for time zones supporting it.

•

Save your configuration as described in the Verifying and Saving Your Configuration chapter.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 76

Verifying and Saving Your Clock and Time Zone Configuration

Enter the following command to verify that you configured the time and time zone correctly:

show clock

The output displays the date, time, and time zone that you configured.

Configuring Network Time Protocol Support

This section provides information and instructions for configuring the system to enable the use of the Network Time Protocol (NTP).

System Settings

Important

Configure the system clock and time zone prior to implementing NTP support. This greatly reduces the time period that must be corrected by the NTP server.

Many of the services offered by the StarOS require accurate timekeeping derived through NTP. If the time reference(s) used by StarOS are not accurate, the services may be unreliable. For this reason it should be assumed that normal system operation requires that NTP be configured.

The system uses NTP to synchronize its internal clock to external time sources (typically GPS NTP sources, or other Stratum 2 or 3 servers, switches or routers).

By default, NTP is not enabled externally and should be configured when the system is initially installed. When enabled, the active MIO/UMIO/MIO2 will synchronize with external sources. If not enabled, the active MIO/UMIO/MIO2 will use its local clock as a time source. In the event of an NTP server or network outage, an already running MIO/UMIO/MIO2 will continue to use NTP to maintain time accuracy, but in a holdover mode.

All cards with CPUs synchronize to the active MIO/UMIO/MIO2 internally. This occurs even if an external NTP server is not configured. In the event of a MIO/UMIO/MIO2 switchover, all other cards will start synchronizing with the newly active MIO/UMIO/MIO2 automatically.

The system should have:

NTP enabled.

•

NTP configured for use in the local context only. Use of other contexts (which can be specified in the

•

enable configurable) will cause issues.

NTP configured for at least three external NTP servers. With three or more servers, outlyers and broken

•

or misconfigured servers can be detected and excluded. Generally, the more servers the better (within reason).

Important

ASR 5500 System Administration Guide, StarOS Release 21.4

Do not configure any external NTP servers using the prefer keyword. The NTP clock selection algorithms already have the built-in ability to pick the best server. Use of prefer usually results in a poorer choice than NTP can determine for itself.

Page 77

System Settings

Configuring NTP Servers with Local Sources

Important

Do not change the maxpoll, minpoll, or version keyword settings unless instructed to do so by Cisco TAC.

Use the following example to configure the necessary NTP association parameters:

configure

ntp

enable server ip_address1 server ip_address2 server ip_address3 end

Notes:

By default context_name is set to local. This is the recommended configuration.

•

A number of options exist for the server command. Refer to the NTP Configuration Mode Commands

•

chapter in the Command Line Interface Reference for more information.

Enter the IP address of NTP servers using IPv4 dotted-decimal or IPv6 colon-separated-hexadecimal

•

notation.

Configure the system with at least three (preferably four) NTP servers.Important

Save the configuration as described in the Verifying and Saving Your Configuration chapter.

Configuring NTP Servers with Local Sources

NTP can use network peers, local external clocks (such as GPS devices), or a local clock with no external source.

A local clock with no external source is usually a last-resort clock when no better clock is available. It is typically configured on a site's intermediate NTP server so that when a WAN network outage occurs, hosts within the site can continue to synchronize amongst themselves.

You can configure this in ntpd or on many commercially available NTP devices. This local clock should always have a high stratum number (8+) so that under normal conditions (when real sources are available) this local clock will not be used.

Using a Load Balancer

The NTP daemon and protocol assume that each configured server is running NTP. If a NTP client is configured to synchronize to a load balancer that relays and distributes packets to a set of real NTP servers, the load balancer may distribute those packets dynamically and confuse the NTP client. NTP packets are latency and jitter sensitive. Relaying them through a load balancer can confuse the NTP client and is not a supported practice.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 78

Verifying the NTP Configuration

Verify the NTP configuration is correct. Enter the following command at the Exec mode prompt:

show ntp associations

The output displays information about all NTP servers. See the output below for an example deploying two NTP servers.

remote refid st t when poll reach delay offset jitter ============================================================================== *10.81.254.202 .GPS. 1 u 160 1024 377 21.516 0.019 0.009

The following table describes the parameters output by the show ntp associations command.

System Settings

Table 3: NTP Parameters

remote

DescriptionColumn Title

List of the current NTP servers. One of these characters precedes each IP address to show the server's current condition:

( ) Rejected/No response

•

X False tick

•

. Excess

•

- Outlyer

•

+ Candidate

•

# Selected

•

* System peer

•

(o) PPS peer

•

Last reported NTP reference to which the server is synchronizing.refid

NTP server stratum level.st

Communication type: broadcast, multicast, etc.t

Number of seconds since the last contact.when

Polling interval between the system and the NTP server.poll

reach

Octal value of the reachability shift register indicating which responses were received for the previous eight polls to this NTP server.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 79

System Settings

Configuring SF Boot Configuration Pause

DescriptionColumn Title

delay

offset

Round-trip delay (in milliseconds) for messages exchanged between the system and the NTP server.

Number of milliseconds by which the system clock must be adjusted to synchronize it with the NTP server.

Jitter in milliseconds between the system and the NTP server.jitter

Configuring SF Boot Configuration Pause

Under certain circumstances, within VPC-DI deployments, the CF applies the boot configuration before all SFs have completed their boot process.

The following Configuration Mode command, wait cards active, pauses configuration until all specified cards are operational or the timeout period expires (whichever criteria is met first). The pause occurs immediately following local management context creation and ntp/snmp configuration.

This command corrects a scenario where SFs come online late following chassis load or reload and the configuration pertaining to those SFs is not applied (and thereby lost).

configure

[ no ] wait cards active { all | number } [ standby number ] timeout seconds end

Notes:

all: Pause until all active mode cards attain operational status.

•

number : Pause until the specified number of active mode cards attain operational status.number is 0

•

through the number of active mode cards.

standby number : (Optional) Also wait for the specified number of non-active mode cards to attain

•

operational status.

number is 0 through the number of service slots not configured for active mode SFs.

timeout seconds: Wait from 1 through 3600 seconds for the specified card set to attain operational status.

•

The wait is terminated early when or if this condition is satisfied. Otherwise the wait is terminated when the timeout period expires.

The following example command instructs the system to wait up to 120 seconds for all active cards and 1 standby card to become active:

wait cards active all standby 1 timeout 120

Enabling CLI Timestamping

To display a timestamp (date and time) for every command that is executed on the CLI, enter the following command at the root prompt for the Exec mode:

timestamps

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 80

Configuring CLI Confirmation Prompts

The date and time appear immediately after you execute the command.

Save the configuration as described in the Verifying and Saving Your Configuration chapter.

Configuring CLI Confirmation Prompts

A number of Exec mode and Global Configuration mode commands prompt users for a confirmation (Are you sure? [Yes|No]:) prior to executing the command.

This section describes configuration settings that:

Automatically confirm commands for the current CLI session (Exec mode) or for all CLI sessions and

•

users (Global Configuration mode).

Requires confirmation prompting only for the Exec mode configure command and autoconfirm

•

command.

Selectively requires confirmation of Exec mode configuration commands.

•

System Settings

Enabling Automatic Confirmation

You can use the autoconfirm command to disable confirmation prompting for configuration commands. The autoconfirm command is available in the Exec mode and Global Configuration mode. Enabling the autoconfirm

feature automatically supplies a "Yes" response to configuration command prompts, including for critical commands such as reload and shutdown. By default autoconfirm is disabled.

In the Exec mode, autoconfirm applies only to the current interactive CLI session.

In the Global Configuration mode, autoconfirm applies to all CLI sessions for all CLI users:

configure

autoconfirm end

To disable autoconfirm once it has been enabled, use the no autoconfirm command.

If commandguard is enabled, autoconfirm will disable commandguard.Important

Autoconfirm is intended as an "ease-of-use" feature. It presumes that the answer to "Are you sure? [Y/N]" prompts will be "Yes", and skips the prompt. Its use implies that the user is an expert who does not need these "safety-net" prompts.

Requiring Confirmation for autoconfirm and configure Commands

You can require confirmation prompting for the autoconfirm (Exec mode and Global Configuration mode) and configure (Exec mode) commands via the Global Configuration mode commandguard command.

Important

ASR 5500 System Administration Guide, StarOS Release 21.4

If autoconfirm is enabled, commandguard will not take effect until autoconfirm is disabled in both Exec and Global Configuration modes.

Page 81

System Settings

Requiring Confirmation for Specific Exec Mode Commands

The following command sequence enables the commandguard feature:

configure

commandguard end

With commandguard enabled the confirmation prompt appears as shown in the example below:

[local]host_name# configure Are you sure? [Yes|No]: yes [local]host_name(config)#

To disable commandguard once it has been enabled, use the no commandguard command.

The status of commandguard is output in show configuration commands.

Requiring Confirmation for Specific Exec Mode Commands

A keyword for the commandguard command allows you to apply mandatory prompting for specified categories of Exec mode configuration commands, even when autoconfirm is enabled.

The command syntax is as follows:

configure

commandguard exec-command exec_mode_category end

Notes:

exec-command exec_mode_category specifies one of the following categories of Exec mode configuration

•

commands.

card

◦

clear

◦

copy

◦

debug

◦

delete

◦

filesystem

◦

reload

◦

rename

◦

shutdown

◦

task

◦

upgrade

◦

You can enter multiple commandguard exec-command exec_mode_category commands.

•

All Exec mode commands beginning with the specified category word will prompt for confirmation,

•

regardless if autoconfirm is enabled.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 82

Configuring System Administrative Users

You can turn off confirmation prompting for a specific category using no commandguard exec-command

•

exec_mode_category.

If autoconfirm is overridden by commandguard exec-command for an Exec mode command, StarOS

•

displays an informational message indicating why autoconfirm is being overridden when you attempt to execute the command.

Users may selectively override confirmation prompting for any Exec mode configuration command that

•

supports the -noconfirm keyword.

For example, with commandguard exec-command card enabled, the confirmation prompt appears as shown below:

[local]host_name# card busy-out 1 Info: commandguard prevents autoconfirm of this command

Are you sure? [Yes|No]: yes [local]host_name#

Configuring System Administrative Users

System Settings

Important

Getting Started describes how to configure a context-level security administrator for the system.

This section provides instructions for configuring additional administrative users having the following privileges:

Security Administrators: have read-write privileges and can execute all CLI commands, including

•

those available to Administrators, Operators, and Inspectors

Administrators: have read-write privileges and can execute any command in the CLI except for a few

•

security-related commands that can only be configured by Security Administrators. Administrators can configure or modify system settings and execute all system commands, including those available to the Operators and Inspectors.

Operators: have read-only privileges to a larger subset of the Exec Mode commands. They can execute

•

all commands that are part of the inspector mode, plus some system monitoring, statistic, and fault management functions. Operators do not have the ability to enter the Config Mode.

Inspectors: are limited to a few read-only Exec Mode commands. The bulk of these are show commands

•

for viewing a variety of statistics and conditions. An Inspector cannot execute show configuration commands and does not have the privilege to enter the Config Mode.

Configuration instructions are categorized according to the type of administrative user: context-level or local-user.

For information on the differences between these user privileges and types, refer to Getting Started.

User Name Character Restrictions

User names can only contain alphanumeric characters (a-z, A-Z, 0-9), hyphen, underscore, and period. The hyphen character cannot be the first character. This applies to AAA user names as well as local user names.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 83

System Settings

If you attempt to create a user name that does not adhere to these standards, you will receive the following message: "Invalid character; legal characters are "0123456789.-_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".

Configuring Context-level Administrative Users

This user type is configured at the context-level and relies on the AAA subsystems for validating user names and passwords during login. This is true for both administrative user accounts configured locally through a configuration file or on an external RADIUS or TACACS+ server. Passwords for these user types are assigned once and are accessible in the configuration file.

This section contains information and instructions for configuring context-level administrative user types.

It is possible to configure the maximum number of simulations CLI sessions on a per account or per authentication method basis. It will protect certain accounts that may have the ability to impact security configurations and attributes or could adversely affect the services, stability and performance of the system. The maximum number of simultaneous CLI sessions is configurable when attempting a new Local-User login and a new AAA context-based login. If the maximum number of sessions is set to 0, then the user is authenticated regardless of the login type. When the CLI task starts, a check is complete to identify the count. In this case, the CLI determines that the sessions for that user is 1 which is greater than 0 and it will display an error message in the output, it generate starCLIActiveCount and starCLIMaxCount SNMP MIB Objects and starGlobalCLISessionsLimit and starUserCLISessionsLimit SNMP MIB Alarms.

Configuring Context-level Administrative Users

The max-sessions keyword for the local-user username Global Configuration Mode command configures the maximum number of simultaneous sessions available for a local user.

The max-sessions Context Configuration Mode command allows administrative users to configure the maximum simultaneous sessions allowed for corresponding users.

Refer to the Command Line Interface Reference for detailed information about these commands.

Configuring Context-level Security Administrators

Use the example below to configure additional security administrators:

configure

context local

administrator user_name { [ encrypted ] [ nopassword ] password password } end

Notes:

Additional keyword options are available that identify active administrators or place time thresholds on

•

the administrator. Refer to the Command Line Interface Reference for more information about the administrator command.

The nopassword option allows you to create an administrator without an associated password. Enable

•

this option when using ssh public keys (authorized key command in SSH Configuration mode) as a sole means of authentication. When enabled this option prevents someone from using an administrator password to gain access to the user account.

Save the configuration as described in the Verifying and Saving Your Configuration chapter.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 84

Configuring Context-level Administrative Users

Configuring Context-level Administrators

Use the example below to configure context-level configuration administrators:

configure

context local

config-administrator user_name { [ encrypted ] [ nopassword ] password password } end

Notes:

Additional keyword options are available that identify active administrators or place time thresholds on

•

the administrator. Refer to the Command Line Interface Reference for more information about the config-administrator command.

The nopassword option allows you to create a config-administrator without an associated password.

•

Enable this option when using ssh public keys (authorized key command in SSH Configuration mode) as a sole means of authentication. When enabled this option prevents someone from using a config-administrator password to gain access to the user account.

System Settings

Save the configuration as described in the Verifying and Saving Your Configuration chapter.

Configuring Context-level Operators

Use the example below to configure context-level operators:

configure

context local

operator user_name { [ encrypted ] [ nopassword ] password password } end

Notes:

Additional keyword options are available that identify active administrators or place time thresholds on

•

the administrator. Refer to the Command Line Interface Reference for more information about the operator command.

The nopassword option allows you to create an operator without an associated password. Enable this

•

option when using ssh public keys (authorized key command in SSH Configuration mode) as a sole means of authentication. When enabled this option prevents someone from using an operator password to gain access to the user account.

Save the configuration as described in the Verifying and Saving Your Configuration chapter.

Configuring Context-level Inspectors

Use the example below to configure context-level inspectors:

configure

context local

inspector user_name { [ encrypted ] [ nopassword ] password password } end

Notes:

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 85

System Settings

Additional keyword options are available that identify active administrators or place time thresholds on

•

the administrator. Refer to the Command Line Interface Reference for more information about the inspector command.

The nopassword option allows you to create an inspector without an associated password. Enable this

•

option when using ssh public keys (authorized key command in SSH Configuration mode) as a sole means of authentication. When enabled this option prevents someone from using an inspector password to gain access to the user account.

Save the configuration as described in the Verifying and Saving Your Configuration chapter.

Configuring LI Administrators

Configuring Context-level Administrative Users

Important

57.

Use the example below to configure a context-level LI administrator:

configure

context context_name

administrator user_name { [ encrypted ] [ nopassword ] password password li-administrator}

end

LI Administrators and non-LI Administrators can configure Lawful-Intercept CLI commands. However, only LI Administrators can view the encrypted Lawful-Intercept CLI commands in Trusted Builds and in Normal builds, if the Global Configuration mode require segregated li-configuration command is enabled. For additional information, see the Lawful Intercept Configuration Guide and Segregating System and LI

Configurations, on page 53 .

Segregating System and LI Configurations

Lawful Intercept (LI) configuration includes sensitive information. By default in a Normal build, an administrator without li-administration privilege can view the LI configuration commands. However, display of the LI configuration commands can be restricted or segregated from the rest of the system configuration.

The Global Configuration mode require segregated li-configuration command permanently segregates display of System and Lawful Intercept CLI. The CLI commands with Lawful-Intercept keyword are encrypted and can only be viewed by an administrator with li-administration privilege.

Important

In a Trusted build, LI segregation is turned on and cannot be disabled. The require segregated li-configuration command is invisible.

Segregating LI configuration from system configuration has the following impacts on StarOS:

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 86

Configuring Context-level Administrative Users

Only administrators with li-administration privilege can see Lawful Intercept CLI commands in the

•

output of the show configuration command.

Executing the save configuration command will automatically encrypt Lawful Intercept CLI configuration

•

commands.

When loading a saved configuration file via CLI command (for example, configure <url>), encrypted

•

Lawful Intercept CLI commands will be decrypted and executed only for an administrator with LI privilege. For an administrator without LI privilege, encrypted Lawful Intercept CLI commands will not be decrypted and executed.

During a system boot wherein the boot config is loaded, encrypted Lawful Intercept configuration will

•

be decrypted and loaded silently, in other words Lawful Intercept CLI configuration will not be visible on the console port.

The Exec mode configure command now supports a keyword that allows an LI administrator to load

•

only encrypted Lawful Intercept configuration from a saved configuration file (for example, configure encrypted <url>). The encrypted keyword can only be executed by an LI Administrator.

If you are running a system with encrypted Lawful Intercept configuration (segregated LI), the output

•

of the show boot initial-config command contains a line indicating whether it needed to run the second pass or not during the initial boot. This line displays "encrypted li" if the encrypted Lawful Intercept configuration was processed. If the line reads "encrypted li errors" then the second pass was not successful, or gave some output which was not expected or informational in nature.

System Settings

Note

A user with li-administration privileges can view the boot config output for the encrypted Lawful Intercept

•

configuration with the show logs encrypted-li command.

For a detailed description of the Global Configuration mode require segregated li-configuration and associated commands, see the Lawful Intercept CLI Commands appendix in the Lawful Intercept Configuration Guide.

The Lawful Intercept Configuration Guide is not available on www.cisco.com. Contact your Cisco account representative to obtain a copy of this guide.

In Release 21.4 and higher (Trusted builds only):

Users can only access the system through their respective context interface.

•

If the user attempts to log in to their respective context through a different context interface, that user

•

will be rejected.

Irrespective of whether the users are configured in any context with 'authorized-keys' or 'allowusers',

•

with this feature these users will be rejected if they attempt to log in via any other context interface other than their own context interface.

Users configured in any non-local context are required to specify which context they are trying to log

•

in to. For example:

ssh username@ctx_name@ctx_ip_addrs

Verifying Context-level Administrative User Configuration

Verify that the configuration was successful by entering the following command:

show configuration context local

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 87

System Settings

This command displays all of the configuration parameters you modified within the Local context during this session. The following displays sample output for this command. In this example, a security administrator named testadmin was configured.

config

context local

interface mgmt1

ip address 192.168.1.10 255.255.255.0 #exit subscriber default #exit administrator testadmin encrypted password fd01268373c5da85 inspector testinspector encrypted password 148661a0bb12cd59

exit

port ethernet 5/1

bind interface mgmt1 local

#exit

Configuring Local-User Administrative Users

The local user type supports ANSI T1.276-2003 password security protection. Local-user account information, such as passwords, password history, and lockout states, is maintained in /flash. This information is saved immediately in a separate local user database subject to AAA based authentication and is not used by the rest of the system. As such, configured local-user accounts are not visible with the rest of the system configuration.

Configuring Local-User Administrative Users

Important

In release 20.0 and higher Trusted StarOS builds, the local user database is disabled. The Global Configuration mode local-user commands, and Exec mode show local-user and update local-user commands are unavailable. For additional information on Trusted builds, see the System Operation and Configuration chapter.

Use the example below to configure local-user administrative users:

configure

local-user username name end

Notes:

Additional keyword options are available identify active administrators or place time thresholds on the

•

administrator. Refer to the Command Line Interface Reference for more information about the local-user username command.

For additional information on the local-user database, see Updating and Downgrading the local-user Database,

on page 56.

Verifying Local-User Configuration

Verify that the configuration was successful by entering the following command:

show local-user verbose

This command displays information on configured local-user administrative users. A sample output for this command appears below. In this example, a local-user named SAUser was configured.

Username: SAUser

Auth Level: secadmin Last Login: Never Login Failures: 0

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 88

Configuring Local-User Administrative Users

Password Expired: Yes Locked: No Suspended: No Lockout on Pw Aging: Yes Lockout on Login Fail: Yes

Updating Local-User Database

Update the local-user (administrative) configuration by running the following Exec mode command. This command should be run immediately after creating, removing or editing administrative users.

update local-user database

Updating and Downgrading the local-user Database

Prior to release 20.0, local-user passwords were hashed with the MD5 message digest-algorithm and saved in the local-user database. In release 20. 0, PBKDF2 (Password Based Key Derivation Function - Version 2) is now used to derive a key of given length, based on entered data, salt and number of iterations. Local-user account passwords are hashed using the PBKDF2 method with a randomly generated salt coupled with a large number of iterations to make password storage more secure.

When upgrading to release 20.0, existing user passwords in the local-user database are not automatically upgraded from MD5 to PBKDF2 hashing (only hashed password values are stored). Since hash functions are one-way, it is not possible to derive user passwords from the stored hash values. Thus it is not possible to convert existing hashed passwords to strongly hashed passwords automatically.

To update the database, a Security Administrator must run the Exec mode update local-user database CLI command. When this command is executed, StarOS reads the database from the /flash directory, reconstructs the database in the new format, and writes it back to the disk.

The database upgrade process does not automatically convert MD5 hashed passwords into the PBKDF2 format. StarOS continues to authenticate users using the old encryption algorithm. It flags the users using the old encryption algorithm with a "Weak Hash" flag. This flag appears in the output of the show local-user [verbose] Exec mode CLI command. When users re-login with their credentials, StarOS verifies the entered password using the MD5 algorithm, then creates a new hash using the PBKDF2 algorithm and then saves the result in the database. StarOS then clears the "Weak Hash" flag for that user.

System Settings

Important

Since hash functions are one-way, it is not possible to convert PBKDF2 hashed passwords to the MD5 format. The local-user database must be downgraded prior to reverting to StarOS releases prior to 20.0.

To downgrade the local-user database to use the MD5 hash algorithm, a Security Administrator must run the Exec mode downgrade local-user database command. StarOS prompts for confirmation and requests the Security Administrator to reenter a password. The entered password re-authenticates the user prior to executing the downgrade command. After verification, the password is hashed using the appropriate old/weak encryption algorithm and saved in the database to allow earlier versions of StarOS to authenticate the Security Administrator.

The downgrade process does not convert PBKDF2 hashed passwords to MD5 format. The downgrade process re-reads the database (from the /flash directory), reconstructs the database in the older format, and writes it back to the disk. Since the PBKDF2 hashed passwords cannot be converted to the MD5 hash algorithm, and earlier StarOS releases cannot parse the PBKDF2 encryption algorithm, StarOS suspends all those users encrypted via the PBKDF2 algorithm. Users encrypted via the MD5 algorithm ("Weak Hash" flag) can continue

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 89

System Settings

to login with their credentials. After the system comes up with the earlier StarOS release, suspended users can be identified in the output of the show local-user [verbose]command.

To reactivate suspended users a Security Administrator can:

Set temporary passwords for suspended users, using the Exec mode password change local-user

•

username command.

Reset the suspend flag for users, using the Configuration mode no suspend local-user username

•

command.

Provisioning Lawful Intercept

Lawful Intercept (LI) functionality allows a network operator to intercept control and data messages to and from targeted mobile users. Accompanied by a court order or warrant, a Law Enforcement Agency (LEA) initiates a request for the network operator to start the interception for a particular mobile user.

There are different standards followed for Lawful Intercept in different countries. The LI Configuration Guide describes how the feature works as well as how to configure and monitor the feature for each of the StarOS services that support Lawful Intercept. This guide is not available on www.cisco.com. It can only be obtained by contacting your Cisco account representative.

Provisioning Lawful Intercept

Security-related limitations on Lawful Intercept provisioning are described in Lawful Intercept Restrictions section of the System Security chapter.

LI can be provisioned within one or more StarOS contexts. An administrative user with li-administration privilege is associated with the context(s) that support LI capability. That administrator has access to the CLI configuration commands that provision LI functionality.

There are several types of LI configurations supported within a StarOS system configuration.

• No LI Context – The LI configuration was never entered for any context.

• Single LI Context – The LI configuration was entered within one context, but was never been entered

within any other context. In this state, the Single LI Context can be converted to Multiple LI contexts if another context is configured with an LI configuration, or this context can be converted into the Dedicated-LI context by entering the Context Configuration mode dedicated-li command.

• Multiple LI Contexts – Two or more contexts have been configured with the LI configuration. A

Multiple-LI context configuration can never be re-configured as any other type of LI configuration.

• Dedicated LI Context – If the existing system configuration is a No LI Context or a Single LI Context

system, it can be converted to a Dedicated-LI Context system by entering the Context Configuration mode dedicated-li command. A Dedicated LI context limits access to the LI configuration to the one VPN context which requires it. Once configured as a Dedicated-LI context system, it can never be

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 90

Restricting User Access to a Specified Root Directory

re-configured any other type of LI context system. Refer to the Lawful Intercept Configuration Guide before attempting to create a Dedicated-LI context.

Figure 6: LI Context Configurations

In Release 21.4 and higher (Trusted builds only):

Users can only access the system through their respective context interface.

•

System Settings

If the user attempts to log in to their respective context through a different context interface, that user

•

will be rejected.

Irrespective of whether the users are configured in any context with 'authorized-keys' or 'allowusers',

•

with this feature these users will be rejected if they attempt to log in via any other context interface other than their own context interface.

Users configured in any non-local context are required to specify which context they are trying to log

•

in to. For example:

ssh username@ctx_name@ctx_ip_addrs

Restricting User Access to a Specified Root Directory

By default an admin user who has FTP/SFTP access can access and modify any files under the /mnt/user/ directory. Access is granted on an "all-or-nothing" basis to the following directories: /flash, /cdrom, /hd-raid, /records, /usb1 and /usb2.

An administrator or configuration administrator can create a list of SFTP subsystems with a file directory and access privilege. When a local user is created, the administrator assigns an SFTP subsystem. If the user's authorization level is not security admin or admin, the user can only access the subsystem with read-only privilege. This directory is used as the user's root directory. The information is set as environmental variables passed to the openssh sftp-server.

You must create the SFTP root directory before associating it with local users, administrators and config administrators. You can create multiple SFTP directories; each directory can be assigned to one or more users.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 91

System Settings

Configuring an SFTP root Directory

The subsystem sftp command allows the assignment of an SFTP root directory and associated access privilege level.

configure

context local

server sshd

subsystem sftp [ name sftp_name root-dir pathname mode { read-only | readwrite } ]

Notes:

sftp_name is an alphanumeric string that uniquely identifies this subsystem.

•

pathname specifies the root directory to which SFTP files can be transferred. Options include:

•

/hd-raid/records/cdr

◦

/flash

◦

Restricting User Access to a Specified Root Directory

Associating an SFTP root Directory with a Local User

The local-user username command allows an administrator to associate an SFTP root directory with a specified username.

configure

local-user username user_name authorization-level level ftp sftp-server sftp_name password

password

exit

Associating an SFTP root Directory with an Administrator

The administrator command allows an administrator to associate an SFTP root directory for a specified administrator.

configure

context local

administrator user_name password password ftp sftp-server sftp_name

exit

Associating an SFTP root Directory with a Config Administrator

The config-administrator command allows an administrator to associate an SFTP root directory with a specified configuration administrator.

configure

context local

config-administrator user_name password password ftp sftp-server sftp_name

exit

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 92

Configuring TACACS+ for System Administrative Users

This section describes TACACS+ (Terminal Access Controller Access Control System+) AAA (Authentication Authorization and Accounting) service functionality and configuration on the ASR 5500.

Operation

TACACS+ is a secure, encrypted protocol. By remotely accessing TACACS+ servers that are provisioned with the administrative user account database, the ASR 5500 system can provide TACACS+ AAA services for system administrative users. TACACS+ is an enhanced version of the TACACS protocol that uses TCP instead of UDP.

The system serves as the TACACS+ Network Access Server (NAS). As the NAS the system requests TACACS+ AAA services on behalf of authorized system administrative users. For the authentication to succeed, the TACACS+ server must be in the same local context and network accessed by the system.

The system supports TACACS+ multiple-connection mode. In multiple-connection mode, a separate and private TCP connection to the TACACS+ server is opened and maintained for each session. When the TACACS+ session ends, the connection to the server is terminated.

TACACS+ is a system-wide function on the ASR 5500. TACACS+ AAA service configuration is performed in TACACS Configuration Mode. Enabling the TACACS+ function is performed in the Global Configuration Mode. The system supports the configuration of up to three TACACS+ servers.

Once configured and enabled on the system, TACACS+ authentication is attempted first. By default, if TACACS+ authentication fails, the system then attempts to authenticate the user using non-TACACS+ AAA services, such as RADIUS.

It is possible to configure the maximum number of simulations CLI sessions on a per account or per authentication method basis. It will protect certain accounts that may have the ability to impact security configurations and attributes or could adversely affect the services, stability and performance of the system. The maximum number of simultaneous CLI sessions is configurable when attempting a new TACACS+ user login. The recommendation is to use the max-sessions feature is through the TACACS+ server attribute option maxsess. The second way is though the StarOS CLI configuration mode TACACS+ mode using the maxsess keyword in the user-id command. If the maximum number of sessions is set to 0, then the user is authenticated regardless of the login type. When the CLI task starts, a check is complete to identify the count. In this case, the CLI determines that the sessions for that user is 1 which is greater than 0 and it will display an error message in the output, it generate starCLIActiveCount and starCLIMaxCount SNMP MIB Objects and starGlobalCLISessionsLimit and starUserCLISessionsLimit SNMP MIB Alarms.

System Settings

The max-sessions TACACS+ Configuration Mode command configures the maximum number of sessions available for TACACS+. Also the default option for the user-id TACACS+ Configuration Mode command configures the default attributes for a specific TACACS+ user identifier. Refer to the Command Line Interface Reference for detailed information about these commands.

Important

ASR 5500 System Administration Guide, StarOS Release 21.4

The user can define the maximum number of simulations CLI sessions available in both the StarOS and TACACS+ server configuration. However, this option is extremely discouraged.

Page 93

System Settings

User Account Requirements

Important

For releases after 15.0 MR4, TACACS+ accounting (CLI event logging) will not be generated for Lawful Intercept users with privilege level set to 15 and 13.

User Account Requirements

Before configuring TACACS+ AAA services, note the following TACACS+ server and StarOS user account provisioning requirements.

TACACS+ User Account Requirements

The TACACS+ server must be provisioned with the following TACACS+ user account information:

A list of known administrative users.

•

The plain-text or encrypted password for each user.

•

The name of the group to which each user belongs.

•

A list of user groups.

•

TACACS+ privilege levels and commands that are allowed/denied for each group.

•

Important

TACACS+ privilege levels are stored as Attribute Value Pairs (AVPs) in the network's TACACS+ server database. Users are restricted to the set of commands associated with their privilege level. A mapping of TACACS+ privilege levels to StarOS CLI administrative roles and responsibilities is provided in the table below.

To display the default mapping of TACACS+ privilege levels to CLI administrative roles, run the Exec mode show tacacs priv-lvl command. The default mapping varies based on the StarOS release and build type.

TACACS+ priv-levels can be reconfigured from their default StarOS authorization values via the TACACS+ Configuration mode priv-lvl and user-id commands. For additional information, see the TACACS+ Configuration Mode Commands chapter of the Command Line Interface Reference.

In release 20.0 and higher Trusted StarOS builds, FTP is not supported.Important

StarOS User Account Requirements

TACACS+ users who are allowed administrative access to the system must have the following user account information defined in StarOS:

username

•

password

•

administrative role and privileges

•

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 94

Configuring TACACS+ AAA Services

System Settings

Important

For instructions on defining users and administrative privileges on the system, refer to Configuring System Administrative Users.

Configuring TACACS+ AAA Services

This section provides an example of how to configure TACACS+ AAA services for administrative users on the system.

Caution

When configuring TACACS+ AAA services for the first time, the administrative user must use non-TACACS+ services to log into the StarOS. Failure to do so will result in the TACACS+ user being denied access to the system.

Use the example below to configure TACACS+ AAA services on the system:

configure

tacacs mode

server priority priority_number ip-address tacacs+srvr_ip_address end

Note:

server priority priority_number: Must be an integer from 1 to 3 (releases prior to 18.2) or 1 through

•

4 (releases 18.2+), that specifies the order in which this TACACS+ server will be tried for TACACS+ authentication. 1 is the highest priority, and 3 or 4 is the lowest. The priority number corresponds to a configured TACACS+ server.

Important

ip-address: Must be the IPv4 address of a valid TACACS+ server that will be used for authenticating

•

administrative users accessing this system via TACACS+ AAA services.

By default, the TACACS+ configuration will provide authentication, authorization, and accounting

•

services.

Enable TACACS+ on the StarOS:

configure

aaa tacacs+ end

For additional information, see Disable TACACS+ Authentication for Console, on page 64.

Save the configuration as described in the Verifying and Saving Your Configuration chapter.

For complete information on all TACACS+ Configuration Mode commands and options, refer to the TACACS Configuration Mode Commands chapter in the Command Line Reference.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 95

System Settings

Configuring TACACS+ for Non-local VPN Authentication

By default TACACS+ authentication is associated with login to the local context. TACACS+ authentication can also be configured for non-local context VPN logins. TACACS+ must configured and enabled with the option described below.

A stop keyword option is available for the TACACS+ Configuration mode on-unknown-user command. If TACACS+ is enabled with the command-keyword option, the VPN context name into which the user is attempting a login must match the VPN name specified in the username string. If the context name does not match, the login fails and exits out.

Without this option the login sequence will attempt to authenticate in another context via an alternative login method. For example, without the on-unknown-user stop configuration, an admin account could log into the local context via the non-local VPN context. However, with the on-unknown-user stop configuration, the local context login would not be attempted and the admin account login authentication would fail.

configure

tacacs mode

on-unkown-user stop ? end

Verifying the TACACS+ Configuration

This section describes how to verify the TACACS+ configuration.

Log out of the system CLI, then log back in using TACACS+ services.

Important

Once TACACS+ AAA services are configured and enabled on the StarOS, the system first will try to authenticate the administrative user via TACACS+ AAA services. By default, if TACACS+ authentication fails, the system then continues with authentication using non-TACACS+ AAA services.

At the Exec Mode prompt, enter the following command:

show tacacs [ client | priv-lvl | session | summary ]

The output of the show tacacs commands provides summary information for each active TACACS+ session such as username, login time, login status, current session state and privilege level. Optional filter keywords provide additional information.

An example of this command's output is provided below. In this example, a system administrative user named asradmin has successfully logged in to the system via TACACS+ AAA services.

active session #1:

login username : asradmin login tty : /dev/pts/1 time of login : Fri Oct 22 13:19:11 2011 login server priority : 1 current login status : pass current session state : user login complete current privilege level : 15 remote client application : ssh remote client ip address : 111.11.11.11 last server reply status : -1

total TACACS+ sessions : 1

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 96

Separating Authentication Methods

System Settings

Important

For details on all TACACS+ maintenance commands, refer to the Command Line Interface Reference.

Separating Authentication Methods

You can configure separate authentication methods for accessing the Console port and establishing SSH/telnet sessions (vty lines).

If you configure TACACS+ globally, access to the Console and vty lines are both authenticated using that method.

Since the Console port is a last resort access to StarOS, you can configure local authentication for the Console and employ TACACS+ for the vty lines.

Important

Disable TACACS+ Authentication for Console

This feature extends to AAA (Authentication, Authorization and Accounting) service as well as local users. For example, local-users may have only Console access and AAA (VPN context) users with access only via vty lines.

Separating authentication methods (Console versus vty lines) requires disabling Console access for users based on the type of authentication.

A noconsole keyword for the Global Configuration mode aaa tacacs+ command disables TACACS+ authentication on the Console line.

configure

aaa tacacs+ noconsole exit

By default, TACACS+ server authentication is performed for login from a Console or vty line. With noconsole enabled, TACACS+ authentication is bypassed in favor of local database authentication for a console line; on vty lines, TACACS+ remains enabled.

Important

When aaa tacacs+ noconsole is configured, a local user with valid credentials can log into a Console port even if on-authen-fail stop and on-unknown-user stop are enabled via the TACACS+ Configuration mode. If the user is not a TACACS+ user, he/she cannot login on a vty line.

Disable AAA-based Authentication for Console

A noconsole keyword for the Global Configuration mode local-user allow-aaa-authentication command disables AAA-based authentication on the Console line.

configure

local-user allow-aaa-authentication noconsole exit

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 97

System Settings

Disable TACACS+ Authentication at the Context Level

Since local-user authentication is always performed before AAA-based authentication and local-user allow-aaa-authentication noconsole is enabled, the behavior is the same as if no local-user allow-aaa-authentication is configured. There is no impact on vty lines.

This command does not apply for a Trusted build because the local-used database is unavailable.Important

Disable TACACS+ Authentication at the Context Level

When you enable aaa tacacs+ in the Global Configuration mode, TACACS+ authentication is automatically applied to all contexts (local and non-local). In some network deployments you may wish to disable TACACS+ services for a specific context(s).

You can use the no aaa tacacs+ Context Configuration command to disable TACACS+ services within a context.

configure

context ctx_name

no aaa tacacs+

Use the aaa tacacs+ Context Configuration command to enable TACACS+ services within a context where it has been previously disabled.

Important

AAA TACACS+ services must be enabled in the Global Configuration mode (all contexts) before you can selectively disable the services at the context level. You cannot selectively enable TACACS+ services at the context level when it has not been enabled globally.

Limit local-user Login on Console/vty Lines

As a security administrator when you create a StarOS user you can specify whether that user can login through the Console or vty line. The [ noconsole | novty ] keywords for the Global Configuration mode local-user

username command support these options.

configure

local-user username <username> [ noconsole | novty ] exit

The noconsole keyword prevents the user from logging into the Console port. The novty keyword prevents the user from logging in via an SSH or telnet session. If neither keyword is specified access to both Console and vty lines is allowed.

Important

Use of the noconsole or novty keywords is only supported on the new local-user database format. If you have not run update local-user database, you should do so before enabling these keywords. Otherwise, noconsole and novty keywords will not be saved in the local-user database. After a system reboot, all users will still be able to access the Console and vty lines. For additional information, see the Updating

and Downgrading the local-user Database, on page 56.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 98

Limit Console Access for AAA-based Users

This command does not apply for a Trusted build because the local-used database is unavailable.Important

Limit Console Access for AAA-based Users

AAA-based users normally login through on a vty line. However, you may want to limit a few users to accessing just the Console line. If you do not use the local-user database (or you are running a Trusted build), this needs to be done by limiting access to the Console line for other AAA-based users. Enable the noconsole keyword for all levels of admin users that will not have access to the Console line.

The noconsole keyword is available for the Context Configuration mode commands shown below.

configure

context <ctx_name>

administrator <username> { encrypted | nopassword | password } noconsole config-administrator <username> { encrypted | nopassword | password } noconsole inspector <username> { encrypted | nopassword | password } noconsole operator <username> { encrypted | nopassword | password } noconsole exit

The noconsole keyword disables user access to the Console line. By default noconsole is not enabled, thus all AAA-based users can access the Console line.

System Settings

Important

The local-user allow-aaa-authentication noconsole command takes precedence. In that case, all AAA-based users cannot access the Console line.

Verify Configuration Changes

You can verify changes made related to the separation of authentication methods via the Exec mode show configuration command. After saving the configuration changes, run show configuration |grep noconsole

and show configuration |grep novty. The output of these commands will indicate any changes you have made.

Configuring a Chassis Key

A chassis key should be configured for each system. This key is used to decrypt encrypted passwords found in configuration files.

Overview

The chassis key is used to encrypt and decrypt encrypted passwords in the configuration file. If two or more chassis are configured with the same chassis key value, the encrypted passwords can be decrypted by any of the chassis sharing the same chassis key value. As a corollary to this, a given chassis key value will not be able to decrypt passwords that were encrypted with a different chassis key value.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 99

System Settings

The chassis key is used to generate the chassis ID which is stored in a file and used as the master key for protecting sensitive data (such as passwords and secrets) in configuration files

For release 15.0 and higher, the chassis ID is an SHA256 hash of the chassis key. The chassis key can be set by users through a CLI command or via the Quick Setup Wizard. If the chassis ID does not exist, a local MAC address is used to generate the chassis ID.

For release 19.2 and higher, the user must explicitly set the chassis key through the Quick Setup Wizard or CLI command. If it is not set, a default chassis ID using the local MAC address will not be generated. In the absence of a chassis key (and hence the chassis ID), sensitive data will not appear in a saved configuration file. The chassis ID is the SHA256 hash (encoded in base36 format) of the user entered chassis key plus a 32-byte secure random number. This assures that the chassis key and chassis ID have 32-byte entropy for key security.

If a chassis ID is not available encryption and decryption for sensitive data in configuration files will not work.

Configuring a New Chassis Key Value

CLI Commands

Important

Use the Exec mode chassis key value key_string command to enter a new chassis key.

The key_string is an alphanumeric string of 1 through 16 characters. The chassis key is stored as a one-way encrypted value, much like a password. For this reason, the chassis key value is never displayed in plain-text form.

The Exec mode chassis keycheck key_string command generates a one-way encrypted key value based on the entered key_string. The generated encrypted key value is compared against the encrypted key value of the previously entered chassis key value. If the encrypted values match, the command succeeds and keycheck passes. If the comparison fails, a message is displayed indicating that the key check has failed. If the default chassis key (MAC address) is currently being used, this key check will always fail since there will be no chassis key value to compare against.

Use the chassis keycheck command to verify whether multiple chassis share the same chassis key value.

Important

For additional information, refer to the Exec Mode Commands chapter in the Command Line Interface Reference.

Beginning with Release 15.0, the chassis ID will be generated from the chassis key using a more secure algorithm. The resulting 44-character chassis ID will be stored in the same file.

Release 14 and Release 15 chassis IDs will be in different formats. Release 15 will recognize a Release 14 chassis ID and consider it as valid. Upgrading from 14.x to 15.0 will not require changing the chassis ID or configuration file.

Only a user with Security Administrator privilege can execute the chassis key value and chassis keycheck commands.

For release 19.2 and higher, in the absence of an existing chassis ID file the chassis keycheck command is hidden.

ASR 5500 System Administration Guide, StarOS Release 21.4

Page 100

Configuring MIO/UMIO/MIO2 Port Redundancy

However, if the chassis key is reset in Release 15 through the Quick Setup Wizard or CLI command, a new chassis ID will be generated in Release 15 format (44 instead of 16 characters). Release14 builds will not recognize the 44-character chassis ID. If the chassis is subsequently downgraded to Release 14, a new 16-character chassis ID will be generated. To accommodate the old key format, you must save the configuration file in pre-v12.2 format before the downgrade. If you attempt to load a v15 configuration file on the downgraded chassis, StarOS will not be able to decrypt the password/secrets stored in the configuration file.

For release 19.2 and higher, in a chassis where the chassis ID file already exists nothing is changed. However, if the chassis ID file is lost in both management cards, all existing configuration files become invalid. Entering a new chassis key that is the same as the original value will not resolve the issue because of the new method used to generate the chassis ID.

System Settings

Caution

After setting a new chassis key, you must save the configuration before initiating a reload. See the Verifying and Saving Your Configuration chapter.

Quick Setup Wizard

The Quick Setup Wizard prompts the user to enter a chassis key value. If a chassis key value is not entered a default chassis is generated using the chassis' MAC address (releases prior to 20.0).

For releases 20.0 and higher, if the chassis ID file does not exist, the Quick Setup Wizard prompts the user to enter a chassis key. A default chassis ID is not generated if a chassis key is not entered.

To run the Quick Setup Wizard, execute the Exec mode setup command.

[local]host_name# setup

1. Do you wish to continue with the Quick Setup Wizard[yes/no]: y

2. Enable basic configuration[yes/no]: y

3. Change chassis key value[yes/no]: y

4. New chassis key value: key_string

Configuring MIO/UMIO/MIO2 Port Redundancy

Port redundancy for MIO cards provides an added level of redundancy that minimizes the impact of network failures that occur external to the system. Examples include switch or router port failures, disconnected or cut cables, or other external faults that cause a link down error.

Caution

To ensure that system card and port-level redundancy mechanisms function properly, disable the Spanning Tree protocol on devices connected directly to any system port. Failure to turn off the Spanning Tree protocol may result in failures in the redundancy mechanisms or service outage.

By default, the system provides port-level redundancy when a failure occurs, or you issue the port switch to command. In this mode, the ports on active and standby MIO/UMIO/MIO2 cards have the same MAC address, but since only one of these ports may be active at any one time there are no conflicts. This eliminates the need to transfer MAC addresses and send gratuitous ARPs in port failover situations. Instead, for Ethernet ports, three Ethernet broadcast packets containing the source MAC address are sent so that the external network equipment (switch, bridge, or other device) can re-learn the information after the topology change. However, if card removal is detected, the system sends out gratuitous ARPs to the network because of the MAC address change that occurred on the specific port.

ASR 5500 System Administration Guide, StarOS Release 21.4

Cisco ASR 5000 Series, ASR 5500 Administration Manual

ASR 5500 System Administration Guide, StarOS Release 21.4

CONTENTS

About this Guide

Conventions Used

Related Documentation

MIOs and DPCs

Contacting Customer Support

System Operation and Configuration

System Management Overview

Terminology

Contexts

Ports

Logical Interfaces

Management Interface

Bindings

Services

AAA Servers

Subscribers

Trusted Builds

How the System Selects Contexts

Context Selection for Context-level Administrative User Sessions

Context Selection for Subscriber Sessions

Understanding the ASR 5500 Boot Process

Understanding Configuration Files

IP Address Notation

IPv4 Dotted-Decimal Notation

IPv6 Colon-Separated-Hexadecimal Notation

CIDR Notation

Alphanumeric Strings

Character Set

Quoted Strings

Getting Started

ASR 5500 Configuration

Using the ASR 5500 Quick Setup Wizard

The Quick Setup Wizard

Using the CLI for Initial Configuration

Configuring System Administrative Users

Limiting the Number of Concurrent CLI Sessions

Automatic Logout of CLI Sessions

Configuring the System for Remote Access

Configuring SSH Options

SSH Host Keys

Setting SSH Key Size

Configuring SSH Key Generation Wait Time

Specifying SSH Encryption Ciphers

Authorized SSH User Access

Generating SSH Keys

Setting SSH Key Pair

Authorizing SSH User Access

SSH User Login Restrictions

Creating an Allowed Users List

SSH User Login Authentication

Secure Session Logout

Changing Default sshd Secure Session Logout Parameters

SSH Client Login to External Servers

Setting SSH Client Ciphers

Setting Preferred Authentication Methods

Generating SSH Client Key Pair

Pushing an SSH Client Public Key to an External Server

Enabling NETCONF

Configuring the Management Interface with a Second IP Address

System Settings

Configuring a Second Management Interface

Verifying and Saving Your Interface and Port Configuration

Configuring System Timing

Setting the System Clock and Time Zone

Verifying and Saving Your Clock and Time Zone Configuration

Configuring Network Time Protocol Support

Configuring NTP Servers with Local Sources

Using a Load Balancer

Verifying the NTP Configuration

Configuring SF Boot Configuration Pause

Enabling CLI Timestamping

Configuring CLI Confirmation Prompts

Enabling Automatic Confirmation

Requiring Confirmation for autoconfirm and configure Commands

Requiring Confirmation for Specific Exec Mode Commands

Configuring System Administrative Users

User Name Character Restrictions