Configuring the Catalyst

This sample chapter from Cisco Press compares differences between the router CLI and the Catalyst 4000/5000/6000 family. It also describes the command line interface including aspects like command line recall, command editing, uploading and downloading code images and configuration files, and finally provides an overview of the menu driven configuration for the other Catalysts.

This chapter covers the following key topics:

• Catalyst 5000/6000 CLI Syntax Conventions—Provides the standard Cisco representation for interpreting commands administered on Catalyst switches.

• Catalyst 5000 Configuration Methods—Provides information on how to operate under the Console, Telnet, and TFTP configuration modes for Catalyst configuration.

• Using the Catalyst 5000/6000 Command-Line Interface—Describes command-line recall, editing, and help for the Catalyst 5000 series.

• Passwords—Provides documentation on how to set, change, and recover passwords for the Catalyst 5000/6000 series of switches.

• Configuration File Management—Discusses how to store and restore configuration files on flash and TFTP servers for Supervisor I, II, and III modules.

• Image File Management—Describes how to transfer Supervisor I, II, and III module software images.

• Redundant Supervisor Modules—Discusses how to implement redundant Supervisor modules to ensure system operation in the event of a module failover.

• Configuring Other Catalysts—Provides a quick overview of the configuration methods for the 1900/2800 and the 3000 series of Catalyst switches.

Configuring the Catalyst

Users familiar with Cisco routers exercise a command line interface (CLI) embedded in the IOS. The CLI characteristics are seen across nearly all of the router product line. However, most Catalysts CLIs differ from those found on Cisco routers. In fact, the Catalyst family has several CLIs based upon the model origins. The Catalyst 4000/5000/6000 series differs from the 3000 series, the 1900,2800 and the 8500 series. This chapter compares differences between the router CLI and the Catalyst 4000/5000/6000 family. It also describes the command line interface including aspects like command line recall, command editing, uploading and downloading code images and configuration files. An overview of the menu driven configuration for the other Catalysts is addressed in the last section, Configuring Other Catalysts. Examples of configuring the Catalyst 8500 series are included in Chapter 11, "Layer 3 Switching." This chapter deals primarily, however, with the "XDI" interface used by the Catalyst 4000/5000/6000 family.

The Catalyst product family evolution does not have the same roots as the Cisco router products. Cisco's history begins with the development of routers to interconnect networks. As the router family increased, a number of differences between the early models and the later became evident. Particularly with the release of 9.1x, the command line interface vastly differed for the IOS. But the IOS essentially retained the same look and feel after that point across all of the router family. Users of the Catalyst on the other hand may encounter multiple CLIs dependent upon the model used. This occurs not because Cisco changed its mind on how to present the CLI, but because some of the products were acquired technologies with a previously installed user base. For example, some of the Catalysts such as the 1900 and 2800 came from Grand Junction and have their own configuration methods. Some come from Kalpana, such as the Catalyst 3000, and use a different menu structure. Some were developed by Cisco. For example, the 8500 and the 2900XL, and use IOS type configurations. The Catalyst 5000 family originated with Crescendo. When Cisco acquired Crescendo, a significant user base already familiar with the XDI/CatOS configuration modes existed. The Catalyst 5000 and 6000 series use a CLI which differs from all of the others.

This chapter provides an overview for configuring the Catalyst 4000/5000/6000 series products. The CLI syntax and conventions are covered, along with command recall and editing methods. Methods for storing and retrieving configuration files images are also explained. Finally, configuring and managing redundant supervisor modules in a Catalyst 5500/6000/6500 are discussed.

Catalyst 5000/6000 CLI Syntax Conventions

All well-documented equipment uses a standard representation for interpreting commands. The Catalyst is no exception. Cisco documents how to interpret the printed commands of its documentation. Table 4-1 summarizes the command syntax conventions used in the Catalyst documentation and in this book.

Table 4-1 Catalyst Syntax Conventions

Command Presentation	Interpretation
Boldface	Commands and keywords that are entered literally as shown are in boldface.
Italic	Arguments for which you supply values are in italics.
[ ]	Elements in square brackets are optional.
{x | y | z}	Alternative required keywords are grouped in braces and separated by vertical bars.
[x | y | z]	Optional alternative keywords are grouped in brackets and separated by vertical bars.
String	A nonquoted set of characters. Do not use quotation marks around the string or the string will include the quotation marks.

Catalyst 5000 Configuration Methods

When you attempt to log in to the Catalyst, the Catalyst presents you with a password prompt. If you enter the correct password, you enter the Catalyst's NORMAL mode. Normal mode equates to a router's User EXEC mode allowing you to view most Catalyst parameters, but not authorizing any configuration changes. To make changes, you must enter the Catalyst's PRIVILEGED mode. The privileged mode functionally equates to the router's PRIVILEGED EXEC mode. In the privileged mode, you can view configuration files and make configuration changes. You enter the Catalyst's privileged mode with the enable command. The Catalyst then prompts for a password.

You can access the Catalyst CLI through one of three methods: through the console interface, Telnet, or Trivial File Transfer Protocol (TFTP). The following sections detail each access method.

Like a router, commands are additive—adding configuration statements to an existing file does not completely overwrite the existing configuration. Suppose you have an existing configuration that assigns ports 2/1-10 to VLAN 5. If you add a configuration that assigns ports 2/1-5 to VLAN 5, but you do nothing to ports 2/6-10, 2/6-10 remain in VLAN 5. The absence of these ports in the new VLAN assignment does not remove them from VLAN 5. If, however, the additional configuration includes a line that assigns ports 2/6-10 to VLAN 20, they move VLAN membership.

A foolproof way of ensuring that a new configuration completely overwrites an existing file is to enter clear config all (see Example 4-1). If you clear the configuration from Telnet or TFTP, you do not see this output. You only see this when directly attached to the console. This CLI command returns the Catalyst Supervisor module to its default configuration where all ports belong to VLAN 1, there is no VTP domain (explained in Chapter 12, "VLAN Trunking Protocol"), and all Spanning Tree parameters back to default values. NOTE also that entering this command clears the console's IP address too. You can clear the configuration with any of the access methods, but if you do so while you access the Catalyst through Telnet, you disconnect from the Catalyst because the Catalyst no longer has an IP address either.

