JNCIP-ENT common mistakes
JNCIP-ENT · Understand the traps and how to avoid them.
When asked to verify OSPF adjacency formation, the candidate only checks that neighbors reach Full state and never examines which router is DR/BDR on a broadcast segment or whether the adjacency is 2-Way between DROthers.
Lab experience is often built on point-to-point or single-router-per-segment topologies, so the DR/BDR election mechanics and the normal 2-Way state between DROthers are never practiced. The candidate then misreads a healthy 2-Way adjacency as a failure or misses a genuine DR election problem caused by priority or RID ordering.
What to do instead
Before checking state, run show ospf interface detail to record DR/BDR addresses, priorities, and the network type. Then map show ospf neighbor output against that table: Full with the DR and BDR, 2-Way with DROthers is expected. Practice predicting the election outcome from priority then router ID, and rehearse how a priority change requires clearing the OSPF process to take effect.
The candidate configures OSPF or IS-IS areas and metrics but cannot explain which router installs a given prefix when the same route arrives from multiple levels or areas, and mis-predicts the outcome of a redistribution point.
Study focuses on single-protocol, single-area scenarios. Junos route preference, the distinction between intra-area, inter-area, and external OSPF paths, and IS-IS Level 1 vs Level 2 default behavior (L1-only routers using the nearest L1/L2 router as default) are learned as facts but not as a decision order.
What to do instead
Build a written decision ladder for each protocol: OSPF prefers intra-area over inter-area over external, then cost, then tie-breakers; IS-IS prefers L1 within an area and L2 across, with the attached bit driving default routing. Verify with show route protocol ospf detail and show isis route, reading the path attributes rather than just the winning prefix.
On BGP questions the candidate reads only the local preference and AS path length and stops, ignoring origin type, MED, and the eBGP-over-iBGP and router-ID tie-breakers, so the selected best path is wrong.
The BGP selection algorithm is long and is usually memorized as a list rather than as an ordered filter. Candidates skip steps they consider rare, such as origin, MED comparison only among paths from the same neighboring AS, and the final cluster-length and peer-address steps.
What to do instead
Rehearse the full ordered list until it is automatic: weight, local preference, locally originated, AS path length, origin, MED, eBGP over iBGP, IGP cost to next hop, oldest route, lowest router ID, lowest cluster length, lowest peer address. For every practice route, annotate which step decided it, and confirm with show route protocol bgp detail, which shows the local preference, MED, and peer values used.
The candidate applies an export policy to a BGP session but never confirms the next hop is resolvable or that the route is actually advertised, then concludes the policy is broken.
In Junos, a route can be present in the RIB but not advertised because of an unresolved next hop, a missing next-hop-self on iBGP, or a policy that matches on the wrong term. Candidates debug at the wrong layer.
What to do instead
Check in order: show route detail for the next-hop resolution, show route advertising-protocol bgp to see exactly what is sent, and show route receive-protocol bgp on the far side. Add next-hop-self on iBGP route reflectors and confirm policy terms with a test using show policy or a lab commit.
When asked how a multicast receiver gets traffic, the candidate stops at 'PIM is configured' and cannot state which RPF interface or which rendezvous point path will be used, so the traffic-flow question is answered incorrectly.
Multicast is studied as a list of modes (sparse, dense, SSM) without practicing the RPF check, the shared tree versus shortest-path tree transition, and the role of the RP. Candidates also confuse IGMP snooping on the switch with PIM on the router.
What to do instead
For every scenario, write the RPF check explicitly: the unicast route back to the source or RP determines the incoming interface. Verify with show pim rpf, show pim join, and show multicast route. Practice the S,G to *,G transition after the first packet reaches the RP, and separate the Layer 2 IGMP snooping question from the Layer 3 PIM question.
The candidate treats a blocked RSTP or MSTP port as a fault and recommends clearing it, or cannot predict which port becomes the root port or alternate after a topology change.
Spanning tree is learned as 'loops are bad, STP fixes it' rather than as a port-role election. RSTP's proposal/agreement handshake and MSTP's per-instance instance mapping are skipped, so the candidate cannot interpret discarding, learning, and forwarding states per instance.
What to do instead
Practice deriving roles from scratch: lowest bridge ID becomes root, each bridge picks the lowest-cost path to root with the neighbor bridge ID as tie-breaker, and the remaining port on the segment is designated or alternate. Confirm with show spanning-tree interface and show spanning-tree mstp configuration, and check that MSTP instance-to-VLAN mapping is identical on all bridges.
The candidate configures 802.1X or MAC RADIUS but forgets the order of authentication methods and the fallback behavior, so a port that should fall back to MAC RADIUS or a guest VLAN instead stays down.
Junos access control combines dot1x, mac-radius, and captive portal settings under protocols dot1x and an authenticator interface stanza, and the permit/deny behavior of the server-reject-vlan and server-fail options is easy to overlook.
What to do instead
Write out the intended sequence and the failure branch: 802.1X first, then MAC RADIUS if configured, then the server-reject or guest VLAN on failure. Verify with show dot1x interface detail and show network-access radius, and test each branch by disabling the supplicant, sending a wrong credential, and removing the RADIUS reachability.
The candidate answers IP telephony questions by describing only the voice VLAN and PoE, missing LLDP-MED or the DHCP option 43/242-style boot options and the codec and call-admission implications.
Telephony features are treated as a switching topic. The candidate does not connect the voice VLAN advertisement, the phone's boot process, and the QoS marking that the phone applies, so end-to-end questions are answered partially.
What to do instead
Trace the phone boot: PoE negotiation, LLDP-MED voice VLAN and QoS advertisement, DHCP with the appropriate option for the call server, then registration. Verify with show lldp neighbors detail, show ethernet-switching interfaces, and show voice vlan. Then state how the phone marks voice traffic so the CoS answer is consistent.
The candidate maps a DSCP or 802.1p value to a forwarding class but cannot say which scheduler or drop profile will act on it, or assumes markings survive a trunk without a rewrite rule.
CoS is studied as a table of code points rather than as a pipeline: classifier, rewrite, scheduler map, and drop profile. The candidate forgets that a rewrite rule is needed to set the outbound CoS bits and that a trunk may trust or untrust the incoming marking.
What to do instead
For each scenario, draw the pipeline: ingress classifier assigns the forwarding class and loss priority, the scheduler map shapes each queue, and the rewrite rule sets the outgoing bits. Verify with show class-of-service interface, show class-of-service classifier, and show interfaces extensive for queue counters, and test with a marked stream to confirm the rewrite.
On EVPN questions the candidate describes VXLAN tunnels but cannot explain the route types (Type 2 MAC/IP, Type 3 IMET, Type 5 IP prefix) or how the VTEP learns a remote MAC, so the control-plane answer is wrong.
EVPN is learned as an encapsulation topic. The candidate does not connect the BGP EVPN address family, the route targets and route distinguishers, and the MAC learning through Type 2 routes, so data-plane and control-plane behavior get mixed.
What to do instead
Map each route type to its purpose: Type 2 for MAC and MAC/IP advertisement, Type 3 for inclusive multicast and BUM replication, Type 5 for IP prefix routes in symmetric routing. Verify with show evpn database, show route table bgp.evpn.0, and show evpn instance extensive, and trace a remote MAC from the local VTEP advertisement to the remote VTEP installation.