CCNA Etherchannel Questions

PAgP is a Cisco proprietary protocol and cannot negotiate with LACP. Even if one side is set to PAgP desirable, the LACP active side will not respond, resulting in no EtherChannel formation.

The 'on' mode creates a static EtherChannel without any negotiation. Since the LACP active side expects LACP PDUs to form the bundle, the static 'on' side will not send or respond to LACP messages, causing a mismatch.

PAgP auto is a passive PAgP mode that waits for a PAgP desirable partner. It cannot negotiate with LACP active because the protocols are incompatible.

Passive mode does not initiate LACP negotiation; it only responds to incoming LACP packets. Active mode is the one that actively sends LACP packets. Therefore, passive mode is not stronger than active mode.

LACP configuration does not change the interface type; it only bundles multiple physical links into a logical EtherChannel. The interface remains a Layer 2 or Layer 3 port based on its configuration, not a routed port automatically.

Passive mode does not cause the switch to delete the port-channel configuration. The configuration remains, but the EtherChannel will not come up because no LACP negotiation occurs.

Uses PAgP mode 'desirable' instead of LACP mode 'active'. Additionally, configuring trunk is unnecessary for a single VLAN access port.

Using 'passive' on both sides would prevent the EtherChannel from forming because neither side sends LACP packets.

Using different channel-group numbers creates separate EtherChannels, not a single bundle. Both interfaces must be in the same channel-group to form one logical link.

EtherChannel does not require interfaces to be in different VLANs; in fact, all member interfaces must have the same VLAN configuration (either all access ports in the same VLAN or all trunk ports with the same allowed VLAN list). Placing interfaces in different VLANs would violate the consistency requirement and prevent bundling.

Port numbering (odd or even) has no bearing on EtherChannel eligibility; any physical ports on a switch can be bundled as long as they meet the configuration consistency requirements. The restriction is based on hardware capabilities, not port numbers.

STP path cost is a per-interface value used by Spanning Tree Protocol to determine the best path to the root bridge; it is not a requirement for EtherChannel bundling. In fact, when interfaces are bundled, STP treats the EtherChannel as a single logical link, and all member interfaces share the same STP state.

The specific factual error is that LACP requires all member interfaces to have identical speed and duplex settings; changing SW2 to 100/half does not match SW1's 1000/full.

The specific factual error is that the trunk must allow all required VLANs; omitting VLAN 30 violates the requirement.

The specific factual error is that the configuration does not match the requirement to allow only VLANs 10, 20, and 30; it allows all VLANs instead.

LACP supports active-active mode where both sides are configured as active, which is a common and valid configuration. The statement that LACP requires exactly one active and one passive side is incorrect; active-passive is just one possible combination.

STP treats the entire EtherChannel as a single logical interface, so it does not block individual member links. STP will only block the port-channel itself if there is a loop, but it does not block all but one interface inside the channel.

EtherChannel is commonly used on trunk ports to increase bandwidth and provide redundancy between switches. There is no restriction that prevents EtherChannel from being used on trunk ports; in fact, it is a best practice for inter-switch links.

LACP requires that all member interfaces in the same port-channel use the same channel-group number. Using different numbers would place them in separate bundles, preventing the intended aggregation.

PPP is a Layer 2 encapsulation used on serial links, not on Ethernet switch ports. EtherChannel on Cisco switches uses Ethernet frames, and PPP is irrelevant to the configuration of port-channels.

BGP is a routing protocol that operates at Layer 3 and is not required for EtherChannel formation. EtherChannel is a Layer 2 technology that bundles physical links into a single logical link, independent of any routing protocol.

Passive mode requires the other side to be active; both passive means no negotiation. Speed/duplex mismatch (100/half vs 1000/full) and VLAN mismatch (20 vs 10) prevent bundling.

The mode 'desirable' is used with Cisco's proprietary PAgP protocol, not with the IEEE standard LACP. Using it would not form an LACP EtherChannel.

Speed/duplex mismatch causes one port to be suspended in the EtherChannel. VLAN mismatch prevents the port-channel from being in up/up state as a Layer 2 bundle.

Assuming that a protocol mismatch might exist without checking the existing configuration first.

Prioritizing a Layer 1 check over a Layer 2 parameter that must be identical for EtherChannel to bundle.

Confusing STP port states with EtherChannel negotiation states.

