Par exemple, avant la diffusion d’une communication du PDG de la société en live, il est préférable de s’assurer que le réseau supportera le flux vidéo sans problème !

D’autres applications critiques peuvent aussi demander cette validation : les flux d’information fournies aux équipes de Trading dans une banque, par exemple.

Pour préparer un réseau au transport d’un flux Vidéo sur IP en temps réel, on doit s’assurer que ce dernier présente les caractéristiques requises en termes de latence, de délai, de perte de paquets et de gigue.

Mais au-delà de ces caractéristiques, on voudra s’assurer de la Qualité d’Expérience des utilisateurs.

Est ce que la vidéo est correctement transportée sans problème d’écran noir, de période de gel d’image ou autre problème de transport de l’image?

Pour répondre simplement à tous ces points, J3Tel propose de mettre en œuvre les éléments suivants :

Tout d’abord, on va positionner, au point de transmission du flux vidéo, une sonde Ineoquest G1T (jusqu’à 2 Gbps de trafic) ou Ineoquest G10 (jusqu’à 20 Gbps de trafic) permettant de générer du trafic vidéo. On va, soit générer du trafic synthétique, soit répliquer dans le réseau une source vidéo disponible.

Sonde Singulus G1T

Il sera aussi possible de simuler dans la sonde des problèmes réseau de type : gigue, perte de paquets, perte d’information de PID, modification de la limite de gigue du PCR, paquets dupliqués, paquets hors séquence. Ces simulations permettront de se rendre compte de la robustesse du réseau.

On pourra ensuite installer, à différents points du réseau, une ou des sondes de type Cricket IP Plus. Ces petites sondes vont analyser le trafic vidéo et en particulier :

• Permettre de faire du troubleshooting de la vidéo en cas d’incident
• Mesurer la performance de la vidéo grâce au  »MDI », l’équivalent du MOS pour la vidéo
• Valider les capacités multicast du réseau
• Valider le transport MPEG de la vidéo
• Mesurer et analyser le contenu vidéo en temps réel

Tableaux de bord de gestion de la vidéo

Graphe de performance du canal vidéo

J3Tel peut réaliser ces opérations sous forme de prestations, en laboratoire ou sur site, et faire suivre l’étude d’un audit plus poussé si des problèmes apparaissent lors de la validation.

Pourquoi ne pas commencer à entrer dans le sujet par une définition ?

Le réseau de collecte est l’ensemble des moyens mis en œuvre pour permettre la collecte des informations venant des éléments réseau afin de les router vers les différentes sondes de métrologie et de sécurité. L’objectif est donc d’obtenir le maximum de visibilité réseau et d’optimiser l’utilisation des sondes.

Quelles sont les problématiques de supervision rencontrées aujourd’hui ?

• Les débits augmentent de plus en plus, le 10G se généralise, le 40G et le 100G arrivent. Comment continuer à utiliser mes sondes 1G ? Comment raccorder mes sondes ?

• Le réseau est de plus en plus dense, avec de plus en plus d’interfaces à analyser, comment puis-je améliorer la corrélation de mes données ?

• Puis-je analyser le trafic sans connaitre les données de mes clients ?

• Comment superviser un brin réseau avec différentes types de sondes ?

Comment répondre à l’ensemble de ces problématiques ?

Plusieurs méthodes sont à ma disposition pour optimiser l’utilisation de mes outils de métrologie :

1. Port Miroir
2. TAP-TAP multiports
3. Matrice de brassage
4. Agrégateur SPAN
5. Agrégateur SPAN filtrant
6. Tableau de comparaison

Illustration avec l’utilisation de l’agrégateur SPAN filtrant (Net Tools Optimizer d’ANUE)

Si je me place dans un cas de besoin de supervision dans un Datacenter, sans agrégateur SPAN filtrant NTO, je serais dans l’obligation de multiplier le nombre de points de collecte (TAP, port miroir) ainsi que le nombre de sondes pour garantir une supervision complète du trafic, le tout demandant un investissement en ressources financières et techniques trop important de nos jours.

