Cisco Switch Configuration Basics

In my last post, I introduced the basic concepts of switching and the MAC address table. In this post, I’ll cover some important points about interface configuration, especially regarding speed and duplex, as well as sundry global configuration settings.

Logging into a new Cisco switch via the console port is easy enough. I typically use the PuTTY terminal emulation software, with the required settings of 9600 bps, 8 data bits, 1 stop bit, no parity and no flow control. Once the session is connected, you are placed into user EXEC mode, where you can look but not touch. First up, let’s move into global configuration mode and give the switch a hostname:

Switch> enable
Switch# configure terminal
Switch(config)# hostname Icarus

Since we haven’t set any passwords yet, we can just march right into privileged EXEC mode and thence into global configuration mode. The hostname shows up in subsequent prompts and is useful when you have multiple switches and connect remotely to administer them.

To set a password for privileged EXEC (or enable) mode, you can use:

Icarus(config)# enable password letmein

However, this password is stored in the running configuration in clear text, and is therefore vulnerable. Better to use the more secure secret password, which is encrypted in the configuration file:

Icarus(config)# enable secret opensesame

With both passwords configured, the switch will require the secret version to allow you future access to enable mode. The plain version will remain stored in the running configuration, but will not be used. Let’s remove it:

Icarus(config)# no enable password

Prefixing many Cisco IOS commands with no will reverse or remove them. To try the new password, let’s back out of global configuration mode and return to user EXEC mode, then enter privileged EXEC mode again:

Icarus(config)# end
Icarus# disable
Icarus# enable

This time, the switch prompts for the enable secret password before granting access. But how about preventing console access to the switch at all—even into user EXEC mode? This is easy and just requires the setting of a console password:

Icarus> enable
Icarus# configure terminal
Icarus(config)# line console 0
Icarus(config-line)# password abracadabra
Icarus(config-line)# login
Icarus(config-line)# exit

Line console 0 is the first (usually the only) console line into the device. Here, we just set a password and use the login command to tell the device to prompt for it. If you logout fully

Icarus(config)# end
Icarus# logout

and then reconnect, you will be prompted for the console password. Do note that this password is stored in clear text, and is not as secure as the secret passwords, which are encrypted. Is there a better way? There sure is: we can create a local user account with a secure secret password, and tell the console to use this instead:

Icarus> enable
--- Type password ---
Icarus# configure terminal
Icarus(config)# username frasier secret activ8

Here, we head into global configuration mode and create the local user account, with a name of frasier and a password that will be encrypted in the running configuration. Next, we must tell the console to use this account:

Icarus(config)# line console 0
Icarus(config-line)# no password
Icarus(config-line)# login local
Icarus(config-line)# exit

First, we remove the simple password we added earlier, then we tell the console to require a local account for granting access. If you disconnect and reconnect, you must now use this new account, and you will be prompted for a username and password accordingly. It’s likely that you’ll want to access the switch over the IP network when in production, to save the hassle of having to physically connect to the console port. I’ll cover the use of Telnet and Secure Shell to access switches and routers in a separate post, once I’ve covered VLANs.

Now, let’s cover the configuration of interfaces, particularly the assignment of speed and duplex settings. From global configuration mode, you use the interface command, followed by the name of the interface to configure, e.g.

Icarus(config)# interface fa0/1
Icarus(config-if)#

However, you can also configure a range of interfaces in one fell swoop, just by adding the range parameter:

Icarus(config)# interface range fa0/1 - 5
Icarus(config-if-range)#

As expected, this will enter a configuration mode for all five interfaces, and any commands you use will be applied to them all. Note how the IOS prompts differ for single interfaces and ranges. To target multiple non-contigouous ranges, drop in a comma after each one:

Icarus(config)# interface range fa0/1 - 3, fa0/8 – 12

Here, we configure interfaces 1 to 3 and 8 to 12 in a single command. All right, let’s stick to a single interface, and give it a description. These can be useful for the administrator to indicate what is supposed to be connected to the port:

