jump to navigation

Pourquoi une mauvaise gestion de la bande passante réseau peut vous couter cher ? 30 octobre 2012

Posted by frnetworker in Diagnostic Réseau, OmniPeek.
Tags: , , ,
add a comment

Toutes les entreprises, rencontrent un jour ou l’autre un problème de bande passante. Une bonne politique de gestion de la bande passante est source d’efficacité et d’économies substantielles, voici pourquoi :

Il est fréquent d’entendre dire que les problèmes du réseau viennent d’un manque de bande passante qui diminue au fil du temps. Trop souvent la première réaction est de chercher à augmenter la bande passante afin de faire disparaitre le problème rencontré.

Du point de vue de l’utilisateur, une bande passante plus importante va améliorer son confort de travail. Mais l’adjonction de bande passante ne fait, le plus souvent, que masquer temporairement les problèmes.

En augmentant la bande passante, on ne s’attaque pas à la cause du problème, pire ce nouveau confort apparent peut même masquer des signaux d’alerte qui mériteraient une attention immédiate, comme par exemple un poste infecté qui essaye de propager un malware et accapare la bande passante de l’entreprise.

Mais, qu’est-ce qu’un soucis de bande passante ? Pour beaucoup c’est quand l’utilisation de la bande passante dépasse un certain seuil. Pour d’autres la fréquence et la durée de ces dépassement sest également prise en compte.

Sans connaissance approfondie des trafics qui circulent sur votre réseau,
augmenter la bande passante quand ces signaux apparaissent
n’est rien de plus que de jeter de l’argent par la fenêtre.

Sniffer réseau OmniPeek : détection des phagocytes de bande passante

Détecter les consommateurs de bande passante

Contrôler si vous devez ou non augmenter la bande passante de votre réseau est un processus qui devrait recueillir toute votre attention. Les 4 étapes sont l’audit, l’analyse, les modifications et la mesure. Voyons ces points plus en détail :

Auditer

L’objectif principal de la phase d’audit est de catégoriser votre trafic en fonction de vos besoins.

Comme les affaires dépendent pour partie des bonnes performances du réseau, vous devez vous assurer de disposer de la bande passante nécessaire pour vos applicatifs métier dans toutes les circonstances, y compris lors des pics de charge. Nous savons tous que la bande passante disponible à tendance à être grignotée au fur et à mesure. A vous de déterminer si c’est par des applications métiers ou par du trafic futile !

Le plus souvent le trafic réseau peut être divisé en 4 catégories :

Le trafic critique pour le business : En l’absence de cette catégorie de trafic, votre entreprise s’arrête. Typiquement se sont les email, SaaS (incluant les activitées cloud), les liaisons WAN inter-sites, le VPN … La liste peut varier selon votre métier : par exemple une société de production vidéo, doit ajouter à cette catégorie de trafic les flux vidéos.

Le trafic professionnel : Sans ce type de trafic, certains travailleurs vont subir des perturbations, mais votre business ne s’arrêtera pas pour autant. Par exemple la recherche d’information sur le web ou les activités liées aux média sociaux.

Le trafic ‘accessoire’ : normalement il ne va pas impacter votre travail et son niveau est (et doit) rester très faible. Il s’agit par exemple des email personnels, du streaming audio, des accès Facebook …

Enfin le trafic ‘toxique’ c’est à dire celui qui empoisonne votre réseau. Par exemple le streaming vidéo, le peer to peer, les gros transferts de fichiers.

Connaitre et identifier les différentes types de trafics est essentiel pour la gestion de la bande passante. Si vous détectez du trafic toxique, votre mission est de l’éradiquer, pas d’accroitre la bande passante !

Analyser

La gestion de la bande passante ne se limite pas à connaitre le type de trafic, il faut aussi avoir une connaissance des différents média qui composent votre réseau et du type d’équipements réseaux qui s’y trouvent. Le média qui demandera la plus grande vigilance est bien sur le wifi puisqu’il s’agit d’un média dont la bande passante est partagé, sensible aux interférences et ‘mono-utilisateur’. A un instant donné, un seul utilisateur peut envoyer un signal radio sur le réseau : si le débit dont il dispose est faible, cela impactera l’ensemble des utilisateurs de ce segment réseau.

Dans ce cas, ce qui peut être perçu comme un problème de bande passante wifi est simplement un problème de client wifi peu performant qui génère une grande quantité de trafic.

Modifier

Dans le mesure ou vous avez compris vos besoins prioritaires, vous allez être en mesure de modifier le mode d’utilisation de votre réseau. Bien entendu le trafic critique va resté en place mais vous pourrez probablement router différemment le trafic de moindre importance sur des réseaux moins chargés. Vous pouvez aussi décider de bloquer certains types de trafic comme l’accès aux média sociaux et bien sur l’ensemble du trafic toxique. Évidement, les décisions que vous prendrez dépendent de votre appréciation et de la politique de l’entreprise, mais dans tout les cas, ce sera une approche de la gestion de la bande passante moins couteuse et dont le bénéfice sera plus simple à quantifier.

Mesurer

Il s’agit tout simplement de valider l’efficacité des mesures prises. Obtenez-vous le résultat espéré ?

