> Configuring System Settings
> This chapter provides instructions for configuring system options such as:

> • | Configuring a Second Management Interface

> • | Configuring System Timing

> • | Configuring Transmit Timing Source

> • | Enabling CLI Timestamping

> • | Configuring System Administrative Users

> • | Configuring Virtual MAC Addresses

> • | Configuring PAC/PSC and Line Card Availability

> • | Configuring Line Card and SPIO Port Redundancy

> • | Configuring Link Aggregation

> Important: The contents of this chapter assume that the procedures to initially configure the system in the Getting Started chapter have been completed.
> Important: The commands used in the configuration examples in this section are the most common or 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
> Refer to Getting Started for instructions on configuring a system management interface on the SPIO. This section provides instructions for configuring 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 | sfp ]
> end
> Notes:

> • | For port ethernet slot#, use the actual chassis slot in which the SPIO is installed. This could be either slot number 24 or 25.

> • | For port ethernet port#, use the physical port on the SPIO card that will be used. For the SPIO, this is either port 1 or 2. Port 1 represents the top-most port (either RJ-45 or SFP).

> • | The SPIO is equipped with dual RJ-45 and dual SFP interfaces. The RJ-45 interfaces connect the system to the management network with CAT3 or CAT5 Ethernet cable. The SFP interfaces connect the system to the management network with 1000Base-SX optical fiber 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.

> Verifying and Saving Your Interface and Port Configuration

> Step 1 | Verify that your interface configuration settings are correct by entering the following command:

> show ip interface
> The output from this command should look similar that shown below. In this example an interface named mgmt2 was configured in the local context.
> Intf Name: mgmt2
> IP State: UP (Bound to 24/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: 3600
> Number of Secondary Addresses: 0

> Step 2 | 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 24 or 25. port# is the number of the port (either 1 or 2).
> This command produces an output similar to the one shown below that displays the configuration of port 2 of the SPIO installed in chassis slot 24. In this example, the port is bound to an interface called mgmt2.
> config
> port ethernet 24/2
> description management2
> no shutdown
> bind interface mgmt2 local
> #exit
> end

> Step 3 | Save your configuration as described in the Saving Your Configuration chapter.

> Configuring System Timing
> The system is equipped with a system clock that supplies the timestamp for statistic 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) on the network 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:

> • | Refer to the clock timezone command in the Command Line Interface Reference 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.
> 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 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).
> 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.
> 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).
> 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.
> Use the following example to configure the necessary NTP association parameters:
> configure
> ntp
> enable [ <context_name> ]
> server <ip_address>
> end
> Notes:

> • | context_name is the name of a configured context other than local. Use this option to configure the system to run NTP in a specified context. By default, NTP runs in the local context. 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.

> Important: Configure the system with at least two NTP servers. We recommend four servers.
> Save the configuration as described in the Verifying and Saving Your Configuration chapter.
> Verifying the NTP Configuration

