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.

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.

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.

+----Peer Selection: ( ) - Rejected / No Response 
|                    (x) - False Tick
|                    (.) - Excess
|                    (-) - Outlyer
|                    (+) - Candidate
|                    (#) - Selected
|                    (*) - System Peer
|                    (o) - PPS Peer
v
     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.

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.

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".

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.

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

configure
   local-user username name
   end

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

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.

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 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 1. LI Context Configurations

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

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.

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.

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.

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

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.

Log in to the system using non-TACACS+ services.

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

Enable TACACS+ on the StarOS:

configure
   aaa tacacs+
   end

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

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

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

This section describes how to verify the TACACS+ configuration.

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

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 

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

With port redundancy, if a failover occurs, only the specific port(s) become active. For example; if port 5/1 fails, then port 6/1 becomes active, while all other active ports on the line card in slot 5 remain in the same active state. In port failover situations, use the show port table command to check that ports are active on both cards and that both cards are active.

Take care when administratively disabling a port that is one of a redundant pair. A redundant pair comprises both the active and standby ports—for example 5/1 and 6/1. If 5/1 is active, administratively disabling 5/1 through the CLI does not make 6/1 active. It disables both 5/1 and 6/1 because an action on one port has the same effect on both. Refer to Creating and Configuring Ethernet Interfaces and Ports in System Interface and Port Configuration Procedures.

With automatic card-level redundancy, there is no port-level redundancy in an MIO/UMIO failover. The standby MIO/UMIO/MIO2 becomes active and all ports on that card become active. The system automatically copies all the MAC addresses and configuration parameters used by the failed MIO/UMIO/MIO2 to its redundant counterpart. The ports on MIOs keep their original MAC addresses, and the system automatically copies the failed MIO/UMIO/MIO2's configuration parameters to its redundant counterpart.

Port redundancy can be configured to be revertive or non-revertive. With revertive redundancy service is returned to the original port when service is restored.

This feature requires specific network topologies to work properly. The network must have redundant switching components or other devices that the system is connected to. The following diagrams show examples of a redundant switching topologies and how the system reacts to various external network device scenarios.

Figure 2. Network Topology Example Using MIO/UMIO Port Redundancy

Figure 3. Port Redundancy Failover in Cable Defect Scenario

In the example above, an Ethernet cable is cut or unplugged, causing the link to go down. When this event occurs, the system, with port-mode redundancy enabled, recognizes the link down state and makes port 6/1 the active port. The switching device, using some port redundancy scheme, recognizes the failure and enables the port on the secondary switch to which the MIO/UMIO/MIO2 in slot 6 is connected, allowing it to redirect and transport data.

Figure 4. Port Redundancy Failover in External Network Device Failure Scenario

In the example above, a switch failure causes a link down state on all ports connected to that switch. This failure causes all redundant ports on the line card in slot 6 to move into the active state and utilize the redundant switch.

As discussed in the Understanding the System Boot Process section of Understanding System Operation and Configuration, when the system initially boots up, all installed DPC/UDPCsor DPC2/UDPC2s are placed into standby mode. You must activate some of these cards in order to configure and use them for session processing. One DPC/UDPC or DPC2/UDPC2 may remain in standby mode for redundancy.

This section describes how to activate DPC/UDPCs or DPC2/UDPC2s and specify their redundancy.

Enter the following command to check the operational status of all DPC types:

show card table

This command lists the DPC types installed in the system by their slot number, their operational status, and whether or not the card is a single point of failure (SPOF).

Use the following example to configure DPC/UDPC or DPC2/UDPC2 availability:

configure
  card slot#
    mode { active | standby } 
    end

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

By default if an excessive number of discarded fabric egress packets occurred in the switch fabric, a manual reset of the Fabric Storage Card(s) is required for fabric recovery.

You can optionally enable automatic resets of FSCs if an excessive number of discarded fabric egress packets is detected.

A Global Configuration mode fabric fsc-auto-recover command enables or disables automatic FSC resets upon detection of an excessive number of discarded fabric egress packets.

The following command sequence enables this feature:

configure
   fabric fsc-auto-recovery { disable | enable } [ max-attempts [ number_attempts | unlimited ] ]
   end

max-attempts [ number_attempts | unlimited ] specifies how many times StarOS will attempt to reset each FSC as an integer from 1 to 99 or unlimited (will not stop until FSC is reset). The default setting is 1.

A Link Aggregation Group (LAG) works by exchanging control packets via Link Aggregation Control Protocol (LACP) over configured physical ports with peers to reach agreement on an aggregation of links as defined in IEEE 802.3ad. The LAG sends and receives the control packets directly on physical ports.

Link aggregation (also called trunking or bonding) provides higher total bandwidth, auto-negotiation, and recovery by combining parallel network links between devices as a single link. A large file is guaranteed to be sent over one of the links, which removes the need to address out-of-order packets.

You can dedicate a DPC/UDPC or DPC2/UDPC2, or MIO/UMIO/MIO2 to function as a demux card. Demux is a generic term for signal demultiplexing tasks. These are the tasks are responsible for parsing call setup (signaling packets) and distributing the calls internally. For this reason there almost as many tasks running on a demux card as there are services.

The vpnmgr tasks responsible for each context also run on the demux card. The number of vpnmgr tasks correspond to the number of contexts. A vpnmgr is responsible for IP address assignment to mobile equipment, IP routing (such as BGP, OSPF), as well as a variety of associated tasks.