SNMP vs syslog vs NetFlow : ce que chacun apprend en supervision, collecte, format, protocoles
Exploiter un réseau, c’est surveiller l’état des équipements et du trafic, repérer tôt les problèmes et en rechercher les causes. SNMP, syslog et NetFlow collectent tous des informations auprès des équipements, mais ils n’apprennent pas la même chose. Avec SNMP, un système de gestion (le gestionnaire) interroge les équipements (agents) sur des valeurs comme le trafic des interfaces et l’utilisation du CPU, ce qui indique « combien ». Avec syslog, les équipements envoient des événements, comme la chute d’une liaison, des connexions ou des modifications de configuration, sous forme de messages texte à un serveur de journalisation, ce qui indique « ce qui s’est passé et quand ». NetFlow (et IPFIX, la norme qui en est issue) résume le trafic par groupe de paquets partageant la même source, la même destination, etc. (un flux) et exporte ces résumés, ce qui indique « qui a communiqué avec qui, et combien ». En pratique, les trois sont utilisés ensemble.
| Critère | SNMP | syslog | NetFlow (IPFIX) |
|---|---|---|---|
| Ce qu’il apprend | L’état et les quantités des équipements : trafic et nombre d’erreurs des interfaces, utilisation du CPU et de la mémoire, état des liaisons | Les événements : chutes de liaison, connexions réussies et échouées, modifications de configuration, erreurs | La répartition du trafic : quelles paires source-destination, avec quel protocole et quels ports, ont envoyé combien |
| Mode de collecte | Le gestionnaire interroge à intervalle fixe (scrutation, polling) ; les équipements peuvent aussi signaler les problèmes par des notifications (traps) | L’équipement envoie un message au serveur lorsqu’un événement se produit | L’équipement agrège les flux et les exporte vers un serveur de collecte (collecteur) à la fin d’un flux ou à intervalles fixes |
| Format des données | Valeurs définies dans des MIB (compteurs et états), désignées par des identifiants d’objet (OID) | Gravité (0 à 7), type de source (facility), horodatage et message texte | Enregistrements par flux : adresses, numéros de port, protocole, nombres de paquets et d’octets, heures de début et de fin, etc. ; les champs sont définis par des modèles (templates) |
| Granularité temporelle | Une moyenne sur chaque intervalle de scrutation (par exemple 5 minutes) | Par événement, reçu presque immédiatement | Par flux ; les flux de longue durée sont découpés et exportés à intervalles fixes |
| Ce qu’il ne peut pas indiquer | À qui appartient le trafic | Le volume de trafic | Le contenu des paquets (données) ; ni les valeurs des équipements comme l’utilisation du CPU |
| Charge sur les équipements et les liaisons | Faible | Faible, mais les messages peuvent affluer lors d’une panne | Plus élevée ; sur les liaisons rapides, on utilise parfois l’échantillonnage, qui n’examine qu’une partie des paquets |
| Normes et numéros de port | SNMPv3 : RFC 3411 à 3418 ; port UDP 161 (requêtes) et 162 (traps) | RFC 5424 ; port UDP 514, ou 6514 avec TLS | NetFlow v9 est décrit dans la RFC 3954 (une RFC informative) ; l’IPFIX normalisé est la RFC 7011, port 4739 |
| Sécurité | En v1 et v2c, la chaîne de communauté circule en clair ; la v3 ajoute authentification et chiffrement | Sur UDP, il n’y a ni chiffrement ni confirmation de livraison ; TLS peut le protéger | NetFlow v9 n’a pas de protection intégrée ; IPFIX peut être protégé par TLS ou DTLS |
| Usages principaux | Graphiques de trafic, suivi du taux d’utilisation des liaisons, détection des pannes d’équipements | Recherche des causes de pannes, traçabilité de qui a fait quoi, surveillance de la sécurité (collecte dans un SIEM) | Repérage des hôtes et applications gros consommateurs de bande passante, détection de trafic inhabituel, planification de l’augmentation des liaisons |
Les valeurs indiquées sont des ordres de grandeur typiques et varient selon la génération de procédé et le produit.