Example 4-1 clear config all Output

Console> (enable) clear config

Usage: clear config all

clear config <mod_num>

clear config rmon

Console> (enable) clear config all

This command will clear all configuration in NVRAM.

This command will cause ifIndex to be reassigned on the next system startup.

Do you want to continue (y/n) [n]? y

.

......

............................

......

.....

System configuration cleared.

Use 'session' command to clear ATM or Router specific configurations.

Console> (enable)

From the Supervisor console, or via Telnet, you can clear the Catalyst configuration with the clear config all command. clear config all in Example 4-1 resets the Supervisor module to its defaults. NOTE that this command does not clear the files for the ATM LANE module, nor for the RSM (or MSM in a Catalyst 6000). This only affects the modules directly configured from the Supervisor module. To clear the configurations on the ATM or router modules, you need to access the modules with the session module_number command. This command performs the equivalent of an internal Telnet to the module so that you can make configuration changes. The ATM and router modules use IOS commands to change, save, and clear configurations.

Console Configuration

The Catalyst 5000 series Supervisor module has one physical console connection. For a Supervisor I or a Supervisor II, the connection is an EIA-232 25-pin connection. For a Supervisor III module, the connection is an RJ-45 connector. Make sure that you know which kind of Supervisor module you are working with to ensure that you can attach to the console.

The console has an interesting feature in that it can operate in one of two modes: either as a console or slip interface. When used as a console, you can attach a terminal or terminal emulation device such as a PC with appropriate software to the interface. This provides direct access to the CLI regardless of the configuration. You use this access method when you have no IP addresses configured in the Catalyst; without an IP address, you cannot Telnet to the Catalyst over the network. You also use this method whenever you need to do password recovery. (Password recovery is discussed in a later section.) And, you will probably elect to access the Catalyst with this method whenever you are local to the Catalyst with an available terminal.

You can enable the console port as a SLIP interface. (SLIP [serial line interface protocol] is the precursor to PPP.) When used in the slip mode, you can Telnet directly to the console port. In a likely setup, you attach a modem to the console port enabling you to Telnet directly to the Catalyst without having to traverse the network. This can be useful when troubleshooting the Catalyst from a remote location when you cannot access it over the network. When used as a slip interface, the interface designator is sl0 [SL0]. You can use the interface as a direct console attachment or a slip interface, but not both. It can only operate as one or the other. By default, it operates as a console interface. To configure the console as a slip interface, you need to assign an IP address to sl0 using the set interface command.

Lastly, you can access the CLI through Telnet over the network. The Catalyst has an internal logical interface, sc0, that you can assign an IP address to. This address becomes the source address when generating traffic in the Catalyst, or the destination address when you attempt to reach the Catalyst. Assigning an address to this logical interface causes the Catalyst to act like an IP end station on the network. You can use the address to perform Telnet, TFTP, BOOTP, RARP, ICMP, trace, and a host of other end station functions.

By default, the sc0 has no IP address and belongs to VLAN 1. If you want to change any of these parameters, use the set interface command. You can modify sc0's IP address and VLAN assignment in one statement. For example, set int sc0 10 144.254.100.1 255.255.255.0 assigns sc0 to VLAN 10 and configures an IP address of 144.254.100.1 with a "Class C" IP mask.

Telnet Configuration

Before you can Telnet to a Catalyst, you need to assign an IP address to the sc0 interface on the Supervisor module. The previous section, "Console Configuration," demonstrated how to do this. You can Telnet to a Catalyst as long as your Telnet device can reach the VLAN and IP network that the sc0 interface belongs to. Telnetting to the Catalyst allows you to perform any command as if you were directly attached to the Catalyst console. You do, however, need to know the normal mode and privileged EXEC passwords to gain access.

It was also mentioned earlier that if you enter clear config all from a remote location, you effectively cut yourself off from communicating with the Catalyst through the network. Changing the IP address or VLAN assignment on sc0 can do the same thing. Therefore, be sure to thoroughly review the results of changing the Catalyst IP address or VLAN assignment remotely.

A Catalyst security feature allows you to specify an access list of authorized stations that can access the Catalyst through Telnet or Simple Network Management Protocol (SNMP). You can specify up to 10 entries through the set ip permit command. To enable the access list, you need to specify the set of authorized stations and then turn on the IP permit filter.

To specify the list of allowed stations, use the command syntax set ip permit ip_address [mask]. The optional mask allows you to specify wildcards. For example, if you type set ip permit 144.254.100.0 255.255.255.0, you authorize all stations in subnet 144.254.100.0 to access the console interface. If you enter the command set ip permit 144.254.100.10 with no mask, the implied mask 255.255.255.255 is used, which specifies a specific host.

You can specify up to 10 entries this way. To activate the permit list, use the command set ip permit enable.

Activating the list does not affect any other transit or locally originated IP processes such as trace route and ICMP Echo Requests/Replies. The IP permit list only controls inbound Telnet and SNMP traffic addressed to the Catalyst. If the source IP address does not fall within the permitted range, the Catalyst refuses the connection.

You can also secure the Catalyst using Terminal Access Controller Access Control System Plus (TACACS+) authentication. TACACS+ enables a communication protocol between your Catalyst and a TACACS+ server. The server authenticates a user based upon the username and password for each individual you want to access the Catalyst console. Normally, the Catalyst authenticates using local parameters, the exec and enable passwords. If the user accessing the Catalyst knows these passwords, the user is authenticated to enter the corresponding mode.

TACACS+ allows you to demand not just a password, but also a username. The user attempting to log in must have a valid username/password combination to gain access.

If a user attempts to log in to the Catalyst when TACACS+ is enabled, the Catalyst sends a request to the TACACS+ server for authentication information. The server replies and the user is either authenticated or rejected.

To enable TACACS+, you need to have a functional and accessible TACACS+ server in your network. The specifics of configuring TACACS+ is beyond the scope of this book. See the Catalyst documentation for configuration details.

TFTP Configuration

The Catalyst has a TFTP client allowing you to retrieve and send configuration files from/to a TFTP server. The actual syntax to do TFTP configuration file transfers depends upon the version of Supervisor module installed in the Catalyst.

