Config Lab: Switch Admin Config

Wendell Odom
By Wendell Odom August 31, 2021 17:05

Today’s topic: All lot of administrative settings on a switch, particularly access passwords, that you need to set up when you first install a switch.  Enjoy!

All about Config Labs

The blog has a series of lab exercises called “Config Labs.” Each lab presents a topology with the relevant initial configuration for each device. The lab also lists new requirements, after which you should create the additional configuration to meet those requirements. You can do the lab on paper, in a text editor, or use software tools like Cisco Packet Tracer or Cisco Modeling Labs.

Once you have created your answer, you can click various tabs at the bottom of this post to see the lab answers, comments about the lab, and other helpful information.

The Lab Exercise

Lab Requirements

This lab uses two LAN switches, connected by a link, with a router on the side.


Figure 1 – Lab Topology


For this lab, you need to configure passwords, plus a few other administrative settings. Note that this lab does not ask you to configure IP addressing, leaving that to other labs. However, this lab does ask you to configure the rest of the settings to prepare to allow for inbound Telnet and SSH into the switches.

The requirements are as follows.

  1. On both switches, protect the console using the password “fred”.
  2. On switch SW1, allow telnet but not SSH into the switch, with simple password protection without using a username. Use password “sw1”.
  3. On switch SW2, allow both telnet and SSH into the switch, with both a username and password. You can choose the actual username and password.
  4. On both SW1 and SW2, do not yet configure IP details; defer that work until the router folks tell you what IP addresses to use.
  5. Give each switch a hostname to match the figure.
  6. For each interface used in the lab, document the device’s name on the other end of the link connected to the interface. For instance, for SW1, port G1/0/1, document that “PC1” is on the other end of the link.
  7. On switch SW1, protect privileged mode using the older style (and easier to break) password. Make this password “sw1bad”.
  8. On switch SW2, protect privileged mode using the newer style (and more secure) password that uses MD5 encoding. Make this password “sw2good”.


Initial Configuration

This lab begins with a pretty clean slate. Here are the notes for the initial state:

  • The router has been configured already and is working.
  • The router is connected to other links, not shown; those links are completely unimportant to the lab.
  • The two LAN switches have no configuration; just before this lab, their config was erased, and the switches were reloaded.
  • This lab avoids VLAN and VLAN trunk topics to keep the focus on passwords and Telnet/SSH. So, the link between the two switches is not a VLAN trunk, and only the default VLAN (VLAN 1) is in use.

Answer Options - Click Tabs to Reveal

You can learn a lot and strengthen real learning of the topics by creating the configuration – even without a router or switch CLI. In fact, these labs were originally built to be used solely as a paper exercise!

To answer, just think about the lab. Refer to your primary learning material for CCNA, your notes, and create the configuration on paper or in a text editor. Then check your answer versus the answer post, which is linked at the bottom of the lab, just above the comments section.

You can also implement the lab using the Cisco Packet Tracer network simulator. With this option, you use Cisco’s free Packet Tracer simulator. You open a file that begins with the initial configuration already loaded. Then you implement your configuration and test to determine if it met the requirements of the lab.

(Use this link for more information about Cisco Packet Tracer.)

Use this workflow to do the labs in Cisco Packet Tracer:

  1. Download the .pkt file linked below.
  2. Open the .pkt file, creating a working lab with the same topology and interfaces as the lab exercise.
  3. Add your planned configuration to the lab.
  4. Test the configuration using some of the suggestions below.

Download this lab’s Packet Tracer File

You can also implement the lab using Cisco Modeling Labs – Personal (CML-P). CML-P (or simply CML) replaced Cisco Virtual Internet Routing Lab (VIRL) software in 2020, in effect serving as VIRL Version 2.

If you prefer to use CML, use a similar workflow as you would use if using Cisco Packet Tracer, as follows:

  1. Download the CML file (filetype .yaml) linked below.
  2. Import the lab’s CML file into CML and then start the lab.
  3. Compare the lab topology and interface IDs to this lab, as they may differ (more detail below).
  4. Add your planned configuration to the lab.
  5. Test the configuration using some of the suggestions below.

Download this lab’s CML file!


Network Device Info:

This table lists the interfaces listed in the lab exercise documentation versus those used in the sample CML file.

