jump to navigation

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 

Capturer des données Wireless avec les AP Cisco en mode sniffer 2 juillet 2012

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

Réglages d’un point d’accès Cisco (AP) en mode Sniffer et d’OmniPeek pour capturer à distance

Savez-vous que vous pouvez utiliser les WLC et LAPs Cisco en mode sniffer en conjonction avec OmniPeek ?

Gagnez en temps et en efficacité avec OmniPeek

plus besoin de vous déplacer !

Depuis OmniPeek, en passant par le réseau ethernet vous pouvez capturer des données depuis de multiples AP (Access Point), ce qui permet une grande efficacité pour la capture multi-canaux. Quand il n’y a pas itinérance, il est possible de déplacer l’AP ‘Sniffeuse’ à proximité de l’AP pour laquelle on souhaite faire un diagnotique.

Dans le cas du roaming, les APs placées en mode sniffer, doivent se trouver à proximité des différentes AP que va utiliser le poste client. Cela permettra en quelque sorte d’avoir le « point de vue » de l’AP liée au poste client.

Si l’on s’intéresse plus particulièrement au point du vue du poste utilisateur, une version d’OmniPeek installée sur un ordinateur portable avec plusieurs adaptateurs wifi (un par canal) sera un complément idéal.

Étapes de la configuration

Configuration des WLC / AP Cisco

La première étape consiste à placer l’AP en mode sniffer. ATTENTION, elle ne sera plus en mesure de servir de point d’accès pour les utilisateurs.

Configurer l’AP en mode sniffer pour capturer les paquets radio

La borne wifi va rebooter et ne sera plus disponible en tant que point d’accès, elle devient en quelque sorte votre oreille.

Pour compléter la configuration il faut :

  • activer le mode sniffer
  • sélectionner le canal
  • spécifier l’adresse IP du poste OmniPeek

Régler le canal et l’adresse IP du poste sur lequel est lancé OmniPeek

OmniPeek recevra le trafic 802.11 encapsulé en utilisant AiroPeek Protocol (ancêtre d’OmniPeek) avec comme source le port UDP 5555 et comme destination le port UDP 5000.

Configuration d’OmniPeek

Pour permettre à OmniPeek de recevoir le trafic que stream l’AP en mode sniffer, il faut en premier lieu créer un « Cisco Remote Adapter » (adaptateur Cisco distant) depuis le menu Adapter de la fenêtre Capture Options.

Créaton du Cisco Remote adapter dans le sniffer OmniPeek

Indiquez un nom vous permettant d’identifier l’adapteur et une adresse IP si vous souhaitez que cet adapter ne soit lié qu’à une AP spécifique.

Pour ma part, j’utilise toujours l’adresse IP de point d’accès qui sniffe avec un nom (Name) parlant : par exemple TLS, BAT B, 3ieme, Salle Conférence ce qui me permet de la retrouver rapidement.

Vous pouvez alors lancer la capture après avoir enregistré vos réglages.

Lancer la capture des paquets depuis l’AP en mode sniffer

La capture commence comme si vous utiliser un réseau wifi local. (L’interface d’OmniPeek est identique pour une capture locale ou distante). Le flux radio envoyé par l’AP s’affiche au fil de l’eau dans la fenêtre d’OmniPeek et vous pouvez commencer à éditer les paquets.

Un paquet reçu de l’AP décodé par OmniPeek

•   •

Librement inspiré de l’article : « Collecting a Wireless sniffer trace using the Cisco Lighweight AP in Sniffer mode« 

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 

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

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

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 :