If you plan for the Catalyst to obtain the new configuration over the network after a clear config all, you either need to restore a valid IP address and default gateway setting or you need to have the configuration file on an accessible TFTP server. Details for using TFTP are described in the section, "Catalyst Configuration File Management."

Table 4-2 compares various access methods for configuring the Catalyst.

Table 4-2 Comparing the Usage of Catalyst Access Methods

Access Method	Attachment	When to Use
Console	Direct Supervisor module attachment	Use when network attachments not available, such as Telnet, TFTP, or SNMP. Also used for local access, initial configuration, and password recovery.
Sc0	Network	Use for Telnet, TFTP, or SNMP configurations to the built-in logical interface. Accessible through network connections.
Sl0	Supervisor module attachment	Use this for remote access to the Supervisor module when network access not available.
TFTP	Network	Use this to download a configuration to the Catalysts sc0 or sl0 interface.
SNMP	Network	Used to make configuration changes from a network management station.

Using the Catalyst 5000/6000 Command-Line Interface

Because the Catalyst has a different pedigree than the Cisco routers, the CLI differs between the two. For example, changes in a Cisco router are not permanent until you copy the running configuration to NVRAM. The Catalyst, on the other hand, immediately and automatically copies your commands to NVRAM. Individuals who suffer from an inability to remember to save configuration files on a router enjoy this feature. However, automatic configuration saves makes restoring a configuration more challenging, as discussed earlier.

The Catalyst does not have a special configuration mode like the routers. Rather, changes can be made directly from the privileged mode. Many users enjoy this feature because it allows them to make changes (set, clear) and view results (show) from the same command level. This eliminates the effort of bouncing between configuration mode and privileged mode to make changes and observe the results.

Command-line recall and editing vastly differed prior to Catalyst code version 4.4. With system codes prior to 4.4, command-line recall and editing consists of using UNIX shell-like commands. To recall a previous command, you need to specify how many commands back in the history file you want. Or, you can recall a command through pattern matching. To edit a command line, you need to use UNIX-like commands that specify a pattern and what to substitute in the pattern's place. Doing command-line editing in this manner is not self intuitive for many users, unless the user is a UNIX guru.

With Catalyst Supervisor engine software release 4.4, Cisco introduced IOS-type command-line recall and editing where up and down arrows on your terminal keypad scroll you through the Catalyst's command history buffer. If you are familiar with command-line recall and editing with a Cisco router, you will be comfortable with the Catalyst CLI. If however, you still have code levels prior to 4.4, regrettably, you must continue to use the UNIX structure.

The manner in which the Catalyst displays help differs from the router displays. The router uses a parameter-by-parameter method of displaying help, whereas the Catalyst displays a complete command syntax.

The following sections describe command-line recall, editing, and help for the Catalyst 5000 series with the XDI/CatOS style interface.

Command-Line Recall

When you enter a command in the Catalyst, it retains the command in a buffer called the history buffer. The history buffer can store up to 20 commands for you to recall and edit. Various devices have methods of recalling commands. The Catalyst uses abbreviated key sequences to recall commands. These sequences resemble what a UNIX c-shell user might use. UNIX users often live with awkward methods of recalling and editing commands. Therefore, their comfort level with the legacy Catalyst editing system is probably fairly high, but might be low for the rest of us.

In UNIX, you often perform commands with a bang included in the command line. A bang is nothing more than an exclamation point (!) on a keyboard, but "exclamation" is too difficult to say when dictating commands. Therefore, bang is used in its place. Table 4-3 summarizes the key sequence for recalling previous commands in the history buffer.

Table 4-3 Command Recall from Catalyst History Buffer

Command Sequence	Effect
!!	Repeats the previous command.
!-n	Repeats the command n places before the previous.
!n	Repeats command n in the buffer.
!aaa	Repeats the command that starts with the matching string aaa.
!?aaa	Repeats the command that contains the string aaa anywhere in the command.

Sometimes you not only want to recall a command, but also edit it. Table 4-4 shows the sequences to recall and edit previous commands.

Table 4-4 Catalyst Command Recall with Substitution

Command Sequence	Effect
^aaa^bbb	Recall previous command and substitute bbb for aaa.
!!aaa	Recall previous command and append aaa.
!n aaa	Recall command n and append aaa.
!aaa bbb	Recall command that starts with aaa and append bbb.
!?aaa bbb	Recall the command that contains aaa and append bbb.

Suppose, for example, that you enter a command set vlan 3 2/1-10,4/12-216/1,5/7.

This command string assigns a set of ports to VLAN 3. However, you realize after entering the command that you really mean for them to be in VLAN 4 rather VLAN 3. You could retype the whole command a second time and move the ports to VLAN 4, or you could simply type ^3^4. This forces the Catalyst not only to use the previous command, but to change the number 3 to a number 4, which in this case, corrects the VLAN assignment.

One frustration when mentally recalling commands can be that you have a hard time remembering what command you entered, seven lines previously. This can become particularly challenging because the Catalyst history buffer can store up to 20 commands. Use the history command to see your history buffer. Example 4-2 shows output from a history command. Notice that the commands are numbered allowing you to reference a specific entry for command recall. For example, the output recalls command 2 from the history buffer. This caused the Catalyst to recall the history command. Note also that new commands add to the bottom of the list. Newer commands have higher numbers.

Example 4-2 Catalyst History Buffer Example

Console> history

1 help

2 history

Console> !2

history

1 help

2 history

3 history

Console>

Using Help

In a Cisco router, you access help by entering ? on a command line. The router then prompts you with all possible choices for the next parameter. If you type in the next parameter and type ? again, the router displays the next set of command-line choices. In fact, the router displays help on a parameter-by-parameter basis. Additionally, when the router displays help options, it also ends by displaying the portion of the command that you entered so far. This enables you to continue to append commands to the line without needing to reenter the previous portion of the command.

The Catalyst help system functions differently from the router, though. You access help in the same manner as you do in a router, but the results differ. For example, where a router prompts you for the next parameter, the Catalyst displays the entire usage options for the command, if your command string is unique so that the Catalyst knows what command you want. Example 4-3 shows the help result for a partial command string. However, the string does not uniquely identify what parameter should be modified, so it lists all set system commands.

