Sequence Check Drops and a Misbehaving Automation Job

Sequence check failures mean the flow module is seeing TCP segments outside the expected window, or seeing only one direction of a flow while the other direction takes a different path. After the BGP change, the forward path stayed on ISP-A while the return path moved to ISP-B. That is asymmetric routing through a stateful device, and the SRX's TCP state machine can no longer validate the stream reliably.

set security flow tcp-session no-sequence-check is a global tactical workaround. It disables the window validation that helps reject spoofed or injected segments, so it weakens a protection for every TCP flow, not just the affected branch. It should not be the first choice on a security device.

The permanent fix is to restore symmetric routing: adjust BGP local preference or AS-path so both directions prefer the same ISP for these flows, use a more specific route for the branch's return traffic, or redesign so the SRX is not in the asymmetric path for this traffic. If the business cannot restore symmetry, treat no-sequence-check as a documented, time-limited exception with monitoring, and verify that the drop counter stops while confirming the affected long-lived sessions recover. Do not take an ISP link down to test; use a maintenance window or a lab replica.

commit_check is not a commit. It loads and commits the candidate configuration with an automatic rollback timer. If no confirming commit is issued before the timer expires, Junos rolls back by design. The script apparently exits after commit_check without a confirm step, so the rollback is expected behavior, not a bug. The configuration lock error on the next run is a separate problem: a failed or abandoned session may have left the configuration locked, or a prior confirmed commit is still pending.

Write the job so state is explicit:

• Acquire the configuration lock deliberately and release it in a finally block, so an exception cannot leave the lock held.
• Use commit_check only when a human or a second automated step will confirm within the window; otherwise use a normal commit with a comment after validating the candidate.
• On any exception, call rollback and unlock before exiting.
• In a chassis cluster, use a synchronized commit so both nodes receive the configuration.
• Serialize jobs so two runs cannot compete for the same lock, and log the commit result and any rollback event.

Verify with show system commit and show configuration after the run, not just the script's exit code.

Check the primary and secondary separately; do not trust a single show configuration from the primary. On each node, run show system commit and compare the commit sequence and comments. Then compare the relevant hierarchy, for example show configuration security policies or show configuration | display set | match address-book, on both nodes.

If the secondary is missing the change, first check whether the automation used a synchronized commit. A plain commit on the primary can leave the secondary behind if commit synchronization is not enabled. Run a synchronized commit from the primary, then recheck both nodes. If the synchronized commit fails, read show log messages on both nodes for commit, synchronization, or database errors, and check show chassis cluster status to confirm both nodes are healthy and the secondary is not in a hold or disabled state.

Also confirm that the automation did not target a specific node or a reth-specific stanza that only exists on one node. Address-book and policy configuration is cluster-wide, so a difference usually points to a commit or synchronization failure, not to a legitimate per-node setting.