• 'x' is only required for outgoing connections from the Cisco node. Ctrl + shift + 6 then x basically puts the outgoing connection into suspend mode. If you just want to break from CLI prompts ctrl + shift + 6 should be fine. But it also depends on your terminal client. – APA Dec 6 '17 at 8:45.
• What is the difference between sending a standard break sequence using Control+Break and a special break command using PuTTY? The reason for asking is that my colleague could not send a break using the Control+Break keyboard keys but was able to interrupt to booting of an ME3600-X switch using the special break command from the PuTTY menu, which I find rather weird.

1. Show Time Cisco Switch
2. Cisco Router Command List
3. Break Command For Cisco Switch
4. Cisco Commands List
5. Cisco Break Command Putty
6. Cisco Switch Break Command
7. Basic Cisco Switch Commands

Cisco switches can be used as plug-and-play devices out of the box but they also offer an enormous amount of features. Although the main purpose of the switch is to provide inter-connectivity in Layer 2 for the connected devices of the network, there are myriad features and functionalities that can be configured on Cisco Switches. Some newer switches only support 802.1Q and in that case this command will be unavailable. It’s also possible that packet tracer doesn’t support it, it’s a simulator after all. It doesn’t matter too much thoughwhen this command doesn’t work then the switch will use 802.1Q when you configure the interface as a trunk.

Unfortunately there is no easy way to recover a corrupt or deleted IOS image on a fixed configuration Cisco Catalyst switch. You must use xModem which commonly takes 2+ hours. This lab will discuss and demonstrate the IOS recovery procedure for fixed configuration Catalyst series switches using xModem.

Real World Application

Recovering the Cisco IOS image on a Cisco switch is one of those tasks that is nice to know and not need it then need it and not know it. In the field you may find yourself faced with a Cisco switch that cannot boot up or crashes when booting up due to a possible IOS Image corruption.

Lab Prerequisites

• This lab will require a REAL switch as this lab cannot be emulated using GNS3.
• The Cisco IOS on the switch must be corrupt or missing to perform this lab, to emulate this error you can erase the flash memory to practice this lab.
• An active console session to the device is REQUIRED.
• You’ll need to use either HyperTerminal or SecureCRT as Putty does not support xModem.

Lab Objectives

• Boot the switch into SWITCH ROM mode.
• Initialize the flash file system.
• OPTIONAL – Format the flash file system if needed. (This will remove your startup configuration)
• Set the baud rate to 115200 to increase xmodem transfer speed and decrease time required to restore the IOS Image.
• Copy the Cisco IOS Image via xModem to Flash:
• Set the boot parameter to the new image name located in Flash:
• Unset the baud so that it defaults back to 9600.
• Boot the switch and verify that the switch boots properly.

Lab Instruction

Recovering the Cisco IOS Image on a fix configuration Cisco Catalyst Series Switch is quite a bit different and more of an “old school” way of doing an IOS image recovery. Unfortunately fixed configuration switches require the use of xModem to restore a corrupt or missing IOS images unlike the Cisco 4500 and Cisco 6500 Series supervisor engines which use compact flash cards

Step 1. Boot your switch into switch ROM mode. This typically involves holding down the STAT button on the front of the switch when plugging in the power. You can check out the required procedure by clicking HERE!

Once you’ve booted your switch into Switch ROM mode you’ll be see the following dispatch;

Step 2. Once you’ve booted into Switch ROM mode you’ll need to initialize the flash file system by executing the flash_init command as shown below;

Step 3 – OPTIONAL – If your image is corrupted you can format your flash file system by executing the format flash: command as shown below however this will delete your start-up configuration!!!

Step 4. To speed up the xModem file transfer speed you’ll need to set the console line BAUD rate to 115200 by executing the set BAUD 115200. If you do this you’ll need to disconnect your console session and change the serial line speed from 9600 to 115200. However if you do not set the BAUD to 115200 your file transfer can take up to 3 hours.

Step 5. Once setting the BAUD rate and reconnecting to the console line of your Cisco switch you’re ready to copy the IOS image via xModem to the switch’s flash memory by executing the copy xmodem: flash:filename.bin and starting the xModem file transfer from the terminal emulator client as shown below;

Step 6. Once the IOS image is copied into flash you’ll need to update the BOOT parameter by executing the set BOOT flash:filename.bin command as shown below;

Step 7. Once the boot parameter has been set you can now set the BAUD rate back to the default 9600bps by executing the command unset BAUD. Note that when doing this you’ll need to disconnect your current console connection and change the baud speed on your terminal emulator from 115200 back to 9600.

