RTシリーズの予期しない発呼に関するFAQ

インターネット速度計

[ インターネットに定期的にpingを打って応答速度を監視するアプリケーション ]

• インターネットの反応速度をリアルタイム表示するアプリケーション

  ＜インターネット＞ ------+-----------------------+-------------------------------- | | | +------+------+ | | サーバ | | +-------------+ | ↑ 　〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜↑〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 : : プロバイダに接続 ↑ ISDN網 : : ↑ +-------------+ ↑ 定期的にpingを打って応答速度が | ルータ | ↑ 監視される。→定期的な発呼 +------+------+192.168.0.1 ↑ | ↑ ------+-----------------------↑----+-------------------------- ↑ | 192.168.0.0/24 .......................... +------+------+192.168.0.2 . . | 端末 | . 遅い 速い . /+-------------+ . +-+-+-+-+-+-+-+ . / . |………↑ | ./ . +-------------+ . .......................... インターネット速度計

• 定期的に勝手に繋がってる。

  インターネットの応答速度測定周期が長い場合は、 規則正しく周期的にルータが勝手に接続しているように見えます。

• 切っても切れない。切っても勝手に繋がる。

  インターネットの応答速度測定周期が短い場合は、 ルータの接続を手動で切断しても、次の測定時にルータが勝手に接続して しまいます。

• ルータは、パソコンの電源が入っていると、プロバイダに繋ぐ、しくみな の？

  ルータは、そのようなことはできません。
  パソコンの電源が入れられると、インターネット速度計が動きだす ということです。ルータは、パソコンの指示に従って、プロバイダに 接続するだけです。

• 対策案
  1. インターネットに送信するpingパケットを回線の接続状態に応じて管理する
  2. インターネットに送信するpingパケットをIPパケットフィルタで常に破棄する。
  3. インターネット速度計の利用を中止する。

[ pingパケットを回線の接続状態に応じて管理して快適インターネット ]

• IPパケットフィルタ(restrict)により接続中だけ速度表示を許す

  発呼要因となっていたpingパケットを、回線の接続状態に応じた管理をする。 このようなケースには、ルータのIPパケットフィルタ機能のrestrictフィルタが便利です。

  プロバイダ | ↑ | ↑ インターネットにpingパケットが送り届けられる | ↑ 　〜〜〜〜〜〜↑〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 : : ↑ ISDN網 +----------↑-------+ | 通過↑ | | □→破棄 | …回線の接続状態に応じて、 | ↑ | restrictフィルタで通過や破棄を管理する | ルータ ↑ | +------+---↑-------+ 192.168.0.1 | ↑ | ↑ プロバイダへのpingパケット送信要求 | ↑ 192.168.0.0/24 ------+---↑------------------------+-------------------------- ↑ |192.168.0.2 ↑ +------+------+ ←←←←←←←← | 端末 | プロバイダ向けpingパケット +-------------+

• pingパケットのフィルタ設定例
  • ICMP(ping)をフィルタする方法
  • pingのパケットを観測する方法

[ サポート日記(1997年10月)…ノウハウの伝授！？ ]

• 電話サポート担当のＯ嬢は、いつものように サポート電話を取りました。「ルータ設定を変 えてないのだけれど、切断しても、繋がりっぱ なしになってしまうようになりました。これっ てルータのバグでしょ？何とかしてよ！」と、 お叱りを受けました。プログラムの不具合の心 当りもありませんでしたし、開発に報告するべ き不具合情報が不足していましたので、状況の 把握に務めることにしました。電話で状況を伺 うのと同時に、お客様の許可を頂いて、リモー トセットアップで、お客様のルータにログイン させていただきました。設定の問題も特になく、 ルータのログをチェックして、発呼要因を調べ てみることにしました。すると、特定のIPアド レスから定期的にpingのパケットが発生してい ることがわかりました。そこで、Ｏ嬢はこのIP アドレスの機器から、定期的にプロバイダに自 動接続する要求が出ていることを伝え、お客様 にpingコマンドの使用状況やコンピュータの設 定変更やインストールしたソフトウェアなどを 確認しました。結局、Winodws95のクラッシュ 対策で導入したノートン・ユーティリティに附 属する「インターネット速度計」がpingの応答 時間をグラフ表示していることがわかりました。 お客様の御要望を伺って、後で説明するIPパケ ット・フィルタのrestrict機能を紹介し、設定 を追加して、サポートを終了しました。

• ツールを使って発呼要因を調べる

  一般的な調査方法は、ネットワーク機器の利 用状況を参考にしながら、LANアナライザやWAN アナライザといった専用機器を利用しながら、 ネットワークを利用した通信内容を分析するこ とになります。その調査結果から、発呼の原因 を特定することになります。LANアナライザを 用意しておけば、日頃の利用プロトコルの統計 やトラフィック状態変化や障害検出にも役立ち ます。LANアナライザは、WindowsやMacintosh にインストールして利用するソフトウェア製品 が比較的低価格で提供されるようになったとは いえ、すべてのユーザが導入できるようなもの ではありません。UNIXであれば、フリーソフト ウェアがあるのですが、普段からUNIXを利用し ている方でなければ、使いこなすのは難しいか もしれません。

  しかし、RTシリーズがあれば、手軽でありな がら、もう少し詳しく調査することができます。 次にその調査方法を紹介します。

