Security Platform and Architecture
Security Platform and Architecture tests how well you know the SRX data plane and high-availability design: flow processing, chassis cluster redundancy groups, reth interfaces, and virtualized or logical systems.
Platform internals
SRX is a flow-based device. The first packet of a session traverses the slow path, where the flow module performs screen checks, destination NAT, route lookup, policy lookup, source NAT, and session creation; later packets use the fast path and only a session lookup. On high-end platforms, SPUs/SPCs handle services while NPCs/NPUs forward; on branch SRX, the NPU handles forwarding. Know the order because troubleshooting depends on it: ingress filter, screen, destination NAT, route, policy, source NAT, session, egress.
Chassis cluster
A cluster has a control link for heartbeats and configuration sync and a fabric link for data. Redundancy group 0 carries routing and must be primary on a node before RG1+ can be primary there. Reth interfaces are logical links backed by physical interfaces on both nodes. Priority, preempt, and IP monitoring decide failover.
Worked example
Two SRX in a cluster, dual ISPs, and the requirement that all traffic moves when the primary ISP fails. Put the ISP-facing reth in RG1, set node0 priority 200 and node1 100, enable preempt, and attach an RPM-based IP monitor to reth0.0 with a threshold. Reasoning: if the monitor is only in RG1, RG1 fails over but RG0 stays, so routing and the reth may split across nodes. Monitor in RG0 when full device failover is required.
Traps
- Confusing control and fabric links: the control link carries heartbeats, not user data.
- Trying to make RG1 primary on a node where RG0 is secondary.
- Forgetting reth-count before configuring reth interfaces on older Junos.
- Expecting preempt to act immediately; it waits for the failover delay.