Step 8 is the last step which is to boot the switch and verify that the switch successfully boots the IOS image placed into flash from xMODEM. Execute the boot command to load the IOS image specified in the boot parameter as shown below;

Configuring a switch is generally an easy task, but when things go wrong you need to know what to do. Indeed, in this article, we jump-start you to switch troubleshooting on Cisco devices. With this step-by-step guide, you will learn the troubleshooting commands, and how to use them. Moreover, you will learn to find devices in a network, including where they are connected, IP, and MAC address. It is time to start!

This article comes with a Cisco Packet Tracer lab. To benefit the most from what you learn, you should try the lab while reading the article. This way, we will guide you through the switch troubleshooting steps and fixes.

Once you downloaded the file, open it with Packet Tracer, and continue reading.

Switch Troubleshooting Lab Intro

The Topology

This lab leverages the topology from the previous article about VLANs configuration. In fact, the majority of issues you are going to have with switches involve VLANs. However, we made some changes to enhance switch troubleshooting. First, we used a Layer 3 switch as “TopSwitch”. This switch can perform routing and allows inter-VLAN communication (that was not possible previously).

After that, we have hidden all the switches. This way, we cannot simply see where the cable goes. Instead, we must check the configuration on the switches, doing real switch troubleshooting. We will have to jump on the core device (TopSwitchL3) and then telnet into other switches.

The Requirements

Since this article is all about switch troubleshooting, there is no specific configuration requirement. You won’t implement anything new, but instead, you are going to work with issues. Cisco introduces you to troubleshooting with the concept of the ticket, and because of that, we will do the same. The technical term for a ticket is, in reality, incident: here’s the definition.

An incident (ticket) is an issue in the infrastructure causing it to behave unexpectedly.

It can be a hardware fault, someone plugging a PC in the wrong port, or anything else you need to fix. Tickets are raised by users complaining that something does no work, then you need to identify the problem and solve it. For this article, you have three tickets to solve:

1. Users in the Sales office are complaining they cannot print
2. A guy from the Engineering department complains he has no network access
3. A Junior IT Support technician reported strange alerts on RightSwitch when connected via console

Device credentials

To access the peripheral switches (LeftSwitch, CenterSwitch, and RightSwitch) contained in the cloud, refer to the following table.

List of steps

Since this is a troubleshooting article, we cannot define a specific steps list that will work 100% of the time. However, the following list is the one that will get you to the problem faster. Moreover, we arranged it to be optimized for switch troubleshooting.

1. Define the problem
2. Find device(s) having issues
3. Check VLANs configuration
4. Verify trunk ports configuration
5. Check access ports configuration
6. Troubleshoot client issues

The first step is going to be “Define the problem” every time. However, based on what the problem really is, later steps may be followed in a different order. We are going to follow these steps for both tickets, but before we do it we should talk about troubleshooting approaches.

Troubleshooting approaches and Tips

Some people thing troubleshooting is like an art. Instead, troubleshooting is a simple task that can be written in the form of a procedure. Troubleshooting can be stressful, and you might end up performing the same checks again and again. This is frustrating, as you convince yourself that there is no reason for the problem, and it shouldn’t be happening. Nonetheless, it is happening. You need to have a plan. We can talk a lot about troubleshooting approaches, but for now, we will give you just a few tips.

• First, state the problem clearly, talking with the user if necessary.
• Use the divide-and-conquer approach. This means you start by pinging between the two devices that cannot communicate. If the ping is successful, check for application problems at upper OSI layers. Instead, if the ping fails, do a traceroute to find where in the network the problem is. Then, check the data-link layer and physical connections. This approach is opposed to the bottom-up approach (starting from the cabling) and the top-down approach (starting from the application). With this approach, you start in the middle of the OSI layer.
• Write down everything you do, so you won’t be repeating steps. This is useful for complex issues or infrastructures.
• If you still cannot resolve the issue, don’t panic. Google is your friend, check for users having similar issues.

These concepts are fundamentals. They will help you a lot in switch troubleshooting. We are going to see how right below when working on the tickets.

Ticket #1

Define the problem

The first ticket we are going to face is for the PCs in the Sales department that cannot print. This definition is way far from a punctual problem statement. After calling users, we clarify that they cannot access printers, servers, and file share on the network. Based on that, we know that it is unlikely to be a print problem. Both users have the same problem, but the two PCs can communicate with one another.

It’s time for you to gather technical details. You ask the users to open the command prompt (from the Start or with Win+R, then cmd for Windows users) and type ipconfig /all. We need to gather four items: IP address, default gateway, subnet mask, and Physical address (mac address). The two devices having problems are Laptop0 and Laptop1, so here is an example of Laptop 0 output.