The ports are already configured with LACP active mode, as indicated by the protocol being LACP and the ports being bundled. Reapplying this command does not address the root cause of intermittent connectivity, which is likely due to VLAN mismatch.

The 'lacp rate fast' command changes the LACP packet transmission rate to every second, which is used for faster failure detection. It does not affect VLAN consistency or cause intermittent connectivity; the issue is likely due to VLAN mismatch, not LACP rate.

The ports are already configured as trunk ports (the Po1 is Layer2 and trunking is implied). Reapplying 'switchport mode trunk' does not address the VLAN inconsistency that causes intermittent connectivity.

The modes 'desirable' and 'auto' are used by PAgP (Cisco proprietary), not LACP. LACP uses 'active' and 'passive' modes for negotiation.

The 'show etherchannel summary' command does not display 'UP' or 'DOWN' in plain text; it uses two-letter codes like SU (Layer 2 up), SD (shutdown), etc. This is a common misinterpretation of the output format.

LACP 'active' mode can form an EtherChannel with either 'active' or 'passive' mode. If both sides are passive, the channel will not form because neither initiates negotiation.

The specific factual error: The port-channel interface must match the Layer2 configuration of member ports; using no switchport creates a Layer3 interface that cannot trunk VLANs. Additionally, passive mode requires an active partner to form the channel.

The specific factual error: Speed and duplex should be consistent across all member links, but the correct resolution is to correct the misconfigured interface (Gi0/2) to match the working one (Gi0/1), not vice versa.

The specific factual error: Access mode cannot carry multiple VLANs; trunk mode is required for VLAN 10. Additionally, desirable is a PAgP keyword, not LACP. LACP uses active or passive.

Active mode sends LACP packets unconditionally; it does not require the peer to be active and will negotiate with a passive peer.

PAgP uses desirable and auto modes, not the LACP active/passive modes; these modes are specific to LACP.

The specific factual error is that 'desirable' is a PAgP mode, not LACP. LACP uses 'active' or 'passive'.

The specific factual error is that LACP requires both ends to be in compatible modes (active-active or active-passive), but on the same switch, both ports should use the same mode for the same channel group.

The specific factual error is that 'channel-group' is a physical interface command, not a port-channel interface command. The port-channel interface is used for logical configuration (e.g., trunking) after the channel is formed.

The specific factual error is assuming that LACP mode must match on both sides; active/passive is acceptable.

The specific factual error is that the solution should aim for optimal performance, not just consistency; using 100/half is technically possible but not the best practice.

The specific factual error is that trunking does not fix speed/duplex mismatches, and the native VLAN must be consistent.

The specific factual error is that 'desirable' is a PAgP mode, not LACP. LACP uses 'active' and 'passive' modes.

The specific factual error is that the problem is physical (speed mismatch), not logical (VLAN/trunking). Changing the port type does not address the root cause.

The specific factual error is that the speed mismatch is the root cause, not the LACP mode. Even with correct modes, the EtherChannel will not form if speeds differ.

LACP does not require both sides to be in active mode; active/passive is a valid combination. The passive side will respond to LACP packets from the active side, forming the bundle.

PAgP is a Cisco proprietary protocol and is not required for LACP. LACP and PAgP are independent; enabling PAgP does not affect LACP negotiation.

EtherChannel, once formed, forwards all VLANs allowed on the trunk or access ports. There is no mechanism in LACP that restricts the bundle to a single VLAN.

Passive mode does not initiate LACP negotiation; it only responds to incoming LACPDUs. Therefore, with both sides passive, no LACPDUs are exchanged, and the EtherChannel will not form. The statement that passive mode is preferred is incorrect; active mode is typically used on at least one side to initiate the channel.

LACP operates at Layer 2 and does not change the interface type. The ports remain switchports (Layer 2) unless explicitly configured with 'no switchport'. LACP mode has no effect on Layer 3 routing functionality.

LACP configuration is not automatically deleted when negotiation fails. The configuration remains in the running-config, and the ports will simply not form an EtherChannel. The administrator must manually remove the configuration if desired.

LACP passive/passive is the pairing that fails to form an EtherChannel because both sides wait for the other to initiate negotiation, resulting in no LACP PDUs being sent. Active/active is a valid and functional combination.