Dans la mesure ou le trafic sur votre réseau informatique est ‘vivant’ et évolue, la gestion de la bande passante est bien sur un processus itératif. L’analyse doit être renouvelée de proche en proche.

Comment prendre ses mesures et disposer des informations nécessaire à une gestion responsable de la bande passante ? Avec un sniffer réseau (ou analyseur de paquets) comme OmniPeek qui vous donnera toute les informations nécessaire à la compréhension et à l’optimisation de la bande passante sur votre réseau. L’évaluation 30 jours est gratuite, alors n’hésitez plus.

Librement inspiré du blog de l’éditeur WildPackets : How to Identify Network Problems Masked as Bandwidth Issues

 

Lire aussi : Une mauvaise qualité VoIP peut couter chère ! sur OmniPeek sniffer Blog

OmniPeek est distribué en France par NetWalker.fr
Tarifs et évaluation sur NetWalkerStore.com

Identifier et corriger les problèmes de migration IPv6 les plus courants 9 juillet 2012

Posted by frnetworker in Diagnostic Réseau, OmniPeek.
Tags: , , ,
add a comment

Le 6 juin 2012 était le jour officiel du lancement du protocole IPv6 !

L’année passée, lors du jour IPv6 mondial ( Word IPv6 Day), plusieurs sociétés majeures d’internet ont activé l’IPv6 pour une journée de tests. Cette année, lors de l’évènement, les sociétés participantes ont à nouveau activé IPv6 et espéraient ne plus le désactiver. Certains participants, comme Google et FaceBook, ne l’ont d’ailleurs plus jamais désactivé après la première édition de cette journée IPv6. L’année passé, il s’agissait pour la plupart des entreprises d’une journée de tests en grandeur réelle dans le but d’un basculement réussi des fournisseurs d’accès internet, des fabricants de matériels réseau et autres sociétés du web.

Dans les faits, on assiste à une pénurie d’adresses IPv4, , l’Asie a d’ailleurs déjà effectué son basculement … aussi le changement définitif approche à grands pas. IPv6 apportera plusieurs améliorations importantes ( plus de détails :  IPv6: Is It Finally Time ). En fait IPv6 a commencé a apparaitre lors des Jeux Olympiques de 2008.

Dans ce billet nous allons mettre un peu les mains dans le cambouis et voir quels problèmes vous pouvez rencontrer lors de la mise en oeuvre de l’IPv6 dans votre société et comment régler les problèmes.

Connectivité

Historiquement, le plus gros problème avec Ipv6 est justement d’établir la connectivité IPv6. Jusqu’à ces derniers temps il y avait assez peu de fournisseurs d’accès internet qui proposaient IPv6 et moins encore pour un usage personnel. L’un des buts principaux de la manifestation World IPb6 Launch était de fournir l’option IPv6 au plus grand nombre possible grâce aux fournisseurs d’accès internet et à son support dans les routeurs domestiques. Même si il est évident que l’IPv6 ne peut pas encore être disponible pour tout le monde, l’Internet Society visait un objectif de 1% de connectés en IPv6.

Après s’être assuré de la disponibilité effective de l’IPv6, le problème suivant est de savoir comment configurer l’IPv6 en respectant l’IPv4. Doit-on utiliser un mécanisme de tunneling ou l’une des méthode de translation IPv4 ? La réponse tient en 3 mots : Aucune des deux pour la bonne raison qu’IPv6 n’interfère pas avec l’adresse « classique » IPv4. Historiquement, des solutions temporaires aillant eu recours au tunneling n’ont plus vraiment de raison d’être : Le support natif de l’IPv6 par les fournisseurs d’accès internet permet d’utiliser la méthode du « Dual Stack » qui autorise le fonctionnement des 2 versions du protocole de concert.

Avant même d’imaginer activer la connectivité IPv6, n’oublier pas les règles « d’hygiène de base » : Utilisez un firewall !

La plupart des équipements modernes, disposent à minima d’un support basique des polices de sécurisation du trafic.

La bonne nouvelle c’est qu’IPv6 ne nécessite plus l’utilisation du NAT (et ne le supporte pas) les polices de sécurité seront beaucoup plus simples à configurer (et beaucoup plus claires).

Les adresse IPv6 sont assez différentes des adresses IpV4, aussi il est assez difficile de savoir ce que doivent être les « Bonnes Pratiques ».

Il est bien sur tentant d’utiliser Stateless Address Auto-Configuration (SLAAC) pour simplifier la mise en œuvre,  mais ce n’est pas forcément la meilleure idée : SLAAC utilise la MAC address pour générer l’adresse IPv6 afin de limiter le risque d’adresses dupliquées. En plus du soucis d’absence de confidentialité en incluant l’identifiant d’un adresse hardware dans l’adresse routable, SLAAC allonge la taille de l’adresse IPv6 plus que nécessaire. Il est bon de se souvenirs des difficultés rencontrées avant l’apparition du DHCP. Lorsqu’une adresse générée par SLAAC aura un format du type :  2001:db8::7ee9:d3ff:ffe46:86bb, une adresse DHCP pour le même host aura un format comme : 2001:db8::1c. Même si l’utilisation de DHCPv6 prend un peu de temps à mettre en oeuvre, cela rendra l’administration au quotidien bien plus simple.

MTU, fragmentation et ICMP

