jump to navigation

Votre entreprise envoie-t’elle des spams ? En cas de doute … 10 mai 2011

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

Une des grandes problématiques pour les administrateurs réseau est de pouvoir contrôler et vérifier le fonctionnement du réseau et la bonne application de la politique de sécurité de l’entreprise.

Votre serveur de mails vous fournit probablement des outils permettant d’empêcher ou de limiter l’envoi de spams depuis votre entreprise … mais avez vous vérifié que d’autres ordinateurs n’envoient pas, volontairement ou non, des mails directement ?

OmniPeek fournit aux ingénieurs la possibilité de capturer et d’analyser le trafic. Voyons comment la mise en place d’un filtre permet d’automatiser le contrôle.

Ce filtre va vous permettre de détecter simplement les adresses IP des postes qui envoient des emails via SMTP hors de votre entreprise.

Dans un premier temps, il vous faut positionner l’analyseur au niveau de votre routeur internet (sur votre LAN). Plusieurs techniques existent entre la mise en place d’un TAP* et le port mirroring**.

Puis, il vous suffira de créer un filtre nommé « Contrôle SMTP*** ».

Ce filtre doit comporter 2 instructions :

  1. Tous les paquets SMTP
  2. Sauf les paquets adressés ou reçus par votre serveur de mail.

Il suffit alors soit :

  • De lancer une capture avec le filtre actif,
  • D’appliquer le filtre à une capture déjà réalisée,
  • D’utiliser ce filtre comme trigger (déclancheur) de capture en laissant l’analyseur ‘à l’affût’

Voyons par le détail la mise en place du filtre :

Ajouter un nouveau filtre

Cliquer sur le bouton Insert

Cliquer alors sur le bouton Protocole… pour aller sélectionner SMTP

Sélectionner le protocole SMTP

Sélectionner le protocole SMTP

Indiquer ensuite l’adresse IP (ou le nom) de votre serveur de Mails

Indiquer l'adresse ou le nom du serveur de Mail

Indiquer l'adresse ou le nom du serveur de Mail

En l’état, le filtre ne capturera que les paquets SMTP du serveur de mail, ce qui n’est pas le but recherché, il faut donc switcher en mode ‘Filtres avancés’ afin d’indiquer à OmniPeek ‘Sauf cette adresse’.

Sélectionner les filtres Avancés

Sélectionner les filtres Avancés : Passer de Simple à Advanced

Cliquer droit sur la case qui représente l’adresse IP (ou le nom) du serveur de mails et ajouter NOT

Ajouter NOT pour ignorer les trames du serveur de mails

Ajouter NOT pour ignorer les trames du serveur de mails

Bravo, votre filtre est prêt !

Filtre SNMP opérationnel

Le filtre est prêt à l'usage, il suffit alors de lancer une capture

Une fois la capture lancée, il suffit de se rendre dans l’onglet Nodes … Tout ordinateur qui apparaitra sera ‘fautif’ puisqu’il enverra des mails hors de l’entreprise sans que vous en soyez informé.

A vous de terminer l’enquête …

OmniPeek est un puissant outil d’analyse et de diagnostic de réseau dont NetWalker assure la distribution en France.


* Tap : dispositif de réplication passif du signal réseau.
** les avantages et inconvénients des deux solutions sont présentés ici : Port Mirroring ou Taps
*** SMTP : Simple Mail Transfert Protocole
Publicités

Diagnostic Wifi ? Mais où doit se porter l’analyse de trames ? 13 décembre 2010

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

« Dois-je capturer au niveau du réseau sans-fil ou sur le réseau ethernet filaire »
La réponse dépend essentiellement du type de problèmes rencontrés et du mode d’investigation.

Graphe d'une connexion wifi

Où capturer pour réaliser le diagnostic du problème utilisateur ?

Dans ce billet, nous nous attacherons plus spécifiquement aux problèmes de connectivité wireless.

Commençons donc par le commencement : la connexion de l’utilisateur au réseau WLAN. Cela a l’air tout bête, mais c’est l’un des problèmes les plus fréquents !

La capture sur le réseau sans fil vous permet elle de localiser des paquets provenant du client wireless ?

Au minimum le poste client envoie des paquets « probe request » pour rechercher un AP (Access Point ou borne wifi). Si vous ne voyez aucun paquet « probe request », il est clair que le problème vient directement du poste client et c’est le plus souvent un problème de configuration. Il vous reste à vous rendre sur le poste utilisateur. (1)