LACP operates at Layer 2 and does not change the interface type; the EtherChannel remains a Layer 2 port-channel unless explicitly configured with 'no switchport' or an IP address. The question does not mention any Layer 3 configuration.

EtherChannel formation does not alter VLAN tagging; if the interfaces are trunk ports, VLAN tags remain intact. The bundle simply aggregates bandwidth while preserving existing VLAN configurations.

LACP and PAgP are incompatible, so the bundle cannot form in PAgP mode when one side uses LACP.

The passive side will respond to LACP negotiations, so both sides participate and the bundle forms.

Switches do not automatically rewrite peer configurations; configuration changes must be made manually or via network automation tools. LACP only negotiates parameters like speed and duplex, not switchport mode or VLAN settings.

LACP operates at Layer 2 and does not change the interface type; a mismatched link remains a Layer 2 interface. Converting to a routed interface requires manual configuration with 'no switchport' command.

This is incorrect because a switchport mode mismatch in an EtherChannel typically causes the link to be suspended or placed into an errdisable state, not into a spanning-tree blocking state. Spanning tree deals with loops, not port-channel parameter mismatches.

The 'I' flag in the show command output indicates the port is in stand-alone mode, not err-disabled. An err-disabled interface would show as 'err-disabled' or have a 'D' flag, and BPDU guard violation would cause the port to be in err-disabled state, not stand-alone.

The show command output shows the port-channel interface as 'SU' (Layer2, in use), meaning it is operational. If the port-channel were down, all member ports would be affected, not just one. The issue is isolated to a single member port.

EtherChannel does not have a MAC address limit; each physical port retains its own MAC address. LACP can bundle up to 16 ports (8 active) without any MAC address exhaustion issue. This is not a realistic failure scenario.

LACP priority is not required for basic negotiation and does not cause a failure to bundle.

Active/active LACP successfully negotiates, so this is not the cause.

Bouncing interfaces is not required to trigger LACP negotiation.

The specific factual error: LACP passive mode does not initiate negotiation; it only responds. For the EtherChannel to form, at least one side must be active.

The specific factual error: The port-channel interface and physical interfaces must have consistent switchport mode configuration. Here, the port-channel is access while physical are trunk, causing a mismatch.

The specific factual error: 'channel-group mode on' creates a static EtherChannel without LACP. The question requires LACP, so this does not meet the requirement.

The specific factual error is that the question implies the correct configuration should use speed 1000 and duplex full, not downgrade to 100/half. Also, LACP requires identical settings, but the goal is to match the higher speed.

The specific factual error is that auto-negotiation does not guarantee matching settings when one side is manually configured. The mismatch would persist.

The specific factual error is that the question explicitly states a speed/duplex mismatch prevents the channel from forming, and this option does not correct that mismatch.

The specific factual error: The problem is a Layer 2/Layer 3 mismatch, not the LACP mode. Active mode is valid and commonly used.

The specific factual error: 'switchport nonegotiate' affects trunk negotiation, not EtherChannel bundling.

The specific factual error: The mode change does not fix the interface type mismatch; the port-channel must be Layer 2 to match the member ports.

LACP allows an active port to form a bundle with a passive port; the passive side simply waits for LACP packets from the active side. Therefore, both sides do not need to be active.

LACP mode does not change the Layer 2 or Layer 3 status of interfaces; it only controls the negotiation of EtherChannel bundling. Interfaces remain as switchports unless explicitly configured as routed ports.

LACP negotiation failure does not automatically delete the port-channel interface or its configuration. The port-channel remains, but the member ports will not bundle and will operate as individual ports.

LACP does not use 'auto' and 'desirable' modes; those are PAgP modes.

The 'show etherchannel summary' command does not display LACP system priority; that is shown via 'show lacp sys-id' or 'show etherchannel detail'.

An EtherChannel can be formed even if member ports use different LACP modes (e.g., active and passive), as long as at least one side is active.

The native VLAN does not have to be VLAN 1; it can be any VLAN as long as both sides of the trunk agree. The requirement for EtherChannel is that the native VLAN must match on both sides, but it does not have to be VLAN 1.

STP priority values do not affect EtherChannel formation; STP operates on the logical port-channel interface after the bundle is formed. EtherChannel requirements focus on physical and protocol compatibility, not spanning-tree parameters.

