Oxidized for HPE Aruba and Dell Switches: Supported Models and Custom Input Tweaks

Multi-vendor campus and data center networks rarely stay tidy. A core built on Aruba CX, an access layer of aging ProCurve stacks, a row of Dell PowerConnect switches that nobody wants to touch, and a newer Dell OS10 leaf pair all end up in the same wiring closet. Each family has a different CLI, a different login flow, and a different idea of which SSH algorithms are acceptable. Consequently, a backup tool that works beautifully on one of them often fails quietly on the next.

Oxidized is well suited to this mess, because it was designed around vendor-specific models and configurable inputs. Yet the difference between a working deployment and a frustrating one usually comes down to two things: choosing the right model for each hardware family, and tweaking the SSH input so that older switches can actually connect. This guide covers both in depth. It maps HPE Aruba and Dell hardware to Oxidized models, explains how to prepare each platform, shows how to relax or tighten SSH settings safely, builds a custom model for a platform that lacks one, and then covers Git versioning, syslog triggers, security, restores, and troubleshooting.

What Is Oxidized for HPE Aruba and Dell Switches?

Oxidized for HPE Aruba and Dell switches is an automated backup workflow in which the Oxidized application connects to switches over SSH, runs the display commands defined in a vendor-specific model, normalizes the output, and commits each changed configuration to a Git repository. Separate models cover ArubaOS-Switch, ArubaOS-CX, Comware, Dell PowerConnect, Dell Networking OS, and related families, and configurable SSH input options let it reach legacy devices that use older algorithms.

Key Takeaways

• HPE and Aruba switches span several operating systems, including ArubaOS-Switch (formerly ProCurve), ArubaOS-CX, and Comware, and each maps to a different Oxidized model.
• Dell switches likewise span PowerConnect, Dell Networking OS6, OS9 (descended from FTOS), and OS10, so identify the operating system before choosing a model.
• Legacy switches often support only outdated SSH key exchange, host key, and cipher algorithms, which Oxidized can accommodate through input variables applied at group level.
• Older switches limit concurrent management sessions, so a modest thread count prevents locking out administrators.
• When no bundled model fits, a short custom model is usually enough.
• Syslog events that mark a configuration save or exit can trigger backups within seconds.
• A restore rehearsal per platform family is the only reliable way to know the backups work.

Supported Models: Mapping Hardware to Oxidized

The first decision is simple but easy to get wrong: which Oxidized model matches which switch. The vendor name is not enough, because a single vendor may sell several unrelated operating systems.

HPE and Aruba Families

Hardware Family	Operating System	Typical Oxidized Model
Aruba 2530, 2540, 2920, 2930F and 2930M, 3810, 5400R	ArubaOS-Switch, formerly ProCurve	procurve
Aruba 6000, 6100, 6200, 6300, 6400, 8100, 8320, 8325	ArubaOS-CX	aoscx
HPE 5130, 5510, 5940, 5945 FlexNetwork	Comware	comware
Aruba wireless controllers and mobility devices	ArubaOS	arubaos
HPE OfficeConnect and legacy 1920 or 1950 series	Varies by firmware	Check the CLI before choosing

Dell Families

Hardware Family	Operating System	Typical Oxidized Model
PowerConnect 3500, 5500, 6200, 8024	PowerConnect firmware	powerconnect
Dell Networking N-series	Dell Networking OS6	dnos6
Dell Networking S-series and Z-series on OS9	Dell Networking OS9, descended from FTOS	A Force10 or OS9 model, depending on release
Dell PowerSwitch S-series on OS10, Z-series on OS10	Dell SmartFabric OS10	May need a custom model

Model names and coverage change between Oxidized releases, so treat the tables above as a starting map rather than a guarantee. Dell naming in particular has shifted several times as the product line was renamed and reorganized.

Verify the Models Your Installation Provides

Before designing anything, list what your installed version actually ships. Inside the container, the gem contents show the bundled model files.

docker exec oxidized gem contents oxidized | grep lib/oxidized/model

The output lists one file per model. Match your platforms to those names, and note any family with no obvious match. Those are the candidates for a custom model, which a later section covers.

Identify the Operating System, Not Just the Vendor

A quick login to each device settles ambiguity. The version banner and the prompt style reveal the family.

Clue	Likely Platform
A Press any key to continue banner after login	ArubaOS-Switch (ProCurve family)
A prompt ending in a pound sign with a hostname and mode path	ArubaOS-CX
Display-style commands such as display current-configuration	Comware
Show running-config with a console-style header and a long exec prompt	PowerConnect or Dell Networking OS6
A configuration header with version and last-change comments	Dell Networking OS9
Show running-configuration spelled out in full	Dell SmartFabric OS10

