CCNA Switching and Network Access Questions

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.

Assumes port security is the problem itself rather than its configuration, leading to a full removal of the feature.

Focuses on clearing the error state without addressing why the violation occurred, leading to a loop of repeated err-disabled events.

Mistakenly attributes the err-disabled condition to a Layer 2 loop-prevention feature instead of the explicitly configured Layer 2 security feature.

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.

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

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

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

Candidates may incorrectly associate the blocked state with an administratively disabled interface.

Candidates often confuse error-disabled state (caused by features like BPDU guard) with the standard STP blocking state.

Candidates may misunderstand the root election process and assume a lower priority switch always becomes designated for all segments, ignoring the Altn role.

The 'root primary' macro sets priority to 24576, not 4096.

A priority of 32768 is the default, so it does not guarantee root bridge status.

The requirement is to set priority to exactly 4096, not 8192.

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

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

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

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

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

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

Switches are designed to forward unknown unicast frames by flooding, not dropping them. Dropping would occur only if the frame is malformed or security features like port security are violated.

A Layer 2 switch operates at the data link layer and does not involve the default gateway for forwarding decisions. The default gateway is used for routing between VLANs or subnets, not for unknown unicast flooding within a VLAN.

Switches flood the original unicast frame unchanged; they do not modify the frame type to broadcast. Broadcasting would change the destination MAC to FF:FF:FF:FF:FF:FF, which is not the case for unknown unicast flooding.

VLANs 1002–1005 are reserved for legacy FDDI and Token Ring, not user-created VLANs.

The native VLAN on a trunk sends frames untagged; this command sets the native VLAN, not a tagging restriction.

The MAC address is only used as a tiebreaker when bridge priorities are equal. It is not the first value considered in root bridge election.

The bridge priority is only the first part of the bridge ID; the full bridge ID (priority + MAC address) is compared. If priorities are equal, the MAC address is used as a tiebreaker.

Interface bandwidth is used to calculate path cost, which influences port roles (root port, designated port) but does not affect root bridge election. Root bridge election is based solely on bridge ID.

The specific factual error is that ISL is a legacy Cisco proprietary trunking protocol, and modern switches default to 802.1Q. The question specifies 802.1Q encapsulation.

The specific factual error is that ports connected to end devices (PCs) should be access ports, not trunk ports. Trunk ports are used for inter-switch links.

The specific factual error is that the native VLAN must be explicitly set to 99. Native VLAN 1 is the default and is often targeted in VLAN hopping attacks.

Candidates may think that a native VLAN mismatch breaks all trunk functions.

Candidates may assume that a missing VLAN on one switch explains inter-switch failures, ignoring that local communication would also fail.

Candidates might overlook that the trunk link is operational, which implies matching encapsulation.

UDLD aggressive detects unidirectional links but does not cause err-disabled on receiving BPDUs; it operates at Layer 1/2 for fiber links.

Root guard prevents a port from becoming the root bridge by moving it to root-inconsistent state, not err-disabled.

Loop guard prevents alternate/root ports from becoming designated when BPDUs stop, putting the port in loop-inconsistent state, not err-disabled.

Multi-VLAN access ports (access + voice) stay in access mode; trunk mode is not required and would incorrectly pass all VLANs.

Dynamic desirable actively initiates, but dynamic auto is passive.

When you prune the allowed VLANs, any omitted VLANs (including the native VLAN) are blocked unless added back.

This option revisits a step already completed and verified, making it redundant. Candidates might think double-checking routing is safe, but the scenario explicitly states routing is working as expected.

Some candidates might believe inter-VLAN communication requires a default route, but directly connected routes already provide full reachability without static routing. This action is overly drastic and misdirected.

Candidates often jump to VLAN misconfigurations when inter-VLAN communication fails, even when routing is confirmed. The scenario already establishes the VLAN 20 host's location; the next logical layer to inspect is ARP resolution.

Candidates often confuse 'down' with 'administratively down', assuming any disabled interface will show 'down'. They need to distinguish the two statuses.

Some candidates think a misconfigured IP address can cause an interface to be down, but status does not reflect IP configuration.

A common misunderstanding is that trunk ports do not make a VLAN active; in reality, a trunk carrying VLAN 10 can activate the SVI as long as the trunk is up/up and the VLAN is not pruned.

The SSID is simply the network name broadcast by the access point; encryption algorithms like WPA2 or WPA3 are configured separately on the WLAN and are not part of the SSID itself.

An SSID is a logical identifier, not a physical component. The radio antenna is hardware that transmits and receives wireless signals, but it does not define the network name.

The management IP address of a wireless controller is used for administrative access to the controller, not for client connectivity. Clients use the SSID to identify and connect to a WLAN, not the controller's IP.