Si par contre l’utilisateur est « visible », entendez par là qu’il envoie des paquets « probe request », l’analyse du trafic wifi doit se poursuivre : il faut maintenant s’intéresser aux paquets de management 802.11 relatifs à l’établissement de la connexion entre le poste client (le client) et l’AP. Cela englobe les paquets de type « Associations Request » et ceux « d’Authentification ».

Le poste utilisateur doit nécessairement émettre des paquets de type « Association Request », « Association Response » et « Disassociation ». (Au besoin créer un filtre sur l’adresse IP de l’utilisateur pour limiter la capture à ces paquets) Dans ce cas, une vérification des configurations à la fois sur le poste client et sur l’AP est nécessaire. C’est le plus souvent une erreur de configuration qui est à l’origine du problème. (2)

Lorsque que l’association entre la borne (AP) et le client est réalisée, l’authentification doit être contrôlée.

Le nombre de paquets échangés durant la phase d’authentification dépend du type d’authentification utilisée et augmente selon que le réseau wifi est ouvert ou protégé en WPA2.

Dans tous les cas, l’analyse sur le segment sans-fil du réseau est le point de départ.

Si l’authentification échoue, l’analyse des trames d’authentification permettra de déterminer si la demande d’authentification est refusée et pour quelle raison.

 

 

 

 

 

Payload dans OmniPeek

l'onglet Payload permet de visualiser une conversation en détail !

 

A ce point, l’analyse sur le réseau filaire peut-être nécessaire : la plupart des AP communiquent avec un serveur d’authentification via le réseau filaire. OmniPeek peut réaliser l’analyse en simultanée des réseaux Wifi et filaire. (3)

Si l’analyse wifi indique des échanges de paquets convenables, la cause du problème se trouve sur la partie câblée du réseau. Typiquement il peut s’agir d’un problème matériel ou de routage incorrect entre l’AP et le serveur d’authentification, d’un problème de configuration discordante entre les deux, d’une authentification incomplète, ou tout simplement d’absence de réponse du serveur d’authentification.

Même si c’est un cas fréquent, ce n’est qu’un des problèmes possibles que l’on peut retrouver sur les WLANs.

Dans de prochain billets nous nous concentrerons sur la meilleure approche de capture des données pour résoudre le problème qu’il soit « dans les airs ou sur le fil ».

Librement inspiré du blog de l’éditeur par NetWalker distributeur de la solution OmniPeek en France.

Voir également la vidéo sur le site de l’éditeur : Utiliser les AP Cisco pour la capture et le diagnostic du réseau et des problèmes de Roaming : Cisco AP Grabber

Lenteurs réseau, lenteurs applications ou lenteurs serveurs ? 5 novembre 2010

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

La principale cause de stress pour les administrateurs du réseau …

… c’est lorsque « le réseau est lent ! »


Nous avions publié dernièrement quelques éléments de réflexion pour vous aider à déterminer la cause des lenteurs réseau. Depuis, la discussion n’a fait qu’amplifier :

Qui est vraiment responsable des lenteurs ? Le réseau, les applications ou les serveurs ?

Cette difficulté est bien souvent la cause d’une réelle animosité dans certaines entreprises entre les développeurs, les administrateurs système, les administrateurs réseau et les utilisateurs.

Même si les baisses de performances doivent être étudiées en détail pour chaque entreprise, il est toutefois possible d’identifier quatre raisons principales :


Charge globale du réseau

La charge du réseau est un ratio entre le trafic qui transite actuellement  sur un port et le trafic maximum qui peut y transiter.

Le dépassement d’un certain seuil de charge a pour conséquence la baisse de la vitesse de transmission ou des retransmissions et l’augmentation des temps de réponse, soit, en d’autres mots le ralentissement du réseau !

La montée en charge du réseau peut provenir de nombreuses causes dont le comportement des utilisateurs à l’égard de la musique, des téléchargements ou du streaming de vidéos.


Trafic inutile

Tous les réseaux véhiculent du trafic inutile ! Certains périphériques (les imprimantes en particuliers) utilisent de nombreux protocoles qui ne sont pas nécessaires dans votre environnement.

Souvent aussi, les réseaux Wifi ne sont pas filtrés et il n’est pas rare de voir passer sur ces segments des flux de trafic de management (Routing Protocole, SNMP …) qui grignotent de la bande passante sans aucun bénéfice.


Santé du réseau (en terme de tempêtes de broadcast)

