CCNA Switching Network Access Questions

Native VLAN mismatches can cause traffic to leak between VLANs, but they do not prevent a trunk from becoming operational. The output clearly shows the encapsulation type as ISL, not a native VLAN problem.

Candidates might assume a misconfigured mode causes the issue, but the exhibit confirms the port is in trunk mode ('on' mode).

New learners might equate 'not-trunking' with a shutdown state, but 'admin down' is a distinct status. The port is operationally unable to trunk, not manually disabled.

Root Guard prevents a port from becoming a root port, but it does not provide rapid transition to forwarding or protect against accidental switch connections. PortFast and BPDU Guard are needed for those goals.

Loop Guard is used to prevent alternate or root ports from becoming designated in the absence of BPDUs, not to accelerate DHCP or provide rapid transition to forwarding on end-user switchports.

In the blocking state, the port does not participate in STP actively; it only receives BPDUs but does not send them or transition toward forwarding. The question specifies a state that listens for BPDUs and participates in STP, which is the listening state, not blocking.

The learning state populates the MAC address table by learning source MAC addresses from incoming frames, which directly contradicts the question's requirement that the state does not learn MAC addresses. Learning occurs after listening and before forwarding.

The forwarding state both learns MAC addresses and forwards traffic, which violates the condition that the state does not learn MAC addresses. Forwarding is the final state where the port is fully operational.

Root Guard does not cause a port to go into err-disabled state; instead, it places the port into a root-inconsistent state if a superior BPDU is received, blocking traffic but not disabling the port. The question describes an immediate err-disabled state, which is characteristic of BPDU Guard, not Root Guard.

UDLD aggressive mode does not immediately cause an err-disabled state upon connecting a new switch; it detects unidirectional links by sending probes and can put the port into err-disabled state only after a failure is detected, which takes time. The immediate err-disabled state suggests a feature that reacts instantly to BPDUs.

Storm control does not cause a port to go into err-disabled state by default; it typically drops traffic exceeding a threshold or can be configured to shut down the port, but the immediate err-disabled state upon connecting a new switch is not typical for storm control. The scenario points to a feature that reacts to BPDUs, not broadcast storms.

Port security restricts access based on MAC addresses, not VLANs, and the event message explicitly mentions BPDU Guard, not port security. The exhibit shows a spanning-tree BPDU Guard error, not a port security violation.

DHCP snooping does not cause err-disabled state due to BPDU reception; it filters DHCP messages and can disable ports for DHCP attacks, but the exhibit clearly shows a spanning-tree BPDU Guard event.

EtherChannel suspension occurs due to configuration mismatches or link failures, not BPDU reception. The exhibit's syslog message explicitly identifies BPDU Guard, not EtherChannel issues.

The error is adding an unnecessary access VLAN command for the AP port, which is not required and could conflict with existing configuration.

The error is using show vlan instead of show interfaces switchport to verify voice VLAN on a port.

The error is using show interfaces trunk, which is for trunk ports, not for verifying voice VLAN on an access port.

NetFlow is used for traffic monitoring and analysis, while SNMP traps are used for network management notifications. Neither feature affects STP behavior or port state transitions; they do not cause a port to go err-disabled upon receiving a BPDU.

OSPF passive-interface prevents OSPF from sending routing updates on an interface but does not affect STP or port security. EUI-64 is used for IPv6 address generation. Neither feature relates to BPDU handling or err-disable behavior.

WPA3 is a wireless security protocol, and CAPWAP is a control and provisioning protocol for wireless access points. These are entirely unrelated to wired switch port STP behavior and cannot cause a port to go err-disabled due to BPDU reception.

Removing VLAN 10 from the allowed list would break an already functioning VLAN and would not fix VLAN 30.

Both ISL and 802.1Q support multiple VLANs; the problem is not the trunking protocol but the allowed VLAN list.

Changing a trunk port to access mode would terminate the trunk, preventing all VLAN traffic across the link.

