CCNA Switching Network Access Questions

A trunk port does not provide the voice VLAN advertisement mechanism to the phone; the PC would need to send tagged frames, which typical endpoint NICs do not do.

The phone requires access to VLAN 20 for voice services, and the PC must remain in VLAN 10 for data; this configuration does the opposite, failing to meet the requirement.

The phone still cannot learn the voice VLAN; port security does not provide a DHCP address or make the switch advertise VLAN 20 to the phone.

Candidates mistakenly equate BPDU Guard with any BPDU-induced blocking, but the state 'root-inconsistent' is specific to Root Guard.

Candidates may think that filtering BPDUs leads to port isolation, but BPDU Filter would not trigger a protective state like root-inconsistent.

Candidates often confuse Loop Guard and Root Guard because both can cause inconsistent states, but Loop Guard triggers loop-inconsistent, not root-inconsistent, and is triggered by BPDU loss, not receipt of superior BPDUs.

The switchport mode trunk setting is incorrect because a trunk port allows multiple VLANs to pass, while the question indicates that the PC should only receive broadcasts from VLAN 20. Therefore, the issue lies with the access VLAN configuration.

The speed setting of 1000 Mbps (1 Gbps) does not influence VLAN membership or broadcast traffic; it only affects the data transfer rate. Therefore, this option does not address the issue of the PC receiving broadcasts only from VLAN 1.

The duplex setting of the switch port does not influence VLAN membership or broadcast traffic. Therefore, a duplex configuration of 'full' does not affect the ability of a PC to receive broadcasts from VLAN 20.

Candidates often associate BPDU Guard exclusively with access ports and assume configuring it on a trunk is itself a misconfiguration, overlooking that PortFast is the real culprit.

Students may confuse root bridge placement with BPDU Guard operation, thinking that a BPDU from a superior switch might cause a port to be disabled, when in fact BPDU Guard is content-agnostic.

Candidates may think that because a link between switches should be a trunk, the access mode misconfiguration is the root cause. However, they miss the fact that BPDU Guard acts on the BPDU regardless of the port mode, and the real misconfiguration is PortFast.

Fa0/1 is connected to VLAN 10, and since the user in VLAN 20 cannot reach the distribution switch, checking this port would not address the issue, as it is not part of the user's VLAN.

Fa0/2 is connected to VLAN 10, which means it cannot facilitate communication for a user in VLAN 20. The issue lies with the trunk port, which is responsible for carrying multiple VLANs, including VLAN 20.

Option D is incorrect because it suggests checking any access port in VLAN 1, which is not relevant to the user's issue in VLAN 20. The problem lies with the trunk port not allowing VLAN 20 traffic, not with access ports in VLAN 1.

Incorrect. Allowing a VLAN on a trunk does not disable it; this option contradicts how VLANs and trunks operate in Cisco switches.

Incorrect. Port Address Translation (PAT) is unrelated to VLAN trunking. VLANs do not require PAT to cross trunks.

Incorrect. VLAN 99 does not have to be the native VLAN to function on a trunk. The native VLAN is independent of VLAN allowance and operation.

The specific factual error is that BPDU Guard should not be disabled on a port that is supposed to be an edge port with BPDU Guard enabled.

The specific factual error is that simply re-enabling the same features does not prevent recurrence; the source of BPDUs must be removed or the port must be reconfigured as a non-edge port.

The specific factual error is that Root Guard and BPDU Guard serve different purposes; Root Guard does not stop BPDU Guard from disabling the port.

A user PC does not require EtherChannel to function; EtherChannel is a method for bundling multiple physical links into a single logical link, which is not necessary for standard PC connectivity.

Trunk mode does not disable MAC address learning; it actually allows the switch to learn MAC addresses from multiple VLANs. Therefore, a switch port configured as a trunk can still learn MAC addresses normally.

Trunk mode does not disable IP addressing; it allows multiple VLANs to be carried over a single link, and IP addressing is still applicable to the switch interfaces. Therefore, the user PC's inability to communicate is not due to trunk mode disabling IP addressing.

The err-disabled state requires a manual interface reset (shutdown followed by no shutdown) to recover; a single 'no shutdown' command is insufficient.

Saving the configuration preserves the settings but does not affect the current operational state of the interface; the port stays err-disabled.

The shutdown command disables the interface but does not automatically re-enable it; the err-disabled state is cleared only after a shutdown/no shutdown cycle.

