JNCIE-ENT common mistakes
JNCIE-ENT · Understand the traps and how to avoid them.
Committing a candidate configuration and walking away without verifying that the commit actually completed and that the box is still reachable, then discovering minutes later that a management-path change or a filter on lo0 locked the candidate out of the device.
JNCIE-ENT labs are timed and candidates chain commit, test, and next task quickly. Junos applies commit synchronously but a bad change to the management VRF, a firewall filter applied to lo0, or an interface disable can sever the very session used to verify. Candidates assume 'commit complete' means 'device usable'.
What to do instead
Before any change touching lo0, management interfaces, routing instances carrying management, or interface disable, stage a rollback safeguard: use 'commit confirmed 5' so the commit auto-reverts unless confirmed, and keep an out-of-band console or second session open. After commit, verify with 'show system commit', 'show interfaces terse', and a ping from the management subnet before moving on.
Configuring syslog, SNMP, or telemetry targets and never validating that messages actually arrive, so the monitoring task is marked wrong because the host, facility, or severity filter silently drops everything.
Candidates copy a logging host stanza but forget that Junos requires 'set system syslog host any any' plus an explicit 'set system syslog file messages any any' style of matching; severity 'none' or a wrong facility means nothing is forwarded. SNMP similarly needs community plus allowed client list.
What to do instead
Build a minimal known-good stanza: 'set system syslog host 192.0.2.10 any any', 'set system syslog host 192.0.2.10 explicit-priority', then generate a test event (e.g., login or interface flap) and confirm with 'show log messages | match '. For SNMP, verify with 'show snmp statistics' after an snmpwalk from the collector.
Treating a trunk as a single flat VLAN list and forgetting that a native VLAN mismatch or a missing 'native-vlan-id' on a trunked interface causes untagged frames to land in the wrong VLAN, breaking management or a routed subinterface.
On EX/QFX, an 802.1Q trunk carries tagged frames for listed VLANs but untagged frames go to the native VLAN; candidates configure 'family ethernet-switching' with 'port-mode trunk' and 'vlan members' but omit native-vlan-id, so untagged traffic silently maps to VLAN 1. Voice or AP traffic then fails without an obvious error.
What to do instead
Explicitly set 'set interfaces ge-0/0/1 native-vlan-id 10' and confirm the peer matches. Verify with 'show ethernet-switching interface ge-0/0/1' and 'show ethernet-switching table' to see which VLAN untagged MACs land in. Where a routed subinterface is used, confirm the 802.1Q tag matches the peer.
Assuming RSTP and VSTP interoperate transparently across a mixed-vendor or multi-instance topology, and leaving a spanning-tree instance unconfigured so a loop persists or a blocked port stays blocking.
Junos defaults to RSTP on many platforms but VSTP is required for per-VLAN instances; candidates configure one and expect the other. Also, a bridge priority left at default can make the wrong switch root, and BPDU protection/loop protection left off lets a rogue edge port create a loop.
What to do instead
Decide the STP mode per design: 'set protocols rstp' for a single instance, or 'set protocols vstp vlan ' for per-VLAN. Set bridge priority deliberately on the intended root ('set protocols rstp bridge-priority 4k'). Enable 'set protocols rstp interface ge-0/0/1 edge' plus 'bpdu-block-on-edge' and 'set protocols layer2-control bpdu-block' on access ports. Verify with 'show spanning-tree bridge' and 'show spanning-tree interface'.
Building an IRB or VRRP gateway and forgetting that the IRB must have the correct VLAN membership and that VRRP preemption and priority determine which box answers, so the virtual gateway answers intermittently or not at all.
Candidates configure 'set interfaces irb unit 10 family inet address 10.0.0.1/24' but forget 'set vlans v10 l3-interface irb.10' or the VLAN's interface membership. For VRRP, leaving preempt at default with equal priorities causes split behavior, and a missing 'accept-data' stops the master from answering for the VIP.
What to do instead
Tie the L3 interface to the VLAN explicitly ('set vlans v10 l3-interface irb.10'), set 'set interfaces irb unit 10 family inet address 10.0.0.1/24 vrrp-group 10 virtual-address 10.0.0.254', set priority 200 on the intended master and 'preempt' on both, and add 'accept-data'. Verify with 'show vrrp' and a ping to the VIP from an access port.
Advertising a subnet into OSPF or IS-IS without confirming the interface is actually in the expected area/level and that passive or export policy is set, so routes are missing or leaked between areas unexpectedly.
Junos does not advertise connected routes into OSPF unless the interface is included in an area; candidates add a policy-options term but forget 'export' under the protocol, or they mark the uplink passive and lose the adjacency. Area mismatches and level mismatches produce silent adjacency failures.
What to do instead
Add every transit interface to the correct area explicitly, keep loopbacks passive, and apply the policy with 'set protocols ospf export '. Check adjacencies with 'show ospf neighbor' and 'show isis adjacency', and confirm the expected prefixes with 'show route protocol ospf'. If a policy is used, verify with 'show policy ' and 'test policy'.
Configuring an EVPN-VXLAN overlay but omitting the underlay reachability or the correct VNI-to-VLAN mapping, so MACs are learned locally but never appear in the remote VTEP's table.
Candidates focus on the EVPN signaling (route types, route targets) and forget that VXLAN requires a loopback VTEP address reachable via the underlay, an 'vxlan' encapsulation stanza with the right VNI, and matching 'vni' under the VLAN. A route-target mismatch means type-2 routes are not imported.
What to do instead
Verify the chain in order: underlay loopback reachability ('ping' VTEP-to-VTEP), 'set switch-options vtep-source-interface lo0.0', 'set vlans v10 vxlan vni 5010', and 'set protocols evpn' with matching 'vrf-target' or 'route-target'. Confirm with 'show evpn database', 'show ethernet-switching table', and 'show route table bgp.evpn.0'.
Applying a CoS classifier or scheduler map to an interface but never binding the forwarding class to a queue or the scheduler map to the interface, so all traffic still egresses from the default queue and priority behavior is untested.
Junos CoS is a chain: classifier sets forwarding class, the forwarding-class-to-queue map assigns the queue, the scheduler-map assigns schedulers to queues, and the scheduler-map must be applied under the interface. Candidates configure one or two links and assume the rest are implicit.
What to do instead
Wire the full chain explicitly: 'set class-of-service classifiers dscp forwarding-class loss-priority low code-points ', 'set class-of-service forwarding-classes class queue-num ', 'set class-of-service scheduler-maps forwarding-class scheduler ', and 'set class-of-service interfaces ge-0/0/1 scheduler-map '. Verify with 'show class-of-service interface ge-0/0/1' and 'show interfaces queue ge-0/0/1'.
Testing CoS with a single flow and concluding shaping or policing works, when the behavior only shows under contention or with a specific DSCP marking that the classifier does not actually match.
Candidates send one stream, see it pass, and move on. Shaping and priority only manifest when the queue is oversubscribed; also, the default classifier may not match the DSCP the test tool sets, and 'loss-priority' may be high for that code point so traffic is dropped before it reaches the queue.
What to do instead
Generate at least two flows at different DSCP values that exceed the shaper rate, then check 'show interfaces queue ge-0/0/1' for per-queue drops and transmit rates. Confirm the classifier match with 'show class-of-service classifier ' and verify the code point is not mapped to high loss priority. Use 'monitor traffic interface' to confirm markings survive the path.
Leaving the lab in a partially configured state and not verifying the final configuration against the task list, so a correct earlier change is undone by a later one or a stale commit is still pending.
With many tasks, candidates make a later change that overwrites an earlier stanza (for example re-applying an interface unit without the original family or re-declaring a VLAN without its l3-interface), and they never run a final diff. A pending candidate configuration is also easy to forget.
What to do instead
Before finishing, run 'show system commit' to confirm the last commit, 'show configuration | compare rollback 1' to see what the last commit changed, and 'show | compare' to confirm no uncommitted candidate remains. Walk the task list and verify each with the relevant show command (routing table, EVPN database, CoS interface, spanning-tree) rather than trusting the config alone.