JNCIS-ENT common mistakes
JNCIS-ENT · Understand the traps and how to avoid them.
Creates the VLAN with a name and vlan-id, then only sets `family ethernet-switching` on the access ports without any `vlan members` binding, and later finds the VLAN has zero ports in `show vlans` while user traffic lands in the default VLAN or is dropped.
On Junos a VLAN is only an object definition; port membership is configured separately on the interface unit, so a defined-but-unbound VLAN does nothing, and untagged traffic falls back to the default VLAN (vlan-id 1).
What to do instead
Bind the VLAN explicitly, e.g. set interfaces ge-0/0/1 unit 0 family ethernet-switching interface-mode access vlan members V100 (trunk: interface-mode trunk vlan members [V100 V200]), then verify with show ethernet-switching interface ge-0/0/1 and show vlans V100.
Studies RSTP and expects it to build a separate topology per VLAN so that some VLANs block on one uplink and others on the other uplink.
RSTP on Junos switches is a single spanning-tree instance covering all VLANs (PVST+ is not supported), so every VLAN shares one blocking port and no per-VLAN load sharing occurs.
What to do instead
Use VSTP (set protocols vstp vlan all) or MSTP with several MSTIs (set protocols mstp msti 1 vlan [V100 V200]) and tune cost/priority per instance, then confirm the topology with show spanning-tree interface and show vstp vlan <id>.
Leaves every switch at the default bridge priority and assumes the intended core device will become root.
All bridges tie at the default priority (32768), so the root is decided by the lowest MAC address, which is arbitrary and can put the root on an access switch.
What to do instead
Set an explicit low priority on the core (set protocols rstp bridge-priority 4096, or the mstp/vstp equivalent for per-instance roots) and verify the elected root with show spanning-tree bridge and show spanning-tree interface.
Enables DHCP snooping on the user VLANs and immediately the whole site stops getting leases; the snooping binding table stays empty.
Snooping treats every port as untrusted by default, so DHCP OFFER/ACK packets arriving from the real server across the uplink are dropped.
What to do instead
Mark the server-facing or uplink port trusted (set ethernet-switching-options secure-access-port interface ge-0/0/24 dhcp-trusted on non-ELS EX; on ELS platforms the equivalent trusted override lives under the forwarding-options dhcp-security hierarchy), then confirm entries appear in show dhcp snooping binding.
Writes a redistribution/export policy that lists a `from` condition but omits `then accept`, or writes a valid policy and never applies it with an `export` statement under the protocol, and expects redistributed routes to appear.
Junos has an implicit deny in its default export policy, so a policy without an explicit accept action, or a policy that is never referenced, results in nothing being redistributed or advertised.
What to do instead
Terminate the policy with then accept (or then metric/accept), apply it under the protocol (set protocols ospf export STATIC-TO-OSPF, set protocols bgp group <g> export ...), and verify with show ospf database external or show route advertising-protocol bgp <peer>.
Tries to enable OSPF with a network/subnet statement rather than per-interface configuration, so no interface ever joins the area and no adjacencies form.
Junos has no network command for IGPs; OSPF is enabled by listing interfaces under an area, and interfaces that are not listed are silently excluded regardless of their IP addressing.
What to do instead
Add interfaces explicitly (set protocols ospf area 0.0.0.0 interface ge-0/0/0.0, plus interface lo0.0 passive), optionally using interface all with disable exceptions, then verify with show ospf neighbor and show ospf interface detail.
Enables IS-IS on interfaces configured only with `family inet` and never places a NET on the loopback, then cannot understand why the adjacency is down or no routes appear.
IS-IS runs over CLNS, so the interface needs family iso and the router needs a NET (system ID plus area) under family iso address; without them the adjacency cannot form and no LSPs are generated.
What to do instead
Add family iso to the transit interface and the NET to lo0.0 (set interfaces lo0 unit 0 family iso address 49.0001.1921.6800.1001.00), then verify with show isis adjacency and show isis database.
Advertises an external route into iBGP from the border router without setting next-hop-self, then sees the prefix present in `show route` but marked unusable and never installed.
iBGP does not change the next hop, so internal peers receive the external peer's address as next hop, cannot resolve it, and the route stays hidden; the same class of failure occurs when the iBGP full mesh or route reflector is not built.
What to do instead
Configure set protocols bgp group IBGP neighbor <ip> next-hop-self on the border router (or a policy with then next-hop self), confirm full-mesh or RR reachability, and verify with show route <prefix> detail and show bgp neighbor <ip>.
Brings up a GRE tunnel and expects it to pass traffic, but the tunnel endpoint address has no route via the physical path, the tunnel unit has no `family inet` address, or the tunnel subnet is not included in the IGP, so the tunnel is up but the far-side prefix is unreachable.
The tunnel interface is logical: the router still needs a physical route to the tunnel destination and the tunnel interface must be both addressed and advertised for traffic to flow; large packets can also be dropped if MTU is left at 1500 over a 1500-byte underlay.
What to do instead
Configure tunnel source/tunnel destination plus a family inet address on the tunnel unit, ensure the destination is reachable via the physical next hop (not recursively through the tunnel), include the tunnel interface in the routing protocol, and set family inet mtu 1476 (or clamp TCP MSS).
Makes configuration changes with a plain `commit` on a dual-RE device and assumes the backup Routing Engine is in sync.
Without commit synchronize, a commit applies only to the local Routing Engine, so after a failover the newly active RE runs a stale configuration and behaviour silently reverts.
What to do instead
Enable set system commit synchronize (or always use commit synchronize) and confirm the REs match with show system commit and show system redundancy status before testing failover.