Dans la mesure où les réseaux sont dynamiques, il est essentiel que les entreprises contrôlent régulièrement leur réseau. Il faut vérifier que les processus et que les périphériques font bien ce qu’ils sont censés faire et que le comportement général du réseau ne change pas.

Il est essentiel d’identifier rapidement les nouvelles tendances et de réaliser les modifications idoines pour prendre en compte ces modifications comportementales. Faute de quoi, les entreprises s’exposent à des tempêtes de broadcast qui surviennent lorsque des broadcasts ou des multicasts constants asphyxient littéralement le réseau.


Applications et besoins ‘locaux’

Chaque entreprise a ses besoins propres. En fait, chaque segment réseau peut avoir des comportements différents en fonction des applications spécifiques qui y transitent.

L’application la plus utilisée par les services commerciaux sera différente de celle utilisée par les services de R & D.

Les besoins en bande passante des principales applications de chaque service de l’entreprise doivent être connus.

Il faut dès lors s’assurer que lorsque ces flux transitent sur les mêmes segments réseau (au niveau du datacenter par exemple) la bande passante disponible est suffisante !

C’est d’ailleurs l’une des principales raisons qui motive les investissements réseau.

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

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.

Analyse de la VoFI : Mettre en place la supervision, l’analyse et le diagnostic 8 juin 2010

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

La VoIP mobile (ou VoFI) s’installe dans les entreprises. La société  In-Stat anticipe 171 millions d’utilisateurs aux alentours de 2013 avec des revenus estimés à 10 milliards de dollars. Concentrons-nous sur la supervision, l’analyse et le diagnostic de la VoIP sur Wifi. (VoFI)

Avant d’être effrayés, prenez une bonne respiration ! Analyser le trafic VoFI revient à peu de chose près à analyser le trafic VoIP. Souvenez-vous seulement que le WIFI rend plus sensible des problèmes comme la gigue, la latence et la perte de paquets.

Remontons à la source : les appels de vos utilisateurs !

Lorsque des problèmes surviennent avec des applications VoIP ou VoFI, le point de départ est toujours le même : Avant même de vous précipiter sur vos statistiques ou vos captures prenez le temps d’écouter les appels significatifs afin de vous rendre compte par vous-même de ce que les utilisateurs ont vécu.

Votre oreille vous indiquera les signes de latence excessive, gigue ou perte de paquets.

Le plus simple est de  vous assurer que votre solution d’analyse VoIP vous permet le playback des appels téléphoniques et plus spécialement des flux RTP individuellement ainsi que de l’ensemble d’une conversation.

Sans cette ré-écoute, vous perdrez probablement des heures à pister l’origine des problèmes sur le réseau ou dans l’application alors qu’il s’agissait d’un simple problème de casque défectueux sur le poste de l’utilisateur !


Prendre le pouls de votre réseau !

Une fois que vous avez écouté l’appel, vous pouvez alors contrôler ce qui se passe sur le réseau.

Synthèse de la qualité VoIP sur votre réseau avec OmniPeek

Synthèse de la qualité VoIP sur votre réseau

Vous visualisez immédiatement ce que vous avez entendu ! La qualité de l’appel était déplorable (poor). (la barre orange sur le graphe).

Entrer dans les détails

Le système expert vous permet de vérifier ce que vos oreilles vous avaient littéralement ‘laissé entendre’ :

Synthèse des évènements réseau

Synthèse des évènements réseau

Durant cet appel, il y a eu une grande quantité d’erreurs physiques : paquets arrivés en retard, ré-émission, paquets dé-séquencés, pertes de paquets, trop de gigue …

La cause ayant été rapidement identifiée, vous allez être en mesure de régler le problème.

En visualisant l’appel dans sa globalité, vous constatez que l’appel s’est clôturé avec une fin ‘normale’ dans le sens ou l’appel n’a pas été coupé. Quel Codec a été utilisé, quelle longueur, quel était son score ?

Statistique des appels VoIP & VoFI

Statistique des appels VoIP & VoFI

Dans cet exemple, le score d’évaluation était de 2,5 ce qui confirme la mauvaise qualité de l’appel.

La vue par média (Media view) vous permettra de déterminer pourquoi la qualité était si déplorable.

Détails des appels, R-factor, Mean Opinion Score, Pourcentage de paquets perdus …

Détails des appels, R-factor, Mean Opinion Score, Pourcentage de paquets perdus …

Comprendre la différence entre les appels VoIP sur réseau physique et ceux sur réseau Wifi.