NetFlow export is related to network traffic analysis and monitoring, not directly to client movement or experience between access points in a WLAN. It does not address the seamless connectivity aspect of roaming.

DHCP snooping is a security feature that helps prevent unauthorized DHCP servers from distributing IP addresses on a network. It does not directly relate to the user experience of roaming between access points in a WLAN deployment.

Route summarization is a technique used in routing protocols to reduce the size of routing tables by aggregating multiple routes into a single route. It does not pertain to client movement or wireless connectivity between access points.

VLAN 99 is not the default VLAN for switch ports on a new Cisco switch; the default is VLAN 1. VLAN 99 is often used in specific configurations but is not the factory default setting.

VLAN 1002 is a reserved VLAN for Token Ring and FDDI, and it is not the default VLAN for switch ports on a new Cisco switch. Most switch ports default to VLAN 1 unless configured otherwise.

This option is incorrect because, by default, Cisco switches assign all ports to VLAN 1, not leaving them unassigned. Every port is part of VLAN 1 unless configured otherwise.

Option B is incorrect because sticky MAC learning does not disable the maximum secure MAC limit; it simply allows the switch to learn and retain the MAC address within that limit. The maximum secure MAC count remains enforced regardless of sticky learning.

Sticky learning does not automatically save the running configuration; it only adds the learned MAC to the running configuration, which must be explicitly saved to the startup configuration to persist across reboots.

This option is incorrect because sticky MAC learning does not prevent security violations; it only allows the learned MAC address to be retained across reboots if saved. A security violation can still occur if an unauthorized MAC address is detected on the port.

Trunk mode is incompatible because the phone expects an access port, and the voice VLAN is tagged internally by the phone, not by switch port trunking.

Configuring an access VLAN is not mandatory for voice VLAN; the question targets only the commands unique to enabling the voice feature.

Limiting the port to one MAC address would block the PC's MAC, breaking dual-device support provided by the phone's internal switch.

This option is incorrect because using nonoverlapping channels does not impact the Power over Ethernet (PoE) budget for access points; PoE budget is determined by the power supply and the devices connected, not by channel selection.

This option is incorrect because using nonoverlapping channels does not eliminate the need for authentication in wireless networks; authentication is a separate security measure that ensures only authorized users can connect.

This option is wrong because using nonoverlapping channels does not force clients to operate exclusively on the 5 GHz band; it simply allows for better channel management to reduce interference. Clients can still connect on both 2.4 GHz and 5 GHz bands based on their capabilities and network configuration.

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.

The specific factual error: 'root primary' sets priority to 24576, not 4096. Also, err-disabled recovery requires a shutdown followed by no shutdown.

The specific factual error: err-disabled recovery requires a shutdown before no shutdown. 'show interfaces status' does not display STP port roles.

The specific factual error: 'show running-config' does not display STP port roles or blocking status.

Routing protocols like OSPF or EIGRP are not required for directly connected SVIs; only 'ip routing' is needed to enable Layer 3 routing.

Assigning IP addresses to physical interfaces would convert them to routed ports, breaking the existing Layer 2 VLAN configuration and is not the correct approach.

Using an external router with router-on-a-stick would enable inter-VLAN routing but does not enable routing on SW1 as required.

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.

An access port cannot negotiate trunking; it simply forwards only one VLAN's traffic.

Broadcast storms are not caused by an access port misconfiguration.

The native VLAN is sent untagged to maintain backward compatibility with devices that do not understand 802.1Q tagging.

The command to restrict allowed VLANs is switchport trunk allowed vlan, not the native VLAN command.

To see IP addresses on subinterfaces, use show ip interface brief or show running-config on the router.

This option is wrong because the spelling of the SSID does not affect the ability to roam between access points; the user is already connected to the SSID and can access internal resources.

This option is wrong because PPP (Point-to-Point Protocol) is not directly related to VoIP performance or roaming issues; it primarily pertains to WAN connections rather than local Wi-Fi network transitions.

This option is wrong because the issue described pertains to roaming and VoIP call quality, which is unrelated to static routing configurations on the user's phone. A static default route would not directly impact the ability to maintain VoIP calls while transitioning between access points.

This option is incorrect because PortFast does not enable access ports to participate in OSPF; OSPF is a routing protocol that requires Layer 3 interfaces, while PortFast is a feature for Layer 2 switch ports.

This option is wrong because PortFast does not convert access ports into trunk ports; it is designed to bypass the Spanning Tree Protocol (STP) listening and learning states to allow end devices to connect more quickly.