A loop-inconsistent state is different from the root-inconsistent state observed. Loop Guard acts when BPDUs stop arriving, not when they appear with a superior root claim.

While BPDU Guard also reacts to incoming BPDUs, it puts the port in err-disabled (shutdown) state, not a blocking state named 'root-inconsistent'. The symptom described is not error-disabled.

BPDU Filter would not cause the port to show a root-inconsistent state. The symptom is a protective blocking state, which BPDU Filter does not provide.

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

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

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

Incorrect because 'switchport access vlan' applies only to access ports and cannot specify multiple VLANs; it does not configure trunk VLANs.

Incorrect because 'switchport mode dynamic auto' controls trunk negotiation but does not limit which VLANs are allowed on the trunk.

Incorrect because 'switchport trunk native vlan' sets only one native VLAN for untagged traffic and does not restrict the allowed VLAN list.

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

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

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

PortFast is used to bypass the listening and learning states on access ports, but it does not resolve the root bridge election issue. The port is blocking due to STP topology inconsistency, not because of slow convergence.

BPDU Guard is used to protect against unauthorized switches by disabling a port if a BPDU is received, but it does not fix the root bridge election issue. The port is blocking due to STP, not due to BPDU violations.

Both PVST+ and Rapid PVST+ use the same bridge ID election process. Changing the mode would not resolve the priority misconfiguration; the root bridge election is based on bridge priority and MAC address, not the STP variant.

The client receives an address from the guest network, indicating that the DHCP server or VLAN assignment is incorrect. A manually configured wrong subnet mask would not cause the client to obtain an IP from a different network; it would simply prevent proper communication within the assigned subnet. The issue is at the network assignment level, not a host configuration error.

PPP encapsulation is used on serial WAN links, not in wireless LAN environments. Wireless clients connect via 802.11, and APs use Ethernet or CAPWAP to connect to the network. PPP has no role in VLAN assignment or DHCP for wireless clients.

STP root election determines the root bridge in a switched network to prevent loops, but it does not affect VLAN assignment for wireless clients. Even if STP root election failed, it would not cause a client to receive an IP from the wrong network; it would more likely cause network instability or loops.

Root Guard prevents a port from becoming a root port by placing it in a root-inconsistent state, not err-disabled. It does not cause link flaps or err-disable ports.

Loop Guard prevents alternate or root ports from becoming designated in the absence of BPDUs, but it does not err-disable ports. It places ports in a loop-inconsistent state, which is not err-disabled.

The global 'spanning-tree portfast bpduguard default' command only applies BPDU Guard to PortFast-enabled ports. If a port receives a BPDU and is not PortFast, it will not be err-disabled by this global command. The scenario states BPDU Guard was configured on all access ports, implying interface-level configuration.

The client has already joined the correct SSID, authenticated, and received an IP address in the correct subnet, so the SSID broadcast setting is not the issue. The problem is specific to one application, not general connectivity.

The voice VLAN on the AP uplink is used for VoIP traffic, not for general data applications. Since the client can access other internal resources, the issue is not related to the AP uplink configuration.

OSPF router IDs are used by routers in OSPF routing, not by end-client devices. Clients do not run OSPF, so this is irrelevant to the problem.

The specific factual error is using a range (10-20) instead of a list (10,20), which includes unintended VLANs.

The specific factual error is omitting the 'trunk' keyword in the native VLAN command, which is required for trunk ports.

The specific factual error is setting the native VLAN to 1 instead of 99, which does not meet the requirement.

Reducing path cost on a nonroot switch does not affect the root bridge election, which is determined by lowest bridge ID.

Changing cost on one uplink of a nonroot switch does not force all designated ports on downstream switches into blocking; only a topology change might trigger recalculations.

Path cost adjustment does not stop BPDUs; BPDUs continue to be sent from all ports in the spanning tree.

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

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

Layer 2 switches do not support routed ports; they only support switchport mode access or trunk.

An access port cannot carry multiple VLANs; a trunk is required for Router-on-a-Stick.

Router-on-a-Stick requires subinterfaces; a single IP address on the physical interface only handles one VLAN. The 'vlan' command is not used on routers for inter-VLAN routing.

The specific factual error is that the question states SW1 is a multilayer switch with SVIs, so it can route internally without an external router. The issue is that IP routing is not enabled on the switch itself.

The specific factual error is that the SVIs are already up (hosts can ping the gateway), so 'no shutdown' is not the missing step. The problem is at Layer 3 routing, not Layer 2/3 interface status.

The specific factual error is that directly connected networks do not require static routes; the switch automatically installs them when the SVI is up. The problem is that 'ip routing' is not enabled, so the switch does not use these routes for forwarding.