Les deux écrans suivants, montrent le déroulement, paquet par paquet, d’un appel VoIP sur un réseau filaire et sur un réseau Wifi. Vous remarquez qu’ils sont assez similaires. Si les protocoles utilisés sont différents, le VoFI comporte cependant une étape supplémentaire : l’authentification !

Anatomie d'un appel VoIP sur réseau filaire

Anatomie d'un appel VoIP sur réseau filaire

L’utilisation du wifi implique des interférences de signal et des authentifications.

Anatomie d'un appel VoIP sur un réseau wifi (VoFI)

Anatomie d'un appel VoIP sur un réseau wifi (VoFI)

Approfondir :

Il y a quelques temps, Joe Habib, Directeur des services professionnels a présenté « QoS en VoIP : Tordre le cou à la latence, à la gigue et aux pertes de paquets ». Si la VoFI ou si vous prévoyez de la déployer, un coup d’oeil sur ce document PDF vous permettra de mieux cerner les enjeux et d’éviter de nombreux écueils.

Dans cette présentation vous retrouverez :

  • Quels sont les 6 facteurs qui contribuent à une mauvaise qualité de la VoIP,
  • Comment évaluer la qualité des appels VoIP,
  • Comment faire la balance entre les besoins de vitesse des équipements et celui de qualité des appels VoIP,
  • Comment capturer les données VoFI et comment identifier l’apparition des problèmes,
  • Comment analyser les appels VoFI paquet par paquet et vérifier la qualité effective avec le play-back.

Cette présentation est disponible ici : QoS de la téléphonie sur IP

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.

YouTube assassine t’il votre bande passante ? 26 mai 2010

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

Avec des services tels YouTube, Facebook, iTunes ou la VoIP parmi tant d’autres, nos réseaux sont la proie de fortes hausses de trafic. S’assurer que le réseau reste efficace et en bonne santé n’est pas une tâche subalterne pour les administrateurs réseau, c’est un devoir basic pour la productivité et l’efficacité de l’entreprise !

La gestion et le contrôle de la bande passante sont essentiels pour éviter des performances déplorables qui pèsent directement sur la productivité de l’entreprise !

Comment éviter les écueils ? Voici quelques conseils pour une mise en œuvre réussie :

1 – Focalisez sur les segments critiques du réseau

A tout moment, sachez qui utilise quoi, quand, et pourquoi sur ces segments réseau. C’est la seule manière efficace pour une entreprise d’optimiser la gestion de la bande passante et de connaitre avec précision la situation actuelle. Ces mesures de référence sont la pierre angulaire d’une gestion performante de la bande passante. En premier lieu, vous pouvez démarrer en contrôlant les connexions internet, les liens WAN, l’utilisation du Wifi et l’accès aux serveurs. Un logiciel d’analyse de réseau est un outil essentiel pour déterminer ces valeurs de référence et permet la mise en forme de rapports des principaux indicateurs au format PDF ou web. Ces compte-rendus ne serviront pas seulement à résoudre et contrôler les problèmes existants mais permettront également aux Entreprises de remonter dans le temps pour valider les performances actuelles et futures.

2 – Privilégiez les applications critiques pour le business

Chaque Entreprise a des priorités différentes ! En fait, chaque segment de réseau a des priorités différentes au regard des applications spécifiques qui y transitent. Il est évident que les principales applications consommatrices de bande passante seront différentes entre le service commercial et le service R&D. Les protocoles applicatifs doivent être gérés par ordre d’importance sur chaque segment réseau. Mais lorsque ces flux convergent et transitent sur les mêmes segments il est essentiel de tenir compte des besoins spécifiques de chacun d’entre eux.

3 – Analysez les interactions Applications/Protocoles.

Il est essentiel de comprendre les besoins spécifiques de chaque application et la/les manière(s) dont elles utilisent les protocoles sur le réseau. La mauvaise gestion d’un seul protocole peut mettre à terre les performances de l’application dans son ensemble. C’est un second point pour lequel un analyseur de réseau pourra mettre en évidence rapidement chacun des flux et ses performances propres. Il permet aux entreprises de disposer d’une vue temps-réel du fonctionnement du réseau et de classer les flux selon différents critères.

4 – Supprimez trafics et protocoles inutiles

Chacun de nos réseaux véhicule une part de trafic totalement inutile. Certains périphériques, en particulier les imprimantes, supportent des protocoles dont vous n’avez aucune utilité. Le Wifi ne fait pas exception est n’est malheureusement pas souvent filtré : Il arrive que des protocoles de management comme les protocoles de routage, SNMP …  soient présents sur des WLANs sans aucune raison si ce n’est de consommer de la bande passante.

