test

Solaris のシステム管理 (ネットワークサービス)

PPP および PPPoE 関連の問題の解決

PPP 関連の問題と PPPoE 関連の問題を解決する方法については、次の節を参照してください。

Procedureネットワークの問題を診断する方法

PPP リンクがアクティブになったにもかかわらずリモートネットワーク上のほとんどのホストに到達できないという場合は、ネットワーク問題が見つかる可能性があります。ここでは、PPP リンクに影響を与えるネットワーク障害を特定し、解決する方法を示します。

  1. ローカルマシン上でスーパーユーザーになるか、同等の役割になります。

    役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 問題のある接続を切断します。

  3. 次のオプションを PPP 構成に追加して、構成ファイルのオプションのプロトコルを無効にします。


    noccp novj nopcomp noaccomp default-asyncmap

    このオプションは、もっとも単純で圧縮を行わない PPP を使用可能にします。コマンド行でこれらのオプションを引数として pppd を実行してみます。これまで接続できなかったホストに接続できれば、次のいずれかの位置にオプションを追加します。

    • /etc/ppp/peers/peer-name、call オプションのあと

    • /etc/ppp/options、オプションを広域的に適用する場合

  4. リモートピアを呼び出します。次に、デバッグをオンに設定します。


    % pppd debug call peer-name

  5. chat の -v オプションを使用して、chat プログラムから冗長ログを取得します。

    たとえば、PPP 構成ファイルで次の形式を使用します。


    connect 'chat -v -f /etc/ppp/chatfile'

    /etc/ppp/chatfile は、お使いの chat ファイルの名前を表します。

  6. Telnet またはほかのアプリケーションを使ってリモートホストに接続し、問題を再度発生させてみます。

    デバッグログを調べます。これでもリモートホストに接続できない場合は、PPP の問題はネットワークに関連している可能性があります。

  7. リモートホストの IP アドレスが登録されているインターネットアドレスであることを確認します。

    組織によっては、ローカルネットワーク内では通用するが、インターネットへは経路指定できない内部 IP アドレスを割り当てる場合があります。リモートホストが社内にある場合、インターネットに接続するためには、管理者は、NAT (名前 - アドレス変換) またはプロキシサーバーを設定する必要があります。リモートホストが社内にない場合は、遠隔組織に問題を報告する必要があります。

  8. 経路指定テーブルを調べます。

    1. ローカルマシンとピアの両方で経路指定テーブルを確認します。

    2. 経路指定テーブルで、ピアからリモートシステムへのパスにあるルーターをすべて確認します。また、リモートシステムからピアへの戻りのパスにあるルーターもすべて確認します。

      中間ルーターの設定が間違っていないことを確認します。ピアへの戻りのパスに問題が見つかることがしばしばあります。

  9. (省略可能) マシンがルーターである場合、オプションの機能を確認します。


    # ndd -set /dev/ip ip_forwarding 1

    ndd の詳細は、ndd(1M) のマニュアルページを参照してください。

    Solaris 10 リリースでは、ndd(1M) ではなく routeadm(1M) を利用できます。


    # routeadm -e ipv4-forwarding -u
    注 –

    ndd コマンドに持続性はありません。このコマンドに設定された値は、システムのリブート時に消失します。routeadm コマンドは持続します。このコマンドに設定された値は、システムのリブート後も保持されます。

  10. netstat -s および同様のツールから取得した統計を確認します。

    netstat の詳細は、netstat(1M) のマニュアルページを参照してください。

    1. ローカルマシン上で統計を実行します。

    2. ピアを呼び出します。

    3. netstat -s によって生成された新しい統計を調べます。詳細は、「PPP に影響を与える一般的なネットワークの問題」を参照してください。

  11. DNS 構成を確認します。

    ネームサービス構成に問題があると、IP アドレスを解釈処理できないため、アプリケーションは障害を発生します。

PPP に影響を与える一般的なネットワークの問題

netstat -s によって生成されたメッセージを使用すると、次の表に示したネットワークの問題を解決できます。関連する作業情報として、「ネットワークの問題を診断する方法」を参照してください。