> Step 1 | 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
> | |  | (-) - Outlier
> | |  | (+) - Candidate
> | |  | (#) - Selected
> | |  | (*) - System Peer
> | |  | (o) - PPS Peer
> v |  |

> ‌

> remote | refid | st | t | when | poll | reach | delay | offset | jitter
> ===================================================================
> +192.68.11.1 | 192.68.11.55 | 3 | - | 677 | 1024 | 377 | 0.800 | 1.330 | 1.111
> #11.11.1.10 | 11.11.1.55 | 3 | - | 677 | 1024 | 377 | 0.725 | -3.134 | 0.112

> ‌
> The following table describes the show ntp associations output table.

> Column Title | Description
> remote | Lists 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
> • | - Outlier
> • | + Candidate
> • | # Selected
> • | * System peer
> • | (o) PPS peer
> refid | Shows the last reported NTP reference to which the server is synchronizing.
> st | Shows the NTP server stratum level.
> t | Shows the communication type: broadcast, multicast, etc.
> when | Shows the number of seconds since the last contact.
> poll | Shows the polling interval between the system and the NTP server.
> reach | Shows the octal value of the reachability shift register indicating which responses were received for the previous 8 polls to this NTP server.
> delay | Shows the round-trip delay (in milliseconds) for messages exchanged between the system and the NTP server.
> offset | Shows the number of milliseconds by which the system clock must be adjusted to synchronize it with the NTP server.
> jitter | Shows the jitter in milliseconds between the system and the NTP server.

> ‌
> Configuring Transmit Timing Source
> This feature is only for application services that use SDH or SONET over the Optical or Channelized line cards.
> In general, the SPIO automatically provides clocking based on the system clock. However, some application services that use SDH or SONET require greater clocking precision to ensure synchronous transmission. The timing source options include Building Integrated Timing Supply (BITS-timing) and line-timing. BITS-timing uses Stratum 3-compliant BITS modules resident on the SPIOs. The line-timing recovers the receive timing from an external clock through a specified port on an Optical or Channelized line card. The timing is then distributed via the SPIO to all line cards in the chassis.
> Important: To use BITS-timing, the SPIO version must include the BITS BNC timing interface or the BITS 3-pin timing interface. For additional interface information, refer to the Product Overview.
> You can enable and configure up to four timing sources: two BITS-timing and two line-timing sources. Having more than one timing source ensures back-up. If BITS-timing is enabled, it always takes priority over line-timing to provide the clocking.
> Configure BITS as the Timing Source
> Use the following example to configure BITS as the timing source:
> configure
> port bits <slot#/port#>
> mode <e1/t1> framing <type>
> no shutdown
> end
> Save the configuration according to the steps in the Verifying and Saving Your Configuration chapter.
> Configure Line-timing as the Timing Source
> Use the following example to configure line-timing as the timing source:
> configure
> port atm <slot#/port#>
> line-timing
> no shutdown
> exit
> port bits <slot#/port#>
> recover line1 <linecard slot #>
> shutdown
> end
> Save the configuration as described in the Verifying and Saving Your Configuration chapter.
> Configure Both BITS and Line as Timing Sources
> Use the following example to configure both BITS and line-timing as the timing sources:
> configure
> card <CLC slot#>
> framing <mode>
> exit
> port atm <OLC slot#/port#>
> line-timing
> no shutdown
> exit
> port channelized <CLC slot#/port#>
> line-timing
> no shutdown
> exit
> port bits <slot#/port#>
> recover line1 <LC slot#/port#>
> recover line2 <LC slot#/port#>
> no shutdown
> end
> Save the configuration as described in the Verifying and Saving Your Configuration chapter.
> Confirming the Timing Source
> Use the show timing command, documented in the Exec Mode Commands chapter of the Command Line Interface Reference, to confirm the timing source has been configured correctly.
> 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
> Immediately after you execute the command, the date and time appear.
> Save the configuration as described in the Verifying and Saving Your Configuration chapter.
> Configuring System Administrative Users
> The Getting Started chapter describes how to configure a context-level security administrator for the system.
> This section provides instructions for configuring additional administrative users of each of the following privileges:

> • | security administrator

> • | administrator

> • | operator

> • | inspector

> Instructions are categorized according to the type of administrative user: context-level, or local-user.
> Important: For information on the differences between these user privileges and types, refer to the Getting Started chapter.
> If your deployment does not require the configuration of additional administrative users, proceed to the Configuring PSC and Line Card Availability section.
> Configuring Context-level Administrative Users
> This section contains information and instructions for configuring context-level administrative user types.
> Configuring Context-level Security Administrators
> Use the example below to configure additional security administrators:
> configure
> context local
> administrator <name> { password <pwrd> | encrypted password <pwrd> }
> end
> Notes:

> • | Additional keyword options are available that, for example, identify the administrator when active or place time thresholds on the administrator. Refer to the Command Line Interface Reference for more information about the administrator command.

> Save the configuration as described in the Verifying and Saving Your Configuration chapter.
> Configuring Context-level Administrators
> Use the example below to configure context-level administrators:
> configure
> context local
> config-administrator <name> { password <pwrd> | encrypted password <pwrd> }
> end
> Notes:

> • | Additional keyword options are available that, for example, identify the administrator when active or place time thresholds on the administrator. Refer to the Command Line Interface Reference for more information about the config-administrator command.

> 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 <name> { password <pwrd> | encrypted password <pwrd> }
> end
> Notes:

> • | Additional keyword options are available that for example, identify the administrator when active or place time thresholds on the administrator. Refer to the Command Line Interface Reference for more information about the operator command.

> 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 <name> { password <pwrd> | encrypted password <pwrd> }
> end
> Notes:

> • | Additional keyword options are available that, for example, identify the administrator when active or place time thresholds on the administrator. Refer to the Command Line Interface Reference for more information about the inspector command.

> Save the configuration as described in the Verifying and Saving Your Configuration chapter.
> Verifying Context-level Administrative User Configuration
> Verify that the configuration was successful by entering the following command:
> show configuration context local
> This command displays all of the configuration parameters you modified within the Local context during this session. The following displays a command output sample. 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 24/1
> bind interface mgmt1 local
> #exit
> end
> Configuring Local-User Administrative Users
> Use the example below to configure local-user administrative users:
> configure
> local-user username <name>
> end
> Notes:

> • | Additional keyword options are available that, for example, identify the administrator when active or place time thresholds on the administrator. Refer to the Command Line Interface Reference for more information about the local-user username command.

> Save the configuration as described in the Verifying and Saving Your Configuration chapter.
> 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. The output below displays a sample of this command’s output. In this example, a local-user named SAUser was configured.
> Username: SAUser
> Auth Level: secadmin
> Last Login: Never
> Login Failures: 0
> Password Expired: Yes
> Locked: No
> Suspended: No
> Lockout on Pw Aging: Yes
> Lockout on Login Fail: Yes
> Configuring Virtual MAC Addresses
> When you enable virtual MAC addressing, a single block of 256 addresses is added to the system configuration. The MAC addresses assigned and stored in the IDEEPROM on Ethernet Line Cards are disregarded; MAC addresses for all ports on all Ethernet Line Cards are assigned from the specified block of virtual MAC addresses. This does not affect the MAC addresses on SPIO cards.
> As in normal MAC address assignments, the corresponding ports on the upper and lower line cards have the same assigned MAC address. When you enable virtual MAC addressing, these addresses are all assigned from the specified block of 256 addresses.
> If you enable virtual MAC addressing and remove a line card from the system, MAC addresses do not have to be reassigned because the MAC addresses in use do not belong to any line card. Therefore, if a line card is removed from the system, there is no possibility that any port on a linecard in the system is using any of the MAC addresses that belong to the removed line card.
> Use the following example to configure virtual MAC addressing:
> configure
> port mac-address virtual-base-address <MAC_Address>
> end
> Notes:

> • | MAC_Address is the first address of a block of 256 MAC addresses. The system has reserved 65536 MAC addresses (00:05:47:FF:00:00 - 00:05:47:FF:FF:FF) for use by customers. This range allows you to create 256 address blocks each containing 256 MAC addresses (e.g., 00:05:47:FF:00:00, 00:05:47:FF:01:00, 00:05:47:FF:02:00, 00:05:47:FF:03:00, 00:05:47:FF:04:00, etc.).

> Caution: This configuration requires a valid block of unique MAC addresses that are not used anywhere else. The use of non-unique MAC addresses can degrade and impair the operation of your network.
> Save your configuration as described in the Verifying and Saving Your Configuration chapter.
> Verifying Virtual MAC Address Configuration
> Verify port information by entering the following command
> show port info <slot#/port#>
> slot# is the chassis slot number of the line card on which the physical port resides. port# is the physical port on the line card.
> The output of this command should be similar to that shown in the example below.
> Port: 36/8
> Port Type : 10/100 Ethernet
> Description : (None Set)
> Controlled By Card : 4 (Packet Accelerator Card)
> Redundancy Mode : Port Mode
> Redundant With : 20/8
> Preferred Port : Non-Revertive
> Physical ifIndex : 604504064
> Administrative State : Enabled
> Configured Duplex : Auto
> Configured Speed : Auto
> MAC Address : 00-05-47-02-04-3F
> Link State : Up
> Link Duplex : Full
> Link Speed : 100 Mb
> Logical ifIndex : 604504065
> Operational State : Down, Standby
> Configuring Packet Processing and Line Card Availability
> As discussed in the Understanding the System Boot Process section of Understanding System Operation and Configuration, when the system boots up, all installed PSCs/PSC2s are placed into standby mode. You must activate some of these cards in order to configure and use them for session processing. Others may remain in standby mode to serve as redundant components.
> When you activate an application card, the line card behind it shows up as attached and in a Ready state. Only when you bind a logical interface to one of the ports of the line card pair will the line cards assume an active and standby state.
> This section provides instructions for activating PSCs/PSC2s and specifying their redundancy.
> Important: Refer to the Product Overview Guide for information about system hardware configurations and redundancy.
> Enter the following command to check the application card’s operational status:
> show card table
> This command lists the PSCs/PSC2s and RCCs installed in the system by their slot number, their operational status, whether or not the card is a single point of failure (SPOF), and its attachment to a line card.
> Important: For an ASR 5000, the output of this command would have indicated “PSC” or “PSC2”.
> Check the line card operational status by entering the following command:
> show linecard table
> This command lists the line cards installed in the system by their slot number, their operational status, whether or not the card is a single point of failure (SPOF), and its attachment to a PSC/PSC2 or SMC.
> Use the following example to configure PSC/PSC2 and line card availability:
> configure
> card <slot_#>
> mode active { pac | psc }
> exit
> card-standby-priority <slot#_p1 slot#_p2 ... slot#_pn>
> end
> Notes:

> • | When activating cards, remember to keep at least one card in standby mode for redundancy.

> • | Repeat for every other /PSC in the chassis that you wish to activate.

> • | The card-standby-priority specifies the order in which the system will use standby PSCs as redundant components.

> • | By default, the system uses the standby PSC or PSC2 in the highest-numbered slot (slot 16) as the first card to use for redundancy. This step is required if there are processing cards installed in the system that are in standby mode, and you want to configure the system to use an order other than the default.

> • | slot#_p1 is the chassis slot number of the standby PSC/PSC2 that you want to use first as a redundant component. slot#_p2 is the chassis slot number of the standby processing card that you want to use second as a redundant component. slot#_pn is the chassis slot number of the standby PSC that you want to use as the last redundant component.

> Example
> A system has three PSCs or PSC2s that are in standby mode. They are installed in chassis slots 14, 15, and 16. If an active processing card fails, and you want the PSC in slot 15 to replace the failed PSC followed by the PSC in slot 14, enter the following command:
> card-standby-priority 15 14
> In the unlikely event that the PSCs in chassis slots 15 and 14 are unavailable, the system automatically uses the remaining standby PSC in slot 16 for redundancy.
> Save the configuration as described in the Verifying and Saving Your Configuration chapter.
> Verifying Packet Processing and Line Card Configurations
> Verify that the configuration was successful. Depending on the type of card(s) you activated, enter either or both of the following commands:
> show card table
> show linecard table
> Any card that you made active should now have an operational status of Active.
> Configuring Line Card and SPIO Port Redundancy
> Port redundancy for line cards and SPIOs 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 line 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 line cards (for example, 17/1 and 33/1 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 an line 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 17/1 fails, then port 33/1 becomes active, while all other active ports on the line card in slot 17 remain in the same active state. In port failover situations, use the show port table or show linecard table commands 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 17/1 and 33/1. If 17/1 is active, administratively disabling 17/1 through the CLI does not make 33/1 active. It disables both 17/1 and 33/1 because an action on one port has the same effect on both. Refer to Enabling Line Card and SPIO Redundancy below and Creating and Configuring Ethernet Interfaces and Ports in the System Element Configuration Procedures chapter.
> If card-level redundancy is initiated, there is no port-level redundancy in a line card or SPIO failover. The standby line card or SPIO becomes active and all ports on that card become active. With line cards, the system automatically copies all the MAC addresses and configuration parameters used by the failed line card to its redundant counterpart. The ports on SPIOs keep their original MAC addresses, and the system automatically copies the failed SPIO’s configuration parameters to its redundant counterpart. The PAC/PSC automatically re-routes to its redundant line card.
> With the SPIO cards, any time there is a port or card switch gratuitous ARPs are sent.
> Important: Be aware that in the case of a system with only one SMC and two SPIO cards, both SPIOs come up online. Automatic switching of Ethernet ports does not occur in this scenario, but you can initiate card and port switching by using the card spio switch to and port switch to commands.
> 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.
> Network Topology Example Using Line Card Port Redundancy
> PortRedundancyFailover 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 33/1 the active port. The switching devices, using some port redundancy scheme, recognizes the failure and enables the port on the secondary switch that the line card in slot 33 is connected to, allowing it to redirect and transport data.
> 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 33 to move into the active state and utilize the redundant switch.
> Enabling Line Card and SPIO Port Redundancy
> Use the following example to enable port redundancy:
> configure
> card <slot_#>
> redundancy { card-mode | mixed-mode | port-mode }
> end
> Notes:

> • | The card-mode keyword indicates that no port redundancy is used. The system provides card-level redundancy, which is triggered by an internal failure. The port-mode keyword, available for Ethernet and SPIO line cards, indicates that port redundancy will be enabled. This is the default redundancy mode.

> Important: You do not need to use this configuration for each line card or SPIO. The system intuitively understands that if the command is entered for an active line card, the standby line will operate in the same mode. For example, if you enter the command for the line card in slot 17, it automatically places the line card in Slot 33 into port redundant operation.
> Important: If you network-boot a dual-SMC chassis with SPIO port redundancy enabled, you should have CFE1.1.0 or greater in flash on both SMCs. Otherwise, you risk having a standby SMC that can't boot from the network in certain circumstances. You can use any version of the CFE with SPIO port redundancy if the SMCs boot from a local file system (/flash, /pcmcia1, or /pcmcia2).
> Save the configuration as described in the Verifying and Saving Your Configuration chapter.
> Verifying Line Card and SPIO Port Redundancy
> View the configuration of the card by entering the following command:
> show configuration card <slot_#>
> slot_# is the chassis slot number where the line card or SPIO you want to configure is installed.
> The following is a sample of output for an line card in slot 17 and a SPIO in slot 24 that both have redundancy enabled.
> [local]host_name# show config card 17
> config
> card 17
> redundancy port-mode
> #exit
> end
> [local]host_name# show config card 24
> config
> card 24
> redundancy port-mode
> #exit
> end
> Configuring Line Card and SPIO Port Redundancy Auto-Recovery
> When port redundancy is enabled at the card level, 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, requiring a manual port switch to return use to the original port.
> Important: This feature is applied on a per port basis, allowing you to configure specific ports to be used on individual line cards or SPIOs. For example, you could configure ports 1 through 4 as preferred on the line card in slot 17, and configure ports 5 through 8 as the preferred ports on the line card in slot 33. On a SPIO, you could configure port 1 as preferred on the SPIO in slot 24 and configure port 2 as preferred on the SPIO in slot 25. In this scenario, both line cards or SPIOs would be in an active state while providing line card and port redundancy for the other.
> 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
> Notes

> • | If you do not specify a preference, redundancy is non-revertive. If you do specify a preference, redundancy is revertive to the specified card.

> • | Repeat for each additional port that you want to make preferred.

> Caution: A preference cannot be configured in normal redundancy mode. Attempting to do so will produce an error message from the cli command.
> Save the configuration as described in the Verifying and Saving Your Configuration chapter.
> Verifying Line Card and SPIO Port Redundancy Auto-Recovery
> Verify port information by entering the following command
> show port info <slot#/port#>
> slot# is the chassis slot number of the line card on which the physical port resides.
> port# is the physical port on the line card.
> The following shows a sample output of this command for port 1 on the LC in slot 17:
> [local]host_name# show port info 17/1
> Port: 17/1
> Port Type : 10/100 Ethernet
> Description : (None Set)
> Controlled By Card : 1 (Packet Accelerator Card)
> Redundancy Mode : Port Mode
> Redundant With : 33/1
> Preferred Port : Revertive to port 17/1
> Physical Index : 285278208
> Administrative State : Disabled
> Configured Duplex : Auto
> Configured Speed : Auto
> MAC Address : 00-05-47-01-11-00
> Link State : Up
> Link Duplex : Unknown
> Link Speed : Unknown
> Logical ifIndex : 285278209
> Operational State : Down, Active
> Configuring Link Aggregation
> The four-port Quad Gigabit Ethernet line card (QGLC) developed for use in the ASR 5000 chassis supports link aggregation as defined in IEEE 802.3ad. No other proprietary or non-standard modes are supported.
> Link aggregation (also called trunking or bonding) provides higher total bandwidth and better fault tolerance by combining up to four 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.
> Important: The aggregated ports must be on the same QGLC redundant pair. Link aggregation does not work across line card slots. In the event of a failure of one or more of the member physical ports, the remaining ports continue to be aggregated.
> Important: An aggregation group can consist of from one to four ports. A port can only be in one aggregation group; for example, Port 3 can be in Group A linked to Switch 1, but it cannot simultaneously be in Group B linked to Switch 2.
> Requirements
> Observe the following requirements:

> • | Assure that links between the two systems are full duplex and at the same speed.

> • | Set the port medium configuration to auto or full duplex and maximum speed.

> • | Certain physical port configuration changes, such as the MAC address or SRP, are prohibited on any interface participating in link aggregation

> There is more on configuring ports and port redundancy in “Configuring Line Card and SPIO Port Redundancy.”
> Operation
> Link aggregation operates as a sublayer between the MAC client and the MAC layer.
> Each MAC passes received frames up for control or collection in an aggregator—a logical MAC that aggregates several links together. The MAC client sends frames to the aggregator for distribution among MACs, as follows:
> Link Aggregation Traffic Flow
> The aggregator and each MAC share the same MAC address, which means the MAC has no need to parse two different unicast MAC addresses.
> Frame distribution uses an algorithm to distribute frames among MACs that prevents both the mis-ordering of frames belonging to the same “conversation,” and frame duplication.
> Link Aggregation Control
> 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 (although not required) that you set up the master first by CSP (task managing card/slot/ports), and unset last.
> 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...1023].
> 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. VPN CLI and vpnmgr return a failure message if you attempt to bind to a link aggregation member port.
> Two redundant line cards and their controlling PSC function as a system; this allows loopback addressing between vertical slots. Each system that participates in link aggregation has a unique system ID that consists of two bytes priority (where the lowest number (0) has the highest priority) and six bytes of MAC 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 slow (30s) or fast (1s) rate. The defaults for this release are Active and Slow; see the sample configuration below:
> config
> port ethernet <slot#/port#>
> link-aggregation lacp active rate fast
> 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 a QGLC line card 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.

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883