How Oxidized Works with Switch Platforms

Oxidized organizes its work around sources, inputs, models, and outputs. For switches, the input and model layers matter most.

Architecture Components

Layer	Component	Function in a Switch Deployment
Source	CSV, SQL, HTTP, or NetBox	Lists switches, addresses, models, and groups
Input	SSH, with optional Telnet fallback	Opens the CLI session and negotiates algorithms
Model	procurve, aoscx, comware, powerconnect, dnos6, or custom	Handles login prompts, paging, commands, and cleanup
Output	Git or gitcrypt	Stores each changed configuration as a commit
Hooks	githubrepo, exec, slackdiff	Reacts to stored changes
Interface	REST API and Oxidized Web	Shows node status and allows manual triggers

The Backup Lifecycle

1. Oxidized loads the node list from the source.
2. A worker opens an SSH session, negotiating key exchange, host key, cipher, and message authentication algorithms.
3. The model answers any login banners and escalates to privileged mode if required.
4. The model disables paging so long output does not stall.
5. The model runs its display commands and collects the output.
6. Volatile lines such as uptime and change timestamps are stripped.
7. Oxidized compares the result with the previous version.
8. A changed result becomes a Git commit, and any hook fires.

Input Versus Model: Where Problems Live

A failed backup usually belongs to one of two layers. If the session never opens, the input layer is at fault, typically because of algorithm mismatch, access lists, or credentials. If the session opens but the output is wrong, truncated, or hangs, the model layer is at fault, typically because of prompts, paging, or unsupported commands. Separating the two layers early saves a great deal of debugging time.

Prerequisites and Planning

Requirement	Recommendation	Why It Matters
Backup server	Linux VM with 2 vCPU and 2 GB RAM	Light workload, Git grows steadily
Container runtime	Docker Engine with Compose	Simple upgrades and rollbacks
SSH access	Enabled on a reachable management interface	Oxidized prefers SSH
Service account	Dedicated read-oriented user	Limits blast radius
Source restriction	Management access limited to the Oxidized server	Stolen credentials become far less useful
Time sync	NTP on all devices	Reliable logs and commit times
Remote Git	Private repository on GitLab, GitHub, or Gitea	Protects history if the server fails
Platform inventory	OS family and firmware version per switch	Determines model and SSH tweaks

Session Limits on Older Switches

Many switches allow only a handful of simultaneous management sessions, and some count SSH, Telnet, and console sessions together. If Oxidized runs twenty threads against a stack with five available sessions, it can lock out human administrators or fail intermittently. Therefore, keep the thread count conservative and consider staggering polling by group.

Preparing HPE Aruba Switches

ArubaOS-Switch (ProCurve Family)

These switches present an operator prompt after login, which ends in a greater-than sign, and a manager prompt after enabling, which ends in a pound sign. Many firmware versions also show a banner that waits for a keypress, which the model handles. Start by enabling SSH and creating a dedicated account.

crypto key generate ssh ip ssh ip ssh version 2 password manager user-name oxidized plaintext ChangeThisLongRandomPassword ip authorized-managers 10.10.50.25 255.255.255.255 access manager aaa authentication ssh login local aaa authentication ssh enable local

The authorized-managers entry restricts management access to the Oxidized server, though it also applies to every other administrator, so add the addresses your team needs before enabling it. Commands and options vary by firmware generation, so confirm them with ? on your version.

ArubaOS-CX

Aruba CX uses role-based access control with built-in groups. The auditors group provides read-oriented access, which is exactly what a backup account needs.

user oxidized group auditors password plaintext ChangeThisLongRandomPassword ssh server vrf mgmt

After creating the user, log in from the Oxidized server and run show running-config to confirm that the role can read the configuration. Role permissions vary by software release, so if the output is incomplete, move the user to a broader group temporarily and document why. Additionally, remember that CX switches separate management traffic into a management VRF, so the SSH server must be enabled in the VRF through which Oxidized reaches the switch.

Stacks, VSF, and VSX

Stacked and virtualized switches present a single management address, but the topology matters for backups.

Technology	Backup Consideration
Traditional stack	One configuration for the whole stack, back up the stack address
VSF on ArubaOS-CX	One conductor holds the configuration, back up the shared management address
VSX pairs	Each peer has its own configuration, so back up both peers
Aruba Central managed devices	Configuration is template-driven, so Central is the source of truth