Example 4-3 Catalyst Help Example

Console> (enable) set system ?

Set system commands:

----------------------------------------------------------------------

set system baud Set system console port baud rate

set system contact Set system contact

set system help Show this message

set system location Set system location

set system modem Set system modem control (enable/disable)

set system name Set system name

On the other hand, if you have enough of the command on the line that the Catalyst recognizes what command you intend to implement, it displays the options for that command. This time, in Example 4-4, the string identifies a specific command and the Catalyst displays help appropriate for that command. The user wants to modify the console interface in some way, but is unsure of the syntax to enter the command.

Example 4-4 Another Catalyst Help Example

Console> (enable) set interface ?

Usage: set interface <sc0|sl0> <up|down>

set interface sc0 [vlan] [ip_addr [netmask [broadcast]]]

set interface sl0 <slip_addr> <dest_addr>

Console> (enable)

Notice that when the console displays help, it returns the command line with a blank line. The command string you entered so far is not displayed for you as it is on a router. You can now elect to use command recall. Suppose you want to disable the logical interface, sc0. So you want to enter the command set int sc0 down. Being a clever network administrator, you elect to use command recall and complete the command. What happens if you type !! sc0 down ? You see the command usage screen again, without the console changing state to down (see Example 4-5). This happens because the command recall executes the previous statement that was set int ? with the help question mark and your appended parameters. When you add the additional parameters, the Catalyst interprets the string as set int ? sc0 down , sees the question mark, and displays help.

Example 4-5 Command Recall after Help

CAT1> (enable) set int ?

Usage: set interface <sc0|sl0> <up|down>

set interface sc0 [vlan] [ip_addr [netmask [broadcast]]]

set interface sl0 <slip_addr> <dest_addr>

CAT1> (enable) !! sc0 down

set int ? sc0 down

Usage: set interface <sc0|sl0> <up|down>

set interface sc0 [vlan] [ip_addr [netmask [broadcast]]]

set interface sl0 <slip_addr> <dest_addr>

CAT1> (enable)

If you have system code 4.4 or later, you can use the up/down arrow to perform command recall after help, but the recall includes the question mark. The advantage here, though, over the !! recall is that you can edit out the question mark on the recalled command line using router editing commands. Therefore, you can perform command recall, remove the question mark, and enter the rest of the command. The Catalyst then correctly interprets the command, assuming that you subsequently enter correct and meaningful parameters.

A Catalyst invokes help when you enter a question mark on the command line. It also provides help if you enter a partial command terminated with <ENTER>. For example, the command in Example 4-4 displays the same screen if the user enters set interface <ENTER>. The Catalyst uniquely recognizes set int, but also observes that the command is not complete enough to execute. Therefore, the Catalyst displays the command usage screen. If you intend to modify the sc0 VLAN membership to VLAN 5 and change the IP address in the same line, you can enter the command set int sc0 5 144.254.100.1 255.255.255.0. Suppose that as you enter the command you enter the VLAN number, but forget the rest of the command line. You might be tempted to hit <ENTER> to get a command usage screen. But you do not see the usage screen. Instead, the Catalyst sees the current command line and says, "There is enough on this line to execute, so I will." You just successfully changed the sc0 VLAN membership without changing the IP address. If you do this through a Telnet session in a production network, you probably just completely removed Telnet access to the Catalyst. It is now time to walk, drive, or fly to the Catalyst to restore connectivity. (Or call someone who can do it for you and confess your mistake!)

Supervisor Module Configuration

Modifying and viewing Catalyst 5000/6000 configuration files consists of using set, clear, and show commands. Because the Catalyst does not use a separate configuration mode to make changes, you can make changes and view system configurations all from the same prompt level. You must make all changes from the privilege mode, which requires an enable password.

Important show Statements

To view configurations, use the show command. Example 4-6 annotates a simple Supervisor module configuration file displayed through the show config command. Some configuration lines are editorially deleted because they are redundant and needlessly consume printed space. The remaining portion of the file enables you to see the general organization of the configuration file.

Example 4-6 Annotated Supervisor Configuration File

Console> (enable) show config

...

.........

.........

........

........

..

begin

set password $1$FMFQ$HfZR5DUszVHIRhrz4h6V70

set enablepass $1$FMFQ$HfZR5DUszVHIRhrz4h6V70

set prompt Console>

set length 24 default

set logout 20

set banner motd ^C^C

!

#system

set system baud 9600

set system modem disable

set system name

set system location

set system contact

!

#snmp

set snmp community read-only public

set snmp community read-write private

set snmp community read-write-all secret

!Other SNMP commands deleted

#IP

!This sets up the console or slip interfaces.

set interface sc0 1 144.254.100.97 255.255.255.0 144.254.100.255

!

set interface sl0 0.0.0.0 0.0.0.0

set arp agingtime 1200

set ip redirect enable

set ip unreachable enable

set ip fragmentation enable

set ip alias default 0.0.0.0

!

#Command alias

!

#vmps

set vmps server retry 3

set vmps server reconfirminterval 60

set vmps tftpserver 0.0.0.0 vmps-config-database.1

set vmps state disable

!

#dns

set ip dns disable

!

#tacacs+

!This section configures the TACACS+ authentication parameters

!

#bridge

!This section defines FDDI module behavior

!

#vtp

!This section characterizes the virtual trunk protocol and vlan parameters

!

#spantree

#uplinkfast groups

set spantree uplinkfast disable

#vlan 1

set spantree enable 1

set spantree fwddelay 15 1

set spantree hello 2 1

set spantree maxage 20 1

set spantree priority 32768 1

!Other VLAN Spanning Tree information deleted. This section describes Spanning

!Tree for each VLAN.

!

#cgmp

!This group of commands controls the Catalyst multicast behavior

!

#syslog

set logging console enable

set logging server disable

!Other logging commands deleted. This characterizes what events are logged.

!

#ntp

!This sets up network time protocol

!

#set boot command

set boot config-register 0x102

set boot system flash bootflash:cat5000-sup3.3-1-1.bin