Icarus(config)# interface fa0/1
Icarus(config-if)# description Connects to client PC

To administratively disable the port, issue the shutdown command. Use no shutdown to bring it back up:

Icarus(config-if)# shutdown
Icarus(config-if)# no shutdown

The Cisco exams are wont to ask about speed and duplex settings for switch ports. Today, most switches will have Gigabit Ethernet ports, as will most end devices. Thus, they expect to operate at 1 Gbps. Older equipment may well be using Fast Ethernet, which operates at 100 Mbps, or one-tenth of the Gigabit speed. By default, switch ports are set to auto-negotiate both speed and duplex with the attached device. In a modern set-up, you will attach a gigabit device to a gigabit switch port, and the two will happily negotiate a 1 Gbps, full-duplex connection. You can manually configure these settings on a switch interface, although there is seldom need to do so. If, for some obscure reason, I needed to limit a modern connection to 10 Mbps, half-duplex, I could configure the port as follows:

Icarus(config-if)# speed 10
Icarus(config-if)# duplex half

This would cap the allowed speed to 10 Mbps and force half-duplex operation, meaning that collision-detection logic would be applied. However, manually setting the speed and duplex invites danger. Before we consider what happens when things go awry, let’s see how to confirm what settings a switch port is actually using. One way is to issue the classic show interfaces command, which I’ll prefix with do, since I’m currently in interface configuration mode and this is really a privileged EXEC command:

Icarus(config-if)# do show interfaces fa0/1

--- Sample output ---

FastEthernet0/1 is up, line protocol is up
Hardware is Gigabit Ethernet Port, address is A050.547b.cee5 
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
   reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 10Mb/s

--- Omitted output ---

I’ve cleaned up the output a little, but the duplex and speed are clearly shown on line six. Let’s restore their default settings:

Icarus(config-if)# speed auto
Icarus(config-if)# duplex auto
Icarus(config-if)# do show interface fa0/1

--- Sample output ---

FastEthernet0/1 is up, line protocol is up
Hardware is Gigabit Ethernet Port, address is A050.547b.cee5 
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
   reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Auto-duplex, Auto-speed

--- Omitted output ---

Notice that, when auto-negotiation is used, the actual speed and duplex that were chosen are not shown here. If you want a summary of all the ports’ settings, you can issue the show interfaces status command, which proves most useful by showing just a single line per interface plus the chosen speed and duplex:

Icarus(config-if)# do show interfaces status

--- Sample output ---

Port  Name  Status     Vlan  Duplex  Speed  Type
----  ----  ------     ----  ------  -----  ----
Fa0/1       connected  1     a-full  a-1000 10/100/1000BaseTX

--- Omitted output ---

I’ve included just the line for the Fa0/1 port, since that is the only one connected in my simple scenario. Note the Duplex and Speed fields, which are both prefixed with a- to indicate they were auto-negotiated. The Status is listed as connected, which indicates that the port is operational.

So, what’s the problem with manually setting the speed and duplex? Well, as a rule of thumb, if you set these manually at the switch port, you should also manually configure them on the device. This effectively disables auto-negotiation, and the devices will use the given settings every time. But this leads to greater administrative overhead, and if the device is changed, and the new one is not configured with the same settings, the link can break. Therefore, it’s advisiable to use auto-negotiation whenever possible. If you must manually configure both ends, because auto-negotiation is failing for some reason, just be sure to match the speed and duplex settings. The speed should be the highest that is mutually supported, and in any modern topology you’ll want full-duplex.

Most troubles occur when the device is manually configured (for example, the user has disabled auto-negotiation) and the switch port is set to auto-negotiate. Let’s see what happens when auto-negotiation fails. Back in 1995, with the release of the Fast Ethernet specification, 802.3u, the IEEE also introduced the auto-negotiation process. But it was optional and manufacturers differed in how they implemented it. Fortunately, the 1999 Gigabit Ethernet standard, 802.3ab, made a well-defined negotiation process mandatory. When the link comes up, each device states what it is capable of, and the best speed and duplex settings are selected.

