Protocole d'exportation Flow de votre père (partie 1)

Vous connaissez peut-être NetFlow, IPFIX et d'autres protocoles similaires comme J-Flow et sFlow. Ces protocoles fournissent des informations utiles sur la composition du trafic et les communautés d'intérêt. Cependant, ces protocoles ne contiennent pas les détails de la couche application que certains administrateurs souhaitent. Les administrateurs informatiques ont besoin d'une plus grande visibilité au niveau des applications pour pouvoir effectuer une gestion des performances des applications (APM) et résoudre les problèmes de couche application. Les protocoles basés sur les flux actuels manquent de détails sur la couche application qui sont nécessaires pour effectuer une analyse plus approfondie et un dépannage.

Leçon d'histoire NetFlow:

Dans les années 1990, NetFlow version 5 a commencé comme un protocole propriétaire de Cisco Systems pour capturer et envoyer des informations sur les flux de trafic réseau vers un point de collecte. NetFlow peut être activé sur les périphériques réseau qui utilisent Cisco Press Forwarding (CEF). Le périphérique compatible NetFlow capture des informations sur les flux de réseau IP traversant l'interface et envoie les données sur les flux dans les paquets UDP à un système collecteur. Le collecteur NetFlow est généralement un ordinateur qui exécute le logiciel de collecte et d'analyse. NetFlow est devenu très populaire au cours de la dernière décennie et maintenant il existe une multitude d'entreprises qui prennent en charge NetFlow sur leurs appareils et de nombreuses entreprises qui font des utilitaires de collecte et d'analyse NetFlow.

En raison de la surcharge de traitement supplémentaire requise pour prendre en charge NetFlow, il n'était pas adapté à une utilisation sur de nombreux périphériques réseau. Cisco a développé Sampled NetFlow, Deterministic Netflow et Random Sampled NetFlow pour réduire les frais généraux liés à l'exécution de NetFlow sur des appareils occupés, tout en offrant une certaine visibilité sur le trafic. Plus tard, Cisco a développé Flexible NetFlow qui permet d'envoyer la couche 2, IPv6 et d'autres types de données à un collecteur.

NetFlow et IPFIX:

Alors que NetFlow commençait à gagner en popularité, NetFlow version 9 a ajouté des détails de flux pour les réseaux MPLS et les flux de données IPv6. NetFlow a commencé comme un protocole propriétaire de Cisco, mais a été documenté dans un RFC 3954 d'information IETF en 2004. L'IETF a commencé à travailler sur Internet Protocol Flow Information eXport (IPFIX) en 2004. Les exigences IPFIX ont d'abord été documentées dans le RFC 3917. En fait, NetFlow v9 était la base de la norme IETF IPFIX. Le fait est qu'IPFIX et NetFlow v9 partagent de nombreux types de champs. NetFlow et IPFIX ont été réunis dans NetFlow v10 et standardisés avec RFC 5101, RFC 5102, RFC 5103 et RFC 5655. Le modèle d'information d'IPFIX a été mis à jour avec RFC 6313. IPFIX a été mis à jour maintenant dans les RFC IETF 7011, 7012, 7013, 7014 et 7015. De nombreux produits de fournisseurs prennent désormais en charge IPFIX.

Autres protocoles d'exportation de flux:

Étant donné que NetFlow était initialement considéré comme une méthode de flux propriétaire de Cisco, d'autres fournisseurs voulaient développer leurs propres protocoles ou collaborer sur des protocoles de flux plus «ouverts» pour travailler sur leur propre matériel. Il existe de nombreux autres protocoles d'analyse du trafic réseau basés sur les flux et certains ne sont utilisés que par un seul fournisseur.

J-Flow v5 / v8 / v9 est un protocole de surveillance basé sur le flux qui a été développé par Juniper Networks. Il fonctionne sur leurs appareils JUNOS et J-Flow est interopérable avec les collecteurs compatibles NetFlow.

sFlow est un autre protocole d'échantillonnage de paquets qui envoie des informations sur les flux à un collecteur. sFlow est pris en charge par une organisation du secteur qui aide à favoriser l'adoption du protocole. La différence entre sFlow et d'autres protocoles d'exportation de flux est qu'il peut effectuer un échantillonnage de paquets au lieu d'une simple exportation basée sur le flux. L'échantillonnage de paquets peut améliorer les performances de la technique en réduisant la charge de travail sur le périphérique réseau. sFlow version 5 a un large support fournisseur.

NetStream est un autre protocole d'exportation basé sur les flux utilisé par 3Com / HP / Huawei.

Ericsson a également son propre protocole RFlow.

Les systèmes OpenBSD peuvent utiliser pflow (flux pseudo-périphérique) comme méthode d'exportation des données de flux. pFlow est compatible avec NetFlow v5 / v9 et v10 (IPFIX).

Limitations des protocoles de flux réseau:

La limitation de tous les protocoles d'analyse de réseau basés sur le flux est qu'ils manquent de granularité dans le trafic. Rien ne fournit plus de détails sur le trafic que le décodage de protocole réel avec un analyseur de protocole. Cependant, la capture de paquets bruts peut être un fardeau de performances sur un périphérique réseau et le stockage de toutes ces informations peut être coûteux. Les captures de paquets peuvent être une option viable pour le dépannage et les tests de courte durée, mais ce n'est pas une solution durable pour la planification de la capacité, les tendances et l'analyse à long terme.

En outre, la possibilité d'effectuer des captures de paquets à de nombreux points via la topologie du réseau n'est généralement pas une option. La mise en place d'un plus grand nombre de prises de connexions SPAN / port miroir peut être impossible. Vous n'avez pas toujours un commutateur de surveillance de paquets à portée de main ou un contrôleur de réseau Cisco eXtensible (XNC) exécutant l'application Monitor Manager avec des commutateurs Nexus 3000 déjà configurés.

Aujourd'hui, nous connaissons également un visage changeant de la topologie informatique. Les systèmes qui étaient auparavant situés dans les propres installations d'une entreprise sont désormais passés à une infrastructure basée sur le cloud. Toutes les applications ne sont pas nichées en toute sécurité dans le centre de données de l'entreprise et accessibles via le WAN interne de l'entreprise. Cela rend l'analyse des protocoles d'applications cloud plus difficile à réaliser. Nous n'avons pas non plus la possibilité d'effectuer des captures de paquets sur des services cloud ou sur des plateformes de virtualisation. En conséquence, de nombreuses applications ne disposent pas de la visibilité dont elles ont besoin pour pouvoir effectuer une analyse détaillée des applications ou résoudre les problèmes.

Sommaire:

Les entreprises ont besoin de meilleures méthodes pour comprendre le trafic applicatif traversant leurs systèmes sur site et cloud. NetFlow et IPFIX sont utiles, mais n'ont pas la granularité d'une capture de protocole complète. Cependant, la capture du trafic brut peut ne pas être une option selon la topologie. De plus en plus de problèmes de performances liés aux applications nécessitaient plus de visibilité pour pouvoir dépanner. Il y a d'autres protocoles qui peuvent être disponibles qui nous donnent la visibilité que nous désirons.

Dans la deuxième partie de cet article, nous couvrirons un nouveau protocole d'analyse de flux qui fournit ces informations utiles.

Scott

Rejoignez les communautés Network World sur Facebook et LinkedIn pour commenter des sujets qui vous tiennent à cœur.