Show Time Cisco Switch

After talking with the user, here is what we have learnt.

• User 1 is using a laptop with IP 10.100.2.10 and subnet mask of 255.255.255.0. Its default gateway is 10.100.20.1 and the MAC address is 00-D0-FF-66-C6-A1.
• User 2 is also using a laptop, with IP 10.100.2.11 and subnet mask of 255.255.255.0. Its default gateway is still 10.100.20.1 and the MAC address is 00-E0-8F-E1-5D-8B.

From that, we know that IP configuration on the two laptops is correct. This is likely to be a network issue, and we need to find where in the network the issue is.

Gathering more information

When we face this kind of problem, we need to find out where the isolation is. In other words, we know that these two PCs are somehow isolated, but we need to know if they can reach at least their gateway, or if there is a problem with L2 segmentation. So, we jump on the TopSwitchL3, which is the default gateway, and we try to ping these two IP addresses. Both pings will fail.

Verify ARP cache

Since pings are failing, and we are in the same subnet, we need to verify if the data-link layer is working as expected. To verify the data-link layer, we start by issuing show ip arp just after those pings. With this command, we are checking if our switch was able to resolve the IP addresses to MAC addresses.

The command show ip arp presents you with the content of the ARP table. In other words, you can find all the bindings between IP addresses and MAC addresses the switch know. It may contain hundreds or even thousands of entries in a real-world switch performing routing. This command presents you several columns, here’s their meaning.

• Protocol – Internet stands for IP, identifies the protocol that triggered the ARP request/response process
• Address – IP address
• Age – Time in minutes since the entry is in the table
• Hardware Addr – MAC address associated with the IP address in the same row
• Type – ARP encapsulation type, generally “ARPA”, way out of scope for this article
• Interface – On which interface the switch learned the MAC address

Cisco Router Command List

Entries that have no age (but a dash instead) are the ones associated switch’s IP addresses. Moreover, note that this table is populated only from ARP requests the switch made. As a result, ARP requests made from other devices, and passing through the switch will be ignored.

Checking the previous output, we didn’t find any MAC address but the ones of the local switch. This means that ARP requests have been failing, so we have a problem at the data-link layer or even below.

Verify MAC address table

The MAC address table on a switch remembers the association between a MAC address and a physical port of the switch. The switch will populate that table and keep it up-to-date every time it receives an ethernet frame. In other words, to see the MAC address of these laptops on the Top switch, laptops must generate traffic and that traffic must reach the Top switch. Even ARP responses are traffic, but we don’t know if our requests made it to the client. In case they didn’t, the device won’t have generated any traffic. Just to be sure, jump on Laptop0 and ping the default gateway, 10.100.2.1.

Even if ping fails, our PC has generated some traffic, so we can check the ARP table on the Top switch to see if they made it. We do it by typing show mac address-table from the privileged exec prompt.

We are looking for the MAC address of the Laptop0, which is 00d0.ff66.c6a1 (in Cisco notation). Nevertheless, we cannot find this MAC address here. Now we are sure that communication with the device doing routing is broken. We need to find if we can reach the peripheral switch, at least. Since we don’t know where in the network Laptop0 is, we need to check all the switches. Our objective is to find a switch having that MAC address in the MAC address table.

Checking MAC address table on peripheral switches

To continue with our switch troubleshooting, we are going to connect to LeftSwitch. To do it, remain on TopSwitchL3 in privileged exec, then type telnet 10.80.0.2 and enter the password as required. Then, once again, issue show mac address-table and check the results.

Here we are! We found our device, it is connected to the FastEthernet 0/10 port on LeftSwitch. At this point, we know that the connection between Laptop0 and LeftSwitch is working fine, but there might be some problems between LeftSwitch and top switch. Before we check that, try to discover where Laptop1 is connected on your own. Just for the sake of learning, here’s the explanation of show mac address-table output.

• Vlan – the VLAN associated with the MAC address, this comes from the VLAN associated with the port
• Mac Address – the MAC address itself
• Type – How the MAC address was learned, dynamic means from an ethernet frame, static means it was hardcoded
• Port – Physical port this MAC address was seen on

Tip: if you don’t see the MAC address even there, it means the MAC address table aged out. Try again the ping from the Laptop and, as soon as it finishes, immediately check the MAC address table.

Checking trunks

This problem involves two devices on the same VLAN, so it could be potentially a problem of that VLAN. We issue show vlan brief to check if the VLAN exists, and we find that VLAN 102 is the one for Laptops. Consequently, we need to check if this VLAN goes on the trunk toward TopSwitchL3. We do that with show interfaces trunk.

