Config Lab: Switch Duplex and Speed

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

For this next lab, instead of just asking you what the IEEE auto-negotiation rules look like, the lab asks you to configure some switches in ways that affect auto-negotiation. But the lab gives you the end goal: the resulting speed and duplex. The logic is not complex, but if you have only read the basics in a table, and never applied it yourself, these basics are easy to miss. This exercise gives you a chance to apply the ideas.

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

This lab begins by giving you some details about the lab environment and then giving you two sets of requirements. First, here are some of the details about the lab environment, detailed in Figure 1:

  • 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.
  • This lab avoids VLAN and VLAN trunking topics to keep the focus on duplex and speed. To that end, the link between the two switches is an access link (that is, it is not a VLAN trunk), and only the default VLAN (VLAN 1) is in use.

 

Figure 1 – Lab Topology

This lab begins with the router configured correctly, but the lab ignores the router configuration for the most part. The two switches start with the configurations as shown. These initial configurations have no real impact on configuring the switches for the upcoming new requirements.

hostname SW1

interface FastEthernet0/1
 description connected to PC1

interface FastEthernet0/2
 description connected to PC2

interface FastEthernet0/3
 description connected to PC3

interface FastEthernet0/11
 description connected to SW2

ip default-gateway 192.168.1.30

interface vlan 1
 ip address 192.168.1.29 255.255.255.224
 no shutdown

Example 1: SW1 Initial Config

hostname SW2

interface FastEthernet0/4
 description connected to PC4

interface FastEthernet0/5
 description connected to PC5

interface FastEthernet0/6
 description connected to PC6

interface FastEthernet0/12
 description connected to SW1

interface FastEthernet0/7
 description connected to R1

ip default-gateway 192.168.1.30 

interface vlan 1
 ip address 192.168.1.28 255.255.255.224
 no shutdown

Example 2: SW2 Initial Config

 

Problem 1: Configure to Match Desired Auto-Negotiation Results

This exercise does not match what you might do in real life, but it does allow you to exercise the different command options. For this lab, configure the switch ports so that the switch achieves the IEEE auto-negotiation results shown in an upcoming table. That’s it! There are a few key assumptions and rules to keep in mind, though:

  1. The PC NICs use IEEE auto-negotiation.
  2. The PC NICs have default settings, which means the PC NICs will attempt to negotiate speed and duplex.
  3. All PC NICs can sense the speed ONLY through IEEE auto-negotiation (in real life, some can just look at the physical layer encoding and detect the speed).
  4. All interfaces have the correct cabling already installed.
  5. All switch ports are 10/100 ports.
  6. Show all possible configurations that result in the final state listed in the table.

Switch

Interface

Speed

Duplex

SW1

F0/1

100

Half

SW1

F0/2

10

Half

SW2

F0/4

10

Full

SW2

F0/5

100

Full

Table 1: Resulting Speed and Duplex; Configure to Cause These Settings

 

Problem 2: Configure and Predict Results

For this last part of today’s exercise, for two ports, configure based on the written rules listed here. Then predict the speed and duplex that should result on that link, on each end of the link. (Note that with IEEE auto-negotiation, the two ends may not end up agreeing on the duplex setting; the result is bad.)

  1. On SW1 F0/3, configure the switch to automatically detect duplex but force the speed to 100 Mbps.
  2. On SW2 F0/6, configure the switch to automatically detect speed but force the duplex to half.

That’s it! Configure away!

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 F0/1 G2/1
SW1 F0/2 G2/2
SW1 F0/3 G2/3
SW1 F0/11 G1/1
SW2 F0/4 G3/1
SW2 F0/5 G3/2
SW2 F0/6 G3/3
SW2 F0/7 G0/1
SW2 F0/12 G1/2

 

Issues with This Lab in CML:

The lab exercise uses FastEthernet ports, but the switches in CML do not support FastEthernet. As a result, when doing this lab in CML to meet the requirements as listed, you will need slightly different configuration than the answer configuration shown with this lab.

Lab Answers Below: Spoiler Alert

Lab Answers: Configuration (Click Tab to Reveal)

