Customer Network Design Requirements
This domain tests whether you can turn business goals into a Juniper-appropriate WAN design, not just list products. Expect requirements gathering, constraints, availability targets, growth, and trade-off reasoning.
Core rules
- Separate business requirements (revenue, compliance, user experience) from technical requirements (latency, bandwidth, availability, security).
- Record constraints: budget, legacy Junos devices, carrier contracts, regulatory data residency, and skills.
- Derive measurable KPIs: availability, MTTR, round-trip latency, jitter, loss, and scale headroom.
- Prefer modular, hierarchical designs that can grow; state assumptions explicitly.
- Validate the design against a POC or lab before committing.
Worked example
A retailer has 120 branches, POS transactions must complete under 100 ms to the DC, availability must be 99.95%, and capital budget is tight. Branches already run EX switches; the carrier offers MPLS but at high cost. Requirement mapping: latency and availability favor dual connections; budget favors Internet with IPsec overlays. Design: dual ISP at each branch, SRX firewalls, IPsec to two DC hubs, BGP for path selection, QoS for POS. Reason: 99.95% is about 4.4 hours downtime per year, so single ISP is unacceptable; MPLS is not required because 100 ms is achievable over regional Internet with an overlay.
Traps
- Treating a wanted feature as a hard requirement.
- Ignoring growth and operational skills.
- Assuming full-mesh IPsec scales without hubs.
- Quoting availability without MTTR or SLA math.