!Any special boot instructions are placed here.

!

#permit list

!The access list is found here

set ip permit disable

!

#drip

!This is Token Ring stuff to take care of duplicate ring numbers.

!

!On a per module basis, the Catalyst displays any module specific

!configurations.

#module 1 : 2-port 10/100BaseTX Supervisor

set module name 1

set vlan 1 1/1-2

set port channel 1/1-2 off

set port channel 1/1-2 auto

set port enable 1/1-2

set port level 1/1-2 normal

set port speed 1/1-2 auto

set port trap 1/1-2 disable

set port name 1/1-2

set port security 1/1-2 disable

set port broadcast 1/1-2 100%

set port membership 1/1-2 static

set cdp enable 1/1-2

set cdp interval 1/1-2 60

set trunk 1/1 auto 1-1005

set trunk 1/2 auto 1-1005

set spantree portfast 1/1-2 disable

set spantree portcost 1/1 100

set spantree portcost 1/2 100

set spantree portpri 1/1-2 32

set spantree portvlanpri 1/1 0

set spantree portvlanpri 1/2 0

set spantree portvlancost 1/1 cost 99

set spantree portvlancost 1/2 cost 99

!

#module 2 empty

!

#module 3 : 24-port 10BaseT Ethernet

set module name 3

set module enable 3

set vlan 1 3/1-24

set port enable 3/1-24

set port level 3/1-24 normal

set port duplex 3/1-24 half

set port trap 3/1-24 disable

set port name 3/1-24

set port security 3/1-24 disable

set port broadcast 3/1-24 0

set port membership 3/1-24 static

set cdp enable 3/1-24

set cdp interval 3/1-24 60

set spantree portfast 3/1-24 disable

set spantree portcost 3/1-24 100

set spantree portpri 3/1-24 32

!

#module 5 : 1-port Route Switch

!Note that the only things in this configuration are Spanning Tree and bridge

!related. There are no routing configs here.

set module name 5

set port level 5/1 normal

set port trap 5/1 disable

set port name 5/1

set cdp enable 5/1

set cdp interval 5/1 60

set trunk 5/1 on 1-1005

set spantree portcost 5/1 5

set spantree portpri 5/1 32

set spantree portvlanpri 5/1 0

set spantree portvlancost 5/1 cost 4

!

#switch port analyzer

!If you set up the ability to monitor switched traffic, the

!the configs will show up here

set span disable

!

#cam

!set bridge table aging to five minutes

set cam agingtime 1,1003,1005 300

end

Console> (enable)

Note in Example 4-6 that the file collates in logical sections. First, the Catalyst writes any globally applicable configuration items such as passwords, SNMP parameters, system variables, and so forth. Then, it displays configurations for each Catalyst module installed. Note that the module configuration files refer to Spanning Tree and VLAN assignments. Further, it does not display any details about other functions within the module. For example, an RSM is installed in module 5 of this Catalyst. Although this is a router module, it attaches to a virtual bridge port internally. The Catalyst displays the bridge attachment parameters, but not the Route Switch Module (RSM) or ATM LANE configuration lines. To see the these module specific configurations, you need to access them with the session module_number and view its own configuration file.

Other show commands display item specific details. For example, to look at the current console configuration, you can use the show interface (sh int) command as demonstrated in Example 4-7.

Example 4-7 show interface Display

Console> (enable) show interface

sl0: flags=51<UP,POINTOPOINT,RUNNING>

slip 0.0.0.0 dest 128.73.35.160

sc0: flags=63<UP,BROADCAST,RUNNING>

vlan 1 inet 144.254.100.97 netmask 255.255.255.0 broadcast 144.254.100.255

Console> (enable)

Another useful show command displays the modules loaded in your Catalyst (see Example 4-8).

Example 4-8 show module Output

Console> (enable) show module

Mod Module-Name Ports Module-Type Model Serial-Num Status

--- ------------------- ----- --------------------- --------- --------- -------

1 2 10/100BaseTX Supervis WS-X5530 008700085 ok

3 24 10BaseT Ethernet WS-X5013 008678074 ok

4 2 MM OC-3 Dual-Phy ATM WS-X5158 008444947 ok

5 1 Route Switch WS-X5302 007600273 ok

13 ASP

Mod MAC-Address(es) Hw Fw Sw

--- ---------------------------------------- ------ ------- ----------------

1 00-90-92-bf-70-00 thru 00-90-92-bf-73-ff 1.5 3.1(2) 3.1(1)

3 00-10-7b-4e-8d-d0 thru 00-10-7b-4e-8d-e7 1.1 2.3(1) 3.1(1)

4 00-10-7b-42-b0-59 2.1 1.3 3.2(6)

5 00-e0-1e-91-da-e0 thru 00-e0-1e-91-da-e1 5.0 20.7 11.2(12a.P1)P1

Mod Sub-Type Sub-Model Sub-Serial Sub-Hw

--- -------- --------- ---------- ------

1 EARL 1+ WS-F5520 0008700721 1.1

1 uplink WS-U5531 0007617579 1.1

Console> (enable)

The output in Example 4-8 displays details about the model number and description of the modules in each slot. The second block of the output tells you what MAC addresses are associated with each module. Notice that the Supervisor module reserves 1024 MAC addresses. Many of these addresses support Spanning Tree operations, but other processes are involved too. Module 3, the 24-port Ethernet module, reserves 24 MAC addresses, one for each port. These also support Spanning Tree in that they are the values used for the port ID in the Spanning Tree convergence algorithm. The third block of the display offers details regarding the Supervisor module.

Other key show statements are demonstrated throughout the rest of the book.

Modifying Catalyst Configurations

To modify a Catalyst parameter, you use either the set or clear commands. The set command changes a parameter to a value that you specify, whereas the clear command returns some parameters to their default setting.

To change system parameters, you use the set system command as demonstrated in Example 4-9.

Example 4-9 set system Example

Console> (enable) set system ?

Set system commands:

----------------------------------------------------------------------

set system baud Set system console port baud rate

set system contact Set system contact

set system help Show this message

set system location Set system location

set system modem Set system modem control (enable/disable)

set system name Set system name

