Autres protocoles de supervision réseau

a. Fonctions initiales des logs

Lorsqu’un événement inattendu, comme une panne, intervient sur un équipement réseau, l’administrateur commence par analyser des fichiers journaux : « les logs ». Ces derniers sont générés par l’équipement en question et recensent l’ensemble des événements survenus et ceci, en temps réel.

Un événement se caractérise par exemple par un changement d’état d’une interface, un incident de type port-security sur un commutateur, un seuil d’utilisation de ressources matérielles élevé, une connexion à l’interface d’administration de l’équipement ou toute autre activité intervenant dans la « vie » de l’actif en question. Tout processus exécuté sur l’équipement a été développé dans le souci de garder des traces ou tout au moins d’afficher sur la console d’administration son état.

Concrètement, les logs correspondent à des messages textes qui sont en général stockés en mémoire vive ou morte, permettant à l’administrateur de connaître l’activité de l’actif en temps réel, mais également sur une période de temps donnée puisque ces messages sont horodatés.

D’où l’importance de configurer d’une part l’heure et la date sur un équipement, mais surtout d’autre part de faire en sorte qu’elles soient synchronisées avec une référence unique, utilisée par tous les autres actifs du réseau. Un protocole a même vu le jour pour cela, il s’agit du protocole NTP (Network Time Protocol).

Le mécanisme de logs entre totalement dans les objectifs de la supervision, on peut faire un parallèle avec l’utilisation de SNMP en mode trapping. En effet, c’est l’équipement en lui-même qui génère et fournit les événements, aucun processus extérieur n’en est à l’origine. Pour l’administrateur, les logs permettent...

a. Origines du protocole

Le protocole NetFlow a été conçu par Cisco System à partir de 1996 et a très vite été intégré dans les différentes gammes de routeurs commercialisés. Le principe de NetFlow est en fait d’analyser le trafic réseau qui entre par une interface et qui ressort par une interface de sortie. À partir de cette analyse, le trafic est rassemblé en ce que l’on appelle des flux. Cette récolte de flux permet à l’administrateur de dresser des statistiques sur les débits des interfaces en fonction de plusieurs critères comme l’adresse IP (source et/ou destination), les ports utilisés ainsi que les classes de QOS déclenchées.

NetFlow et ses variantes sont utilisés particulièrement par les opérateurs télécoms pour d’une part monitorer leur réseau, et d’autre part facturer leurs clients - dans le cadre d’une facturation à l’usage - c’est-à-dire au débit consommé. D’ailleurs, certains logiciels interprétant les flux récoltés sont capables de les chiffrer financièrement.

À la base, NetFlow a été normalisé dans la RFC 3954, qui faisait plus office de mémo à usage public que de véritable norme. En 2009, Cisco publie la version 9 de NetFlow qui est encore relativement utilisée puisqu’elle est compatible avec les protocoles IPv6, MPLS et BGP. Dans la même période, le protocole IPFIX (IP Flow Information Export) apparaît à l’IETF sous la RFC 5101 reprenant tous les concepts de NetFlow et les formalisant ainsi de manière officielle. 

En 2013, IPFIX (qui est même considéré comme la version 10 de NetFlow) est amélioré dans la nouvelle RFC 7012. Il se présente alors comme le standard « officiel » à implémenter par les constructeurs pour le formatage, la gestion et la collecte des flux. C’est une amélioration de NetFlow 9 permettant une plus grande flexibilité dans la définition des flux, c’est-à-dire la possibilité de rajouter des variables...