CNEpv common mistakes
CNEpv · Understand the traps and how to avoid them.
Treating the OSI model as a vocabulary quiz instead of using it as a diagnostic ladder, so when asked at which layer a given symptom occurs the candidate guesses by keyword association.
Most study material presents the seven layers as a list to memorize, and candidates never practice mapping concrete failures (duplicate MAC, MTU black hole, TLS handshake failure) onto a layer. Under time pressure they pattern-match on words like 'frame' or 'packet' rather than reasoning about encapsulation boundaries.
What to do instead
Build a one-page mapping table with a real symptom per layer per device type, then rehearse 20 short scenarios where you must state the layer, the evidence you would collect, and the next troubleshooting step. Force yourself to justify the layer by naming the PDU and the address type involved.
Confusing collision domains with broadcast domains when evaluating a topology, and assuming a switch port is always its own collision domain regardless of duplex or hub presence.
Candidates memorize 'a switch breaks collision domains, a router breaks broadcast domains' as a slogan but never work through mixed topologies containing hubs, unmanaged switches, and VLANs, where the slogan produces the wrong count.
What to do instead
Redraw five mixed topologies by hand and count both domains per segment, annotating which device terminates which. Include one hub-uplink case and one VLAN case, and state explicitly why a router interface is a broadcast boundary.
Selecting a routing protocol or path based on administrative distance alone while ignoring prefix length, so a longer-match answer is missed whenever AD and mask length point in different directions.
AD tables are easy to memorize and appear frequently in study guides, which trains candidates to compare AD first. Longest-prefix-match is the actual forwarding rule, and questions that deliberately set a /24 via a worse AD against a /16 via a better AD expose the habit.
What to do instead
Adopt a fixed decision order for every path-selection question: longest prefix first, then AD, then metric, then equal-cost load balancing. Practice ten route-table exhibits where you must state the winning entry and the exact tiebreaker used.
Misapplying Spanning Tree behaviour, such as assuming a blocked port forwards user traffic, that RSTP still uses the full 802.1D timer sequence, or that a root bridge is elected by lowest bridge ID including priority only.
STP is taught as port states and timers with little emphasis on the bridge ID composition (priority plus MAC) and on RSTP's proposal-agreement mechanism. Candidates then apply classic 802.1D assumptions to RSTP questions or forget that the root port selection depends on path cost to the root.
What to do instead
Work through root election and port-role assignment on a five-switch triangle by hand, computing bridge IDs and cumulative costs. Then repeat the same topology under RSTP and note which convergence steps disappear. Verify each answer against the port state's actual forwarding behaviour.
Answering security questions by naming a control category (for example 'use MFA' or 'segment the network') without matching it to the threat being mitigated or the layer where the attack occurs.
Candidates study controls as a checklist and study attacks as a separate checklist, so they never build the link between them. Exam items that describe an attack pattern and ask for the most effective mitigation then trigger a recall of the most familiar control rather than the most relevant one.
What to do instead
For each attack you study (ARP spoofing, VLAN hopping, DHCP starvation, on-path interception, credential replay), write the attack's prerequisite, the layer it abuses, and two mitigations ranked by effectiveness. Rehearse explaining why the second-best mitigation is insufficient.
Treating 802.1X, RADIUS, and NAC as interchangeable, and placing authentication at the wrong point in the flow (for example assuming the switch validates credentials or that the supplicant talks directly to the RADIUS server).
The three components are usually introduced together in a single paragraph, so their distinct roles blur. Candidates also forget that EAPoL runs between supplicant and authenticator while RADIUS carries the encapsulated EAP exchange to the authentication server.
What to do instead
Draw the three-party exchange as a sequence diagram with the message names on each leg, then label which device makes the authorization decision and which enforces it. Add one case with MAB fallback and one with dynamic VLAN assignment, and state where each fails.
Reading monitoring output literally without correlating interfaces, so a question about a degraded link is answered from a single counter (often CRC errors or utilization) instead of from the direction and pattern of errors across both ends.
Candidates learn individual show commands and their counters but not how counters relate. They do not know that input errors and CRCs point toward the local receive path and cabling, while output drops point toward congestion or egress policy, so they pick whichever counter name looks familiar.
What to do instead
Build a counter-to-cause matrix (CRC and input errors, runts, giants, late collisions, output drops, interface resets) with the likely cause and the confirming command for each. Practice diagnosing a duplex mismatch and a congested uplink using counters from both ends of the link.
Jumping to a configuration change as the answer to a troubleshooting scenario before establishing a baseline or verifying the fault domain, and choosing the 'most likely fix' over the 'next diagnostic step' the question actually asks for.
Candidates read the scenario as a repair task because that is how hands-on experience feels, and they skim the final clause of the stem. Structured methodology is also rarely practised, so there is no habit of narrowing scope before acting.
What to do instead
Before answering any scenario item, underline the requested action verb (verify, isolate, mitigate, restore) and answer only that. Rehearse a fixed sequence: define the symptom, establish what changed, test from the closest point outward, then propose the fix last.
Confusing configuration management and orchestration tooling roles, such as assuming Ansible requires an agent, that NETCONF replaces YANG, or that RESTCONF uses a different data model from NETCONF.
The automation domain packs many overlapping terms (NETCONF, RESTCONF, YANG, gNMI, Ansible, Terraform, model-driven telemetry) into a short syllabus, and candidates learn the acronym expansions without learning the division of labour between transport, encoding, and data model.
What to do instead
Draw a layered diagram separating transport (SSH, HTTPS, gRPC), encoding (XML, JSON, protobuf), data model (YANG), and tooling (agentless versus agent-based). For each named technology, place it on the diagram and state one thing it does not do.
Treating cloud networking as a renamed version of on-premises networking, for example assuming security groups are stateful like ACLs, that subnets span availability zones, or that overlay tunnels change the underlying routing requirements.
Candidates transfer on-premises mental models to cloud constructs without checking where the abstractions differ. Statefulness, distributed enforcement, and the separation of control plane from data plane are exactly the points exam items probe, and the familiar analogy produces a confident wrong answer.
What to do instead
For each cloud construct you study (security group, network ACL, VPC subnet, route table, load balancer, overlay segment), write one sentence on how it differs from its on-premises counterpart. Include one stateful-versus-stateless comparison and one failure scenario caused by assuming the analogy holds.