Free 300-425 Practice Test Questions 2026

Explanation:

Key Requirements:

Six buildings, each with a WLC in the IDF (Intermediate Distribution Frame).

Seamless roaming between APs and controllers across buildings.

Why Distributed Architecture (Option A) is Correct:

Local Controllers in Each Building:

A distributed architecture places a WLC in each building’s IDF, optimizing local traffic handling and reducing latency.

Mobility Domain Roaming:

Controllers are grouped into a mobility group, allowing clients to roam seamlessly between APs on different WLCs.

Scalability and Redundancy:

If one WLC fails, only one building is affected (vs. centralized, where all buildings rely on a single WLC).

Why Other Options Are Incorrect:

Option B (Centralized):

All APs connect to a single central WLC, which is not scalable for six buildings and introduces a single point of failure

. Option C (Cloud):

Cloud controllers (e.g., Meraki) don’t align with the requirement for on-premises WLCs in IDFs.

Option D (Autonomous):

Autonomous APs operate independently (no WLC), making roaming and centralized management impossible.

Reference:

Cisco Campus Wireless Design Guide: Recommends distributed WLCs for multi-building deployments.

Cisco Mobility Groups Documentation: Explains how controllers share client sessions for roaming.

Explanation:

Key Requirements:

Auditorium with 500+ students (ultra-high client density).

Support for laptops (implying concurrent data, video, and possibly VoIP traffic).

Why High-Density Design (Option D) is Correct:

AP Placement and Cell Sizing:

Smaller cells (more APs with lower transmit power) to avoid co-channel interference.

Typical density: 1 AP per 50–100 users (e.g., 5–10 APs for 500 seats).

Channel Planning:

Use 5 GHz exclusively (more non-overlapping channels than 2.4 GHz).

20 MHz channels (not 40/80 MHz) to maximize channel reuse.

Client Load Balancing:

Band steering (push clients to 5 GHz) and Airtime Fairness to prevent slow clients from hogging airtime.

Why Other Options Are Incorrect:

Option A (Roaming Design): Focuses on mobility (e.g., hallways), not static high-density seating.

Option B (Voice Design): Optimized for low-latency VoIP, not mass data traffic.

Option C (Location Design): For RTLS/asset tracking, not capacity.

Reference:

Cisco High-Density Design Guide: Recommends 1 AP per 75 users in lecture halls.

Explanation:

Key Requirements:

Voice SSID for Cisco 8821 phones (VoWLAN).

Optimized roaming across multiple WLCs.

Solution 1: Mobility Groups (Option A)

Why?

Mobility groups allow WLCs to share client state information, enabling seamless roaming between controllers.

Without this, phones would reauthenticate when moving between WLCs, causing call drops.

Reference:

Cisco Wireless LAN Controller Configuration Guide: "Mobility groups are required for inter-controller roaming."

Solution 2: Cisco Centralized Key Management (CCKM) (Option B)

Why?

CCKM enables fast secure roaming (802.11r-like behavior) for Cisco phones.

Reduces reauthentication time from ~500 ms to sub-50 ms, critical for voice.

Reference:

Cisco VoWLAN Design Guide: "CCKM is recommended for Cisco 8821/8845 phones."

Why Other Options Are Incorrect:

Option C (AP Groups): AP groups are for local AP organization, not roaming.

Option D (AVC Profile): AVC is for application visibility, not roaming optimization.
Option E (AVC for Best Effort): Voice traffic must be tagged as Platinum (Voice), not Best Effort.

Explanation:

Why Option B is Correct?

Pervasive Coverage Requirement:

The oil terminal requires consistent coverage, meaning APs should provide a strong signal without excessive overlap.

Auto power assignment allows APs to dynamically adjust transmit power for optimal coverage and minimal interference.

Casual Web & Email Traffic (Low Bandwidth Needs):

Since the traffic is light (web/email), disabling low data rates (below 24 Mbps) improves efficiency by:

Reducing airtime usage (slow clients consume more airtime).

Encouraging clients to connect at higher rates, improving overall network performance.

5 GHz Band Optimization:
5 GHz has less interference and more channels than 2.4 GHz.

Disabling very low rates (e.g., 6, 9, 12, 18 Mbps) ensures clients don’t linger on inefficient connections

Why Other Options Are Incorrect?