IP subnet masks are Layer 3 concepts and do not affect Layer 2 VLAN propagation across a switchport. The issue here is purely Layer 2, related to the switchport mode (access vs. trunk), not IP addressing. VLANs 20 and 30 would still fail regardless of subnet mask configuration.

Routed ports are Layer 3 interfaces used for routing between networks, not for carrying multiple VLANs. The standard method for carrying multiple VLANs between switches is to use a trunk port, which tags frames with VLAN IDs. A routed port would not solve the issue and would break Layer 2 connectivity.

STP (Spanning Tree Protocol) prevents loops by blocking redundant paths, but it does not selectively block specific VLANs based on their VLAN ID. If STP were blocking VLANs 20 and 30, it would be due to a misconfiguration like PVST+ inconsistencies, not by design. The scenario describes a simple access port misconfiguration, not an STP issue.

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.

Loop Guard is applied to non-designated ports (alternate or backup ports), not root ports. When BPDUs stop arriving, the port is placed into a loop-inconsistent state (blocked) to prevent loops, not into forwarding mode.

Root Guard and BPDU Guard have conflicting behaviors: Root Guard allows BPDU processing to detect superior BPDUs, while BPDU Guard disables the port upon receiving any BPDU. They cannot be enabled simultaneously on the same port because their actions are mutually exclusive.

Loop Guard is effective on ports that are in a blocking state (alternate or backup ports), but it does not prevent them from transitioning to forwarding; instead, if BPDUs stop, the port remains in a loop-inconsistent state (blocked) to prevent loops. The statement incorrectly implies that Loop Guard prevents transition, but it actually causes the port to stay blocked.

OSPF authentication is unrelated to switchport security; it protects routing protocol exchanges but does not control physical or MAC-level access on a switchport.

NetFlow is a traffic monitoring tool that provides visibility into network flows but does not enforce any limits on the number of devices connected to a switchport.

NTP is used for time synchronization across network devices and does not provide any mechanism to restrict or control devices connected to a switchport.

Root guard is used to protect the root bridge election by restricting ports that could become root ports, not to speed up edge-port forwarding.

Loop guard prevents alternate or root ports from becoming designated in the absence of BPDUs, which is unrelated to fast forwarding on host-facing ports.

UDLD aggressive mode detects and disables unidirectional links on point-to-point switch links, not for end-device connections.

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.

Converting the trunk to an access port would remove all other VLANs, not solve the selective failure for VLAN 20.

There is no requirement that VLAN 20 must be the native VLAN; the native VLAN is used for untagged traffic and is unrelated to the allowed VLAN list.

The encapsulation type (ISL vs 802.1Q) does not affect per-VLAN allowed lists; the issue is purely about the allowed list configuration.

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.

The root bridge is elected based on the lowest bridge ID, not the highest.

PortFast does not automatically enable BPDU Guard; they must be configured separately.

Rapid PVST+ uses the same root bridge election process (lowest bridge ID) as traditional STP.

OSPFv3 is an IPv6 routing protocol and has no role in Layer 2 voice VLAN handling on access ports. The issue is about VLAN assignment and trunking, not routing protocol adjacency.

The scenario involves wired switches and IP phones, not wireless LAN. Guest SSID configuration on a wireless controller is unrelated to voice VLAN treatment on a wired trunk link.

BGP is an exterior routing protocol used for interdomain routing, not for Layer 2 VLAN handling. The symptom is about voice VLAN treatment on a trunk, which is unrelated to BGP metrics or static routes.

Increasing port bandwidth by combining links is done via EtherChannel, not related to BPDU Guard or loop prevention.

VLAN trunking is automatically negotiated via DTP or manually configured, not triggered by BPDU Guard or PortFast.

Forcing Rapid Spanning Tree Protocol is not a function of PortFast or BPDU Guard; they are separate STP optimizations.

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.

'no switchport' creates a routed port, which cannot handle VLANs for an IP phone and PC.

