CCNA Switching Questions

The priority value 4096 is not used by the root primary command; it sets priority to 24576. Additionally, errdisable recovery does not immediately recover the port; it requires a timer.

Root secondary makes the switch a secondary root, not primary. An err-disabled port requires a shutdown before no shutdown to clear the error state.

BPDU filter does not trigger err-disable on BPDU reception; it silently drops BPDUs. BPDU Guard is needed to protect edge ports.

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.

Assumes the switch port configuration alone guarantees proper VLAN delivery to the PC, ignoring the phone's role as a transparent bridge.

Confuses the mechanism for voice VLAN assignment with the requirement for data passthrough; CDP's role is only for the phone's own voice VLAN, not for the PC's data VLAN.

Misapplies QoS as a potential cause for a connectivity issue; it is a quality-of-service feature and does not block DHCP or initial network access.

The native VLAN is untagged on the trunk, and R1 can handle it via the physical interface if needed, but a missing subinterface for native VLAN 1 is not the cause of the issue.

IP routing is already enabled; the issue is a configuration error on the subinterface, not a missing global command.

The trunk configuration is correct; the problem is the encapsulation mismatch on the router subinterface.

This is not a difference; both RSTP and STP require a root bridge with a lower bridge priority than all other switches.

Both RSTP and STP use the same three timers (Hello, Max Age, Forward Delay); RSTP does not reduce or eliminate them.

RSTP still uses BPDUs—it does not eliminate them; it enhances BPDUs with new flags for faster convergence.

OSPF is a Layer 3 routing protocol used for exchanging routes between routers, not for resolving Layer 2 switchport mismatches. This issue is purely about trunk/access configuration, which is unrelated to OSPF.

While native VLAN mismatch can cause issues on a trunk link, the primary problem here is that one side is configured as access, not trunk. Even if native VLAN is set to 1 on both sides, the access port will still not process tagged frames correctly.

Hostnames are purely for identification and have no impact on switchport operation or VLAN tagging. The trunk/access mismatch is a Layer 2 configuration issue independent of hostnames.

BPDU Guard does not prevent loops by disabling a trunk port; it is typically used on access ports with PortFast and disables the port upon receiving any BPDU.

Root Guard places the port into root-inconsistent state, not errdisable; errdisable is the state used by BPDU Guard.

Neither Root Guard nor BPDU Guard filters BPDUs; they both process received BPDUs and then take action (root-inconsistent for Root Guard, errdisable for BPDU Guard).

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 is using trunk mode for an IP phone port instead of access mode with voice VLAN.

The specific factual error is reversing the VLAN assignments: the access VLAN should be data, and the voice VLAN should be voice.

The specific factual error is swapping the PoE priority values: the phone should be critical, the AP high.

Candidates focus on the matching priority numbers and overlook the missing root port that indicates a complete loss of BPDUs.

Candidates may assume no BPDUs means STP is off, but the intended root designation suggests STP is on and a physical disconnect is the primary suspect.

Candidates recall that BPDU guard can block ports, but they fail to differentiate between a missing port due to err-disable and a missing port due to a physically down link, which looks identical in this output.

Option C is incorrect because access points are still required to provide the actual wireless radio connectivity; the controller does not replace APs.

Option D is incorrect since DHCP or other IP configuration methods are still needed for client devices; the controller does not replace these network services.

Option E is incorrect because WPA3 is a wireless security standard and does not relate to the architectural concept of controller-based WLAN management.

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.

The router's interface is a routed port, not a switchport; access/trunk concepts apply to switch interfaces. Even if it were a switch interface, the issue is about ARP replies, which require Layer 3 addressing, not trunking.

ARP requests are Layer 2 broadcasts; if the router's interface is in the same VLAN as Host A, it will receive the request. The problem is that the router does not reply, indicating it lacks an IP in the destination subnet.

Duplex mismatch causes CRC errors and collisions, but ARP requests would still be received and could be replied to. The capture shows clean ARP requests with no replies, pointing to a Layer 3 issue, not physical layer.