Device Lab Port  CML Port
SW1 G1/0/1 G2/1
SW1 G1/0/2 G2/2
SW1 G1/0/3 G2/3
SW1 G1/0/11 G1/1
SW2 G1/0/4 G3/1
SW2 G1/0/5 G3/2
SW2 G1/0/6 G3/3
SW2 G1/0/7 G0/1
SW2 G1/0/12 G1/2

Lab Answers Below: Spoiler Alert

Lab Answers: Configuration (Click Tab to Reveal)

Answers: Switch Admin Config

The answers require that you exercise your memory more than performing detailed analysis. Examples 1 and 2 list the answers. The examples list the commands in the same order that IOS would list them in the output of a show running-config command, rather than in the same order as the requirements listed in the original post. To help you navigate the configuration, the examples include comments that reference the requirement number. Figure 1 repeats the figure for reference.


Figure 1 – Lab Topology


Example 1: SW1 Config


Example 2: SW2 Config

Commentary, Issues, and Verification Tips (Click Tabs to Reveal)

Most of the parameters for the commands in this lab require no analysis – you just need to remember them all. The trickiest part may be remembering all the pieces of the SSH configuration on SW2.

The lab requirements list the need for SSH on SW2 as requirement #3. Let me make a couple of comments about that particular requirement, as follows:

  • The requirements did not spell out the username/password pair to use, so any pair you made up is legal. I used fred/barney.
  • The requirements did not spell out what domain name to configure; any name you used is fine. I used
  • The default setting on the transport input command in switches (transport input all) works, but I added the transport input all command as a reminder to think about it.

Known Issues in this Lab

This section of each Config Lab Answers post hopes to help with those issues by listing any known issues with Packet Tracer related to this lab. In this case, the issues are:


# Summary Detail
1 show interfaces status incorrect This command, in real switches, lists the contents of the description interface subcommand under the heading “name”. PT lists blanks, ignoring the description setting.
1 show interfaces description not supported This command, in real devices, lists interfaces and the contents of the description interface subcommand. PT does not support the command.


Why Would Cisco Packet Tracer Have Issues?

(Note: The below text is the same in every Config Lab.)

Cisco Packet Tracer (CPT) simulates Cisco routers and switches. However, CPT does not run the same software that runs in real Cisco routers and switches. Instead, developers wrote CPT to predict the output a real router or switch would display given the same topology and configuration – but without performing all the same tasks, an actual device has to do. On a positive note, CPT requires far less CPU and RAM than a lab full of devices so that you can run CPT on your computer as an app. In addition, simulators like CPT help you learn about the Cisco router/switch user interface – the Command Line Interface (CLI) – without having to own real devices.

CPT can have issues compared to real devices because CPT does not run the same software as Cisco devices. CPT does not support all commands or parameters of a command. CPT may supply output from a command that differs in some ways from what an actual device would give. Those differences can be a problem for anyone learning networking technology because you may not have experience with that technology on real gear – so you may not notice the differences. So this section lists differences and issues that we have seen when using CPT to do this lab.

Beyond comparing your answers to this lab’s Answers post, you can test in Cisco Packet Tracer (CPT) or Cisco Modeling Labs (CML). In fact, you can and should explore the lab once configured. For this lab, once you have completed the configuration, try these verification steps. 

  1. You can test the console and enable passwords on switch SW1 from the console, as follows:
    1. Connect to the console of your SW1. (If already connected, connect and reconnect. Note that the exit command logs you out of the console.)
    2. Press enter to (hopefully) cause a password prompt to appear.
    3. Type the console password you just configured to test. You should reach user mode.
    4. From user mode, issue the enable command; a password prompt should appear.
    5. Type the enable password and press enter to test whether you configured the enable password correctly.
  2. Use the same steps to test the console and enable passwords for switch SW2.
  3. Because this lab did not have configured IP addresses, you cannot test Telnet and SSH into the switches with only the requested configuration. However, use these steps to add enough IP configuration to test from switch SW1, which should be configured to support Telnet but not SSH.
    1. From switch SW1, enter configuration mode, and add these two commands: interface loopback 1 and ip address
    2. Exit configuration mode.
    3. Test Telnet into that same switch with the telnet command. If it works, you will see a password prompt, at which you should type the Telnet (vty) password you configured for this lab.
  4. For switch SW2, test Telnet and SSH with these similar steps:
    1. Configure a loopback 1 interface but with address
    2. Test Telnet from the SW2 console with the telnet command.
    3. To test SSH, use the ssh -l username command, where username is the username you configured in this lab. You should see a password prompt, at which you should type the password you added to the username command.

