メニューボタン
サポートチーム便り2010.09.21

インターフェースの変更を診断する

Question

今週末、とてもおかしなものを見たのですが、是非意見を聞きたいのです。ファイアウォールを経由して FTP されて何ヶ月も動作していたジョブの動作が、わずか一晩で止まってしまいました。調査したところ、以前とは違う IBM i インターフェースを使用していることがわかりました。このインターフェースには、ファイアウォールを通過する許可が与えられていません。ファイアウォールで許可された指定のインターフェースを持つ静的ルートを追加したところ、FTP は正常に動作しました。IP を再起動し、静的ルートを削除してテストしたところ、FTP はまだデフォルトで元の正しいルートを使用していることがわかり、安心しました。

今週、多少ネットワークに関する変更をしていたのですが、その問題は毎週行う IPL を終えた後にだけ見られました。なぜ FTP が別のインターフェースを使用し始めて、IP を再起動した後に元のインターフェースをまた使用し始めるのでしょうか。

Answer

これは、複数の経路が同じ宛先に向かっていることと、IBM i のロード・バランシング機能が原因かもしれません。各経路は「優先バインド・インターフェース」(BINDIFC) というパラメーターを使用しています。この設定の説明は、ADDTCPRTE(コマンド)をプロンプト表示(F4)し、BINDIFC パラメーターの上にカーソルを置いて Help (F1) を押下することにより表示できます。

Re-IPLしたり、新しいネットワーク・コンポーネントをインストールすると、デフォルトの優先バインド・インターフェースが変更される場合があります。ご質問者の場合は、明らかにシステムが、IPL 後に別のルートまたはインターフェースを使用して宛先に接続するよう判断しています。おそらく、以前のルートが一時的に使用できなかったためと思われます。(その後)IPL を行った際には、以前のルートが再度使用可能になったことにより、システムがそのインターフェースをデフォルト・パスとして使用したのです。こうしたことが再発しないようにするため、以前に作成した静的ルートを残しておくのも悪くないでしょう。

経路がダウンしたときにオペレーターのメッセージ・キューに TCPxxxx というメッセージがいくつか表示される場合があります。これで、本来の原因を探ることができるかもしれません。

あわせて読みたい記事

PAGE TOP