When this process fails, often because one end has been manually configured, the IEEE specification defines some rules. Imagine our switch port is set to auto-negotiate, but the attached PC has been manually configured. The port awaits the PC’s best settings, but they are not forthcoming. Therefore, according to the IEEE, the port should fall back to its slowest available speed (probably 10 Mbps) and to use half-duplex—unless the chosen speed is 1 Gbps, in which case full-duplex is used. Thus, it is highly likely that the port will choose 10 Mbps, half-duplex. Cisco devices are somewhat more intelligent though. Rather than simply choosing their slowest speed, they are capable of detecting the link speed automatically (although, if this fails, they do follow the IEEE and use their slowest speed). If the detected speed is 1 Gbps, they use full-duplex; otherwise they use half-duplex.

As always, a couple of concrete examples. The switch port is set to its default of auto-negotiate, but the PC is set to use 100 Mbps, full-duplex. What settings will the port choose? Well, auto-negotiation fails, and the port detects the PC’s speed correctly as 100 Mbps. According to the rules, it will therefore use half-duplex mode. What if the PC was set to 1 Gbps, half-duplex? This time, the detected speed would be 1 Gbps, and so full-duplex would be chosen by the port.

These scenarios often lead to a low-quality link, where one end uses full-duplex and the other uses half-duplex. This is called a duplex mismatch. Recall that half-duplex operation invokes all the classic collision-detection logic, even though no collisions can occur on a point-to-point link between a single device and its switch. Some frames will get through just fine, but if one end (thinking it’s operating in full-duplex) starts sending while the other is also sending, the half-duplex end will back off and start transmitting its jamming signal. The result will be an increasing number of aborted and erroneous frames. This situation can be hard to diagnose, since the link will be shown as connected on the switch, even though its performance is degraded.

Fortunately, you can ask the switch to show you error information. The place to look is the output of the show interfaces command:

Icarus(config-if)# do show interface fa0/1

--- Sample output ---

FastEthernet0/1 is up, line protocol is up
Hardware is Gigabit Ethernet Port, address is A050.547b.cee5 
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
   reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Auto-duplex, Auto-speed
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/120, 8 drops
5 minute input rate 2000 bits/sec, 3 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
   158773 packets input, 17362631 bytes, 4 no buffer
   Received 158781 broadcasts, 0 runts, 0 giants, 7 throttles
   0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
   0 watchdog, 0 multicast
   0 input packets with dribble condition detected
   6299 packets output, 622530 bytes, 0 underruns
   1 output errors, 0 collisions, 3 interface resets
   0 babbles, 0 late collisions, 0 deferred
   1 lost carrier, 1 no carrier
   0 output buffer failures, 0 output buffers swapped out

Pay attention to the details at the end, where various error counters are given. Now, if you are indeed running in a genuine old-school half-duplex environment, with a hub attached to a half-duplex switch port for instance, then seeing these collision errors increase is quite normal. But, in any modern environment, collisions should not happen. So, if your switch has tried to auto-negotiate and failed, and has chosen half-duplex mode, and the device at the other end is using full-duplex, you can expect to see some of these counters increment.

In particular, the late collisions counter is likely to prove twitchy. Classic half-duplex Ethernet is designed to detect collisions within the first 64 bytes of a transmitted frame; but since the full-duplex end can transmit at any time, collisions can—and will—occur at any time. So, if the Cisco exams talk about increasing errors on an Ethernet interface, you’ll want to check the speed and duplex settings.

To finish up, let’s save the switch’s current running configuration into NVRAM, so that it will be restored whenever the switch is rebooted:

Icarus(config-if)# end
Icarus# copy running-config startup-config

In my next post, I’ll cover the essentials of linking two switches together via trunking.

Leave a Reply

Your email address will not be published. Required fields are marked *