Cisco WLCOR 350-101 common mistakes
Cisco WLCOR 350-101 · Understand the traps and how to avoid them.
Computes EIRP or link budget by adding/subtracting milliwatt and dBi values directly (e.g., '20 mW radio plus 6 dBi antenna = 26 mW EIRP', or '30 dBm minus 3 dB gain = 27 mW').
Candidates memorize the dBm-to-mW table but never internalize that dBi and dB are logarithmic ratios, so they treat all the numbers on the worksheet as plain arithmetic. Under exam pressure the familiar 'add the numbers' habit wins.
What to do instead
Before answering any RF math item, convert every power to dBm and every gain/loss to dB, then add/subtract. Drill the anchors: 0 dBm = 1 mW, 10 dBm = 10 mW, 20 dBm = 100 mW, +3 dB = double, +10 dB = ten times, -3 dB = half. Do ten conversion reps daily for a week so the mW-to-dBm step becomes automatic.
Selects an 80 MHz channel width for a high-density office or warehouse because 'wider channel means more throughput and better performance', and treats 40/80 MHz as strictly better than 20 MHz.
Consumer router marketing and home-lab experience equate channel width with speed; candidates never see the noise-floor and co-channel-reuse consequences of wide channels in a real enterprise design.
What to do instead
Restate the trade-off explicitly when practicing design items: wider channels bundle subcarriers but also admit more noise energy, lower SNR per subcarrier, and consume adjacent spectrum, cutting the number of non-overlapping channels (three in 2.4 GHz, and far fewer 80 MHz channels in 5 GHz than 20 MHz channels). Default to 20 MHz for high-density and voice; reserve 40/80 MHz for low-density, high-throughput areas and 6 GHz when channel availability allows.
Submits a design based solely on a predictive/planning-tool heat map and describes the project as having 'completed a site survey'; cannot distinguish predictive, passive, active, and AP-on-a-stick surveys or state what each one produces.
Planning software output looks authoritative and final, and the four survey types overlap conceptually, so candidates collapse them into one generic 'site survey' bucket and answer questions about validation with planning-tool language.
What to do instead
Build a one-line definition for each type: predictive = software model from floor plans, no on-site measurement; passive = listens to existing APs to characterize the RF environment; active = associates to APs and measures real client-experienced throughput/coverage; AP-on-a-stick = temporarily mounts an AP at candidate locations to validate final placement and settings. Memorize that AP-on-a-stick validates the completed design, and that a predictive model is a starting point requiring validation, not a survey result.
Designs coverage against a single threshold (e.g., '-67 dBm everywhere') and ignores secondary/overlap coverage, SNR, and the number of APs audible at a given cell edge, then is surprised by roaming and voice-quality questions.
Candidates latch onto one memorable number from study material and use it as the whole design rule; the concept that cell-edge roaming depends on hearing multiple APs at a usable level is easy to read but rarely rehearsed.
What to do instead
When a design scenario appears, write out all three checks: primary coverage at the target RSSI for the service (voice tighter than data), secondary coverage at roughly -75 dBm from at least a second AP to support roaming and redundancy, and SNR of 25 dB or better for voice and 20 dB or better for data. Tie each check to the service type in the question before choosing an AP count or power setting.
States that all CAPWAP traffic between AP and controller is encrypted by default, or cannot say which CAPWAP port carries control versus data (e.g., claims both use 5246, or that data DTLS is on by default).
CAPWAP is usually taught as one protocol with one numbered port, so the control/data split and the default encryption asymmetry look like trivia rather than a design decision that changes how you troubleshoot.
What to do instead
Memorize the pair: control is UDP 5246 and is DTLS-encrypted by default; data is UDP 5247 and is unencrypted by default, with data DTLS an optional per-AP/per-WLAN enable. Practice by writing the two-channel diagram from memory (control tunnel plus data tunnel) and labeling encryption state and port on each, then explain what a packet capture of each would reveal.
Assumes FlexConnect APs behave like local-mode APs and always tunnel client traffic to the controller, or conversely assumes central web authentication and central DHCP still function when the AP is in standalone mode.
FlexConnect is taught as a feature list rather than as a state machine (connected vs standalone), so candidates learn 'local switching exists' but never map which services survive WAN loss.
What to do instead
Draw a two-column table for connected versus standalone FlexConnect: local switching with central or local auth, local DHCP fallback, and which WLANs continue to serve clients in standalone. Study each service's dependency on the controller (web auth portal, central DHCP, central switching) and answer scenario questions by first asking 'is the AP connected or standalone?'
Claims the controller or AP decides when a client roams, or states that 802.11r is required for every client to roam successfully, mixing up the roles of 802.11k, 802.11v, and 802.11r.
Fast-roaming features are presented together as a 'roaming toolkit', so candidates assign capabilities to the wrong standard and lose track of the fundamental rule that the client makes the roaming decision.
What to do instead
Anchor each standard to one sentence: 802.11k = neighbor reports so the client knows what else is out there; 802.11v = BSS Transition Management so the network can suggest a target; 802.11r = fast BSS transition (FT) to pre-establish keys, over-the-air or over-the-DS. Always restate that the roaming decision belongs to the client and the infrastructure can only assist, then check the client's supported capabilities before promising fast roaming.
Treats a mobility group and a mobility tunnel as the same thing, asserting that all client traffic between two controllers crosses the mobility tunnel, or that guest anchoring is required for normal inter-controller roaming.
Both concepts are named 'mobility' and appear in the same configuration menu, so the control-plane purpose of the group (exchanging client database and roam messages) blurs into the data-plane purpose of the tunnel (forwarding traffic for anchored clients).
What to do instead
Separate the two by plane: a mobility group is the control relationship among controllers that share client information and coordinate roams; a mobility tunnel carries data and is built for specific cases such as guest anchoring or clients that must stay anchored to a home controller. For each scenario question, first decide whether the question is about a client roaming between controllers (group) or traffic being forwarded to an anchor (tunnel).
Assumes PMF (802.11w) is optional or off by default in every case, or equates WPA3-Enterprise with the 192-bit suite without noting that WPA3 requires PMF, and mixes Layer 2 policy (open, PSK, 802.1X, SAE) with Layer 3 policy (web auth, passthrough, centralized web auth).
Security material is studied as a list of checkbox features per WLAN, so dependencies between features (WPA3 implies PMF; web policy applies after Layer 2 completes) are never modeled, and mixed L2/L3 questions expose the gap.
What to do instead
Build a WLAN decision tree: pick Layer 2 security first (open, PSK/SAE, 802.1X, WPA3 modes), then Layer 3 policy (web passthrough/consent/auth, or none), then note dependencies (WPA3 requires PMF; PMF has disabled/optional/required settings and can break legacy clients when required). Answer security items by walking the tree in order and stating the dependency out loud before selecting an option.
Jumps straight to RF remediation (power, channel, RRM) on any client complaint, or misreads the controller's client state and exclusion reason, skipping the ordered check of association, authentication, DHCP, DNS, and AAA reachability.
RF tuning is the most rehearsed part of the material and the client detail page shows alarming-looking states, so candidates act on the loudest signal instead of following a layered isolation method.
What to do instead
Use a fixed order for every troubleshooting scenario: is the client associating (SSID, band, RSSI/SNR), did 802.1X/PSK/portal complete, did it get an address (DHCP reachability, VLAN mapping on the port or FlexConnect AP), can it resolve and reach the default gateway, then is AAA/ISE returning the right result. Read the exact client state and exclusion reason text as evidence rather than guessing, and only move to RF once L2-L4 checks pass.