Gestion réseau, supervision et référentiels d’exploitation
Gestion réseau, supervision et référentiels d’exploitation
Section intitulée « Gestion réseau, supervision et référentiels d’exploitation »Un réseau ne s’exploite pas avec de la mémoire humaine. Il lui faut une carte à jour (inventaire, documentation, configurations sauvegardées), des instruments de mesure (métriques, journaux, résumés de flux) et une discipline du changement qui permet de modifier sans casser, ou de revenir en arrière quand on a cassé quand même. Cette fiche décrit ces trois piliers, les protocoles qui les servent, de SNMP (Simple Network Management Protocol) aux exports de flux, et la manière de relier les mesures aux engagements de service.
→ Lire l’explication complète de la marmotte
Administrer sans perdre la carte
Section intitulée « Administrer sans perdre la carte »Inventaire, nommage et dépendances
Section intitulée « Inventaire, nommage et dépendances »L’inventaire est la liste de référence de tout ce qui compose le réseau : équipements, liens, VLAN (Virtual Local Area Network), préfixes d’adresses, routes statiques, règles de filtrage, contrats opérateurs. Il prend souvent la forme d’une CMDB (Configuration Management Database), base qui décrit chaque élément de configuration et ses relations avec les autres. Des outils spécialisés comme NetBox combinent inventaire et gestion des adresses ; le choix de l’outil compte moins que la règle d’or : une seule source de vérité, mise à jour au moment du changement et non trois mois plus tard.
Le nommage fait partie de la carte. Un nom comme par1-dist-sw02 dit le site (Paris, bâtiment 1), le rôle (distribution), le type (commutateur) et le rang. Un nom comme switch-nouveau ne dit rien, sinon qu’il ne l’est plus. Le même effort s’applique aux interfaces : une description UPLINK vers par1-core-rt01 Te0/1 sur chaque port épargne des heures de traçage de câbles.
Les dépendances complètent l’inventaire : ce commutateur alimente tel étage, ce lien porte tel site, ce serveur DNS sert telle zone. Sans elles, l’inventaire répond à « qu’avons-nous ? » mais pas à la seule question qui compte pendant un incident : « qu’est-ce qui tombe si cela tombe ? ».
Sauvegarder les configurations
Section intitulée « Sauvegarder les configurations »Chaque configuration d’équipement doit être sauvegardée automatiquement, versionnée et horodatée. Des outils comme RANCID ou Oxidized se connectent périodiquement aux équipements, récupèrent la configuration courante et l’enregistrent dans un dépôt de versions. Le bénéfice est double : restaurer un équipement remplacé en quelques minutes, et répondre précisément à « qu’est-ce qui a changé depuis hier ? » par un simple différentiel. Ces sauvegardes contiennent des secrets (communautés SNMP, clés partagées, empreintes de mots de passe) : leur dépôt mérite la même protection que les équipements eux-mêmes.
Superviser et mesurer
Section intitulée « Superviser et mesurer »Plans de gestion, de contrôle et de données
Section intitulée « Plans de gestion, de contrôle et de données »Un équipement réseau se pense en trois plans. Le plan de données transporte les paquets des utilisateurs. Le plan de contrôle calcule comment les transporter : protocoles de routage, arbre couvrant, signalisation qui établit des chemins ou des appels avant que les données circulent. Le plan de gestion sert à administrer l’équipement : configuration, supervision, journaux, mises à jour. Le plan de gestion doit passer par un réseau d’administration séparé ; une interface de gestion joignable depuis le réseau des postes, ou pire depuis Internet, est l’une des trouvailles les plus fréquentes et les plus embarrassantes d’un audit. Le plan de gestion du réseau, au sens organisationnel, désigne aussi le document qui décrit qui supervise quoi, avec quels outils et quels engagements.
SNMP, interfaces web et API
Section intitulée « SNMP, interfaces web et API »SNMP fonctionne sur UDP (User Datagram Protocol) : un gestionnaire interroge les agents des équipements sur le port 161, et les agents envoient des notifications spontanées (traps) vers le port 162. Les valeurs sont rangées dans une MIB (Management Information Base), arborescence d’objets identifiés par des numéros. Les versions 1 et 2c s’authentifient par une simple « communauté » transmise en clair ; la version 3, définie par les RFC 3411 à 3418, ajoute une véritable authentification et le chiffrement. Laisser la communauté public en lecture sur un équipement exposé revient à publier sa table de routage et sa liste d’interfaces.
Un piège numérique classique concerne les compteurs. Le compteur ifInOctets tient sur 32 bits et repasse à zéro après 4 294 967 296 octets : sur un lien à 1 Gbit/s saturé, soit 125 millions d’octets par seconde, il boucle en 34 secondes environ. Interrogé toutes les cinq minutes, il produit des débits absurdes. Les compteurs 64 bits ifHCInOctets existent précisément pour cela.
La gestion web, interfaces graphiques embarquées dans les équipements, convient à un petit parc mais se prête mal à l’automatisation. Les parcs modernes s’administrent par des API (Application Programming Interface) : NETCONF (RFC 6241) et les modèles de données YANG (RFC 7950), ou des interfaces REST propres aux constructeurs. Entre les outils de supervision et les équipements s’intercale souvent un middleware, couche logicielle qui collecte, normalise et redistribue les données. Le modèle DME (Distributed Management Environment), cadre de gestion distribuée promu par l’OSF (Open Software Foundation) au début des années 1990, illustrait cette ambition d’une gestion unifiée reposant sur une couche commune ; il n’a pas connu d’adoption durable et n’a plus qu’un intérêt historique.
Journaux et flux
Section intitulée « Journaux et flux »Les journaux d’équipements, transmis par syslog vers un collecteur central, décrivent des événements : interface tombée, voisin de routage perdu, connexion administrateur, règle refusée. Ils ne valent que si les horloges sont synchronisées (voir DNS, DHCP, NTP) et si leur conservation est prévue avant l’incident.
Les résumés de flux disent qui a parlé à qui, sur quel port, combien et quand, sans le contenu. NetFlow, créé par Cisco, a donné la version 9 à base de modèles, dont l’IETF (Internet Engineering Task Force) a tiré IPFIX (IP Flow Information Export, RFC 7011). sFlow procède autrement : il échantillonne un paquet sur N et exporte des compteurs, ce qui le rend léger sur les liens très rapides mais moins exact pour les petits flux. Ces données alimentent les outils de NDR (Network Detection and Response), qui cherchent des comportements anormaux dans le trafic, et les enquêtes après incident (voir Menaces réseau, détection et réponse).
État et comportement, SLA et SLO
Section intitulée « État et comportement, SLA et SLO »Superviser l’état consiste à savoir si un élément est en marche : interface montée, équipement joignable. Superviser le comportement consiste à savoir s’il fonctionne bien : latence, perte, gigue, erreurs, saturation. Un lien peut être « vert » en permanence tout en perdant 3 % des paquets, ce qui suffit à rendre la téléphonie inaudible et les transferts poussifs.
Le SLA (Service Level Agreement) est l’engagement contractuel, assorti de pénalités, entre un fournisseur et son client. Le SLO (Service Level Objective) est l’objectif interne mesurable que l’équipe se fixe, en général plus strict que le SLA pour garder une marge. L’indicateur mesuré s’appelle SLI (Service Level Indicator). Une disponibilité de 99,9 % sur 30 jours autorise 43,2 minutes d’interruption ; 99,99 % n’en autorise plus que 4,3. Les seuils d’alerte se déduisent des SLO : alerter quand la tendance menace l’objectif, pas à chaque frémissement.
Toute alerte a un propriétaire nommé et une action attendue. Une alerte sans propriétaire est lue par tout le monde, donc traitée par personne, avant d’être filtrée dans un dossier de messagerie où elle finira ses jours. Les tableaux de bord suivent la même logique : peu de courbes, chacune répondant à une question d’exploitation.
Gouverner les changements
Section intitulée « Gouverner les changements »Préparer, exécuter, vérifier
Section intitulée « Préparer, exécuter, vérifier »Un changement se prépare avec quatre éléments écrits : la fenêtre d’intervention, choisie selon l’activité et validée par les métiers ; le rollback, procédure de retour arrière testée, avec le critère qui la déclenche ; la validation, liste des tests qui prouvent que le changement a réussi ; la communication, avant, pendant et après, vers les équipes concernées. La gestion de changements classe ensuite les demandes selon leur risque : standard (pré-approuvé, répétitif), normal (revu par un comité), urgent (traité vite, documenté après coup, mais documenté).
Dérive et audit
Section intitulée « Dérive et audit »La dérive de configuration est l’écart qui s’installe entre la configuration attendue, celle du référentiel, et la configuration réelle. Elle naît des corrections faites à la main pendant un incident et jamais reportées. Un audit régulier compare les deux : différentiel des sauvegardes, vérification de règles de conformité (pas de Telnet, SNMPv3 seulement, bannière légale présente, serveurs NTP définis). La documentation des flux, liste des communications autorisées entre zones avec leur justification, complète l’audit : elle permet de savoir si une règle de filtrage sert encore, et à qui.
Exemples et ateliers
Section intitulée « Exemples et ateliers »Fiche équipement. Une fiche utile tient sur une page :
| Champ | Exemple |
|---|---|
| Nom | par1-dist-sw02 |
| Modèle, numéro de série, version logicielle | commutateur 48 ports, SN ABC123, version 17.9 |
| Emplacement | Paris, bâtiment 1, baie B3, unités 20 et 21 |
| Adresse de gestion | 10.250.1.12 (VLAN 250, administration) |
| Liens montants | Te1/1/1 vers par1-core-rt01, Te1/1/2 vers par1-core-rt02 |
| VLAN portés | 10 postes, 20 téléphonie, 30 imprimantes |
| Dépendances | alimente l’étage 2 (60 postes, 15 téléphones) |
| Contrat de maintenance | jusqu’au 31/12/2027, remplacement sous 4 heures |
| Propriétaire | équipe réseau, astreinte 01 23 45 67 89 |
Cinq métriques vitales pour un lien WAN (Wide Area Network, réseau étendu) : le taux d’utilisation au 95e centile, plus parlant que la moyenne qui lisse les pointes ; la latence aller-retour, comparée à la valeur nominale du lien ; la perte de paquets, qu’il faut maintenir sous 1 % et idéalement bien en dessous pour la voix ; la gigue, variation de latence qui dégrade les flux temps réel ; les erreurs d’interface (CRC, Cyclic Redundancy Check), signe d’un problème physique. La disponibilité se calcule à partir de ces mesures plutôt que du seul état de l’interface. Les liens entre ces mesures et la qualité de service sont détaillés dans Performance, QoS et capacité.
Procédure de changement VLAN. Objectif : créer le VLAN 40 pour des caméras sur par1-dist-sw02. Préparation : vérifier que le numéro 40 est libre dans l’inventaire, réserver le préfixe, rédiger les règles de filtrage associées, sauvegarder la configuration. Exécution, en fenêtre validée : créer le VLAN, l’ajouter aux liens montants autorisés, configurer les ports d’accès, appliquer les règles. Validation : une caméra obtient une adresse, atteint l’enregistreur, n’atteint pas le VLAN des postes. Rollback : restaurer la configuration sauvegardée si un VLAN existant est perturbé. Clôture : mettre à jour l’inventaire et la documentation des flux. Le détail technique des VLAN figure dans VLAN, trunks et boucles.
Pièges classiques
Section intitulée « Pièges classiques »Ne superviser que « up ou down » donne un tableau de bord tout vert pendant que les utilisateurs se plaignent de lenteurs. Modifier sans sauvegarde transforme une erreur de frappe en reconstruction de mémoire. Alerter sans propriétaire produit du bruit, puis de l’indifférence, puis la panne qu’une alerte avait pourtant signalée trois jours plus tôt.
À ne pas confondre
Section intitulée « À ne pas confondre »La supervision vérifie des conditions connues à l’avance (ce lien est-il saturé ?) ; l’observabilité désigne la capacité à répondre à des questions qu’on n’avait pas prévues, à partir de données suffisamment riches (voir Captures, observabilité et diagnostic). Le SLA engage contractuellement envers un client ; le SLO est l’objectif interne qui sert à le tenir. Un log est un événement daté, une métrique une valeur numérique mesurée dans le temps, une trace le parcours d’une requête à travers plusieurs composants : trois formes de données qui se complètent et ne se remplacent pas.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans inventaire ni documentation des flux, un équipement ajouté par un tiers, une règle de filtrage oubliée ou une interface d’administration exposée n’apparaissent sur aucune carte, et ce qui ne figure sur aucune carte n’est défendu par personne. Sans résumés de flux ni journaux conservés, une exfiltration lente passe pour du trafic ordinaire, et l’enquête qui suit n’a rien à relire. Sans gestion des changements, une modification urgente faite à la main s’installe durablement : la configuration réelle s’éloigne de celle qu’on croit appliquer, et le prochain incident se diagnostique sur une documentation fausse, ce qui a le mérite d’occuper l’équipe longtemps.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Exploiter un réseau commence par savoir ce qu’il contient. L’inventaire recense chaque équipement, ses liens, les zones auxquelles il appartient et ce qui dépend de lui, avec des noms cohérents. La configuration de chaque équipement est sauvegardée avec son historique, pour savoir qui a changé quoi et revenir à un état connu. Vient ensuite la surveillance. Les équipements publient des mesures, comme le débit ou le taux d’erreurs, grâce à un protocole de gestion interrogé à intervalles réguliers. Ils envoient aussi des journaux, qui décrivent des événements, et des résumés de flux, qui disent qui a parlé à qui, combien et quand. Savoir qu’un lien est allumé ne suffit pas : il faut mesurer son comportement, par exemple sa lenteur ou ses pertes. Ces mesures sont comparées à des seuils tirés des engagements de qualité de service pris envers les utilisateurs, et chaque alerte doit avoir un responsable désigné, sinon personne ne la traite. Enfin, chaque changement se prépare : une fenêtre d’intervention, une procédure pour revenir en arrière, une vérification après coup et une information des personnes concernées. Des contrôles réguliers comparent la configuration réelle à la configuration attendue, pour détecter les écarts qui s’accumulent.
À lire aussi
- MPLS, GMPLS, SD-WAN et overlays opérateursExpliquer les architectures WAN et opérateurs au-delà d’IP routé : labels, circuits virtuels, transport optique, overlays, SD-WAN et technologies héritées.
- Couches, normes et vocabulaire de paquetsConstruire le vocabulaire nécessaire pour lire une communication réseau : couche, protocole, encapsulation, trame, paquet, segment, datagramme, message et plans réseau.
- Inventorier les objets IoT oubliés sur le réseauMéthode d’identification, de confinement et d’exploitation des objets connectés non inventoriés.
- Décision de chemin, routes statiques et routage systèmeComprendre comment un système ou routeur choisit le prochain saut, comment écrire des routes statiques et comment éviter asymétries et contournements.
Pages voisines
La citent
- Comprendre pourquoi les systèmes communiquent
- Couches, normes et vocabulaire de paquets
- Décision de chemin, routes statiques et routage système
- Routage interne, redistribution et stabilité
- Virtualisation réseau, NFV et data planes ouverts
- Continuité, sauvegardes, PRA/PCA et haute disponibilité
- La fatigue d'alerte
Gestion réseau, supervision et référentiels d’exploitation
Elle cite
: les deux pages se citent l’une l’autre.