This must be the problem. Therefore, all we need to do is enter in configuration mode, go under the interface GigabitEthernet 0/1 and add the missing VLANs. Below, the needed commands.

Once you typed that, try to ping the default gateway from both Laptop1 and Laptop2. This problem prevented all the traffic from devices on LeftSwitch to reach the TopSwitch, the routing core. As a result, all devices inside VLAN 102 on LeftSwitches, was isolated from everything else. Review this configuration, and when you feel confident with what we did move to the next ticket.

Break Command For Cisco Switch

Ticket #2

Define the problem

Cisco Commands List

The second ticket in our Switch Troubleshooting is the one from the Engineering guy, the one complaining to have no network access. This time, we know the problem is on Laptop2, and only on that device. All laptops are working fine, and other devices connected to the same switch are working fine too. Therefore, we know that this problem is very limited, and can be associated with either PC settings or access port settings.

Gathering additional information

Again, we need to know the whereabouts of the PC. So, log into Laptop2 and, from the prompt, type ipconfig /all. You will find that this PC has the IP address 10.100.2.12 associated with a /24 subnet mask, the default gateway is the 10.100.2.1 and the MAC address is 0002.154c.552c. Since we know the problem is likely to be on the device, it’s time to find it.

Finding the device in the network

This time we will go much faster. First thing, from the command prompt of Laptop2, issue a ping toward 10.100.2.1 to generate traffic. After that, immediately check the MAC address table of TopSwitchL3 with show mac address-table command. We are looking for 0002.154c.552c. Apparently, we found it.

At first glance, the laptop might seem connected to FastEthernet 0/2 on TopSwitchL3. The problem is clear from there, the laptop is in VLAN 301 (servers) instead of VLAN 102 (laptops). However, we are doing switch troubleshooting, so we must look closely. Thus, we see than this port is associated with multiple MAC addresses in different VLANs. We should check whether it is a trunk using our friend show interfaces trunk.

To help you, FastEthernet 0/2 is the interface connecting CenterSwitch. Since we saw the MAC address of the laptop coming from that interface, the laptop must be connected to that switch. We can reach it with telnet 10.80.0.3 and check its MAC address table.

Interface FastEthernet 0/10 is an access port in VLAN 301. To put it in VLAN 102, as it should be, use the following commands.

Done. The problem is fixed, and pinging again can prove it.

Ticket #3

Define the problem

For the third ticket of our switch troubleshooting, a Junior technician told us about strange messages on RightSwitch. So, we know where the problem is and we just need to check those messages. Log into RightSwitch using telnet 10.80.0.4 to check those messages. However, since messages normally appear in console only, and we don’t have console access, we need to find an alternative way.

To see the log messages in VTY lines, type terminal monitor, and to disable that use terminal no monitor. If you wait for about 30 seconds with the terminal monitor on, you will see a CDP error message as in the picture.

Fixing Native VLAN Mismatch

Let’s analyze the syntax. Here’s the whole message.

This message is extremely clear, but analyzing all its sections will make that even clearer.

• %CDP – Cisco Discovery Protocol is the protocol that noticed the error
• 4 – Severity, indicates how severe this error is, where 0 is the most severe, and 7 is debugging. 4 means warning.
• NATIVE_VLAN_MISMATCH – The code of the error
• Native VLAN mismatch discovered – Brief description of the error, it indicates that the native VLAN on one side of a trunk is different from the one set by the other switch
• on GigabitEthernet0/1 – the interface of the local switch
• (1) – Native VLAN of the local switch
• with TopSwitchL3 – the hostname of the remote switch
• FastEthernet0/3 – the interface of the remote switch
• (99) – Native VLAN of the remote switch

Cisco Break Command Putty

What this message is trying to say is that the native VLAN on this switch differs from the one on the other side of the trunk. Specifically, TopSwitchL3 is using VLAN 99 – correct – while RightSwitch is using VLAN 1 – wrong. To fix this, simply add the commands below.

Cisco Switch Break Command

Then wait for about a minute, you won’t see any more message like that.

Conclusion

Congratulations! We finished our switch troubleshooting successfully, now everything works as expected. Just to recap, we learned two powerful commands: show ip arp and show mac address-table. These two commands help you to locate devices in the network and perform basic troubleshooting. With experience increasing, you will become faster and faster in switch troubleshooting tasks.

Basic Cisco Switch Commands

Continue to follow our Free CCNA course to learn everything else you need to work in networking and get your certification fast and easy.