The output shows individual port statuses (s) and (I), which indicate LACP negotiation states, not speed/duplex mismatches. While speed/duplex mismatches can cause EtherChannel issues, the specific flags in the exhibit point to a bundling problem, not a mismatch.

A Layer 3 port-channel can function correctly if configured properly. The output does not indicate any Layer 2 vs Layer 3 mismatch; the problem is that the member interfaces are not successfully bundling into the logical channel, as shown by the (s) and (I) status flags.

LACP does not require exactly four links; it can form bundles with 2 to 8 active links (and up to 16 total with standby). The exhibit shows only two member ports, which is perfectly valid for an EtherChannel.

The specific factual error is that changing G0/1 to access VLAN 10 would not resolve the mismatch if the intended configuration is trunking. It would only create a different mismatch if the other side expects trunking.

The specific factual error is that dynamic desirable mode does not ensure trunking; it relies on DTP negotiation, which may fail if the other side is set to trunk. Additionally, the VLAN mismatch (access vs trunk) would still prevent EtherChannel formation.

The specific factual error is that the protocol does not affect the requirement for consistent interface configurations. Both LACP and PAgP require identical VLAN and trunk settings on all member ports.

This option is incorrect because both sides do not need to be active. One side active and the other passive is sufficient for LACP negotiation and channel formation.

This option is incorrect because PAgP is a different, Cisco proprietary protocol and does not work alongside LACP. Enabling PAgP does not affect LACP negotiation.

This option is incorrect because configuring one side as active and the other as passive uses LACP negotiation, not a static Port-Channel. Static Port-Channels require manual configuration on both ends without negotiation.

The exhibit shows the ports as suspended, not err-disabled. Spanning-tree loops typically cause err-disable, not suspension.

The port-channel is up (U), so it is not shutdown.

The scenario explicitly states that all interfaces are configured with the same VLAN, so this is not the cause.

The specific factual error: passive mode on both sides will not form an LACP EtherChannel because neither side initiates negotiation; at least one side must be active.

The specific factual error: 'desirable' is a PAgP mode; LACP uses 'active' or 'passive'. Using 'desirable' would not form an LACP EtherChannel.

The specific factual error: the requirement explicitly states 'active mode on both sides', so setting one side to passive violates the requirement, even though the channel might still form.

This option is incorrect because LACP (Link Aggregation Control Protocol) does not require PAgP (Port Aggregation Protocol) as a backup; they are separate protocols. LACP can operate independently without needing PAgP on either side of the EtherChannel.

This option is incorrect because EtherChannel can indeed operate on switch trunks, allowing multiple VLANs to be carried over a single logical link. The issue in the question pertains to LACP configuration mismatches, not trunking capabilities.

This option is incorrect because Spanning Tree Protocol (STP) does not need to be disabled for EtherChannel to form; EtherChannel can operate alongside STP. Disabling STP can lead to network loops and is not a requirement for EtherChannel functionality.

This option is incorrect because the question specifies that LACP is being used, which is incompatible with PAgP. EtherChannel can operate with either LACP or PAgP, but not both simultaneously.

This option is wrong because EtherChannel can form with access ports or trunk ports, and there is no requirement for the interfaces to be routed ports for EtherChannel to function.

EtherChannel can function with as few as two member links; therefore, requiring three or more member links is not a valid reason for the bundle not forming in this scenario.

The specific factual error is that LACP requires all member ports to have identical configurations, and this option does not align with the existing Port-channel configuration.

The specific factual error is that the VLAN allowed list must match across all member ports and the Port-channel interface; omitting VLAN 30 will cause inconsistency.

The specific factual error is that LACP requires consistent switchport mode (access or trunk) across all member ports and the Port-channel interface.

This option is wrong because the STP root bridge ID does not directly affect the formation of an EtherChannel; EtherChannel requires matching port configurations, not spanning tree parameters.

The interface description does not affect the formation of an EtherChannel, as it is merely a label for identification purposes and does not influence Layer 2 connectivity or protocol negotiation.

The ARP timeout value does not affect the formation of a Layer 2 EtherChannel, as EtherChannel operates at Layer 2 and is concerned with port configurations, not Layer 3 settings like ARP.

The command 'show ip ospf neighbor' is used to display OSPF neighbor relationships, which is not directly related to verifying the operational status of a port-channel. This command would not provide information about the port-channel configuration or status.