L’utilisation du NTO va me permettre de centraliser mes points de capture,  d’optimiser  l’utilisation de mes sondes grâce à ses fonctionnalités de filtrage et ainsi, me permettre de diminuer le nombre de sondes nécessaires au sein de mon Datacenter.

Avant déploiement NTO

Avec déploiement NTO

Vue de la matrice de trafic réalisée au niveau de l’interface graphique de NTO

Pour lire la Présentation ANUE : Comment optimiser ses moyens de métrologie ?

Dans sa dernière version, la solution Qual’IT intègre la possibilité de paramétrer des tests à partir et/ou à destination de groupes de boitiers Qual’IT Box en plus des tests de boitier à boitier.

Cette fonction va faciliter le paramétrage des tests et, par la suite, l’évolutivité et la maintenabilité de la plateforme.

Prenons un exemple concret : notre solution Qual’IT est en place et effectue à intervalles réguliers des tests du réseau entre notre Datacenter et tous nos sites distants.

Dans les anciennes versions de Qual’IT, nous avions paramétré les couples « box Datacenter » vers « box site distant » une à une. Imaginons maintenant que nous ayons un nouveau site distant. Il va falloir rajouter la liaison à tester dans tous les tests réseau en place.

Dans la dernière version, il est possible de créer un test depuis le boitier Datacenter vers le groupe de boitiers des sites distants. Ainsi, il suffit de rajouter la Qual’IT Box correspondant au nouveau site distant dans le groupe pour que tous les tests se mettent à jour automatiquement.

Paramétrage d’un test à partir d’un datacenter vers 3 sites distants sans la gestion des groupes

Paramétrage d’un test à partir d’un datacenter vers un groupe de sites distants

Qu’est ce Qual’IT ?

La solution Qual’IT, composée de la Qual’IT Box et de la console Qual’IT, a été développée par J3tel, afin d’apporter une réponse rapide à une équipe d’exploitants sur la mise en cause ou non du réseau vis-à-vis de plaintes d’utilisateurs et déterminer son implication sur cette dégradation constatée.

A quoi sert la console Qual’IT ?

La console Qual’IT est le guichet unique de la solution gérant l’ensemble des Qual’IT Box en terme de configuration et de remontée de résultats. Elle permet, de manière simple et intuitive, de configurer les scenarii de tests à réaliser de manière manuelle ou automatique, de configurer l’automatisation du lancement des tests entre boîtiers, de consulter via une interface web, les résultats obtenus et ceci sur l’ensemble des tests réalisés dans le temps, de comparer le résultat obtenu par rapport à un référentiel attendu,  de rendre disponibles et exploitables les résultats vers la base de données de l’entreprise.

A quoi sert la Qual’IT Box ?

La Qual’IT Box a pour fonction d’émuler un client ou un serveur et se présente sous la forme d’un petit boîtier indépendant ayant pour fonction d’émuler un client ou un serveur. Chaque boîtier reçoit de la console Qual’IT des scripts de simulation de l’application à exécuter. Les boîtiers, positionnés en différents points du réseau, peuvent dialoguer en point à point ou en point à multipoint ou en multipoint à multipoint.

Article réalisé en collaboration avec Aymeric.

Les nouveaux agrégateurs SPAN filtrants ou Data Access Switch référencés VS-1212-F et VS-1224-F font parti de la gamme Versastream et permettent d’accroitre la visibilité de votre réseau tout en tirant parti de vos investissements en sondes d’analyses, sondes de captures ou équipements de sécurité.

Les fonctions de répartition de charge et de filtrage intégrées aux équipements permettent d’alléger la charge de vos analyseurs réseaux, de vos sondes et de vos équipements de sécurité en filtrant uniquement les données utiles que vous souhaitez surveiller et distribuer, de manière identique, parmi vos différents outils.

L’agrégateur SPAN filtrant ou Data Access Switch améliore la visibilité de votre réseau face aux différentes problématiques rencontrées en proposant un large choix de filtres.

