JNCIA-DC common mistakes
JNCIA-DC · Understand the traps and how to avoid them.
Treating a collapsed core (spine-leaf) fabric as if it were a traditional three-tier design, so the candidate describes access switches uplinking to distribution and distribution to core, and then misplaces EVPN/VXLAN roles when asked where routing happens.
Most study material and prior experience come from campus three-tier networks; the candidate maps 'core' and 'access' onto spine and leaf by name rather than by function, and never internalizes that every leaf is an IP router with equal-cost paths to every other leaf.
What to do instead
Draw the reference topology from memory until it is automatic: spines are pure IP underlay and route reflectors, leaves are VTEPs and default gateways, servers dual-home to two leaves in a LAG or with EVPN multihoming. For each device, write one sentence stating its forwarding role and its control-plane role, then answer practice questions by checking which role the question is testing.
Confusing an MC-LAG (multichassis LAG) with a standard LAG and with EVPN multihoming, claiming that MC-LAG requires VXLAN or that EVPN multihoming requires ICCP, or stating that a server dual-homed with MC-LAG needs two IP addresses.
These three technologies solve overlapping problems (redundant server attachment) but use different control protocols and different failure semantics; the candidate learns them in separate chapters and never builds a comparison table, so details bleed together under exam pressure.
What to do instead
Build a three-row comparison covering: control protocol (LACP to both peers vs ICCP between peers vs EVPN Ethernet segment routes), whether the server sees one or two links, active-active versus active-standby behavior, and what happens on a single peer failure. Re-derive the table weekly from the configuration hierarchy rather than from memory.
Assuming all Junos CLI modes behave like operational mode: the candidate types a configuration command at the > prompt, or expects 'show configuration' output to reflect uncommitted changes, or believes 'commit' takes effect immediately on all Routing Engines in a dual-RE chassis.
Junos has a strict separation between operational mode (>) and configuration mode (#), a candidate/active/committed configuration model, and per-RE commit behavior; candidates coming from single-mode CLIs (or from IOS) expect edits to be live the moment they are typed.
What to do instead
Practice the full cycle deliberately: edit, 'show | compare', 'commit check', 'commit', then 'rollback 1' and 'commit'. In a dual-RE lab, observe 'commit synchronize' versus a plain commit and note which RE receives the change. Memorize that 'show configuration' displays the committed configuration while 'show | display set' in configuration mode shows the candidate.
Misreading the pipe and filter syntax: using '| match' when '| find' or '| except' is needed, putting the pipe in the wrong place, or expecting '| display set' to work in operational mode. The candidate also cannot predict what 'show configuration | display set' versus 'show configuration | display inheritance' will reveal.
Junos pipes are powerful and heavily tested, but candidates memorize a few examples instead of the general rule that pipes transform text output and that some pipes are configuration-mode only. They also forget that inherited values (from groups or apply-groups) are hidden unless explicitly requested.
What to do instead
Learn the small set cold: match, except, find, count, display set, display inheritance, display xml, no-more. For each, write the mode it works in and one realistic use. Then in a lab, apply a configuration group and prove that the value is active but invisible without 'display inheritance'.
Configuring an interface and then being unable to explain why it stays down: the candidate forgets 'set interfaces xe-0/0/0 unit 0 family inet address ...', forgets to enable the physical port, or mixes up 'disable' at the interface level with a missing unit or family, and then blames the commit.
Junos interface configuration is hierarchical (physical interface, unit, family, address) and a missing layer produces a down or unusable interface without an obvious error at commit time. Candidates who configure by rote from a single example miss which layer carries which setting.
What to do instead
Adopt a fixed checklist for every new interface: physical port enabled, speed/MTU if non-default, unit created, family declared, address or DHCP assigned, then verify with 'show interfaces xe-0/0/0 terse' and 'show interfaces xe-0/0/0 extensive | match Flags'. Practice reading the Flags line to distinguish admin down from link down.
Treating firewall filters as if they were stateful firewalls: the candidate writes a filter that permits inbound traffic and expects the return traffic to pass automatically, or places a filter on the wrong interface or wrong direction and then cannot explain why pings fail in one direction only.
Junos firewall filters are stateless and evaluated per interface per direction; the candidate's mental model comes from zone-based stateful firewalls, so the need for an explicit term for return traffic, and for a final implicit discard, is not internalized.
What to do instead
For every filter you write, state out loud: interface, direction (ingress/egress), term order, match conditions, action, and the implicit discard at the end. Then test with a one-way ping and a traceroute to prove which direction is filtered. Remember that a filter with no matching term discards, so always include an explicit permit or a counted discard for visibility.
Confusing routing policy with firewall filters: the candidate uses a firewall filter to try to redistribute or filter routes, or uses a policy-statement to try to block transit packets, and cannot say at which point in the BGP/OSPF pipeline a policy is applied.
Both use term/match/action syntax and both are 'filters' in ordinary language, but one acts on packets in the forwarding path and the other acts on routes in the control plane. The candidate learns syntax first and semantics second.
What to do instead
Anchor each tool to its object: firewall filters act on packets and live under 'firewall family ... filter'; policy-statements act on routes and are referenced by import/export on a protocol or by 'export' on a routing instance. For BGP, memorize the order import policy, then route selection, then export policy, and draw it once on paper.
Getting BGP path selection order wrong: the candidate ranks local preference below AS path length, or forgets that weight is Cisco-style and not the first tiebreaker in Junos, or ignores that a route must be valid and have a next hop reachable before it is even considered.
Junos uses its own preference values and an ordered decision process, and many candidates carry over Cisco's weight/local-pref/AS-path ordering. The exam tests the Junos order specifically, and the first few steps (protocol preference, then local preference) are where most errors occur.
What to do instead
Write the Junos order from memory repeatedly: protocol preference (route preference values), then local preference (higher wins), then AS path length, origin, MED, eBGP over iBGP, IGP cost to next hop, router ID. Verify with 'show route detail' and read the 'best' annotation, then change one attribute in a lab and watch the selection change.
Ignoring commit-time behavior and recovery: the candidate commits a change that locks them out, or cannot recall how to recover when a commit fails or when the configuration is committed but wrong. They also do not know the difference between 'commit confirmed' and a normal commit.
Junos offers rollback, commit confirmed, and rescue configurations, but candidates practice only happy-path commits. Under exam questions about a failed remote change, they guess instead of describing the rollback timer.
What to do instead
In a lab, deliberately break remote access and recover using 'commit confirmed 5' followed by letting the timer expire, and separately using 'rollback 1'. Also create and load a rescue configuration. Memorize that commit confirmed automatically reverts unless confirmed within the timer, which is the safe pattern for remote changes.
Misreading monitoring output: the candidate cannot distinguish 'show route' from 'show route forwarding-table', treats a route in the forwarding table as proof of end-to-end reachability, or ignores interface error counters and queue drops when asked to diagnose a performance problem.
Junos separates the control-plane routing table from the data-plane forwarding table, and monitoring commands each answer a different question. Candidates scan for a familiar-looking output and stop at the first plausible line instead of interpreting counters and flags.
What to do instead
For each monitoring task, name the question first, then the command: is the route learned (show route), is it installed (show route forwarding-table), is the interface healthy (show interfaces extensive, check errors and drops), is the filter counting (show firewall). Practice explaining a single output line by line until you can state what would change if the problem were elsewhere.