SNMP, syslog et NetFlow

Définition

Trois services complètent la supervision d'un réseau. SNMP (Simple Network Management Protocol) interroge des compteurs et variables exposés par un agent MIB. syslog envoie les messages d'événements d'un équipement vers un collecteur central. NetFlow exporte un résumé de chaque flux traversant l'interface (source, destination, ports, volume), pour analyser le trafic plutôt que l'état de la machine.

Contexte

Le blueprint 200-301 couvre SNMP en topic 4.4 (expliquer la fonction de SNMP dans les opérations réseau) et syslog en 4.5 (décrire l'usage de syslog, facilities et niveaux). NetFlow tombe sous le même radar : rôle et cas d'usage, pas configuration approfondie. Les faits à retenir : ports et versions SNMP, les huit niveaux de sévérité syslog, la notion de facility, et ce que NetFlow ajoute par rapport à SNMP.

Détails techniques

SNMP

SNMP s'appuie sur une MIB (Management Information Base) : un arbre d'OID (ex. 1.3.6.1.2.1.2.2.1.10 = ifInOctets). Une station de gestion (NMS) lit des OID (GET), avance dans l'arbre (GETNEXT/GETBULK), et reçoit sans interroger les TRAP que l'agent émet sur événement.

Version	Authentification	Confidentialité	Port
v1	Community string en clair	Aucune	UDP 161 (poll), 162 (trap)
v2c	Community string en clair	Aucune	idem, ajoute GETBULK et les contre-types
v3	User + auth HMAC-MD5 ou SHA	Encryption DES/AES (priv)	UDP 161

v1 et v2c partagent la même faiblesse : la community est un mot de passe transporté en clair. v3 introduit un modèle USM avec trois niveaux : noauthNoPriv, authNoPriv, authPriv. Configuration typique :

R1(config)# snmp-server community READONLY ro 10
R1(config)# snmp-server community WRITEOK rw 20
R1(config)# snmp-server host 10.10.10.5 version 3 priv monitoring
R1(config)# snmp-server enable traps syslog

ro autorise la lecture, rw l'écriture (donc la modification de la config à distance) : à ne jamais exposer sans ACL. Le 10/20 final est un numéro d'ACL qui restreint les sources. Sur v2c, le mot-clé view et les restricted complètent le verrouillage. Le port 162 n'est pas "le port de l'agent trap" : l'agent envoie ses traps de 161 vers 162 du collecteur, et l'agent écoute les requêtes GET sur 161.

syslog

Un message syslog voyage en UDP 514 vers le collecteur. Il porte une facility (origine du message : LOCAL0 à LOCAL7 pour les équipements réseau, mais aussi MAIL, DAEMON, AUTH...) et une sévérité parmi huit :

Niveau	Nom	Exemple IOS
0	Emergencies	système mourant
1	Alerts	panne imminente
2	Critical	erreur critique
3	Errors	message d'erreur
4	Warnings	warnings (ex. %LINK-3-UPDOWN est plus grave)
5	Notifications	normal mais significatif (login)
6	Informational	infos périodiques
7	Debugging	debug, activé temporairement

Configuration IOS :

R1(config)# logging host 10.10.10.5
R1(config)# logging trap warnings
R1(config)# logging buffered 16384
R1(config)# service timestamps log datetime msec

logging trap warnings envoie vers le serveur tout niveau de 0 à 4 inclus (plus c'est critique, plus le numéro est bas). Sans filtre, les équipements inondent un collecteur. logging buffered garde les messages dans la RAM locale (show logging). Cote corrélation, une horloge synchro par NTP et des timestamps en millisecondes rendent la lecture d'un incident multi-équipements lisible.

NetFlow

NetFlow crée un "flux" par combinaison clé (souvent source IP, destination IP, source port, dest port, protocole, ToS, interface). À la fin du flux, au timeout (30 s actif, 15 min inactif par défaut en v5/v9), le routeur exporte l'enregistrement vers un collecteur, classiquement en UDP 2055 ou 9996, ou TCP/SCTP pour IPFIX.

R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip flow ingress
R1(config)# ip flow-export destination 10.10.10.5 2055
R1(config)# ip flow-export version 9

SNMP dit "l'interface a transporté 3,2 Gb"; NetFlow dit "dont 2,1 Gb vers YouTube, 600 Mo vers la sauvegarde de 02h00". Les cas d'usage : capacity planning, détection d'anomalie (vers/vers un hôte isolé), facturation, investigation de compromission. v9 ajoute les templates extensibles, IPFIX est la version standardisée (RFC 7011).

Exemple concret

Un switch 9200 est en panne d'internet un matin. En SNMP, le NMS affiche ifInOctets plat depuis 06h04 et une trap LINK up/down sur Gi1/0/48 (uplink). En syslog, le serveur central corrèle les lignes %LINEPROTO-5-UPDOWN de 14 ports d'accès au même moment, timestampé à la milliseconde près grâce à NTP : l'uplink a coupé, pas les accès. En NetFlow, le collecteur montre qu'avant la coupure l'uplink tournait à 940 Mbps sur 1 Gbps, à 87 % vers trois destinations TCP 443. L'incident est donc une saturation chronique plus une coupure sèche, pas un problème de spanning-tree.

Pièges fréquents

1. Croire que SNMP v2c est sécurisé parce que la community est difficile à deviner : elle circule en clair.
2. Fuite du rw sans ACL : n'importe qui peut modifier une config via SNMP write.
3. logging trap debugging permanent sur un routeur occupé : 1 Mbps de syslog UDP, paquets perdus, collecteur saturé.
4. Confondre ce que NetFlow ne voit pas : un trafic chiffré reste un tuple, pas un contenu ; NetFlow ne remplace pas un IDS.