表 21–2 PPP に影響を与える一般的なネットワークの問題

メッセージ 

問題 

解決方法 

IP packets not forwardable

ローカルホストで送信経路が見つからない 

ローカルホストの経路指定テーブルに欠如している送信経路を追加する 

ICMP input destination unreachable

ローカルホストで送信経路が見つからない 

ローカルホストの経路指定テーブルに欠如している送信経路を追加する 

ICMP time exceeded

2 つのルーターが同じ着信アドレスを互いに送信し、パケットが互いに何度も往復し、TTL (存続時間) の値を超過した 

traceroute を使ってルーティングループの源を見つけ、エラーになっているルーターの管理者に連絡する。traceroute の詳細は、traceroute(1M) のマニュアルページを参照

IP packets not forwardable

ローカルホストで送信経路が見つからない 

ローカルホストの経路指定テーブルに欠如している送信経路を追加する 

ICMP input destination unreachable

ローカルホストで送信経路が見つからない 

ローカルホストの経路指定テーブルに欠如している送信経路を追加する 

Procedure通信の問題を診断し解決する方法

通信の問題は、2 つのピアがリンクを正常に確立できない場合に発生します。これらは、chat スクリプトが不正に設定されているために起きるネゴシエーション問題であることもあります。ここでは、通信の問題を解決する方法を示します。誤りのある chat スクリプトによって発生するネゴシエーション問題を解決する方法については、表 21–5 を参照してください。

  1. ローカルマシン上でスーパーユーザーになるか、同等の役割になります。

    役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. ピアを呼び出します。

  3. リモートピアを呼び出します。次に、デバッグをオンに設定します。


    % pppd debug call peer-name

    通信の問題によっては、問題解決のためにピアからデバッグ情報を取得する必要がある場合があります。

  4. 生成されたログをチェックし、通信の問題が報告されていないかを確認します。詳細は、「PPP に影響を与える一般的な通信の問題」を参照してください。

PPP に影響を与える一般的な通信の問題

次の表は、「通信の問題を診断し解決する方法」の作業で出力されるログに関連する症状を説明したものです。

表 21–3 PPP に影響を与える一般的な通信の問題

症状 

問題 

解決方法 

too many Configure-Requests メッセージ

あるピアがほかのピアを認識できません。 

次の問題を確認します。 

  • マシンまたはモデムの配線が間違っていないか。

  • モデムの構成に不適切なビット設定がないか、あるいは間違ったフロー制御がないか。

  • chat スクリプトが誤っていないか。この場合は、表 21–5 を参照してください。

pppd debug の出力は LCP が起動していることを示しているが、より上位のプロトコルが失敗したか、あるいは CRC エラーを示している

非同期制御文字マップ (ACCM) が正しく設定されていません。 

default-async オプションを使用して ACCM を標準のデフォルトである FFFFFFFF に設定します。まずコマンド行で pppd のオプションとして default-async を使用します。問題が解決したら、default-async を /etc/ppp/options または call オプションのあとの /etc/ppp/peers/peer-name に追加します。

pppd debug の出力は IPCP が起動していることを示しているが、すぐに終了してしまう

IP アドレスの設定が間違っている可能性があります。 

  1. 間違った IP アドレスがないか確認するために、chat スクリプトを調べます。

  2. chat スクリプトに誤りがない場合は、ピアのデバッグログを要求し、ピアのログで IP アドレスを確認します。

接続のパフォーマンスが非常に低い 

フロー制御構成のエラー、モデム設定のエラー、不適切に設定された DTE レートなどにより、モデムが適切に構成されていない可能性があります。 

モデム構成を確認し、適宜調整します。 

ProcedurePPP 構成の問題を診断する方法

