Config Lab: Switch Admin Config

 In 200-301 V1 Ch07: Switch Interfaces, 200-301 V1 Part 2: Ethernet, 200-301 V1 Parts, Config Lab, Config Lab CCNA Vol 1 Part 2, Hands-on

Today’s topic: A 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


! Requirement #5 next
hostname SW1

! Requirement #7 below
enable password sw1bad

! Requirement #6 next

interface GigabitEthernet1/0/1
 description connected to PC1
interface GigabitEthernet1/0/2
 description connected to PC2
interface GigabitEthernet1/0/3
 description connected to PC3
interface GigabitEthernet1/0/11
 description connected to SW2

! Requirement #1 below
line con 0
 password fred

! Requirement #2 below
line vty 0 15
 password sw1
 transport input telnet

Example 1: SW1 Config


! Requirement #5 next
hostname SW2

! Part of Requirement #3 next; more at the bottom
ip domain-name
crypto key generate rsa
username fred password barney

! Requirement #8 below
enable secret sw2good

! Requirement #6 next

interface GigabitEthernet1/0/4
 description connected to PC4
interface GigabitEthernet1/0/5
 description connected to PC5
interface GigabitEthernet1/0/6
 description connected to PC6
interface GigabitEthernet1/0/12
 description connected to SW1
interface GigabitEthernet1/0/7
 description connected to R1

! Requirement #1 below
line con 0
 password fred

! Requirement 3 below; more at the top
line vty 0 15
 login local
 transport input telnet ssh

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.
2 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.
3 transport input telnet ssh not supported This command, in real devices, enables support for both Telnet and SSH in vty line mode. PT does not support the command. Use the transport input all command instead.


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
Notify of

Newest Most Voted
Inline Feedbacks
View all comments
Nicholas C

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


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.

Ben Tauler (@bentauler)

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.


Hey Ben,
I agree – PT supports only a limited number of pipe options for EXEC commands.

Clear Daylight

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!


Hello… Clear?
And thanks for the heads up. I fixed those minor mistakes. Much appreciated.


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.


Vicente Torres

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


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,

Sandro Fasolato

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.

Harold Garcia

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


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


Mr. Wendel Odom,

I hope this email finds you well. I seek your assistance with an issue that I am facing in my networking lab.

I have been working on configuring Switch SW1 in my lab, and I am facing an issue where I am unable to Telnet into the switch after configuring the Loopback interface. Specifically, I entered the following two commands in configuration mode:

interface loopback 1
ip address

However, even after configuring the loopback interface, I am still unable to Telnet into the switch using the command “telnet”. I have verified that the switch has an active Telnet session by using the “sh ip int br” command, but I am still unable to connect to it.

I could not verify that the switch loopback IP address is reachable from the network I am trying to telnet from for I could not ping the loopback Ip from a device in that network and upon using the”show ip route” command, I noticed that the default gateway is not set.

I would greatly appreciate your help in resolving this issue. Please let me know if there are any additional details or information that I can provide to assist you with troubleshooting.

Thank you for your time and assistance.

Best regards,”


“Hello Mr Wendell.

My goal was to be able to Telnet to the switch so I didn’t use the loopback
I did the latter just like you recommended in global configuration mode:

interface vlan 1

ip address (I used an IP address/mask in the

subnet used in VLAN 1 in My lab)

no shutdown (I added this command and that made it work)

The shutdown command changed interface Vlan1 state and protocol to up and up.

I suspected the interface VLAN status and protocol were down and actually that was the case because upon verifying using I could see that VLAN 1 was assigned and IP address but the interface status and protocol Showed down and down, that is were I knew it is because I did not change the interface status using the no shutdown command.

I was able to telnet into the switch immediately from anywhere in that network, and the same worked for ssh using the command ss -l username

I just wanted to take a moment to thank you for your assistance.. Your guidance and support helped me to overcome a the issue I was having with configuring remote management on a switch. I really appreciate the time and effort you put into helping me, and I feel more confident in my networking skills as a result.

Thank you again for all your help and support.

Ermundo Russell aka Old Guy

Hey Wendell,

My SW1 config shows the login command under the password fred config. But on the lab answers config it shows login on top of password fred config. Where did I go wrong?
My Config
line con 0
password fred

Lab answers
line con 0
password fred


Good lab for starters. for the transport input on SW2, packet tracer does not let you add telnet shh in one line so I did transport input all.

Would love your thoughts, please comment.x