Option A: Keep power auto, disable 802.11n/ac MCS rates

Disabling MCS rates (Modulation and Coding Scheme) hurts performance because 802.11n/ac rely on MCS for high-speed transmissions.

Unnecessary for casual traffic and would reduce efficiency in a 5 GHz network.

Option C: Keep all data rates enabled, power auto

Keeping all data rates enabled allows slow clients to connect at low speeds (e.g., 6 Mbps), wasting airtime and degrading performance.

Not optimal for pervasive coverage because slow clients can cause congestion.

Option D: Disable rates below 54 Mbps, static power level 1

Disabling below 54 Mbps is too aggressive—some clients may struggle to connect, especially at the edge of coverage.

Static power level 1 (lowest power) reduces coverage range, which contradicts the pervasive coverage requirement.

Reference:

Cisco Wireless LAN Design Best Practices recommends disabling low data rates for efficiency

Cisco’s High-Density Design Guide suggests auto power adjustment for balanced coverage.

Explanation:

Why Option D is Correct?

Legacy Mobility Tunnel Issue:

In legacy mobility mode, the mobility tunnel between the enterprise WLC and service provider WLC uses UDP port 16666 (by default).

If the tunnel fails, the mapping command on the WLC helps debug the issue by:

Verifying mobility group peers.

Checking if UDP 16666 is reachable between WLCs.

Identifying firewall blocking issues.

Key Debugging Steps:

Run show mobility summary to check mobility peers.

Use mapping to test connectivity on UDP 16666.

Verify firewall rules allow bidirectional UDP 16666 traffic.

Why Other Options Are Incorrect?

Option A: Telnet to firewall on port 97

Port 97 is irrelevant to mobility tunnels.

Mobility tunnels use UDP 16666, not TCP 97.

Option B: Use the mapping command on the WLC (Incomplete Option)

This seems similar to Option D but is cut off, making it invalid.

Option C: Telnet to firewall on port 16666

Telnet uses TCP, but mobility tunnels use UDP 16666.

A Telnet test won’t verify UDP connectivity (must use mapping or ping with UDP checks).

Reference:

Cisco Wireless LAN Controller Configuration Guide, "Mobility Groups"

Mobility tunnels require UDP 16666 (default) between WLCs

The mapping command tests tunnel reachability.

Firewall Requirements for Mobility:

Must allow UDP 16666 in both directions.

Explanation:

Why Option B is Correct?

SSO (Stateful Switchover) Requirements:
For SSO to work properly, the primary and secondary WLCs must be connected via their redundancy ports (typically a direct cable or VLAN).

If this connection is missing or broken, the secondary WLC cannot synchronize with the primary and will go into maintenance mode (failing to take over if the primary fails).

Impact of Missing Redundancy Link:

Without the redundancy port connection:

Heartbeat messages fail, causing the secondary to lose sync.

The secondary WLC cannot receive real-time state updates from the primary.

The system defaults to maintenance mode instead of staying in hot standby.

Why Other Options Are Incorrect?

Option A: Keepalive timer is too low
While a misconfigured keepalive timer can cause synchronization issues, it does not force the secondary into maintenance mode—it may just cause flapping.
The main issue is the physical/logical redundancy link.

Option C: Redundancy port must be in the same subnet as redundancy management

This is not a strict requirement for SSO.
The redundancy port can be on a different subnet as long as routing is properly configured (though Cisco recommends direct connection for reliability).

Option D: Global Configuration of SSO is set to Disabled
If SSO is disabled, the secondary WLC would not even attempt synchronization—it would operate as a standalone controller, not go into maintenance mode.

Reference:

Cisco Wireless LAN Controller High Availability Guide
SSO requires a redundancy port connection (direct or via a dedicated VLAN).
Without it, the secondary WLC cannot maintain state sync and enters maintenance mode.
Cisco Best Practices for SSO:
Use a dedicated, low-latency link for redundancy ports.

Explanation:

Why Option A (firewall port 16666) is Correct?

Mobility Tunnels Use UDP Port 16666
In Cisco Wireless LAN Controllers (WLCs), inter-controller mobility tunnels rely on UDP port 16666 for communication.
If a firewall is blocking this port, the mobility tunnel will fail to establish.