PPP の問題には、PPP 構成ファイルの問題が原因となっているものがあります。ここでは、一般的な構成問題を特定し、解決する方法を示します。

  1. ローカルマシン上でスーパーユーザーになるか、同等の役割になります。

    役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. リモートピアを呼び出します。次に、デバッグをオンに設定します。


    % pppd debug call peer-name

  3. 生成されたログをチェックし、構成問題が報告されていないかを確認します。詳細は、「一般的な PPP 構成の問題」を参照してください。

一般的な PPP 構成の問題

次の表は、「PPP 構成の問題を診断する方法」の作業で出力されるログに関連する症状を説明したものです。

表 21–4 一般的な PPP 構成の問題

症状 

問題 

解決方法 

pppd debug 出力に、「Could not determine remote IP address」というエラーメッセージが含まれる

/etc/ppp/peers/peer-name ファイルにそのピアの IP アドレスが存在しない。ピアが、接続ネゴシエーション時に IP アドレスを提供しない

次の形式を使用して、pppd コマンド行、あるいは /etc/ppp/peers/peer-name でピアの IP アドレスを指定する

:10.0.0.10 

pppd debug の出力が CCP データ圧縮が失敗したことを示す。出力には接続が解除されたことも表示する

ピアの PPP 圧縮設定が衝突している可能性がある  

ピアの 1 つで /etc/ppp/options に noccp オプションを追加して CCP 圧縮を無効にする

Procedureモデムの問題を診断する方法

モデムは、ダイアルアップリンクで問題の発生しやすい領域です。モデム構成でもっともよく発生する問題は、ピアからの応答がないことです。しかし、接続の問題の原因が本当にモデム構成の問題なのかどうかを判定することは難しい場合があります。

モデムの基本的なトラブルシューティングに関するヒントは、『Solaris のシステム管理 (上級編)』の「端末とモデムの問題を解決する方法」を参照してください。モデムメーカーのマニュアルや Web サイトは、特定の装置に関する問題の解決に役立ちます。次の手順は、問題のあるモデム構成が接続の問題の原因となっているかどうかを判定するのに役立ちます。

  1. 「PPP デバッグをオンに設定する方法」で説明した手順で、デバッグをオンに設定してピアを呼び出します。

  2. 作成された /var/log/pppdebug ログを表示し、モデム構成に問題がないかを確認します。

  3. ping を使用してさまざまなサイズのパケットを接続上に送信します。

    ping の詳細は、ping(1M) のマニュアルページを参照してください。

    小さいパケットは受信されるが、大きいパケットはドロップされる場合、モデムに問題があることを示します。

  4. インタフェース sppp0 上のエラーを確認します。


    % netstat -ni
Name  Mtu  Net/Dest   Address      Ipkts    Ierrs Opkts    Oerrs Collis Queue 
lo0   8232 127.0.0.0  127.0.0.1    826808   0     826808   0     0      0     
hme0  1500 172.21.0.0 172.21.3.228 13800032 0     1648464  0     0      0     
sppp0 1500 10.0.0.2   10.0.0.1     210      0     128      0     0      0

    インタフェースのエラーが時間がたつにつれて増えている場合は、モデム構成に問題がある可能性があります。

注意事項

作成された /var/log/pppdebug ログの表示で次の症状が認められる場合は、モデムの構成に問題がある可能性があります。ローカルマシンはピアを認識できますが、ピアはローカルマシンを認識できません。

Procedurechat スクリプトのデバッグ情報を取得する方法

次の操作は、chat のデバッグ情報を表示して一般的な問題の解決方法を知る手段として行なってください。詳細は、「chat スクリプトの一般的な問題」を参照してください。

  1. ダイアルアウトマシン上のスーパーユーザー、またはそれと同等の役割になります。

    役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. /etc/ppp/peers/peer-name ファイルを編集してピアが呼び出されるようにします。

  3. connect オプションで指定されている chat コマンドに引数として -v を追加します。


    connect "/usr/bin/chat -v -f /etc/ppp/chat-script-name"

  4. /etc/ppp/connect-errors ファイルの chat スクリプトのエラーを表示します。

    次は、chat で発生する主なエラーです。


    Oct 31 08:57:13 deino chat[107294]: [ID 702911 local2.info] expect (CONNECT)
Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] alarm
Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] Failed

    この例は、(CONNECT) 文字列を待つ間にタイムアウトしたことを示します。chat が失敗すると、pppd から次のメッセージを受け取ります。


    Connect script failed