Complementary Aruba Tools

Aruba NetEdit offers configuration validation and history for CX switches, and Aruba Central manages cloud-connected devices through templates and groups. HPE IMC provides configuration management for Comware and some ArubaOS-Switch devices. These tools do not compete with Oxidized so much as sit beside it. In practice, Oxidized provides the independent, multi-vendor, Git-based record, while the vendor tools handle provisioning and validation.

Preparing Dell Switches

PowerConnect and Dell Networking OS6

Older PowerConnect firmware often supports only legacy SSH algorithms and a single host key type, which makes input tweaks essential later. Enable SSH, create the account, and restrict management access.

crypto key generate rsa ip ssh server username oxidized password ChangeThisLongRandomPassword privilege 15 enable password ChangeThisEnablePassword

Because these switches begin in user EXEC mode, Oxidized needs the enable password through its variables. Syntax differs between PowerConnect and OS6 releases, so confirm each command on the device.

Dell Networking OS9

OS9 descends from Force10 FTOS and behaves similarly. The configuration header includes comment lines that record the last change time, which the model or a custom filter should remove.

ip ssh server enable username oxidized password ChangeThisLongRandomPassword privilege 15 ip access-list standard OXIDIZED-ONLY permit host 10.10.50.25 line vty 0 9 access-class OXIDIZED-ONLY

The standard access list shown here is too restrictive for everyday administration, so in production include your team’s addresses alongside the Oxidized server. The point is to make the VTY lines reject sources that should never connect.

Dell SmartFabric OS10

OS10 is Linux-based and uses a different CLI style, including the fully spelled show running-configuration command. It also offers a read-only role well suited to backups.

username oxidized password ChangeThisLongRandomPassword role netoperator ip ssh server enable

The netoperator role provides read-oriented access. As always, log in manually and confirm that it can display the configuration before relying on it, since role permissions vary by release.

Installing Oxidized with Docker

Directory Layout

sudo mkdir -p /srv/oxidized/ssh /srv/oxidized/model sudo chown -R 30000:30000 /srv/oxidized

The Core Configuration File

Save this as /srv/oxidized/config. It uses groups so that each platform family can carry its own credentials and SSH tweaks.

username: oxidized password: ChangeThisLongRandomPassword interval: 3600 use_syslog: false debug: false threads: 5 timeout: 45 retries: 3 rest: 127.0.0.1:8888 input: default: ssh ssh: secure: false output: default: git git: user: Oxidized email: oxidized@example.com repo: /home/oxidized/.config/oxidized/switches.git source: default: csv csv: file: /home/oxidized/.config/oxidized/router.db delimiter: !ruby/regexp /:/ map: name: 0 ip: 1 model: 2 group: 3 groups: aruba-cx: username: oxidized password: CxLongRandomPassword aruba-legacy: username: oxidized password: LegacyLongRandomPassword dell-legacy: username: oxidized password: DellLongRandomPassword vars: enable: ChangeThisEnablePassword

Five threads is a deliberately low starting point. Meanwhile, the 45-second timeout leaves room for older switches that render large configurations slowly. Switch secure to true in production once known hosts are populated.

The Device Inventory

sw-core-cx-01:10.10.2.1:aoscx:aruba-cx sw-access-pc-07:10.10.7.7:procurve:aruba-legacy sw-edge-dell-03:10.10.9.3:powerconnect:dell-legacy sw-leaf-os6-02:10.10.9.12:dnos6:dell-legacy

Start the Container

docker run -d --name oxidized \ --restart unless-stopped \ -p 127.0.0.1:8888:8888 \ -v /srv/oxidized:/home/oxidized/.config/oxidized \ oxidized/oxidized:latest oxidized

Follow the first run with docker logs -f oxidized, then confirm with curl -s http://127.0.0.1:8888/nodes.json and git -C /srv/oxidized/switches.git log --oneline. If any node fails, note whether the failure occurs before or after the session opens, because that tells you whether to look at inputs or models.

Custom Input Tweaks for Legacy and Unusual Switches

The input layer is where most older switches fail. A device manufactured a decade ago may offer only a key exchange algorithm that modern clients disable by default, and Oxidized inherits that strictness from its SSH library. The solution is not to weaken everything, but to relax exactly what each legacy group requires.

Symptoms of an Input Mismatch

Symptom	Likely Input Cause
Connection closes immediately after the handshake	No shared key exchange algorithm
Host key errors or negotiation failures	Switch offers only an older host key type
Cipher negotiation errors	Only legacy ciphers available on the device
Authentication fails with correct credentials	Authentication method mismatch
Session opens, then drops on the first command	Device does not support the exec channel
Intermittent failures under load	Management session limit reached

