Blog

Diagnostique réseau : la visibilité bien au delà du NetFlow

En 2013, Cisco écrivait que « Gartner a déclaré que l’analyse des flux doit être utilisé 80 % du temps et que la capture des paquets avec des sondes doit être effectuée 20 % du temps » (référence).

Nous pensons qu’ils ont eu tort !

Dans leur esprit, vous pouvez choisir entre :

  • Analyse de paquets : analyse ciblée et axée sur le diagnostic
  • NetFlow : visibilité grand-angle et axée sur le volume de données transférées
Netflow vs analyse de paquets

Nous ne pouvons qu’être en désaccord avec cette affirmation qui, selon nous, repose sur deux fausses hypothèses :

  • NetFlow n’est pas cher, est facile à déployer et fournit les données dont les équipes réseaux ont besoin.
  • L’analyse de paquets est trop onéreuse et ne permet pas d’adresser de très grands volumes de données.

Le volume de trafic est l’information recherchée par les équipes réseaux et NetFlow est la bonne façon de le faire : Pourquoi nous pensons que cela est faux?

Les volumétries de trafic sont importantes pour la gestion des capacités, pour identifier des congestions massives générées par les menaces virales … Mais répondent-elles à tous les défis rencontrés par les équipes réseaux ?

De nos jours, les équipes réseaux doivent gérer des cas plus complexes et délicats qui n’ont que rarement la forme d’une occupation de toute la bande passante ou de congestions massives.

Les équipes réseau doivent gérer les plaintes émises par les utilisateurs en matière de performance. La congestion est une cause possible, mais il y a beaucoup d’autres causes au niveau du réseau et à d’autres niveaux.

Qu’est ce que l’analyse à base de flow?

Un Flow est une donnée statique, avec un ensemble commun d’identifiants : un flow est défini par le trafic qui a la même adresse IP source, IP de destination, le port source et le port de destination.  Si l’une de ces variables change, un nouveau Flow est donc défini. NetFlow, sFlow et IPFIX fournissent des moyens de recueillir cette information sur le trafic traversant le réseau.

Les équipements tels que les routeurs ou les commutateurs peuvent générer des données Flow, sur la base du trafic qu’ils gèrent. Les données Flow sont envoyées vers un collecteur de Flows, qui peut créer des rapports et des statistiques sur la base des données Flow.

A titre d’exemple, avec NetFlow, vous pouvez suivre les données suivantes :

  • L’Interface et l’adresse source
  • La source et l’adresse IP de destination,
  • Protocole de couche 4 (ICMP, TCP, UDP, …),
  • Numéros des ports source et destination,
  • Type de service
  • Volume de trafic entrant et sortant

Quels sont les prérequis?

La première condition se trouve au niveau du dispositif source : il doit supporter NetFlow et avoir suffisamment de ressources systèmes pour générer les données. Selon les options d’échantillonnage et d’agrégation utilisées, la production de données NetFlow peut nécessiter des ressources importantes.

La deuxième condition est la bande passante nécessaire pour transmettre les données à partir des sources au collecteur : NetFlow nécessite habituellement de 1,5% à 4 % du trafic analysé pour centraliser les données sur le collecteur.

 Quelles sont les limites dans l’environnement actuel?

Eh bien NetFlow a un grand mérite : il existe…, et il fournit quelques données utiles, mais…

  • IPv6 n’est pas reporté (signalé) par le plus populaire NetFlow V5 (uniquement l’IPv4),
  • De plus, l’implémentation intégrera des options d’échantillonnage,
  • Ses données ne concernent que le volume de trafic.

La plupart des équipes d’infrastructure sont à la recherche de la cause fondamentale d’une dégradation des performances, pas seulement pour montrer qu’ils ont prévu suffisamment de bande passante. Dans ce cas, NetFlow n’est tout simplement pas en mesure de fournir une réponse : ils n’ont pas d’informations sur le comportement TCP, aucune information sur les temps de réponse, aucune donnée sur les couches d’applications et sur la performance des transactions … Avec NetFlow, vous éliminerez juste une cause possible, mais vous n’accélérerez pas le temps de résolution du problème.

L’analyse de paquet est trop cher et n’est pas implémentable à très haut débit pourquoi pensons-nous que c’est faux?

Pourquoi Gartner vous recommanderait d’utiliser l’analyse de paquets pour 20 % du trafic ? Nous ne pouvons penser à deux raisons :

  • Il y a trop de trafic,
  • Cela coûte trop d’effort et d’investissement pour mettre en œuvre une visibilité grand-angle à travers l’analyse de paquets

Ces affirmations sont basées sur des technologies anciennes comme les appliances d’enregistrement réseau ou de capture du trafic (exemple : Gigastor, Infinicore, Omnipliance) et des analyseurs logiciels (tels que Wireshark ou Observer, etc…).

Notre solution change la donne sur le marché. Nous offrons des fonctionnalités absolument uniques en termes de profondeur, de supervision et de diagnostic des performances applicatives en grand-angle, à un coût abordable.

Voici ce que SkyLIGHT PVX offre :

  • Intégration des fonctions normalement implémentées dans des NPB (Network Packet Prober ou switch de matrice) coûteux (déduplication et filtrage).
  • Un modèle de licence révolutionnaire où le déploiement de nombreux points de capture est vraiment abordable.
  • Les Appliances virtuelles pour le déploiement à distance à l’échelle mondiale.
  • Une solution unique pour les performances du réseau et des applications en réduisant la complexité et TCO.
  • Une solution qui s’adapte au trafic réseau et à la volumétrie des plus grandes entreprises !
  • Oh … j’oublié de mentionner : SkyLIGHT PVX recueille également des données Netflow !

Voici pourquoi nos clients n’ont pas à choisir entre le troubleshooting et la visibilité grand angle !