Disabling Ethernet addressing on PCs is not related to the function of PortFast, which is designed to expedite the transition of switch ports to the forwarding state. PortFast does not alter how Ethernet addressing operates on connected devices.

Cisco best practice for IP phone + PC is an access port with switchport voice vlan, not trunk mode. Trunk mode is more complex and can cause VLAN hopping if misconfigured.

Portfast enables faster convergence, not a blocking action. A blocked port would show no link or constant amber LED, not intermittent connectivity.

Even if VLAN 10 were wrong, the phone’s registration issue would persist because the voice VLAN is still missing. The problem has two symptoms; the voice VLAN omission explains both.

EtherChannel is used to aggregate multiple physical links into a single logical link for increased bandwidth and redundancy, but it does not inherently separate voice and data traffic on a single port. It does not address the requirement of managing different traffic types on the same physical connection.

The Native VLAN is used for untagged traffic on a trunk link and does not separate voice and data traffic effectively; it simply allows untagged frames to pass through without any differentiation.

Loop guard is designed to prevent loops in a switched network by blocking ports that receive unexpected BPDUs. It does not facilitate the separation of voice and data traffic on a single physical connection, which is the requirement of the question.

Switch priority values affect STP root bridge election, not EtherChannel formation. EtherChannel negotiation depends on the channel-group mode (LACP, PAgP, or on), not on switch priority.

EtherChannel does not require native VLAN to be VLAN 1; it can form with any native VLAN as long as both sides match. The issue here is the LACP mode mismatch (active vs. on), not the native VLAN.

EtherChannel does not require interfaces to be in different VLANs; in fact, all interfaces in a bundle must belong to the same VLAN or be configured as trunk ports with the same allowed VLAN list. Option D is incorrect because bundling interfaces in different VLANs would cause a mismatch.

This option is wrong because a native VLAN mismatch would typically affect all VLANs, not just VLAN 50. Since other VLANs are functioning correctly, it indicates that the native VLAN configuration is not the issue.

802.1Q is a standard that can carry VLANs up to 4096, including VLAN 50. Therefore, the issue of VLAN 50 not communicating is not due to the protocol's inability to carry it.

This option is wrong because VLAN 50 can exist on a trunk without being the native VLAN; it does not need to be configured as such to communicate across the trunk link.

The specific factual error is confusing the allowed VLAN list with the native VLAN configuration. The native VLAN is set with 'switchport trunk native vlan', not 'switchport trunk allowed vlan'.

The specific factual error is including extra steps that are not needed. The trunk already exists, so 'switchport mode trunk' is redundant. Creating VLAN 99 is also unnecessary if it already exists or is not required for the native VLAN change.

The specific factual error is using the wrong verification command. 'show interfaces trunk' is needed to see trunk parameters including native VLAN.

The specific factual error: Root Guard is applied to designated ports, not root ports. BPDU Guard does not auto-recover by default.

The specific factual error: Loop Guard is not restricted to root ports; it can be used on any port where BPDUs are expected. BPDU Guard results in err-disable, not blocking.

The specific factual error: BPDU Guard is not limited to access ports; it works on any PortFast-enabled port. The state is err-disable, not root-inconsistent.

Guest WLANs can use IP routing; they are just restricted by policy.

Inter-VLAN routing is not inherently disabled; it is a configurable policy.

SSIDs do not automatically trigger firewall rules; the assigned VLAN determines the policy.

Issuing only 'no shutdown' will not recover an interface from the err-disabled state caused by BPDU Guard; it must be administratively shut down first with 'shutdown', then re-enabled with 'no shutdown'.

The verification step checks Root Guard on Gi1/0/1 and Loop Guard on Gi1/0/2, which is the original incorrect configuration before the swap; after the fix, Root Guard should be on Gi1/0/2 and Loop Guard on Gi1/0/1.

The verification step incorrectly states that Loop Guard is active on Gi1/0/2. After swapping the configurations, Loop Guard is now on Gi1/0/1, not Gi1/0/2, so this option validates the wrong port.

This option is incorrect because Gi0/1 is configured as a trunk port, not an access port, and it is actively trunking VLANs. Access ports do not participate in VLAN tagging and would not show trunking status.

This option is incorrect because Gi0/2 is set to 'auto' for trunking, meaning it is not forced into trunk mode but is instead waiting for Dynamic Trunking Protocol (DTP) negotiation to determine if it should become a trunk port.

