In theory, once a device is configured and working it should stay that way, but, often, you will be working on a network which you didn’t configure, or you will be working on a shift pattern supporting many unfamiliar networks on which changes have been made, causing one or more issues for the company. I suggest you revist this section after completing a few labs in this guide as the days progress.
Common Switch Issues
Can’t Telnet to Switch
The first question is was Telnet ever working? If it was and is no longer, then perhaps somebody has made a change on the switch, reloaded it, and lost the configuration, or a device is now blocking Telnet traffic somewhere on the network:
Switch#telnet 192.168.1.1
Trying 192.168.1.1 …Open
[Connection to 192.168.1.1 closed by foreign host]
The first thing to check is whether Telnet has actually been enabled on the switch (see the output below). Around 80% of errors on the network are due to silly mistakes or oversights, so never presume anything, and check out everything personally, rather than relying on other people’s words.
A simple show run command will reveal the switch configuration. Under the vty lines, you will see whether Telnet has been enabled. Note that you will need to have the login or login local (or configured AAA, which is beyond the scope of the CCNA exam) command under the vty lines and the password command, as shown below:
line vty 0 4
password cisco
login
line vty 5 15
password cisco
login
The login local command tells the switch or router to look for a username and password configured on it, as illustrated in the output below:
Switch1#sh run
Building configuration…
Current configuration : 1091 bytes!
version 12.1
hostname Switch1
username david privilege 1 password 0 football
line vty 0 4
password cisco
login local
line vty 5 15
password cisco
login local
…
[Truncated Output]
Can’t Ping the Switch
Find out why the person wants to ping the switch in the first place. If you do want to ping a switch, there needs to be an IP address configured on it; in addition, the switch needs to know how to get traffic back out (the default gateway).
Can’t Ping through the Switch
If a ping through the switch is unsuccessful, then check to ensure that the end devices are in the same VLAN. Each VLAN is considered a network and for this reason must have a different address range from any other VLAN. In order for one VLAN to reach another, a router must route the traffic.
Interface Issues
By default, all router interfaces are closed to traffic and switch interfaces are open. If you find that your switch has had its interfaces administratively shut, to open it, the interface must be set with the no shut interface-level command:
Switch1(config)#int FastEthernet0/3
Switch1(config-if)#no shut
Layer 2 interfaces can be set in three modes: trunk, access, or dynamic. Trunk mode lets the switch connect to another switch or a server. Access mode is for an end device, such as a PC or a laptop. Dynamic mode lets the switch detect which setting to select.
The default on platforms such as the 3550 model switch is usually dynamic desirable, but please check your model’s settings and release notes on Cisco.com. For the CCNA exam, you will be asked to configure a 2960 model switch. It will select the mode dynamically unless you hard set it to trunk or access mode:
Switch1#show interfaces switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic auto
The default can easily be changed, as shown in the output below:
Switch1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#int FastEthernet0/1
Switch1(config-if)#switchport mode ?
access Set trunking mode to ACCESS unconditionally
dynamic Set trunking mode to dynamically negotiate access or trunk mode
trunk Set trunking mode to TRUNK unconditionally
Switch1(config-if)#switchport mode trunk
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
Switch1(config-if)#^Z
Switch1#
%SYS-5-CONFIG_I: Configured from console by console
Switch1#show interfaces switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
More Interface Issues
Switch port default settings are auto-detect duplex and auto-detect speed. If you plug a 10Mbps device into a switch running at half duplex (if you could even find such a device), then the port should detect this and work. This isn’t always the case, though, so the generic advice is to hard set the switch port speed and duplex, as illustrated in the output below:
Switch1#show interfaces switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic auto
Switch1#show interface FastEthernet0/2
FastEthernet0/2 is up, line protocol is up (connected)
Hardware is Lance, address is 0030.f252.3402 (bia 0030.f252.3402)
BW 100000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
Switch1(config)#int fast 0/2
Switch1(config-if)#duplex ?
auto Enable AUTO duplex configuration
full Force full-duplex operation
half Force half-duplex operation
Switch1(config-if)#speed ?
10 Force 10Mbps operation
100 Force 100Mbps operation
auto Enable AUTO speed configuration
Signs of duplex mismatches (apart from error messages) include input and CRC errors on the interface, as illustrated in the output below. Please also see the Layer 1 and Layer 2 Troubleshooting sections in Day 15 of the ICND1 section.
Switch#show interface f0/1
FastEthernet0/1 is down, line protocol is down (disabled)
Hardware is Lance, address is 0030.a388.8401 (bia 0030.a388.8401)
BW 100000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 100Mb/s
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:08, output 00:00:05, output hang never
Last clearing of “show interface” counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
956 packets input, 193351 bytes, 0 no buffer
Received 956 broadcasts, 0 runts, 0 giants, 0 throttles
755 input errors, 739 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
2357 packets output, 263570 bytes, 0 underruns
0 output errors, 0 collisions, 10 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Hardware Issues
As with any electrical device, ports on a switch can fail or work only part of the time, which is harder to troubleshoot. Engineers often test the interface by plugging a known working device into another port on the switch. You can also bounce a port, which means applying the shut command and then the no shut command to it. Swapping the Ethernet cable is also a common troubleshooting step. Other common switch problems and solutions are shown in Figure 2.20 below.
Please check the documentation for your switch because, as well as featuring system and port LEDs, each port can display flashing or solid red, amber, and green, indicating normal function or port/system issues.
Figure 2.20 – Common Switch Problems and Solutions
VLAN Assignment Issues
Networks in small environments are relatively easy to manage because a limited number of features need to be implemented in order to achieve the business’s goals. However, in an enterprise environment you won’t be using small workgroup switches and SOHO devices. Rather, you will use high-end devices that are capable of optimising the traffic flow by offering a number of advanced functionalities.
One particular feature that might be configured in such an environment is logically separating different network areas using VLANs. Issues can appear when you have configuration issues related to a particular VLAN and this can become difficult to troubleshoot. One way of doing this is analysing the entire configuration on the switch and trying to identify the problem.
VLAN-related problems are usually detected by observing the lack of connectivity between network hosts (e.g., a user cannot ping a server), even though Layer 1 seems to operate without problems. One important characteristic of VLAN-related problems is that they do not generate any performance degradation on the network. If you misconfigure a VLAN, the connection will simply not work, especially considering that they usually separate IP subnets so that only devices within the same VLAN will be able to communicate with each other.
The first step in troubleshooting VLAN problems is to review the documentation and the logical diagrams developed in the design phase so you can identify the span area for each VLAN, including the associated devices and ports on each switch. The next step is to inspect each switch configuration and try to find the problem by comparing them with the documented solution.
You should also verify the IP addressing scheme. If you are statically assigning IP addresses to devices, you may want to go back and check the device to ensure that it has the proper IP address and subnet mask combination. If there are any mistakes in the IP addressing scheme, like configuring devices on the wrong network or with a wrong subnet mask/default gateway, then you are going to have connectivity problems, even though you have the correct VLAN configured on the switch.
You will also want to confirm that the trunk configuration on the switches is correct. If you have multiple switches, there are usually uplinks between them and VLANs carried across those uplinks. These inter-switch links are often configured as trunks to allow communication across multiple VLANs. The VLAN has to be a member of the trunk group if data is to be sent from one switch to the other, so you also have to make sure that the switch configuration on both sides is set up properly.
Finally, if you move a device to another VLAN, you will have to make changes to both the switch and the client because the client will have a different IP address in a different IP subnet as a result of that move.
If you follow all of these VLAN troubleshooting methods, you can be sure that when plugging in devices for the first time or moving them from VLAN to VLAN, you will have the exact connectivity you desired.