chat スクリプトの一般的な問題

chat スクリプトは、ダイアルアップリンクにおいてもっとも問題が発生しやすい領域です。次の表に、chat スクリプトの一般的なエラーと、エラー解決のためのヒントを示します。操作方法については、「chat スクリプトのデバッグ情報を取得する方法」を参照してください。

表 21–5 chat スクリプトの一般的な問題

症状 

問題 

解決方法 

pppd debug の出力に Connect script failed が含まれる

chat スクリプトは、次のようにユーザー名とパスワードを指定している 


ogin: user-name
ssword: password

しかし、接続しようとしたピアはこの情報を要求していない 

  1. chat スクリプトからログインとパスワードを削除する

  2. 再度ピアを呼び出してみる

  3. まだメッセージが表示される場合は、ISP に連絡して正しいログインシーケンスを問い合わせる

/usr/bin/chat -v ログにメッセージ "expect (login:)" alarm read timed out が含まれる

chat スクリプトは、次のようにユーザー名とパスワードを指定している 


ogin: pppuser
ssword: \q\U

しかし、接続しようとしているピアはこの情報を要求していない 

  1. chat スクリプトからログインとパスワードを削除する

  2. 再度ピアを呼び出してみる

  3. まだメッセージが表示される場合は、ISP に連絡して正しいログインシーケンスを問い合わせる

pppd debug の出力にpossibly looped-back が含まれる

ローカルマシンまたはそのピアがコマンド行で停止していて PPP を実行していない。chat スクリプト内に間違って設定されたログイン名とパスワードがある 

 

  1. chat スクリプトからログインとパスワードを削除する

  2. 再度ピアを呼び出してみる

  3. まだメッセージが表示される場合は、ISP に連絡して正しいログインシーケンスを問い合わせる

pppd debug 出力は LCP が起動していることを示しているが、接続がすぐに終了してしまう

chat スクリプト内のパスワードが間違っている可能性がある 

 

  1. ローカルマシンの正しいパスワードを確認する

  2. chat スクリプト内のパスワードを確認する。間違っている場合は修正する

  3. 再度ピアを呼び出してみる

  4. まだメッセージが表示される場合は、ISP に連絡して正しいログインシーケンスを問い合わせる

ピアからのテキストがチルダ (~) で始まる 

chat スクリプトは、次のようにユーザー名とパスワードを指定している 


ogin: pppuser
ssword: \q\U

しかし、接続しようとしているピアはこの情報を要求していない 

 

  1. chat スクリプトからログインとパスワードを削除する

  2. 再度ピアを呼び出してみる

  3. まだメッセージが表示される場合は、ISP に連絡して正しいログインシーケンスを問い合わせる

モデムが停止する 

chat スクリプトに次の行が含まれており、ローカルマシンがピアからの CONNECT メッセージを待つように強制している


CONNECT ”

chat スクリプトがピアからの CONNECT を待つようにするときは、次の行を使用する 


CONNECT \c

chat スクリプトを ~ \c で終了する

pppd debug の出力に LCP: timeout sending Config-Requests が含まれる

chat スクリプトに次の行が含まれており、ローカルマシンがピアからの CONNECT メッセージを待つように強制している


CONNECT ”

chat スクリプトがピアからの CONNECT を待つようにするときは、次の行を使用する 


CONNECT \c

chat スクリプトを ~ \c で終了する

pppd debug 出力に Serial link is not 8-bit clean が含まれる

chat スクリプトに次の行が含まれており、ローカルマシンがピアからの CONNECT メッセージを待つように強制している


CONNECT ”

chat スクリプトがピアからの CONNECT を待つようにするときは、次の行を使用する 


CONNECT \c

chat スクリプトを ~ \c で終了する

pppd debug の出力に Loopback detected が含まれる

