Etherchannel practice questions

STP manages VLANs, VTP prevents loops, EtherChannel restricts MAC addresses, Port Security aggregates links, DTP provides fast per-VLAN convergence, and Rapid PVST+ negotiates trunks.

Why wrong: This option assigns each feature another feature's job: STP is given VLAN management (VTP's role), VTP is given loop prevention (STP's role), EtherChannel is given MAC address restriction (Port Security's role), Port Security is given link aggregation (EtherChannel's role), DTP is given fast per-VLAN convergence (Rapid PVST+), and Rapid PVST+ is given trunk negotiation (DTP). Since none of the features are matched with their actual purpose, the mapping is completely invalid.

STP aggregates links, VTP prevents loops, EtherChannel manages VLANs, Port Security negotiates trunks, DTP restricts MAC addresses, and Rapid PVST+ provides fast per-VLAN convergence.

Why wrong: This option mixes up five of the six features: STP is incorrectly said to aggregate links (EtherChannel's role), VTP is incorrectly said to prevent loops (STP's role), EtherChannel is incorrectly said to manage VLANs (VTP's role), Port Security is incorrectly said to negotiate trunks (DTP's role), and DTP is incorrectly said to restrict MAC addresses (Port Security's role). Only Rapid PVST+ is correctly matched with providing fast per-VLAN convergence, but the five wrong pairings make the overall option incorrect.

STP provides fast per-VLAN convergence, VTP aggregates links, EtherChannel prevents loops, Port Security manages VLANs, DTP restricts MAC addresses, and Rapid PVST+ negotiates trunks.

Why wrong: Every pairing in this option is mismatched: STP does not provide fast convergence, that is the role of Rapid PVST+; VTP does not aggregate links, EtherChannel does; EtherChannel does not prevent loops, STP does; Port Security does not manage VLANs, VTP does; DTP does not restrict MAC addresses, Port Security does; and Rapid PVST+ does not negotiate trunks, DTP does. Because all six features are assigned to the wrong function, the entire answer is incorrect.

The channel fails because both sides must be passive.

Why wrong: If both sides are configured with LACP passive mode, the channel will fail to form because passive interfaces only respond to received LACP PDUs and never initiate negotiation. With no active device to start the handshake, neither switch will recognize the peer's capability for aggregation, leaving the member links in a standalone state. Thus, passive/passive is the pairing that prevents LACP from establishing the bundle.

The channel becomes a routed interface automatically.

Why wrong: LACP is a link aggregation control protocol that operates independently of the Layer 2 or Layer 3 configuration of the ports; it does not automatically convert an EtherChannel into a routed interface. Whether the resulting port-channel is a Layer 2 switchport or a Layer 3 routed port is determined by the 'switchport' or 'no switchport' configuration, not by LACP itself. Therefore, the channel remains in its configured mode unless the administrator explicitly changes the interface type.

All VLAN tags are removed from the bundle by default.

Why wrong: Forming an EtherChannel does not strip or alter VLAN tags on the aggregated link. When operating as a Layer 2 trunk, each member interface carries the same VLAN tags as any standard trunk port, and the EtherChannel bundle simply aggregates bandwidth while preserving 802.1Q tagging. The statement confuses logical bundling with VLAN manipulation; VLAN tags remain intact for all traffic traversing the channel.

Change the LACP mode on SW1's Gi0/2 from active to passive.

Why wrong: This is incorrect because the LACP mode mismatch is not the primary issue; SW2's Gi0/2 is passive and SW1's Gi0/2 is active, which is a valid combination (active/passive). Changing to passive would not fix the speed/duplex/VLAN mismatches.

Configure both interfaces with speed 100, duplex half, and switchport access vlan 10.

Why wrong: This is incorrect because while it would make the interfaces consistent, it uses suboptimal settings (100/half) that would degrade performance. The correct fix should use the higher speed and full duplex (1000/full) to match the faster interface.

Remove the switchport access vlan command from both interfaces and configure them as trunk ports with native vlan 1.

Why wrong: This is incorrect because the issue is mismatched VLANs, not the interface mode. Changing to trunk with native VLAN 1 would still leave the speed/duplex mismatch unresolved, and the native VLAN must match on both sides. The current configuration shows access ports, so converting to trunk is unnecessary.

The channel stays down because both sides must be active

Why wrong: LACP does not require both ends to be active; a passive interface will not initiate negotiation but will respond to incoming LACP PDUs from an active peer. The active/passive combination is explicitly designed to allow one side to drive the negotiation, so a single active side is sufficient. Thus, the claim that both must be active is incorrect—both active is only one possible valid pairing.

The channel forms only if PAgP is also enabled

Why wrong: PAgP (Port Aggregation Protocol) is a Cisco-proprietary negotiation protocol, whereas LACP is the IEEE 802.3ad open standard. The two protocols are incompatible and cannot be mixed on the same port-channel. Configuring LACP modes active/passive does not require PAgP to be present; the channel forms purely through LACP's own messaging, so this statement is false.

The channel becomes a static Port-Channel

Why wrong: A static port-channel is created only with the 'channel-group X mode on' configuration, which disables any negotiation protocol. In contrast, LACP active/passive modes produce a dynamic, LACP-negotiated bundle where the port-channel is managed by the Link Aggregation Control Protocol. Therefore, the resulting EtherChannel remains an LACP (dynamic) port-channel, not a static one.

Change the channel-group mode on the member interfaces from active to passive.

Why wrong: This is incorrect because the mode mismatch is not the issue; both sides can use active mode. Changing to passive would still work if the other side is active, but it does not fix the Layer 2/Layer 3 mismatch.

Add the 'switchport nonegotiate' command to the member interfaces.

Why wrong: Adding 'switchport nonegotiate' to the member interfaces disables Dynamic Trunking Protocol (DTP) on those ports, which only stops automatic trunk negotiation. It does nothing to align the Layer 3 nature of Port-channel1 (configured with 'no switchport' and an IP address) with the Layer 2 member switchports. The EtherChannel fails because the port-channel interface itself is a routed interface while the members are Layer 2 switchports; without converting the port-channel to Layer 2 trunk mode, this command cannot resolve the mismatch.

Configure the member interfaces with 'channel-group 1 mode on' instead of active.

Why wrong: Changing the channel-group mode from 'active' to 'on' forces the EtherChannel to form without LACP negotiation, bypassing the protocol-state check. However, 'mode on' does not alter the fundamental Layer 2/Layer 3 incompatibility: the member interfaces are Layer 2 switchports, whereas Port-channel1 has been configured as a Layer 3 interface with 'no switchport' and an IP address. The switch still enforces interface-layer consistency for bundling, so even forced mode fails until the port-channel is changed to a Layer 2 trunk.

Verify that both switches are using the same EtherChannel protocol (LACP or PAgP).

Why wrong: Because both switches were configured with `channel-group 1 mode active`, they are already using LACP unambiguously — `active` is an LACP-specific mode, not a PAgP mode. If the neighboring switch had been set to PAgP, LACPDUs would fail and the ports would remain in the stand-alone 'I' state, but inspecting the protocol now would only confirm what the configuration already proves. A protocol mismatch is not the issue here, since both sides explicitly negotiated LACP; the correct diagnostic path is to check VLAN consistency, which directly affects whether LACP considers the member links eligible for bundling.

Check that the speed and duplex settings match on all member interfaces.

Why wrong: While speed/duplex mismatch is a valid cause of the 'I' state, it is not the most targeted next step after confirming LACP mode. The technician should first rule out VLAN configuration mismatches, which are equally likely and require immediate inspection when trunk ports are involved.

Determine whether Spanning Tree Protocol is blocking one of the ports.

Why wrong: STP blocking state does not affect EtherChannel negotiation. A port that is part of a bundle will be shown in the 'P' (bundled) state regardless of STP status. The 'I' state indicates the port is not even joining the bundle, so STP is not the cause.

The EtherChannel is misconfigured with an LACP active/passive mode mismatch, forcing only one link to bundle.

Why wrong: An LACP mode mismatch prevents the EtherChannel from coming up at all; it would not show a formed bundle with only one active link. The exhibit does not display LACP state, only the load‑balancing algorithm.

VLAN pruning on the trunk has removed the VLAN from three of the four member interfaces.

Why wrong: VLAN pruning controls which VLAN traffic is allowed on a trunk. If the VLAN were removed from three members, those members would not carry any traffic for that VLAN, but they would still carry other VLANs and would not be idle for all traffic. The exhibit does not mention VLAN pruning.

Spanning Tree Protocol has blocked three of the four links in the EtherChannel because they form a loop.

Why wrong: STP treats a correctly configured EtherChannel as a single logical interface. Unless there is a misconfiguration (e.g., port‑channel members in different STP states), all members should share the same STP state. The exhibit shows no STP information, and a blocked state would not be caused by the load‑balancing setting.

The local switch is configured with LACP passive while the remote switch is set to LACP active.

Why wrong: LACP passive mode is a valid negotiating mode and is designed to pair with an active neighbor. In a passive-active configuration, the active switch initiates LACP PDUs and the passive switch responds, allowing both sides to aggregate ports into a bundled channel. The output shows member ports flagged D, which means the physical link is down or the port was administratively shut down, not that negotiation is pending. Therefore, a passive-active LACP pair would appear as bundled (P) members, not D, so this cannot be the misconfiguration shown.

The remote switch is configured with PAgP desirable while the local switch uses LACP.

Why wrong: A PAgP vs LACP mismatch would typically result in suspended ports (indicated by (s) or (I)), not the (D) down state shown, and the protocol column would likely show NONE or flags for mismatch. The (D) state suggests the physical link is down, not suspended due to protocol mismatch.

The port-channel member interfaces are configured as access ports, preventing LACP from negotiating.

Why wrong: LACP operates independently of the Layer 2 access or trunk mode, because LACP PDUs are sent to the well-known multicast address 01:80:c2:00:00:02 directly over the physical link before any VLAN tagging or access-port filtering is applied. Configuring an interface as an access port only affects the allowed VLAN and 802.1Q tagging; it has no bearing on whether LACP packets are exchanged. Therefore, access-port configuration cannot block LACP negotiation or cause the member ports to show a (D) down state, so this option is incorrect.

interface port-channel 1 switchport mode trunk switchport trunk allowed vlan 1 interface range g0/1-2 channel-group 1 mode desirable

Why wrong: This is incorrect because 'mode desirable' is a PAgP mode, not LACP. Also, the requirement specifies a Layer 2 EtherChannel in VLAN 1, which implies an access port, not a trunk.

interface port-channel 1 switchport mode access switchport access vlan 1 interface range g0/1-2 channel-group 1 mode passive

Why wrong: This is incorrect because LACP 'passive' mode will not initiate negotiation; it only responds to LACP packets. For the bundle to form, at least one side must be 'active'. The requirement implies both switches should be configured to actively negotiate.

interface port-channel 1 switchport mode access switchport access vlan 1 interface g0/1 channel-group 1 mode active interface g0/2 channel-group 2 mode active

Why wrong: This is incorrect because it assigns each physical interface to a different port-channel (1 and 2), which does not bundle them into a single logical link. Both interfaces must use the same channel-group number.

channel-group 1 mode active

Why wrong: Reissuing `channel-group 1 mode active` is redundant because the interface configuration already places all member ports into port-channel 1 with LACP active negotiation, as evidenced by the operational state and LACP protocol. This command only defines the bundling method and negotiation mode; it does not affect which VLANs are permitted on the trunks. The intermittent connectivity stems from mismatched allowed VLAN lists across the physical port-channel members, not from the channel-group mode being inactive or incorrect.

lacp rate fast

Why wrong: The `lacp rate fast` command only changes the frequency of LACP control PDUs from 30 seconds to 1 second for faster link failure detection. It does not modify the VLAN allowed list, trunk mode, or any forwarding parameter that would cause intermittent traffic loss. Since this EtherChannel is already established under active LACP, altering the keepalive interval cannot resolve a member-port VLAN consistency issue.

switchport mode trunk

Why wrong: While `switchport mode trunk` is necessary for carrying multiple VLANs, it does not dictate the specific set of VLANs permitted on the interface. The interfaces are already operational trunk ports on the Layer 2 port-channel, so reapplying the mode command changes no actual parameter. The critical missing element is the allowed VLAN list—the `switchport trunk allowed vlan` command must be identical on every member to prevent the switch from dropping frames when hashing picks a port that does not have the destination VLAN.

LACP uses the 'auto' and 'desirable' modes to negotiate an EtherChannel.

Why wrong: This statement is wrong because 'auto' and 'desirable' are PAgP (Port Aggregation Protocol) modes, which is a Cisco proprietary protocol. LACP (Link Aggregation Control Protocol) uses the IEEE 802.3ad standard modes 'active' and 'passive'. The 'auto' and 'desirable' modes are used with PAgP to dynamically form an EtherChannel between Cisco devices, but they have no meaning in a pure LACP configuration.

The 'show etherchannel summary' command shows the LACP system priority for each channel.

Why wrong: This statement is incorrect because the 'show etherchannel summary' command provides a high-level operational view of each EtherChannel, listing the channel group number, the port-channel interface, member ports, and their bundle status. LACP system priority is not part of that output; it is displayed by 'show lacp sys-id' or 'show etherchannel detail'. The summary output focuses on which ports are successfully aggregated (marked 'P') rather than on the LACP negotiation parameters.

An EtherChannel can be formed only if all member ports use the same LACP mode.

Why wrong: This statement is false. LACP does not require all member ports to use the same mode; instead, at least one end of the link must be in 'active' mode for negotiation to begin. A port in 'passive' mode only responds to LACP packets, so an 'active' port on one switch can successfully form a channel with a 'passive' port on the peer switch. If both ends are 'passive', no negotiation occurs, but an active/passive combination is perfectly valid.

Configure the port as a routed port with no switchport

Why wrong: A routed port assigned with 'no switchport' makes the interface a Layer 3 port that expects an IP address and routes packets rather than forwarding frames in VLANs. This would prevent the switch from applying the access or voice VLAN features, and the attached PC would need its own subnet separate from the phone, requiring a router instead of a simple edge switch. Cisco IP phones use L2 protocols (like CDP for voice VLAN) that only function on switchport interfaces, making a routed port incompatible with the standard phone-plus-PC deployment.

Configure the port as an EtherChannel member

Why wrong: EtherChannel is a link-aggregation technique that combines multiple physical switch ports into one logical interface to increase bandwidth and provide redundancy, typically using LACP or PAgP. It has no effect on how a single access port should segregate IP phone and PC traffic, because the goal here is VLAN membership, not link bundling. Configuring this port as an EtherChannel member would also require a compatible peer on the phone, which is not how Cisco IP phones operate.

Use a native VLAN only and disable all tagging

Why wrong: Using only a native VLAN and disabling all tagging collapses both phone and PC into the same broadcast domain, eliminating the VLAN separation needed for voice QoS and security. The native VLAN is primarily for untagged frames on a trunk, but here there is no trunk; a single port cannot distinguish phone traffic from PC traffic without either a voice VLAN or separate physical switchports. Cisco phones also rely on CDP to receive a voice VLAN assignment, so failing to tag voice frames prevents the phone from implementing its voice VLAN configuration.

Configure interface GigabitEthernet0/1 with 'speed 100' and 'duplex half', then verify the EtherChannel is up.

Why wrong: This is incorrect because it would make both ports use speed 100 and duplex half, but GigabitEthernet0/1 is a GigabitEthernet interface that typically supports 1000 Mbps full duplex. Forcing it to 100/half would degrade performance and may not be supported, and it does not match the intended configuration.

Configure interface GigabitEthernet0/2 with 'speed auto' and 'duplex auto', then verify the EtherChannel is up.

Why wrong: This is incorrect because setting speed and duplex to auto on GigabitEthernet0/2 may result in auto-negotiation settling on a different speed/duplex than the manually configured GigabitEthernet0/1 (speed 1000, duplex full). LACP requires all ports to have identical operational speed and duplex, so auto could cause a mismatch.

Configure interface GigabitEthernet0/2 with 'channel-group 1 mode active' and 'switchport access vlan 100', then verify the EtherChannel is up.

Why wrong: Issuing 'channel-group 1 mode active' does enable LACP on GigabitEthernet0/2, but it does nothing to correct the speed/duplex mismatch with GigabitEthernet0/1. Because LACP compares physical parameters during negotiation, the port will fail to aggregate and remain suspended even though the channel-group is configured. Adding 'switchport access vlan 100' is also unrelated to the problem and may actually introduce a VLAN inconsistency if the peer port is in a different access VLAN.

The EtherChannel always forms because passive mode is preferred.

Why wrong: The term passive means the interface will only answer LACP messages it receives; it will never initiate a negotiation, so it is not a 'preferred' or more willing mode. For an EtherChannel to form, at least one side must be in active mode to send LACP PDUs. If both ends are passive, neither speaker initiates the handshake, so the channel cannot come up regardless of how many links are bundled.

The links automatically become a routed interface.

Why wrong: EtherChannel is purely a Layer 2 link-aggregation mechanism; it aggregates multiple physical links into a single logical port-channel but has no effect on whether the interface is a Layer 3 routed port. LACP negotiation only manages the bundling of physical links, not IP addressing or routing. To make a routed interface, an administrator must manually issue no switchport and assign an IP address, so LACP passive mode never triggers this conversion.

The switches delete the bundle configuration automatically.

Why wrong: The switch does not delete the port-channel or LACP configuration when negotiation fails; the port-channel interface and channel-group commands remain in the running configuration. When LACP cannot form, the physical member ports are simply not added to the logical bundle, but no automatic removal occurs. The administrator must manually change the LACP mode (e.g., to active) or remove the channel-group configuration if the bundle is no longer desired.

The EtherChannel always forms because passive mode is stronger than active mode.

Why wrong: Passive mode is not stronger than active mode; rather, active mode is the initiator that sends LACP PDUs, while passive mode only responds to received PDUs. The terms 'active' and 'passive' describe behavior during negotiation, not link priority or throughput. When both sides are passive, no one initiates, so the channel cannot form despite both supporting LACP.

The link becomes a routed port automatically.

Why wrong: LACP configuration applies to switchport (Layer 2) interfaces and does not automatically change the interface from Layer 2 to Layer 3. A routed port is created by issuing 'no switchport' and assigning an IP address; channel-group membership is independent of that choice. Even if LACP mode is set to active or passive, the interface remains in its current switchport or routed state.

Both switches delete the port-channel configuration.

Why wrong: Configured LACP parameters such as channel-group numbers and mode are stored in the running configuration and remain intact even if the channel fails to come up. Passive mode does not trigger any automatic removal of the port-channel interface or the member interface's channel-group configuration. The configuration persists until an administrator explicitly deletes it with commands like 'no channel-group'.

The switch automatically rewrites the peer configuration to match.

Why wrong: The local switch has no mechanism to modify or rewrite the configuration of a remote peer; LACP only detects and reports incompatibilities via the exchange of LACPDUs. If the remote side is configured differently, the local switch may mark the link as suspended or note a channel misconfiguration, but it cannot push a new configuration to the peer. Configuration changes must be made manually on the remote device to restore channel compatibility.

LACP converts the mismatched link into a routed interface automatically.

Why wrong: LACP is purely a link-aggregation control protocol; it exchanges LACPDUs to bundle physical ports into a single logical link and does not alter the Layer 3 status of an interface. A mismatched link remains a Layer 2 switchport, and it will not become a routed interface because of an EtherChannel inconsistency. To create a routed port, an administrator must explicitly enter interface configuration mode and issue the no switchport command.

The mismatched link is placed in a spanning-tree blocking state.

Why wrong: A mismatched EtherChannel link is not automatically shut down by spanning-tree; STP reacts to network loops and topology changes, not to LACP parameter mismatches. The inconsistent link may be placed into a suspended state by the EtherChannel driver or kept as a standalone non-aggregated link, but STP will still evaluate it based on the active spanning-tree rules. An STP blocking decision is based on bridge IDs and port costs, not on LACP configuration differences.

Each interface must belong to a different VLAN

Why wrong: EtherChannel does not require member interfaces to be in different VLANs; in fact, interfaces in the same access VLAN or configured as trunk ports can be bundled. The mandatory condition is that all interfaces share identical VLAN assignments, including the same native VLAN and allowed VLAN list for trunks. Requiring different VLANs would actually break the channel, because the switch needs to treat the bundle as one consistent logical link for forwarding decisions.

Only odd-numbered switch ports can be bundled

Why wrong: The physical port number of an interface has no bearing on its ability to join an EtherChannel; switches group interfaces based on administrative configuration and hardware capabilities, not on numeric order or parity. Odd-numbered ports are not singled out by any Ethernet or channeling protocol, and mixing odd- and even-numbered ports in the same bundle is perfectly supported. The true eligibility criteria are matching speed, duplex, and VLAN/trunk settings, along with the switch's capacity for channel-group assignments.

Each interface must have a different STP path cost

Why wrong: STP path cost is not a bundling criterion; rather, Spanning Tree Protocol operates on the logical EtherChannel as a whole, computing a combined cost based on aggregated bandwidth. Each physical interface's individual STP cost is irrelevant to channel formation, and demanding different costs would only introduce instability. In fact, interfaces that will form a channel should have consistent STP settings such as portfast and link type to avoid topology changes during negotiation.

LACP always requires one side to use PAgP as a backup.

Why wrong: LACP and PAgP are separate and mutually exclusive link aggregation protocols; LACP is defined by IEEE 802.3ad/802.1AX, while PAgP is a Cisco proprietary protocol. There is no requirement for LACP to have PAgP as a backup, and they cannot run simultaneously on the same port. LACP simply uses Active/Passive modes to negotiate bundles, with no involvement of PAgP.

EtherChannel cannot operate on switch trunks.

Why wrong: EtherChannel fully supports trunk links; in fact, aggregating trunk ports between switches is a common design for increasing bandwidth while preserving VLAN tagging. The IEEE 802.1Q encapsulation on each member interface must be consistent, but trunking does not preclude EtherChannel operation. Therefore, the statement that EtherChannel cannot operate on switch trunks is incorrect.

One switch must disable STP before EtherChannel can form.

Why wrong: Disabling Spanning Tree Protocol is not a prerequisite for EtherChannel formation; in fact, EtherChannel interacts with STP by presenting the bundle as a single logical port, which prevents loops while allowing redundancy. STP remains operational to maintain a loop-free topology at the logical layer. Disabling STP would actually introduce a risk of broadcast storms, so it is never required or recommended.

LACP requires both interfaces to use different channel-group numbers.

Why wrong: The correct requirement is the opposite: all member interfaces that are to join the same EtherChannel bundle must be assigned the identical channel-group number, as well as the same protocol (such as LACP active or passive). If LACP interfaces use different channel-group numbers, they would be treated as separate bundles or remain ungrouped, not as one logical channel. Therefore, a mismatch in channel-group numbers would itself cause the bundle to fail, making this option incorrect as an explanation for a formation issue.

The interfaces must both be configured for PPP.

Why wrong: PPP is a WAN encapsulation protocol used on serial point-to-point links, not on Ethernet switch interfaces. EtherChannel operates by bundling Ethernet links at Layer 2, and the physical layer encapsulation must remain Ethernet. Configuring PPP on a switchport is not a valid or supported operation, and it would not affect the formation of an EtherChannel because the channel negotiates based on LACP or PAgP parameters, not on WAN encapsulations.

The bundle fails because BGP is not enabled on the switch.

Why wrong: BGP is an exterior gateway protocol used to exchange routing information between autonomous systems at Layer 3. EtherChannel is a link aggregation technology that bundles multiple physical Ethernet links into one logical link, and it operates independently of any routing protocol. The channel formation relies on Link Aggregation Control Protocol (LACP) or Port Aggregation Protocol (PAgP) negotiation and link parameters, so BGP being disabled or enabled has no bearing on whether the port channel is established.