This option is incorrect because Gi0/1 is configured as a trunk port and can carry tagged traffic, while Gi0/2 is in a state waiting for DTP negotiation, which means it can potentially become a trunk port as well.

BPDU Guard is designed to be enabled on access ports to protect against unauthorized switches, so disabling it on all access ports would defeat its purpose.

Root Guard prevents a port from becoming the root bridge, but does not block BPDU reception that causes err-disable with BPDU Guard.

Loop Guard detects and prevents loops on blocked ports due to unidirectional links, not related to the BPDU Guard err-disable mechanism.

This option is wrong because a native VLAN mismatch would typically affect all VLANs across the trunk, not just VLAN 30. In this scenario, only VLAN 30 is experiencing connectivity issues, indicating a different problem.

This option is wrong because configuring VLAN 30 as the native VLAN does not directly affect the ability of PCs in VLAN 30 on SwitchA to communicate with servers in VLAN 30 on SwitchB, especially if VLAN 30 is already properly configured on both switches.

SwitchB using ISL instead of 802.1Q is not relevant to the connectivity issue between VLAN 30 on SwitchA and SwitchB. The problem is likely due to VLAN 30 not being allowed on the trunk, not the encapsulation method used.

This option is wrong because good design thinking for guest access requires implementing security measures to protect the network and its resources, even for guests. Completely avoiding security compromises the network's integrity and exposes it to potential threats.

This option is wrong because guest WLANs should have distinct permissions to ensure that guests do not have access to sensitive internal resources, which could lead to security breaches.

This option is wrong because guest access typically requires controller coordination to manage policies, monitoring, and security effectively, ensuring that guest traffic is properly segmented and controlled.

Switches do not automatically convert an access port to a trunk; manual configuration is required.

An access port remains a Layer 2 interface; it does not become a routed Layer 3 interface.

VLANs operate at Layer 2 and are not automatically summarized into a single prefix; that would be a routing function.

This option is wrong because a port configured with PortFast and BPDU Guard will not automatically become the root port when it receives BPDUs; instead, it will be error-disabled due to BPDU Guard's protection mechanism.

This option is wrong because a port configured with PortFast does not automatically convert to a trunk port when it receives BPDUs; instead, it remains in access mode. BPDU Guard will cause the port to be error-disabled upon receiving BPDUs, preventing any trunking behavior.

This option is wrong because PortFast does not disable Spanning Tree Protocol (STP) entirely; it merely allows the port to transition to the forwarding state immediately without participating in STP calculations. BPDUs are still processed, and BPDU Guard will take action if they are received.

Candidates may overlook the explicit mention that the SVIs are up/up, mistakenly thinking a shut SVI could be the problem.

Trunk misconfiguration is a common inter-VLAN issue, but the scenario explicitly says the trunks are working properly, making this answer invalid.

The successful ping to the default gateway proves the gateway is correct. Without 'ip routing', the switch can't forward packets from VLAN 10 to VLAN 20, but it can respond to local VLAN requests.

The native VLAN mismatch is not resolved; the switch likely uses native VLAN 1, so R1 should also use 1 or both sides must be configured consistently.

IP routing is disabled by default on Cisco routers; it must be explicitly enabled for the router to perform routing functions.

Two errors: native VLAN mismatch persists and IP routing is disabled, so packets cannot be routed between VLANs.

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.

This option is wrong because the question specifies that the PC cannot reach the default gateway due to VLAN issues, not because of port security settings. Port security would typically result in the interface being in an error-disabled state, which is not indicated here.

This option is incorrect because converting the port to a trunk would not resolve the issue of the PC not reaching the default gateway if VLAN 20 is not configured or active. The problem lies in the VLAN configuration, not the port type.

This option is incorrect because the default gateway is typically configured on the device (e.g., a router or PC) rather than on the switch port itself. The issue in the question pertains to VLAN configuration, not gateway settings.

The specific factual error: 'restrict' does not disable the port; it only filters traffic and logs the violation, but the port remains operational.

The specific factual error: 'protect' silently drops unauthorized traffic without logging or disabling the port.

The specific factual error: PortFast is required to bypass STP convergence; without it, the port will wait for STP to transition, causing delay.

Misunderstanding that DAI controls DHCP traffic rather than ARP packets.

Assuming DHCP snooping introduces routing changes or that the server is on a different subnet.

Confusing DHCP snooping with DHCP relay agent functionality and option 82 insertion.