Validation Steps:
Check firewall rules to ensure UDP 16666 is allowed between all WLCs in the mobility group.
Use tools like telnet (TCP test) or nc (netcat for UDP) to verify reachability.

Why Option B (mapping) is Correct?

The mapping Command Tests Mobility Tunnel Connectivity
The mapping command on the WLC checks if:
The UDP 16666 tunnel can be established.
The peer WLC is reachable.
If this fails, it confirms a network/firewall issue.

Why Other Options Are Incorrect?

Option C (mepping) – Typo, Invalid Command
This is a misspelling of mapping and does not exist as a valid command.

Option D (rping) – Not Relevant for Mobility Tunnels
rping is used for CAPWAP discovery, not mobility tunnel troubleshooting.

Option E (firewall IP protocol 97) – Incorrect Protocol
Protocol 97 is not used for mobility tunnels (they use UDP 16666).

This is a distractor with no relevance to WLC mobility.

Reference:
Cisco Wireless LAN Controller Configuration Guide
Mobility tunnels require UDP 16666 between controllers.
The mapping command is the primary tool for testing tunnel connectivity.

Firewall Requirements:
Must allow UDP 16666 bidirectional traffic between all WLCs in the mobility group.

Explanation:

Why Option C is Correct?

FlexConnect APs Require a FlexConnect Group for 802.11r Fast Transition (FT):

802.11r Fast Transition (FT) is supported on FlexConnect APs, but only if they are part of a FlexConnect group.

Without being in a FlexConnect group, the APs do not properly apply the WLAN’s 802.11r FT policies, leading to roaming failures.

Impact of Missing FlexConnect Group:

Local mode APs handle 802.11r FT natively, but FlexConnect APs require:

A FlexConnect group to enforce consistent roaming policies.

The WLAN’s 802.11r FT settings to be properly inherited.

If the APs are not in a group, they default to basic roaming, causing delays and voice quality issues.

Why Other Options Are Incorrect?

Option A: "They do not support 802.11r FT."

False. FlexConnect APs do support 802.11r FT, but only when properly configured in a FlexConnect group.

Option B: "They must be added into AP groups along with a common RF profile."

AP groups (different from FlexConnect groups) help with RF settings but do not enable 802.11r FT for FlexConnect APs.

Option D: "They must be added to AP groups to support fast roaming methods."

AP groups are for RF tuning, not 802.11r FT enforcement—FlexConnect groups are mandatory for FT.

Reference:

Cisco FlexConnect Deployment Guide

802.11r FT requires FlexConnect groups for proper roaming behavior.

Cisco Wireless LAN Controller Configuration Guide

FlexConnect APs must be in a group to apply advanced WLAN features like 802.11r.

Solution:

Create a FlexConnect group (if not existing).

Add the APs to the group.

Verify 802.11r FT is enabled on the WLAN.

Explanation:

Why Option D is Correct?

802.11v BSS Transition Management (BTM) Provides Roaming Recommendations

802.11v BTM allows APs to suggest or direct clients (especially VoWLAN devices) to roam to a better AP without forcing non-voice clients to comply.

This is ideal for VoWLAN because:

Voice clients get assisted roaming (better call quality).

Data clients remain unaffected (no forced roaming).

How It Works:

APs send BSS Transition Management frames to recommend roaming.

Voice clients (like IP phones) prioritize these hints for seamless handoffs.

Non-voice clients ignore suggestions if their connection is stable.

Why Other Options Are Incorrect?

Option A: 802.11r Fast Transition

802.11r speeds up reauthentication during roaming but does not provide roaming suggestions.

It’s useful for fast roaming but doesn’t differentiate between voice/data clients.

Option B: 802.11k Neighbor Lists

802.11k helps clients discover nearby APs but does not actively recommend roaming.

It’s a passive tool for scanning, not proactive steering like 802.11v.

Option C: CCKM with 802.1X

CCKM (Cisco Centralized Key Management) is for fast secure roaming (reduces reauthentication time).

It does not provide roaming recommendations—it’s purely a security optimization.

Reference:

Cisco Wireless LAN Configuration Guide, "802.11v BSS Transition Management"

Describes how BTM improves VoWLAN roaming without impacting data clients.

Cisco VoWLAN Design Best Practices

Recommends 802.11v for voice clients to reduce latency during calls.

Explanation:

Why Option A is Correct?

