Configuration of a meaningful system name is essential in managing Catalyst switches effectively. The default names of Switch, Router, and Console on multiple switches are not easily distinguishable from the CLI when multiple Telnet, SSH, or console sessions are open to multiple switches. Configuring meaningful and unique switch system names throughout the enterprise network is extremely useful, particularly system names that allude to location. For example, a system name of Sw4thFlRm2 abbreviates “Switch 4th Floor Room 2.” Meaningful system names provide for quick examination of the precise switch currently being accessed. To configure the Catalyst switch system name on Cisco IOS–based switches, use the following command:

hostname name-string

name-string refers to the switch name. To configure the Catalyst switch system name on Cisco CatOS–based switches, use the following command:

set system name name-string

Examples 3-1 and 3-2 illustrate a user configuring the Catalyst switch system name on a Cisco IOS–based and Cisco CatOS–based switch, respectively.

Switch(config)#hostname Access-Floor1

Access-Floor1(config)#

Console (enable) set system name Core-2

System name set.

Core-2> (enable)

The management IP address allows for administrative access to the switch using Telnet, SSH, and HTTP. For Layer 2 switches and for Layer 3 switches acting solely as Layer 2 switches, use a single IP address for administrative access. This IP address occupies a specific VLAN. For example, Figure 3-1 illustrates a medium-sized network in which each access layer switch consists of two VLANs: one for voice and one for data. The switch management IP address resides in the data VLAN in this example. If VLAN A represents VLAN 101, then you should configure an interface VLAN 101 on your access layer switch with an IP address in VLAN 101.

Figure 3-1. Network Topology for Examples 3-3 and 3-4

Use the following command to configure an IP address on a Cisco IOS–based switch:

ip address ip-address subnet-mask

Example 3-3 illustrates configuration of an IP address on a VLAN interface on a Cisco IOS–based switch.

Switch(config)#interface vlan 101

Switch(config-if)#ip address 10.1.101.10 255.255.255.0

Switch(config-if)#no shut

Because Layer 2 switches do not perform routing functions, Layer 2 switches require a default gateway IP address to reach subnets beyond the local subnet. Use the following command to configure an IP default gateway on a Cisco IOS–based switch:

ip default-gateway ip-address

Example 3-4 illustrates the configuration of an IP default gateway on a Cisco IOS–based switch.

Switch(config)#ip default-gateway 10.1.101.1

Cisco CatOS–based switches are Layer 2 switches. As a result, these switches use a specialized interface for management, known as the sc0 interface. The sc0 configuration parameters include IP address, subnet mask, and VLAN. Use the following command to configure the sc0 management interface on Layer 2–only Cisco CatOS–based switches:

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

Then use the following command to configure the default gateway for a Cisco CatOS–based switch:

set ip route default gateway [primary]

To view the current sc0 interface configuration, use the following command:

show interface

Example 3-5 illustrates the configuration of an IP address on the sc0 interface and default gateway configuration on a Cisco CatOS–based switch in VLAN 5. Note that the broadcast address is automatically configured unless otherwise specified.

Console (enable) set interface sc0 5 10.1.101.11 255.255.255.0

Interface sc0 vlan set, IP address and netmask set.

Console (enable) set ip route default 10.1.101.1

Route added.

Console (enable) show interface
sl0: flags=51<UP,POINTOPOINT,RUNNING>
        slip 0.0.0.0 dest 0.0.0.0
sc0: flags=63<UP,BROADCAST,RUNNING>
        vlan 5 inet 10.1.101.1 netmask 255.255.255.0 broadcast 10.1.101.255

The Building Distribution and Campus Backbone submodule switches in Figure 3-1 are Layer 3 switches; these switches are composed of multiple IP subnets on either VLANs or Layer 3 interfaces. Consequently, these switches have multiple IP addresses, which may act as a management IP address. As long as the management IP address is reachable from any network for in-band access, any IP address configured on the Layer 3 switches suffices as a management IP address. However, it is nonetheless recommended to separate out a specific subnet for management purposes. In addition, these switches do not require default gateways because they are performing routing functions and using routing protocols. Later chapters of this book discuss Layer 3 routing configuration in more detail.

