CNEn common mistakes
CNEn · Understand the traps and how to avoid them.
Treating the OSI/TCP-IP model as pure memorisation and failing to map a described symptom to the correct layer before choosing an answer.
Candidates memorise layer names and PDUs but never practise translating real symptoms (duplex mismatch, MTU black hole, ARP failure) into a layer, so scenario questions that require layer-first reasoning feel ambiguous.
What to do instead
Build a one-page table of layers against concrete evidence at each layer (cable/link LEDs, MAC/ARP tables, IP/TTL and ICMP, ports and sequence numbers, session state, encoding). For 30 practice scenarios, write the layer and the evidence before looking at answer choices.
Confusing broadcast domains, collision domains, and VLAN boundaries when counting or predicting traffic behaviour in a switched topology description.
Textbook definitions are learned separately from switch behaviour, so candidates forget that each VLAN is a separate broadcast domain and that a router or Layer 3 switch is required to move between them.
What to do instead
Redraw topologies from word problems, labelling every port as access or trunk and marking each broadcast domain boundary. Practise counting broadcast domains in topologies with VLANs, trunks, and a router-on-a-stick until the count is automatic.
Choosing a routing protocol or path by preference alone, ignoring administrative distance, longest-prefix match, and metric tie-breaking.
Candidates learn protocol features in isolation and then apply 'lower AD wins' without checking prefix length first, or forget that the routing table installs only the best route per prefix.
What to do instead
Work through a fixed decision order for every routing question: longest prefix match, then administrative distance, then metric, then equal-cost multipath. Drill with tables containing overlapping static, OSPF, and EIGRP entries and state the winning route and why.
Misreading spanning tree and switch-port state questions, such as assuming a blocked port forwards or that all trunk ports are root ports.
STP is learned as a list of states and timers rather than as a root-election and path-cost process, so candidates cannot trace which port blocks in a described topology.
What to do instead
Practise full STP walks: elect the root by lowest bridge ID, compute root path cost to each switch, then assign root, designated, and blocked ports. Confirm that a blocked port still receives BPDUs but does not forward data frames.
Treating a firewall rule set as first-match or last-match inconsistently, or forgetting that stateful inspection permits return traffic without an explicit inbound rule.
Candidates mix implicit deny, rule ordering, and stateful return-traffic behaviour, so they predict the wrong permit or deny outcome for a described flow.
What to do instead
For each scenario, list rules in evaluation order, mark the first matching rule, and note whether the device is stateful. Practise with asymmetric flows and return traffic to confirm that established sessions are allowed while new inbound sessions are dropped.
Confusing authentication, authorisation, and accounting, or misplacing 802.1X roles (supplicant, authenticator, authentication server) in a described deployment.
The three A's are memorised as a phrase and 802.1X as a diagram, so candidates cannot say which component makes the decision or which protocol carries credentials.
What to do instead
Write a short narrative for one wired and one wireless 802.1X flow naming each role and the protocol between each pair (EAP over LAN to the authenticator, RADIUS to the server). Then classify ten access-control statements as authentication, authorisation, or accounting.
Mixing up DHCP and DNS failure symptoms, such as blaming DNS when a client has an APIPA address or blaming DHCP when resolution fails but pings to IP addresses succeed.
Both are 'the network is broken' complaints, and candidates skip the quick discriminating tests, so they pick a plausible but wrong root cause.
What to do instead
Memorise a short triage sequence: check the client address (169.254.x.x means DHCP failure), then ping a known IP, then resolve a name. Apply this sequence to every service-failure scenario and state which layer or service is implicated.
Ignoring NAT and PAT translation when predicting end-to-end connectivity or reading a capture, assuming private addresses appear unchanged on the internet side.
NAT is studied as a configuration topic rather than as a packet-transformation step, so candidates forget that source addresses and ports are rewritten and that inbound sessions need a static mapping or port forwarding.
What to do instead
Trace a packet hop by hop through a NAT device, writing the source and destination address and port before and after translation. Practise explaining why an internal web server is unreachable from outside without a static NAT entry.
Jumping to a conclusion from a single command output instead of following a structured troubleshooting method and verifying with a second data point.
Exam questions reward the first plausible clue, and candidates under time pressure skip the layered verification that real troubleshooting requires, so they miss distractor answers built on partial evidence.
What to do instead
Use a fixed loop for every scenario: define the problem, identify the affected layer, form one hypothesis, choose the cheapest test, then confirm or reject. Always name the second command or observation that would confirm the diagnosis before selecting an answer.
Treating cloud, SD-WAN, and overlay concepts as marketing vocabulary rather than as concrete forwarding and control-plane models, leading to wrong answers about where policy is enforced.
These topics are newer and less practised, so candidates memorise terms without learning the data plane versus control plane split, tunnel encapsulation, or the difference between underlay and overlay reachability.
What to do instead
For each technology, draw the control plane, data plane, and encapsulation, and state where policy is applied. Compare a traditional WAN, an SD-WAN with a central controller, and an overlay tunnel in one table, then answer questions about which component makes forwarding decisions.