Configuring System Settings


Configuring System Settings
 
 
This chapter provides instructions for configuring system options such as:
 
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).
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
 
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
 
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.
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
 
show ntp associations
The output displays information about all NTP servers. See the output below for an example deploying two NTP servers.
The following table describes the show ntp associations output table.
 
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:
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:
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:
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:
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:
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:
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:
The card-standby-priority specifies the order in which the system will use standby PSCs as redundant components.
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
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:
 
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