Clock settings to accurately display the time and date are essential in monitoring and troubleshooting Catalyst switches. Knowing exactly when events occur is crucial to maintaining control and stability of an enterprise network because system logging functionality uses timestamps. Furthermore, NTP is useful for synchronizing the system clocks for all network devices in the enterprise. Events for which time stamping is crucial include SNMP traps, SNMP inform messages, and system logging messages such as link state change, system reload, and so on. Use the following commands on Cisco IOS–based switches to configure the time and date along with the time zone; the clock set commands have two alternative formats:

clock set hh:mm:ss day month year
clock set hh:mm:ss month day year
clock timezone zone hours-offset [minutes-offset]

The clock set command is an executable command; the clock timezone command is a global configuration command. For the clock timezone configuration command, zone represents the time zone in abbreviations such as EST and PST, and hours-offset indicates the number of hours the current time zone is offset from UTC.

For Cisco CatOS–based switches, use the following commands to accomplish the same time and date configuration tasks:

set time [day_of_week] [mm/dd/yy] [hh:mm:ss]
set timezone [zone_name] [hours [minutes]]

Examples 3-6 and 3-7 illustrate configuration of the time, date, and time zone on Cisco IOS–based switches and Cisco CatOS–based switches, respectively.

Switch#clock set 12:30:00 May 1 2005
Switch#show clock
08:09:38.922 EST Mon Feb 7 2005
Switch#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

Switch(config)#clock timezone EST -5

Console> (enable) set time 05/01/2005 13:30:00

Sun May 1 2005, 12:30:00



Console> (enable) set timezone EST -5

Timezone set to 'EST', offset from UTC is -5 hours

Daylight savings time adjustments are configurable to automatically update the system clock if your location observes yearly time adjustments. Use the following commands to configure recurring or one-time time adjustments, respectively, on a per-time basis for Cisco IOS–based switches:

clock summer-time zone recurring [week day month hh:mm week day month hh:mm [offset]]
clock summer-time zone date date month year hh:mm date month year hh:mm [offset]
clock summer-time zone date month date year hh:mm month date year hh:mm [offset]

Use the following commands to configure recurring or one-time clock adjustments, respectively, for Cisco CatOS–based switches:

set summertime {enable | disable} [zone]
set summertime recurring [{week} {day} {month} {hh:mm} {week | day | month | hh:mm}
  [offset]]
set summertime date {month} {date} {year} {hh:mm} {month | date | year | hh:mm} [offset]

Examples 3-8 and 3-9 illustrate the configuration of the standard United States recurring daylight savings time on Cisco IOS–based switches and Cisco CatOS–based switches, respectively.

Switch(config)#clock summer-time EST recurring second sunday March 2:00 first sunday
november 2:00 1

Switch> (enable) set summertime recurring second Sunday March 2:00 first Sunday
november 2:00 1f

Summertime is enabled and set to ''

  Start : Sun Mar 11 2007, 02:00:00

  End   : Sun Nov 4 2007, 02:00:00

  Offset: 1 hour

  Recurring: yes, starting at 02:00am of second Sunday of March and ending on 02:00 am
of first Sunday of November.

The United States summertime parameters are the default and do not appear in the configuration. However, between 2007 and 2009, there is a shift to extend the period of daylight saving time in the United States as part of the Energy Policy Act of 2005. After 2009, a study will be presented to Congress to determine whether the extended period for daylight saving time is valuable and should continue.

Moreover, NTP is useful in synchronizing all the system clocks in the enterprise. Time synchronization is helpful in troubleshooting and network monitoring. To configure a Cisco IOS–based switch to synchronize its clock to an NTP server, use the following command:

ntp server ip-address

For information about the switch itself acting as an NTP server and additional NTP configuration options such as authentication keys and preferences, consult the configuration guide for the respective Catalyst switch.

To configure a Cisco CatOS–based switch to synchronize its clock to an NTP server, use the following command:

set ntp server ip_address

Examples 3-10 and 3-11 illustrate the configuration of NTP server associations on Cisco IOS–based switches and Cisco CatOS–based switches, respectively.

Switch(config)#ntp server 10.192.1.1

Switch> (enable) set ntp server 10.192.1.1