This configuration makes the port a trunk port, which is used to carry multiple VLANs between switches, not for a single user PC. The 'switchport trunk native vlan 20' command sets the native VLAN for untagged traffic on the trunk, but the port still actively negotiates trunking via DTP, violating the requirement to not negotiate trunking.

The 'switchport mode dynamic desirable' command actively attempts to form a trunk with the connected device via DTP, which contradicts the requirement to not negotiate trunking. Additionally, 'switchport trunk allowed vlan 20' only restricts which VLANs are allowed on the trunk, but the port is still in trunking mode, not an access port.

The 'no switchport' command converts the Layer 2 switch port into a Layer 3 routed interface, which cannot be assigned to a VLAN. This configuration is used for routing between VLANs or connecting to routers, not for connecting a user PC to a specific VLAN.

PortFast is unsafe on trunk ports; it is intended only for edge access ports.

The root bridge is determined by the lowest bridge priority, not the highest.

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.

Root guard does not error-disable a port; instead, it places the port into a root-inconsistent state if a superior BPDU is received, preventing the port from becoming a root port. It is used to enforce the root bridge location, not to disable ports upon BPDU reception.

Port security restricts the number of MAC addresses learned on a port and can error-disable the port if a violation occurs (e.g., too many MAC addresses). It does not react to BPDUs; its focus is on MAC address learning, not spanning-tree BPDUs.

DHCP snooping is a security feature that filters DHCP messages and can error-disable a port if a DHCP violation occurs (e.g., rogue DHCP server). It does not inspect or react to BPDUs, which are layer 2 spanning-tree frames.

The maximum limit of 10 MAC addresses is too high for the requirement of allowing only one learned MAC address. Additionally, protect mode drops frames from unknown MACs but does not shut down the port, so the port remains active even after a violation.

Restrict mode does not shut down the port; it only logs and drops frames from unknown MACs. The requirement explicitly states the port should shut down, which restrict does not achieve.

Setting the maximum to unlimited defeats the purpose of limiting MAC addresses to one. Even though violation mode is shutdown, the port will never trigger a violation because there is no limit, so it will never shut down due to port security.

Root Guard does not cause err-disable; it only prevents the port from becoming a root port. The err-disabled state is triggered by BPDU Guard, not Root Guard.

PortFast on the access switch's uplink does not cause err-disable on the distribution switch. PortFast only affects the access switch's port state, not the distribution switch's interface.

The err-disable is caused by BPDU Guard, not by trunking misconfiguration. Changing the port mode to access would not resolve the BPDU Guard issue and could disrupt connectivity.

Native VLAN configuration does not affect tagged VLAN 60 traffic—native VLAN only matters for untagged frames.

The trunk is stated to allow VLAN 60, so VLAN filtering is not the problem; a student might misread the premise.

The default gateway resides on SW1, not SW2; configuring a loopback on SW2 does not create a gateway for VLAN 60.

The exhibit shows a port-security violation message, not an STP topology change. A superior BPDU would cause a root port election, not a port shutdown due to security policy.

Connecting a hub does not change the interface type; a switchport remains a Layer 2 interface unless explicitly configured with 'no switchport'. The exhibit shows a Layer 2 security violation, not a routed port conversion.

DHCP snooping does not automatically shut down a port when a hub is attached; it filters DHCP messages and can disable ports only if a DHCP server is detected on an untrusted port. The exhibit clearly shows a port-security violation message.

RF channel issues cause connectivity or performance problems, not authentication failures after a successful association.

Hiding the SSID does not affect the 802.1X authentication process; the failure is likely due to RADIUS communication.

Voice VLAN assignment is unrelated to client authentication; clients do not need a voice VLAN to authenticate.

A trunk port is designed to carry traffic for multiple VLANs using 802.1Q tagging, which is not expected from a standard PC. Using a trunk port for a PC would cause the switch to expect tagged frames, leading to communication failures.

A routed port is a Layer 3 interface used for routing between VLANs or connecting to routers, not for connecting end-user PCs. It does not operate as a Layer 2 switchport and would not handle VLAN tagging as required.