Le premier problème IPv6 survient avec les mauvaises habitudes contractées avec IpV4 concernant le MTU, la fragmentation et ICMP.

En IPv4, les paquets de grande taille, sont fragmentés en plus petits paquets par les routeurs disponibles sur le cheminement des trames.

Il en va tout autrement en IPv6 ou les routeurs vont retourner un paquet ICMPv6 d’erreur pour les paquets trop grands. C’est au poste émetteur de gérer sa propre fragmentation.  Pourquoi un poste devrait il gérer une fragmentation layer 3 peu fiable lorsque TCP c’est charge parfaitement au layer 4? Si un programmeur n’interroge pas l’OS pour s’enquérir de la MTU, et se base sur la MTU standard Ethernet de 1500 octets, moins 20 octets pour l’IPv4 et 20 autres pour TCP, le calcul laisse penser que 1.460 octets sont disponible pour les données TCP dans chaque datagramme. Malheureusement l’entête IPv6 est à minima de 40 Octets soit 20 Octets de moins disponibles !

Heureusement, la plupart des applications réseau comme les navigateurs web, ont tous été testés en IPv6, il peut rester des applications qui ne sont pas codés pour utiliser ces valeurs dynamiques pour la pile réseau. D’autant également, que les politiques de sécurité restrictives en IPv4 bloquent les paquets ICMP à l’exception du ping. De la sorte, la conjonction des entêtes trop long, l’absence de fragmentation par les routeurs associé au blocage partiel des trames ICMPv6 va générer des paquets qui n’atteindront pas leur destination et ne permettront pas le retour (au poste émetteur) des messages de diagnostic d’erreur. Ce problème sera particulièrement difficile à identifier sur switches des réseaux locaux qui autorisent les jumbo frames ethernet puisque les dépassement de taille y sont autorisés et gérés. Les paquets transiteront sans problèmes sur les sous réseaux locaux entre les switches L2 et L3 … mais seront bloqués par les routeurs.

HTTP Compliance

Le dernier problème lié à la transition IPv6 est quelque peu plus subtil … HTTP est un protocole plutôt simple de part sa conception, mais qui cache en fait une grand complexité parce que la plus grand majorité des pages web incluent des tags pour indiquer au navigateur de charger des contenus additionnels qui peuvent provenir de différents serveurs.

Les pages web sur les serveurs hébergés sur des hosts IPv6 pourront être amenés à charger des contenus sur des serveurs IPv4. Durant la phase de cohabitation, les pages web seront alors chargées bien plus lentement si un DNS non compatible IPv6 ignore les requêtes des enregistrements AAAA IPv6, provoquant un time out sur le poste utilisateur qui essayera d’accéder à l’enregistrement A en IPv4. Et comme ce problème n’existe pas pour le serveur … il risque fort de persister jusqu’à la mise à jours des DNS ou des infrastructures de l’hébergeur. Fort heureusement ce type de problème est déjà survenu par le passé depuis 2005 ( voir RFC 4074). Le choix du format de requête AAAA ou A est sous le contrôle du navigateur et ce problème est sérieusement à l’étude en ce moment même.

Les études d’APNIC Labs fin 2011 ont montré qu’Internet Explorer 9 à une timeout de 21 secondes, mais Chrome utilise une méthode qui réduit ce timeout à 0,3 seconde ! (et les versions de FireFox sont encore moins bien loties). D’autres solutions peuvent passer par un filtrage et l’utilisation d’un serveur DNS local qui fera le lookup pour le poste utilisateur, ce qui résoudra le problème grâce à une combinaison caching et forced failback. Le paradoxe d’internet est qu’HTTP a été la clé de voûte de l’adoption massive d’IPv4 mais qu’il sera sans doute le dernier des protocoles majeurs a devenir compatible avec l’IPv6.

Le bon coté des choses est que les utilisateurs ne verront pas la différence lorsqu’ils utiliseront IPv6. IPv6 est supporté par l’ensemble des acteurs majeurs d’internet, y compris les par les navigateurs Web. Et même si il reste de petits problèmes, comme indiqué ci-dessus pour les sites web IPv6 faisant appel à des contenus hébergés sur des serveurs en IPv4, la plus grande partie du web ne posera aucun soucis en IPv6.

Pour les applications plus anciennes et les utilisateurs comme les développeurs qui ont besoin d’utiliser de nombreuses adresses IPv4 il n’y a rien à craindre non plus. IPv6 est un nouveau protocole : il ne modifie en rien le fonctionnement d’IPv4 et les deux vont pouvoir tourner en parallèle jusqu’à ce que les administrateurs réseau décident de désactiver l’IPv4 … très certainement dans plusieurs décennies.

IPv6 est à notre porte, et il est prudent (essentiel) de s’y préparer dès maintenant. Dans cet optique, il est essentiel de disposer des outils temps-réels, comme OmniPeek, qui permettrons de comprendre et résoudre rapidement tout les problèmes rencontré lors de la transition.

•  •

Librement inspiré de l’article Common Deployment Pains with IPv6: How to Identify and Fix Them 

Sniffer le wifi, quelques règles de bases 25 juin 2012

Posted by frnetworker in Diagnostic Réseau, OmniPeek, Wireless.
Tags: , , , , , , , , , , , , , ,
add a comment