Trunk mode is for inter-switch links, not for end devices; access mode is required.

'power inline never' disables PoE, but the IP phone needs power from the switch.

This statement is incorrect because voice and data VLANs are independent on a switchport configured with separate VLANs. The phone successfully registering on the voice VLAN does not guarantee that the data VLAN is correctly configured; the PC could still be assigned to a different VLAN or subnet due to misconfiguration.

CAPWAP (Control and Provisioning of Wireless Access Points) is a protocol used for wireless LAN controller and access point communication, not for wired switchport configuration. The scenario describes a wired phone and PC sharing a switchport, which is unrelated to wireless controllers.

The phone's successful registration does not rule out DHCP issues for the PC. The PC could be receiving an IP address from a DHCP server that is on the wrong subnet or VLAN, or the DHCP relay might be misconfigured for the data VLAN. The phone's DHCP success is independent of the PC's DHCP process.

Candidates might associate VLAN support with trunk encapsulation types, but ISL fully supports VLAN 40. This is a distractor.

This is a common operational mistake, but the resulting output would show VLAN 40 missing from the 'Vlans allowed' column, not from the forwarding list.

Candidates might confuse local pruning (due to non-existent VLAN) with VTP pruning. VTP pruning would also require a multi-switch VTP domain and is less likely in a standalone troubleshooting scenario.

IP addresses for multiple VLANs are configured on subinterfaces, not directly on the physical interface.

Inter-VLAN routing requires a router; the switch does not route between VLANs internally in a router-on-a-stick design.

Serial encapsulation is used for WAN serial links, not for VLAN tagging on Ethernet interfaces.

EtherChannel is used to aggregate multiple physical links into a single logical link for increased bandwidth and redundancy, not to limit MAC address learning on a single port. It does not provide any mechanism to restrict the number of MAC addresses learned on a switchport.

OSPF passive-interface is a routing protocol feature used to prevent OSPF from sending hello messages on an interface, typically used on interfaces that do not have OSPF neighbors. It has no effect on MAC address learning or switchport security.

Native VLAN is a concept used on trunk ports to specify the VLAN that carries untagged traffic. It does not control MAC address learning or limit the number of MAC addresses on a switchport.

In a controller-based WLAN, the access point is a lightweight device that relies on the wireless LAN controller (WLC) for management, control, and data forwarding decisions. The AP cannot replace the controller because it lacks the necessary intelligence and processing power to perform controller functions such as RF management, client authentication, and mobility services.

The access point does not act as a default gateway for wired VLANs. Default gateway functionality is provided by routers or Layer 3 switches that route traffic between different subnets. The AP's role is limited to wireless access and forwarding client traffic to the wired network, typically through the controller or directly to the switch.

OSPF route summarization is a routing protocol function performed by routers or Layer 3 switches, not by access points. APs are not involved in routing protocol operations; they focus on wireless connectivity and may forward traffic to the controller or wired network without participating in dynamic routing.

Converting all access ports to trunks is unnecessary and incorrect because host-facing ports should remain access ports assigned to a single VLAN. Trunks are used to carry multiple VLANs between switches, not to connect end hosts. This change would not enable inter-VLAN routing.

Making both VLANs use the same IP subnet would break the fundamental purpose of VLANs, which is to separate broadcast domains and logically segment the network. Hosts in different VLANs must be in different subnets for proper routing; otherwise, they would expect to communicate directly at Layer 2, which is not possible across VLANs.

Disabling Spanning Tree Protocol (STP) on both VLANs would not enable inter-VLAN routing; it would only risk creating Layer 2 loops and broadcast storms. STP is a loop-prevention mechanism and has no role in Layer 3 routing between VLANs.

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.

A trunk port is designed to carry traffic for multiple VLANs between switches, not for a single end host. Using switchport mode trunk on an access port would allow multiple VLANs and enable trunk negotiation, violating the requirement.

