INVESTIGATIONS RESÉAU:ÉTAPE PAR ÉTAPE
Avec des plaintes d'utilisateurs au sujet du réseau qui manquent souvent de détails, il peut être difficile de savoir par où commencer. La meilleure manière est souvent en recherchant dans la couche réseau et en éliminant les possibilités une par une.
Dans les derniers bulletins, nous avons regardé des problèmes de couche physique et de couche réseau. Dans cet article, nous continuerons à explorer les étapes de dépannage de la couche réseau et à évaluer les temps de réponse des applications.
1) Passer en revue la configuration de la QoS (qualité de service)
La QoS est employée principalement pour la VoIP, la vidéo et les applications de Communications Unifiés. Employez Observer pour confirmer que la QoS est convenablement configurée. Pour une discussion plus approfondie sur la vérification de la configuration de la priorité, lisez le deuxième article de ce bulletin.
2) Mesurer la latence du réseau
Il y a quatre manières différentes de mesurer la latence réseau :
- Visualisez la négociation Handshake de TCP. Localisez le SYN, le SYN-ACK, et l'ACK qui initie la connexion. En utilisant la demande initiale de SYN comme point de départ il est aisé de mesurer la durée aller-retour pour identifier la latence de réseau.
- Avec DHCP (Dynamic Host Configuration Protocol), il y a quatre paquets qui voyagent à travers le réseau pour obtenir une adresse IP d’une machine. Utilisez ces paquets pour calculer le temps de réponse réseau approximatif. D'abord, le client envoie une découverte (discover) et le serveur répond avec une offre (offer). Le client fait alors une requête et le serveur envoie un ACK. DHCP utilise UDP, tandis que la 1ere méthode utilisée pour déterminer le temps de réponse avec SYN, SYN-ACK, emploie TCP.
- Traquez les requêtes et les réponses DNS qui emploient également le protocole UDP pour vous donner une autre métrique de temps de réponse. Utilisez différents protocoles pour établir des points de référence pour évaluer où se situe le problème.
- Envoyer une requête ARP à la passerelle par défaut et chronométrez la réponse.
3) Trouver le paquet de SYN
Utilisez la Dynamique de Connexion pour trouver le paquet TCP SYN. Quand vous avez localisé le paquet de SYN cliquez bouton droit dans le graphe de Dynamique de Connexion sur le paquet et choisissez Décoder. Aller en dessous de l'en-tête TCP dans le panneau du milieu du décodage= et sous « TCP options » trouvez la liste de la taille maximum de segment. La taille la plus efficace pour une topologie 10/100 Ethernet est 1460. (Note : En Gigabit Ethernet qui peut soutenir les paquets Jumbo, soyez sûr que la taille maximum de segment est convenablement configurée). Au même endroit du paquet décodé, vérifiez que d'autres options telles que le SACK, Scaling Window et les Timestamps (horodateurs) sont configurés correctement.
4) Taille de fenêtre TCP
Utilisez Observer Expert pour regarder la taille de fenêtre TCP dans les connexions de l’analyse Experte sous les événements TCP. Si vous voyez du zéro Windows se produire, il se peut qu’un dispositif ait un souci de ressource. Parfois la taille de fenêtre est placée si basse que cela peut causer des transferts de données inefficaces et des problèmes de congestion.
5) Retransmissions TCP
Les retransmissions TCP sont provoquées par beaucoup de choses. Utilisez Observer Expert pour les dépister dans les événements TCP. Si vous voyez beaucoup de retransmissions, vérifier la couche physique qui peut être la source probable des retransmissions. Ensuite, prenez des captures simultanées de chaque côté de la transaction avec une 2e sonde et employez le MultiHop Analysis pour voir si l'autre partie ou un serveur pourrait être responsable de ces problèmes.
6) Configurations des Urgent Bit
Bien que le Urgent Bit soit rarement utilisé, les administrateurs réseau doivent le connaître. Si le Urgent Bit est configuré, l'application est capable d’informer l'autre partie d'un problème qui pourrait altérer la communication.
7) Application Thread Processing Time
Identifiez d'abord si l'application prend trop de temps pour procéder une requête ou pour répondre. Ensuite, contrôlez si l'application remplit la taille maximum de segment. Se rappeler que 1460 est le plus efficace pour un réseau Fast Ethernet.
Si la couche réseau est sans erreur, la prochaine étape sera d'analyser plus en profondeur la performance applicative. Pour en apprendre plus au sujet des Experts Observer « Application Analysis ». Vous pouvez également affiner vos capacités de dépannage de réseau en vous inscrivant à une de nos classes NI University.
Vérifier la Priorité d'Application
En mettant en œuvre n'importe quelle application temps réel il est impératif de s’assurer de la disponibilité de la bande passante à travers la QoS. Ne pas mettre en application la QoS ouvre la porte aux interférences d'autres applications sur le réseau, un problème connu sous le nom de contention. Nous regarderons les diverses méthodes pour confirmer la mise en place de priorité ou les règles de QoS avec Observer.
Par Paquet
Pour trouver le niveau de Précedence d’un paquet en particulier, faites click droit sur ce paquet et choisissez décoder. Vous pouvez identifier la configuration dans l'en-tête du paquet. Dans Observer, la QoS peut être réglée pour être montrée par type de service (ToS) ou par services différenciés (DSCP). Dans cet exemple, la priorité est placée à 18.
Par Protocole
Observer montre également les protocoles par niveau de QoS. Dans cet exemple, notez que des flux RTP sont placés à 46 et à 18. Cette disparité avec deux priorités différentes peut expliquer des problèmes de qualité de VoIP.
Pour trouver : Menu > Distribution de Protocoles.
Pour la VoIP
Si vous dépistez des problèmes liés aux applications VoIP, employez l'Expert VoIP d’Observer pour montrer les métriques de VoIP comme la gigue (jitter) et le Scoring avec les niveaux de priorité.
Pour trouver : Menu > Expert Analysis > VoIP Events
En dernier lieu, assurez-vous que la configuration de QOS soit mise en place dans tout le réseau et de manière harmonieuse, avec les applications critiques placées à un niveau de priorité le plus élevé.
Livre Blanc: Remporter les Défis des Nouvelles Architectures
Il peut être difficile de prévoir comment les technologies naissantes comme la virtualisation ou le cloud computing impacteront la performance des applications. Développez les stratégies pour surmonter les problèmes de visibilité et de dépannage qu’elles représentent.
Lire le livre blanc (PDF) (en Anglais).
Tous droits réservés. Network Instruments, Observer, GigaStor, Link Analyst, et tous les logos associés à Network Instruments sont des marques enregistrées de Network Instruments, LLC.
Toutes les autres marques, protégées ou non, sont la propriété de leurs auteurs respectifs.
Network Instruments, LLC, 10701 Red Circle Drive, Minnetonka, MN 55343