Using a trunk port for a single device connection is unnecessary and violates standard access port design; it would also require the phone to support trunking, which is not the typical Cisco IP phone configuration.

STP does not introduce significant delays in normal operation, and disabling it risks broadcast storms and network loops.

Access ports operate at Layer 2; converting to a routed port would prevent the phone and PC from communicating within their respective VLANs.

Candidates may think that STP version incompatibility disrupts root election, but both versions use the same BPDU format and root election rules.

Candidates often associate Root Guard with preventing a switch from becoming the root. However, it does not cause another switch to become root; it just protects the network from unexpected superior BPDUs.

Candidates may confuse the symptom and think that a low priority on the new switch causes the problem, but this would make the new switch the root, not another switch.

The native VLAN setting only governs untagged traffic on the trunk, not the tagged frames of VLAN 30, so it cannot fix a missing allowed VLAN.

STP does not globally block all VLANs on a trunk; per‑VLAN spanning tree can block individual VLANs, but a single VLAN failure would not cause the trunk to block all traffic.

Changing the trunk to access mode would restrict the link to a single VLAN, breaking VLAN 10 connectivity as well, which contradicts the working state of VLAN 10.

Trunk mode is used to carry multiple VLANs, but for a single access port with voice, the port remains in access mode and uses the voice VLAN feature.

The native VLAN is used for untagged traffic on a trunk, while the voice VLAN is a specific VLAN that carries tagged voice traffic from the phone.

They are separate VLANs and usually belong to different subnets for logical separation and management.

The specific factual error is that global commands affect all ports, not a single interface.

The specific factual error is confusing Root Guard with BPDU Guard; they serve different purposes.

The specific factual error is using the 'disable' keyword instead of 'enable' to activate BPDU Guard.

In the listening state, a switch port listens for BPDUs but does not learn MAC addresses. The learning state is the next step where the port begins to learn MAC addresses from incoming frames while still not forwarding traffic.

In the Forwarding state, the switch port has already learned MAC addresses and is forwarding data frames, whereas the question specifies a state that does not yet learn MAC addresses.

The Disabled port state does not listen for BPDUs, learn MAC addresses, or forward frames; it is administratively shut down and has no participation in STP topology.

This option is wrong because a switch interface configured as `dynamic desirable` and its peer as `dynamic auto` will negotiate a trunk link, not a routed port. Routed ports are typically configured explicitly and not through dynamic negotiation.

This option is wrong because configuring a switch interface as `dynamic desirable` and `dynamic auto` does not lead to the deletion of VLANs; it instead allows for trunk negotiation between the switches.

This option is wrong because a switch interface configured as `dynamic desirable` and its peer as `dynamic auto` will negotiate a trunk link, not a routed port. Routed ports are typically configured explicitly and do not involve dynamic negotiation.

The port is not in an err-disabled state; BPDU Guard causes the port to be shut down, not to stay in listening.

Misunderstanding that PortFast bypasses timers completely on access ports; the high forward delay is irrelevant if PortFast were active.

The assumption that the server is sending BPDUs is contradicted by the output showing zero BPDUs received.

Root Guard uses a specific 'root-inconsistent' state, not the generic 'blocking' state.

BPDU Guard triggers err-disable, not blocking. Blocking is an STP state, not an error state.

Root Guard and BPDU Guard have different effects: root-inconsistent vs. err-disable. Mixing them up is a common error.

Voice VLANs operate on access ports by tagging voice traffic while keeping PC traffic untagged in the data VLAN. A trunk is not required.

Native VLAN mismatches on trunks would affect both data and voice VLANs if both were allowed. The PC works, ruling out a general trunk issue.

The phone would work if it was sending voice traffic on the data VLAN (10), because VLAN 10 exists. The phone failing indicates a missing voice VLAN, not a misconfiguration on the phone.

Reducing all AP transmit power to zero would completely disable the wireless network, making it impossible for users to connect or experience any performance, which does not address the issue of slow performance in a dense office environment.

Changing every AP to the same channel would lead to co-channel interference, exacerbating the slow wireless performance issue rather than resolving it. In a dense office environment, this configuration would reduce overall throughput and increase contention among devices.

Disabling WPA2 security would not address the issue of slow wireless performance in a dense office environment; instead, it would compromise network security and potentially allow unauthorized access, worsening the situation.