Quick Review of Auto-Negotiation on Cisco Switches, and Lab Rules

This lab exercise revolves around both configuring the switches and relying on the switch to use auto-negotiation. Cisco switch ports (like 10/100 and 10/100/1000 UTP ports) that support multiple speeds can be configured for speed, duplex, and both. However, when both are configured, the switch port also disables IEEE auto-negotiation. Also, the lab exercise asked you to assume that the PC NIC would not sense the speed correctly if auto-negotiation were disabled on the switch.

When both ends use auto-negotiation, they use the best speed that both support, and the best duplex (full is better than half). When the opposite end does not perform auto-negotiation, if using auto-negotiation rules, the local end chooses to use the slowest speed and the worst duplex (10/half in this case). (However, note that switches and device NICs typically do sense the speed, independent of the IEEE auto-negotiation process, through some electrical sensing on the link.)

And as usual, as a reminder, here’s the LAN topology:

Figure 1 – Lab Topology

 

Switch Configurations – Problem 1

The configurations for Problem 1 are listed below. The answers show one way to configure for each of the four requirements in the original lab, Problem 1. However, the original lab asked for all. Which ways did you configure as an alternative to these? Post the answers here, and I can review if you’re unsure.

interface FastEthernet0/1
 duplex half
 ! allow auto-n for the speed; this leaves auto-n on

interface FastEthernet0/2
 duplex half
 speed 10
 ! disables auto-n, causing the PC NIC to use the worst speed/duplex of 10/half

Example 1: SW1 New Config, Problem 1

 

interface FastEthernet 0/4
 speed 10
! allow auto-n for the duplex; this leaves auto-n on

interface FastEthernet 0/5
! Rely on Auto-n to choose best (100/full)

Example 2: SW2 New Config, Problem 1

 

Switch Configurations – Problem 2

Problem 2 required very little configuration – the problem statement essentially tells you the configuration in English wording. The real question is to predict the speed settings on both ends, and in particular, to pay attention to any possible duplex mismatches.

Examples 3 and 4 show the configuration added in each case.  In these two cases, note that the switch ports do not have both the speed and duplex configured, so the switch still uses auto-n. As a result, no matter the duplex settings, the PC NIC and the switch port will be able to agree to which duplex to use.

  • For SW1’s Fa0/3: Both ends use 100 Mbps, Full
  • For SW2’s Fa0/6: Both ends use 100 Mbps, Half

 

interface FastEthernet0/3
 speed 100

Example 3: SW1 New Config, Problem 2

 

interface FastEthernet 0/6
 duplex half

Example 4: SW2 New Config, Problem 2

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

For this lab, the lab commentary is within the Lab Configuration tab area just above.

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 PT does not accept the transport input telnet ssh command The initial configuration shows the transport input telnet ssh command on a device. PT does not support the command. Instead, use the transport input all command (which is included in the supplied .pkt file.)
2 PT displays incorrect information about speed/duplex in the show interfaces status command. The command’s output on real gear, under the “Duplex” and “Speed” columns, uses an “a-” prefix if the setting was derived through auto-negotiation. PT lists the “a-” prefix whether speed or duplex was found with auto-negotiation or configured directly.
3 PT PCs do not display speed/duplex settings. The PCs in the Packet Tracer application do not show what speed or duplex is used on a link.

 

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. For Packet Tracer users:
    1. Use the show interfaces status command to discover the speed and duplex, but ignore the indications about whether the information was learned by auto-negotiation or not. See the “Known PT Issues” tab for more about the false duplex/speed information implied by the show interfaces status command.
    2. Use the show interfaces f0/1 and similar commands to find the speed and duplex of the switch port. Be aware that this command does not imply whether the setting was configured or auto-negotiated.
    3. For the PC settings, open a PC’s configuration tab, and navigate to the line for the NIC. It should indicate whether the PC is attempting auto-negotiation and the current speed/duplex settings.
  2. For CML users:
    1. Use the show interfaces status and show interfaces f0/1 (and similar) commands, trusting the output.

More Labs with Related Content!