Comme tous les produits Data Access Switch, les modèles VS-1212-F et VS-1224-F peuvent être commandés depuis  votre navigateur web avec le logiciel STREAMLITE ou en ligne de commande (CLI), ce qui vous permet de contrôler l’ensemble des données via une interface unique.

Les plus :

• Permet de monitorer des liens 10G avec des outils ne fonctionnant qu’à 1 G.

• Load Balancing :  Equilibre la charge entre une multitude de ports et évite ainsi la perte de données.

• Filtrage des données : l’application de filtres hardware permet d’éviter les engorgements sur les ports de monitoring. La syntaxe des filtres est basée sur Wireshark dans la console CLI.

• Agrégation de liens (Many to Any)

• Regeneration (Any to Many)

• Port Steering (Any to Any)

Pour lire plus, télécharger les documentations :

VERSAstream™ 1212 Data Access Switch with FilteringLoad Balancing (12-Port)

VERSAstream™ 1224 Data Access Switch with FilteringLoad Balancing (24-Port)

ou rendez vous sur le site du constructeur :

Datacom Systems

Qu’est qu’un agrégrateur filtrant ?

Les réseaux étant de plus en plus chargés, nous constatons les limites de l’agrégation dans le cas où la somme des débits de chaque lien dépasse le potentiel du port d’analyse.
Une nouvelle génération d’équipement est apparue, l’agrégateur filtrant, qui permet de mettre en œuvre des filtres sur le contenu des flux et permet de ne dériver que le flux souhaité pour l’analyse. Les critères de filtres peuvent être une combinaison sur l’adresse IP, le numéro de port, la MAC adresse, le type de protocole. Une autre possibilité sera de spécialiser l’outil d’analyse pour le suivi d’une application particulière comme par exemple la VoIP.

L’agrégateur filtrant permet de paramétrer un port vers un autre au choix tout en gérant l’option ‘régénération’. Son architecture permet d’orienter un port d’entrée vers plusieurs ports de sortie (copie de flux de données), d’agréger les données Tx et Rx et d’orienter les flux vers plusieurs ports de sortie.

L’ agrégateur SPAN filtrant ou Data Access Switch va permettre d’appliquer à votre SPAN le filtrage des paquets au niveau des ports de sortie, vous assurant ainsi que vos outils d’analyse réseau (ou sécurité) reçoivent uniquement le trafic que vous souhaitez surveiller.

En 2012, nous avons investi dans plusieurs équipements nécessaires à la mise en place d’une plateforme de génération et de monitoring des flux de type ASM (Adaptive Streaming) et OTT (Over the Top).

L’objectif est de créer une chaîne de liaison permettant d’encoder depuis la TNT des flux en multicast, récupérés par un segmenteur/packageur, pour les envoyer vers nos Origin Servers.

La fonction du segmenteur/packageur est de découper les flux multicast en « chunk » (petits fichiers contenant 2 à 10 secondes de vidéo) avant de les envoyer vers les Origin Servers, sous les formats :

• HLS (HTTP Live Streaming)
• Smooth Streaming (Microsoft Silverlight)

Pour valider cette chaîne de liaison, nous avons mis en place une sonde DVA (en charge du monitoring QoE et QoS) du côté des flux multicast, associée à une sonde active, l’Expedus ASM, destinée à simuler les clients se connectant aux Origin Servers.

En complément, nous nous sommes équipés d’une sonde passive IQ Dialogue ASM permettant de valider le point de publication entre le packageur et l’Origin Server mais aussi de monitorer les flux demandés, par l’Expedus ASM, aux Origin Servers.

Ainsi, nous bénéficions pour nos clients :

• d’une plateforme de démonstration.
• d’une plateforme de validation dans le but d’effectuer des tests de nouvelles versions ou de nouvelles fonctionnalités.

A quoi sert la sonde Expedus DVA ?

Ella permet d’analyser les problèmes d’écrans noirs, de gel d’images, de silence audio, de macroblock et de pixelisation. Elle permet, aussi, de s’assurer de la qualité de la vidéo en sortie de l’encodeur/décodeur/transcodeur.

