Déconnexion de session sur Frame Relay

ne
se déconnectent pas. Quel
pourrait être le problème ?

R. Il y a plusieurs hypothèses. Vous ne
précisez pas quel client 5250 vous utilisez.
S’il s’agit de CA (Client Access), le
problème est une haute latence périodique
sur votre circuit frame relay en
cause. CA envoie des paquets de maintien
d’activité pour s’assurer qu’il est
en contact continu avec l’hôte iSeries à 
distance. Si le client CA ne reçoit pas
une réponse à  un paquet keep-alive
dans un bref intervalle de temps
donné, il clôt la session. Le client
TN5250, qui reformate les sessions
5250 à  l’aide du protocole TCP/IP
Telnet, n’envoie pas de keep-alives et,
par conséquent, ne déconnectera pas
les sessions à  cause de la latence. Pour
résoudre à  court terme votre problème,
vous pouvez demander aux utilisateurs
d’essayer le client TN5250.

Mais cela masque simplement les
symptômes d’un mal plus profond
dont souffre le réseau : votre nouveau
fournisseur de frame relay n’offre pas
les débits de données les plus rapides
qui soient. Peut-être opère-t-il sur un réseau surchargé, souvent congestionné.
Il est probable que vous payez
pour une latence de paquets maximale
exprimée en millisecondes (en principe,
15 millisecondes sur une ligne
T1), donc vous devez effectuer
quelques mesures pour voir si vous obtenez
bien cela. Un test simple consiste
à  « pinger » l’adresse IP du routeur distant
sur l’autre côté de votre liaison
frame relay. Sur un écran de commande
Windows, la commande ping
pour cela est la suivant :

C:\>ping -n 120 x.x.x.x

où -n 120 signifie envoyer 120 pings à  l'intervalle par défaut d'un par seconde et x.x.x.x est l'adresse IP du routeur frame relay distant. La sortie du ping se présente ainsi :

Reply from x.x.x.x: bytes=32 time=28ms
Reply from x.x.x.x: bytes=32 time=29ms
Reply from x.x.x.x: bytes=32 time=27ms
Reply from x.x.x.x: bytes=32 time=30ms
Reply from x.x.x.x: bytes=32 time=254ms
Reply from x.x.x.x: bytes=32 time=329ms
…
Reply from x.x.x.x: bytes=32 time=27ms

Statistiques de Ping pour x.x.x.x :

Packets: Sent = 120, Received = 120,
Lost = 0 (0%),
Approximate roundtrip times in milliseconds:
Minimum = 25ms, Maximum = 329ms,
Average = 48ms

Les temps indiqués par Ping sont
des temps d'aller-retour (RTT, roundtrip
times) - le temps nécessaire à  un
paquet pour atteindre une adresse IP
de destination et revenir. La latence est
la moitié du RTT. Le ping donne le détail
du RTT sur chaque paquet de test
envoyé. Dans un réseau frame relay
non engorgé, vous devriez voir zéro
paquet perdu et des RTT voisins de 30
ms. Dans l'exemple ci-dessus, deux
des RTT sont très élevés - 250 ms et
329 ms. Ce qui signifie que, pendant
deux secondes, la congestion a retardé
certains paquets dix fois plus longtemps
que la normale. Un tel délai est
suffisant pour provoquer des timeouts
de la session 5250.

Votre propre réseau peut aussi être
responsable de l'engorgement. Si vous
envoyez trop de trafic sur une liaison
frame relay, il en résulte une latence
accrue.

Si vos tests révèlent une moyenne
de RTT haute, ou de nombreuses périodes
de congestion, vous devez soit
augmenter la vitesse de la liaison frame
relay, soit demander au fournisseur de
frame relay d'améliorer sa prestation.