Root Guard and UDLD do not directly address the requirement for a port to quickly transition to forwarding while shutting down upon receiving a BPDU. Root Guard is used to prevent a port from becoming a root port, while UDLD is for detecting unidirectional links.

Loop Guard and native VLAN do not directly address the requirement for a port to quickly transition to forwarding while shutting down upon receiving a BPDU. Loop Guard is designed to prevent loops by keeping a port in a loop-inconsistent state, and native VLAN is related to VLAN tagging, not port state management.

Port security and EtherChannel do not directly address the need for a switch port to quickly transition to forwarding mode while also shutting down upon receiving a BPDU. Port security focuses on limiting MAC addresses and EtherChannel is used for link aggregation, neither of which fulfill the specific requirements of this question.

The current configuration uses access mode with voice vlan, which is correct for a phone+PC setup. Trunk mode is unnecessary and could break the phone's untagged traffic expectations.

The voice vlan is correctly configured for the phone; the problem is with the data vlan assignment for the desktop.

Portfast is beneficial for host ports; disabling it would worsen the issue by introducing STP convergence delays.

APs use Ethernet frames, not PPP encapsulation; PPP is used for serial links.

CAPWAP does not assign IP addresses; DHCP handles that, but removing the AP's IP does not correct the gateway mismatch.

Disabling DHCP on the controller would break all APs, not just AP-22, and does not address the gateway issue.

The native VLAN being missing would not directly cause a port to go err-disabled when connecting an IP phone and workstation; it typically results in VLAN mismatches or communication issues rather than disabling the port.

BPDU Guard is designed to protect against loops by disabling ports that receive Bridge Protocol Data Units (BPDUs). In this scenario, the port is err-disabled due to port security violations, not because of BPDU Guard activation.

DHCP snooping denying the voice VLAN would typically result in the IP phone failing to receive an IP address, rather than causing the port to go err-disabled. The err-disabled state is more likely due to port security violations when multiple devices are connected.

Root Guard prevents a port from being elected as root port, not from receiving BPDUs on an access port.

Loop Guard prevents loops caused by BPDU loss on blocked ports, not from BPDU reception on access ports.

UDLD detects unidirectional links but does not disable a port when a BPDU is received.

The specific factual error is that trunk ports are used to carry multiple VLANs between switches, not for connecting end devices like phones and PCs. The correct method is to use an access port with a voice VLAN.

The specific factual error is that 'power inline never' explicitly disables PoE, which would prevent the phone from powering on. The correct command is 'power inline auto' to enable PoE detection and delivery.

The specific factual error is that the VLAN numbers are reversed. The access VLAN should be the data VLAN (10), and the voice VLAN should be 20. Swapping them would place data traffic in VLAN 20 and voice in VLAN 10, which is not the intended configuration.

EtherChannel is a technology used to combine multiple physical links into a single logical link for increased bandwidth and redundancy, but it does not separate user and voice traffic on a switchport. Therefore, it does not fulfill the requirement of carrying voice and user traffic separately.

SPAN (Switched Port Analyzer) is used for monitoring and capturing traffic on a switch port, not for separating user and voice traffic. It does not provide the necessary functionality to handle VLANs for voice and data traffic on a single port.

The Native VLAN is used for untagged traffic on a trunk port and does not separate voice and user traffic on an access port. It is not designed to handle the specific requirements of carrying both voice and data traffic separately.

The 'switchport protected' command is used to isolate ports within a VLAN (private VLAN edge), preventing communication between protected ports. It does not limit MAC addresses or trigger port shutdown upon violation.

The 'switchport nonegotiate' command disables Dynamic Trunking Protocol (DTP) negotiation, preventing the port from becoming a trunk. It does not limit MAC addresses or enforce violation actions, so it cannot meet the requirement to learn one MAC and shut down on a second unauthorized device.

Incorrect. OSPF router IDs are relevant to routing protocols and do not affect wireless client authentication or SSID association processes.

Incorrect. Routed-port mismatches on switch uplinks affect wired network traffic forwarding but do not cause wireless authentication failures at the client level.

Incorrect. DHCP relay problems affect IP address assignment after authentication; since the client fails authentication repeatedly, DHCP issues are not the cause.

The native VLAN must match the VLAN that the router's subinterface handles as untagged. Setting it to VLAN 1 violates the requirement.

The trunk must carry all VLANs that need inter-VLAN communication. Excluding VLAN 10 prevents its traffic from reaching the router.

PCs are end devices that expect untagged frames; they should be connected to access ports, not trunk ports.

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.