5 – Rendez les applications critiques prioritaires grâce à la QoS

La plupart du temps les Entreprises mettent en œuvre les mécanismes de gestion de la priorité incluse dans leurs routeurs et commutateurs. Il est parfois nécessaire de recourir à des matériels ou logiciels spécifiques (compression de trafic …) qui optimisent encore la gestion de la bande passante.

6 – Contrôlez et gérez au quotidien

Il est essentiel pour les Entreprises de comprendre que le réseau est dynamique et que l’utilisation qu’en font les utilisateurs varie au cours du temps. Les administrateurs réseau doivent contrôler le bon fonctionnement des applicatifs en permanence et s’assurer que l’état de santé du réseau reste stable.  Il est primordial de suivre et de comprendre les tendances pour réaliser les changements nécessaires afin de parer aux évolutions des comportements de vos utilisateurs.

Cet article est librement inspiré du blog de l’éditeur WildPackets et par les expériences clients de NetWalker.

Résorber les trous noirs réseau des environnements virtualisés 18 mai 2010

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

L’adoption de la virtualisation continue à augmenter. Selon l’analyste Cindy Borovick d’IDC, l’année 2010 verra pour la première fois le nombre de serveurs virtuels dépasser celui des serveurs ‘réels’.

Un nombre croissant d’entreprises se tourne vers la virtualisation pour simplifier le déploiement d’applications et les opérations de maintenance, mais aussi pour répondre plus rapidement aux évolutions constantes des besoins du business.

A ce jour, même de petites structures ont recourt à la virtualisation grâce à la baisse des coûts et à la simplification des outils d’administration.

Il est important de mémoriser que l’analyse réseau [des environnements virtualisés] diffère quelque peu de celle en environnements ‘traditionnels’ puisque les ressources sont partagées.

Dans un environnement ‘traditionnel’ vous allez mettre en place du port mirroring sur un commutateur ou un routeur et les données proviendront directement du serveur.

Dans le cas d’un environnement virtuel, les données arrivent d’un adaptateur réseau virtuel sans nécessairement passer par le port du commutateur : D’où la présence de trous noirs !

La communication entre les serveurs virtuels reste invisible aux outils traditionnels … ainsi que les statistiques et les problèmes de communication inter-serveurs.

Pour résorber ces trous noirs et déployer une supervision réseau efficace en environnement virtuel, il est important de se fixer des objectifs : Du point de vue des objectifs, l’analyse en réseaux traditionnels ou en environnement virtuel est similaire ! Seule la mise en oeuvre des outils d’analyse diffère. Au lieu de capturer des données au niveau de la couche physique, vous devez réaliser la capture au niveau de ces commutateurs virtuels.

Omnivirtual permet aux entreprises d’accéder simplement à ce trafic virtuel et d’éliminer tous les points d’ombre du réseau.

Les sociétés qui ont recours à la virtualisation devraient prendre en compte les 5 considérations suivantes :

  • Être précis : Sachez ce que vous souhaitez analyser et concentrez vous sur ces points uniquement.
  • Tenir compte de l’environnement : ajustez les options aux seules machines ou applications nécessaires, les réglages ne sont pas là par hasard et vous permettent de tirer la quintessence de vos outils d’analyse.
  • Analysez seulement l’essentiel : N’analysez que le nécessaire et n’hésitez pas à exclure avec des règles le superflu.
  • Connaitre les limites : Vous devez prendre en compte des éléments comme la puissance processeur, l’espace disque, la charge CPU.
  • Anticipez les besoins : Si vous devez réaliser de la post-capture ou de la post-analyse, il est essentiel d’être certain de disposer de l’espace disque nécessaire et restez dans les limites du raisonnable.

Les bénéfices de la virtualisation sont indéniables pour les entreprises. Mais n’oubliez pas de mettre en oeuvre une solution efficace d’analyse réseau pour garantir la bonne santé de votre infrastructure et en tirer le meilleur.

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

Cloud Computing, la fin de l’analyse réseau ? 30 mars 2010

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

Sauf si vous vivez sur une autre planète, vous avez sûrement entendu parlé du Cloud Computing* qui consiste pour les entreprises à outsourcer serveurs et applications.

Beaucoup d’entreprises ont déjà adopté cette technologie  : Pew Research Center rapporte que 69% des entreprises aux U.S.A. l’utiliseraient déjà.

