CCNA common mistakes
CCNA · Understand the traps and how to avoid them.
Subnetting by writing out binary for every question instead of using the block-size (magic number) shortcut, which burns 3-5 minutes per question and leaves the simulation/lab items at the end of the exam unreached.
Most candidates learn binary conversion first and never drill the 256-minus-mask-mask-octet method, so every subnet question becomes long division in base 2 under a clock.
What to do instead
Drill the shortcut daily: mask octet -> block size -> valid subnets -> broadcast. Target under 20 seconds for any /17 through /30 question. Practice on 10 random 'given 192.168.44.0/27, list the third subnet, its range, and broadcast' prompts and time yourself.
Classifying a fault to the wrong OSI layer: labeling a VLAN mismatch or native-VLAN mismatch as a Layer 1 problem, placing ARP at Layer 2 only, or saying a switch 'routes' frames.
Layers get memorized as a list of seven names and one keyword each, not as an encapsulation model, so symptoms that straddle layers (MTU, duplex mismatch, VLAN tagging, ARP) have no anchor.
What to do instead
For each layer write the PDU name, the addressing used, the device that acts there, and two real symptoms. Then take 20 trouble tickets and force yourself to name the layer plus one command that would prove it (show interfaces, show mac address-table, show arp, show ip route).
Troubleshooting a trunk that 'isn't passing VLANs' by only re-typing 'switchport mode trunk', without comparing the allowed VLAN list, the native VLAN on both ends, and whether DTP negotiated the link as access.
Practice labs use default trunks between directly connected switches, so allowed-list and native-VLAN mismatches never appear until the exam presents a partially configured topology.
What to do instead
Build a fixed trunk checklist you run every time: show interfaces trunk (mode, encapsulation, native VLAN, allowed and active VLANs), show interfaces switchport on both ends, and compare native VLANs. Configure 'switchport nonegotiate' with an explicit 'switchport trunk allowed vlan' in labs so you see the failure modes.
Configuring OSPF and moving on without checking adjacency, so the router has no routes but the config 'looks right'; also writing 'network 10.0.0.0 255.255.255.0 area 0' as if it were a subnet mask.
OSPF takes the config silently - a hello/dead timer, area ID, MTU, stub flag, or authentication mismatch just leaves neighbors stuck in INIT/EXSTART with no error message, and the network statement wildcard mask is easy to type as a normal mask.
What to do instead
Make 'show ip ospf neighbor' mandatory after every OSPF change and require FULL/DR or FULL/BDR before continuing. Drill wildcard conversion (255.255.255.255 minus the mask) and memorize the default hello/dead timers for broadcast (10/40) and non-broadcast (30/120).
Picking a route by lowest metric or by 'most specific-looking' instead of applying longest prefix match first, then administrative distance, then metric.
Study material teaches AD and metric as separate facts, so candidates default to whichever number is smaller across routes learned from different sources.
What to do instead
Recite the order out loud every time: longest prefix match wins outright; only among equal prefixes compare AD; only among equal prefix and equal AD compare metric. Work 10 sets of five competing routes and write the elimination reason next to each losing route.
Placing a DHCP server on a different subnet from the clients and never configuring 'ip helper-address' on the client-facing router interface, then blaming the DHCP pool.
Nearly every practice lab puts the DHCP server on the same LAN, so broadcast containment by the router never becomes visible as a failure.
What to do instead
Lab it deliberately: one router, two LANs, DHCP server on LAN B, clients on LAN A. Confirm clients fail, add ip helper-address pointing at the server, and verify with 'show ip dhcp binding' and 'show ip dhcp conflict'. Note that the helper forwards to UDP 67 using the interface address as source.
Building a static NAT or PAT config that looks complete but never marks the interfaces 'ip nat inside' / 'ip nat outside', and never verifies with 'show ip nat translations' or 'debug ip nat'.
NAT syntax is order-dependent and a missing interface designation produces zero errors - packets simply aren't translated, which reads as a routing problem.
What to do instead
Use a fixed four-step build order and check it each time: (1) mark inside/outside interfaces, (2) define the match ACL or 'nat inside source list/interface overload', (3) apply to the correct interface and direction, (4) verify with show ip nat translations, show ip nat statistics, and clear ip nat translation * before retesting.
Treating the three port-security violation modes as interchangeable, and forgetting that a shutdown violation err-disables the port with no automatic recovery.
The mode names are memorized as a list without the behavior table, so protect/restrict/shutdown get swapped under pressure, and errdisable recovery timers are assumed to be on by default when they are off.
What to do instead
Write the three-column table once - protect (drops, no log, no counter increment), restrict (drops, logs, increments violation counter), shutdown (err-disables, logs, counter) - and lab each mode with 'show port-security interface'. Then add 'errdisable recovery cause psecure-violation' and verify with 'show errdisable recovery'.
Assuming Ansible requires an agent on managed devices, or swapping YANG for NETCONF/RESTCONF as if they were the same thing, and describing the controller as forwarding traffic.
The automation domain is often skimmed because it 'isn't networking', so the tool/protocol/model layers blur into undifferentiated buzzwords.
What to do instead
Build a one-page matrix with rows for Ansible, Puppet, Chef, and columns for agent vs agentless, push vs pull, language, and transport. Separately define the stack: YANG = the data model, NETCONF/RESTCONF = the transport/protocol carrying it, SNMP = legacy monitoring. State clearly that the controller manages the control plane and does not forward data-plane traffic.
Memorizing controller names (DNA Center, APIC, WLC) without being able to say which plane each acts on or what a northbound versus southbound API is used for.
SDN questions are answered by name recognition rather than by the control-plane/data-plane split, so any question phrased around APIs or flows breaks the pattern.
What to do instead
For each controller write: what it manages, whether it is on-prem or cloud, the interface it uses southbound to devices (CLI/SNMP/NETCONF), and the northbound interface it offers to applications (REST API). Practice explaining in two sentences how a centralized control plane differs from a distributed one on traditional routers.