Analyse et capture des trames sur les réseaux sans fil

Réaliser une capture de bonne qualité du signal des réseaux wireless à des fins d’analyse et de diagnostic peut être une opération complexe et longue.

Vous devez conserver à l’esprit quelques points clés qui rendrons cette opération plus simple et surtout vous feront gagner du temps.

En fait vous devez capturer l’ensemble des données qui transitent sans fil dans votre environnement. Voici 7 règles basiques pour parvenir à vos fins.

7 points essentiels à mémoriser pour une capture rapide et efficace

Positionner le sniffer correctement

Dans la mesure ou l’analyseur réseau, OmniPeek par exemple, doit capturer les signaux radio générés par l’Access Point (AP ou Borne Wifi) et par le poste utilisateur, il vous sera utile de vous positionner aussi près que possible du poste utilisateur. Cela permettra à OmniPeek de vous donner un aperçu aussi réaliste que possible de ce que reçoit et émet le poste utilisateur. (= le sniffer et le poste utilisateur vont recevoir un signal radio identique, incluant les mêmes perturbations)

Le sniffer doit sniffer

Il faut éviter d’installer le logiciel de capture wifi sur le poste qui réalise les manipulations de test (le poste utilisateur dont vous essayez de capturer une trace) car la capture sera altérée. (Au pire utilisez OmniPeek mais avec un second adaptateur wifi)

Identifiez le canal et la fréquence du poste utilisateur avant la capture

Pensez à verrouiller OmniPeek sur la fréquence qu’utilise le poste utilisateur lorsque vous paramètrez votre capture. N’utilisez surtout pas le mode « Scan Channels ». (En mode scanner, le sniffer va continuellement passé d’un canal à un autre ce qui peut être très utilise pour par exemple identifier des connexions pirates mais ne sera d’aucune utilité pour le diagnostic).

Rappelez-vous également que le poste utilisateur peut se déplacer et utilisera alors les fonctions de roaming ( itinérance ). Dans ce cas, vous serez plus efficace en utilisant plusieurs adaptateurs wifi sur OmniPeek et en attribuant un canal à chaque adaptateur : Vous pourrez suivre les transmissions de l’utilisateur, y compris les paquets de liées au changement d’AP et de canal. Typiquement, dans un environnement 802.11b/g (2,4Ghz), vous pourrez être  amenés à analyser 3 canaux différents (NDLR : donc avec 3 adaptateurs wifi différents) en positionnant chacun d’eux sur les canaux 1, 6 et 11 qui sont les plus souvent utilisés en entreprise. (Les clés Wifi USB vous seront d’un grand secours pour ce type de configuration).

Limitez le nombre de canaux analysés si vous utilisez la fréquence 5Ghz

Si vous réalisez vos diagnostics sur un réseau sans fil utilisant la fréquence 5Ghz, le nombre de canaux possibles est beaucoup plus important et vous risquez fort de ne pas disposer du nombre d’adaptateurs wifi suffisants. Une bonne pratique consiste à se limiter à 4 canaux.

En cas d’itinérance ( roaming )

Si vous arrivez à reproduire le problème que rencontre l’utilisateur lors du roaming, alors l’analyse de 2 canaux seront suffisant (celui de départ et celui d’arrivée).

Si vous ne disposiez que d’un seul adapteur wifi (=vous ne pouvez capturer qu’un seul canal) placez-vous de préférence sur le second (celui d’arrivée), car il est probable que c’est sur ce dernier que surviennent les soucis.

Si vous utilisez plusieurs Sniffers dictincts

Si vous utilisez plusieurs postes sniffer, pensez à synchroniser les horloges de ces ordinateurs (et celui de l’utilisateur) avec le même serveur NTP.

Cela facilitera la corrélation des traces. Évidement si vous utilisez OmniPeek avec de multiples adaptateurs wifi, l’horodatage sera identique sur toutes les captures. (OmniPeek permet de fusionner les captures de différents canaux dans une seule trace).

Pour les captures de longue durée

Si vous deviez capturer des données sur de longues périodes, pensez à configurer votre sniffer pour lancer une nouvelle capture (NDLR : et enregistrer l’ancienne) périodiquement afin de disposer de fichier trace de taille raisonnable pour la post-analyse. OmniPeek peut utiliser des Triggers Events pour démarrer et arrêter la capture, par exemple début de la capture quand le protocole SIP est utilisé par l’IP 192.168.1.1 ce qui permet de capturer moins de données et surtout d’être sur de ne pas rater la capture de l’essentiel

•  •

Librement inspiré de l’article Fondamentals of Wireless Sniffig

Lenteurs, le réseau est il fautif ? réponse immédiate avec OmniPeek ! 1 mai 2012

Posted by frnetworker in OmniPeek.
Tags: , , , , , , , , ,
add a comment

En tant qu’administrateur réseau, nous sommes souvent confronté aux utilisateurs qui se plaignent, souvent à juste titre, des lenteurs du système d’information.

Habituellement c’est le réseau qui est montré du doigt par les utilisateurs, mais ce n’est pas toujours le cas !

C’est notre rôle de déterminer comment diminuer les temps de réponse, mais où doit on agir ? Quelle est l’origine des lenteurs ? s’agit t’il de lenteurs réseau ou de lenteurs liées au serveur et à ses applications ?

