Oxidized : sauvegarde automatique des configurations réseau dans Git

Le jour où un switch tombe et qu'on doit reconstruire sa config, on découvre qu'il n'y a aucun backup à jour. Le dernier export de conf date d'il y a 18 mois, fait à la main par un sysadmin parti depuis. Le NOC se retrouve à reconstruire la config par mémoire et par déduction. Coût d'incident multiplié par dix.

Oxidized résout ce problème depuis 2014. Successeur de RANCID, il automatise la collecte de configurations réseau de tous les équipements d'un parc, les versionne dans Git, alerte sur changements, expose une UI web. Pour les ops réseau, c'est un outil non négociable côté gouvernance.

Pas de magie : Oxidized se connecte en SSH ou Telnet aux équipements, exécute les commandes "show running-config", stocke la sortie, commit dans Git si elle a changé. Simple et éprouvé, multi-vendor.

• Le problème : configs réseau non versionnées
• Architecture Oxidized
• Support multi-vendor : Cisco, Juniper, MikroTik, etc.
• Configuration et inventaire
• Versioning Git et workflow
• Alerting sur changements
• Intégration LibreNMS, NetBox, monitoring
• Pièges et limites

Trois pathologies courantes en gouvernance réseau.

Pas de backup. Sur un parc de 30 switches Cisco, personne ne sait dire quelle est la dernière config sauvegardée. Au crash, on retombe sur des fichiers .txt épars datant d'il y a 2 ans.

Pas de traçabilité. Un switch a été modifié hier. Par qui, pourquoi, qu'est-ce qui a changé ? Aucune trace. Diff impossible.

Pas d'audit. Pour une certification ISO ou un audit PCI, on doit prouver qu'une config respecte les baselines. Sans versioning, impossible de répondre.

Oxidized résout les trois en un outil de 200 lignes Ruby + des hooks adaptés à chaque vendor.

Oxidized est en Ruby, monoprocess, simple :

• Loop principale : itère toutes les X minutes (typiquement 1h) sur la liste d'équipements.
• Connexion : se connecte en SSH/Telnet à chaque équipement avec les credentials configurés.
• Modèle : exécute les commandes spécifiques au vendor pour récupérer la config (show running-config sur Cisco, show configuration sur Juniper, etc.).
• Stockage : compare avec la version précédente. Si différent, commit dans Git.
• API REST + Web UI : expose les configs et l'historique.

Stockage Git local par défaut. On peut pointer vers un repo Git distant (GitLab, Forgejo, etc.) pour redondance et accès UI Git natif.

Hook system : sur chaque commit, exécution de scripts custom (alertes, push vers SIEM, etc.).

Oxidized supporte 130+ types d'équipements via des "models" Ruby. Couverture représentative :

Si un vendor manque, on écrit un model Ruby de 30-50 lignes.

Configuration ~/.config/oxidized/config :

username: oxidized-readonly
password: <secret>
model: cisco
interval: 3600
log: ~/.config/oxidized/oxidized.log
debug: false
threads: 30

source:
  default: csv
  csv:
    file: ~/.config/oxidized/router.db
    delimiter: !ruby/regexp /:/
    map:
      name: 0
      ip: 1
      model: 2
      username: 3
      password: 4

output:
  default: git
  git:
    user: oxidized
    email: oxidized@exemple.fr
    repo: /var/lib/oxidized/configs.git

hooks:
  push_to_remote:
    type: exec
    events: [post_store]
    cmd: 'cd /var/lib/oxidized/configs.git && git push origin master'

Inventaire router.db :

core-sw-01:10.0.0.1:cisco:admin:secret
core-sw-02:10.0.0.2:cisco:admin:secret
edge-rt-01:10.0.0.5:juniper:admin:secret
fw-edge-01:10.0.0.10:fortios:admin:secret
mikrotik-1:10.0.0.20:routeros:admin:secret
vyos-bordure-01:10.0.0.30:vyos:admin:secret

Pour des parcs >50 équipements, importer depuis un CMDB (NetBox via plugin) plutôt que CSV.

Oxidized commit chaque changement dans le repo Git :

commit a1b2c3d4
Author: oxidized <oxidized@exemple.fr>
Date:   2026-06-12 10:23

    core-sw-01.cfg

diff --git a/core-sw-01.cfg b/core-sw-01.cfg
+ interface GigabitEthernet0/24
+  description Link to backup-server
+  switchport mode access
+  switchport access vlan 100

