JNCDS-WAN common mistakes
JNCDS-WAN · Understand the traps and how to avoid them.
Begins by selecting Juniper platforms (for example EX4650, MX204, SRX4600) and drawing links, then retrofits a requirements list to justify the topology.
Exam time pressure and product familiarity pull candidates toward memorized hardware; design-domain questions score traceability from business and technical requirements to components, not the components themselves.
What to do instead
Write a numbered requirements table first (sites, user counts, application flows, bandwidth and latency targets, growth, budget, existing Junos estate), then annotate every topology and platform choice with the requirement ID it satisfies.
Places a single SRX at the internet edge and lets all inter-VLAN and inter-department traffic switch at the campus core without a policy enforcement point.
Candidates equate securing the network with perimeter firewalling and overlook east-west traffic, internal segmentation, and the customer's data-classification requirements.
What to do instead
Derive security zones from data classification and compliance scope, insert SRX or vSRX enforcement at each zone boundary including internal segments, and design policy, logging, and session scale for east-west flows.
Sizes the SRX from the datasheet firewall throughput number alone and ignores IMIX traffic, concurrent sessions, new sessions per second, and IPsec tunnel count.
Headline throughput is the easiest number to remember; design scenarios often include branch-to-DC VPNs and mixed application traffic that invalidate the headline figure.
What to do instead
Use Juniper's SRX sizing tool or capacity planner with the customer's traffic mix, add HA and growth headroom, and state the sizing basis (sessions, tunnels, IMIX throughput) in the design.
Designs dual MX or EX routers with redundant links but never specifies control-plane redundancy (GRES, NSR), BFD, or unified ISSU, and never defines a failover test.
Candidates treat high availability as link and device redundancy and forget that a dual-RE or dual-chassis design still drops sessions if routing state is not synchronized.
What to do instead
State the HA model per layer (dual RE with GRES/NSR, chassis cluster, MC-LAG or ESI), set BFD timers and routing convergence targets, and include failover test cases with expected session loss.
Omits the management plane from the design: no out-of-band console or management network, NTP hierarchy, syslog, SNMPv3, RBAC, or streaming telemetry over Juniper Telemetry Interface.
Management is treated as day-two operations rather than a design domain, yet exam scenarios ask how the network will be monitored, upgraded, and troubleshot.
What to do instead
Add a management design section covering out-of-band versus in-band access, NTP stratum plan, syslog and SNMPv3 collectors, Juniper Telemetry Interface or streaming telemetry, and RBAC with AAA integration.
Designs a flat Layer 2 campus with one large VLAN per building and STP as the loop-prevention mechanism, with no Layer 3 boundary at distribution or access.
Legacy campus habits and fear of Layer 3 access lead candidates to stretch VLANs and rely on STP, which conflicts with modern Juniper campus and EVPN guidance and with scale requirements.
What to do instead
Choose a collapsed-core or EVPN-VXLAN campus with Layer 3 to the access or distribution, limit Layer 2 domains to a closet or small building, and document STP only as a residual safety net with edge protection.
Draws the WAN as a link diagram with bandwidth labels but no CoS design: no forwarding classes, scheduler maps, per-class oversubscription ratio, or application SLA mapping.
Candidates focus on physical connectivity and routing adjacencies; QoS is perceived as configuration detail, yet WAN design questions test whether voice, video, and bulk classes are engineered.
What to do instead
Define traffic classes and code points, map them to Junos forwarding classes and schedulers on MX and SRX, set per-class oversubscription and admission targets, and verify the result against the customer's SLA requirements.
Selects MPLS, internet, or SD-WAN from a preferred technology rather than from requirements, and leaves WAN-edge routing incomplete with no BGP ASN plan, prefix summarization, or failover policy.
Candidates anchor on one transport they know and reproduce a standard diagram; design questions reward a requirements-driven transport choice and a complete routing and redundancy story.
What to do instead
Compare transports against latency, jitter, cost, regulatory, and site-size requirements, then document BGP ASN allocation, route summarization, local-preference or MED failover, and SD-WAN policy if the design is hybrid.
Designs an EVPN-VXLAN data center with a VLAN-to-VNI table but omits underlay MTU, anycast gateway, ESI multihoming, and a route-target and route-distinguisher plan.
Candidates memorize overlay concepts but skip the underlay and control-plane details that determine whether the fabric actually forwards and converges.
What to do instead
Specify jumbo MTU end to end for the underlay, anycast gateway with a consistent virtual MAC, ESI-LAG for server multihoming, and a documented RT/RD and BGP ASN scheme per tenant.
Designs the data center as a traditional STP-based Layer 2 network with large VLANs, or builds a spine-leaf IP fabric without ECMP and a scalable BGP ASN plan.
Candidates carry campus habits into the data center or add spine-leaf without designing the routing underlay, so the fabric lacks multipathing and scale.
What to do instead
Use a spine-leaf IP fabric with BGP and ECMP and a documented ASN scheme; if Layer 2 stretch is required, use EVPN-VXLAN rather than STP, and state the failure and convergence model.