JNCIA-Junos common mistakes
JNCIA-Junos · Understand the traps and how to avoid them.
When sizing a subnet they assign the subnet's network or broadcast address to a host, or compute usable addresses as 2^n instead of 2^n-2.
They memorised '/24 = 254 hosts' and then extrapolate by guesswork rather than recomputing the block for the actual mask length.
What to do instead
For any mask, compute the block size (256 minus the interesting octet), list each subnet's range, and cross off the first and last address. Usable hosts = 2^host-bits - 2; verify with a quick binary conversion of the fourth octet.
They confirm a link shows 'up/up' with show interfaces terse and conclude traffic should flow, then stop investigating when it doesn't.
Junos separates physical link state from logical configuration, so an interface with no logical unit, no family inet address, or the wrong encapsulation still reports Link up.
What to do instead
Check the logical layer explicitly: show interfaces terse for the unit line, show interfaces extensive for the configured address and counters, and show configuration interfaces to confirm 'unit 0 family inet address'.
They type set commands at the operational prompt, or type show commands inside configuration mode, and read the resulting syntax error as proof the feature is unsupported.
Junos has two distinct CLI modes whose prompts differ by a single character (> versus #), and the error text does not say 'wrong mode'.
What to do instead
Read the prompt character before typing. Use configure to enter configuration mode and exit configuration-mode to leave it, or prefix an operational command with run while inside configuration mode.
They use rollback 1 to undo set commands they just typed but have not committed, and are surprised that nothing changes.
Rollback walks the commit history of already-committed configurations; it does not touch uncommitted candidate edits, so the candidate still holds their changes.
What to do instead
Use rollback 0 to discard all uncommitted candidate changes back to the active configuration, and use show | compare before committing to see candidate versus active differences.
They make a change to an interface address, a management-access setting, or an input firewall filter with a plain commit and lock themselves out of the device.
A plain commit takes effect immediately and persistently; a reachability mistake or a filter that discards their own management session cannot be undone remotely.
What to do instead
Use commit confirmed for any change that could sever access; the device auto-rolls back unless a plain commit is issued before the timer expires. Practise the habit even in labs.
They troubleshoot using only show interfaces terse and show route output, and never look at the system log.
Interface flaps, commit failures, authentication failures and protocol errors are recorded in the messages log, so they are invisible in interface and route tables.
What to do instead
Make show log messages | match (or | last ) a routine step, together with show chassis alarms and show system alarms, before changing any configuration.
They configure a static route for a prefix and assume it is being used, without checking whether it is hidden or less preferred than a competing dynamic route.
Junos selects by preference (static 5, OSPF 10, eBGP 170), and a route can appear in show route while being hidden or inactive for another reason.
What to do instead
Run show route detail and show route hidden, compare the Preference column and the status flags, and resolve it by adjusting preference or removing the competing route.
After enabling OSPF on an interface they assume the adjacency will form, without checking area, MTU, hello/dead timers or interface type.
A mismatched area, mismatched MTU (a classic cause of a neighbour stuck in ExStart/Exchange on Ethernet), or a passive interface silently prevents the adjacency.
What to do instead
Verify with show ospf neighbor and show ospf interface detail; match the area and MTU on both sides, match hello/dead timers, and remove passive from interfaces that must form adjacencies.
They write a firewall filter whose only term discards bad traffic and assume everything else is denied.
The implicit default of a filter is accept, so unmatched traffic passes; and forgetting to bind the filter to the correct interface and direction means nothing is filtered at all.
What to do instead
End every filter with an explicit term default-discard then discard, bind it with set interfaces unit 0 family inet filter input , and confirm counters increment with show firewall filter .
They build a policy-statement with a prefix-list and a then reject, but never reference it in export or import, or expect the reject to drop transit packets.
Routing policy only controls which routes are accepted into or advertised from the routing table; an unattached policy does nothing, and a rejected route does not block packets.
What to do instead
Attach the policy (for example set protocols bgp group export or set protocols ospf export ), verify with show route advertising-protocol bgp or show route detail, and use a firewall filter when the goal is to drop packets.