chat スクリプトに次の行が含まれており、ローカルマシンがピアからの CONNECT メッセージを待つように強制している


CONNECT ”

chat スクリプトがピアからの CONNECT を待つようにするときは、次の行を使用する 


CONNECT \c

chat スクリプトを ~ \c で終了する

pppd debug の出力に SIGHUP が含まれる

chat スクリプトに次の行が含まれており、ローカルマシンがピアからの CONNECT メッセージを待つように強制している


CONNECT ”

chat スクリプトがピアからの CONNECT を待つようにするときは、次の行を使用する 


CONNECT \c

chat スクリプトを ~ \c で終了する

Procedureシリアル回線の速度の問題を診断して解決する方法

ダイアルインサーバーは、速度の設定の衝突が原因で問題が発生する可能性があります。次に示す手順は、接続の問題の原因がシリアル回線速度の衝突であることを特定するのに役立ちます。

速度の問題は、次のような原因で発生します。

pppd は、はじめは回線に設定されていた速度を /bin/login または mgetty によって設定された速度に変更します。このことが回線の障害を発生させます。

  1. ダイアルインサーバーにログインします。デバッグをオンに設定してピアを呼び出します。

    手順については、「PPP デバッグをオンに設定する方法」を参照してください。

  2. 作成された /var/log/pppdebug ログを表示します。

    出力に次のメッセージがないか確認します。


    LCP too many configure requests

    このメッセージは、PPP に設定されているシリアル回線の速度が衝突している可能性があることを示します。

  3. PPP が /bin/login のようなプログラムを介して起動されているかどうかを調べ、設定されている回線速度を調べます。

    このような状況では、pppd はもともと設定されていた回線速度を /bin/login で指定されている速度に変更します。

  4. ユーザーが PPP を mgetty コマンドから起動し、誤ってビットレートを指定していないかどうか確認します。

    この処理もまた、シリアル回線速度の衝突を引き起こします。

  5. 次のようにしてシリアル回線速度の衝突の問題を解決します。

    1. モデムの DTE レートをロックします。

    2. autobaud を使用しないようにします。

    3. 設定後に回線速度を変更しないようにします。

ProcedurePPPoE の診断情報を取得する方法

PPP および標準の UNIX ユーティリティーを使用して PPPoE の問題を特定できます。接続上の問題の原因が PPPoE だと思われるとき、次の診断ツールを使ってトラブルシューティング情報を取得できます。

  1. PPPoE トンネルを実行しているマシン、つまり PPPoE クライアントまたは PPPoE アクセスサーバーでスーパーユーザーになります。

  2. 「PPP デバッグをオンに設定する方法」で説明した手順で、デバッグをオンに設定します。

  3. ログファイル /var/log/pppdebug の内容を表示します。

    次の例は、PPPoE トンネルとの接続で生成されたログファイルの一部です。


    Sep  6 16:28:45 enyo pppd[100563]: [ID 702911 daemon.info] Plugin 
  pppoe.so loaded.
Sep  6 16:28:45 enyo pppd[100563]: [ID 860527 daemon.notice] pppd 
  2.4.0b1 (Sun Microsystems, Inc.,
Sep  5 2001 10:42:05) started by troot, uid 0
Sep  6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] connect option:
   '/usr/lib/inet/pppoec 
-v hme0' started (pid 100564)
Sep  6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.info] Serial connection established.
Sep  6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.info] Using interface sppp0
Sep  6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.notice] Connect: sppp0
   <--> /dev/sppptun
Sep  6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] /etc/ppp/pap-secrets
  is apparently empty
Sep  6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] /etc/ppp/chap-secrets
  is apparently empty