The dynamic desirable mode actively attempts to form a trunk with the connected device using DTP. This allows trunk negotiation, which contradicts the requirement to not negotiate trunking and to forward traffic for only one VLAN.

The no switchport command converts the Layer 2 switch port into a Layer 3 routed port, which does not operate as a switch port and cannot be assigned to a VLAN. This is used for routing between VLANs, not for connecting an end host to a single VLAN.

802.1Q is an open IEEE standard. Cisco-proprietary trunking is Inter-Switch Link (ISL).

Layer 2 switches cannot route between VLANs. Inter-VLAN routing requires a Layer 3 device such as a router or a Layer 3 switch with SVIs.

Trunk ports forward tagged frames so the receiving switch can distinguish VLANs. Removing tags from all frames would defeat the purpose of trunking.

Incorrect because the client already successfully joins and authenticates to the SSID, so SSID visibility is not the issue.

Incorrect because BGP autonomous system numbers relate to routing protocols and have no impact on wireless client roaming or connectivity.

Incorrect because ACL wildcard masks affect packet filtering rules and do not influence wireless roaming or client mobility between access points.

The absence of a speed command on the access port does not prevent VLAN forwarding or connectivity to the default gateway. Speed settings affect physical link parameters but not VLAN membership or Layer 2 forwarding.

VTP transparent mode controls VLAN propagation between switches but does not affect whether a VLAN exists locally. Missing VLANs must be created manually regardless of VTP mode.

DTP desirable mode is used to negotiate trunk links and is irrelevant for access ports, which do not trunk and only carry untagged frames for a single VLAN.

The command 'switchport trunk allowed vlan 30' is used on trunk ports to specify which VLANs are allowed to traverse the trunk link. It does not assign a VLAN to an access port; instead, it filters VLANs on a trunk, which is not appropriate for a port connected to a single PC.

The command 'encapsulation dot1Q 30' is used on a router subinterface to enable 802.1Q trunking and specify the VLAN for that subinterface. It is not a valid command on a switch access port, and switch ports do not use encapsulation commands for VLAN assignment.

The command 'ip helper-address 30' is used to configure DHCP relay on a router or Layer 3 switch interface, forwarding DHCP broadcasts to a DHCP server. It has nothing to do with VLAN assignment on a switch port.

The exhibit shows both switches have native VLAN 1 configured, so there is no mismatch. A native VLAN mismatch would cause all VLAN traffic to fail or be misdirected, not just a single VLAN.

Since other VLANs are working across the same trunk, the trunk encapsulation (802.1Q) is functioning correctly. Changing to ISL would not fix the issue and would break connectivity for all VLANs.

A VLAN does not need to be the native VLAN to traverse a trunk; native VLAN is only for untagged traffic. Making VLAN 30 the native VLAN would not solve the problem and could introduce other issues.

The 'root primary' command does not guarantee root status if another switch has a priority lower than 24576. The question expects manual recovery, not automatic.

Priority 0 is not incorrect but is not the standard recommendation. The recovery method is wrong: disabling BPDU Guard does not clear the err-disabled state.

The command 'clear spanning-tree detected-protocols' does not clear the err-disabled state; it only resets the port's protocol state.

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 is using 'switchport mode trunk' instead of 'switchport mode access'. Access ports are used for end devices like IP phones and APs, not trunks.

The specific factual error is using 'power inline never' which disables PoE. The correct command to enable PoE is 'power inline auto'.

The specific factual error is reversing the VLAN assignments: 'switchport access vlan 110' and 'switchport voice vlan 10' instead of the correct order.

Common misconception: the warning message implies a VLAN is not allowed, but native VLAN mismatch means the trunk ports disagree on the native VLAN, not that a VLAN is missing from the allowed list.

Over‑reaction: candidates might think a trunk problem requires eliminating the trunk, but the correct approach is to correct the native VLAN parameter on the existing trunk.

Wrong feature: PortFast addresses access port convergence, not VLAN mismatches. Candidates may reach for any familiar command, but it targets the wrong layer and port type.