Config Lab: SSH Config
Config Lab: Switch Admin Config
Subscribe
Notify of
guest

19 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Jonathan

Greetings,

I have tried to adjust the speed and the duplex on the interface but I get the following message.

“Autoneg enabled. Duplex cannot be set”

What is the command that turns autoneg off?

certskills

Jonathan,
I think you’re seeing quirks of Packet Tracer. On a real switch, you could use the **duplex** and **speed** commands without that error message appearing. Setting a specific speed and duplex disables IEEE autonegotiation on that switch port. FYI.

jp

I have the same issue with EVE-ng with Cisco IOS images. You have to use the command no negotiate auto in global configuration mode.

certskills

JP (and all),
At issue here is whether the effects you’re seeing are true of real Cisco switches or not. For instance, JP, when using EVE-ng, are you using the IOSL2 image that Cisco supplies in CML? If so, I would contend that image, while very useful for practice, is imperfect for comparisons to real switches sold by Cisco. Cisco built that image originally from the code for a real switch, modified it as necessary to run in the predecessors of CML (back as far as the early 2000’s), and then kept it as a separately developed code base. They keep updating it, thankfully, so we have a switching IOS to use in CML etc. However, it may have commands that just do not match the IOS commands on products sold over those intervening years. Particularly, it might have differences to support features more directly related to hardware and the physical layer, so that the code works in an emulator.

For instance, the command both Jonathan and JP mention, “[no] negotiate auto”, isn’t in the command reference for the Catalyst 9200 or 1000 series (current lower-end enterprise access switches). The command is not available from the CLI of the most recent older model series 2960 XR and similar older switches. But those command guides do mention the traditional conventions that are also detailed in the Cisco docs, as noted in this lab.

I’m happy to learn something new here. If anyone has a specific model series of switch that is a product Cisco sells to consumers, and you can show me some output, or a link to a command guide/reference that supports this command, I’m happy to look further. Honestly, it would not be the first time Cisco added something and then I learned about it from a reader – seriously, happy to hear more. But after looking further again, I still don’t see any evidence for a “[no] negotiate auto” command outside of simulator/emulator environments.

Hope this helps…
Wendell

PS 9200 command reference: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9200/software/release/17-6/command_reference/b_176_9200_cr/176_9200_cr_CLT_chapter.html#N
1000 command reference: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst1000/software/releases/15_2_7_e/command_reference/b_1527e_1000_cr/1527e_1000_cr_CLT_chapter.html#N

jp

Hi Wendell,

I use vIOS and IOL that I got from the internet, it’s not from Cisco CML. I can’t remember. I just tested with the Cisco IOL, and I can set the duplex to half if I want without putting it the no negotiate auto in the interface config. I can’t change the speed because it’s an ethernet port. It seems to only affect the vIOS

Wendell, for the exam, do you suggest just ignoring the no negotiation auto? By the way, in EVE-NG, the vIOS switch I use is more of a layer 3 switch…

certskills

JP
OK, so we weren’t on the same page entirely. I was thinking switches, and you were testing vIOS, which is a router operating system. So, on LAN switches, what’s in the book, and the “[no] negotiate auto” command not being a command, is what is correct.
As for IOS, or vIOS… you can get legitimate vIOS by purchasing a license to CML. I don’t have a working copy handy, so when I get caught up after my absence, I’ll try and take a look. Just so I understand the context: Are you trying to set the speed and duplex on routed ports in vIOS, aka normal router interfaces? Or on interfaces that are part of an Ethernet switch network module? Just wanting to make sure I know where you’re coming from.
Wendell

jp

Wendell,

I wasn’t specific enough, and I’m sorry for that. I do use what is called Cisco vIOS switch in EVE-NG; it’s a layer3 type of switching I think. The exact image name is viosl2-adventerprisek9-m.03.2017

As for your other question about routed ports, I am not sure…I issued the command no ip routing in global configuration mode because I couldn’t set the ip default-gateway command in the previous chapter.

I am pretty sure it’s ethernet switching emulated modules; it’s one of twelves gig interfaces.

I cannot say I am legitimate here. I do not use CML license. I got this image from the internet.