• ログ機能を利用して発呼の要因を調べる

  ネットボランチを含むRTシリーズには、発呼 する時、発呼のログと発呼要因となったパケッ トの情報(IP Commencingログ)をログに残すよ うになっています。このIP Commencingログに は、プロトコルの種類と始点と終点のIPアドレ スやポート番号の情報が同時に記録されるので、 意図しない発呼の原因の特定作業の手掛りとな ります。

  先程の「インターネット速度計」は、pingコ マンドの仕組を利用しておりました。pingコマ ンドは、ICMP Echo Requestを相手のホストに 送ります。相手のホストがICMP Echo Request を受け取ると始点と終点アドレスを入れ換えた ICMP Echo Replyを送り返します。そのICMP Echo Replyを受け取ったpingコマンドは、ICMP Echo Requestを送信してからICMP Echo Reply を受信するまでの時間を応答時間として報告す る仕組です。その応答時間をリアルタイムにメ ータ表示することで「インターネット速度計」 になります。サポートのＯ嬢もログに、ICMP Echo RequestのIP Commencingログが周期的に 残っていましたので、これが発呼要因となる パケットであると判断したのです。

• フィルタリングで無用な発呼を抑える

  「インターネット速度計」は、悪いユーティ リティでしょうか？悪い要因としては、大規模 なネットワークで全員が一斉に利用したら膨大 なトラフィックが発生してスループットを低下 させる可能性があります。しかし、初心者にと っては、インターネットの距離感がイメージで 捉えられて非常に身近になって楽しくなる機能 です。実際の価値観は、ネットワークに対する 立場で違ってくるでしょう。

  ISDNルータにIPパケット・フィルタリングを 利用することにより対処することができます。 Ｏ嬢のヒアリングした要望は「インターネット 速度計は欲しいのだけれど、常時発呼は困る。」 というものでしたので、restrictフィルタを紹 介しました。restrictフィルタは、ISDN回線の 接続状態に応じて、パケットを通過させたり、 破棄させることができますので、プロバイダと 接続しているときの「インターネット速度計」 には、pingの応答速度が表示され、プロバイダ と接続していないときには「速度がゼロ、つま り、通信不能」となるような要望が満足できる 環境ができました。

  ICMPパケットのrestrictフィルタ適用設定例

  # ip filter 80 restrict * * icmp * * # ip filter 100 pass * * * * * # pp select 1 pp1# ip pp secure filter out 80 100

  アプリケーションとネットワークとISDNルー タが上手に使いこなせるようになるとインター ネットがより楽しいものになります。

• 要因が特定しにくいDNS情報の問い合せ発呼

  通信相手がDNS名で指定されていた場合、実 際の通信に先立って、DNSサーバに対してDNS 名からIPアドレスを問い合わせる通信が始まり ます。このような通信のIP Commencingログは、 常にDNSサーバへの問い合せパケットとなり原 因の特定に至りません。さらに、DNSリカーシ ブサーバ機能を利用されている環境では、発呼 要因はルータになります。

  このようなルータのパケットが発呼要因であ る状況に対処する為にRTシリーズの発呼要因の ログ機能では、DNSサーバへの問い合せパケッ トが発呼要因となった時、その問い合せ対象の DNS名をログに残すように仕様変更されました。 DNSリカーシブサーバ経由の問い合せであった 場合は、その要求元であるホストのIPアドレス も付加されます。

  DNSサーバへの問い合せによる発呼要因のログ

  192.168.0.2がDNSサーバに問い合せた時 PP[XX] IP Commencing: UDP 192.168.0.2:1024 > DNSサーバ:53 (DNS Query [www.rtpro.yamaha.co.jp])

  192.168.0.2がDNSリカーシブサーバを経由して DNSサーバに問い合せた時 PP[XX] IP Commencing: UDP 192.168.0.1:53 > DNSサーバ:53 (DNS Query [www.rtpro.yamaha.co.jp] from 192.168.0.2)

  これらの情報を手掛りとして実際の通信内容 を調査する為、通過したパケットのログを取る pass-logフィルタを適用して実際の通信内容を 観測し、プロトコルを特定していきます。

• 脚色してしまいました。(_o_)
  • Ｏ嬢がこの一件を初めてサポートしたとき、restrictフィルタを知らなかった。

    restrictフィルタを知らなかったので、 icmpをrejectするか、インターネット速度計を使わないように 指導したのだった。

  • Ｏ嬢がこの一件を初めてサポートしたとき、nslookupなるものを知らなかった。

    ping宛先の情報を調べる為に、tracerouteを実施したときの 逆引き情報を表示させていた。
    この情報により、利用しているアプリケーションの手掛りとした。

[ 関連FAQ ]

• 知らない間にダイヤルアップ接続してしまいます。
• 無用な発呼を抑えるフィルタ設定例
• IPパケット・フィルタ
  • pingのパケットを観測する方法
  • ICMP(ping)をフィルタする方法

[ FAQ for RT-Series ]
[ FAQ for 予期しない発呼 / files / 設定 / ログ / IPパケットフィルタ / Windows / Macintosh ]