A quoi sert la sonde Expedus ASM ?

Sonde Active de QoS, elle permet de valider la capacité des Origin Servers de mettre à disposition l’ensemble des flux ASM auprès des Caching Servers des CDN. Cette sonde simule simultanément plusieurs clients regardant tous les profils existants sur une ou plusieurs chaînes. Elle valide aussi la taille de chaque chunk et de chaque profil ainsi que l’ensemble des échanges HTTP.

A quoi sert la sonde IQDialogue ASM ?

La sonde passive IQDialogue ASM permet de monitorer l’ensemble des flux en sortie du packageur à destination des Origin Servers (Point de Publication). Placée en sortie de l’Origin Server, elle permet de valider la QoS vers tous les CDN abonnés aux Origin Servers et de connaître, ainsi, l’usage des CDN et la QoS délivrée aux CDNs. Elle permet aussi de vérifier le SLA de chaque CDN.

Nous vous souhaitons une année à venir pleine de promesses et de succès.

Nos meilleurs vœux de bonheur pour cette nouvelle année 2013 !

Au cours de cette matinée, les intervenants J3Tel et Fluke Networks ont présentés les nouvelles solutions de la gamme des sondes NTM (Network Time Machine) et du logiciel d’analyse CSA (Clearsight Analyzer) de Fluke Networks.

Petit-déjeuner Ladurée, au salon Bonaparte, le 22 novembre dernier en images…   

Pour lire les présentations utilisées lors de cette matinée :

Présentation sondes NTM J3Tel

Présentation CSA Clearsight J3Tel

Presentation Fluke Networks

J3Tel_Séminaire 22 nov 2012_

Mais comment tout cela fonctionne-t-il?

Le principe est plutôt simple:

• Une chaîne de télévision génère du contenu,
• Ce contenu est envoyé vers des plateformes d’encodage et de segmentation,
• Chaque segment créé sera un flux vidéo décliné en plusieurs formats (HLS, Silverlight, Flash, Smooth streaming, etc…) et avec différentes résolutions,
• Ces derniers sont envoyés vers un CDN qui lui-même renvoie ce flux vers notre FAI.

Comme vous pouvez le voir ci-dessus, mettre en place un site de Streaming vidéo pour un diffuseur, est simple sur le papier.

Cependant sa mise en place l’est beaucoup moins pour des raisons de coûts et aussi de responsabilité. En effet, si un client n’arrive pas à regarder ses vidéos sur son terminal, à qui la faute? Est-ce le créateur du contenu? Est-ce le CDN? Est-ce l’opérateur?

Avant de pouvoir répondre à ces problématiques, il est important de bien comprendre la façon dont le Streaming vidéo fonctionne:

1. Au début est né le le flux vidéo en MPEG-TS,
2. Ce dernier en clair est ensuite récupéré par les Encodeurs et Segmenteurs,
3. Les Segmenteurs ont pour objectif de créer les différents flux de Streaming, les flux générés sont sous la forme de petites vidéos de 10 secondes appelées Chunk.
4. Ces flux seront envoyés aux Origin Servers,
5. Puis Les Caching serveurs, répartis au plus proche de l’utilisateur (….ou pas), ont pour objectif de distribuer les flux directement aux demandeurs.
6. Le dernier point est l’utilisateur avec au choix, son smartphone, sa tablette ou son PC.

De ces 6 points, il est possible de rencontrer plusieurs répartitions des rôles et attributs.

Les 3 premiers points seront généralement pris en charge par le créateur du contenu.

Le 4ème point est pris en charge soit par le créateur, soit par le CDN.

Le 5ème point est pris en charge par le CDN.

Quant au point n°6, ce sera à l’opérateur de s’assurer de l’accessibilité aux flux.

Les questions qui se poseront (ou qui ont déjà été posées pour certains) sont:

• « Comment s’assurer que mon Client aura une bonne qualité? »
• « Comment définir les rôles? »
• « Pourquoi devrais-je gérer les Origins Servers? »
• « Dois-je choisir un ou plusieurs CDN? Comment répartir la charge entre mes CDN? »