Sticky Client Problem occurs when wireless clients remain connected to a distant or weak AP (low RSSI) instead of roaming to a stronger one, degrading performance.

Configuring an RSSI Threshold forces clients to disconnect when their signal strength drops below a set level, encouraging them to roam to a better AP.

Example: Setting an RSSI threshold of -75 dBm ensures clients proactively seek a stronger AP before the connection degrades.

Optimized Roaming Feature relies on RSSI thresholds to improve client handoffs.

Why Other Options Are Incorrect?

Option B: Disable DFS

DFS (Dynamic Frequency Selection) is used for 5GHz channel selection and has no impact on sticky clients. Disabling it would reduce available channels, worsening performance.

Option C: Disable 802.11k

802.11k (Neighbor Reports) helps clients discover nearby APs for better roaming decisions. Disabling it would worsen roaming, not improve it.

Option D: Enable Data Rates

While adjusting data rates can influence client behavior, it does not directly solve sticky clients. RSSI thresholds are the proven method for forcing better roaming.

Reference:

Cisco Wireless LAN Controller Configuration Guide – Recommends RSSI thresholds for sticky client mitigation.

Enterprise Mobility 4.1 Design Guide – Highlights Optimized Roaming with RSSI-based client steering.

Explanation:

Why Option B (Kitchen) is Correct?

Microwave Ovens

Operate in the 2.4 GHz band (same as Wi-Fi) and cause significant interference.

Even modern "RF-shielded" microwaves can leak noise.

Bluetooth Devices (Wireless Headsets, Thermometers)

Many medical/kitchen Bluetooth devices use 2.4 GHz, adding to congestion.

Why Option E (Patient Room) is Correct?

Wireless Medical Devices

Patient monitors, infusion pumps, and IoT sensors often use 2.4 GHz or 5 GHz bands.

Example: Zigbee (2.4 GHz) for hospital equipment.

Wi-Fi Clients (Tablets, Smartphones, VoWiFi Phones)

High density of personal/medical devices leads to co-channel interference.

Why Other Options Are Incorrect?

Option A (Magnetic Resonance Imaging - MRI)

MRI machines generate strong magnetic fields, not RF noise in Wi-Fi bands.

They do not operate at 2.4/5 GHz; interference is rare unless poorly shielded.

Option C (Gamma Knife Radiation Treatment)

Gamma Knife uses focused gamma rays, not RF emissions.

No overlap with Wi-Fi frequencies.

Option D (X-ray Radiography)

X-rays are ionizing radiation, not RF signals.

They do not interfere with Wi-Fi.

Reference:

Cisco Wireless LAN Design Guide for Healthcare

Identifies kitchens and patient rooms as high-interference zones due to microwaves and medical IoT.

Explanation:

Why Option B is Correct?

RSSI (Received Signal Strength Indicator) for Voice Services

For VoWiFi (Voice over Wi-Fi), Cisco recommends a minimum RSSI of -67 dBm to ensure clear voice quality.

-67 dBm ensures sufficient signal strength for low-latency, jitter-free calls.

Lower values (e.g., -70 dBm or worse) lead to choppy audio and dropped calls.

Why Option C is Correct?

Retransmission Rate for Voice Quality

A retransmission rate ≤ 15% is critical for voice traffic.

High retransmissions (>15%) indicate:

Interference (co-channel or non-Wi-Fi).

Poor signal strength (weak RSSI).

Congestion (too many clients).

Voice traffic is latency-sensitive, so excessive retransmissions degrade call quality.

Why Other Options Are Incorrect?

Option A: Noise floor ≤ -87 dBm
While a low noise floor is good, -87 dBm is too lenient for voice.

Cisco recommends ≤ -90 dBm for voice networks.

Option D: Retransmissions ≤ 20%
20% is too high for voice.

VoWiFi requires ≤ 15% for acceptable quality.

Option E: RSSI ≥ -65 dBm
While -65 dBm is excellent, -67 dBm is the Cisco minimum requirement.

This option is too strict for general deployment.

Reference:
Cisco VoWLAN Design Guide (7925G/8821 IP Phones)
RSSI ≥ -67 dBm for voice coverage.

Retransmissions ≤ 15% for reliable voice.

CWNP (Certified Wireless Network Professional) Voice over Wi-Fi Best Practices

Confirms 15% retransmission threshold for voice.