ARP operates at Layer 2 (Data Link layer) and is used to resolve IP addresses to MAC addresses. A lack of ARP replies indicates a Layer 2 connectivity issue, such as a misconfigured VLAN, incorrect cabling, or a switch port problem, not a Layer 3 routing issue.

ICMP echo requests without replies typically indicate a Layer 3 issue, such as no route back to the source, or a firewall blocking the replies. Layer 2 loops cause broadcast storms, duplicate frames, and MAC address flapping, not a simple lack of ICMP replies.

TCP SYN packets without SYN-ACK replies often indicate a firewall blocking the connection, a service not listening on the destination port, or a Layer 4-7 issue. Layer 1 physical issues would typically result in no packets being received at all, not just missing SYN-ACKs.

Disabling STP globally removes all loop protection, which is not desired because loop protection elsewhere is still needed.

Changing the trunk native VLAN does not affect STP port state transitions and is irrelevant for an access port.

Setting the port to half-duplex has no impact on STP listening/learning timers and would not speed up host access.

A native VLAN mismatch does not convert tagged traffic into routed traffic. Tagged frames continue to be switched based on their VLAN tags, and the trunk remains a Layer 2 link. The mismatch only affects untagged frames on the native VLAN.

A native VLAN mismatch is a Layer 2 trunking issue and does not directly affect OSPF or any routing protocol. OSPF adjacency is a Layer 3 process and would only be impacted if the mismatch caused connectivity loss for the router interfaces, but the mismatch itself does not force OSPF adjacency resets.

A native VLAN mismatch does not prevent the trunk from carrying other tagged VLANs. Tagged frames for other VLANs are still forwarded correctly because they are not affected by the native VLAN configuration. The trunk can carry multiple VLANs, but the native VLAN traffic is misdirected.

Spanning Tree Protocol (STP) can block a VLAN if there is a loop, but the output shows VLAN 40 is active in the management domain and not listed as blocked. The explicit absence of VLAN 40 from the allowed VLAN list is the direct cause, not STP.

The native VLAN is only for untagged traffic on an 802.1Q trunk. All other VLANs are tagged and can cross the trunk regardless of the native VLAN. VLAN 40 is not the native VLAN, but that does not prevent it from being carried if permitted.

802.1Q has no limit of three VLANs per trunk; it can support up to 4094 VLANs. The output shows only three VLANs allowed because of configuration, not a protocol limitation.

DHCP snooping is a security feature that filters DHCP messages and does not affect Layer 3 routing between VLANs. Disabling it would not enable inter-VLAN communication. The issue is routing, not DHCP.

Removing all VLAN assignments would break the network entirely, as hosts would lose their VLAN membership and connectivity. VLANs are essential for segmenting the network; removing them would not solve the routing issue.

The specific factual error: 'spanning-tree portfast bpduguard default' enables BPDU guard, not recovery. Recovery requires 'errdisable recovery cause bpduguard'.

The specific factual error: Using 'cause all' is not the best practice; the question implies a specific cause. Also, the verification command is correct but the configuration is not precise.

The specific factual error: errdisable recovery is a global configuration command, not interface-specific.

PortFast does not filter BPDUs; it still processes them normally. If a BPDU is received on a PortFast port, the port will still participate in STP and may transition to a blocking state, defeating the purpose of PortFast. The statement incorrectly claims BPDUs pass through while the port remains forwarding, which is not true.

BPDU Guard does not affect STP election processes; it simply err-disables the port upon receiving any BPDU. It does not ignore superior BPDUs or prevent the port from becoming a root or designated port. That behavior is associated with Root Guard, not BPDU Guard.

BPDU Guard is intended for access ports with PortFast, not for trunk ports. Trunk ports between switches are expected to exchange BPDUs for normal STP operation; applying BPDU Guard on a trunk would cause the port to err-disable upon receiving legitimate BPDUs, disrupting the network.