Relaxing Legacy SSH Algorithms

Oxidized supports input variables for key exchange, host key, message authentication, and encryption algorithms. Apply them at group level so that only the legacy platforms are affected. First, discover what the switch actually offers.

ssh -vv oxidized@10.10.9.3 2>&1 | grep -i "kex\|host key\|cipher\|mac" | head -20

The verbose output lists the algorithms each side proposes and shows where negotiation fails. Then add the minimum necessary values to the legacy group.

groups: dell-legacy: username: oxidized password: DellLongRandomPassword vars: enable: ChangeThisEnablePassword ssh_kex: diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 ssh_host_key: ssh-rsa,ssh-dss ssh_hmac: hmac-sha1 ssh_encryption: aes128-cbc,3des-cbc

Variable names and accepted values depend on your Oxidized version and its SSH library, so confirm them in the documentation for your release. Moreover, treat this configuration as a documented exception rather than a default. Legacy algorithms are weak, so keep these switches on an isolated management network, accept them only for the specific groups that need them, and record a plan to retire or upgrade the devices.

Handling Devices Without an Exec Channel

Some switches accept an SSH login but reject commands sent through the exec channel, which is the mechanism Oxidized normally prefers. For those devices, force an interactive shell session instead.

groups: aruba-legacy: username: oxidized password: LegacyLongRandomPassword vars: ssh_no_exec: true

Bundled models often set the correct behavior for their platform already, so add this only if the session opens and then drops on the first command.

Authentication Method Control

When a switch advertises several authentication methods and handles them poorly, restricting Oxidized to a specific method can resolve odd failures. Public key authentication also removes the password from your configuration file, which is an advantage where supported.

groups: aruba-cx: username: oxidized vars: ssh_keys: /home/oxidized/.config/oxidized/ssh/id_rsa

Telnet Fallback as a Last Resort

Oxidized can try SSH first and fall back to Telnet.

input: default: ssh, telnet

Because Telnet sends credentials and configurations in clear text, use it only on a trusted, isolated management VLAN, and only until the device can be upgraded. In addition, log a finding for every node that relies on it.

Reaching Switches Through a Jump Host

Where switches sit on a network that the Oxidized server cannot reach directly, an SSH proxy variable routes the session through a bastion.

groups: remote-branches: vars: ssh_proxy: backup@bastion.example.com

This approach keeps the management network closed while still allowing automated backups.

Summary of Input Tweaks

Tweak	Use When	Risk
Legacy key exchange, host key, cipher, and MAC variables	The switch supports only old algorithms	Weaker cryptography, so isolate and plan retirement
Forced shell session	The device rejects exec channel commands	Slightly slower, more prompt sensitivity
Public key authentication	The switch supports keys	Key management overhead
Telnet fallback	SSH is impossible	Clear text credentials
SSH proxy	Switches sit behind a bastion	Bastion becomes a dependency
Lower threads and longer timeouts	Management sessions are limited or slow	Longer overall polling time

Writing a Custom Model for a Platform Without One

When no bundled model matches, a custom model is often a few dozen lines. Dell SmartFabric OS10 is a common example. Save the following as /srv/oxidized/model/dellos10.rb. It disables paging, prints version and inventory as comments, removes volatile lines, and displays the running configuration.