The command 'show ip route' is used to display the routing table of a device, which does not provide information about the operational status of a port-channel after configuration changes.

The command 'show access-lists' is not relevant for verifying the operational status of a port-channel; it focuses on access control lists rather than link aggregation status.

The specific factual error is that LACP modes must be compatible (active-active or active-passive), but the question states both sides are active, so mode is not the issue.

The specific factual error is that VLAN settings are irrelevant to the physical bundling of ports in an EtherChannel.

The specific factual error is that interface mode is a Layer 2 property unrelated to the physical bundling process.

This option is incorrect because a Layer 2 EtherChannel can indeed carry trunk links, allowing multiple VLANs to be transmitted over the same logical link. The issue with the EtherChannel not forming is more likely related to mismatched negotiation protocols or other configuration errors.

This option is wrong because the channel-group number must be the same on both switches for an EtherChannel to form. Different numbers would prevent the aggregation of the links.

This option is wrong because a Layer 2 EtherChannel can indeed carry trunk links, allowing multiple VLANs to be transmitted over the same link. Therefore, the inability to form the EtherChannel is not due to the mode of the member interfaces.

LACP active mode only enables negotiation, but it does not resolve underlying parameter mismatches. The interfaces must still have consistent speed, duplex, and VLAN configuration.

All member interfaces must have identical speed and duplex settings. Even if VLANs match, speed mismatch will cause the channel to fail.

The port-channel interface is a logical interface that requires its own VLAN configuration. Physical interfaces must have identical VLAN assignments; otherwise, the channel will not form.

Candidates may think that an LACP problem explains a single active link, but a mismatch would cause the entire EtherChannel to fail, not selectively use one member.

Candidates might mistake an idle member for a pruned VLAN, but pruning would not affect all traffic, only the specific VLAN, and it is not related to the load‑balance method shown.

Candidates may associate an idle link with STP blocking, but an EtherChannel bundle presents one logical link to STP. A blocking state on some members only would indicate a serious configuration error, not the load‑balance method shown.

This option is wrong because all member interfaces in an EtherChannel must be configured with the same native VLAN for the bundle to form correctly, not different native VLANs.

This option is wrong because EtherChannel can only form if both ends of the link use the same protocol, either LACP or PAgP, not a mix of both. Mixing protocols will prevent the EtherChannel from establishing.

This option is wrong because different native VLANs do not prevent an EtherChannel from forming; they can still establish a link if other configurations are compatible. The primary issue in this scenario is related to LACP mode mismatches.

This option is incorrect because EtherChannel can use either PAgP or LACP for negotiation, and both protocols can operate independently of each other. The requirement for both sides to use PAgP in desirable mode is not a necessity for EtherChannel to function.

This option is wrong because EtherChannel can be configured on switch ports without needing to convert them to routed ports. Routed ports are not necessary for EtherChannel to function, as it operates at Layer 2.

The show output indicates Layer 2 mode is already active, and trunking isn’t required for bundling. The issue is LACP protocol negotiation, not interface mode.

The Port-channel would still form even with a native VLAN mismatch; it would not be down (SD) and ports would not be stand-alone (I) solely because of VLAN mismatch.

The flags in the output (I, SD) are not consistent with a speed/duplex problem, and the explicit configuration of passive mode on both sides is the known root cause.

EtherChannel load balancing is configurable and can use source/destination IP, MAC, or Layer 4 port, not just MAC addresses.

Only 8 interfaces can be active in a single EtherChannel; the other 8 are in standby mode.

Spanning Tree Protocol runs on the logical port-channel interface, not on each individual physical link within the bundle.

Load-balancing configuration does not influence the bundle state of a port-channel; it only affects frame distribution. The output shows a physical/logical inconsistency, not a hashing algorithm problem.

Candidates may mistakenly think the whole bundle fails if one port is down, but the output clearly states Gi0/1 is operational. The failure is due to Gi0/2's native VLAN mismatch.

A common misconception is that any down or suspended link indicates an STP loop. However, 'show etherchannel detail' presents the explicit reason, and the native VLAN mismatch line directly contradicts this option.

LACP passive is not incompatible with LACP active.

PAgP/LACP mismatch leads to suspended state, not down; the exhibit's (D) indicates the link is not up, which points to LACP negotiation failure rather than protocol mismatch.

LACP negotiation is independent of the access/trunk configuration.