Sep  6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] sent 
  [LCP ConfReq id=0xef <mru 1492> 
asyncmap 0x0 <magic 0x77d3e953><pcomp><acomp>
Sep  6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] rcvd 
  [LCP ConfReq id=0x2a <mru 1402>
asyncmap 0x0 <magic 0x9985f048><pcomp><acomp

    デバッグの出力によって問題を特定できない場合は、次の手順に進みます。

  4. PPPoE から診断メッセージを取得します。


    # pppd connect "/usr/lib/inet/pppoec -v interface-name"

    pppoec は、診断情報を stderr に送信します。pppd をフォアグラウンドで実行する場合、出力が画面に表示されます。pppd をバックグラウンドで実行する場合、出力は /etc/ppp/connect-errors に送られます。

    次の例は、PPPoE トンネルがネゴシエートされたときに生成されるメッセージです。


    Connect option: '/usr/lib/inet/pppoec -v hme0' started (pid 100564)
/usr/lib/inet/pppoec: PPPoE Event Open (1) in state Dead (0): action SendPADI (2)
/usr/lib/inet/pppoec: Sending PADI to ff:ff:ff:ff:ff:ff: 18 bytes
/usr/lib/inet/pppoec: PPPoE State change Dead (0) -> InitSent (1)
/usr/lib/inet/pppoec: Received Active Discovery Offer from 8:0:20:cd:c1:2/hme0:pppoed
/usr/lib/inet/pppoec: PPPoE Event rPADO+ (5) in state InitSent (1): action SendPADR+ (5)
/usr/lib/inet/pppoec: Sending PADR to 8:0:20:cd:c1:2: 22 bytes
/usr/lib/inet/pppoec: PPPoE State change InitSent (1) -> ReqSent (3)
/usr/lib/inet/pppoec: Received Active Discovery Session-confirmation from
   8:0:20:cd:c1:2/hme0:pppoed
/usr/lib/inet/pppoec: PPPoE Event rPADS (7) in state ReqSent (3): action Open (7)
/usr/lib/inet/pppoec: Connection open; session 0002 on hme0:pppoe
/usr/lib/inet/pppoec: PPPoE State change ReqSent (3) -> Convers (4)
/usr/lib/inet/pppoec: connected

    診断メッセージによって問題を特定できない場合は、次の手順に進みます。

  5. snoop を実行します。次にトレースをファイルに保存します。

    snoop の詳細は、snoop(1m) のマニュアルページを参照してください。


    # snoop -o pppoe-trace-file

  6. snoop トレースファイルを表示します。


    # snoop -i pppoe-trace-file -v pppoe
    		 

    ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 1 arrived at 6:35:2.77
ETHER: Packet size = 32 bytes
ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast)
ETHER: Source      = 8:0:20:78:f3:7c, Sun
ETHER: Ethertype = 8863 (PPPoE Discovery)
ETHER:
PPPoE: ----- PPP Over Ethernet -----
PPPoE:
PPPoE: Version = 1
PPPoE: Type = 1
PPPoE: Code = 9 (Active Discovery Initiation)
PPPoE: Session Id = 0
PPPoE: Length = 12 bytes
PPPoE:
PPPoE: ----- Service-Name -----
PPPoE: Tag Type = 257
PPPoE: Tag Length = 0 bytes
PPPoE:
PPPoE: ----- Host-Uniq -----
PPPoE: Tag Type = 259
PPPoE: Tag Length = 4 bytes
PPPoE: Data = Ox00000002
PPPoE:
.
.
.
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 5 arrived at 6:35:2.87
ETHER: Packet size = 60 bytes
ETHER: Destination = 8:0:20:78:f3:7c, Sun)
ETHER: Source      = 0:2:fd:39:7f:7, 
ETHER: Ethertype = 8864 (PPPoE Session)
ETHER:
PPPoE: ----- PPP Over Ethernet -----
PPPoE:
PPPoE: Version = 1
PPPoE: Type = 1
PPPoE: Code = 0 (PPPoE Session)
PPPoE: Session Id = 24383
PPPoE: Length = 20 bytes
PPPoE:
PPP: ----- Point-to-Point Protocol -----
PPP:
PPP-LCP: ----- Link Control Protocol -----
PPP-LCP:
PPP-LCP: Code = 1 (Configure Request)
PPP-LCP: Identifier = 80
PPP-LCP: Length = 18