Les heureux propriétaires d’OmniPeek vont connaitre la réponse en quelques instant avec l’aide de l’utilisateur concerné !

Mettre en oeuvre une capture

  1. Positionnez OmniPeek pour capturer les données du réseau au niveau du poste utilisateur,
  2. Créez un filtre avec l’adresse IP de l’utilisateur pour vous concentrer sur son trafic et lancez la capture,
  3. Demandez à l’utilisateur d’utiliser ses applicatifs comme il le fait au quotidien.

Afficher les informations de diagnostique

OmniPeek affiche les informations permettant un diagnostique immédiat des lenteurs dans les fenêtres Event Summary et Visual Expert.

Event Summary

OmniPeek détecte pour vous les anomalies de fonctionnement du réseau grâce au système expert.

Le système expert d'OmniPeek lui permet de relever les erreurs réseau …

OmniPeek enregistre les anomalies réseau dans l'onglet Event Summary

Visual Expert

OmniPeek permet également de visualiser les temps de réponses des applications dans l’onglet Visual Expert.

La séquence des paquets et le délai de réponse permettent à l'administrateur de connaitre avec précision l'origine du problème.

OmniPeek trace les latences réseau ou applicatives dans le fenêtre Visual Expert

Dans le cas de cette seconde copie d’écran, les paquets d’accusés de réception (ACK) parviennent rapidement, vous avez donc la certitude que le problème provient du serveur ou de ses applications et que votre réseau est clean !

C’est des nombreuses raisons pour laquelle OmniPeek permet aux administrateurs de réaliser un travail de haute qualité.

Essayer Gratuitement OmniPeek Maintenant

OmniPeek est distribué en France par NetWalker.
Informations et Tarifs 

Prêt pour l’analyse et le diagnostic 10 Gigabit Ethernet ? 18 juin 2010

Posted by frnetworker in Diagnostic Réseau, OmniPeek.
Tags: , , , , , , , ,
add a comment

Avec la baisse du coût d’acquisition des équipements 10 GbE, son adoption est de plus en plus fréquente … mais le challenge de l’analyse des flux sur réseaux 10 GbE reste entier, probablement parce que l’industrie n’a pas encore défini de méthodologie pour l’analyse de tels segments. La capture et l’analyse 10 GbE sont pourtant déjà possibles avec OmniPeek et l’OmniAdapter 10 GbE …

OmniAdapter 10 gigabits ethernet

Carte de capture 10 GbE 2 ports PCI-E

Voici les six questions à vous poser pour savoir si vous êtes déjà prêt à réaliser des diagnostics sur vos réseaux 10 Gigabits ethernet.

1. Êtes-vous assez précis ?

Il est crucial de savoir précisément ce que vous souhaitez capturer et quelles informations vont vous fournir les détails essentiels pour votre diagnostic.

La meilleure stratégie d’analyse des segments 10 GbE, surtout si le trafic est conséquent, est d’avoir recours à l’analyse post-capture et de ne réaliser que la capture et l’enregistrement sur disque en temps-réel.

Essayer de capturer et d’analyser en même temps sur des segments chargés sollicitera bien d’avantage votre système que si vous réalisez l’analyse en deux étapes.

2. Connaissez-vous avec précision votre réseau ?

Savoir ce que vous êtes en droit d’attendre de votre réseau est essentiel pour l’analyse des segments 10 GbE chargés.

Si vous êtes déjà lancé dans une analyse complexe d’un problème qui ne l’est pas moins, par exemple extinction d’incendie à la Red Adair (le pompier volant) … il est déjà bien trop tard pour déterminer quelles sont les conditions de fonctionnement ‘normale’ de votre réseau.

Comment établir un référentiel du fonctionnement standard de votre réseau ?

Nous vous conseillons d’enregistrer, d’analyser et d’archiver des mesures sur un protocole spécifique comme HTTP sur des périodes d’une heure, d’un jour et d’une semaine et ce pour l’ensemble de votre réseau.

Faites de même pour les protocoles de vos applications critiques pendant des opérations typiques

Les autres paramètres qui entrent en considération au fil du temps sont :

  • la répartition des tailles de paquets,
  • l’utilisation par protocole,
  • l’utilisation par poste

La connaissance de ces cycles vous fournira un solide référentiel de votre utilisation standard. Ce sera en quelque sorte la marque de fabrique de votre réseau.

De la sorte, vous disposerez toujours d’une comparaison pertinente lorsque des problèmes surviendront.

Et c’est seulement en possession de ces données que vous pourrez vous lancer dans une analyse détaillée et plonger jusqu’aux arcanes des paquets.

3. Restez-vous concentré sur l’essentiel ?

La tentation est forte de capturer et d’analyser l’ensemble du trafic, surtout dans la mesure où l’origine du problème est inconnue.

Mais le plus souvent certaines causes peuvent être immédiatement écartées ce qui permet de se limiter à la capture et l’analyse de l’essentiel.

Vous avez aussi la possibilité de désactiver certains modules sans grand intérêt pour le diagnostic en cours.

Par exemple, le module d’analyse du Wifi peut être désactivé sans hésiter lors de l’analyse du 10 GbE. Vous devez personnaliser les réglages en fonction de vos buts et de votre activité du moment.

