A misconfigured automation script corrupted large portions of a rural ISP's lab router configuration with conflicting and duplicate statements, and an engineer wants to discard the entire candidate configuration and start clean from a known-good saved file, keeping nothing from what's currently there. Which load operation fits?
Select an answer to reveal the explanation.
Short Explanation
load override is a clean slate. It throws out the whole existing candidate and drops the saved file in as the entirely new starting point, with no leftovers from what was there before.
Full Explanation
load override filename replaces the entire candidate configuration with the contents of the specified file, which fits exactly this situation — a candidate too tangled with conflicting and duplicate statements to safely merge into, where starting fresh from a known-good baseline is safer than trying to reconcile every conflicting line by hand. load merge would add the good file's statements onto the already-corrupted candidate rather than discarding it, so the same conflicts could persist or even multiply. load patch applies a prior compare-style diff file rather than loading in a complete baseline configuration, which doesn't address a candidate that is broadly corrupted rather than missing a specific set of changes. rollback 0 reloads the most recently committed configuration back into the candidate, discarding uncommitted edits, but it only cycles back through Junos's own commit history — it can't be pointed at an arbitrary saved known-good file the way load override can. Caveat: load override does not touch the active configuration until a commit follows, so the corrupted state remains reversible right up to that point. Check: run show | compare immediately after loading to confirm the resulting candidate matches the known-good file before committing.