A Syslog Change That Took Down a Subnet

Junos has one candidate configuration per device, shared by all users unless someone takes a lock.

• configure does not hand each user a private copy.
• commit does not commit "my changes"; it commits the entire candidate configuration as it exists at that moment - including changes authored by other users who are still inside configuration mode.

So when B ran commit, the candidate contained both B's syslog host and A's completed firewall term. Both went active at 02:40. show system commit records only who ran the commit and the commit comment, not who authored each delta - which is why B looks responsible and A looks innocent. Both statements are literally true: A never committed, and B only changed syslog.

The secondary lesson is that A's abandoned session was the real hazard. A had left a syntactically valid but operationally premature change sitting in a live candidate configuration with nothing preventing it from being committed.

Prove the delta first:

• show configuration | compare rollback 1 (or show system rollback compare 1 0) - shows precisely what the last commit added or removed. This will show both the syslog host and the filter term.
• show system commit - confirms the rollback number to compare against and the commit author/comment.

Then restore service, minimising collateral: Do not simply rollback 1 and commit. That would revert B's legitimate syslog change as well, so you would trade one unplanned change for another and lose the logging that may be needed for the incident record.

The least-disruptive path is to remove only the offending construct while keeping B's change:

1. deactivate firewall family inet filter <name> term <block-10.20> (or delete the term), preserving it for the later scheduled rollout.
2. commit comment "incident 4711: deactivate unplanned 10.20/16 block".
3. Verify: show firewall (counters stop incrementing), show configuration | compare rollback 1 (only the intended delta), and a live test from a 10.20.0.0/16 host.

If the delta is tangled and you cannot isolate it safely, rollback 1, commit, then immediately re-apply B's syslog change in the same commit - a single controlled change beat two improvised ones.

Configuration-method changes:

• configure exclusive - takes a lock on the shared candidate so no other user can edit or commit while you are in configuration mode. Best when a change spans multiple stanzas and must land atomically.
• configure private - gives you a private candidate that is merged and committed only by you, and other users' commits cannot pick up your work. This is the cleanest fix for the exact failure here: an engineer parked mid-edit.
• commit confirmed <minutes> for anything touching production traffic - the change auto-reverts unless explicitly confirmed, so an unattended or mistaken commit self-heals.
• Discard on exit discipline - rollback 0 before leaving configuration mode, or simply exit configuration-mode after rollback 0, so no orphaned edits sit in the candidate.
• commit comment / annotate on every commit so the audit trail records intent, not just authorship.

Process changes:

• A prepared-but-not-scheduled change belongs in a configuration group that is not applied, in a saved text file, or in the ticketing system - not in a live candidate configuration.
• Review show configuration | compare before any commit; it shows other users' pending edits and is the single cheapest defence against this class of outage.
• Keep individual accounts (already in place) but add a change-window convention that nobody sits in configuration mode outside their window.