Nous aborderons ces questions dans un prochain billet.

Au revoir!

« Les lenteurs du réseau m’empêchent de travailler !! Je mets un temps fou à aller sur [application réseau de votre choix]!!!!! »

Mais comment savoir si c’est le réseau qui ne fonctionne pas correctement ou si c’est autre chose (l’application, les serveurs d’application, la base de donnée, le poste client, …) ?

Comment savoir si c’est vraiment une lenteur de mon réseau ?

Voilà la vraie question ! Car en tant qu’administrateur réseau ce qui m’intéresse c’est de prouver aux autres services que ce n’est pas un problème réseau et qu’ils devraient regarder un peu de leur coté. Seulement quels méthodes a-t-on à notre disposition pour fournir cette preuve ?

La capture de trace ?

C’est parti pour capturer le trafic.

Allons mettre 2 taps en coupure (les ports miroirs ne restituent pas exactement les temps réseau) 1 au plus près du poste de Roger¹  (notre râleur N°1) et un au plus près du serveur (en heures non ouvrées bien sûr pour ce dernier, car on ne peut pas couper l’accès au serveur d’application comme ça…). Ensuite, on lance les captures. On attend que l’utilisateur du poste client ait un problème de lenteur (et oui c’est pas en permanence), et qu’il note les heures où ça se produit (ce qu’un utilisateur ne fait JAMAIS).

Une fois qu’on a 2 à 3 jours de capture, on ouvre les 2 traces et on cherche les requêtes qui ont été lentes parmi les quelques milliers de transactions. On arrive enfin à dire que c’est le serveur d’application qui a mis 40 secondes à répondre…

Après une semaine, on peut dire que les « lenteurs réseau » de Roger sont en réalité des soucis au niveau du serveur d’application. Plus qu’à faire la même chose auprès des postes de Régis, Thomas et Alice (respectivement les râleurs N°2, 3 et 4 de l’entreprise).

Après plus d’un mois d’acharnement et de souffrances, on a notre preuve !! C’est l’application et/ou son serveur qui mettent du temps à répondre !!

Réponse du service application :

« Ça tombe bien, on a déployé une nouvelle version qui est plus rapide et corrige ces lenteurs. Maintenant si c’est long c’est qu’il y a des lenteurs du réseau !! ».

Le polling SNMP?

Essayons alors de voir au niveau de la santé des équipements réseau.

Pour cela commençons par autoriser la récupération des infos en SNMP sur les équipements qui le permettent (et sur lesquels on a des droits). Ensuite, on installe un poller SNMP dans lequel on ajoute nos équipements.

Une fois ce travail fait, on a une visibilité sur les équipements en terme de débit traité, de CPU, de mémoire et de paquets perdus.

Par contre pas d’informations sur les temps de réponse… Donc même si cela peut donner un état des lieux sur la santé des divers équipements, cette méthode ne nous garantit pas que le réseau n’est pas responsable des ralentissements de l’application utilisée.

Gagnons du temps avec Qual’IT

Une autre option est de déployer une solution Qual’IT pour vérifier de façon régulière si le réseau répond correctement.

Qual’IT va s’appuyer sur les Qual’ITBox qu’on va placer à des endroits stratégiques du réseau et qui vont tester le réseau situé entre elles. Ces boitiers étant dédiés aux tests, nous nous affranchissons ainsi de la charge d’un serveur d’application ou bien du poste client.

Pour être encore plus pointilleux sur les preuves qu’on va fournir, on crée un profil de test qui va simuler les mêmes communications que mon application à partir d’une capture.

On va placer au minimum une Qual’ITBox au plus près du serveur d’application et quelques unes au plus près des utilisateurs mécontents. Une fois que ces box sont en place, la console Qual’IT va nous permettre :

• d’organiser les Qual’ITBox (en zones géographiques ou bien en services),

Gestion des Qual'ITBox