A port-channel interface is a logical bundling of multiple physical links for increased bandwidth and redundancy, not a single connection to an end-user PC. It is used between switches or to servers, not for typical PC access.

The specific factual error is confusing Root Guard with BPDU Guard. Root Guard is used to enforce the root bridge position, not to protect against BPDUs.

The specific factual error is that BPDU Filter silently drops BPDUs instead of taking action, which can allow loops to form if an unauthorized switch is connected.

The specific factual error is using the global configuration command on an interface. The global command enables BPDU Guard on all PortFast-enabled ports, but the question asks to configure it on a specific port.

Changing encapsulation is unnecessary because the subinterfaces already use the correct dot1Q encapsulation for VLANs 10 and 20.

The 'ip routing' command is already enabled by default on routers, and global routing is not the problem here.

Subinterfaces do not support a 'no shutdown' command; their operational state is determined solely by the physical interface.

BPDU Guard is a security feature that err-disables a port upon receiving BPDUs; it does not accelerate root election. Root election speed is influenced by STP timers and bridge priorities, not BPDU Guard.

BPDU Guard does not disable STP permanently; it only reacts to BPDU reception by err-disabling the port. STP remains active on other ports, and the port can be re-enabled after the violation is resolved.

Limiting MAC addresses on a port is the function of port security, not BPDU Guard. BPDU Guard specifically monitors for BPDU frames and takes action if any are received.

A native VLAN mismatch does not cause all other VLANs to stop forwarding. The trunk continues to forward frames for all VLANs, but untagged frames (native VLAN) are miscommunicated.

A trunk port does not automatically convert to an access port due to a native VLAN mismatch. The trunk remains operational, but the native VLAN mismatch causes problems for untagged traffic.

STP continues to run normally on the trunk link despite a native VLAN mismatch. The mismatch does not disable STP; it only affects the handling of untagged frames.

Separate WLANs do not eliminate the need for wireless security; both employee and guest WLANs require encryption (e.g., WPA2/WPA3) and authentication mechanisms to protect data in transit and prevent unauthorized access.

Roaming problems, such as handoff delays or authentication re-requirements, are not automatically resolved by having separate WLANs; they depend on factors like controller configuration, AP placement, and roaming protocols (e.g., 802.11r).

Separate WLANs do not replace the need for VLANs or policy controls; in fact, they often rely on VLANs to segregate traffic and on additional policies (e.g., ACLs, firewall rules) to enforce access restrictions between the WLANs and the network.

BPDU Guard results in err-disable, which is not reflected in the show spanning-tree inconsistentports output. The exhibit clearly shows Root Inconsistent, indicating Root Guard, not BPDU Guard.

Loop Guard creates a loop-inconsistent listing, not root-inconsistent. The command output explicitly indicates Root Inconsistent, ruling out Loop Guard.

Without BPDU Guard, PortFast does not react to BPDUs with a blocking state. The exhibit's root-inconsistent inconsistency is specific to Root Guard, not PortFast or BPDU Guard.

Changing the native VLAN to 30 would not resolve the issue because the native VLAN is used for untagged traffic on a trunk, and the problem is that VLAN 30 traffic is not being allowed at all. Additionally, native VLAN mismatch can cause connectivity issues, but it does not specifically prevent only VLAN 30 from reaching other VLANs.

Configuring the uplink as an access port would place it in a single VLAN, preventing traffic from multiple VLANs (including VLAN 30) from traversing the link. Since the switch needs to carry traffic for multiple VLANs, the uplink must remain a trunk port.

Disabling STP on VLAN 30 would be dangerous as it could cause bridging loops and network instability. Moreover, STP does not control whether a VLAN is allowed on a trunk; it only prevents loops. The issue is a missing VLAN in the trunk allowed list, not a spanning-tree problem.

PortFast is a feature that allows a port to transition immediately to the forwarding state, bypassing the usual spanning-tree listening and learning phases. It does not cause a port to shut down or enter an err-disabled state; it only speeds up convergence for end-user devices.

Assigning an access VLAN (VLAN 30) simply places the port into a specific broadcast domain for user traffic. It has no mechanism to detect or react to BPDUs, and it does not cause a port to enter an err-disabled state. The port would remain operational regardless of the VLAN assignment.