Console> (enable) set sys location whoneedsmarketing

System location set.

Console> (enable) show system

PS1-Status PS2-Status Fan-Status Temp-Alarm Sys-Status Uptime d,h:m:s Logout

---------- ---------- ---------- ---------- ---------- -------------- ---------

ok faulty ok off faulty 0,00:31:09 20 min

PS1-Type PS2-Type Modem Baud Traffic Peak Peak-Time

---------- ---------- ------- ----- ------- ---- -------------------------

WS-C5508 WS-C5508 disable 9600 0% 0% Thu Aug 13 1998, 16:18:10

System Name System Location System Contact

------------------------ ------------------------ ------------------------

whoneedsmarketing

Console> (enable)

Clearly, there are several system variables that you can modify. Example 4-9 modifies the system location object.

Some commands provide a warning if your action might cause connectivity problems for you or the users. For example, in Example 4-10, the user intends to change the IP address of the console interface. If the user is making the change remotely—that is, the user is logged in to the Catalyst through a Telnet session—the user loses connectivity and needs to re-establish the Telnet session.

Example 4-10 set interface Example

Console> (enable) set interface sc0 1 144.254.100.97 255.255.255.0

This command may disconnect your Telnet session.

Do you want to continue (y/n) [n]? y

Interface sc0 vlan set, IP address and netmask set.

Console> (enable)

Use a clear command to restore a parameter to a default value. Suppose you have a VLAN 4 configured on the Catalyst and want to remove it. You use the command clear vlan 4. This eliminates references to VLAN 4 in the Catalyst. However, some things associated with VLAN 4 are not eliminated. For example, if you have ports assigned to VLAN 4 and you clear vlan 4, the ports assigned to VLAN 4 move into a disabled state. They do not move to VLAN 1. You need to manually reassign the ports to VLAN 1. The clear config command demonstrated in Example 4-1 returns the whole Catalyst to its default out-of-the-box configuration. The Catalyst warns you about potential connectivity issues with this command before executing it.

Catalyst Password Protection

When you first receive a Catalyst from Cisco, it has no password set. In other words, the password is <ENTER> to enter both the EXEC and privilege modes. Your first task as a conscientious network administrator should be to change the passwords to the unit. This helps to prevent unauthorized children in adult form from modifying the Catalyst and disrupting your network. Example 4-11 shows a Catalyst session where the user changes the EXEC and enable passwords. The user starts by changing the enable password for privilege mode with the command set enablepass. The Catalyst immediately prompts for the old password. If you are doing this to a Catalyst with a fresh configuration file, you should respond with <ENTER>. Otherwise, you need to know the existing enable password. If you do not know the existing enable password, see the following section, "Catalyst Password Recovery," for details on what to do next.

Example 4-11 Modifying a Catalyst's Passwords

Console> (enable) set enablepass

Enter old password: cntgetin

Sorry password incorrect.

Console> (enable) set enablepass

Enter old password: cantgetin

Enter new password: stillcantgetin

Retype new password: stillcantgetin

Password changed.

Console> (enable) set password

Enter old password: guessthis

Enter new password: guessthis2

Retype new password: guessthis2

Password changed.

Console> (enable)

Note that italicized text is not displayed in real output.

In Example 4-11, the user types in the wrong enable password, so the Catalyst shows an error message and stops the modification process. The user tries again, but this time enters a correct existing enable password. The Catalyst then asks the user to enter the new enable password, twice, to confirm the entry.

The user then changes the normal mode password with the set password command. As with the enable password, the user has to know the existing password before the Catalyst allows any changes to the password. Upon entering the correct password, the Catalyst asks for the new password and a confirmation.

Catalyst Password Recovery

If at any time you forget the normal mode or enable passwords, you need to start a password recovery process. Password recovery on the Catalyst 5000/6000 series differs from the methods used on a Cisco router or on other Catalyst models.

You must be at the Catalyst console to perform password recovery. Password recovery requires a power cycle of the system by toggling the power switch. After you power cycle the Catalyst, the Catalyst goes through its initialization routines and eventually prompts you for a password to enter the normal mode. At this point, you have 30 seconds to perform password recovery.

The trick in Catalyst password recovery lies in its behavior during the first 30 seconds after booting: when the Catalyst first boots, it ignores the passwords in the configuration file. It uses the default password <ENTER> during this time. So, when the Catalyst prompts you for an existing password at any time, simply type <ENTER> and the Catalyst accepts your response. Immediately enter set password or set enablepass to change the appropriate password(s).

Catalyst Configuration File Management

For complete system recovery, make sure that you have a copy of each Catalyst's configuration file stored somewhere other than on the Catalyst itself. If anything happens to the Catalyst Supervisor module, you might not be able to recover the configuration file. It is a crime to have to rebuild the entire configuration file from scratch during a system outage when it is easy to create a backup on a network accessible machine.

Through TFTP, you can store your configuration file on a TFTP server and recover it later when needed. The syntax varies depending upon the version of Supervisor module you have. Catalyst 5000 Supervisor III modules and Catalyst 6000s use a syntax more like a Cisco router than do the Catalyst 5000 Supervisor I or II modules.

Supervisor I and Supervisor II Module Configuration

To save a configuration file from either a Catalyst 5000 Supervisor I or Supervisor II module, use the write net command. Example 4-12 shows a session writing a configuration file to a TFTP server. The server's IP address and the filename are clearly seen in the output. Note that the filename is the name that you want to call the file on the server. This is not the name of the file in the Catalyst. There is only one configuration file residing in the Catalyst, so specifying a source file here is redundant.

Example 4-12 Uploading a Configuration File to a TFTP Server

Console> (enable) write ?

Usage: write network

write terminal

write <host> <file>

Console> (enable) write net

IP address or name of remote host? 144.254.100.50

Name of configuration file? cat

Upload configuration to cat on 144.254.100.50 (y/n) [n]? y

.....

.........

.........

........

........

..

Finished network upload. (6193 bytes)

Console> (enable)

Retrieving a file from the server uses the command configure network. When retrieving a file, you need to specify the source filename on the TFTP server (see Example 4-13).

Example 4-13 Retrieving a Configuration File

Console> (enable) configure ?

