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.

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.

Important

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

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.

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.

Important

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

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.

Important

The local-user allow-aaa-authentication noconsole command takes precedence. In that case, all AAA-based users cannot 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

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.

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.

You can configure a port auto-recovery feature. When a port failure occurs and the preferred port is returned to service (link is up), control is automatically returned to that port. By default, ports are in a non-revertive state, meaning that no ports are preferred; a manual port switch is required to return use to the original port.

Important

This feature is applied on a per port basis (via the preferred slot keyword), allowing you to configure specific ports to be used on individual MIO cards. For example, you could configure ports 10 through 19 as preferred on the MIO/UMIO in slot 5, and configure ports 20 through 29 as the preferred ports on the MIO/UMIO in slot 6.

Use the following example to configure a preferred port for revertive, automatic return to service when a problem has cleared:

configure 
   port ethernet slot#/port# 
      preferred slot slot# 
      end 

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

Verify that the configuration was successful. Enter the following command:

show card table 

Any DPC/UDPC or DPC2/UDPC2 that you made active should now have an operational status of Active.

Logical port configurations (VLAN and binding) are defined in the master port of the LAG. If the master port is removed because of a card removal/failure, another member port becomes the master port (resulting in VPN binding change and outage), unless there is a redundant master port available.

Important

The master port on which VLAN can be created for VPN binding must always be configured on the active/master MIO/UMIO. The redundancy between the MIO/UMIO in slot 5 and the MIO/UMIO in slot 6 automatically causes both ports to be the master with the same VLANs configured and active.

All ports in a LAG can be auto-switched to another MIO/UMIO when certain active port counts or bandwidth thresholds are crossed.

This feature connects subscriber traffic ports on MIOs to ports on Ethernet switches. A port failure/switch forces all ports in a LAG to switch to the other MIO/UMIO when a specified threshold is crossed. This works in a way similar to the auto-switch feature for port redundancy. LACP runs between the ASR 5500 and the Ethernet switch, exchanging relevant pieces on information, such as health status.

The following table summarizes typical LAG functionality on an MIO/UMIO card.

One port in an aggregation group is configured as a master so that all traffic (except control traffic) in the aggregation group logically passes through this port. It is recommended that you configure link-aggregation on the master port first when enabling LAG, and unconfigure the master port last when disabling LAG.

The following command creates link aggregation group N with port slot#/port# as master. Only one master port is allowed for a group. N must be in the range of [1–255].

configure 
   port ethernet slot#/port# 
      link-aggregation master group N 
      exit 

Important

Link Aggregation Control Protocol (LACP) starts running only when the master port is enabled.

Use the following command to add a port as member of link aggregation group number N only if the master port is assigned. Otherwise, it is added to the group when the master port is assigned:

   port ethernet slot#/port# 
      link-aggregation member group N 
      exit 

Important

The VPN can only bind the master port, and a VLAN can only be created on the master port. A failure message is generated if you attempt to bind to a link aggregation member port.

Each system that participates in link aggregation has a unique system ID that consists of a two-byte priority (where the lowest number [0] has the highest priority) and a six-byte MAC address derived from the first port's MAC address. The following command sets the system priority used to form the system ID. P is a hex in the range [0x0000..0xFFFF]. The default is 0x8000.

   card slot# 
      link-aggregation system-priority P 

Ports in a system are assigned keys. The group number maps directly to the key, whereupon only ports with the same key can be aggregated. Ports on each side of the link use a different aggregation key.

The system ID, port key and port ID of two peers form the Link Aggregation Group Identifier (LAGID). You can aggregate links having the same LAGID. Systems are often configured initially with each port in its own aggregation (requiring a separate key per port), or with all ports in the same aggregation (a single key for all ports). Negotiation via LACP would qualify the actual aggregation.

Systems exchange information about system ID, port key and port ID with peers across the physical links using LACP.

LACP packets are defined with the Slow Protocol format. Each system sends out its own ("actor") information and its last received information about its peer ("partner") over the physical link.

Use the following commands to set the LACP parameters. LACP can run in active mode to send LACP packets periodically, or in passive mode, in which it only responds to LACP packets it receives.

LACP can send packets at either a auto (30s) or fast (1s) rate. The defaults for this release are Active and Auto; see the sample configuration below:

config 
   port ethernet slot#/port# 
      link-aggregation lacp { active | passive } [ rate { auto | fast } | timeout { long | short } ] 

Peers send out LACP packets when the state changes or if a difference is found from a received LACP packet about its own state.

Corresponding ports on an MIO/UMIO redundant pair cannot be active at the same time. Redundant ports share the same MAC address, so after a failover is resolved, the original port rejoins the link aggregation group.

A minimum links option specifies that a Link Aggregation Group (LAG) is up (usable) only when a minimum number of links are available for aggregation. This guarantees that a minimum amount of bandwidth is available for use.

When this feature is enabled, a LAG is not usable when the number of links in a LAG goes below the configured min-link value. Switchover to another LAG bundle (if available) automatically occurs when the number of links in the current active bundle goes below the configured min-link value.

Use the min-link keyword option in the Global Configuration mode link-aggregation command to enable this feature.

configure 
   port ethernet slot/port 
      link-aggreagation master ( global | group } number 
         min-link number_links 
         end 

For L2 redundancy set the following option on the master port for use with the whole group:

link-aggregation redundancy standard [hold-time sec ] [preferred slot { card_number | none }  

Standard redundancy treats all cards in the group as one group.

When a LAG contains two sets of ports each connecting to a different switch, the operator has the ability to specify the slot/port (connected to the destination switch) when switching ports.

The Exec mode link-aggregation port switch to slot/port command configures this option. The slot/port is any valid port connected to the destination switch. The following criteria apply to the setting of this option:

LAG can be deployed in a non-redundant mode in which the ports from both MIO/UMIO cards are connected to the same switch.

As shown in the following figure, all ports in a LAG used on both the cards function in a non-redundant mode (Active/Active).

In the above configuration, there is a single, primary LAG. All ports work as a single bundle of ports that distribute the traffic.

Important

If you use the Ethernet Port Configuration mode shutdown command to shut down one of the ports on an MIO/UMIO card in this LAG configuration, by default the paired port on the other MIO/UMIO card will also be shut down. You can selectively disable an MIO/UMIO port in this LAG configuration using the Exec mode port { disable | enable } ethernet slot/port command.

Important

With this mode of operation, automatic ASR 5500 port redundancy is lost.

To achieve redundancy you must configure a second non-redundant LAG. You can use a higher layer load balancing mechanism such as ECMP (Equal Cost Multiple Path) routing to uniformly distribute the traffic across two LAG groups.

When one MIO/UMIO fails, half the ports from both the LAG groups will be available for distribution of the traffic from the other MIO/UMIO.

Configuring a second LAG group is not mandatory, but is the usual approach for achieving redundancy with this mode of LAG.

However, if the aggregating ports are loaded with more than 50% of their capacity and an MIO/UMIO failure/switchover occurs, the ASR 5500 configured port capacity is oversubscribed and an indeterminate amount of sessions are dropped and traffic lost.

The Global Configuration mode fast-data-plane-convergence command enables faster recovery of existing sessions in an Active-Active LAG configuration with aggressive MicroBFD timers. This feature can be enabled with an Active-Standby LAG configuration, however, reduced switchover time cannot be guaranteed.

This feature eliminates false positive detection of failure with an external switch and false positive ICSR failover with another ASR 5500.

configure 
  fast-data-plane-convergence 

Important

Active-Active LAG groups must be configured, along with aggressive microBFD timers (such as 150*3). During MIO card recovery BGP Sessions might flap based on the configuration. To avoid traffic loss during these events, BGP graceful restart must be configured with proper hold/keepalive and restart timers. See the description of the bgp graceful-restart command in the BGP Configuration Mode Commands chapter of the Command Line Interface Reference.

To check the status of link aggregation, use the following commands:

A single character is used to display LAG physical port status in the output of the show port table command. See the table below.

Designating a DPC/UDPC or DPC2/UDPC2, or MIO/UMIO as a demux card frees up resources for session handling, which has the potential to increase system throughput. However, there is no increased support in total subscriber capacity due to other system resource restrictions.

This feature is disabled by default and can be enabled via the Global Configuration mode require demux command. It is only supported for a limited number of products. Refer to the product Administration Guide for additional information.

To support this feature session recovery must also be enabled via the Global Configuration mode require session recovery command.

Important

After enabling demux card and session recovery, you must save the configuration and reboot the ASR 5500 to enable this feature.

Caution

Enabling the Demux on MIO/UMIO feature changes resource allocations within the system. This directly impacts an upgrade or downgrade between StarOS versions in ICSR configurations. Contact Cisco TAC for procedural assistance prior to upgrading or downgrading your ICSR deployment.

The following restrictions apply when enabling an MIO/UMIO as a demux card:

• The require demux management-card command must be configured before any service or contexts have been created on the system. The command will not execute after a mode of operation has been selected for the chassis.

• Only the following services currently support the designation of an MIO/UMIO card for demux functions: ePDG (StarOS Release 21.2 and later), GGSN, HeNBGW (StarOS Release 21.2 and later, SaMOG (StarOS Release 21.2 and later), SGW, PGW, HA, SAE-GW and L2TP LNS. These services are supported only when they are deployed as consumer gateways.

• SGSN, MME, HNBGW, HeNBGW (StarOS Release 21.1 and earlier), SaMOG (StarOS Release 21.1 and earlier), PDG, PDIF, ePDG (StarOS Release 21.1 and earlier), IPSG, PDSN, HSGW, L2TP LAC, NEMO, FA, and WSG are not supported. Enterprise or corporate gateways (GGSN, HA, PGW, etc.) are also not supported.

• You should not enable demux functionality on MIO/UMIO for configurations that require a large number of tunnels.

• After the ASR 5500 has booted with demux functions running on an MIO/UMIO, you cannot configure non-supported services. A maximum of eight Demux Managers are supported. Any attempt to add more than eight Demux Managers will be blocked.

• Service/products requiring a large number of VPN Managers, VRFs and/or Demux Managers must not enable demux functions on an MIO/UMIO.

• With demux functions running on an MIO/UMIO, the ASR 5500 supports a maximum of 10 contexts, 64 interfaces per context, and 250 VRFs per system.

• ICSR upgrades require compatible configurations and Methods of Procedure (MOPs).

Implementation of this feature assumes that CEPS (Call Events Per Second) and the number of subscribers will remain constant, and only the data rate will increase. This ensures that the CPU demand will not increase on the MIO/UMIO.

Note	If a process crash occurs in the background on a demux card, planned or unplanned migration of the card fails.

Important

Contact Cisco TAC for additional assistance when assessing the impact to system configurations when enabling the Demux on MIO/UMIO feature.

To configure a DPC/UDPC as a demux card enter the following CLI commands:

config 
  require demux processing-card 
  end 

To configure a DPC/2UDPC2 as a demux card enter the following CLI commands:

config 

  require demux processing-card 

  end 

To configure an MIO/UMIO as a demux card enter the following CLI commands:

config 

  require demux management-card 

  end