Both Cisco IOS–based and Cisco CatOS–based switches support administrative access via Telnet and SSH. Catalyst switches running Cisco IOS require a virtual terminal password configuration for command-line access, and both Cisco IOS and CatOS require an enable password for configuration access. Telnet passes passwords in clear-text. As a result, SSH, which does not transmit passwords in clear-text, is the preferable in-band connection method for CLI access to Catalyst switches. SSH requires the configuration of usernames and passwords and may optionally use RADIUS and TACACS+ methods of centralized security access. Cisco Secure supports both the TACACS+ and Radius Server features.

To configure a Cisco IOS–based switch’s virtual terminal password and an enable password, use the following virtual terminal interface and global configuration commands, respectively:

password password
enable password [level level] {password | [encryption-type] encrypted-password}

For this command, encryption-type specifies the Cisco-proprietary algorithm used to encrypt the password. Currently, the only encryption type available is 7. If you specify encryption-type, the next argument you supply must be an encrypted password (a password already encrypted by a Cisco router). For simplicity, do not use the encryption-type option; simply enter a nonencrypted password in the command line when configuring the enable password.

To configure a Cisco CatOS–based switch’s virtual terminal password and an enable password, use the following commands to generate prompt scripts for changing passwords:

set password
set enablepass

Examples 3-12 and 3-13 illustrate the configuration of Catalyst Cisco IOS–based switches and Cisco CatOS–based switches for enabling passwords and virtual terminal passwords, respectively.

Switch(config)#enable password cisco

Switch(config)#line vty 0 15

Switch(config-line)#password cisco

Console> (enable) set enablepass

Enter old password:

Enter new password: cisco
Retype new password: cisco

Password Changed


Console> (enable) set password

Enter old password:

Enter new password: cisco

Retype new password: cisco

Password Changed

As mentioned previously, SSH does not transmit passwords in clear-text and is the preferable method of in-band access. The SSH feature is available only on recent versions of Cisco IOS for the Catalyst switches. Table 3-3 lists the Cisco IOS versions for which the SSH feature is available.

To enable SSH on a Cisco IOS–based switch, use the following command to generate the necessary keys for SSH:

crypto key generate rsa

Other types of keys besides RSA are available in different versions of Cisco IOS. In addition to the crypto key generate command, enabling SSH requires the global configuration of aaa new-model. This command enables the use of local usernames and passwords for authentication, DNS name configuration, and virtual terminal configuration for inbound SSH sessions. Chapter 14 discusses additional security configurations and explains the aaa new-model command in more detail.

Example 3-14 illustrates the enabling of SSH as the only method of in-band access on a Cisco IOS–based switch.

Switch(config)#ip domain-name cisco.com

Switch(config)#aaa new-model

Switch(config)#username cisco password cisco

Switch(config)#crypto key generate rsa modulus 2048

The name for the keys will be: Switch.cisco.com



% The key modulus size is 2048 bits

Generating RSA keys ...

[OK]



00:02:36: %SSH-5-ENABLED: SSH 1.5 has been enabled

Switch(config)#line vty 0 15

Switch(config-line)#transport input ssh

For additional configuration parameters and examples of configuring SSH on Cisco IOS routers and switches, refer to the following technical document on Cisco.com:

In regard to Cisco CatOS software, Table 3-4 illustrates the software support of the SSH feature on Cisco CatOS–based Catalyst switches.

Example 3-15 illustrates the enabling of SSH as the only method of in-band access on a Cisco CatOS–based switch. Enabling an IP permit list without entries prevents access via the configured protocol.

Switch (enable) set crypto key rsa 2048

Generating RSA keys............... [OK]



Switch (enable) set ip permit enable telnet

TELNET permit list enabled.

WARNING!! IP permit list has no entries.

Although SSH is fairly secure, there are several inherent vulnerabilities that exist as a result of the protocol itself. Aside from protocol vulnerabilities, implementation and hardware or software defects on specific Cisco products might yield additional vulnerabilities. Keeping up-to-date on Cisco field notices, product vulnerabilities, and software versions minimizes security issues with SSH. The following list describes possible vulnerabilities with SSH, most of which have been addressed in the latest software versions of Cisco IOS and other vendor SSH server and client software:

Configuring DNS on Catalyst switches is useful for resolving domain names to IP addresses for management and troubleshooting purposes. To configure Cisco IOS–based switches for DNS, use the following commands:

ip name-server address [address2...address6]
ip domain-name domain
ip domain-lookup

The ip name-server address command configures up to eight domain servers to query for DNS resolution. The ip domain-name domain command specifies the domain on which the switch resides, and the ip domain-lookup command enables DNS resolution.

To configure Cisco CatOS–based switches for DNS, use the following commands:

set ip dns server ip-addr [primary]
set ip dns domain name
set ip dns {enable | disable}

The set ip dns server ip-addr command adds DNS servers to configured lists of servers. The Catalyst switch queries the primary DNS server before moving to other DNS servers in the list if there is no response to the DNS query. The set ip dns enable command enables the switch to perform DNS queries.

Examples 3-16 and 3-17 illustrate configuring Catalyst Cisco IOS–based switches and Cisco CatOS–based switches for DNS functionality, respectively.

Switch(config)# ip domain-name cisco.com

Switch(config)# ip name-server 10.4.1.209 10.4.1.210

Switch(config)# ip domain-lookup

Console> (enable) set ip dns server 10.4.1.209

10.4.1.209 added to DNS server table as primary server.

Console> (enable) set ip dns server 10.4.1.210

10.4.1.210 added to DNS server table as backup server.

Console> (enable) set ip dns domain cisco.com

Default DNS domain name set to cisco.com

Console> (enable) set ip dns enable

DNS is enabled

System logging is another useful tool to manage Catalyst switches. By default, Catalyst switches log critical information to a local buffer that is configurable in size. In addition, Catalyst switches support various logging levels, from emergency-level settings to debugging-level settings of various features and components, such as the Cisco Discovery Protocol (CDP) and the IEEE 802.1D Spanning Tree Protocol (STP). Generally, it is advisable to log all messages up to the critical status to a syslog server. Using a syslog server centralizes monitoring of multiple Catalyst switches in the enterprise.

For more information about syslog levels, facilities, and components, refer to the technical documentation for the respective Catalyst switch on Cisco.com. Recommended practice is to configure all Catalyst switches to log to syslog servers as part of their initial configuration.

To configure a Cisco IOS–based switch for system logging to a syslog server, use the following command:

logging ip-address

To configure a Cisco CatOS–based switch for system logging to a syslog server, use the following commands:

set logging server ipaddress
set logging server {enable | disable}

Examples 3-18 and 3-19 illustrate the configuration of Catalyst Cisco IOS–based switches and Cisco CatOS–based switches for DNS functionality, respectively.

Switch(config)# logging 10.1.1.118

Console> (enable) set logging server 10.1.1.118

10.1.1.118 added to system logging server table.

For information about different logging levels of Catalyst features and system capabilities, consult Cisco.com.

Simple Network Management Protocol (SNMP) is a powerful and standards-based protocol by which to manage network devices. Example use of SNMP includes the following:

In small networks, SNMP is mostly useful for monitoring; however, in large enterprise networks, SNMP is useful for configurations as well. Due to the large size of enterprise networks, centralized management and configuration is essential to successful deployments of multilayer switched networks.

All Cisco Catalyst switches support SNMP. A complete discussion of SNMP is outside the scope of the BCMSN; nevertheless, it is important to review the basic configuration needed to allow remote management of Cisco Catalyst switches through SNMP. Applications such as CiscoWorks, HP OpenView, and What’s Up use SNMP to manage, track, monitor, and gather performance data from Cisco network devices.

There are three main versions of SNMP:

Most enterprise networks currently use version 2c with a defined upgrade path to version 3. Version 3 is the only version that supports a high level of security using encryption. Table 3-5 shows the security levels available with SNMP.

Recommended practice is to use SNMPv3 with secure authentication and command encryption; however, most enterprise networks have built their management applications around SNMPv2, and it might be some time before enterprise networks fully migrate to SNMPv3. Nevertheless, avoid using the read-only and read-write community strings as public and private, because those strings tend to be the standard default in enterprise networks. In review, SNMPv3 provides enhanced network security through the following features:

For more information on configuring SNMP with Cisco IOS on Catalyst switches, search the Cisco.com website for SNMP.

snmp-server community string [view view-name] [ro | rw] [number]

Cat6500-MSFC(config)#snmp-server community public ro
Cat6500-MSFC(config)#snmp-server community private rw

snmp-server engineID [local engineid-string] | [remote ip-address udp-port port-
number engineid-string]

snmp-server host host [traps | informs][version {1 | 2c | 3 [auth | noauth | priv]} ]
community-string [udp-port port] [notification-type]

Cat6500-MSFC(config)#snmp-server EngineID local MSFC123
Cat6500-MSFC(config)#snmp-server host 10.1.1.12 traps version 2c public

snmp-server group [groupname {v1 | v2c | v3 [auth | noauth | priv]}][read readview]
[write writeview] [notify notifyview] [access access-list]

snmp-server user username [groupname remote ip-address [udp-port port] {v1 | v2c | v3
[encrypted] [auth {md5 | sha} auth-password [priv des56 priv password]] [access
access-list]

To determine the size, available space, and contents of the Cisco IFS, use the following command in both Cisco CatOS and Cisco IOS:

show flash

Example 3-24 illustrates a user displaying information about the IFS on a Catalyst 2950 and 4500 running Cisco IOS and a Catalyst 6500 running Cisco CatOS, respectively. Note that the Catalyst 4500 does not support the show flash command on the current software version.

! Catalyst 2950 Switch:

Switch#show flash



Directory of flash:/



    2  -rwx     2664051   Mar 01 1993 00:03:38  c2950-i6q4l2-mz.121-11.EA1.bin

    3  -rwx         616   Mar 06 1993 01:45:22  vlan.dat

    4  -rwx     2774747   Mar 03 1993 18:35:17  c2950-i6q4l2-mz.121-12c.EA1.bin

   22  -rwx         316   Mar 03 1993 20:11:35  env_vars

    7  drwx         896   Mar 03 1993 18:36:23  html

   19  -rwx         110   Mar 03 1993 18:37:12  info

   20  -rwx         110   Mar 03 1993 18:37:12  info.ver



7741440 bytes total (571392 bytes free)
___________________________________________________________________________________

! Catalyst 4500 Switch running Cisco IOS
Switch#show bootflash:

-#- ED ----type---- --crc--- -seek-- nlen -length- -----date/time------ name

1   .. config       76481B10 12B1018   15    56610 Jan 31 2000 22:08:56 Backup

2  .. image         40A9D879 2E07B90  28  8150708 Aug 18 2000 15:39:37 cat4000-is-
mz.121-12c.EW.bin


13599856 bytes available (47741840 bytes used)
___________________________________________________________________________________

! Catalyst 6500 Switch running Cisco CatOS:

Console> (enable) show flash
-#- ED --type-- --crc--- -seek-- nlen -length- -----date/time------ name

  1 .. ffffffff f61a1629 673028  24  6238120 Nov 26 2002 14:10:11 cat6000-sup2k8.7-
4-3.bin


25743320 bytes available (6238248 bytes used)

The name of the Cisco IOS or Cisco CatOS image indicates the appropriate platform and version. For the Cisco IOS images, the filename contains multiple parts specifying platform, software release number, features, and type. For example, the filename c2950-i6q412-mz.121-11.EA1.bin contains this information:

The Cisco IOS software naming conventions, field meanings, image content, and other details are subject to change. For the most updated list of Cisco IOS software naming conventions, consult the following document on Cisco.com:

Cisco IOS show and debug commands are important tools for troubleshooting network anomalies, connectivity problems, performance issues, and other anomalous behavior. The show commands provide a static collection of information about the status of a network device, neighboring switches and routers, and network performance. Use show commands when gathering facts for isolating problems in an enterprise network, including problems with interfaces, nodes, media, servers, clients, or applications. An example of using show commands for troubleshooting is using the show interface command to gather error statistics such as the number of Layer 2 cyclic redundancy check (CRC) frames received from a directly attached device.

The debug commands provide a flow of information about the traffic being seen (or not seen) on an interface, error messages generated by nodes on the network, protocol-specific diagnostic packets, and other useful state troubleshooting data. Use debug commands when you need to see process operations on the router or network to determine whether events or packets are working properly. One such example is debugging Cisco Express Forwarding (CEF) switching to verify behavior of packet flows.

Use debug commands only to isolate problems, not to monitor network or switch operation. Generally, it is advisable to use debug commands only under the supervisor of a TAC engineer because debugs may result in high CPU overhead. The following list summarizes important notes about the use of debug commands:

Time stamping of debug and log messages is essential to proper debugging. Knowing time frames and exact instances when events occur is critical to troubleshooting performance issues. To configure Cisco IOS–based switches to time stamp debug and log messages, use the following Cisco IOS global configuration commands:

service timestamps debug {datetime | uptime} [{msec} {localtime} {show-timezone}]
service timestamps log {datetime | uptime} [{msec} {localtime} {show-timezone}]

Other parameters exist for configuring debug and logging time stamps; the commands listed with the msec and localtime options add millisecond time stamps using the switch’s current time to all messages. These parameters are found to be the most useful when troubleshooting from the CLI. For Cisco CatOS–based switches, use the following command to enable and disable logging:

set logging timestamp [enable | disable]

On Cisco CatOS–based switches, time-stamp logging is a default configuration.

Noting CPU load before enabling debugging is necessary to prevent high CPU conditions. To determine the current CPU load before enabling debug commands, use the following Cisco IOS command:

show processes

This command reveals the current processes that are running and the total CPU utilization. It is not advisable to enable debugging when the CPU utilization is over 70 percent; doing so may further increase CPU utilization and cause anomalous behavior on the switch. Recall that current Catalyst switches use hardware switching for packet forwarding, and CPU utilization is not a direct correlation of packet performance.

Two other useful commands when enabling and disabling debugs are the no debug all and undebug all commands. These commands are useful for immediately disabling all debugs to prevent further CPU utilization.

Generally, if an abnormal situation results in the use of debugs, temporarily trading off switching and CPU efficiency for the opportunity to rapidly diagnose and correct the problem may be ideal. To effectively use debugging tools, determine the following information:

Some considerations for using debug commands are as follows:

All debug commands are entered in privileged EXEC mode, and most debug commands do not require parameters. Nevertheless, debug parameters are useful in isolating debug information to a specific interface or feature.

To list and see a brief description of all the debugging command options, enter the debug ? command in privileged EXEC mode.

By default, the network server sends the output from debug commands and system error messages to the console. Monitoring debugging output by using a virtual terminal connection is the preferable debugging method to the console port. However, in certain situations, virtual terminal access may be affected by the issue you are trying to debug. To redirect debugging output, use the logging command options within configuration mode. Possible destinations include the console, virtual terminals, internal buffer, and UNIX hosts running a syslog server. The syslog format is compatible with 4.3 Berkeley Standard Distribution (BSD) UNIX and its derivatives. Note that by default, virtual terminal sessions do not display debug or logging output; enter the terminal monitor EXEC command to enable display of logging and debug output to the current virtual terminal session.

For additional information about troubleshooting using protocol analyzers and other debugging and baselining tips, see Chapter 17, “Performance and Connectivity Troubleshooting Tools for Multilayer Switches.”

If you are unable to connect to the switch via the console port, perform the following troubleshooting steps. The order of the steps is not significant:

If you are unable to establish connectivity to or from a switch using Telnet or SSH, perform the following troubleshooting steps. The order of these steps is significant:

The resources and equipment required to complete this exercise are as follows:

The purpose of this exercise is to demonstrate the initial configuration of a Cisco IOS–based Catalyst switch acting as a Layer 2 switch. At the end of this exercise, you will be able to execute the following initial configurations on Cisco IOS–based Catalyst switches:

The exercise exposes topics (such as VLANs) that are found in later chapters; however, the main purpose of this exercise is to demonstrate initial switch configuration.

Figure 3-3 shows the network layout for this lab exercise.

Figure 3-3. Network Diagram for Lab Exercise

In this lab exercise, you will use the commands listed in Table 3-10. These commands are in alphabetical order so that you can easily locate the information you need. Refer to this table if you need configuration command assistance during the lab exercise. The table includes only the specific parameters used in the example and not all the available options for the command.