jp

I am pretty sure that it works for Cisco IOL but I cannot test the speed. If I issue the command duplex half on an interface, it works. If I try the same on the vIOS, it replies with the error message (Autoneg enabled). However, I cannot test the speed command with that IOL switch because the ports speed are ethernet. I am pretty sure it would work.

In short, it doesn’t work on Cisco vIOS but works on IOL.

Albert

exercise 1

sw 1
interface f0/1
duplex half
speed auto (or 100)

int f0/2
duplex half
speed 10

sw2
int f0/4
speed 10
duplex auto (or full)

int f0/5
speed auto (or 100)
duplex auto (or full)

James

Thanks for the lab and using the concept that both speed and duplex must be configured to disable auto-negotiation. A small but important detail.

Otherwise, I assumed incorrectly (Problem 2, Example 3) that configuring speed only, would cause the PC (PC can not sense speed) to not see any negotiation messages from the switch about the speed and thus PC would drop speed to 10 and use half duplex.

My commands were correct, but my logic was wrong.

So thanks again.

James

certskills

You’re welcome!
I get a lot of follow-up questions on this point in the support queue for the CCNA books. Maybe your comment is the underlying issue. Maybe I need to explain more about how the autonegotiation happens out-of-band, that is, it’s not using bits transmitted the same way the data is transmitted. Thanks for the comment.

James

One other thought I had was, what is the PC’s logic. I was making the assumption that the PC used the same logic as the switch, but I don’t remember the book stating exactly what this is and the examples are from the switches perspective. As someone new that is learning this, I am not sure exactly what the PC does when the switch doesn’t respond appropriately. I assume the same b/c the PC and sense (tip from the lap) speed too.

I don’t know if its needed for the CCNA, but I love more details about what happens when only speed or duplex is configured. It was not as obvious for me until this lab.

Your labs have been way better than the Pearson lab simulator I have purchased!!! The other labs spoon feed you too much.

James

certskills

James,
Thanks for the additional feedback! FYI, a couple of years into an edition of the books, I start chipping away at small revisions and changes, knowing that one day I’ll revise the books again. That point was on my mind, and you’ve helped me along the way in thinking through that point. Notes made for changes for the next edition! Thanks.
Appreciate the comments on the labs! Honestly, lab style becomes a religious argument when you get more than one person on a team developing labs for any IT product. 🙂 Glad you like these. I think it works well given the possibility of interaction.
Thanks again,
Wendell

Cee

Hi Wendell,

I am new to networking and reading your 2020 edition of the CCNA Vol 1 guide. The point James mentioned is not highighted in the book. Are you able to expand on this aspect of autonegotiation more in your blog for those of us studying for the exam, it will be most appreciated.

Attila

Hello Wendell,

I’d like to ask about your chapter on collision domains in Vol. 1 of the OCG.

Isn’t it correct to say that the only scenario where collisions could occur is if a device (any device) was connected to a hub (or a repeater, the hub being just a multiport repeater)? The reason being that hubs/repeaters only speak half-duplex, so they are using only 1 wire pair for transmitting data. So one wire pair is used to both transmit and receive signals (but only one at time, so either transmit, or receive), and the other wire pair is used to signal busy/ready. If both ends start transmitting at the same time, then when the signals reach each other (because they’re traveling on the same wires), they “collide,” i.e. both signals get corrupted.

Now if we set the interface of a switch or a router to half-duplex and we connect it to any device other than a hub or repeater, it may think in certain cases that a collision has occured, but in truth, no collisions can ever occur, right? In other words, even if one or both devices (neither of which are hubs or repeaters) are set to half-duplex, the signals don’t get jumbled when the devices detect a collision (unlike in the case where one device is a hub or a repeater). Or when you set one (or both) of them to half-duplex, do they (the switches or routers) start using the same wire pair for both sending and receiving signals, and the other one to signal busy/ready?

I’d be very happy to read your enlightening response.
Have a nice weekend.
Attila

Reason

What is the password for the line con and enable haha

Reason

what are the line con and enable passwords haha?

19
0
Would love your thoughts, please comment.x
()
x