4. Connaissez-vous vos limites ?

Même si l’analyse 10 GbE est limitée à quelques segments de votre infrastructure, capturer des données sur ces réseaux produit très rapidement des quantités énormes de données à analyser.

Ce qui deviendra rapidement une tâche Herculéenne même si l’on écarte les problèmes de performances de la station de capture des paquets et que l’on utilise la méthode Capture puis Post-Analyse.

En fait, il faut trouver le juste équilibre entre 2 problématiques antinomiques :

  • La taille des fichiers de données,
  • La fréquence de sauvegarde sur les disques.

L’intuition pourrait vous laisser penser que plus les fichiers sont volumineux mieux c’est … ce qui n’est pourtant pas le cas !

De gros fichiers réclament bien plus de mémoire lors de leur manipulation. Si les fichiers sont énormes, ils vont être inutilisables car votre pc va littéralement ramer faute de mémoire vive.

A l’opposé, de plus petits fichiers qui demandent des accès (en écriture) plus fréquents aux disques durs peuvent consommer d’avantage de ressources pendant la capture.

Les performances optimales sont donc obtenues par un compromis entre ces 2 contraintes qui dépendent en grande partie des ressources (mémoire, disque dur, processeur) du poste d’analyse.

Une règle simple à conserver en mémoire : si des fichiers sont créés toutes les 30 secondes (ou moins) cela va impacter l’efficacité du taux de capture de manière significative.

Utiliser des tailles de buffers et de fichiers adaptés peut faire toute la différence.

Nous recommandons de démarrer avec 256 Mb de buffers de capture et de fixer la taille des fichiers à 128 Mb.

Après quelques captures vous allez rapidement déterminer quel paramètre doit être ajusté en fonction des capacités de votre matériel.

Essayez également d’utiliser le moins grand nombre possible de captures simultanées. Bien sûr les logiciels d’analyse vous permettent pour la plupart un nombre illimité de captures mais vous devez garder en mémoire que chaque capture supplémentaire consomme des ressources supplémentaires.

5. Filtrez-vous ?

Le filtrage basé sur des critères spécifiques de l’utilisateur est un moyen efficace de limiter le nombre de paquets capturés et archivés.

Tronquer les paquets (Slicing) vous permet aussi de minimiser la quantité de données à traiter mais cela n’est valable que si vous vous intéressez uniquement aux entêtes de paquets car toute reconstruction de transaction est alors rendue impossible.

Ces deux techniques permettent de réduire le volume de données à traiter et stocker ce qui libère d’autant la puissance de l’ordinateur pour la capture et l’espace disque.

6. Êtes-vous raisonnable ?

OmniPeek permet la connexion distante de multiples utilisateurs à l’appliance qui réalise les captures critiques et l’analyse temps-réel.

Fixez une limite au nombre d’utilisateurs concurrents.

Nommez un responsable pour chaque système de capture qui supervisera les filtres et les captures avec éventuellement la possibilité de stopper certaines captures en cas de nécessité.

Trop d’utilisateurs avec trop de prérogatives n’apportera que des inconvénients.

Vous pourrez toujours assouplir les règles en cas de besoin.

•    •

Librement inspiré du blog de l’éditeur WildPackets par NetWalker, distributeur pour la France.

L’itinérance Wifi et ses effets sur la qualité du réseau 30 mai 2010

Posted by frnetworker in Diagnostic Réseau, OmniPeek.
Tags: , , , , , , , , ,
1 comment so far

Le roaming (ou itinérance) c’est lorsqu’un utilisateur du réseau wifi se déplace hors du champ couvert par un des points d’accès pour entrer dans celui d’un autre. Le roaming permet donc à l’utilisateur de se déplacer sur un site tout en restant connecté au réseau. Cependant le roaming est l’une des principales causes de problèmes que rencontrent les utilisateurs sur les réseaux sans fils. Des temps de roaming trop élevés entrainent une mauvaise qualité réseau pour les utilisateurs de voix ou de vidéo sur IP et provoquent des pertes de connexions ou de données.

Le roaming  provoque le plus souvent un changement de canal, mais cela dépend de la technologie utilisée. Dans le cas d’une architecture multi-canal, la plus fréquente, un changement de canal est nécessaire. Dans un tel cas, le poste client (ordinateur, téléphone …) doit être ré-authentifié et ré-associé avec le nouveau point d’accès, ce qui prend le plus souvent de l’ordre de 150 millisecondes surtout si des fonctions avancées comme le WPA2 et WMM sont actives. La plupart des réseaux sans fils sont constitués de plusieurs points d’accès (AP) et les utilisateurs font l’expérience d’un signal de faible puissance malgré une couverture wifi convenable lorsque  le ‘client’ est/reste connecté à la mauvaise AP. Même dans les architectures les plus récentes, les systèmes de gestion centralisée, le ‘client’ wifi décide seul quand il bascule d’un AP à l’autre. Cette décision est basée sur l’évaluation de la force du signal et est réalisée par le pilote qui contrôle l’accès radio. Ce pilote logiciel est différent d’un constructeur à l’autre et d’un matériel à l’autre, de sorte que la décision de faire appel au roaming se fait de manière extrêmement variable. Le plus souvent, le client sans fil va attendre trop longtemps l’affaiblissement du signal avant de basculer sur une autre AP avec un meilleur signal.