More Labs with Related Content!

Config Lab: Switch Duplex and Speed
Config Lab: Switch IP Config
Wendell Odom
By Wendell Odom August 31, 2021 17:05
Write a comment


  1. Nicholas C December 7, 18:09

    One packet tracer issue I’ve noticed is that if you use the sub command “description” in interface configuration mode, that description does not then show up if you do a “show interfaces status” command. Additionally, the command “show interfaces description” does not seem to be available in the Packet Tracer software.

    Unless I’m missing something (which is perfectly possible) , these seem to be packet tracer bugs that us students might want to be aware of.

    Thanks for these amazing resources!
    Nick C

    Reply to this comment
    • certskills December 8, 14:18

      Hey Nick,
      Woohoo! Got an amazing! Seriously, they’re working well for you.
      I agree with your comments – always good to get a hint about PT oddities. I just updated the post. Thanks for the suggestion.

      Reply to this comment
      • Ben Tauler (@bentauler) January 9, 09:53

        I’ve also observed that in Packet Tracer this command does not work:

        show running-config interface f0/2

        Seems like “show” command won’t accept any filtering option, it only works when you ask for the full configuration output.

        Reply to this comment
  2. Clear Daylight January 17, 10:32

    Loving these resources. Thank you! I’ve taken to writing out the commands I anticipate needing, checking them against your examples, and then updating my initial command text with anything I missed.

    In this lab, there appear to be a couple typos, though neither of them take away from the lab’s effectiveness:
    1. In the visual representation of the initial setup, G1/0/3 is written “G10/3”.
    2. The switch interfaces are referred to as FastEthernet in the Lab Answers section, whereas in the lab and PacketTracer file, they are GigabitEthernet.

    Thank you again for such a wealth of knowledge!

    Reply to this comment
  3. Rambo September 5, 11:43

    Hello all,

    Thank you for the lab.

    Even, though I knew in order to configure ssh I need to configure the Domain name. Since there was no instruction in the lab tasks I skipped it.


    Reply to this comment
  4. Vicente Torres October 27, 14:24

    In CPT version the show interaces status command shows the description under the “name” column. Perhaps they have already corrected?

    Reply to this comment
    • certskills October 31, 10:56

      Hi Vicente,
      Thanks for letting me know. I wouldn’t be surprised if it had been changed. It’s a lot to keep up with – but notes like this help. Thanks,

      Reply to this comment
  5. Sandro Fasolato November 21, 13:02

    Hi Wendell,
    luckily I have the option to use a 3560 gear and I can compare it to PT: I noticed that the “transport input all/telnet/ssh” does not show in PT version when using the “show run” command. It’s just another notice for PT users. Thank you for your book and for the website, I’m learning a lot and I’m applying your teachings in the field as well, best combination possible.

    Reply to this comment
    • Wendell Odom November 30, 17:41

      Glad you’re enjoying the process! When we added the Config Labs here to match the book, I was hopeful they would help.
      Also, on this one, on real gear, try “show line vty 0” and you should see the setting for “transport input”. PT doesn’t support it, though.

      Reply to this comment
  6. Harold Garcia January 18, 18:08

    why do I have to do an ip domain-name in order to set the RSA encryption?

    Reply to this comment
    • Wendell Odom January 20, 06:59

      The crypto key command uses the fully-qualified domain name of the device as input to the process. To build that, it uses the device hostname and its domain name, hence the requirement for the ip domain-name command.

      Reply to this comment
  7. AJ January 23, 21:42

    Since there was no domain name given and Step 4 saying Router team would give IP addresses, I figured they would supply a domain name too so I did not do:
    ip domain-name
    crypto key generate rsa

    Reply to this comment
View comments

Write a comment

Comment; Identify w/ Social Media or Email


Subscribe to our mailing list and get interesting stuff and updates to your email inbox.

Thank you for subscribing.

Something went wrong.