• de définir des scripts de tests incluant les informations à surveiller (telles que le temps de réponse, le débit, le temps de latence, …), les seuils de réussite ou d’échec du test (par exemple le test est en échec si le temps de réponse réseau est supérieur à 2 secondes) et, éventuellement, les alarmes à remonter par e-mail ou par trap SNMP.

Paramétrage des seuils de test

• de définir les profils de QoS TOS ou DSCP utilisés sur le réseau si besoin,
• de paramétrer les tests, entre les Qual’ITBox, lancés par Qual’IT à intervalles réguliers.

Paramétrage d'un test

Une fois que Qual’IT aura fait quelques tests, nous n’aurons plus qu’à jeter un coup d’œil au tableau de bord.

Tout est vert !! Mon réseau est parfait!!

Si tout est vert, c’est qu’il n’y a pas de problème réseau et que le problème de lenteur vient d’autre part. Si on a du rouge, nous allons pouvoir forer dans les résultats de test et voir ce qui pose problème (la latence dans un sens de communication, les pertes de paquets, …) et tout cela de manière continue.

Et voila! Maintenant on peut aller voir le DSI en lui assurant que la « lenteur réseau » n’en est pas une et lui présenter nos preuves.

En savoir plus sur Qual’IT

A la question « Comment déployer Netflow ? » il est important de comprendre les problématiques actuelles.

Premier constat : la majorité des clients sont opérés.

Second constat : l’activation d’une visibilité à notion de flux est soumise à contrat, changement d’éléments actifs et abonnement.

Troisième constat : on rend l’opérateur juge et parti sur ce qu’il présente.

Comment répondre à cette problématique ? Toujours à moindre frais ?

La solution : profiter de l’information que peut fournir Netflow au travers d’un équipement tiers.

Lors de ma recherche de moteurs d’export, je suis tombé sur nprobe.

Première surprise : L.Deri, patron et cerveau du moteur nprobe a développé des pilotes hardware assurant une capacité d’écoute sur du 10 Gb/s full band.

Seconde surprise : l’environnement nBox s’interface très bien avec des sondes et cartes constructeur multiports à bas coût. Résultat, on peut obtenir un sonde 10G à moins de 10 K€!! (pour info une sonde de capture massive de flux avec des To de disque et traitant un trafic 10 Gb coûte entre 60 et 100 K€ voir plus chez certains fournisseurs qui utilisent leur propre hardware).

Sonde pour remplacer routeur Netflow

Troisième surprise : nProbe analyse et décode des encapsulations non encore gérées par les moteurs Netflow v9 ou IPfix des éléments actifs actuels. Temps de réponses, application de couche L7, URL, requêtes mysql, DNS…

Quatrième surprise : analyse portée sur le stack TCP/IP avec des mesures du 3Way handshake, des retransmissions, des out of order.

Cinquième surprise : un collecteur est capable d’enregistrer ces informations et d’en présenter un certain nombre en fonction du temps. Scrutinizer est aujourd’hui le seul collecteur à ma connaissance à enregistrer les flux flexible Netflow même si le champ n’est pas connu de l’application.

Contenu d'un template nProbe vu par Scrutinizer

Pour plus d’info sur l’outil de collecte Netflow vous pouvez vous rendre ici

En pensant au lancement de ce blog, je me suis demandé comment aborder Netflow pour que nos lecteurs puissent réellement comprendre l’intérêt des technologies de métrologie à base de flux.

Je vais donc m’attacher à décrire ce qu’offre aujourd’hui le protocole Netflow.

Dans de futurs billets, j’aborderai les autres protocoles d’export de flux que sont S-Flow, J-Flow et IP-Fix.

Etat de l’ART

En termes de surveillance des réseaux d’infrastructure, les solutions de métrologie ont longtemps reposé sur :

• le polling SNMP, solution largement déployée aujourd’hui fournissant les indicateurs indispensables sur l’état de santé des éléments actifs constituant le réseau mais se limitant aux couches basses.
• le bon vieil analyseur de trace, tel que wireshark, nécessaire au troubleshooting ponctuel d’incidents
• Les solutions de capture massive de flux et d’analyse de performance, orientées Data Center et fort coûteuses.