De nouveaux standards sont disponibles et définissent les conditions pour un roaming rapide (fast roaming) permettant des basculements qui prennent seulement 5 à 10 millisecondes. Ces spécifications incluent :

  • 802.11i – Mécanisme de caching de clé ne nécessitant pas de ré-authentification (plus connu sous le sigle WPA2)
  • 802.11r – Défini un mode d’itinérance pour les communications VoIP permettant de passer d’un point d’accès à un autre de manière très rapide.
  • 802.11k – Permet l’optimisation d’allocation des ressources du réseau sans fil selon la qualité de chaque liaison.

Ces nouveaux standards (le 802.11i n’est pas nouveau mais fait partie intégrante des améliorations pour le roaming) permettent aux AP un meilleur contrôle pour déterminer quand un basculement doit être effectué et les autorisent à tenir compte des performances actuelles et des demandes des réseaux wifi.

Le problème vient d’une adoption très lente des normes 11k et 11r principalement sur les  clients Wifi … et tant que ces normes n’auront pas été adoptées en masse, les clients continueront à souffrir des transitions trop lentes provoquant de piètres performances en VoIP et Video over IP.

Dans l’intervalle, la meilleure approche est de superviser et d’analyser l’activité liée à l’itinérance sur le réseau. Disposer d’une vision complète et pertinente nécessite l’agrégation temps-réel des données de multiples canaux et AP avec une analyse détaillée (automatique) qui fournit des rapports détaillés. Qui se déplace ? Combien de temps prend chaque évènement ? et quelle est l’efficacité de chacune des AP ? Si le rapport donne une vue claire de la situation, son établissement est un processus complexe qui démontre que des outils d’analyse pertinents de réseau sont essentiels pour rester productifs.

OmniPeek Network Analyzer est l’un des outils qui permet aux administrateurs de mener leur tâche critique.

Librement inspiré du blog de l’éditeur WildPackets par NetWalker, distributeur pour la France.

Trois points clés pour déterminer si la latence est causée par le réseau ou par les applications. 11 mars 2010

Posted by frnetworker in Diagnostic Réseau, InterMapper, OmniPeek.
Tags: , , , ,
add a comment

Le réseau est le support d’un large spectre d’applications, depuis les plus simples hébergées en local comme l’email à des applications plus complexes utilisant de multiples serveurs ou encore des applications dépendantes des temps de réponses comme la VoIP. Lorsque le trafic de telles applications transite au travers de data centres, la tendance à atteindre les limites rend les latences du réseau encore plus pénalisantes. Identifier puis corriger les ralentissements devient rapidement une nécessité et peut parfois relever de l’exploit !

Mais dans ces conditions, qui est responsable de ces temps de réponses déplorables pour les utilisateurs  ? L’application elle-même ou le réseau ?

En premier lieu, nous devons définir les deux types de latence possibles réseau ou applicatif.

La latence réseau est le temps nécessaire à l’application pour envoyer une requête et à l’applicatif (sur le serveur) pour renvoyer l’accusé de réception de la requête. (Un message est renvoyé au travers TCP pour accuser la bonne réception du paquet de requête).

La latence applicative est le temps nécessaire de l’application pour traiter la requête et renvoyer les données de la réponse. C’est cette latence, mesurée par l’indice Apdex, qui permet une estimation du taux de satisfaction des utilisateurs applicatif par applicatif.

La plupart des logiciels d’analyse réseau proposent quelques outils de mesure des temps de latence mais dans la plupart du temps et à la différence d’OmniPeek, ils ne permettent pas de différencier l’origine des latences.

Voici les trois points qui vous permettront de connaitre la source de la latence : Réseau ou Applicatif et parfois même les deux à la fois.

  1. Faire la part des choses : latence réseau versus latence applicatif
    C’est bien connu, tous les problèmes des applications sont dus à des dysfonctionnements du réseau!  « Coupable tant que pas prouvé innocent ! »

    Dès lors, mesurer avec précision la latence réseau et celle des applicatifs est la preuve de la compétence et de l’impartialité des ingénieurs réseau. L’analyse des paquets est idéale pour se rendre à l’évidence. L’échange de paquets lors d’une conversation entre un poste client et une application (sur un serveur) permet de visualiser si le réseau est la source des latences constatées ou si l’application est le point de congestion. Pour cela, il suffit de comparer le temps de réponse nécessaire à l’envoi du paquet d’accusé de réception de la requête (latence réseau) et le temps de réponse nécessaire à l’envoi des informations résultant de la requête (latence applicative). Le plus souvent, l’accusé de réception est renvoyé très rapidement (quelques millisecondes) tandis que la réponse de l’application elle-même nécessite plusieurs secondes. Si c’est ce que vous constatez vous aussi, c’est que l’application  est la cause de la latence.
  2. Evaluer périodiquement les applications clés et la réactivité du réseau
    Investir dans une analyse régulière préventive des éléments clés est le meilleur outil pour détecter rapidement toute dégradation de performances. Même si cette technique ne contrôle que le temps de réponse (de latence) réseau, elle fournit des informations indispensables pour déterminer l’origine d’une dégradation des temps de réponse. Par exemple, lancer une série de Ping à intervalles réguliers à votre application de CRM peut fournir une base de mesures de référence objective des variations de performances pour les utilisateurs. (NDLR : il est évidement plus simple d’utiliser un logiciel comme InterMapper pour réaliser cet étalonnage de manière permanente et automatique). Si les valeurs commencent à augmenter, c’est que le temps de réponse du réseau est en passe de devenir problématique rapidement. Si les utilisateurs se plaignent des temps de réponse sans que votre échantillon ne montre de modification de la latence des pings, alors c’est l’applicatif lui-même (ou le serveur qui l’héberge) qui est à incriminer.
  3. Conserver des graphes de l’évolution des temps de réponse dans le temps
    Grapher le temps de réponse dans le temps, c’est disposer d’un référentiel indispensable pour détecter les variations qui nécessitent votre attention.La supervision des temps de latence vous permet de corréler  les variations avec d’autres statistiques comme par exemple la charge réseau au même moment. Ce type de monitoring (d’analyse préventive) est essentiel pour détecter au plus tôt les problèmes afin de se focaliser sur leur origine.Dans l’idéal, les temps de latence du réseau et des applications devraient être graphés en parallèle au fil du temps. La fluctuation des courbes (relative et absolue) sera toujours riche d’enseignement.Le monitoring des temps de réponse peut inclure la mise en place de seuils d’alertes automatisés. Cela permet aux ingénieurs d’intervenir sur un problème de latence réseau avant même que les performances de l’applicatif  n’en souffre, au plus grand bénéfice des utilisateurs.