Visualisation côté GitLab / Forgejo : on parcourt le repo comme un repo de code, on voit l'historique, le blame, les diffs entre commits. Pour un audit, rien de mieux.

Pour aller plus loin :

• Backup automatique du repo Git lui-même via Restic ou Kopia.
• Push vers un repo Git distant pour redondance.
• Hooks pour pousser vers un autre stockage (S3, NFS) en complément.

Les hooks Oxidized réagissent sur événements :

hooks:
  alert_change:
    type: exec
    events: [post_store]
    cmd: |
      curl -X POST -H 'Content-Type: application/json' \
        -d "{\"text\":\"Config changed: $OXIDIZED_NODE_NAME\"}" \
        https://hooks.slack.com/services/XXX

Sur chaque commit, un message Slack est envoyé indiquant quel équipement a changé. Pour le NOC qui doit savoir si un changement non planifié a eu lieu, c'est immédiat.

Patterns d'alerte courants :

• Slack/Teams : channel #network-changes qui reçoit chaque diff résumé.
• Email : pour des changements sur équipements critiques (routeurs de bordure).
• SIEM : push vers Wazuh / Splunk pour corrélation avec d'autres événements.
• Webhook ServiceNow / Jira : pour ouvrir un ticket si changement non autorisé.

Pour des règles fines (ex: alerter uniquement si la config touche aux ACLs), filtrer dans le hook avec git diff parsé.

LibreNMS : plugin Oxidized officiel. Depuis l'UI LibreNMS, on voit la config Oxidized de chaque équipement et son historique. Voir librenms-snmp-2026 pour la stack monitoring SNMP.

NetBox : Oxidized peut consommer NetBox comme source d'inventaire via plugin. Plus de double maintenance d'inventaire. Voir netbox-documentation-reseau.

Grafana : tableau de bord nombre de changements par équipement / par jour. Métriques exposées via API Oxidized.

Stack logging : push des changements vers Loki ou Vector pour analyse historique avec autres logs.

Credentials en clair. Les login/password sont en clair dans router.db. Permissions strictes (mode 0600), root only, ou utiliser un secret manager via env vars.

Comptes "oxidized" en read-only. Sur chaque équipement, créer un compte dédié read-only avec les commandes "show" autorisées et rien d'autre. Si le serveur Oxidized est compromis, les credentials ne permettent pas de modifier.

SSH legacy. Beaucoup d'équipements anciens n'acceptent que SSH 1.x ou des algos obsolètes. Oxidized supporte ces dialectes mais demande config spécifique. Documenter par modèle.

Performance. 30 threads en parallèle pour 100 équipements donnent un cycle de 30-60 minutes. Au-delà de 1000 équipements, scinder en plusieurs instances Oxidized par site.

Diff trop verbeux. Certains équipements (Cisco surtout) ré-écrivent leurs configs avec timestamps ou comptages dynamiques qui changent à chaque show. Le diff est pollué. Filtrer avec sed/awk dans le model Ruby ou ignorer ces lignes.

Pas un orchestrateur. Oxidized lit. Pour pousser des changements, utiliser Ansible avec modules réseau, ou Terraform avec providers spécifiques. Voir terraform-iac ou automatiser-configuration-ansible.

Multi-tenant. Oxidized n'a pas de RBAC fin. Si on veut donner accès aux configs d'un sous-périmètre à une équipe spécifique, passer par les permissions Git du repo distant.

SSH bastion. Oxidized ne supporte pas natif les bastions. Soit on l'installe sur le bastion, soit on configure SSH ProxyJump dans ~/.ssh/config du user oxidized.

Oxidized devient vite un standard dès qu'un parc réseau dépasse la dizaine d'équipements. Le coût de mise en place est faible et l'apport sur la gouvernance, l'audit et la restauration est immédiat. Sur un parc hétérogène avec des backups de configs artisanaux, la stack Oxidized + Git distant + alerting se monte en quelques jours. Reste à la faire tourner dans la durée : surveiller les cycles, traiter les équipements qui décrochent, garder les models à jour, ce qui rentre dans le maintien en conditions opérationnelles.

• Oxidized GitHub : code source, models, releases.
• Oxidized models : drivers vendor.
• LibreNMS Oxidized integration : intégration officielle monitoring.
• NetBox Oxidized plugin : intégration source d'inventaire.
• RANCID project : ancêtre historique d'Oxidized.
• Network Automation with Ansible : complément pour automatiser les pushs.