第 10 章 PPP の障害追跡
この章では、ネットワーク上に PPP を構成した後に行う必要のある一連の検査事項を示します。その後、PPP リンクを介した通信に問題が生じたときには、PPP 診断機能を問題の解決に用いることができます。
要約すると、これらの検査は次の順序で行う必要があります。
-
ハードウェア
-
インタフェースの状態
-
接続
-
ネットワークインタフェースの動作状態
-
ローカルルーティングテーブル
-
アクセス権
-
パケットフロー
PPP がすべてのテストに合格すれば、TCP と UDP のサービス、たとえば rlogin、telnet、ftp などを、リンクを介して使用できるようになっているはずです。それでもリンクに障害がある場合は、PPP 診断機能を利用して障害追跡を試みてください。
以下の各節では、上記の各検査について詳しく説明します。
ハードウェアの検査
すべてのモデムケーブルと電源ケーブルがしっかりと接続されていることを確認します。PPP に問題が生じたときは、常に、モデム、ケーブル、シリアルカード、電話回線を最初に検査してください。
インタフェースの状態の検査
PPP を起動した後は、PPP インタフェース名だけを引数として指定した ifconfig を使用して、回線の現在の状態が監視できます。例 10-1 に示すのは、実行中の PPP リンクについての ifconfig のサンプル出力です。
注 -
特権 (root) ユーザーが ifconfig コマンドを発行した場合は、上記のようにマシンのアドレスが出力に表示されます。
例 10-1 ポイントツーポイントリンクに関する ifconfig の出力
nomadb# ifconfig ipdptp0
ipdptp0: flags=28d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,UNNUMBERED> mtu 1500
inet 129.144.111.26 --> 129.144.116.157 netmask ffff0000
ether 0:0:0:0:0:0
標準と動的のどちらのポイントツーポイントリンクの場合も、コード例 10-2 に示すような出力が得られます。
例 10-2 マルチポイントリンクに関する ifconfig の出力
nubian# ifconfig ipd0
ipd0: flags=c1<UP,RUNNING,NOARP> mtu 1500
inet 129.144.201.191 netmask ffffff00
ether 0:0:0:0:0:0
ifconfig に UP と RUNNING が表示されない場合は、PPP が正しく構成されていないことを示します。ifconfig の詳細は、「ifconfig コマンド」と、ifconfig(1M) のマニュアルページを参照してください。
接続の検査
ping コマンドを使用して、接続が up 状態であるか、または確立可能であるかを検査します。たとえば、次のような単純な往復テストを考えてみてください。
# ping elvis |
ここで、elvis はリモートホスト上の PPP インタフェースの名前です。結果の表示が次のとおりであったとします。
elvis is alive |
この場合は、elvis との間でパケットを送受信できます。この結果が得られなかったとすれば、ローカルホストとリモートホストの間のどこかに、ルーティングに関する問題があります。ping についての詳細は、「ping コマンド」と、ping(1M) のマニュアルページを参照してください。
インタフェースの動作状況の検査
パケットが正しく送受信されているかどうかを検査するには、netstat コマンドを使用します。
# netstat -i |
「netstat コマンド」 と netstat(1M) マニュアルページを参照してください。
ローカルルーティングテーブルの検査
ローカルルーティングテーブルを表示するには、netstat コマンドを使用します。
# netstat -r |
次に出力例を示します。
Routing tables Destination Gateway Flags Refcnt Use Interface sahara deserted UGH 0 0 ie1 karakum labia UGH 0 0 ie1 frodo bilbo UGH 1 12897 ipdptp0 route7 route7 UGH 0 0 ie0 eastgate route71 UGH 0 158 ie0 backbone pitstopbb U 1 16087 ie1 dresdenpc route1 UG 0 0 ie1 loopback localhost U 2 113436 lo0 swan-bb pitstop U 406 146044 ie0 dallas2 route7 UG 0 0 ie0 trainingpc route62 UG 0 0 ie1 |
ありうる宛先ネットワークのそれぞれについて、ルーティングテーブルエントリが 1 つずつあることを確認してください。特に、Interface の欄に示される PPP デバイスが、Gateway の欄に示される適切なホスト名と適合している必要があります。同様に、Gateway エントリは、Destination の欄の正しいエントリと適合している必要があります。
この条件が満たされていない場合は、静的ルーティングを使用しているのであれば、適正な静的送信経路を追加します。in.routed を用いて動的ルーティングを使用しているときは、次のようにします。
-
次のように入力して、in.routed が実行中であるかどうかを確認します。
# ps -e | grep route
それでもまだルーティングテーブルが正しくない場合は、スーパーユーザーになって次の手順に進みます。
-
ps -e から入手したプロセス ID を kill の引数として指定して、in.routed を終了します。たとえば、1384 がプロセス ID であるとすれば、次のように入力します。
# kill 1384
-
# /usr/sbin/route -f
-
# /usr/sbin/in.routed
アクセス権の検査
rsh を使用しようとして、Permission denied というメッセージが出力された場合は、リモートシステムの /etc/hosts.equiv ファイルまたは /.rhosts ファイルに、送信側システムのホスト名が含まれていないか、行 + が含まれていません。
パケットフローの検査
次にパケットフローを検査します。snoop コマンドを使って、ネットワークからパケットを観察し、各パケットの内容を観察します。 例 10-3 に、snoop からの出力例を示します。
例 10-3 snoop からの出力例
# snoop -d ipdptp0
Using device ipdptp0 (promiscuous mode)
corey -> pacifica7 RLOGIN C port=1019
hugo -> ponc3 RPC R XID=22456455 Success
ponc3 -> hugo NFS C WRITE FH=1B29 at 32768
commlab3 -> commlab4 TELNET R port=34148
commlab4 -> commlab3 IP D=129.144.88.3 S=129.144.88.4 LEN=46, ID=41925
commlab3 -> commlab4 TELNET R port=34148
commlab4 -> commlab3 ICMP Echo request
commlab3 -> commlab4 ICMP Echo reply
commlab4 -> commlab3 FTP C port=34149
commlab4 -> commlab3 FTP C port=34149
commlab3 -> commlab4 FTP R port=34149
commlab4 -> commlab3 FTP C port=34149
出力の最初の行の Using device ipdptp0 に含まれている ipdptp0 というデバイス名は、ポイントツーポイント接続を示しています。
注 -
snoop を使って回線の状態を検査するには、リンクが "up" 状態にあり、トラフィックがある程度生成されている必要があります。
snoop は、ネットワークからパケットを取り込んで、その内容を表示します。snoop は、パケットフィルタモジュールとストリームバッファーモジュールの両方を使用して、ネットワークから効率的にパケットを取り込みます。取り込んだパケットは、受け取ると同時に表示することも、後で見るためにファイルに保存しておくこともできます。
snoop は、単一行要約形式と複数行詳細形式のどちらでも、パケットを表示できます。要約形式の場合は、最高レベルのプロトコルに関するデータだけが表示されます。たとえば、NFS パケットについては NFS に関する情報だけが表示されます。その下位にある RPC、UDP、IP、イーサネットフレームの情報は抑止されますが、詳細形式オプションのどれかを選択した場合は表示されます。
snoop コマンドの詳細は、snoop(1M) のマニュアルページを参照してください。
PPP 診断機能を用いた障害追跡
モデム接続を正常に確立した後でリンクに問題がある場合は、PPP レベルの診断機能を用いた障害追跡を行うことができます。PPP レベルの診断機能は、リンクの動作状況に関する詳細情報を報告するので、どこに障害があるのかを突き止めるのに役立ちます。
診断情報を入手するには、debug_level 8 の行を asppp.cf ファイルの path セクションに追加します (データ通信に関する詳しい知識がある場合は、デバッグレベル 9 を用いれば、きわめて詳細な情報が得られます)。次に、PPP 診断機能を呼び出す構成ファイル例を示します。
ifconfig ipdptp0 plumb nomada nubian-ppp up path interface ipdptp0 peer_system_name nubian-ppp #The name in the /etc/uucp/Systems file inactivity_timeout 300 #Allow five minutes before timing out debug_level 8 #Start up PPP diagnostics for this link
aspppd.conf ファイルについての詳細は、「/etc/asppp.cf 構成ファイルの編集」を参照してください。
マシンに対する診断の設定方法
監視したいホストについて診断を設定するには、次のようにします。
-
スーパーユーザーになり、/etc ディレクトリに移動します。
-
アクセス権が必ず 600 に設定されるように、ファイルを保存します。
-
# kill PID # aspppd
ここで、PID は aspppd のプロセス ID です。
PPP は、/var/adm/log/asppp.log に診断情報を書き込みます。
診断出力の分析
PPP が正常に実行されているときに、asppp.log ファイルには、通常の出力のほかに診断情報が含まれています。この節では、診断メッセージの意味について説明します。ここに該当する出力がない場合は、RFC 1331 を参照してください。
ホストとモデムの設定
ローカルホストがモデムに構成情報を送り、モデムがリモートホストにダイヤルしようとしたときに発生するメッセージについて説明します。これらの初期の動作は、実際には UUCP デーモンが取り扱います。これらの動作は、非同期 PPP 通信の UUCP 部分と考えることができます (UUCP についての詳細は、第 12 章「UUCP のデータベースとプログラム」を参照してください)。
下記の 2 つのメッセージは、セッションの始めに常に表示されます。これは、aspppd デーモンが正常に起動されたことを示します。
11:53:33 Link manager (1057) started 04/14/94 11:53:33 parse_config_file: Successful configuration
次の行は、パケットがローカルホストの ipdptp0 インタフェースに送られたことを示しています。これは、ダイヤルアウトが正常に行われたかどうかを判断するのに役立ちます。たとえば、リモートマシンの ping を試みたときに、asppp.log 内にこのメッセージがないとすれば、ルーティングの問題が原因でパケットが失われていると考えられます。
次に、UUCP は、/etc/uucp/Systems ファイル内のチャットスクリプトの中にある Ppac7 に一致するエントリを探します。そして、デバイスタイプが ACUTEC であるエントリが見つかったことを報告します (Systems ファイルについての詳細は、「/etc/uucp/Systems ファイル」を参照してください)。
11:53:46 process_ipd_msg: ipdptp0 needs connection conn(Ppac7) Trying entry from '/etc/uucp/Systems' - device type ACUTEC.
UUCP は、次に、/etc/uucp/Devices ファイルから、ACUTEC ダイヤラに関するダイヤル情報を探します。この情報が見つかると、UUCP は、ローカルホストの該当するシリアルポートをオープンし、その速度を 9600 に設定します (/etc/uucp/Devices についての詳細は、「/etc/uucp/Devices ファイル」を参照してください)。
Device Type ACUTEC wanted Trying device entry 'cua/a' from '/etc/uucp/Devices'. processdev: calling setdevcfg(ppp, ACUTEC) fd_mklock: ok fixline(8, 9600) gdial(tb9600-ec) calle
UUCP は、/etc/uucp/Dialers ファイルの中から tb9600 というエントリを見つけ、次のメッセージを送り出します。
Trying caller script 'tb9600-ec' from '/etc/uucp/Dialers'
expect: ("")
|
ホストは 2 秒間待ってから、モデムのレジスタを設定します。下記のログに示される情報は、個々のモデムに固有のものです。これは /etc/uucp/Dialers ファイルからの情報をもとにしています。
got it sendthem (DELAY) APAUSE APAUSE APAUSE T&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M<NO CR>) |
次の行は、モデムとホストマシンとの間のダイアログです。expect (OK^M) は、モデムが「了解」を送ることを予期していることを意味します。2 行目の終わりの got it という語句は、ホストがモデムから「了解」メッセージを受け取ったことを意味します。
expect: (OK^M) AAAT&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M^M^JOK^Mgot it |
次にホストは下記の文字列をモデムに送り、実際にはモデムがダイヤリングを行います。2 行目の電話番号は、/etc/uucp/Systems ファイル内のリモートホストに関するエントリから検索されます。
sendthem (ECHO CHECK ON A^JATTDDTT99003300887744^M^M<NO CR>) |
expect で始まる行は、ローカルホストが、モデムから 9600 bps の速度であるという応答を受け取ることを予期していることを意味します。その次の行は、モデムが応答したことを示しています。
expect: (CONNECT 9600) ^M^JCONNECT 9600got it |
次の行は、リンク上でハードウェアフロー制御が開始されたことを示しています。ホストは、フロー制御情報を /etc/uucp/Dialers ファイルから入手します。
STTY crtscts |
その後の一連のメッセージは、ローカルホストが、リモートホストから標準的な UNIX ログインプロンプトが送られてくるのを待っていることを示しています。
getty ret 8
expect: ("")
got it
sandiest (^J^M)
expect: (login:)
次のメッセージは、ローカルホストがリモートからのログインプロンプトを受け取ったことを示します。ローカルホストは、リモートホストについての /etc/uucp/Systems エントリ内のチャットスクリプトから、該当するログインシーケンスを検索します。このシーケンスは Ppong^M で、リモートホストがログインするために必要です。
^M^J^M^Jlogin:got it sendthem (Ppong^M) |
下記のメッセージでは、ローカルホストは、リモートホストからの ssword プロンプトを待ちます。このプロンプトを受け取ると、ローカルホストは、リモートホストに関する /etc/uucp/Systems エントリ内のチャットスクリプトから検索したパスワードを送ります。
expect: (ssword:) login: Ppong^M^JPassword:got it |
下記のメッセージは、ダイヤリングとモデム接続が正常に完了したことを示しています。
sendthem (ppptest1^M) call cleanup(0)^M |
ローカルホストとリモートホストの間の通信
この時点で、ローカルホストとリモートホストの間のリンクが確立され、PPP 通信が開始されます。
セッションのこの部分の最初のいくつかの行は、構成要求 (Config-Req) です。これは、リモートホストに送られる最初の PPP パケットです。構成要求は、リンク制御プロトコル (LCP) パケットの一例です。このパケットは、構成を設定することを要求し、エンドポイントマシン間の PPP リンクを設定します。 例 10-4 は、サンプルの構成要求を示します。
例 10-4 構成要求
11:54:20 004298 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=4c LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
以下に、例 10-4 に示した構成要求について説明します。
-
11:54:20 - タイムスタンプフィールド。パケットが送られた時刻を示す
-
004298 - パケットの番号
-
ipdptp0 - 使用するネットワークインタフェース
-
SEND PPP ASYNC - モデムが非同期 PPP を送信していることを示す
-
29 Octets - ホストが送ったデータの量
-
LCP - 送信するパケットタイプ
-
ID=4c - パケットに関連付けられている識別子。これは実際にはパケットの一部
-
LEN=24 - パケットの LCP 部の長さ
残りの項目は、ホスト間でのネゴシエーションを必要とするオプションのリストです。
-
MRU=1500 - 最大受信単位 (MRU)。呼び出し側ホストがリモートホストから受信できる最大パケットサイズ
-
ACCM=00000000 - 非同期文字マップ (ACCM)。送信でエスケープする制御文字をリモートホストに知らせるために送られるマスク
-
MAG#=69f4f5b2 - マジックナンバフィールド。ループバック検出メカニズムに使用される
-
ProtFCOMP AddrCCOMP - フレームヘッダーの特定の部分 (プロトコルフィールド、アドレスフィールド) の圧縮をリモートホストに要求する
その後のいくつかの行は、無効な PPP パケットを報告しています。これらのパケットは、実際には UNIX テキストを送信しようとしているリモートホストから送られてきたものです。これは PPP に問題があることを示すものではありません。
11:54:20 004299 ipdptp0 RECEIVE {Invalid ppp packet}PPP ASYNC 7
Octets [BAD FCS] {Unrecognized protocol: 1}
11:54:20 004299 ipdptp0 RECEIVE PPP ASYNC 73 Octets [BAD FCS]
{Unrecognized protocol: 880a}
|
次のパケットでは、ローカルホストはリモートホストからの構成要求を受け取り、さらに別の構成要求を送ります。これら 2 つのパケットは、ID フィールド以外の部分はどちらも同じです。2 つのパケットは ID フィールドにより区別されます。
11:54:21 004301 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- Req ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP 11:54:21 004302 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
次のパケットでは、ローカルホストは、リモート要求に対する確認として、構成肯定応答 (Config-ACK) を送ります。
11:54:21 004303 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP |
ローカルホストは、リモートホストからの構成要求 (Config-Req) を受け取ります。
11:54:21 004304 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- Req ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP |
次のパケットでは、ローカルホストはリモートホストから送られてきた第 2 のパケットを確認し、リモートホストの肯定応答を受け取ります。
11:54:21 004305 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP 11:54:21 004306 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- ACK ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
次のパケットでは、ローカルホストは IP 伝送に関するパラメータについてのネゴシエーションを行います。LEN=16 はパケットサイズを表します。VJCOMP は、Van Jacobson のヘッダー圧縮を示しています。IPADDR の後にあるのは呼び出し側ホストの IP アドレスです。
11:54:21 004307 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config- Req ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.70 |
次のパケットは、ローカルホストがリモートホストから、IP アドレスを含む IP 構成を受け取ったことを示しています。
11:54:22 004308 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP Config-Req ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.71 |
ローカルホストは次の ACK をリモートホストに送り、リモートホストからの ACK を受け取ります。
11:54:22 004309 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config- ACK ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.71 11:54:22 004310 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP Config-ACK ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.70 |
下記の最初のメッセージは、リンク上で IP が起動されたことを示しています。第 2 のメッセージは、ローカルホストがリンクを介して IP トラフィックを送信していることを示しています。
11:54:22 start_ip: IP up on interface ipdptp0, timeout set for 120 seconds 11:54:24 004311 ipdptp0 SEND PPP ASYNC 89 Octets IP_PROTO |
下記の最初のメッセージでは、ローカルホストはリモートホストからの IP トラフィックを受け取ります。その後のメッセージは、アイドルタイムアウトが原因でインタフェースが切り離されたことを示しています。
11:54:25 004312 ipdptp0 RECEIVE PPP ASYNC 89 Octets IP_PROTO 11:56:25 process_ipd_msg: interface ipdptp0 has disconnected 11:56:25 disconnect: disconnected connection from ipdptp0 |
下記のメッセージからは、終了シーケンスを開始します。最初のメッセージは、リモートホストが IP 層を終了するためのパケットを送ったことを示しています。第 2 のメッセージは、終了要求に対するローカルホストの肯定応答です。
11:56:25 004313 ipdptp0 RECEIVE PPP ASYNC 9 Octets IP_NCP Term- REQ ID=38 LEN=4 11:56:25 004314 ipdptp0 SEND PPP ASYNC 9 Octets IP_NCP Term-ACK ID=38 LEN=4 |
ローカルホストは、LCP 層の終了要求を受け取ります。第 2 のメッセージはその要求に対する肯定応答であり、その結果正常なシャットダウンが行われます。
11:56:25 004315 ipdptp0 RECEIVE PPP ASYNC 9 Octets LCP Term-REQ ID=39 LEN=4 11:56:25 004316 ipdptp0 SEND PPP ASYNC 9 Octets LCP Term-ACK ID=39 LEN=4 |
次のメッセージはリンクが閉じられたことを示しています。
11:56:29 004317 ipdptp0 PPP DIAG CLOSE |
- © 2010, Oracle Corporation and/or its affiliates