What has to line up before an MX can terminate IPsec
A commit that accepts the configuration proves the parser, not the path. Five parts of the platform tuple decide whether the service actually runs.
The configuration commits cleanly, the interfaces come up, and the tunnel still refuses to establish. Nothing in the log says the platform cannot do this; it simply does not do it. On Junos, IPsec is a service that a specific combination of chassis, service hardware or software path and release can perform, and a feature page describes the software capability rather than your box. The tuple has to be checked part by part, because a commit result proves only the parser.
Where the packet actually goes
Traffic selected for IPsec has to reach the component that encrypts it. On platforms with a services module, the selected flow is steered to that module and returns to the forwarding path afterwards. If the module is missing, undersized or not bound to the interface, the configuration exists and no packet is ever processed. Nothing in the commit output distinguishes that case from a healthy one.
Software-hosted implementations keep the work on the routing engine or in inline hardware, with very different resource limits. A tunnel visible in the configuration does not tell you which of those paths is actually carrying it.
The five parts of the tuple
Write the combination down before reading any recommendation, because one part can invalidate the others. A part number that supported a service three years ago says nothing about the card and release in this chassis. Read the rows below as the checklist, then fill in the values the configuration cannot show you.
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
The address families and the workload are the two rows people skip, and both are cheap to check and expensive to discover later. Read the tuple from the box rather than from a spreadsheet, because a configuration reports what you asked for rather than what is installed. Two commands carry most of it: show chassis hardware names the card actually seated, and show version gives the exact release. Neither depends on the configuration being right, which is the point.
show chassis hardware
show versionRelease gates are real gates
The release detail is not a formality. Juniper's IPsec overview dates AES-GCM support for multiservices cards to Junos 17.3R1, with FIPS mode beginning at 17.4R1. The same feature therefore has two thresholds depending on how the platform is operated, and the mode you run decides which one applies. Check the mode before you check the feature list.
Read the release notes for the exact version installed, not the newest documented one. A capability that arrived in a later build cannot be presumed present in an earlier one, and a statement written for one card does not transfer to another. Copy the release-note line into the design record so the claim carries its own source, because a support statement written for a platform family is not a statement about the mode you run or the card you have.
Capacity is a workload, not a headline
A headline throughput figure without its measurement conditions is a marketing number. Small packets cost far more per bit than large ones, concurrent associations consume memory, and every other service sharing the card reduces what remains.
Estimate from the traffic you expect: typical and worst-case packet sizes, the number of peers, and whether that card also terminates NAT or another service. Then leave headroom for the day one path carries more load than the design assumed. A capacity plan that assumes idle hardware is a wish rather than a plan. If the figure matters to the business case, measure it once on the box under a representative load and keep that measurement with the design.
Write the record before the design
For each capability the design needs, keep the platform reference, the release-matched documentation and any unresolved restriction in one place. Where a row of the tuple fails, compare a separate approved gateway instead of rebuilding the design around an obsolete shopping list. The record should say which exact system performs the job and under what limits.
Only then check the peer, because protocol compatibility with the far end is the next question and never a substitute for local support. A peer that agrees on proposals still cannot help a chassis that never encrypts a packet.