Configuring a port as an access port is a standard practice for connecting end devices. It does not inherently cause any shutdown or err-disabled condition. The port remains up and forwarding traffic unless another feature, such as BPDU Guard, triggers a protective action.

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.

Attributing the issue to a native VLAN mismatch overlooks the root election change and the BPDU Guard-triggered err-disable state.

This answer ignores the root election shift and the BPDU Guard events; PortFast misconfiguration alone would not cause these symptoms.

This fails to account for the selective err-disable of only access ports and the concurrent root bridge change, which points to a targeted misconfiguration rather than a blanket global setting.

WPA2 and WPA3 are security protocols, not radio frequencies. 802.11 radio frequencies refer to bands like 2.4 GHz and 5 GHz, which are unrelated to security standards.

Trunk ports are a concept in switched networks for carrying multiple VLANs, typically using 802.1Q tagging. WPA2 and WPA3 have nothing to do with switch port configuration.

WPA3 does not eliminate the need for SSIDs; SSIDs are still required to identify and differentiate wireless networks. WPA3 focuses on authentication and encryption, not network identification.

The specific factual error is that IP routing is not enabled by default; it requires the 'ip routing' global command.

The specific factual error is that the native VLAN must match on both sides; changing R1's native VLAN to 1 does not match the switch's native VLAN 99.

The specific factual error is that the subinterface G0/0.20 is associated with VLAN 20, so its encapsulation must be dot1Q 20, not 10.

Confusing DTP trunk negotiation with the operational consequences of a native VLAN mismatch.

Assuming that a crossover cable is mandatory for switch-to-switch connections, ignoring auto-MDIX.

Mistaking the ability to forward traffic for a specific VLAN with the ability to negotiate a trunk.

The native VLAN is used for untagged traffic on a trunk and does not affect the forwarding of tagged frames for other VLANs. Changing the native VLAN to 50 would not resolve the issue because VLAN 50 frames are still tagged and require inclusion in the allowed VLAN list.

An access port can only carry a single VLAN, so changing the trunk to an access port would prevent the link from carrying multiple VLANs, including VLAN 50. The link is intended to carry multiple VLANs, so a trunk is required.

PPP (Point-to-Point Protocol) is a WAN protocol used on serial links, not on Ethernet trunks. Ethernet trunks use 802.1Q or ISL encapsulation, and PPP has no relevance to VLAN trunking issues.

This action is too drastic and impacts all ports, whereas the issue is specific to access ports connected to end devices. PortFast is the standard, safe method for eliminating delay on edge ports.

Candidates might think that turning off STP on a single VLAN is a quick fix, but it removes the safety net against loops and is not a recommended network practice. PortFast provides the immediate-forwarding benefit while preserving STP loop protection.

Candidates often assume that Rapid PVST+ immediately forwards on all access ports, but the edge port behavior must be configured. The scenario explicitly mentions the port is an access port connected only to a PC; the immediate fix is to enable PortFast, not change the entire STP mode.

This statement is incorrect because the phone and PC can operate on different VLANs on the same port. The phone uses the voice VLAN, while the PC uses the access (data) VLAN. They are not required to use the same VLAN, and misconfiguration of the access VLAN can cause the PC to fail while the phone works.

BGP (Border Gateway Protocol) is a routing protocol used between autonomous systems, not related to VLAN configuration on a switchport. The issue described is about Layer 2 VLAN assignment, not Layer 3 routing. BGP has no role in this scenario.

The access VLAN remains relevant even when a voice VLAN is configured. The access VLAN is used for the PC's data traffic, while the voice VLAN is used for the phone's traffic. If the access VLAN is incorrect, the PC will not be able to communicate on the correct data network.

Rapid PVST+ uses RSTP's rapid handshake process, not timer-based convergence like standard 802.1D.

Rapid PVST+ is based on the 802.1w standard (RSTP), not 802.1D.

Rapid PVST+ runs a separate instance per VLAN and does not use 802.1Q to consolidate instances.

