Les échecs de routage | enterprise.netscout.com

Les échecs de routage


Les échecs de routage

Malheureusement, des problèmes d’itinéraires de mauvaise qualité ou incorrects sont communs. Le plus souvent, ils sont le résultat d’erreurs administratives dans la configuration du réseau. Occasionnellement, le protocole de routage utilisé mène au problème. Il peut sembler surprenant que plusieurs routeurs à bas coût et la plupart des serveurs qui agissent comme des routeurs utilisent le protocole RIP (routing information protocol). Ce protocole est vieux de plus de trente ans. Les routeurs et serveurs qui utilisent ce protocole choisissent le chemin de destination basé sur le nombre de sauts (liaisons entre des routeurs). Toutefois, aucune disposition n’est mise en oeuvre afin d’évaluer la vitesse ou le débit d’une liaison. Par conséquent, les liaisons peuvent être sur un chemin qui est très lent lorsqu’un chemin alternatif n’est pas utilisé. La meilleure façon de repérer une liaison lente est probablement d’utiliser un outil de traçage d’itinéraire.




Un facteur qui peut s’avérer important est la perte de paquets de la part du routeur réseau. Entre les routeurs, il n’y a aucune disposition concernant la retransmission. Ainsi, le client ou le serveur doit déterminer que les routeurs ont perdu des paquets. Quand ils le font, ils retransmettront généralement les paquets. Mais vous vous souviendrez que nous avons souligné que cette retransmission peut survenir beaucoup plus tard et provoquer d’importants ralentissements de débit de livraison TCP. Alors, pourquoi les routeurs perdraient-ils des paquets ? Il y a deux raisons principales. Tout d’abord, un paquet arrive au routeur et il est corrompu. Autrement dit, il a été endommagé et le routeur détecte que certaines informations contenues sur celui-ci sont incorrectes. Il ne va pas essayer de déterminer quelles informations sont correctes. Cela utiliserait de précieux cycles processeur. Il supprime le paquet. Dans certains cas, il renvoie un paquet appelé un paquet ICMP (Internet Control Message Protocol) à la source, indiquant cette suppression. Mais le paquet est perdu. La deuxième chose qui puisse arriver est que le routeur est tout simplement trop encombré (c’est-à-dire occupé). Presque tous les routeurs atteignent un seuil où ils commencent à supprimer au hasard du trafic afin d’accomplir un routage adéquat autant qu’ils le peuvent. Encore une fois, l’impact sur les applications TCP dans le client ou le serveur peut être dévastateur.

Les problèmes d’impression sont souvent associés à des erreurs d’acheminement. Par exemple, si un client est connecté à un serveur qui est de l’autre côté d’une liaison WAN, mais choisit d’imprimer vers une imprimante locale, le fichier d’impression peut traverser la liaison WAN vers le spouleur d’impression (file d’attente). Lorsque l’imprimante est disponible, le fichier sera renvoyé à travers la liaison WAN pour venir atteindre l’imprimante. C’est un phénomène très courant et cela crée habituellement des lenteurs au niveau de l’impression parce que les liaisons de réseau étendu ont tendance à avoir une bande passante limitée.

Un autre problème commun se produit lorsque des périphériques sur un réseau avec un routeur à rattachements multiples sont mal configurés. Consultez la Figure 19. L’administrateur réseau avait à l’origine configuré les téléphones avec des adresses se terminant de .1 à .126 sur un même réseau. Lorsque l’administrateur n’avait plus d’adresses à sa disposition, il a décidé d’ajouter la plage allant de .130 à .190 en ajoutant au routeur une seconde adresse 192.168.0.129 avec un masque de 26 bits. Apparemment, les utilisateurs aux plages allant de .5 à .83 ont découvert que l’utilisateur à leur bureau à l’adresse .133 ont cherché comment modifier la configuration du téléphone. Ils ont modifié leur configuration pour être compatibles avec le téléphone .133. Cela va présenter une série de problèmes potentiels. Si le téléphone est assez intelligent pour être à même de découvrir l’erreur de configuration, il se peut qu’il fasse ce que ferait un client Windows®. Dans ce cas-là (.83), le téléphone semble indiquer que le routeur configuré comme étant le routeur par défaut (.1) n’est pas sur le réseau local.


Cependant, les appareils tels que les téléphones ont des systèmes d’exploitation très limités. Il est beaucoup plus probable que le téléphone autorise l’activation de cette configuration. Dans ce cas, le trafic entre .5 et .83 sera acheminé. Si le routeur n’est pas surchargé, ce problème de configuration peut rester dans l’ombre pendant des années. Toutefois, lorsque le routeur devient trop congestionné par le trafic en rafales, il pourrait commencer à perdre des paquets au cours des appels entre ces deux stations.


Figure 19 : Configuration incorrecte



La perte de paquets le long de l’itinéraire peut demeurer invisible. Par exemple, supposons qu’une paire de commutateurs de deuxième couche sont reliés par une connexion par fibre optique ou paire torsadée. Parce que seuls les commutateurs suivent normalement des liaisons de ce type, des erreurs de bit peuvent se produire qui provoquent la corruption de trames de données par la liaison. Ce problème va être traité par les stations aux extrémités. Si les applications qui perdent des trames sont basées sur le protocole TCP, l’incidence sera importante. Si l’administrateur du réseau utilise la liaison pour le transport de la VoIP, des pertes de trame mineures ne seront probablement pas évidentes dans la mesure de la qualité des appels. L’administrateur peut donc chercher la cause et passer à côté de la source réelle de la dégradation des performances. D’autres causes de perte de paquets peuvent être une surexploitation de la qualité technique du service, de mauvaises cartes NIC dans les routeurs ou des liaisons sans fil intermédiaires (tels que les passerelles sans fil).




RETOUR À LA TABLE DES MATIÈRES

TÉLÉCHARGER LE GUIDE COMPLET

 
 
Powered By OneLink