class DellOS10 < Oxidized::Model comment '! ' prompt %r{^\r?[\w.@/()-]+#\s?$} cmd :all do |cfg| cfg.each_line.to_a[1..-2].join end cmd 'show version' do |cfg| cfg.gsub!(/^Up Time:.*\n/, '') comment cfg end cmd 'show inventory' do |cfg| comment cfg end cmd 'show running-configuration' do |cfg| cfg.gsub!(/^! Last configuration change at .*\n/, '') cfg end cfg :ssh do post_login 'terminal length 0' pre_logout 'exit' end end

The model name used in the inventory is the lowercase class name, so this one becomes dellos10. Restart the container so Oxidized loads the file, then add nodes using that name.

sw-leaf-os10-01:10.10.10.1:dellos10:dell-os10

A Testing Checklist for Any Custom Model

1. Run the commands manually and confirm that every one is permitted for the backup account.
2. Confirm that the prompt pattern matches every prompt the session produces.
3. Back up the device twice in a row and confirm that no commit results.
4. Change a harmless setting and confirm that exactly one commit appears.
5. Check that the output ends cleanly and is not truncated by paging.
6. Store the model in version control and review changes like any other code.

These models are sketches built on standard Oxidized syntax, so adapt the command names, prompts, and filters to your platform and software version before production use.

Git Versioning for Switch Configurations

Why Git Fits

Switch configurations are line-oriented text where one VLAN or one port setting is one or a few lines. Consequently, a Git diff shows precisely what changed on which port or VLAN, even in configurations with thousands of lines. Git also provides integrity, compact storage, and tools that auditors already recognize.

Reading the History

git clone /srv/oxidized/switches.git ~/switch-configs cd ~/switch-configs # Last five changes to one switch git log -5 --stat -- aruba-cx/sw-core-cx-01 # What changed in the latest commit git show HEAD -- aruba-cx/sw-core-cx-01 # Compare two points in time git diff HEAD~10 HEAD -- aruba-cx/sw-core-cx-01

Because nodes are stored under their group directory, adjust paths accordingly. Commit messages record the node, so git log --grep finds every change to one switch quickly.

Push to a Remote Repository

hooks: push_to_remote: type: githubrepo events: [post_store] remote_repo: git@git.example.com:netops/switch-configs.git publickey: /home/oxidized/.config/oxidized/ssh/deploy.pub privatekey: /home/oxidized/.config/oxidized/ssh/deploy

The hook works with any SSH-reachable Git server. Use a deploy key limited to this repository and protect the main branch so history cannot be rewritten.

Taming Noise in Switch Backups

A Git history is only useful when its commits mean something. If every hourly run produces a change, reviewers stop looking and the one meaningful edit disappears. Switch noise tends to come from a short list of platform-specific sources.

Platform	Noise Source	Remedy
ArubaOS-Switch	Uptime and session details in system output	Strip uptime lines in the model and keep the configuration text itself
ArubaOS-CX	Dynamic or timestamped values in version output	Review the first diffs and filter anything that changes without an administrator action
Comware	Clock and uptime fields in display output	Remove volatile fields from informational commands
PowerConnect and OS6	Uptime and clock lines	Strip them in the model or a custom filter
Dell OS9	Last configuration change and startup update comments	Remove those header comment lines
Dell OS10	Last configuration change comment and uptime	Filter, as the custom model above does
Stacks and VSX	Member-specific values that differ between peers	Keep each peer as its own node

After changing any model or filter, run two consecutive backups of a quiet lab switch. If the second run produces a commit, noise remains. Repeat until two consecutive runs produce identical files, and only then deploy broadly.

The Secrets Decision

Switch configurations often contain sensitive material. Depending on platform and settings, running configurations can reveal SNMP community strings, RADIUS or TACACS+ shared keys, local password hashes, and VPN or routing authentication keys.

Policy	What You Gain	What You Risk
Keep secrets in the stored configuration	Complete record, better restore fidelity	Repository must be protected like a credential store
Strip secrets in the model	Safer repository, easier sharing	Restores require re-entering secrets
Encrypt the repository	Protects secrets at rest	Requires key management

Because many switch platforms display some secrets in clear text by default, check each family. For example, ArubaOS-Switch offers a credential-encryption setting that changes how stored secrets appear, so consider enabling it where your firmware supports it. Regardless of policy, never mirror the repository to a public or shared platform, and apply gitcrypt or disk encryption on the backup server.

Real-Time Backups with Syslog Triggers

Hourly polling leaves a gap between a change and its capture. Most switches can announce configuration events through syslog, which allows Oxidized to capture the change within seconds.

How It Works

1. An administrator changes or saves the configuration.
2. The switch generates a log message describing the event.
3. The message is forwarded to the Oxidized server over syslog.
4. rsyslog passes the sender address and message to a script.
5. The script recognizes a configuration event and calls the Oxidized API.
6. Oxidized fetches the configuration and commits the diff.

Choosing the Right Event per Platform

Every vendor words these messages differently, and wording changes between firmware releases. The safest approach is to make a harmless change on a lab switch, capture the resulting syslog lines, and build your pattern from real data.

Platform	What to Look For
ArubaOS-Switch	Log entries recording a configuration save or a manager session change
ArubaOS-CX	Event log entries that record configuration changes by user
Dell OS9	Messages that state the configuration was changed from a console or VTY line
PowerConnect and OS6	Messages recording a copy of the running configuration to startup
Dell OS10	Log entries for configuration commits and saves

Configure Forwarding

Send logs to the Oxidized host from each switch, using the platform’s own syntax. A generic example from a Dell-style CLI looks like this, and other platforms use similar statements.

logging 10.10.50.25

After configuring each family, confirm that messages arrive on the server and note the source address the switch uses, because the trigger identifies devices by IP.

Configure rsyslog and the Script

template(name="ipmsg" type="string" string="%fromhost-ip% %msg%\n") module(load="imudp") input(type="imudp" port="514" ruleset="sw") ruleset(name="sw") { action(type="omprog" binary="/usr/local/bin/oxidized-trigger.sh" template="ipmsg") }

#!/bin/bash PATTERN='CONFIG_I|FILECPY|startup-config|Configuration changed|configuration save' while read -r ip msg; do case "$msg" in *oxidized*) ;; *) if [[ "$msg" =~ $PATTERN ]]; then curl -s "http://127.0.0.1:8888/node/next/${ip}" > /dev/null fi ;; esac done

The pattern above is a starting point containing fragments that appear on some platforms, so replace it with strings taken from your own captured messages. Notice the first case, which ignores messages that mention the backup account. Without it, Oxidized’s own login could trigger another backup, which would trigger another. Furthermore, restrict the listener to switch addresses and consider a short debounce, so that a busy change window does not flood the queue.

Using the Oxidized REST API and Web Interface

Endpoint	Purpose
/nodes	Lists nodes with status and last run time
/nodes.json	Same data in JSON for automation
/node/fetch/NAME	Returns the latest stored configuration
/node/next/NAME	Queues an immediate backup
/node/version?node_full=GROUP/NAME	Lists stored versions
/reload	Reloads the inventory

The JSON node list is a convenient monitoring feed. Alert on any node that remains in a failed state for more than two intervals. That catches expired credentials, changed access lists, firmware upgrades that altered SSH algorithms, and switches that have quietly gone offline.

Securing the Backup Pipeline

Switch configurations reveal VLAN design, trunking, spanning tree roots, management addresses, and sometimes secrets, so the repository deserves careful protection.

Control	Recommendation
Service account	Dedicated user, read-oriented role, source-restricted
Legacy algorithms	Enabled only per group, on an isolated management network, with a retirement plan
Telnet	Avoid, or confine to a trusted VLAN and track every node using it
Host key checking	Enable once known hosts are populated
API exposure	Bind to localhost, publish only through an authenticated TLS proxy
Repository	Private remote, deploy key, protected main branch
Encryption at rest	Use gitcrypt or disk encryption on the backup server
Server hardening	Patch regularly, restrict SSH, use disk encryption
Monitoring	Alert on failed nodes and unexpected commits

These measures follow CIS Controls guidance on secure configuration of network devices and the configuration management controls in NIST SP 800-53. In addition, weak legacy cryptography should appear on your risk register as an accepted exception with an owner and a date, which turns a quiet liability into a managed one.

Restoring Switches from Backups

Restore procedures differ widely, and the most dangerous assumption is that loading a file replaces the existing configuration. On many platforms, copying a file into the running configuration merges it.

General Restore Workflow

1. Retrieve the target version from Git and confirm it with git diff against the current state.
2. Review the file for secrets that were stripped or masked.
3. Place the file on a TFTP, SCP, or SFTP location the switch can reach.
4. For a clean rebuild, load the file as the startup configuration and reload.
5. For a targeted rollback, paste only the affected sections into configuration mode.
6. Save the configuration, then verify VLANs, trunks, spanning tree, routing, and management access.

Platform Notes

Platform	Restore Approach	Caution
ArubaOS-Switch	Copy the file to the startup configuration and reboot	Confirm the firmware version matches the file
ArubaOS-CX	Copy from a remote server, or use a checkpoint for quick rollback	Behavior of copy to running configuration differs by release, so test first
Comware	Load the file as the next startup configuration and reboot	Check boot settings before reloading
PowerConnect and OS6	Copy the file to the startup configuration and reload	Copy to running configuration merges
Dell OS9	Copy to startup configuration and reload	Merge behavior applies to the running configuration
Dell OS10	Use the platform’s copy and load procedure for your release	Confirm whether the operation merges or replaces

As an example, a clean rebuild of a ProCurve-family switch from a TFTP server uses a copy to the startup configuration.

copy tftp startup-config 10.10.50.25 sw-access-pc-07.cfg

The switch then prompts for a reboot to apply the file. Syntax differs between firmware generations, so confirm it with tab completion and rehearse the procedure on a spare unit before an emergency forces the first attempt.

Change Auditing and Compliance Evidence

Because every commit records what changed and when, Git history combined with switch logs forms a complete audit trail.

Framework	Relevant Area	How the Workflow Helps
NIST SP 800-53	CM-2, CM-3, CM-6	Baselines, tracked changes, documented settings
CIS Controls	Secure configuration of network devices	Versioned, reviewable switch configurations
ISO 27001:2022	Configuration management	Retrievable configuration history
PCI DSS 4.0	Network security control reviews	Diffs that simplify periodic review
SOC 2	Change management criteria	Timestamped records of production changes

To put this to work, send a daily digest of commits to the network team and require that each commit correlate with an approved change ticket. As a result, undocumented changes surface within a day instead of at the next audit.

Scaling Across Many Switches

Groups for Platforms and Credentials

Groups are the key to scale in a mixed estate. Each platform family gets its own group carrying credentials, SSH tweaks, and enable variables. Git then stores each group in its own directory, which keeps a large repository navigable.

A Source of Truth for the Inventory

A CSV file is fine for a pilot, yet it drifts over time. Switching to NetBox or an HTTP source means the inventory follows your documentation, with the platform and role taken from device attributes, and retired switches leave the rotation automatically.

Timing and Load

Because older switches have small session pools, keep thread counts low and stagger polling across groups. Meanwhile, rely on syslog triggers for timely capture instead of shortening the interval, and raise timeouts before raising retries for slow or remote sites.

Troubleshooting Switch Backups in Oxidized

Symptom	Likely Cause	Fix
Connection closes right after the handshake	No shared key exchange, host key, cipher, or MAC algorithm	Inspect with verbose ssh and add the minimum legacy values to that group
Node shows no_connection	Access list, authorized-managers, or VRF blocks the server	Test manually from the Oxidized host and adjust management access
Authentication failed	Wrong password, role lacks login rights, or method mismatch	Verify the same login manually and review authentication settings
Session opens then drops on the first command	Exec channel unsupported	Force a shell session with the no-exec variable
Output stalls at a pager prompt	Paging not disabled by the model	Confirm the model’s pager command and that it is permitted
Hang at the Press any key banner	Model mismatch or custom banner	Confirm the procurve model for that family and test manually
Wrong or empty output	Wrong model for the operating system	Identify the OS and choose the matching model
Intermittent failures	Management session limit reached	Reduce threads and stagger groups
Commit on every run	Uptime or change-time comments	Strip volatile lines and verify two matching runs
Backup loop after a syslog trigger	Oxidized’s own session triggers messages	Exclude the service account in the trigger script
Custom model not found	File name, class name, or ownership issue	Match the lowercase class name and check file permissions

Debugging a Single Node

Isolate the failing node, enable debug temporarily, and restart the container. Then run the same login and commands manually over SSH with the same account and compare the transcripts. If the session never opens, work on the input layer. If it opens and the output is wrong, work on the model layer.

After a Firmware Upgrade

Firmware upgrades often change SSH algorithms, banners, or command output. When backups begin failing afterward, update the Oxidized image, retest the group’s SSH variables, and compare a manual session with the model’s expectations. Upgrades can also remove legacy algorithms, which helpfully eliminates the need for some tweaks.

Common Mistakes to Avoid

• Choosing a model by vendor name instead of by operating system.
• Enabling legacy SSH algorithms globally rather than per group.
• Running too many threads against switches with small session pools.
• Leaving Telnet fallback enabled long after the need passed.
• Assuming a restore replaces the running configuration when it actually merges.
• Storing secrets in a repository that is mirrored to a shared platform.
• Backing up only one peer of a VSX or similar pair.
• Trusting custom models without a two-run noise test.
• Allowing the backup account’s own login to trigger syslog-driven backups.
• Never rehearsing a restore for each platform family.

Oxidized Compared with Other Switch Backup Options

Method	Cost	Version Control	Multi-Vendor	Best Fit
Oxidized	Free	Native Git	Yes	Readable history and API across vendors
Aruba NetEdit	Licensed	Revision history	Aruba CX focused	Validation and compliance on CX switches
Aruba Central	Subscription	Template and change history	Aruba focused	Cloud-managed Aruba estates
HPE IMC	Licensed	Yes	Broad but HPE centered	Comware and HPE environments
Dell OpenManage tools	Varies	Varies	Dell focused	Dell-centric environments
Ansible with vendor collections	Free	You build it	Yes	Teams invested in Ansible
Commercial NCM suites	Licensed	Yes	Yes	Vendor support and reporting

In practice, vendor tools handle provisioning and validation for their own platforms, whereas Oxidized provides the single, readable, multi-vendor history that sits across all of them. Teams with mixed estates therefore tend to run both.

Real-World Scenarios

Scenario One: Finding the Change Behind a Spanning Tree Event

A campus experiences a brief outage after hours. The engineer opens the Git history for the core CX switches and finds a commit twenty minutes earlier that changed a spanning tree priority. The diff shows exactly which line changed, the switch log names the administrator, and the fix is a single-line revert instead of an evening of speculation.

Scenario Two: Bringing Legacy Dell Switches into the Fold

A team inherits a closet of PowerConnect switches whose SSH negotiation fails from the Oxidized server. A verbose SSH test shows that the switches offer only an older key exchange and host key type. The team creates a dedicated group with those two values relaxed, places the switches on an isolated management VLAN, and logs a risk entry with a retirement date. Backups succeed, and the exception is visible rather than hidden.

Scenario Three: Replacing a Failed Access Switch

An ArubaOS-Switch access stack fails during a storm. The replacement is staged with the matching firmware, loaded with the latest configuration as the startup configuration, and rebooted. Because the team rehearsed the procedure and restored the stripped secrets from their password manager, the closet returns to service within the hour.

Optimization Recommendations

Area	Recommendation	Benefit
Model selection	Match by operating system and verify with the gem contents list	Correct output on the first run
SSH tweaks	Apply per group, document each exception	Controlled risk
Threads	Start at five and increase gradually	Avoids session exhaustion
Polling	Hourly interval plus syslog triggers	Fresh data, low load
Custom models	Keep in version control and test twice	Reproducible behavior
Repository	Off-site mirror and periodic garbage collection	Resilience and smaller storage
Secrets	Encrypt the repository and strip secrets where policy allows	Safer storage
Documentation	README with restore steps per platform	Faster recovery under pressure

Frequently Asked Questions

Does Oxidized support HPE Aruba switches?

Yes. Oxidized includes models for ArubaOS-Switch (procurve), ArubaOS-CX (aoscx), and HPE Comware (comware), among others. Choose the model that matches the switch’s operating system.

Does Oxidized support Dell switches?

Yes, for several families. PowerConnect and Dell Networking OS6 have bundled models, OS9 is covered by a Force10-style model in many releases, and OS10 may need a small custom model.

Which Oxidized model should I use for an Aruba 2930F?

The 2930F runs ArubaOS-Switch, so use the procurve model. Newer Aruba CX models such as the 6300 use the aoscx model.

How do I connect Oxidized to a switch with old SSH algorithms?

Inspect the negotiation with verbose ssh, then set the key exchange, host key, cipher, and MAC variables for only the affected group. Isolate those switches and plan to retire or upgrade them.

Is it safe to enable legacy SSH algorithms?

It weakens the connection, so confine it to an isolated management network, limit it to the groups that need it, and document it as a risk exception with a retirement date.

What permissions does the Oxidized account need on a switch?

A read-oriented role that can run show or display commands and disable paging. Examples include the auditors group on Aruba CX and the netoperator role on Dell OS10. Test the exact commands your model runs.

Can Oxidized back up stacked or VSX switches?

Yes. Back up the stack or conductor address for stacks and VSF, and back up each peer of a VSX pair separately.

Why does my Dell switch backup commit on every run?

OS9 and OS10 headers include last-change comments, and many platforms show uptime. Strip those lines in the model and confirm that two consecutive runs match.

How do I write a custom model for an unsupported switch?

Save a short Ruby class in the model directory that sets the prompt, disables paging, runs the display commands, and removes volatile lines. Restart Oxidized and use the lowercase class name in the inventory.

Can Oxidized restore a configuration to the switch?

No. Oxidized collects and versions configurations. Restoration uses the switch’s own copy and load commands, which vary by platform.

Conclusion

Backing up HPE Aruba and Dell switches with Oxidized comes down to two disciplines: choosing the right model for each operating system, and tuning the input layer so every device can actually connect. Where models exist, they work well. Where they do not, a short custom model fills the gap. Where devices are old, carefully scoped SSH tweaks keep them in the rotation without weakening everything else. Furthermore, syslog triggers, Git history, and rehearsed restores turn a collection of exceptions into a dependable system.

The practical next step is small. List your switch families, map each to a model using the gem contents check, and pilot one switch per family. Fix connection failures at the input layer and output problems at the model layer, run the two-backup noise test, and rehearse one restore for each platform. After that, scale out by group and let the repository become the record of truth for your multi-vendor network.