L’adoption de cette technologie pourrait laisser penser que la supervision du réseau dans les entreprises est moins stratégique que par le passé puisque les applications et les problèmes sont, eux aussi, outsourcés !

Dès lors, la question se pose de savoir si le Could Computing annonce la fin de la supervision réseau ?

Nous pensons bien au contraire, qu’elle est plus nécessaire que jamais !

Même si la mise en place du Cloud Computing modifie la manière de superviser les réseaux, une infrastructure réseau robuste reste la clé de voûte pour permettre une communication fluide entre les utilisateurs et leurs applications.

En fait, la plus grande différence est que les administrateurs vont se concentrer sur la gestion (performances, disponibilité …) des services plutôt que sur celle des infrastructures.

D’un point de vue réseau, le Cloud Computing revient à gérer des flux accédant à des serveurs distants, comme cela est déjà le cas pour les entreprises multi-sites. De ce fait, la problématique réseau demeure : Goulets d’étranglements potentiels, mauvaise répartition de la bande passante, et utilisation de protocoles non autorisés subsistent et impactent directement la fluidité des communications.

Le contrôle des performances applicatives requiert dès lors une attention particulièrement aiguisée !

Il est essentiel de disposer d’un référentiel des performances applicatives AVANT de basculer en Cloud Computing ! Une attention particulière devra également être portée aux transactions cross-applications une fois le basculement réalisé.

Comme toujours, la sécurisation du réseau reste un point essentiel, la migration vers un nuage ne fait pas exception.

Ce contrôle de sécurité commence avec le choix du prestataire retenu. Confier la gestion et le traitement de données hautement sensibles à un prestataire nécessite une vigilance de chaque instant. L’étude et la compréhension de la politique de sécurité du prestataire ainsi que son contrôle lors de tests menés par vos soins est primordiale.

Les analyses réalisées avec OmniPeek lors des phases de tests vont permettre aux ingénieurs de disposer de données cruciales sur les performances et la sécurité pour assurer une migration en toute quiétude.

Si l’utilisation du Cloud-Computing sécurise l’hébergement physique des données, la disponibilité sans faille du réseau ne doit en aucun cas être négligée car il ne s’agit ni plus ni moins (d’un point de vue réseau) que d’un déplacement de serveurs ! Les processus d’analyse et de contrôle au fil de l’eau sont un point clé de la réussite d’une migration vers le Cloud Computing.

Ces procédures garantiront à l’entreprise un contrôle impartial et adapté des prestations en matière de performances, de disponibilité et de respect des procédures de sécurité indispensables.

Elles permettent de garantir une migration sous contrôle et un suivi dans le temps.

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

(*ou encore informatique dématérialisée ou informatique dans les nuages)

Compass ou l’utilisation des statistiques pour accélérer le diagnostic 22 mars 2010

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

Le plus grand challenge du diagnostic de réseau est de cerner rapidement l’origine des problèmes pour les résoudre. Toutes les techniques afin d’optimiser le processus d’analyse rapide sont les bienvenues car elles permettent d’accroitre le taux de disponibilité du réseau et sa santé.

Partant de cette constatation, voici une suggestion : plutôt que de charger (et d’analyser) tous les paquets, gagnez du temps en utilisant les statistiques du trafic pour trouver des réponses aux questions comme « Que c’est il passé ?« , « Quand ?« , « Qui l’a fait ?« . En isolant la période précise grâce aux statistiques, vous pouvez alors focaliser toute votre expertise sur les paquets concernés.

Compass Forensics DashBoard

Exemple d'affichage de Compass

Pour vous simplifier la tâche, WildPackets rend disponible gratuitement* ‘Compass‘, un tableau de bord interactif pour OmniPeek. Ce tableau de synthèse (voir graphique) permet aux ingénieurs de sélectionner un intervalle de temps pour l’analyse. Ils peuvent alors afficher soit masquer des nœuds ou des protocoles à ce graphe afin de permettre comparaisons et corrélations sur différentes périodes.

Dans certains cas, la consultation du graphe de Compass permettra directement de résoudre le problème. D’autres fois, après avoir borné une plage horaire, les paquets concernés pourront directement être chargés grâce au bouton « Load Packets » pour une analyse complémentaire détaillée.

*Compass est téléchargeable gratuitement sur le site MyPeek pour les licences ayant un contrat de maintenance en cours.

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

%d blogueurs aiment cette page :