Trouver les véhicules abandonnés

réseau, puis à  un échangeur pour placement sur un grand réseau de
paquets rapides, ou nuage.

Supposons que vous déboguiez le
problème suivant : vous ne pouvez pas
démarrer une session Telnet (couche
application) sur votre hôte de l’autre
côté de votre réseau. Les paquets sont
éjectés quelque part ! Logiquement, le
problème peut se situer de votre côté
du réseau, ou dans l’une des couches
intermédiaires. Comment donc trouver les véhicules abandonnés ?

Testons notre réseau par petits
morceaux, un morceau à  la fois, en utilisant
PING. PING est un protocole
TCP de couche basse qui utilise l’ICMP
(Internet Control Message Protocol).
ICMP n’exige pas de livraison garantie
des paquets, ce qui est parfait pour révéler
des problèmes de réseau. Une
application utilisant la commande
PING iSeries envoie des paquets ICMP à  intervalles fixes – disons un par seconde
– puis attend immédiatement
une réponse. Chaque paquet PING a
une occasion d’être entendu sur le réseau.
Si aucune réponse n’est renvoyée,
on vous dit qu’il n’y a pas eu de
réponse de l’hôte (« No Response
From Host »).

Etape 1. Faites PING du Loopback.
Pour utiliser PING depuis votre client
pour déterminer si la pile TCP/IP répond
normalement, faites PING de
votre adresse Loopback 127.0.0.1. Tous
les paquets devraient répondre. Ce test
fondamental doit fonctionner avant de
pouvoir passer à  l’étape 2. S’il échoue,
vous n’avez que deux possibilités :
1. Recycler l’interface en l’arrêtant et
en la redémarrant.

2. Recycler TCP/IP en tapant ENDTCP
suivi de STRTCP.

Si aucune des deux ne vous aide,
vous pouvez contacter l’IBM Support
Center à  http://www-912.ibm.com/
pour obtenir une assistance au débogage.

Etape 2. Faites PING de votre adresse
IP locale. Cette étape teste les composants,
applications, pile et matériel du
modèle de la figure 1. (Vous sortez la
voiture du garage.) Veillez à  utiliser
l’adresse IP (pas le nom de l’hôte) afin
d’éviter tout problème DNS dans le réseau.
Vous pouvez trouver l’adresse IP
de votre système en utilisant la commande
CFGTCP (Configure TCP/IP) et
en indiquant l’option 1. Si votre
adresse IP est 10.10.10.17, émettez la
commande PING 10.10.10.17.
Remarque : Sur l’iSeries, vous devez
placer les adresses TCP entre guillemets
simples.

Cette étape doit fonctionner dans toutes les situations. Si ce n’est pas le
cas, passez carrément de la pile au matériel
:
1. Terminez l’interface pour cette
adresse, puis faites varier la ligne sur
off et à  nouveau sur on.
2. Démarrez et arrêtez TCP si nécessaire.

CFGTCP option 1 montrera l’état
de l’interface réseau quand vous appuierez
sur la touche F11 (figures 2 et
3). Si l’interface est active, la description
de ligne et TCP/IP sont actifs.

Etape 3. Faites PING de l’adresse IP
de votre routeur. Faites un tour dans le
voisinage. Pour trouver l’adresse IP de
votre routeur, tapez CFGTCP sur la
ligne de commande de l’iSeries.
Choisissez l’option 2 pour montrer
l’adresse *DFTROUTE (passerelle), de
votre iSeries, qui est l’adresse de votre
routeur telle qu’elle se trouve dans le
champ nommé Next Hop.

Tous les PING doivent fonctionner
dans toutes les situations ; si ce n’est
pas le cas, il existe un problème entre
le matériel et le routeur. Dans ce cas
(un PING qui a échoué vers un routeur),
ce peut être un commutateur,
une MAU (multistation action unit), un
concentrateur, un fil, un émetteur-récepteur
et/ou le routeur lui-même. Il
se peut aussi qu’un fort trafic du réseau
provoque un engorgement sur le routeur.
Parlez-en à  votre administrateur
réseau pour éliminer cette hypothèse.
Si vous êtes l’administrateur réseau,
vous devez avoir accès aux compteurs
statistiques du routeur qui vous indiqueront
s’il constate de forts volumes
de trafic et s’il laisse tomber des paquets.

Si vos PING ne fonctionnent toujours
pas correctement à  ce stade, il
faut jeter un coup d’oeil au PAL
(Product Activity Log) de l’iSeries. Le
PAL donne une vue des problèmes
entre le matériel et le réseau. Pour vérifier le PAL, tapez
STRSST (Start System Service Tools) et
choisissez les options suivantes dans l’ordre, en appuyant sur Entrée après
chacune : 1, 1, 1, 5, 1. Examinez maintenant
le nom de ligne associé à  l’interface
confrontée aux problèmes. Si le
problème se situe au niveau LAN (problèmes
de congestion, de matériel
marginal, de transceiver, par exemple),
vous le verrez.

De là ,
vous pouvez afficher des rapports détaillés.
Dans le cas d’un problème inattendu
avec un paquet frame relay, les utilisateurs doivent contacter
l’IBM Support Center pour déterminer
la cause de l’erreur. Quelques problèmes
de type engorgement dans un
réseau Token-Ring peuvent aussi intervenir. Même si de tels
problèmes ne sont pas graves, il est
bon de pousser plus loin l’investigation
si des problèmes continuent à  se manifester
au niveau de la couche application.

Etape 4. Faites PING de l’adresse IP
distante. Tout semble fonctionner correctement
jusqu’au routeur. Essayez
maintenant d’atteindre la destination
finale au travers de tout le réseau. Les
routeurs sur le chemin qui mène à  la
destination restent en principe transparents.
Si vous ne pouvez pas faire
PING de l’adresse IP distante, voyez si
vous pouvez faire PING de son routeur
passerelle.

En cas de problèmes à  ce stade,
vous devrez peut-être contacter l’ISP
ou l’administrateur réseau au point de
destination, et demander pourquoi
vous n’obtenez pas de réponse aux paquets
PING. L’échec vient peut-être de
la présence de filtres de paquet ou
d’un pare-feu sur le réseau de destination.