The violation mode 'restrict' does not place the port in error-disabled state; it only drops traffic from unauthorized MACs and increments a counter.

The 'protect' mode drops violating frames but does not disable the port or generate syslog messages; it is the least restrictive violation mode.

The command 'switchport port-security mac-address' manually assigns a MAC address, whereas 'switchport port-security mac-address sticky' enables dynamic learning and storage of MAC addresses.

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

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

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

An incorrect SSID would prevent the client from associating to the WLAN at all, not allow authentication followed by DHCP failure.

A statically configured IP is less likely the strongest cause because the client would either not use DHCP or would obtain an APIPA address, and the issue is specifically about failing to obtain a correct address via DHCP.

The access point’s default gateway does not impact DHCP forwarding for client traffic; in controller-based deployments, DHCP packets are handled by the controller or bridged directly to the wired network.

Root Guard is only effective on designated ports; applying it to a root port would not prevent a rogue switch from becoming root. Loop Guard on a designated port is unnecessary and could cause false positives.

BPDU Guard on a trunk port would err-disable it upon receiving a BPDU, which is normal for trunk ports. Loop Guard on the root port is essential for loop prevention; removing it would leave the network vulnerable.

Root Guard on an access port would block the port if a superior BPDU is received, but access ports should not receive BPDUs if PortFast is enabled. BPDU Guard already handles that by err-disabling the port.

The specific factual error is that IP phones typically use an access port with a voice VLAN, not a trunk port. Trunking is unnecessary and can cause compatibility issues.

The specific factual error is confusing the access VLAN and voice VLAN assignments. The voice VLAN is configured with 'switchport voice vlan', and the access VLAN with 'switchport access vlan'.

The specific factual error is reversing the PoE settings: 'power inline never' on the phone port and 'power inline auto' on the AP port.

The command 'switchport access vlan 10' assigns the interface to a specific access VLAN, placing it in access mode, not trunk mode. Trunk mode is required to carry multiple VLANs, and this command does not enable trunking.

The command 'switchport mode dynamic auto' places the interface in a mode that waits for the neighboring switch to initiate trunking via DTP. It does not directly force trunking; the interface will only become a trunk if the neighbor is set to 'dynamic desirable' or 'trunk'.

The command 'spanning-tree portfast' is used to speed up the transition of an access port to the forwarding state, bypassing the listening and learning phases. It has no effect on trunking mode and is unrelated to VLAN trunk configuration.

BPDU guard causes an err-disable state, which would show the interface as down or err-disabled, not as root-inconsistent.

Loop guard places a port into loop-inconsistent blocking state when BPDUs stop being received, not when a superior BPDU is received.

A forwarding state would allow traffic; the problem here is that the port is in a blocked state due to root guard, not a misconfigured VLAN.

The violation mode 'protect' does not shut down the port; it only drops offending traffic. The question explicitly requires the port to shut down.

The maximum MAC addresses must be set to 1 to restrict the port to a single device. Setting it to 2 allows an additional device.

The command 'switchport port-security mac-address 0000.1111.2222' statically assigns a MAC address, which does not allow dynamic learning. Sticky learning is enabled with the 'sticky' keyword.

A root bridge election failure would not place the port in err-disabled state; it would cause loops but not trigger BPDU Guard directly.

PortFast and BPDU Guard are fully compatible with Rapid PVST+; this option implies incompatibility, which is incorrect.

A trunk misconfiguration alone would not cause the port to go err-disable unless a BPDU is received on a PortFast-enabled port, and BPDU Guard is the specific mechanism for that.

The native VLAN is used for untagged traffic on a trunk and is typically VLAN 1 by default. It has no bearing on whether a specific tagged VLAN like VLAN 30 is carried; the allowed VLAN list controls that.

PortFast is a feature that speeds up the transition of an access port to the forwarding state, bypassing STP listening/learning. It does not affect trunk operation or whether a VLAN is carried on a trunk.

The commands `switchport voice vlan 150` and `switchport access vlan 20` are used on a Layer 2 switch port, not a routed interface. A routed WAN interface would require `no switchport` and an IP address configuration, which is not present here.

CAPWAP (Control and Provisioning of Wireless Access Points) is a protocol used for wireless LAN controller and access point communication, not for voice VLAN configuration. The voice VLAN feature is unrelated to CAPWAP.

The `switchport voice vlan` command only affects the specific access port where it is configured, not all trunk ports. The native VLAN on trunks is configured separately with `switchport trunk native vlan`.

Assigning an IP to the physical interface would prevent subinterfaces from working, and 'switchport mode trunk' is invalid on a router interface.

The problem is specifically that R1 cannot route between VLANs due to missing 'ip routing', not a trunk pruning issue.

Subinterfaces cannot be individually shut down; the physical interface controls the link state.