A routed port (no switchport) is used for Layer 3 routing between switches or routers, not for connecting end devices like IP phones and PCs. It does not support VLAN assignment or the coexistence of multiple VLANs on a single port, making it unsuitable for this scenario.

EtherChannel is used to aggregate multiple physical links into a single logical link for increased bandwidth and redundancy. It does not provide any mechanism to separate voice and data traffic into different VLANs on a single port, and it is not relevant to the requirement of connecting an IP phone and PC.

Using a native VLAN only and disabling all tagging would place all traffic (voice and data) in the same VLAN, which contradicts the requirement to separate voice into VLAN 200 and data into VLAN 20. The native VLAN is used for untagged traffic on a trunk, but this design requires distinct VLANs with tagging for voice.

BPDU Guard is a protective feature that disables a port upon receiving a BPDU, not upon losing BPDUs. The symptom here is a loss of BPDUs, not a reception of unexpected BPDUs.

UDLD acts by shutting down the port or putting it in errdisable state, while the scenario explicitly shows the port in a loop-inconsistent state, indicating an STP-based protection mechanism.

Root Guard would block a port if it received a BPDU with better root information, not when BPDUs stop arriving. It also does not produce a loop-inconsistent state.

Trunk ports are not appropriate for end devices; they are designed for inter-switch links.

The question does not require creating or naming VLANs; it only asks to assign ports to existing VLANs.

The 'switchport mode access' command is required to explicitly set the port as an access port; otherwise, the port might negotiate trunking.

Root Guard blocks the port upon receiving a superior BPDU, not forwards. Loop Guard transitions to blocking only after BPDU loss, not while BPDUs are still received.

Root Guard results in a blocking state, not err-disable. BPDU Guard results in err-disable, not blocking.

Loop Guard does not immediately place the port in loop-inconsistent state; it only does so after BPDU loss. Here, BPDUs are still being received.

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.

Candidates often confuse port-level issues with VLAN-level states. Port security violations would result in an err-disable status, which is not reflected in the VLAN status column; the VLAN would still show 'active' if it were enabled.

Candidates may mistake the VLAN shutdown for an SVI shutdown because both involve the 'shutdown' keyword. However, the SVI state would appear in 'show ip interface brief' or 'show interface vlan 30', not here.

Candidates often attribute connectivity loss to STP blocking, which is a common cause of forwarding issues. However, this exhibit’s specific clue is the 'act/lshut' flag, directing attention to the VLAN administrative state.

This answer assumes STP is off entirely, but the presence of BPDU guard configuration indicates spanning tree is operational.

Candidates often assume that BPDU guard simply failed, overlooking the interaction with BPDU filter, which can neutralize guard by suppressing BPDUs.

Root guard is a different feature and not related to the suppression of BPDUs that would allow a loop to form undetected.

CAPWAP is a control protocol for AP-WLC communication, not a client SSID—an SSID is the network name that clients see and associate with.

CAPWAP is not a security replacement; WPA2 and WPA3 are wireless security standards, whereas CAPWAP tunnels traffic between AP and WLC.

CAPWAP supports both IPv4 and IPv6 transport; it is not limited to IPv4 ACL filtering.

By default, frames belonging to the native VLAN (VLAN 1) traverse a trunk link without an 802.1Q tag.

Trunk ports differentiate frames from multiple VLANs using VLAN tags, permitting concurrent forwarding for all allowed VLANs.

Cisco switches allow administrators to assign any active VLAN as the native VLAN for a trunk port.

Root Guard is designed to block a port that receives superior BPDUs, which is exactly what happened. The configuration is correct and should not be removed.

BPDU Guard is correctly configured; the err-disable is expected behavior when a BPDU is received on a PortFast port. The solution is to re-enable the port and ensure the host is not a switch.

BPDU Filter is not a substitute for BPDU Guard; it prevents the port from sending or receiving BPDUs, which can cause bridging loops. The correct action is to re-enable the port, not change the protection mechanism.

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.