Troubleshooting Basic Switch Connectivity – CCNA Course

troubleshooting basic switch connectivity

As always, when troubleshooting connectivity issues, use a layered approach and eliminate possibilities at each layer to home in on the possible cause of the problem. Over time, you will begin to develop a sixth sense about these problems and decrease the amount of effort it takes to accurately pinpoint a connectivity problem. In the meantime, let’s look at some possible connectivity scenarios and walk through some possible deductions as to what might cause the problem.

In instances where you cannot gain console connectivity to the switch, you should ask the following questions:

  1. Is the switch powered on and running? Although this seems like common sense, it is still valid to check to make sure the switch is powered on and successfully completed its bootup process. Catalyst switches all have LEDs (light-emitting diodes) on the switch face to signify that it is operating correctly. The system and status lights for the switch should both be a steady green if the device is powered on and operating normally.
  2. Are your terminal connections correct? Verify that you have configured your terminal application correctly by setting the speed, flow control, and start and stop bits and ensure that you have the console (rollover) cable connected between your PC and the switch.
  3. Did you or someone else change the console password? If you are gaining access to IOS but cannot log in, you may need to perform password recovery on the switch. Consult the switches manually or look online at cisco.com to switch specific steps to recover your password.

In instances where you cannot gain remote connectivity to the switch, you should ask the following questions:

  1. Is the switch powered on and running? If possible, console into the switch or have someone check that switch is powered on and successfully completed its bootup process.
  2. Do you have IP connectivity to the switch? You can utilize troubleshooting commands from the switch such as ping to test connectivity between the switch and management computer you are remotely connecting from. If your pings fail, verify that you have configured the default for the switch and continue troubleshooting using the traceroute command to identify where along the forwarding data path the packets failing.
  3. Did you or someone else change the vty password or SSH login and password? If you are gaining access to IOS but cannot log in, you may need to reconfigure the SSH and Telnet passwords via the console to regain access to these remote management protocols.

In instances where the switch is not forwarding frames, you should ask yourself these questions:

  1. Is the switch powered on and running? This would be fairly evident because all devices connected to the switch would be unable to communicate with each other. If possible, check that the switch is powered on and successfully completed its boot-up process.
  2. Does the switch have Layer 1 connectivity to the devices? The LEDs above the port may give you a quick indication if there is a problem with that port.

To verify your cabling, ensure you are using a straight-through Ethernet cable if connecting to a PC, router, or other end devices. If connecting to another switch, you should have a cross-over Ethernet cable attached to those interfaces. What’s more, you can also verify that the interfaces are not administratively shut down and are in an up/up state using the show interfaces interface-id command.

Keep in mind that if you just connected the end device to the switch, it will take at least 30 seconds to transition to a forwarding state, as dictated by spanning tree protocol.

  • Does the output of the show interfaces interface-id command show you incorrect speed or duplex? An interface that does not become active or is constantly bouncing up and down may indicate duplex and/or speed mismatches from auto-negotiation. This will be evident if the show interfaces interface-id output is displaying excessive collisions or the interface is in an up/downstate. To remedy this problem, ensure that the switch and the end device are set for auto-negotiation. To eliminate all doubt, manually set the speed and duplex parameters on the switch ports and the end device.
  • Does your switched internetwork intermittently stop forwarding frames? Recall that when new switches are added to a switched internetwork, it may take up to 50 seconds to have the switch’s coverage to the new STP topology. If you are not adding switches to the network, verify that there isn’t a faulty switch causing re-election of the STP topology by using the debug spanning-tree command. This command shows real-time events of the spanning-tree process and indicates whether a switch might have an interface that is going up and down causing re-elections in the STP  topology.