Config Lab: L2 EtherChannel 2
Both layer 2 EtherChannel and layer 3 EtherChannel use the same set of commands to create the channel. You have the option to use static configuration or one of two dynamic protocols to negotiate the formation of a trunk (LACP or PAgP). Today’s lab provides a little exercise on all three options (static, PAgP, LACP) in the context of L2 EtherChannels, but it helps you prepare for both L2 and L3 EtherChannel configuration.
The Lab Exercise
Requirements
This lab uses a small LAN, all acting as layer 2 switches. Several pairs of switches connect with a pair of links that operate as 802.1Q trunks. Your job: make each pair of links operate as a layer 2 EtherChannel.
As a bit of a twist, the initial configuration for this lab pre-configures some details. Your job is to determine the correct configuration that should be added to the initial configuration. By starting out with some configuration, you not only have to think about a nice orderly configuration, but also the impacts of the existing configuration on the final EtherChannel configuration.
The specific rules for this lab are:
- Configure the three EtherChannels shown in the figure as follows:
- Dist1 – Dist2: manually configured.
- Dist1 – Access 1: Use LACP, with Dist1 initiating the negotiations and Access1 not initiating the negotiations.
- Dist2 – Access 2: Use PAgP, with Dist2 initiating the negotiations and Access2 not initiating the negotiations.
- All physical links between switches already use 802.1Q trunking per the initial configurations.
- Ensure that the Port Channels act as trunks:
- Use 802.1Q trunking instead of ISL.
- Configure all switches to dynamically negotiate trunking, and all switches to initiate that negotiation.
Figure 1: Distribution/Access Switch Topology
Initial Configuration
Examples 1, 2, 3, and 4 show the beginning configuration state of Dist1, Dist2, Access1, and Access2.
hostname Dist1
!
vlan 2,3,4
!
interface GigabitEthernet1/0/1
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
channel-group 10 mode on
!
interface GigabitEthernet1/0/2
switchport access vlan 2
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
channel-group 10 mode on
!
interface GigabitEthernet1/0/3
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
channel-group 20 mode active
!
interface GigabitEthernet1/0/4
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
channel-group 20 mode active
Example 1: Dist1 Config
hostname Dist2
!
vlan 2,3,4
!
interface GigabitEthernet1/0/1
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
channel-group 10 mode on
!
interface GigabitEthernet1/0/2
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
switchport access vlan 2
channel-group 10 mode on
!
interface GigabitEthernet1/0/3
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
channel-group 20 mode auto
!
interface GigabitEthernet1/0/4
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
switchport access vlan 2
channel-group 20 mode auto
Example 2: Dist2 Config
hostname Access1
!
vlan 2,3,4
!
interface GigabitEthernet1/0/1
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
channel-group 20 mode desirable
!
interface GigabitEthernet1/0/2
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
channel-group 20 mode desirable
Example 3: Access1 Config
hostname Access2
!
vlan 2,3,4
!
interface GigabitEthernet1/0/1
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
channel-group 20 mode auto
!
interface GigabitEthernet1/0/2
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
switchport access vlan 2
channel-group 20 mode autoExample 4: Access2 Config
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:
- Download the .pkt file linked below.
- Open the .pkt file, creating a working lab with the same topology and interfaces as the lab exercise.
- Add your planned configuration to the lab.
- Test the configuration using some of the suggestions below.
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:
- Download the CML file (filetype .yaml) linked below.
- Import the lab’s CML file into CML and then start the lab.
- Compare the lab topology and interface IDs to this lab, as they may differ (more detail below).
- Add your planned configuration to the lab.
- Test the configuration using some of the suggestions below.
Note: As of when this post was published, CML did not support LACP to negotiate a trunk. The LACP configuration shown in the answers post is correct, but if you test in CML, you will not see a working EtherChannel between Dist1 and Access1.
Note: IOS tends to copy interface configuration over to the automatically-creates port-channel interface, and for good reason. However, that feature means that in your lab, or when using CML, you may see a slightly different initial configuration based on the timing of when the configuration is added to the switches. So, if you do this lab in CML or any other environment, focus more on the final configuration rather than the interim state or the initial configuration state.
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 |
| Dist1 | G1/0/1 | G0/1 |
| Dist1 | G1/0/2 | G0/2 |
| Dist1 | G1/0/3 | G0/3 |
| Dist1 | G1/0/4 | G1/0 |
| Dist2 | G1/0/1 | G0/1 |
| Dist2 | G1/0/2 | G0/2 |
| Dist2 | G1/0/3 | G0/3 |
| Dist2 | G1/0/4 | G1/0 |
| Access1 | G1/0/1 | G0/1 |
| Access1 | G1/0/2 | G0/2 |
| Access2 | G1/0/1 | G0/1 |
| Access2 | G1/0/2 | G0/2 |
Lab Answers Below: Spoiler Alert
Lab Answers: Configuration (Click Tab to Reveal)
Answers
Figure 1: Distribution/Access Switch Topology
interface GigabitEthernet1/0/2
no switchport access vlan 2
!
interface port-channel 10
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
!
interface port-channel 20
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
Example 1: Dist1 Config
interface GigabitEthernet1/0/2
no switchport access vlan 2
!
interface GigabitEthernet1/0/3
shutdown
channel-group 20 mode desirable
no shutdown
!
interface GigabitEthernet1/0/4
shutdown
channel-group 20 mode desirable
no shutdown
!
interface port-channel 10
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
!
interface port-channel 20
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
Example 2: Dist2 Config
interface range GigabitEthernet1/0/1-2
shutdown
no channel-group 20 mode desirable
channel-group 20 mode passive
no shutdown
!
interface port-channel 20
switchport trunk encapsulation dot1q
switchport mode dynamic desirable
Example 3: Access1 Config
interface port-channel 20
switchport trunk encapsulation dot1q
switchport mode dynamic desirableExample 4: Access2 Config
Commentary, Issues, and Verification Tips (Click Tabs to Reveal)
Commentary
This lab focused on layer 2 EtherChannel. There are three main ways to configure EtherChannel: Statically configuring it using the on keyword, dynamically configuring it to use LACP, and dynamically configuring it to use PAgP. Both LACP and PAgP have similar goals but are not interoperable with each other. Interestingly, Cisco prefers customers to use one of the dynamic protocols because the protocols perform compatibility checks of several parameters that must match for links to be added to a channel.
This lab calls for three different EtherChannel links, all of which had at least one compatibility issue based on the pre-existing configuration. To complete this lab, you need to configure the three EtherChannels per the lab specifications while also changing the configuration to overcome the compatibility issues.
Also, as an aside, you would likely not see so many combinations of configuration settings in the same LAN. Instead, you would create a configuration and use that convention repeatedly for all EtherChannels. This lab asks for a variety of configurations to help you exercise your configuration skills.
One huge key to interpreting the initial configuration is that the channel-group number interface subcommand causes IOS to create a port-channel interface by that same number. For instance, on switch Dist1, once the first channel-group 10 command was configured, interface portchannel 10 existed, with all default settings.
PortChannel 10 – Dist1 to Dist2
First, focus on Etherchannel 10 between switches Dist1 and Dist2. As initially configured, it has two problems:
- The two physical links have different access VLAN settings, which prevents both physical links from being active in the EtherChannel at the same time. One physical link uses a default setting of access VLAN 1, while the other is configured with access VLAN 2 (switchport access vlan 2).
- Per the sequence of events in this lab, the lab does not show the port-channel interface in the initial configuration. Once the switch creates the port-channel interface, it has all default settings. As a result, it may or may not be correctly configured for trunking at this point, so trunking needs to be configured on the port-channel interface.
On the first point above, EtherChannels have a list of configuration settings that must agree before new links can be added to an EtherChannel. One of the settings that must agree is the access VLAN setting – even if the channel will be trunking. To solve this problem, make the physical links use the same access VLAN setting. In this case, we set both links to use the default setting of access VLAN 1 with the command no switchport access vlan 2 on one physical port (or you could have used switchport access vlan 1).
Once completed, both links in port-channel 10 should be added and active in the channel. Then, to make the port-channel act as a trunk, you should add the switchport mode dynamic desirable command to match the particulars of the lab instructions. This tells the switch to initiate the dynamic choice to use 802.1Q trunking. (Additionally, on some older switches, including the simulated switches in Cisco Packet Tracer, the switches need to be told to use 802.1Q instead of ISL using the switchport trunk encapsulation dot1q command.)
PortChannel 20 – Dist1 to Access1
Next, focus on the link between Dist1 and Access1. Per the initial configuration, Dist1 uses LACP because of its channel-group 20 mode active command, and Access1 uses PAgP per the channel-group 20 mode auto command. (The “auto” option happens to be one of the PAgP options, and the “active” option is one of the LACP options.) Because LACP and PAgP are not compatible with each other, this EtherChannel channel will never form. The lab requirements state that this link should use LACP, with Dist1 being the initiating device. To meet the lab requirements, change the configuration on switch Access1 to use LACP passively; to configure this, use the channel-group 20 mode passive command on both links on Access1.
The other requirement for this EtherChannel is to use 802.1Q trunking, so the same configuration required for port-channel 10 between Dist1 and Dist2 is required here as well. To match the lab requirements, on both Dist1 and Access1, add the switchport mode dynamic desirable command and optionally the switchport trunk encapsulation dot1q command.
Finally, note that Packet Tracer gets confused if you leave the interfaces up while configuring the subcommands in the configuration solution. To improve your chances of success, follow the convention in the answer config uses a shutdown command to disable the ports, followed by the relevant subcommands, and ends with a no shutdown to enable the ports again.
PortChannel 20 – Dist2 to Access2
For this last combination, note that we chose the duplicate number of port-channel number 20 on purpose to duplicate the same port-channel number used between Dist1 and Access1. The port-channel number just has to be unique on a switch. In a real-life design, the designer would likely use a unique number to make operational tasks more obvious.
For this last EtherChannel, per the initial configuration, both Dist2 and Access2 are configured to use PAgP per the channel-group 20 mode auto command. (The “auto” option one of the PAgP options.) However, the auto parameter causes the switch to wait for the other switch to initiate the channel negotiations, so with both sides using auto, no channel will form. The requirements state that this link should use PAgP, with Dist2 being the initiating device. To correct this configuration, modify the Dist2 configuration with the channel-group 20 mode desirable command on both physical links.
The other requirement for this EtherChannel is to use 802.1Q trunking, so the same configuration required for the other two port channels is required here as well. To match the lab requirements, on both Dist2 and Access2, add the switchport mode dynamic desirable command and optionally the switchport trunk encapsulation dot1q command.
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 | Packet Tracer trunking may require the switchport trunk encapsulation command | Packet Tracer LAN switches operate like older Cisco switch generations in that they support both ISL and 802.1Q trunking. The initial configurations for this lab show the switchport trunk encapsulation dot1q command, which if needed on a PT switch, is the correct command to define the type of trunking to use. Depending on the PT version and switch model you use, you may not need the command. |
| 2 | Use the shutdown and no shutdown commands on interfaces before changing the configurations of those interfaces | Packet Tracer can struggle with dynamic changes to the operation of the devices based on new configuration. Particularly for this lab, it helps if you disable interfaces before changing EtherChannel configuration settings on an interface. |
| 2 | To change to another channel-group setting (auto, desirable, etc), first remove the existing command with no channel-group … | This is not specific to Packet Tracer, but to make sure you see it… for example if an interface has channel-group 20 mode auto configured, issue a no channel-group 20 mode auto command to remove it before configuring another setting. |
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.
- Use the show etherchannel summary command to verify that each of the EtherChannels is up and operational.
I used P/T and configured the full topology using all the given config commands, for all the four switches.
Once all done, it could be noticed, that, there are blinking green arrows on, the individual connections, of all the three EtherChannels, except, a sole connection of the EtherChannel between, Dist2, and, Access2, which is poorly communicating, showing a blinking Amber.
This connection belongs obviously to the Channel-group 20, and, is between the GigaEth1/0/4 port of Dist2, switch, and, the GigaEth1/0/2 port of the Access2 switch.
Channel-groups mode of both of these switches, were configured as, “auto”, in the given problem, i.e, exercise.
So, fixed the fault by configuring the mode as, “desirable”, and it could be seen the blinking green arrows on this connection.
I had a lot of trouble with this exercise in Packet Tracer. For some reason, even with the ports set to their appropriate LACP/PAGP configurations in the same port-channel, with the switchport access vlan commands removed, and the portchannel interface config configured to switchport mode dynamic desirable, the etherchannels failed to dynamically negotiate trunking, except for the Dist2-Access2 link, which already starts off successfully trunking. I only got the Etherchannels to trunk successfully by configuring them all with the switchport mode trunk command. I think maybe it has something to do with the switch CLIs in packet tracer not recognizing the switchport trunk encapsulation command, and perhaps this lab’s save file dating from a time when that command was still relevant, but I’m not sure.
Hi John,
Thanks for the notes. I’ll flag it as something to check out – good to know.
Wendell
I can confirm this. Switching from switchport mode dynamic desirable to switchport mode trunk on all trunks fixes the issue. Running version 8.1 and I can’t issue switchport trunk encapsulation dot1q command at all.
Thanks for the confirmation, Emil. I don’t want to go change all the notes about PT issues, but I think I should, regarding the need (or not) for trunking encapsulation depending on the PT version. Thanks for the scoop.
Wendell
Lots of trouble with PT and this lab. PT was telling me that the port-channel was up between dist1 — access1 but using different protocols!
Tried the suggestion in the PT issues section to no avail and also tried the options mentioned in the earlier comments to no avail. I may have been missing something as I did quite a bit of fiddling.
On access1, port gig1/0/2 says “Access Mode VLAN: 2 (VLAN0002)” even though I have completely removed that vlan from the switch configuration (I think).
Need to start again fresh tomorrow and see if it works. I have physical lab gear but only 2 catalyst switches not 4 so will struggle doing it that way. Have also setup GNS3 so might try that way instead as I don’t want to spend more time with PT if the software is bugged.
PT version is 8.1.1.0022.
Hi Joe,
I think your problems were likely caused by the lab exercise moreso than your work or by Packet Tracer bugs. I tested today both in PT and on real switches, and I updated this lab post and the .pkt and .yaml (CML) files. FYI. Details below.
First off, on the Dist1 – Access1 Etherchannel, I did not intend to begin the lab with different access VLANs on the ports used between Dist1 and Access1. The Dist1 – Dist2 Etherchannel lets you experience that issue already, so I didn’t mean to require you to think about it for Dist1 – Access1. Anyway, to fix that issue, I changed the initial config on Dist1’s G1/0/3 and 4 both default to access vlan 1, likewise for Access1’s G1/0/1 and 2.
Next, the lab did not account for a transition issue to move from the initial config to the answer config. I’ve added some notes in the Commentary and Known Issues tabs. For example, Access1 rejects the ” channel-group 20 mode passive” subcommand because ” channel-group 20 mode desirable” is already configured. So if you just paste the suggested solution config into Access1, that command is rejected, and the Etherchannel does not work. FYI, I tested today on some 2960XR switches, and they show the same error as Packet Tracer.
Best solution: shutdown the interfaces, then use the “no” version of the channel-group command to remove the existing command, and then configure the new command, and then enable the interfaces again with a no shutdown command. That’s what I changed the lab to show.
I think that now, with the new .pkt file, and the new suggested configurations, the lab should work. Give it a shot and let me know what you think.
This solution worked a treat for me. Thanks!
Hi Wendell,
First of all I want to thank-you for the “disclaimer” about how packet tracer works compared to actual Cisco networking hardware with IOS up and running.
With that said, I’m wondering if this Config Lab pushed packet tracer a little too far. In spite of many attempts, the only way I could get this topology working as intended, was by using static trunking. Every time I tried using DTP there were always problems. This is true for the downloaded .pkt as well as .pkt files I configed from scratch using the same switch model (3650-24PS) for the switches as the downloaded .pkt file.
When I used DTP for trunking I would sometimes get 4 green triangles for link lights but, even then, if I looked a little deeper I would find problems. While the show etherchannel summary and show etherchannel portchannel commands might indicate that the EtherChannel is up and running other show commands indicated problems with trunking. The show vlan brief command would include the PortChannel and interfaces that were supposedly trunks. And the show interface trunk command had nothing in its output, indicating again, that the trunking did not actually happen. The last command I would use is the show interface g1/0/1 switchport (for example) and I think I found a hint to the problem. Each time I used DTP for trunking I would see a “mixed mode” problem, with the Administrative mode being dynamic desirable and the Operational Mode being static access. This got me thinking and I’m wondering if there is an issue between DTP and CDP within packet tracer. In any case, I would greatly appreciate any ideas, comments, and information you could share with me.
Please note that I did my best to keep notes on the configuration steps and that I followed and the results for both the downloaded .pkt file and the “from scratch” .pkt file. And if it would be at all helpful, I would be willing to share these files with you.
The version of packet tracer I’ve been using for this is: Version 8.1.1.0022
Mike
Mike,
So sorry for the delay in approving your post and getting back to you. And thanks for the interesting post!
I don’t know for sure, but I think that PT is not attempting to re-create protocols. EG, you wonder if there’s a DTP vs. CDP interaction issue in PT. My first thought is that instead of implementing CDP, for instance, they take the config + topology + state and predict “what would CDP display?” So it’s internally a game (a complex game) of predicting all factors to consider to predict the show command output, rather than generating messages, processing them, attempting to implement CDP, for instance.
So, while I like your logic, I’m not sure going down that path will help solve the immediate problem.
By the way, the above is my personal opinion, having helped design a CCNA simulator. It’s not based on some secret revelation about PT.
That said, I wonder if a simpler case might help. For instance, try two links only – even remove all the configuration.
Also, whenever you configure more than a command or two, and see weird results, save the configs, and save the .pkt file, close it, and even stop PT and restart. I’ve seen several cases in which PT doesn’t respond well in show commands with dynamic config but that it handles the same case well with everything already in the startup-config file.
Hope some of this helps. Sorry I don’t have the specific “oh I’ve seen this” answer in this case in PT, though. All the best.
For those who can get etherchannel working but can’t get trunking to work, here is my problem and solution.
Problem: Etherchannel between switches work fine but when configuring etherchannel with dtp, the switch will error disable the etherchannel because etherchannel have bpdu turned on. The switch received the following error message:
(%SPANTREE-2-RECV_PVID_ERR: Received 802.1Q BPDU on non trunk Port-channel20 VLAN1.)
(SPANTREE-2-RECV_PVID_ERR: Received 802.1Q BPDU on non trunk Port-channel20 VLAN1.)
Solution: Go to the etherchannel interface (int po10) and issue (no spanning-tree bpduguard)
Hope that helps!
Having some lingering issues with this one. I was able to edit/configure Dist1->Access1 and Dist1->Dist2 but the Dist2->Access2 is giving me problems. I have it set to the correct PAgP modes of desirable on Dist2 G1/0/3-4 and auto on Access2 G1/0/1-2. I removed the access VLAN 2 command and even saved/reloaded the switches and still get this STP error on Dist2 Po20 after a few minutes:
%SPANTREE-2-RECV_PVID_ERR: Received 802.1Q BPDU on non trunk Port-channel20 VLAN1.
%SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel20 on VLAN0001. Inconsistent port type.
For some reason STP on Access2 is removing G1/0/2 from the tree and Dist2 is blocking Po2 because of it.
I think it is a bug but not sure. Could I send the config over for review and let me know where I’m going wrong?
This lab completely threw me off. I had no idea I had to make half the changes I see in the completed configuration. I don’t recognize half of the commands used; no switchport access, interface port-channel w/switchport subcommands, and then the shutdown/no shutdown with channel-group commands in between. I understand this was kind of a ‘clean it up’ sort of config, but that’s the extent of my understanding. I haven’t had any issues with config labs up to this point, so I can only wonder if I am missing something that built up to this lab. All other labs more or less built upon the last, and this one did as well, but dumped a lot of other ideas in that I wasn’t prepared for. Was I supposed to read the suggested Appendix mentioned in the book?
Hi Sean,
Thanks for the comment – it will help me improve the books.
To your question, no, I don’t think you’re missing something. This lab just goes a bit beyond what the books spell out. For instance, in many places, the book tells you about using a “no” version of a command to revert to the default, or to the opposite value, but the VLANs chapter doesn’t specifically state that for the “no switchport access vlan 2” command reverting to the default. A more difficult leap is the need for the interface subcommands under the port-channel interface, which the book doesn’t address at all.
So, I’d say that this lab may be just unfair to ask based on what I covered in the book. I’ll look at adjusting it a bit. (It’s a pretty involved lab even if you had learned those commands anyway.)
Also, was the info in the Lab Commentary useful to at least understand the answers, so you could learn from that? Again, just looking to improve.
Thanks again,
Wendell
I have encounter an error while trying to configure encapsulation dot1q, either trying on each interface saparately or in the portchannel interface created, a assume is because PT switches just admit dot1q by default, please advise
Alberto,
Some versions of Packet Tracer, from some switches, require the command – but some do not. If they don’t require it, they default to 802.1Q. See the notes in the “Known Packet Tracer Issues” tab.
Wendell
Hello Wendell,
I don’t seem to find the page where you discussed configuring trunking on the port channels. Are you able to point me in the right direction? I am reading your CCNA Vol 1 guide.
Hi Tewa,
Thanks for using my books!
The trunking config is described in Chapter 8. The config details are the same on physical switch ports as with layer 2 EtherChannel ports.
Hello Wendell,
Please a request for some clarifications.
I hope I was able to articulate my question so you can understand my confusion. I also know this is a lot, I will appreciate if you can provide me some clarifications. Thanks Wendell
Hey Tewa,
By number…
1) The switchport access vlan x command does not make the port an access port, regardless of whether it needs to create the VLAN or not. The command defines the access VLAN that the port uses IF the port is an access port. The port is an access or trunk port based on the switchport mode command’s settings and resulting negotiation (if using a setting that allows negotiation.) EG, switchport mode access makes the port operate as an access port.
2) Short answer: yes. It’s a check of whether the access VLAN setting is the same. It’s not a check of whether the setting make sense compared to your VLAN design.
3) That’s a mistake in the lab – I’ll need to fix it. Thanks for noting it.
4) Honestly, it’s complex. I tried to simplify the topic in the book to match what’s reasonable for the exam, and I would probably approach it differently next edition. For instance, switches do not care about STP settings when creating the channel… but then fail if you later change physical interface STP settings to different values. And there is some difference I’ve seen in experiments based on models and/or IOS versions. And Cisco doesn’t test on such differences. So, for configuring the channel the first time, STP settings are not considered, and mismatches do not cause a problem. Example 10-6 is a case from an older switch/IOS (for which I don’t have notes on what it was) that gave that error. For instance, that same error doesn’t occur on more recent switches. Which is why I need to simplify to a description that is digestable for the exam.
For instance, here’s the likely replacement example for the next edition, where I use a native VLAN mismatch to demonstrate the failure.
Hope this helps…
Wendell
Hello Wendell,
Is there a limitation on length of posts or permitted characters on this site? I am trying to post a question but the site would not post my comment.
switchport trunk encapsulation dot1q says that it is an invalid command. Please don’t create labs with instructions that can’t be configured. this is very frustrating.
Jay,
Thank you kindly for the feedback.
FYI, the command can be configured in some versions of Packet Tracer. Sorry that the info in the “Known Packet Tracer Issues” section of the lab page didn’t solve your problem. For future reference, if you try other labs, if you find odd behavior in Packet Tracer, check that tab for notes that might explain the issue.
Wendell
Here are my configurations 😁 (I did it before checking the initial configuration).
Not really sure about it, but when I saw initial configuration it looked like it was already configured. Also I read that other students got some problems in Packet Tracer, as I’m doing it on text editor I will make sure to replicate exercise as .pkt so I could check the extra challenges of packet tracer.
Dist1
>enable
#configure terminal
#(c)#int range Gi1/0/3-4
#(c-ifr)#channel-group 20 mode active
#(c-ifr)#exit
#(c)#interface port-channel 20
#(c-if)#switchport mode trunk
#(c-if)#switchport trunk encapsulation dot1q
#(c-if)#exit
#(c)#int range Gi1/0/1-2
#(c-ifr)#channel-group 10 mode on
#(c-ifr)#exit
#(c)#interface port-channel 10
#(c-if)#switchport mode trunk
#(c-if)#switchport trunk encapsulation dot1q
#(c-if)#do wr
#(c)#end
Dist2
>enable
#configure terminal
#(c)#int range Gi1/0/3-4
#(c-ifr)#channel-group 20 mode desirable
#(c-ifr)#exit
#(c)#interface port-channel 20
#(c-if)#switchport mode trunk
#(c-if)#switchport trunk encapsulation dot1q
#(c-if)#exit
#(c)#int range Gi1/0/1-2
#(c-ifr)#channel-group 10 mode on
#(c-ifr)#exit
#(c)#interface port-channel 10
#(c-if)#switchport mode trunk
#(c-if)#switchport trunk encapsulation dot1q
#(c-if)#do wr
#(c)#end
Access1
>enable
#configure terminal
#(c)#int range Gi1/0/1-2
#(c-ifr)#channel-group 20 mode passive
#(c-ifr)#exit
#(c)#interface port-channel 20
#(c-if)#switchport mode trunk
#(c-if)#switchport trunk encapsulation dot1q
#(c-if)#do wr
#(c)#end
Access2
>enable
#configure terminal
#(c)#int range Gi1/0/1-2
#(c-ifr)#channel-group 20 mode auto
#(c-ifr)#exit
#(c)#interface port-channel 20
#(c-if)#switchport mode trunk
#(c-if)#switchport trunk encapsulation dot1q
#(c-if)#do wr
#(c)#end
I read all the comments and packet tracer issues and I am still a bit unsure how to complete this lab or if it’s even possible? After removing vlan 2 from int1/0/2 and moving into conf mode for port channel10, on Dist1, I can’t get “switchport trunk encapsulation dot1q” to work, even after shutting down the port channel & the physical interfaces.
I am not clear on what you meant in the known issue – “Packet Tracer trunking may require the switchport trunk encapsulation command.” I tried just “switchport trunk encapsulation” (without dot1q), but that didn’t work either.
Am I missing something big here? Will the actual test have these kinds of issues? Is there any way we could get the config, specifically for packet tracer?
Thank you for any help
Hi Jay,
I found some problems. I’m editing the lab. So… ignore the lab til I post here again.
Jay,
So, I’ve gotten my head around this lab again. I’ve not read it in quite a while. So let me answer your questions to help you sift through things. But I also found some oddities in Packet Tracer behavior, so I may need to work on the lab to avoid those a little better.
So… is the lab even possible? I believe so. However, the oddities I’m seeing in Packet Tracer has to do with the PortChannels NOT trunking. I see some improvement with saving the packet tracer file and re-opening, and with shutting down the interfaces and then doing a no shut. Anyway, you may not be imagining things on that point. But I don’t have a definitive answer yet.
On the confusion about the “switchport trunk encapsulation” command, if you have my books, look in chapter 8 under “VLAN Trunking Configuration” for more info. Shorter version… Cisco switches formerly supported ISL and 802.1Q. So, you could pick. Packet tracer required you to pick one or the other. Over time, real Cisco switches quit supporting ISL, so there was no need to pick (via config). Packet Tracer was slow to match. So those comments are a reminder to pick by issuing “switchport trunk encapsulation dot1q”.
In your version of packet tracer, they’ve finally migrated to match the more modern behavior of not supporting ISL. I know that because the now-obsolete command is rejected as if it does not exist any more as a command.
So, whatever issues you’re finding in lab, at your Packet Tracer version, are probably not related to the “switchport trunk encapsulation” command. Probably has more to do with Packet Tracer and the support for portchannels and trunking.
I will look further at the lab and the behavior… just not likely before a few more days. FYI.
Dear Wendell,
In the above configuration of Dist 1, switchport access vlan 2 is assigned for interface gigabitethernet 1/0/2 only and not for the other ports, likewise in other switches switchport access vlan 2 is assigned for some specific ports but not all the ports.
and why did you create vlan 2, 3 and 4 ??