Usage: configure <host> <file>

Console> (enable) configure network

IP address or name of remote host? 144.254.100.50

Name of configuration file? cat

Configure using cat from 144.254.100.50 (y/n) [n]? y

/

Finished network download. (6193 bytes)

[Truncated output would show the configuration lines]

Note that in the command usage output, the configure network option is not displayed. However, it is a valid option to use.

Supervisor III Module Configuration

Transferring Supervisor III and Catalyst 6000 configuration files via TFTP to another device looks more like a router command. The command copy config {flash | file-id | tftp} copies the configuration file to one of three locations. You can store the configuration file in the bootflash memory, a flash card in a flash slot (with an appropriate Supervisor III module), or to a TFTP server. When copying configuration files from or to the Catalyst, you need to specify the source filename. Because of the flash architecture on the Supervisor III, you might have several configuration files local. However, only one can be active. Therefore, you need to specify which of the local files you are trying to copy.

Recovering a configuration file works in reverse. If you intend to retrieve the file from a TFTP server, use the command copy tftp {flash | file-id | config}. When retrieving, you can write the configuration file to your bootflash, a flash card, or to the running configuration. If you intend to write the configuration file to your running configuration, use the command form copy tftp config. Example 4-14 shows a session recovering the configuration filename cat to a flash device.

Example 4-14 Recovering Configuration Files from a TFTP Server

Console> (enable) copy tftp flash

IP address or name of remote host []? 144.254.100.50

Name of file to copy from []? cat

Flash device [slot0]? <ret>

Name of file to copy to [cat]? <ret>

If you store your configuration file in your flash, you can recover it with the command copy flash {tftp | file-id | config}. Again, any of three destinations are possible.

If the file is on any other flash device, use the command copy file-id {tftp | flash | file-id | config}.

Catalyst Image File Management

As with routers, Catalysts need software to function. The software loads into the flash memory of the Supervisor module and is referred to as the Supervisor Engine Software. The software provides the Catalyst CLI, Spanning Tree functions, VLAN configurations, VTP, and many other processes associated with the Supervisor.

The Catalyst 5000 Supervisor I and Supervisor II modules differ in how they transfer software images compared to the Supervisor III module. Therefore, they are treated separately in this section. As with the configuration files, the Supervisor III module behaves more like a Cisco router than do the Supervisor I and II modules.

The following sections assume that you have a single Supervisor module in your Catalyst. If you have redundant Supervisor modules, refer to the section, "Redundant Supervisor Modules," for more details.

Downloading image files to your Catalyst's flash memory causes the Catalyst to need a reboot for the new image to take effect. So be aware that any code changes temporarily take users off line if you elect to make the new image effective immediately. This might cause your beeper to beep or phone to ring.

Supervisor I and II Image File Management

To transfer Supervisor image files, use the commands download host file and upload host file. Example 4-15 shows a download from a TFTP server. Note that at the end of the transfer, the Catalyst prompts that you need to reset the image for it to take effect.

Example 4-15 Supervisor Image Download from a TFTP Server

Console> (enable) download 172.20.52.3 cat5000-sup.4-2-1.bin

Download image cat5000-sup.4-2-1.bin from 172.20.52.3 to module 1 FLASH (y/n)

[n]? y

/

Finished network single module download. (2748504 bytes)

FLASH on Catalyst:

Type Address Location

Intel 28F016 20000000 NMP (P3) 8MB SIM

Erasing flash sector...done.

Programming flash sector...done.

Erasing flash sector...done.

Programming flash sector...done.

Erasing flash sector...done.

Programming flash sector...done.

The system needs to be reset to run the new image.

Console> (enable) reset system

This command will reset the system.

Do you want to continue (y/n) [n]? y

Console> (enable) 07/21/1998,10:52:36:SYS-5:System reset from Console

Supervisor III Image File Management

The same commands used to maneuver the configuration files on a Supervisor III module (and on Catalyst 6000s) apply to moving the image files. Use the copy flash tftp to upload a file or use copy tftp flash to download a file. You have the option of directing the copy operation towards the flash memory, a flash slot device, or a TFTP server.

Serial Port Download

One final method exists for importing an image file to the Supervisor module—through the console port. The Catalyst supports kermit transfers through the console. Kermit is a protocol for transferring files and is usually built into many terminal emulation software packages. If you have an image file on a UNIX host or PC connected to the Catalyst's console port, you can enable kermit on the Catalyst to receive the image file. Use download serial to receive the file through the console port. Be aware though, that this might take some time to transfer because you are transferring the code, a fairly large size, at the EIA-232 line rates. This is intended for emergency use only where a TFTP server is not available, nor are flash devices.

If you have the console port configured as a slip interface rather than a console, you can use TFTP to transfer the image through the port.

Redundant Supervisor Modules

One of the motivations for the introduction of the Catalyst 5500 series products was the customer need for system redundancy. The legacy Catalyst 5000 series contains one Supervisor module, which, if it fails, disables the entire unit. The Catalyst 5500/6000 family, on the other hand, enables you to put two Supervisor modules into the chassis at the same time. On power up, one of the modules becomes the active Supervisor engine, and the other becomes the standby Supervisor engine. The active Supervisor engine module takes care of all Catalyst operational details and provides the CLI for the administrator. The active module, therefore, takes care of the Spanning-Tree Protocol, SNMP, CLI, Telnet, VLAN assignments, VTP, CDP, and other aspects. If at any time the active engine fails, the Catalyst resets and the standby engine assumes the responsibility of the active Supervisor engine.

When a Supervisor module is in standby mode, its console interface is not active. All configuration changes must be made through the active Supervisor engine. And depending upon what version of Supervisor engine code is running, you might not be able to use the uplink ports on the standby unit either. If you are running an engine software version earlier than 4.1, you cannot use the uplinks on the standby unit. However, when the standby unit becomes the active module, the uplink ports are activated. If you have 4.1 or 4.2, the standby ports are active at all times, even if the module is in standby mode. If you have version 4.3 or later, the standby ports are inactive by default when in standby mode, but can be administratively enabled.

There are a few things that must be true for the failover to function correctly:

1. The Catalyst 5000 Supervisor module must be a Supervisor Engine II or later. The legacy Supervisor module that is associated with the Catalyst 5000 series does not support the redundant features. In fact, the Supervisor I module does not even work in a 5500 chassis. All Catalyst 6000 Supervisors support redundancy.

2. The active and the standby Supervisor engines must be the same model. For Catalyst 5500s, they must both be Supervisor II or both be Supervisor III. You cannot mix a Supervisor II and a Supervisor III in the same unit. The reason for this will become clear shortly.

3. If you use two Catalyst 5000 Supervisor III modules, the feature cards on the two cards must be the same. If you have the NetFlow Feature Card (NFFC) card on one, they must both have NFFC capability.

4. Configuration files must match between the two modules.

5. The software images must be the same for both.

The first three items you must administratively ensure. You must select the appropriate hardware to support the redundancy feature. The Catalyst cannot do this for you.

However, the Catalyst can greatly help you regarding the last two items. The system code automatically synchronizes software between the two Supervisor modules to ensure that they are running the same files. This helps to ensure that, in the event of a failover, the failover condition can support all configured features that were running when the first unit was the active unit. Most network engineers can deal with a failover situation and replace a failed module. But when the network operational mode changes as a result of the failover ("oh no, everything now is in VLAN 1!"), they become very unhappy. So do users.

Synchronizing Configuration Between Redundant Supervisor Modules

Whenever you make a configuration change, you must make it in the active Supervisor module, because the console on the standby unit is disabled. If you make a change on the active Supervisor, how do you ensure that the configuration on the standby unit gets updated too? You don't need to, the Catalyst does it for you.

Configuration changes on the active unit are automatically updated to the standby unit. This happens internally to the Catalyst. If you swap standby modules, the active Supervisor automatically ensures that the standby gets a copy of the current configuration. It updates the configuration file in the standby unit.

Synchronizing Image Files Between Redundant Supervisor Modules

Not only must the Supervisor modules be the same and running the same configuration file, but they must also have the same software image. As with the configuration file, the active Supervisor module ensures that the standby unit has the same software image. If they differ, the active Supervisor module loads the running image to the standby Supervisor and resets the standby module. The active unit checks the following to determine if the software images need to be synchronized:

1. The active unit checks to see if the boot images have the same time stamp. If they differ, the active Supervisor module updates the standby Supervisor module.

2. If you change the BOOT environment variable, the active Supervisor module copies the new target boot image to the standby, if necessary, and modifies the environment variable on the standby so that they start with the same image.

3. If you upgrade the boot image on the active unit, the active Supervisor module updates the standby.

Notice that images and configurations flow from the active to the standby units, never the other direction. You cannot update the image on the standby module first and then synchronize the active module with the standby. The standby always synchronizes to the active.

When using Catalyst 5000 Supervisor Engine III modules and all Catalyst 6000 modules, additional elements are compared between the active and standby engines. Specifically, the active module compares not just the boot image, but also the run-time image. The run-time image is the image used by the ROM monitor to boot the Supervisor module. If the run-time image successfully loads, and there is a boot image, and a BOOT environment variable pointing to the boot image, the Catalyst also loads the boot image, which is your desired operational image.

The Supervisor ensures that the run-time images are the same on the two modules. As with the boot image, if they differ, the active unit synchronizes the two by downloading a new run-time image. Therefore, the active Supervisor module performs the following to determine if there is a need to synchronize:

1. The active unit checks the timestamp on the run-time image. If they differ, it initiates the synchronization process.

2. If you overwrite the run-time image on the active unit, the active module synchronizes the standby unit.

Configuring Other Catalysts

As mentioned in the opening sections of this chapter, the other Catalysts (non-5000/6000 family) use other configuration methods. The three remaining types come from Grand Junction for the Catalyst 1900/2800 products, Kalpana for the Catalyst 3000 family, and Cisco IOS for the 2900XL and 8500. This section provides a quick overview of the configuration methods for the 1900/2800 and the 3000 because they use methods entirely different from the IOS methods of the 2900XL and 8500, and the CLI mode of the Catalyst 5000/6000. This section does not enter into any detail, but only serves to highlight the configuration interfaces.

After you understand how various aspects of the Catalyst 5000/6000 family operates, such as bridging, Inter-Switch Link (ISL), VLAN Trunking Protocol (VTP), and so forth, you basically understand what to configure on the other Catalysts. The difference is in what features are supported and how to effect configuration changes.

Catalyst 1900/2800 Configuration

The 1900/2800 products use a hierarchical menu structure to make changes. Example 4-16 shows one of the higher level menus from which you can make changes. To select a lower menu, type the letter of the menu item. To return to a higher menu, type X.

Example 4-16 Catalyst 1900 Main Menu Display

Catalyst 1900 - Main Menu

[C] Console Settings

[S] System

[N] Network Management

[P] Port Configuration

[A] Port Addressing

[D] Port Statistics Detail

[M] Monitoring

[V] Virtual LAN

[R] Multicast Registration

[F] Firmware

[I] RS-232 Interface

[U] Usage Summaries

[H] Help

[X] Exit Management Console

Catalyst 3000 Configuration

Like the 1900/2800, the Catalyst 3000 series also uses a hierarchical menu structure. It differs, however, from the 1900/2800 in how you maneuver through the menus. In the Catalyst 3000, you use the arrow keys from your terminal to highlight an item, and then you press <ENTER>. Example 4-17 illustrates the Catalyst 3000 series menu.

Example 4-17 Catalyst 3000 Menu Example

Configuration
SwitchProbe...
Switch/Stack Information...	EtherChannel...
VLAN/VTP Configuration...	MAC Filter & Port Security...
IP Configuration...	Learn and Lock...
SNMP Configuration...	Address Aging...
Spanning Tree...	Port Switching Mode...
Port Configuration...	Broadcast Suppression...
CDP Configuration...	Password...
CGMP Configuration...	Console Configuration...
Module Information...	ATM Configuration...
100VG Port Information...	Router Configuration...
RMON Configuration
	Display the Main Menu
Use cursor keys to choose item. Press <RETURN> to confirm choice. Press <CTRL><P> to return to Main Menu.

Review Questions