Config Lab: L2 EtherChannel 2

 In 200-301 V1 Ch10: RSTP and EtherChannel, 200-301 V1 Part 3: VLANs, STP, 200-301 V1 Parts, Config Lab, Config Lab CCNA Vol 1 Part 3, Hands-on

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.

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

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 auto

Example 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:

  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!

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 desirable

Example 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:

  1. 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).
  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.

 

More Labs with Related Content!

Config Lab: L2 EtherChannel 1
Config Lab: IPv4 Addresses 1
Subscribe
Notify of
guest

23 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Punya Atma

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.

John V

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.

certskills

Hi John,
Thanks for the notes. I’ll flag it as something to check out – good to know.
Wendell

Emil

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.

certskills

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

Joe

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.

certskills

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.

Sam D'Arcy

This solution worked a treat for me. Thanks!

Mike Hewitt

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

certskills

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.

Isaac

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!

GJM

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?

Sean P.

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?

Alberto Silva

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

Tewa

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.

Tewa

Hello Wendell,
Please a request for some clarifications.

  1. This exercise brought up a fact I thought I had previously mastered but from the look of things it appears I still don’t have the basics down yet. This is with regards to letting IOS automatically create vlan. When you issue the switchport access vlan x in interface mode, I know this creates a specified vlan if it does not already exist on the switch. But the confusing part I struggled with in this exercise is the access word in the command. By creating a vlan with the sw access vlan x, does it create the specified vlan as well as mark the int as an access port? or does it simply create the vlan and the access in the command has nothing to do with the port being an access port?
  2. In the lab commentary for both distribution switches you commented on the sw access vlan 2 configuration as follows: “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).” My question on this one is this: Would configuring both links to use vlan 2 instead of vlan 1 or no sw access vlan 2 meet the requirement for this point?
  3. As per the initial config, one of the links between Dist 2 and Access 2 is in vlan 2 (g1/0/4 & g1/0/2 on dist 2 and access 2 respectively) and the other in vlan 1. You did not add any config to resolve the vlan settings mismatch as you did for the distribution switches. Does the same explanation you provided for the distribution switches not relevant in this case? Is there a reason why this was not part of the configuration in the solution you provided?
  4. This one is from vol 1 of the ccna study guide book. Chapter 10, page 252, the paragraph just after the key topic you said “When checking neighbors, all settings except the STP settings must match.” In the example following this statement, a different RSTP port cost was configured causing the etherchannel to fail. My confusion with this is: why would this etherchannel fail if the underlined text applies? I interpreted the underlined text to mean that STP settings does not matter in determining if a port is added to the port channel. Is my interpretation wrong? Did I misunderstand the point here?

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

Tewa

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.

jay

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.

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