4.3 Device Maintenance
Key Takeaways
- `request system software add` installs a Junos package; `request system software rollback` reverts to the previously installed version stored on the device
- `request system reboot`, `request system halt`, and `request system power-off` are the safe shutdown commands; halt/power-off must complete before removing power
- Root-password recovery requires console access and rebooting into single-user mode to reset the root authentication
- A rescue configuration is saved with `request system configuration rescue save` and restored later with `rollback rescue` followed by `commit`
- NTP keeps device time accurate for correlated logs; SNMP exposes counters and traps to a network management system
Junos Software Upgrade and Downgrade
Junos is upgraded by installing a software package (a .tgz/junos-install image). The package is first copied to the device (commonly into /var/tmp) and then installed:
user@router> request system software add /var/tmp/junos-install-21.4R3.tgz
user@router> request system reboot
Key points the exam expects:
- A reboot is required for the new Junos version to become active.
request system software rollbackreverts to the previously installed Junos image, which Junos retains on the device after an upgrade. This is the fast, safe downgrade path and also needs a reboot.- The
validateoption (default on supported releases) checks that the candidate configuration is compatible with the new image before committing the upgrade. - On dual-RE platforms, upgrades are staged per Routing Engine; on single-RE devices it is a single in-place install plus reboot.
The request system Maintenance Commands
The request command performs operational actions that change device state. The maintenance subset is heavily tested:
| Command | Action |
|---|---|
request system reboot | Cleanly restarts the device |
request system halt | Stops the OS so it is safe to power off; does not power down on its own |
request system power-off | Gracefully powers the device down |
request system software add | Install a Junos package |
request system software rollback | Revert to the previous Junos image |
request system snapshot | Copy the running software/config to a backup medium (recovery snapshot) |
request system zeroize | Erase config and data, returning to factory-default state |
request system configuration rescue save | Save the current active config as the rescue config |
Use request system halt (or power-off) and wait for the halt to complete before physically removing power, to avoid filesystem corruption. request system reboot at <time> and request system reboot in <minutes> schedule a delayed restart for maintenance windows.
File and Storage Management
Junos exposes a Unix-like file system through operational file commands and storage cleanup tools:
show system storage- per-filesystem usage; investigate when/varis near fullfile list /var/tmp- list files in a directoryfile copy,file delete,file rename- basic file operationsrequest system storage cleanup- safely propose and delete temporary/old files (rotated logs, old install images) to reclaim space
Clearing space is a common pre-upgrade maintenance step because a Junos image plus its temporary extraction needs free room on /var. The exam may describe a failed request system software add caused by a full filesystem; the corrective action is request system storage cleanup (or manual file delete) before retrying.
Root-Password Recovery
Root-password recovery is a defined procedure, not a hidden backdoor, and it requires physical or console access to the device:
- Connect to the console port.
- Reboot the device and interrupt the boot sequence to enter the boot loader.
- Boot into single-user mode when prompted.
- When asked, choose to start the recovery shell / run the password-recovery option.
- Enter configuration mode, set a new root authentication with
set system root-authentication plain-text-password, andcommit. - Reboot back into normal multi-user mode.
Because the procedure needs console access and a reboot, physical security of the device and console port is itself a security control. There is no way to reset the root password from a normal in-band SSH session without knowing existing credentials.
Configuration Backup, Restore, and Rescue
Protecting the configuration is core maintenance:
| Task | Command |
|---|---|
| Save active config to a file | save /var/tmp/backup.conf (configuration mode) |
| Restore from a file | load override /var/tmp/backup.conf then commit |
| Merge a partial file | load merge <file> then commit |
| Save a rescue configuration | request system configuration rescue save |
| Restore the rescue config | rollback rescue then commit |
| Revert to a prior committed config | rollback <0-49> then commit |
| Automatic remote archival | set system archival configuration (transfer-on-commit/interval) |
The rescue configuration is a known-good baseline an operator deliberately saves. If a bad change locks the device, rollback rescue followed by commit restores that baseline. Junos also retains the last 50 committed configurations (rollback 0 is current, rollback 1 is the previous commit), and system archival can push each committed config to an external server automatically.
NTP and SNMP Basics for Maintenance
Two services support ongoing operations and are tested at a basic level:
NTP (Network Time Protocol) keeps the device clock accurate. Accurate time is essential because syslog and traceoptions timestamps must line up across devices when correlating an incident. Basic configuration sets a server under [edit system ntp]:
[edit system ntp]
user@router# set server 192.0.2.123
show ntp associations and show system uptime help verify time sync.
SNMP (Simple Network Management Protocol) lets a Network Management System (NMS) poll counters and receive traps (asynchronous event notifications). Basic configuration under [edit snmp] sets a read community string and trap targets:
[edit snmp]
user@router# set community public authorization read-only
For JNCIA-Junos, know the purpose of each service and where it is configured rather than deep tuning: NTP for time accuracy, SNMP for monitoring/alerting from an external system.
After installing a new Junos image with request system software add, the device still reports the old version. What is required?
An operator runs request system halt and then immediately unplugs the device. Why is this risky?
A bad commit has made the device unreachable in-band, but a known-good baseline was previously saved with request system configuration rescue save. Which sequence restores it via console?
Why is configuring NTP considered a maintenance and troubleshooting best practice on a Junos device?