Cet article est librement inspiré du blog de l’éditeur WildPackets par NetWalker

Votre nouvelle application est elle une tueuse de réseau ? 9 mars 2010

Posted by frnetworker in Diagnostic Réseau, OmniPeek.
Tags: , , , ,
add a comment

Lorsqu’une nouvelle application est déployée sur votre réseau, les ingénieurs doivent être en mesure de prédire avec précision comment elle va se comporter et surtout garantir que les autres applications critiques ne seront pas pénalisées.

OmniPeek avec les fonctionnalités d’Analyse des performances du réseau (Network Performance Analysis) vous permet de déterminer immédiatement le comportement de nouvelles applications sur le réseau et l’impact éventuel sur les applications existantes.

Il existe trois signaux d’alerte indiquant qu’une nouvelle application ne fonctionne pas aussi bien qu’elle le devrait sur le réseau ou qu’elle dégrade les performances d’autres applications critiques.

  1. Les performances en production diffèrent de celles obtenues lors des tests préliminaires
    Les tests préliminaires peuvent prendre des formes diverses, depuis quelques simulations basiques à la simulation grandeur nature d’une session de travail réel. Mais la seconde approche peut être complexe à mettre en oeuvre et consommatrice de temps ! Il est pourtant simple d’obtenir une estimation précise grâce à OmniPeek. En installant l’application et en capturant les transactions représentatives d’une utilisation standard de l’application, la fonction ‘What If’ (Que se passerait il si …) permet de connaitre l’impact réseau réel en fonction du nombre d’utilisateurs prévus en production. Qui plus est, cela permet d’étalonner la charge induite, le comportement de l’application et de traquer toute variation lors de la mise en route finale de l’application.
  2. Les fondamentaux du réseau changent dramatiquement après le déploiement
    Sans étalonnage préalable des performances et du comportement ‘usuel’ du réseau les équipes travaillent à  l’aveugle à la fois lors du déploiement d’une nouvelle application mais aussi au jour le jour. Un échantillonnage doit inclure des statistiques sur une période suffisamment longue (une semaine par exemple) des points clés du réseau : nœuds, protocoles,  applications au cours du temps et une estimation du seuil de décrochage du réseau, typiquement le nombre de paquets perdus, de retransmissions, les temps de réponse des applications clés. Après le déploiement d’une nouvelle application (et comme pré-requis lors des phases préliminaires) un nouvel échantillonnage doit être réalisé et comparé point par point afin de détecter et de remédier à toute variation inattendue. Cette fonction est disponible en natif dans OmniPeek afin de faciliter la comparaison.
  3. Une modification du « pouls » du réseau
    La bonne santé du réseau tient à son seuil de tolérance au « bruit », mais les modifications de sa santé doivent être perçues au plus vite. OmniPeek analyse en permanence tous les signes vitaux en réalisant une expertise en tâche de fond et prévient quand ces indicateurs commencent à varier. Par exemple, lors de l’installation d’une nouvelle application, si OmniPeek détecte trop de retransmission TCP (‘Too many TCP retransmissions’) c’est un signe fort indiquant que cette nouvelle application a rompu l’équilibre du réseau.

Quelque soit la méthode retenue pour analyser les répercussions d’une nouvelle application sur le réseau, l’applicatif permettant de mesure et contrôler les performances devrait au minimum :

  1. Fournir des informations détaillées sur les sept niveaux du modèle OSI.
  2. Permettre la capture de données sur une période relativement longue (une semaine par exemple) pour établir un échantillonnage de référence.
  3. Identifier rapidement et localiser les points de stress réseau.
  4. Permettre de modéliser l’impact du trafic en fonction des données collectées lors d’une simulation.

Cet article est librement inspiré du blog de l’éditeur WildPackets par NetWalker

%d blogueurs aiment cette page :