La surveillance des flux réseau est un outil essentiel pour de nombreux administrateurs réseau. La surveillance des flux nous permet de collecter et d’enregistrer tout le trafic IP entrant et sortant d’un périphérique réseau. Les données de flux réseau peuvent fournir plus de détails que d’autres méthodes de surveillance courantes, telles que l’affichage de l’utilisation de l’interface ou l’interrogation basée sur SNMP. Le protocole SNMP peut être bien pratique, mais il ne rapporte que la quantité totale de trafic et manque d’autres informations sur la source et la destination de la transmission. SNMP est un outil avec de nombreuses utilisations, mais la surveillance des flux est explicitement conçue pour surveiller le trafic réseau.
La surveillance des flux nous permet d’approfondir les données du trafic IP et peut inclure d’autres détails ainsi comme: la source, la destination, l’application et d’autres attributs. Cela nous donne une meilleure visibilité sur les causes de la congestion, les applications qui utilisent le plus de ressources, les modèles de trafic inhabituels ou même la possibilité de fournir une facturation basée sur l’utilisation.
Généralement, un flux réseau peut être défini comme une combinaison unique d’adresses IP source et de destination, de port source et de destination et de protocole. Il y a de différentes définitions de flux selon différentes normes, donc on a plusieurs options de choisir sur la façon de définir le flux d’une réseau. Chaque fois qu’un périphérique réseau compatible NetFlow détecte un nouveau flux, il commence à compter les paquets et les octets, et regroupe ces informations pour la collecte, le traitement et l’analyse.
Il existe de nombreux protocoles disponibles pour la surveillance des flux, mais l’un des plus connus est évidemment NetFlow. Étant développée premièrement par Cisco, NetFlow est devenu la base de nombreuses normes de l’industrie. Et depuis lors, on a eu de nombreuses révisions et d’autres normes construites sur NetFlow.
La mise en œuvre de NetFlow nécessite trois composants principaux:
Il existe de nombreuses versions de NetFlow, mais les plus pertinentes à connaître sont la 5ème et la 9ème, car ce sont les versions les plus couramment utilisées.
NetFlow a été initialement développé en tant que technologie de commutation de paquets pour les routeurs Cisco, implémentée dans IOS 11 en 1996. Il a été conçu comme une amélioration par rapport à Cisco Fast Switching. Cependant, Cisco Express Forwarding s’est avéré d’être beaucoup mieux adapté à la commutation de paquets, ainsi que NetFlow v1 est devenu la base des protocoles de surveillance de flux qu’on a aujourd’hui. La première version était limitée à IPv4, sans masques de réseau IP ni numéros de système autonome (ASN), devenant bientôt obsolète. Les versions 2 à 4 ont été maintenues en tant que versions internes de Cisco, qui n’ont jamais été publiées.
NetFlow v5 est la version la plus ancienne qui est encore couramment utilisée, étant même la plus utilisée de toutes les versions. NetFlow v5 a une disposition fixe des champs qui peuvent être utilisés, ne fonctionne qu’avec IPv4, et uniquement avec les flux de trafic entrants. NetFlow v5 ne peut pas modifier les attributs qu’il suit. Il ne peut pas non plus exporter les enregistrements basés sur les flux L2 et il lui manque aussi certains attributs L2, comme les étiquettes MPLS.
Le format d’enregistrement de flux NetFlow v5 est le suivant:
– Adresse IP source et destination
– Adresse IP d’un routeur de saut suivant
– Index SNMP de l’interface d’entrée et de sortie
– Nombre de paquets dans le flux
– Nombre d’octets Layer 3 dans les paquets du flux
– System Uptime au démarrage, et l’heure à laquelle le dernier paquet du flux a été reçu
– Numéro de port source et de destination TCP/UDP
– Le cumulatif “OR” de “TCP flags”
– Type de protocole IP (par exemple, TCP = 6 ; UDP = 17)
– Type de service IP (ToS)
– Numéro de système autonome (ASN) de la source et de la destination, soit d’origine, soit de peer
– Bits de la masque de préfixe de l’adresse source et de destination
NetFlow v6 est une autre version obsolète, pendant que la v7 est presque identique à la v5. Dans la version 7, un champ de routeur source a été ajouté, qui est principalement utilisé dans les anciens commutateurs Cisco Catalyst. NetFlow v8 est une autre version peu courante, qui permet l’agrégation de plusieurs formulaires, mais uniquement pour les informations déjà présentes dans les enregistrements de la version 5.
Plutôt qu’avoir un ensemble fixe de champs qui doivent être utilisés, comme la v5, NetFlow v9 est basé sur des modèles. Donc, on peut utiliser de différents modèles qui suivent différents attributs, selon le type de données qu’on a besoin de capturer.
Cela permet à NetFlow v9 d’être beaucoup plus flexible que les autres versions, et c’est pourquoi il est souvent appelé comme “Flexible NetFlow”. La version 9 peut être utilisée aux mêmes fins que la version 5, mais elle peut également être utilisée pour les flux de sortie, IPv6, MPLS et IPv4 avec le prochain saut BGP. De plus, le standard actuel de l’industrie, IPFIX, a été également basé sur Netflow v9. Ensuite, la v10 n’est pas une version de NetFlow mais est plutôt utilisée pour identifier IPFIX.
Vu qu’IPFIX est basé sur NetFlow v9, il utilise une approche similaire basée sur des modèles. IPFIX est une norme IETF, mieux décrite dans les RFC [7011] et [7012]. Même si IPFIX est fortement basé sur NetFlow, la v10 n’a pourtant rien à voir avec NetFlow. NetFlow et ses variantes sont encore largement utilisés, mais IPFIX est désormais un standard ouvert de l’industrie.
sFlow, ou NetFlow échantillonné, est une autre version populaire de la surveillance des flux réseau. Vu que NetFlow assure le suivi de chaque flux dans la réseau, cela peut avoir un impact négatif sur la performance pendant des périodes de forte utilisation. Une option courante pour éviter cela consiste à échantillonner uniquement une partie du trafic réseau. Alors que l’inconvénient dans ce scénario est que toutes les données ne sont pas capturées, cela peut toujours limiter l’impact sur la performance. Une option courante pour éviter cela est d’échantillonner uniquement une partie du trafic réseau.
sFlow n’a aucune notion de flux ou d’agrégation de paquets mais plutôt permet d’exporter des fragments de données de paquets et des compteurs d’interface, ce qui est également possible avec les dernières versions d’IPFIX. Alors que les protocoles d’exportation de flux typiques tels que NetFlow utilisent un taux d’échantillonnage de 1:1, cela n’est généralement pas possible avec sFlow. sFlow est conçu à capturer un échantillon aléatoire de trafic réseau, ce qui le rend plus évolutif pour la surveillance à l’échelle du réseau. Si on souhaite capturer toutes les données sur quelques interfaces clés, NetFlow est la meilleure option, alors que sFlow peut être mieux adapté pour capturer un échantillon de tout le trafic sur toutes les interfaces.
Le choix du bon protocole et de la bonne version dépend de ce que vos périphériques réseau prennent en charge et de ce que vous essayez d’accomplir. Par exemple, si vous n’avez besoin que d’IPv4 et d’autres attributs disponibles dans NetFlow v5, cela reste une option viable. NetFlow v5 est toujours largement pris en charge sur de nombreuses générations d’appareils de nombreux fournisseurs d’équipement. Mais si vous avez besoin de flexibilité, de prise en charge MPLS, saut prochain BGP ou IPv6, alors NetFlow v9 et IPFIX sont probablement de meilleures options.
Quel que soit votre choix en termes de protocole ou de version, afin de l’adapter à vos besoins il faudra toujours faire beaucoup de tests et d’ajustements. Mais une fois correctement déployée, la surveillance de votre flux réseau passera à un niveau supérieur, ce que vous offrira des informations inestimables sur votre réseau.
Le futur de la surveillance des flux réseau a beaucoup de potentiel. Dans le passé, NetFlow et IPFIX pouvaient rapidement dépasser la quantité de ressources disponibles sur un périphérique réseau, créant un goulot d’étranglement ou rencontrant des limitations lorsque l’utilisation était bien élevée. Au fur et à mesure que les périphériques réseau deviennent plus performants et que de plus en plus de périphériques sont conçus prenant en compte la surveillance des flux, on aura de plus en plus d’avantages, pendant que les limitations seront moins problématiques. Quel que soit votre choix en matière de protocole – Netflow, JFlow, sFlow, IPFIX ou NetStream, le Noction Flow Analyzer sera toujours pleinement en charge de vous aider dans la surveillance de flux réseau.
Accéder à la version anglaise de cet article – The Evolution of Network Flow Monitoring, from NetFlow to IPFIX