Changing the port type to trunk does not affect spanning-tree root bridge election or port roles. The blocking state is determined by spanning-tree topology, not by trunk configuration.

Portfast is intended for access ports connected to end devices to bypass listening/learning states; it is not used on uplinks and does not resolve a blocking state caused by spanning-tree topology.

BPDU guard is used on access ports to protect against rogue switches by disabling the port if a BPDU is received. It does not affect root bridge election or port roles on uplinks.

The command 'switchport trunk allowed vlan 10' is used on a trunk port to specify which VLANs are allowed to traverse the trunk link. It does not change the port mode to access; instead, it assumes the port is already a trunk. Therefore, it is incorrect for placing a switch port into access mode.

The command 'switchport mode dynamic desirable' enables Dynamic Trunking Protocol (DTP) to actively negotiate trunking with the connected device. This does not directly place the port into access mode; instead, it allows the port to become a trunk if the neighbor agrees. The port remains in a dynamic state until negotiation completes.

The command 'no switchport' converts a Layer 2 switch port into a Layer 3 routed port, which is used for routing between VLANs or connecting to routers. This removes all Layer 2 switching functionality, including VLAN assignment, and is the opposite of placing the port into access mode.

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.

Spanning Tree Protocol (STP) operates at Layer 2 and has no mechanism to manage or allocate IP addresses; IP address exhaustion is addressed by protocols like DHCP or IPv6 transition technologies.

DNS lookups are application-layer processes that rely on IP connectivity and name resolution servers; STP does not influence DNS performance or resolution speed.

Wireless encryption is a security feature implemented at the data link layer (e.g., WPA2/3) and is unrelated to STP, which deals with physical topology loop prevention.

PortFast allows a port to transition to forwarding immediately upon link up, but it does not react to BPDU reception. BPDU Guard is a separate feature that disables the port upon receiving a BPDU, not accelerate forwarding.

Receiving a BPDU on a single edge port does not trigger a root bridge election. Root bridge election is based on bridge ID comparison across the entire spanning-tree domain, not on a single BPDU on a port.

BPDU Guard does not change the port mode; it only reacts to BPDU reception by disabling the port. Port mode (access or trunk) is configured separately and is not affected by STP protection features.

Channel width affects all clients on the AP, not just a single client.

Hiding the SSID only prevents the SSID from being broadcast; it does not impact network access after association.

WPA2 does not require NTP for client authentication; NTP is for time synchronization, not client access control.

The specific factual error is that the voice VLAN is set to VLAN 10 instead of VLAN 20, which contradicts the requirement that voice traffic uses VLAN 20.

The specific factual error is the failure to enable PoE on the interfaces, which is required for both the AP and IP phones to operate.

The specific factual error is the omission of the 'switchport voice vlan 20' command on the phone ports, leaving them without voice VLAN assignment.

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.

DHCP Discover is always broadcast (destination FF:FF:FF:FF:FF:FF), not unicast, because the client does not know the DHCP server's MAC address.

A TCP SYN-ACK indicates the server received the SYN and is willing to establish the connection; it is part of a successful three-way handshake, not a failure.

The TTL in a captured packet is the value after decrementing at each hop; the original TTL is set by the source but is not preserved in the packet header.

The specific factual error: 'spanning-tree guard root' is a root guard feature, not BPDU guard. Also, manually setting priority to 4096 may not guarantee root if another switch has lower priority.

The specific factual error: 'root secondary' is for backup root, not primary. It sets priority to 28672, which is higher than the default priority of 32768 but not low enough to become root if another switch has a lower priority.

The specific factual error: priority 32768 is default and does not change root status. BPDU filter is not a security feature against BPDU attacks; it suppresses BPDUs entirely.

BPDU guard is incorrect because it disables a port upon receiving any BPDU, which is suitable for edge ports but does not control root path roles or topology changes.

Port security is unrelated to STP root path control; it manages MAC address access on a port and does not affect BPDU processing or root bridge election.

DHCP snooping protects against rogue DHCP servers by filtering DHCP messages and does not interact with STP or root bridge election mechanisms.