Les besoins en visibilité sur les réseaux d’infrastructure se font grandissants. les coûts associés à la métrologie se réduisent.

La mesure ne fait malheureusement pas partie des prérogatives des projets d’implantation et généralement, les entreprises commencent à considérer la métrologie lorsqu’un incident majeur devient source de grogne générale des utilisateurs du Système d’Information.

Quelle solution mettre en œuvre pour améliorer la visibilité sur le réseau et à moindre coût ?

Netflow en est, à mon sens, la solution la plus pérenne et la moins coûteuse.

Qu’est ce que Netflow ?

Il faut comprendre qu’avec Netflow, c’est le réseau qui vous fournit l’information des usages et même plus.

Initialement, Netflow est un mécanisme de commutation intégré aux routeurs Cisco WAN (fin des année 90). Ce sont les ingénieurs Cisco qui ont su profiter de la mine d’information  que recelait leur routeur pour en faire un protocole d’export.

Basé sur l’inspection des entêtes des couches 3 et 4, un cache provisionnait en plus des éléments d’information comme la volumétrie en paquets et en octets avec une granularité à la minute.

Très longtemps les administrateurs furent réticents à activer l’export Netflow sur les commutateurs en raison de la charge induite dans le cache qui impactait directement la mémoire et le CPU. C’est chose révolue. Les équipements réseau possèdent leurs propres ASIC pour traiter le flux et l’envoyer sous format de ticket Netflow à destination d’un collecteur.

Les versions de Netflow ont évolué au fil des années jusqu’à l’ultime version Netflow v9, format flexible et extensible du protocole, qui devient le modèle du standard réalisé par l’IETF appelé IPFIX.

Flexible et extensible. N’y voyez aucune allusion douteuse, je parle bien d’un protocole.

Avant, les formats des tickets Netflow étaient figés et le moteur d’analyse limité à son analyse des couches réseaux et transport.

Obtenir de la flexibilité sur un protocole d’export signifie être libre de définir son propre format de ticket Netflow c’est à dire être libre de définir les champs analysés.

L’extensibilité du protocole, est là tout l’intérêt de Netflow v9 et d’IPFIX.

Hier, je n’obtenais que des graphes de charge par application, client, serveur, vlan, adresses mac, labels MPLS, ce qui, vous l’avouerez est déjà un pas de plus comparé au polling SNMP.

Aujourd’hui, je mesure le temps de réponse réseau, les statistiques TCP (retransmission, déséquencements), les pertes de paquets et la gigue en VoIP, les URL visitées, les temps de réponse applicatifs, les applications web telles que You Tube, Skype, e-mule et j’en passe… Aujourd’hui je peux même voir le trafic entre mes machines virtualisées.

Bref, je vois assez pour ne plus avoir besoin de sonde de capture de flux.

Nombre de connexion par url

Demain, j’aurai les statistiques d’état de santé de mes éléments actifs. J’aurai les alertes générées hier par Syslog, je serai prévenu de la reconfiguration de mon réseau.

Bref, je n’aurai plus besoin de SNMP ni de Syslog. J’aurai un protocole unique pour la supervision de l’ensemble de mon Système d’Information.

C’est bien joli tout ça, mais comment je visualise mes données ?

Bien sur, le protocole seul ne fait pas tout. Les tickets ont besoin d’être collectés, analysés, historisés et présentés.

C’est le rôle des solutions de collecte Netflow que j’aborderai dans de futurs billets de ce blog.

Une petite vidéo de présentation de Netflow est disponible sur notre site.

Puis l’idée faisant son chemin, nous nous sommes dits que les questions que nous nous posons tous les jours et les situations que nous rencontrons devraient aussi vous intéresser !!

Alors pourquoi ne pas partager nos expériences?

C’est ainsi que nous avons décidé d’écrire régulièrement des articles dans ce blog pour partager sur les technologies que nous utilisons, parler des cas d’école que nous rencontrons ou bien de l’état de l’art de la métrologie réseau.

Bonne lecture

Découvrir J3TEL