EtherChannel and LACP Scenarios

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