NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: System → Reboot
2. CLI: /system reboot
3. Safety net for risky changes: /system scheduler add name=undo on-event="/system reboot" start-time=startup interval=5m — or better, use Safe Mode.
4. Safe Mode: press Ctrl+X in a terminal (or the *Safe Mode* button in WinBox) before making changes; if the session drops, all changes since entering Safe Mode are reverted automatically.

Gotchas & notes

• Safe Mode is the most valuable RouterOS feature nobody uses. Ctrl+X before editing firewall or VLAN config means a lockout reverts itself when your session dies. Press Ctrl+X again to commit and leave Safe Mode.
• Only one session can hold Safe Mode; a second admin taking it over discards your protection.
• /system reboot does not save anything extra — RouterOS config is applied immediately and persists, unlike IOS.
• For scheduled maintenance use /system scheduler with a one-shot start-date/start-time, and remember to remove the entry afterwards.

Steps

1. GUI: Dashboard → the *System Information* widget → Reboot.
2. CLI: execute reboot — it prompts for confirmation.
3. Shut down instead: execute shutdown
4. Verify uptime after: get system status

Gotchas & notes

• FortiOS applies config changes immediately and persistently; there is no save step and no automatic rollback. A bad allowaccess or policy change survives the reboot.
• There is no built-in 'revert if I lose contact' feature. Build one yourself with System → Automation (a scheduled script) if you are making a risky remote change.
• On an HA pair, execute reboot reboots only the unit you are on; check get system ha status first so you do not reboot the primary by accident.
• A reboot re-runs the boot image selection; if you recently upgraded, confirm which image is active with get system status.

Steps

1. GUI: Devices → <device> → Settings → Manage Device → Restart.
2. Restart many at once: select devices in the Devices list → *Restart*.
3. CLI (device SSH): reboot
4. For the controller/UniFi OS console, restart from UniFi OS settings.

Gotchas & notes

• Rebooting a UDM/UDM-Pro takes the whole network down, controller included, for several minutes — it is not a management-plane-only action like rebooting an AP.
• A device that fails to come back shows as *Disconnected* but keeps its config; the controller re-provisions it on return, which can take a few minutes after the link is up.
• PoE-powered APs can be power-cycled from the switch instead: Devices → <switch> → Ports → <port> → *Power Cycle*, which is often faster than a reboot.
• There is no config-rollback-on-lockout. Take a controller backup before big changes.

Steps

1. Before a risky change: reload in 10 — schedules a reload in 10 minutes. If your change locks you out, the device reloads to the (unsaved) startup config and you get back in.
2. If the change worked: reload cancel
3. Normal reboot: reload — answer no to saving if you do not want to keep the running config.
4. Better rollback on IOS-XE: configure replace flash:backup.cfg with the archive feature, or configure terminal revert timer 10.
5. Verify: show version | include uptime

Gotchas & notes

• reload in <minutes> is the single best remote-change safety net on any platform here. Combined with *not* saving the config first, a lockout fixes itself. Make it a habit before ACL and interface changes.
• It only works if you have not run copy running-config startup-config. Saving first defeats the entire mechanism.
• reload cancel must be run from an enabled session — if you cancel from the wrong session or forget entirely, the device reboots mid-afternoon.
• IOS-XE's configure terminal revert timer <minutes> is even better: it rolls back the configuration without a reboot. Confirm with configure confirm.
• On a stack, reload restarts all members; use reload slot <n> for a single member.

Steps

1. GUI: Device → Setup → Operations → Reboot Device.
2. CLI: request restart system
3. Restart just the dataplane (rarely needed, still disruptive): request restart dataplane
4. Verify: show system info

Gotchas & notes

• The candidate-config model is the safety net: if a change locks you out before you commit, nothing happened. After a commit, use Device → Setup → Operations → Load configuration version to roll back — no reboot needed.
• PAN-OS has no 'reload in' equivalent, but *Commit → Preview Changes* plus auto-saved config versions covers most of the same ground.
• A reboot is slow (several minutes) because the management and data planes come up separately; the GUI answers before traffic flows.
• request restart dataplane drops every session and is not a lighter-touch option — treat it as an outage.

Steps

1. GUI: Diagnostics → Reboot (with an option to reboot into a different boot environment on ZFS installs).
2. Console menu: option 5) Reboot system.
3. CLI: shutdown -r now
4. Verify: dashboard uptime.

Gotchas & notes

• Diagnostics → Backup & Restore → Config History is pfSense's rollback: revert the last change with one click, no reboot. Reach for that before a reboot when a change broke something.
• On ZFS installs, boot environments let you reboot into the pre-upgrade state — the closest thing pfSense has to a safety net for a bad upgrade.
• A reboot re-runs the filter and re-reads config.xml; a change that only exists in the GUI without *Apply Changes* is lost.
• Rebooting drops all firewall states, so long-lived sessions (VoIP, SSH, VPN) reconnect.

Steps

1. GUI: Device → Settings → Firmware and Backups (or the restart icon in the top status bar) → Restart, then choose Restart SonicWall (keeps current settings) — avoid the adjacent 'and boot with factory default settings' option unless that's actually what you want.
2. CLI: connect via SSH or console and issue reboot — this restarts immediately with no delay.

Gotchas & notes

• There is no scheduled-reboot and no commit-confirm/auto-revert mechanism on SonicOS. Unlike Cisco's reload in <minutes> plus auto-revert if you don't confirm, a SonicWall reboot (GUI or CLI) is immediate and final — if the change you just made locks you out, nothing automatically undoes it.
• Your only real safety nets: keep an out-of-band console/serial session open while making risky interface or routing changes, or accept that recovery means a trip to the reset button.
• SafeMode does auto-trigger after repeated failed/hung boots, but that's a firmware-health fallback, not a response to 'I changed a setting and now I can't reach it.'
• The 'Restart SonicWall and boot with factory default settings' option lives right next to the normal restart button on the same dialog — a genuine misclick risk when you just meant to reboot.

Steps

1. Insight-managed routers, Orbi Pro APs, and Insight-managed switches: Insight Cloud Portal/app → select the device (or multiple devices, or a whole Device Group) → Reboot. To schedule one (or a recurring window) instead: Insight Pro → Locations → Scheduled Device Reboot → pick devices, date/time, and optional recurrence. Cancel/edit the same schedule from that page to remove it.
2. Smart Switches, local path: switch's own HTTPS GUI → Maintenance → Reboot. The Lite CLI also exposes a basic reload command for the same action over SSH.
3. M4200/M4300 (real CLI): reload from Privileged EXEC — it will prompt to save unsaved config first if running-config differs from startup-config. GUI equivalent: Maintenance → Reboot.

Gotchas & notes

• None of the three NETGEAR surfaces has anything like Cisco's reload in 10 + configure confirm safety net that auto-reverts a change if you lose contact. Insight's 'scheduled reboot' is just a timer to restart the box at a chosen time (useful for maintenance windows) — it does not roll back any configuration if the box comes back broken.
• On the M4200/M4300, reload is immediate and manual-confirm only; if a config change locks you out of management, the only recourse is a console cable or physical power cycle, not an automatic revert.
• Because routers and Orbi Pro APs have no CLI, a scripted/automated reboot-and-verify workflow (SSH in, run a command, watch for it to come back) is impossible on those — you're limited to whatever the Insight portal/app UI and its scheduler expose.
• The Lite CLI's reload (where present) and the local GUI reboot on Smart Switches are independent of Insight's cloud reboot/schedule feature — rebooting locally doesn't clear or interact with any pending Insight-scheduled reboot for that device.