10    ネットワークおよびネットワーク・サービスに関する問題の解決

この章では,ネットワークおよびネットワーク・サービス・ソフトウェアを使用する際に発生する問題を解決するための診断用マップについて説明します。 この章とともに適切なマニュアルを参照することにより,多くの問題をユーザ・レベルで解決することができます。

10.1 節10.2 節 には診断マップの使用方法と,マップ内での開始位置を問題の種類ごとに示しています。 それ以降の各節には診断マップがあり,次に挙げる各種の接続に関する問題を解決するための方法を説明しています。

10.1    診断マップの使用方法

ネットワークおよびネットワーク・サービスに関する問題は,さまざまな原因によって発生します。 この章の診断マップは,問題の原因を特定するために役立ちます。 同様の診断マップは,『ネットワーク管理ガイド:サービス編』にも記載されています。 次の図に,診断マップの使用方法を示します。

図 10-1:  診断マップの使用方法

問題を切り分けた後,診断マップは,さまざまな問題解決ツールやユーティリティの使用方法について他の章を参照するように指示します。 また,場合によっては,特定のデバイスやソフトウェア製品のマニュアルを参照するよう指示します。

レイヤード・ソフトウェアを通してネットワークおよびネットワーク・サービス・ソフトウェアを使用している場合には,本書で説明していない問題が発生する場合があります。 詳しい情報については,該当する製品のマニュアルを参照してください。

10.2    準備

問題の解決を開始する前に,通信ハードウェアが使用できる状態になっていることを確認してください。 次のことを確認します。

既知の問題に関する最新の情報については,各製品のリリース・ノートを参照してください。

IPv6 ネットワークで発生した問題に効率的に対処するためには,次の用語も十分理解してから,問題解決を行ってください。

オンリンク・ノード

使用しているシステムと同じサブネットワークに接続されているノード。 この場合のサブネットワークとは,LAN,PPP のシリアル接続,IPv6 over IPv4 構成済みトンネルのいずれかです。 使用しているシステムとオンリンク・ノードとの間には IPv6 ルータは存在しません。 構成済みトンネルの場合には,トンネルの接続先側のノードがオンリンク・ノードです。

オフリンク・ノード

使用しているシステムと同じサブネットワークには接続されていないノード。 システムとオフリンク・ノードとの間には,少なくとも 1 つの IPv6 ルータが存在します。

図 3-4 では,ホスト A がユーザのシステムだとすると,ホスト B がオンリンク・ノード,ホスト C とホスト D がオフリンク・ノードになります。

表 10-1は,問題解決の際に,まず診断マップのどの部分を参照すればよいかを示しています。

表 10-1:  問題解決のスタート・ポイント

問題の種類 スタート・ポイント
uucp コマンドのエラー

ネットワーク管理ガイド:サービス編』の「UUCP に関する問題の解決」

ネットワーク・コマンドのエラー

10.8 節 (SLIP 接続を使用している場合)

10.9 節 (PPP 接続を使用している場合)

10.3 節

10.4 節

ATM ネットワークへの接続

10.6 節

10.6.1 項 (Classical IP を使用している場合)

10.6.2 項 (LANE を使用している場合)

10.6.3 項 (IP 交換を使用している場合)

10.3 節

10.4 節

DHCP を使用しての IP アドレスの取得

10.7 節

10.3 節

10.4 節

NTP を使用している場合にシステム時間を修正

ネットワーク管理ガイド:サービス編』の「NTP に関する問題の解決」

ホスト名情報の取得

ネットワーク管理ガイド:サービス編』の「DNS/BIND クライアントに関する問題の解決」(DNS/BIND を使用している場合)

ネットワーク管理ガイド:サービス編』の「NIS クライアントに関する問題の解決」(NIS を使用している場合)

ファイルへのアクセス

ネットワーク管理ガイド:サービス編』の「NFS クライアントに関する問題の解決」(NFS を使用している場合)

ネットワーク管理ガイド:サービス編』の「AutoFS に関する問題の解決」(AutoFS を使用している場合)

10.3 節

10.4 節

LAT を使用したホストへの接続 10.10 節
未知のエラー 10.3 節
未知の IPv6 エラー 10.4 節
メールの送信または受信

ネットワーク管理ガイド:サービス編』の「sendmail に関する問題の解決」

ネットワーク管理ガイド:サービス編』の「POP および IMAP に関する問題の解決」(メール・システムに POP または IMAP を使用している場合)

10.3    IPv4 ネットワークに関する問題の解決


システムに電源を入れます。 システムのマニュアルを参照して,スタートアップ手順および問題解決の方法について確認してください


Network Information Service (NIS) を実行していて,NIS デーモンを起動した後,リモート・ファイル・システムをマウントする前にシステムがハングする場合は,ypbind 要求に応答する NIS サーバがありません。 ドメイン内に NIS サーバがあることがわかっている場合は,サーバが応答するまで待ちます。 ブート・プロシージャは続行されます。

Local Area Transport (LAT) に問題がある場合は,次のメッセージが表示されます。

getty: cannot open "/dev/ttyxx"

LAT に関する問題の解決手順については,10.10 節を参照してください。

ご使用のシステムが Network File System (NFS) クライアントで,リモート・ファイル・システムまたはディレクトリのマウント中にハングする場合は,次の手順に従ってください。

  1. システムとネットワーク間のケーブルおよび接続部を調べます。

  2. ネットワーク上の,/etc/fstab ファイルに記述されているサーバが,すべて使用可能になるまで待ちます。 システムは,その後でブートを続行します。

  3. NFS サーバが停止している場合にクライアント・システムをブートするには,次の手順に従ってください。

    1. システムを停止します。

    2. シングルユーザ・モードでシステムをブートし,ローカル・ファイル・システムで fsck コマンドを実行します。

    3. /etc/fstab ファイルを編集し,bg (バックグラウンド) オプションをサーバのエントリに追加します。 詳細は, fstab(4) および mount(8) を参照してください。

    4. 次のコマンドを使用してシステムをリブートします。

      # /sbin/reboot
      

      fstab ファイルのエントリに bg オプションが指定されている場合は,サーバが起動して NFS サーバとして機能し始めると,リモート・ファイル・システムまたはディレクトリが自動的にマウントされます。


ネットワークが構成されたどうか見るためには,次の手順に従ってください。

  1. 使用しているシステムがこの環境では初めてであり,ネットワーク上で使用するために最近システムを構成した場合,ネットワーク・アダプタ・モードがコンソール・レベルで正しく設定されているかどうか確認します。 たとえば,10base2 イーサネット・ネットワークを持っているにもかかわらず,システムが 10baseT イーサネットを使用するように構成されている場合,適切なコンソール値に設定されるまでシステムはネットワークの確認に失敗します。 詳細については,『インストレーション・ガイド』 にある,フル・インストレーションにあらかじめ必要なタスクを参照してください。

  2. rcmgr ユーティリティを使用して,/etc/rc.config ファイル内の NUM_NETCONFIG エントリの値を表示します。

    # rcmgr get NUM_NETCONFIG
    

    値が 0 の場合は,ネットワークを構成するために SysMan Menu ユーティリティを実行します。 詳しくは,2.3 節 を参照してください。


ネットワーク・デーモン (inetd) が実行されていることを確認します。 次のコマンドを入力します。

# ps -e | grep inetd

実行中の inetd デーモンがない場合は,次のコマンドを使用して inetd デーモンを起動します。

# /sbin/init.d/inetd start


リモート・ホストのネットワークに到達できない場合は,次のメッセージが表示されます。

network is unreachable

次の手順に従ってください。

  1. netstat -i コマンドを使用して,ローカル・ホストのネットワーク・デバイスが適切に構成されていることを確認します。 ネットワーク・デバイスの構成についての説明は,2.3 節を参照してください。

  2. netstat -r コマンドを使用して,ローカル・ホストのルーティング・テーブルが正しいことを確認します。

  3. 各インターネット・プロトコル (IP) ルータのルーティング・テーブルのパスをトレースして,リモート・ホストのネットワークのエントリがあることを確かめます。 IP ルータのルーティング・テーブルの正しくない部分は修正します。 この手順を実行するには,ネットワーク・トポロジについての完全な知識が必要です。

  4. リモート・ホストに対する,ローカル・ホストのアドレスから名前への変換が正しいことを確認します。 「[ホストを認識できる ?]」の解決手順を参照してください。

  5. リモート・ホストへのパスにあるすべてのルータを調べ,それらのセキュリティ機能が有効になっているためにリモート・ホストに到達できないのかどうかを調べます。


リモート・ホストが未知の場合は,次のメッセージが表示されます。

unknown host

次の手順に従ってください。

  1. 有効なホスト名を使用してリモート・ホストに到達しようとしているかどうかを確かめます。

  2. リモート・ホストが別の名前ドメインに属していないか,またはユーザがフル・ドメイン名を指定しているかを確かめます。

  3. サイトが,名前からアドレスへの変換に DNS (Domain Name System) を使用している場合は,/etc/svc.conf ファイルを調べ,hosts データベース・エントリのサービスとして bind が指定されているかどうかを確かめます。 指定されていない場合は,/etc/svc.conf ファイルを編集して,そのエントリを追加します。 また,DNS サービスがリモート・ホストについての情報を持っているかどうかを確認します。 『ネットワーク管理ガイド:サービス編』の「DNS/BIND クライアントに関する問題の解決」で説明されている手順を参照してください。

  4. サイトが,名前からアドレスへの変換に NIS ネーム・サービスを使用している場合は,/etc/svc.conf ファイルを調べ,hosts データベース・エントリのサービスとして yp (NIS) が指定されているかどうかを確かめます。 指定されていない場合は,/etc/svc.conf ファイルを編集して,そのエントリを追加します。 また,NISサービスがリモート・ホストについての情報を持っているかどうかを確認します。 『ネットワーク管理ガイド:サービス編』の「NIS クライアントに関する問題の解決」で説明されている手順を参照してください。

  5. /etc/svc.conf ファイルにリストされている名前からアドレスへの変換メカニズムが local だけの場合は,/etc/hosts ファイルにはリモート・ホストについての情報がありません。 詳細については, svc.conf(4) を参照してください。


リモート・ホストに到達できない場合は,次のメッセージが表示されます。

host is unreachable

次の手順に従ってください。

  1. ローカル・ホストとネットワーク間のケーブル接続を確かめます。

  2. ping コマンドを使用して,リモート・ホストが実行されていることを確認します。

  3. netstat -i コマンドを使用して,ローカル・ホストのネットワーク・デバイスが適切に構成されていることを確認します。 ネットワーク・デバイスの構成についての説明は,2.3 節を参照してください。

  4. netstat -r コマンドを使用して,ローカル・ホストのルーティング・テーブルが正しいことを確認します。 ping コマンドを使用して,IP ルータが到達可能であるかどうかを確認します。

  5. リモート・ホストに対するローカル・ホストのアドレス-名前変換が正しいことを確かめます。 「[ホストを認識できる ?]」の解決手順を参照してください。

  6. リモート・ホストへのパスにあるすべてのルータを調べ,それらのセキュリティ機能が有効になっているためにリモート・ホストに到達できないのかどうかを判断します。


コマンド rcp または rsh を使用してファイルにアクセスできない場合は,次のメッセージが表示されます。

permission denied

次の手順に従ってください。

  1. ユーザがリモート・ホストへアクセスしようとしたのかどうかを確かめます。 リモート・ホストは,リモートからのアクセスを意図的に禁止していることがあります。

  2. 正しいホスト定義およびユーザ定義がリモート・ホストのユーザの .rhosts ファイルにあることを確かめます。

  3. /etc/hosts.equiv ファイルが正しく設定されていることを確かめます。

  4. リモート・システムの .rhosts ファイルにコピーされたディレクトリ,およびファイルの保護が正しいことを確かめます。

NFS を使用している場合は,『ネットワーク管理ガイド:サービス編』に記載されている NFS に関する問題解決の情報を参照してください。

まだ問題がある場合は,サービス担当者に報告してください (第 12 章 参照)。

接続が切断されると,次のメッセージが表示されます。

connection timed out

次の手順に従ってください。

  1. ネットワークをテストして,問題が,ローカル・ホスト,リモート・ホスト,またはその 2 つの間にあるホストのうちのどこにあるかを調べます。 ネットワークのテストについての詳細は,第 11 章を参照してください。

  2. 問題のあるホストを発見したら,次の手順に従ってください。

    1. ネットワーク・デバイスが適切に構成されていることを確認します。 ローカル・ホストのブロードキャスト・アドレスおよびアドレス・マスクが正しいことを確認します。 ネットワーク・デバイスの構成上の情報については,2.3 節 を参照してください。

    2. ローカル・ホストの /etc/hosts ファイルに,ローカル・ホストの正しい IP アドレスがあることを確認します。

    3. ローカル・ホストからネットワークへのケーブル接続が損なわれることなく適切に行われていることを確認します。

    4. ローカル・エリア・ネットワーク (LAN) で接続している場合には,アドレス解決プロトコル (ARP) のエントリが正しいこと,およびシステムが LAN に正しく接続されていることを確認します。

    5. ワイド・エリア・ネットワーク (WAN) で接続している場合には,システムが WAN に正しく接続されていること,およびモデムが正常に動作していることを確認します。

10.4    IPv6 ネットワークに関する問題の解決


システムに電源を投入します。 システムのスタートアップ手順と問題解決については,システムのマニュアルを参照してください。


ブート時にネットワーク関連のエラーや警告が表示された場合には,次の手順で対処します。

  1. 次のコマンドを実行し,システムのブート時に IPv6 を使用不能にします。

    # rcmgr set IPV6 "no"
    

  2. システムをリブートします。 問題が解決しない場合には,10.3 節に進んでください。

  3. 次のコマンドを実行して,IPv6 を起動します。

    # /usr/sbin/rcinet inet6
    

    同じ問題が発生するようであれば,誤りがないか /etc/rc.config ファイル,/etc/ip6rtrd.conf ファイル,および /etc/routes ファイルの内容をチェックしてください。


必要な IPv6 サポートがカーネルに構成されていることを確認します。 次のコマンドを実行します。

# sysconfig -s ipv6 | grep configured

何も表示されない場合には,IPv6 オプションはカーネルに構成されていません。 doconfig コマンドを使用してカーネルを再構成します。 詳細については,3.6.1 項を参照してください。

構成済みトンネルを使用する場合には,IP トンネルのサポートがカーネルに構成されているかどうかを確認します。 次のコマンドを実行します。

# sysconfig -s iptunnel |  grep configured

何も表示されない場合には,IPTUNNEL オプションはカーネルに構成されていません。 doconfig コマンドを使用してカーネルを再構成します。 詳細については,3.6.1 項を参照してください。


rcmgr get IPV6 コマンドを実行し,IPv6 がシステムのブート時に起動するように構成されていることを確認します。 IPv6 が構成されている場合には,yes が表示されます。

IPv6 が構成されていない場合には,ip6_setup ユーティリティを使用します。 IPv6 のホストやルータの設定方法については,3.7 節を参照してください。

IPv6 ホストに問題がある場合は 10.4.1 項,IPv6 ルータに問題がある場合は 10.4.2 項,Mobile IPv6 に問題がある場合は 10.4.3 項 に進みます。

次のコマンドを実行し,IPv6 が起動したことを確認します。

# ping ::1

host is unreachable というメッセージが表示された場合には,次のコマンドを実行して IPv6 を起動します。

# /usr/sbin/rcinet start inet6

このコマンドは IPv6 インタフェースを作成して立ち上げ,IPv6 デーモンを起動します。

10.4.1    IPv6 ホストに関する問題の解決


次のコマンドを実行して,nd6hostd デーモンが動作しているか確認します。

# ps ax | grep nd6hostd

このデーモンが動作していない場合には,次のコマンドを実行して,システムが IPv6 ホストとして構成されているか確認します。

# rcmgr get ND6HOSTD

yes と表示されない場合には,ip6_setup ユーティリティを実行して,システムを IPv6 ホストとして構成します。 構成の完了後,次のコマンドを実行して IPv6 を再起動します。

# /usr/sbin/rcinet restart inet6

yes が表示された場合には,次のコマンドを実行して,nd6hostd デーモンのデバッグ機能を使用可能にします。

# rcmgr set ND6HOSTD_FLAGS "-d -l /usr/tmp/nd6hostd.log"

IPv6 を再起動します。


リモート・ホストが未知の場合には,次のメッセージが表示されます。

unknown host

次の手順で対処します。

  1. リモート・ホストに到達できる有効なノード名を使用しているか確認します。

  2. そのリモート・ノードが他のネーム・ドメインに属していることと,ユーザが完全ドメイン名を指定したことを確認します。

  3. 名前からアドレスへの変換に DNS/BIND ネーム・サービスを使用しているサイトでは,/etc/svc.conf ファイルの内容を調べ,hosts データベース・エントリ用のサービスとして bind が指定されているか確認します。 指定されていない場合には,システムを DNS/BIND クライアントとして構成します。 詳細については,『ネットワーク管理ガイド:サービス編』を参照してください。

    システムで IPv4 を実行しているか確認します。 IPv4 を実行していない場合には,名前からアドレスへの変換にローカルの /etc/ipnodes ファイルを使用します。

    さらに,リモート・ノードに関する情報を DNS/BIND サービスが保有しているか確認します。 『ネットワーク管理ガイド:サービス編』の「DNS/BIND クライアントに関する問題の解決」の手順を参照してください。

  4. 名前からアドレスへの変換に NIS ネーム・サービスのみを使用しているサイトでは,ノード名用に別のサービスを使用する必要があります。 これは,NIS が IPv6 アドレスをサポートしていないためです。

    /etc/svc.conf ファイルを編集して,hosts データベース用のサービスとして,bind (DNS/BIND) または local (/etc/ipnodes ファイル) を追加します (リモート・ノードに関する情報を保有しているサービスの方を追加します)。

  5. /etc/svc.conf ファイル内で名前からアドレスへの変換メカニズムとして local のみを指定している場合には,/etc/ipnodes ファイルを編集して,ノード名とアドレスが存在し正しいことを確認します。 必要に応じて追加や修正をします。

    また,ファイル内の編集箇所より前の各行にフォーマット・エラーが存在しないことを確認します。 先頭のエントリから順に,指定されている各ノードに対して ping コマンドを実行して,フォーマット・エラーをチェックします。


オンリンク・ノードに到達できない場合には,次のいずれかのメッセージが表示されます。

host is unreachable
network is unreachable
timeout

オンリンク・ノードのホストまたはルータが存在する場合,ping コマンドを使用して,到達できるか確認します。 コマンドに対して応答がないか,紛失するパケットが多い場合には,次の手順で対処します。

  1. ノードが LAN に接続されている場合には,netstat -I device -s コマンドを使用して,データリンクのカウンタを調べます。 調べるカウンタと,考えられる原因は次のとおりです。

    • 送信ブロック数または受信ブロック数がゼロの場合,ネットワーク・ハードウェアやケーブルに問題があると考えられます。

    • 高い衝突率は,ネットワークのケーブル接続が不適切であるか,ノードが過度のメッセージ・トラフィックを送信していることが考えられます。

    • データ・オーバランによるエラーと,バッファが利用できないというエラーは,システムの構成が不適切であることを示しています。

  2. IPv6 と ICMPv6 のカウンタを,netstat -p ipv6 コマンドと netstat -p ipv6-icmp コマンドを使用して調べます。 調べるカウンタと,考えられる原因は次のとおりです。

    • ICMP エラーによって発生したエラーによって破棄されたパケットは,他のノードが不正なメッセージを生成していることを示します。 他のカウンタに,より詳しい情報が表示されます。

    • 割り当てエラーは,過度のメッセージ・トラフィック,不適切なシステム構成,またはメモリを解放せずに繰り返し割り当てを行っているプログラムの存在を示します。

  3. IPv6 ネットワーク・インタフェースが存在し,使用可能であり,inet6 アドレスを持っていることを,ifconfig -a コマンドを使用して確認します。 IPv6 ネットワーク・インタフェースに問題がある場合には,/etc/rc.config ファイル内の構成変数が正しいか確認します。 エラーを修正するには,ip6_setup ユーティリティを実行します。

    さらに,/var/adm/syslog.dated/current/daemon.log ファイル内で,nd6hostd エラーの有無を調べます。 詳細については,11.9 節を参照してください。

    インタフェースがグローバル・アドレスやサイト・ローカル・アドレスを持たない場合には,ローカル・ルータがリンク上でプレフィックスを通知しているかどうかをネットワーク管理者に依頼して確認してください。 ローカル・ルータがない場合は,ifconfig コマンドを使用してプレフィックスを定義できます (3.8.5 項 を参照)。

  4. オンリンク・ノードが起動して動作していること,IPv6 用に正しく構成されていること,および使用しているアドレスがノード・インタフェース上で使用可能になっていることを,オンリンク・システムの管理者に依頼して確認します。

  5. 両方のシステムに IPv4 が構成されている場合には,オンリンク・ノードの IPv4 アドレスに対して ping コマンドを実行します。 このコマンドが成功した場合は,両方のシステム上で IPv6 構成の確認を行います。 このコマンドに対して応答がない場合は,IPv4 ネットワークの問題を解決する必要があります。 10.3 節の手順を参照してください。

  6. 同じリンク上の他のノードに対して ping コマンドを実行し,問題が 1 つのノードだけで発生するのか,他のノードでも発生するかを調べます。 問題が発生しない部分もある場合は,ネットワーク・デバイスや,リンク上のケーブルに障害が発生している可能性があります。

  7. リンクが構成済みトンネルである場合には,次の手順を実行します。

    1. ifconfig -a コマンドを使用して,トンネルの接続元アドレスと接続先アドレスを確認します。 トンネルの接続先側ノードの管理者に連絡し,そのノードの接続先/接続元アドレスが,自分の接続元/接続先アドレスと一致しているか確認します。

    2. トンネルの接続先アドレスに対して ping コマンドを実行します。 このコマンドに対して応答がない場合には,IPv4 ネットワークの問題を解決する必要があります。 10.3 節の手順を参照してください。


オフリンク・ノードに到達できない場合には,次のいずれかのメッセージが表示されます。

host is unreachable
network is unreachable
timeout

ping コマンドを使用して,オフリンク・ノードに到達できるか確認します。 パケットの紛失率が 100% の場合には,次の手順を実行します。

  1. ping コマンドを使用して,自分のシステムとオンリンク・ルータとの接続を確認します。 このコマンドに対して応答がないか,紛失するパケットが多い場合は,[オンリンク・ノードに到達できる ?]の手順に従ってください。 ルータのアドレスを調べるには,次のコマンドを実行します。

    # ping -I interface ff02::2
    

  2. メッセージ送信に使用しているインタフェースに,使用可能なグローバル・ユニキャスト・アドレスまたはサイト・ローカル・ユニキャスト・アドレスがあるかを,ifconfig -a コマンドで確認します。 使用可能なユニキャスト・アドレスがない場合には,ローカル・ルータがリンク上でプレフィックスを通知しているかどうかを,ネットワーク管理者に依頼して確認してください。

    リンクが構成済みトンネルであり,ローカル・ルータがアドレス・プレフィックスの通知を行っていない場合には,ip6_setup ユーティリティを使用してトンネル用のプレフィックスを手動で定義できます。 詳細については,3.7.1 項を参照してください。

  3. リモート・システムが起動して正しく動作していること,IPv6 用に正しく構成されていること,および自分のシステムで使用している IPv6 アドレスとリモート・システムのインタフェースの IPv6 アドレスが一致することを,リモート・システムの管理者に依頼して確認します。 アドレスが異なる場合には,/etc/ipnodes ファイルの内容を確認するか,リモート・システムの管理者に DNS エントリが正しいことを確認するように依頼します。

  4. netstat -rf inet6 コマンドを使用して,ネットワーク上のルータへの省略時の経路 (U フラグと G フラグが設定された経路) が存在するかどうかを確認します。 存在しない場合には,そのルータが自分を省略時のルータとして通知しているかを,ルータ管理者に依頼して確認します。

    さらに他のルータもチェックして,誤ったパスにメッセージが送られていないか確認します。

  5. traceroute コマンドを使用して,オフリンク・ノードへのパスをトレースします。 詳細については,11.6 節traceroute(8) を参照してください。

紛失するパケットが多い場合には,ネットワークが混雑しているか,断続的にルーティングの問題が発生している可能性があります。 次の手順に従います。

  1. ping コマンドを使用して,自分のシステムとオンリンク・ルータとの接続を確認します。

  2. traceroute コマンドを使用して,オフリンク・ノードへのパスをトレースします。 詳細については,11.6 節traceroute(8) を参照してください。


他のノードから到達できないという報告を受けた場合には,次の手順に従います。

  1. ping コマンドを使用して,相手のノードに到達できるか確認します。 このコマンドに対して応答がない場合には,そのノードの位置に応じて,[オンリンク・ノードに到達できる ?]または[オフリンク・ノードに到達できる ?]の手順に従います。

  2. 相手が DNS データベース内の名前を使用している場合には,DNS データベースに格納されている自分のノードのアドレスが,システムのインタフェースに構成されているアドレスのいずれかと一致することを確認します。 DNS からアドレスを取り出すには nslookup -type=AAAA node-name コマンドを使用し,システムのアドレスを表示するには ifconfig -a コマンドを使用します。

  3. 相手のノードが,相手のローカル /etc/ipnodes ファイルで定義したアドレスを使用している場合には,そのアドレスと,自分のシステムのインタフェースに構成されているアドレスを比較します。 ifconfig -a コマンドを使用します。


アプリケーションからの接続を受け入れるようにリモート・ノードが構成されていない場合は,次のメッセージが表示されることがあります。

connection refused

リモート・ノードのシステム管理者に,正しいソケット・ベースのサービス定義が /etc/services ファイルと /etc/inetd.conf ファイルに定義されているか確認するように依頼します。 定義がないか,コメント・アウトされている可能性があります。

ローカルの /etc/inetd.conf ファイル内のサービスのプロトコル・フィールドに tcp6 または udp6 があるか確認します。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章を参照。

接続が異常終了したり,ネットワーク・アプリケーションがハングアップする場合には,次の手順に従います。

  1. 障害の発生後,直ちに ping コマンドを実行し,リモート・ノードとのネットワーク接続を確認します。

    ping コマンドに対して応答がないか,パケット紛失率が高い場合には,そのノードの位置に応じて,[オンリンク・ノードに到達できる ?]または[オフリンク・ノードに到達できる ?]の手順に従います。

  2. アプリケーションが大量のデータをネットワーク送信する場合には,ping -s 2000 nodename コマンドを使用して,大きなメッセージや分割されたメッセージが正しく処理されているか確認します。

    ping コマンドに対して応答がない場合には traceroute nodename 1200 コマンドを実行し,リモート・ノードへのパスを,1200 バイト長のパケットを使用してトレースします。 すべての IPv6 リンクは,少なくとも 1280 バイトのメッセージ・サイズをサポートしなければなりません。 このコマンドによって,ネットワーク上で問題が発生している位置を特定できることもあります。 詳細については,11.6 節traceroute(8) を参照してください。

  3. ネットワーク上の他のリンクにある他のクライアント・ノードとサーバ・ノードで,同じアプリケーションを実行します。

10.4.2    IPv6 ルータに関する問題の解決


次のコマンドを実行して,ip6rtrd デーモンが動作しているか確認します。

# ps ax | grep ip6rtrd

ip6rtrd デーモンが動作していない場合には次のコマンドを実行して,システムが IPv6 ルータとして構成されているかどうかを確認します。

# rcmgr get IP6RTRD

yes と表示されない場合には,ip6_setup ユーティリティを実行して,システムを IPv6 ルータとして構成します。 構成の完了後,次のコマンドを実行して IPv6 を再起動します。

# /usr/sbin/rcinet restart inet6

yes と表示された場合には,次のコマンドを実行して,ip6rtrd デーモンのデバッグ機能を使用可能にします。

# rcmgr set IP6RTRD_FLAGS "-d -l /usr/tmp/ip6rtrd.log /etc/ip6rtrd.conf"

IPv6 を再起動します。


リモート・ノードが未知の場合には,次のメッセージが表示されます。

unknown host

次の手順を実行します。

  1. リモート・ノードに到達できる正しいノード名を使用しているか確認します。

  2. そのリモート・ノードが他のネーム・ドメインに属していること,および完全ドメイン名を指定してアクセスを試みたことを確認します。

  3. 名前からアドレスへの変換に DNS/BIND ネーム・サービスを使用しているサイトでは,/etc/svc.conf ファイルを参照して,hosts データベース・エントリ用のサービスとして bind が指定されているか確認します。 bind が指定されていない場合には,システムを DNS/BIND クライアントとして構成します。 詳細については,『ネットワーク管理ガイド:サービス編』を参照してください。

    システムで IPv4 を実行しているか確認します。 IPv4 を実行していない場合には,名前からアドレスへの変換に,/etc/ipnodes ファイルを使用します。

    さらに,リモート・ノードに関する情報を DNS/BIND サービスが保有しているか確認します。 『ネットワーク管理ガイド:サービス編』の「DNS/BIND クライアントの問題解決」を参照してください。

  4. 名前からアドレスへの変換に NIS ネーム・サービス (yp) のみを使用しているサイトでは,ノード名用に別のサービスを使用する必要があります。 これは,NIS が IPv6 アドレスをサポートしていないためです。

    /etc/svc.conf ファイルを編集して,hosts データベース用のサービスとして,bind (DNS/BIND) または local (/etc/ipnodes ファイル) を追加します(リモート・ノードに関する情報を保有しているサービスの方を追加します)。

    また,ファイル内の編集箇所より前の行にフォーマット・エラーが存在しないことを確認します。 先頭のエントリから順に,指定されている各ノードに対して ping コマンドを実行して,フォーマット・エラーをチェックします。

  5. /etc/svc.conf ファイル内で名前からアドレスへの変換メカニズムとして local のみを指定している場合には,/etc/ipnodes ファイルを編集して,ノード名とアドレスが存在し正しいことを確認します。 必要に応じて追加や修正をします。


オンリンク・ノードに到達できない場合には,次のいずれかのメッセージが表示されます。

host is unreachable
network is unreachable
timeout

オンリンク・ノードまたはルータが存在する場合,ping コマンドを使用して,到達できるか確認します。 このコマンドに対する応答がないか,紛失するパケットが多い場合には,次の手順を実行します。

  1. ノードが LAN に接続されている場合には,netstat -I device -s コマンドを使用して,データリンクのカウンタを調べます。 調べるカウンタと,考えられる原因は次のとおりです。

    • 送信ブロック数または受信ブロック数がゼロの場合,ネットワーク・ハードウェアやケーブルに問題があると考えられます。

    • 高い衝突率は,ネットワークのケーブル接続が不適切であるか,ノードが過度のメッセージ・トラフィックを送信していることが考えられます。

    • データ・オーバランによるエラーと,バッファが利用できないというエラーは,システムの構成が不適切であることを示しています。

  2. IPv6 と ICMPv6 のカウンタを,netstat -p ipv6 コマンドと netstat -p ipv6-icmp コマンドを使用して調べます。 調べるカウンタと,考えられる原因は次のとおりです。

    • ICMP エラーによって発生したエラーによって破棄されたパケットは,他のノードが不正なメッセージを生成していることを示します。 他のカウンタに,より詳しい情報が表示されます。

    • 割り当てエラーは,過度のメッセージ・トラフィック,不適切なシステム構成,またはメモリを解放せずに繰り返し割り当てを行っているプログラムの存在を示します。

  3. IPv6 ネットワーク・インタフェースが存在し,動作しており,inet6 アドレスを持っていることを,ifconfig -a コマンドを使用して確認します。 IPv6 ネットワーク・インタフェースに問題がある場合には,/etc/rc.config ファイルと /etc/ip6rtrd.conf ファイルが正しいか確認します。

    さらに,/var/adm/syslog.dated/current/daemon.log ファイル内で,ip6rtrd エラーの有無を調べます。 詳細については,11.9 節を参照してください。

    エラーを修正するには,ip6_setup ユーティリティを実行します。

  4. オンリンク・ノードが起動して動作していること,IPv6 用に正しく構成されていること,および使用しているアドレスがノードのインタフェース上で使用可能になっていることを,オンリンク・ノードの管理者に依頼して確認します。

  5. 両方のシステムに IPv4 が構成されている場合には,オンリンク・ノードの IPv4 アドレスに対して ping コマンドを実行します。 このコマンドが成功した場合は,両方のシステム上で IPv6 構成の確認を行います。 このコマンドに対して応答がない場合は,IPv4 ネットワークの問題を解決する必要があります。 10.3 節の手順を参照してください。

  6. 同じリンク上の他のノードに対して ping コマンドを実行し,問題が 1 つのノードだけで発生するのか,他のノードでも発生するかを調べます。 問題が発生しない部分もある場合は,ネットワーク・デバイスや,リンク上のケーブルに障害が発生している可能性があります。

  7. リンクが構成済みトンネルである場合には,次の手順を実行します。

    1. ifconfig -a コマンドを使用して,トンネルの接続元アドレスと接続先アドレスを確認します。 トンネルの接続先側ノードの管理者に連絡し,そのノードの接続先/接続元アドレスが,自分の接続元/接続先アドレスと一致しているか確認します。

    2. トンネルの接続先アドレスに対して ping コマンドを実行します。 このコマンドに対して応答がない場合には,IPv4 ネットワークの問題を解決する必要があります。 10.3 節の手順を参照してください。


オフリンク・ノードにアクセスできない場合には,次のいずれかのメッセージが表示されます。

host is unreachable
network is unreachable
timeout

ping コマンドを使用して,オフリンク・ノードに到達できるか確認します。 パケットの紛失率が 100% の場合には,次の手順を実行します。

  1. ping コマンドを使用して,オフリンク・ノードへのパス上にある次のルータとの接続を確認します。 このコマンドに対して応答がないか,紛失するパケットが多い場合は,[オンリンク・ノードに到達できる ?]の手順に従ってください。

  2. メッセージ送信に使用しているインタフェースに,使用可能なグローバル・ユニキャスト・アドレスまたはサイト・ローカル・ユニキャスト・アドレスがあるかを,ifconfig -a コマンドで確認します。 使用可能なユニキャスト・アドレスがない場合には,/etc/ip6rtrd.conf ファイル ( ip6rtrd.conf(4) を参照) 内でインタフェース・アドレス・プレフィックスが定義されているか確認します。 プレフィックスを修正するには,ip6_setup ユーティリティを使用します。

  3. リモート・システムが起動して正しく動作していること,IPv6 用に正しく構成されていること,および自分のシステムで使用している IPv6 アドレスとリモート・システムのインタフェースの IPv6 アドレスが一致することを,リモート・システムの管理者に依頼して確認します。 アドレスが異なる場合には,ホスト・データベースを確認してください。

パケット紛失率が高い場合には,ネットワークが混雑しているか,断続的にルーティングの問題が発生している可能性があります。 次の手順に従います。

  1. ping コマンドを使用して,自分のシステムとオンリンク・ルータとの接続を確認します。

  2. traceroute コマンドを使用して,オフリンク・ノードへのパスをトレースします。 詳細については,11.6 節traceroute(8) を参照してください。


IPv6 ホストは,リンク上のルータから提供されたアドレス・プレフィックスを使用して,自分のグローバル・ユニキャスト・アドレスおよびサイト・ローカル・ユニキャスト・アドレスを自動的に生成します。 オンリンク・ノードが自分のアドレスを自動構成できない場合には,次の手順に従います。

  1. ホストのリンク・ローカル・アドレスを指定して ping コマンドを実行し,ルータからホストへ到達できるか確認します。 このコマンドに対して応答がないか,パケットの紛失率が高い場合には,[オンリンク・ノードに到達できる ?]の手順に従います。

  2. /etc/ip6rtrd.conf ファイルを編集して,正しいプレフィックスを通知するようにルータが構成されていること,タイマの値が適切であることを確認します。 詳細については,3.8.11 項ip6rtrd.conf(4) を参照してください。


メッセージ送信がルータで失敗しているようだという報告を他のネットワークのユーザから受けた場合,次の手順に従います。

  1. ルータが転送していないメッセージの送信元アドレスと宛先のアドレスを取得します。 そして ping コマンドを使用して,ルータが各ノードに到達できるか確認します。 どちらかのコマンドに対して応答がないか,パケットの紛失率が高い場合には,[オンリンク・ノードに到達できる ?]または[オフリンク・ノードに到達できる ?]の手順のうち,適切な方に従います。

  2. ルータが RIPng プロトコルを実行している場合は,次のコマンドを実行して,IPv6 ルータ・デーモンが動作していることを確認します。

    # ps ax | grep ip6rtrd
    

    このデーモンが動作している場合には,/etc/ip6rtrd.conf ファイルを編集して,各 IPv6 リンクで RIPng プロトコルが使用可能になっていることを確認します。 RIPng プロトコルを使用可能にしないと,ノードが経路を正しく通知できない可能性があります。

  3. 手動経路を使用しているインタフェースと RIPng 経路を使用しているインタフェースが混在していないことを確認します。 /etc/routes ファイルで定義された手動経路は,RIPng では他のルータに通知されません。


他のノードから到達できないという報告を受けた場合には,次の手順に従います。

  1. ping コマンドを使用して,相手のノードに到達できるか確認します。 このコマンドに対して応答がない場合には,そのノードの位置に応じて,[オンリンク・ノードに到達できる ?]または[オフリンク・ノードに到達できる ?]の手順に従います。

  2. 相手が DNS データベース内の名前を使用している場合には,DNS データベースに格納されている自分のノードのアドレスが,システムのインタフェースに構成されているアドレスのいずれかと一致することを確認します。 DNS からアドレスを取り出すには nslookup -type=AAAA node-name コマンドを使用し,システムのアドレスを表示するには ifconfig -a コマンドを使用します。

  3. 相手のノードが,相手のローカル /etc/ipnodes ファイルで定義したアドレスを使用している場合には,そのアドレスと,自分のシステムのインタフェースに構成されているアドレスを比較します。 ifconfig -a コマンドを使用します。


アプリケーションからの接続を受け入れるようにリモート・ノードが構成されていない場合は,次のメッセージが表示されることがあります。

connection refused

リモート・ノードのシステム管理者に,正しいソケット・ベースのサービス定義が /etc/services ファイルと /etc/inetd.conf ファイルに定義されているか確認するように依頼します。 定義がないか,コメント・アウトされている可能性があります。

ローカルの /etc/inetd.conf ファイル内のサービスのプロトコル・フィールドに tcp6 または udp6 があるか確認します。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

接続が異常終了したり,ネットワーク・アプリケーションがハングアップする場合には,次の手順に従います。

  1. 障害の発生後,直ちに ping コマンドを実行し,リモート・ノードとのネットワーク接続を確認します。

    ping コマンドに対して応答がないか,パケットの紛失率が高い場合には,そのノードの位置に応じて[オンリンク・ノードに到達できる ?]または[オフリンク・ノードに到達できる ?]の手順に従います。

  2. アプリケーションが大量のデータをネットワーク送信する場合には,ping -s 2000 nodename コマンドを使して,大きなメッセージや分割されたメッセージが正しく処理されているか確認します。

    ping コマンドに対して応答がない場合には traceroute nodename 1200 コマンドを実行し,リモート・ノードへのパスを,1200 バイト長のパケットを使用してトレースします。 すべての IPv6 リンクは,少なくとも 1280 バイトのメッセージ・サイズをサポートしなければなりません。 このコマンドによって,ネットワーク上で問題が発生している位置を特定できることもあります。 詳細については,11.6 節traceroute(8) を参照してください。

  3. ネットワーク上の他のリンクにあるクライアント・ノードとサーバ・ノードで,同じアプリケーションを実行します。

10.4.3    Mobile IPv6 に関する問題の解決


Mobile IPv6 のサポートがカーネル内に構成されていることを確認します。 次のコマンドを実行してください。

# sysconfig -q ipv6 mobileipv6_enabled

mobileipv6_enabled の属性が設定されていない場合,Mobile IPv6 はカーネル内に構成されていません。 正しいカーネルを実行しているか確認してください。 正しい場合,doconfig コマンドを使用してカーネルを再構成します。 詳細は 3.6.1 項 を参照してください。

mobileipv6_enabled 属性が設定されているが 1 でない場合は,次のコマンドで再設定します。

# sysconfig -r ipv6 mobileipv6_enabled=1
mobileipv6_enabled: reconfigured

次のコマンドを実行して IPv6 を再起動します。

# /usr/sbin/rcinet restart inet6

このコマンドは IPv6 とそのデーモンを停止させ,IPv6 インタフェースを作成して起動し,IPv6 デーモンを開始します。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

コレスポンデント・ノードに対して次のコマンドを実行して,コレスポンデント・ノードにモバイル・ノードに対するバインディングがあることを確認します。

# netstat -b | grep hostname

モバイル・ノードのエントリがなければ,コレスポンデント・ノードで次の手順を実行します。

  1. tcpdump を実行して,Binding Update および Acknowledgement のパケットを探します。 次の表に,拒否された Binding Updates の Status フィールドの値を示します (Status フィールドの値はゼロより大きな値になります)。

    Status の値 理由
    128 理由は不明
    130 管理者により禁止
    131 リソース不足
    132 ホームの登録がサポートされていない
    133 ホーム・サブネットではない
    136 インタフェース識別子の長さが正しくない
    137 このモバイル・ノードのホーム・エージェントではない
    138 DAD (Duplicate Address Detection) の失敗
    139 セキュリティ・アソシエーションがない
    141 シーケンス番号が小さすぎる

  2. 次のコマンドを実行して,デバッグを有効にします。

    # sysconfig -r ipv6 mobileip_debug=1
    mobileipv6_debug: reconfigured
    

    このコマンドは基本的なバインディングの追加,変更,削除のメッセージを表示します。 Mobile IPv6 のデバッグ・レベルについては sys_attrs_ipv6(5) を参照してください。

10.5    IPsec に関する問題の解決


IPsec サブセットがインストールされていることを確認します。 次のコマンドを入力してください。

# setld -i | grep OSFIPSECBASE

次のようなメッセージが表示されます。

OSFIPSECBASEnnn installed IPsec Base Components
   (Network-Server/Communications)

OSFIPSECBASE サブセットがインストールされていない場合は,setld コマンドでインストールします。 サブセットのインストールについては,『インストレーション・ガイド』 を参照してください。


IPsec を使用していないときにリモート・ホストに到達できない場合には,次のいずれかのメッセージが表示されます。

host is unreachable
network is unreachable
timeout

以下の手順を実行してください。

  1. ipsecd デーモンがローカル・システムとリモート・システムのどちらでも実行されておらず,どちらのシステムも IP セキュア・モードでないことを確認します。 Tru64 UNIX システムでは,次のコマンドを入力して IP セキュア・モードを確認します。

    # sysconfig -q ipsec ip_secured
    

    ip_secured の値が 0 の場合,システムは IP セキュア・モードではありません。 詳細は sys_attrs_ipsec(5) を参照してください。

  2. IPv4 接続の場合は, の[ホストに到達できる ?]の手順を参照してください。

  3. IPv6 接続の場合は, の[オンリンク・ノードに到達できる ?] および [オフリンク・ノードに到達できる ?]の手順を参照してください。

  4. ローカル・システムとリモート・システムがセキュア・ゲートウェイとして動作している場合は,各システムで IP 転送が有効になっていることを確認してください。


SysMan の IPsec アプリケーションを使用して,IPsec が構成されシステムの起動時に有効にされていることを確認します。 IPsec が構成され有効になっていれば,メイン・ウィンドウの「Enable IP Security (IPsec)」ボックスがチェックされています。

IPsec が構成されていず有効になっていない場合は,SysMan Menu の IPsec アプリケーションを使用します。 IPsec ホストやセキュア・ゲートウェイの設定については,4.7 節 を参照してください。


次のコマンドを実行して,ipsecd デーモンが実行されていることを確認します。

# ps ax | grep ipsecd

デーモンが実行されていなければ,次のコマンドで実行します。

# /sbin/init.d/ipsec start

IPsec が起動または再起動されると,次のようなメッセージが /var/adm/messages ファイルに出力されます。

Apr 18 13:53:18 host1 vmunix: IPSEC: Attaching to the TCP/IP stack

問題が発生した場合は,/var/adm/syslog.dated/current/auth.log ファイル内のメッセージを参照してください。 IPsec メッセージの一覧は,付録 B を参照してください。


事前共有鍵を使用した接続に失敗した場合は,次の手順を実行します。

  1. リモート・システム上で,IPsec が有効になり構成されていることを確認します。

  2. リモート・システムに対して ping コマンドを実行するか,または適切なポートおよびプロトコルを用いてリモート・システムにトラフィックを送信します。 失敗した場合は,/var/adm/syslog/dated/current/current/auth.log ファイルにエラーまたは警告メッセージが出力されていないか確認します。 たとえば,ESP プロトコルを用いた正常な接続では,次のようなログ・メッセージが出力されます。

    Jun  7 16:24:22 fddicon8 syslog: Phase-1 [initiator] done.
      Created SA between IDs ipv4(udp:500,[0..3]=16.140.64.106)
      and ipv4(udp:500,[0..3]=16.140.64.223).
    Jun  7 16:24:22 fddicon8 syslog: Phase-2 [initiator] done.
      Created 2 SA's by rule fddicon8-spaced(13):`ipsec 
      ipv4(any:0,[0..3]=16.140.64.106)<->ipv4(any:0,[0..3]=16.140.64.223)'
     
     
    

    ipsecd デーモンに対してデバッグと追加ログ・メッセージを有効にするには,次のコマンドを実行します。

    # rcmgr set IPSEC_ARGS "-d -m 2"
    

    次に,以下のコマンドで IPsec を停止して開始します。

    # /sbin/init.d/ipsec stop
    # /sbin/init.d/ipsec start
    

  3. netstat -X -v コマンドを実行して,リモート・システムとのフェーズ 1 (IKE) SA が確立されたことを確認します。 フェーズ 1 SA が確立されなかった場合は,両方のシステムの構成について以下の項目を確認します。

    • IPsec ポリシで正しい IP アドレスが使用され,それがシステムに構成されているアドレスに一致していることを確認します。 トンネル・モードを使用している場合,このアドレスはローカルおよびリモートのセキュア・ゲートウェイのアドレスになることもあります。 両方のシステムが,IPsec の保護が適用されるように構成されていることを確認してください。

    • セキュア・ゲートウェイ構成では,保護されているトラフィックの仕様が,両方のシステムで完全に一致していることを確認します。 たとえば,10.0.1.1/24 のサブネット仕様は 10.0.1.1 - 10.0.1.255 の範囲にも,10.0.0.27 のような特定のホストとも一致しません。

    • 接続の事前共有鍵が両方のシステムで完全に一致していることを確認します。 事前共有鍵が一致していないと,無効なペイロード・タイプやフォーマット・エラーなどとして報告されます。 これは IKE プロトコル・データの暗号が正しく解読されないためです。 また,ローカル ID がリモート・システムが想定しているものと一致していることも確認してください (通常は,ローカル・システムの,適切な IP アドレス)。

    • 事前共有鍵を使用する認証を指定するプロポーザルが IKE プロポーザル・リストに含まれ,プロポーザル内の他のパラメータがリモート・システムのパラメータに一致していることを確認します。

    • 接続に対して指定された IKE グループと PFS 設定が,リモート・システムが想定しているものと一致していることを確認します。 省略時は PFS を持たない IKE グループ 2 です。

    • 両方のシステムで同じ折衝モード (Main または Aggressive) が使用されていることを確認します。

    • 2 つのホストの間に,IKE (UDP のポート 500) トラフィックをブロックしたり衝突するような NAT (Network Address Translator) やファイアウォールがないことを確認します。

  4. 1 つまたは複数のフェーズ 2 (IPsec) SA が,netstat -x -v コマンドを用いてリモート・システムとの間に確立されていることを確認します。 フェーズ 2 SA が 1 つも確立されていない場合は,両方のシステムの構成について以下の項目を確認してください。

    • IPsec プロポーザル・リストに,リモート・システム上のプロポーザルと一致するプロポーザルが少なくとも 1 つ含まれていることを確認します。

    • 接続に関する PFS 設定がリモート・システムでの設定と一致し,PFS が使用中であれば PFS グループが一致していることを確認します。

    • ローカル・システムとリモート・システムの SA 存続期間が一致していることを確認します。 多くの場合,省略時の値として,要求される最短の存続期間になっています。 ただし,IPsec の実装によっては,両方のシステムで同じ値にしたり,特定の範囲内の値にする必要があります。

  5. フェーズ 1 とフェーズ 2 の SA がどちらも確立されている場合は,2 つのホストの間に,IPsec 保護 (AH または ESP) トラフィックをブロックしたり衝突するような NAT やファイアウォールがないことを確認します。

  6. /var/adm/syslog.dated/current/auth.log ファイル内のメッセージが問題を示している場合は,IPsec SysMan アプリケーションを用いてセキュリティ・ポリシを変更する必要があります。 アプリケーションが多数のエラーを検出しても,その中には IPsec ポリシ・マネージャが実際にポリシを使用して鍵と証明書を関連付けるまでは明らかにならないものがあります。 IPsec メッセージのリストは,付録 B を参照してください。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照してください。

公開鍵の証明書を使用した接続に失敗した場合は,次の手順を実行します。

  1. 証明書ベースの認証を使用する IKE プロポーザル・リストを選択して,適切な証明書ファイルを定義します。

  2. リモート・システムに対して ping コマンドを実行するか,または適切なポートとプロトコルでリモート・システムにトラフィックを送信します。 どちらも失敗した場合は,/var/adm/syslog/dated/current/current/auth.log ファイル内にエラーまたは警告メッセージが出力されていないか調べてください。 エラーまたは警告メッセージがあったときには,以下の操作を実行します。

    • 両方のシステムで使用する CA 証明書が構成され CA 証明書としてマークされていることを確認します。 証明書の階層内に複数のレベルがある場合,複数の証明書を構成する必要があります。

    • CRL ファイルが構成されていない場合は,CRL チェックが無効になっていることを確認します。

    • 暗号化フォーマット (PEM,Binary,HEXL) が,すべての証明書に対して正しく指定されていることを確認します。

    • ローカル・システムの証明書が構成され,構成された CA 証明書によって署名されていることを確認します。ipsec_certview ユーティリティを使用して,証明書の属性を調べます。

    • ローカル・システムの証明書に対して正しい非公開鍵ファイルが構成されていることを確認します。 証明書と非公開鍵が実際に一致することを確認するには,ipsec_keypaircheck ユーティリティを使用します。

    • 証明書が有効期限内であることを確認します。 CRL チェックが使用中の場合は,システムの証明書が取り消されていないか確認します。

    • ローカル・システムの証明書が正しい ID (IP アドレス,ドメイン名など) を含み,ID のタイプがリモート・システムが期待するものと一致していることを確認します。 IPsec の実装によっては,証明書内の subjectAltName 属性を 1 つしか処理できないものがあります。

    • IKE プロポーザル・リストに,適切な証明書タイプ (RSA または DSA) を使用する認証を指定するプロポーザルが含まれていることを確認します。 また,プロポーザル内の他のパラメータがリモート・システムのものと一致していることを確認します。

    • RSA 暗号化モードを使用して認証が行われる場合,リモート・システムの ID 証明書がローカル・システムに構成されていることを確認します (RSA 署名モードでは,この証明書は自動的に IKE 経由で送られます)。 また,RSA 暗号化モードでは,証明書に IP アドレスを含む subjectAltName 属性があることを確認します。 IKE は,リモート・システムの IP アドレスだけが分かっているときに,正しい証明書を識別できなければなりません。

    IPsec メッセージの一覧は,付録 B を参照してください。

  3. /var/adm/syslog.dated/current/auth.log ファイル内のメッセージが問題を示している場合は,IPsec SysMan アプリケーションを用いてセキュリティ・ポリシを変更する必要があります。 アプリケーションが多数のエラーを検出しても,その中には IPsec ポリシ・マネージャが実際にポリシを使用して鍵と証明書を関連付けるまでは明らかにならないものがあります。 IPsec メッセージのリストは,付録 B を参照してください。

10.6    ATM に関する問題の解決


ATM サブセットがインストールされていることを確認します。 次のコマンドを入力します。

# setld -i | grep OSFATM

次のメッセージが表示されます。

OSFATMnnn installed ATM Commands
   (Network-Server/Communications)
OSFATMBINnnn installed ATM Kernel
   Modules (Kernel Build Environment)
OSFATMBINCOMnnn installed ATM Kernel
   Header and Common Files
   (Kernel Build Environment)
OSFATMBINOBJECTnnn installed ATM Kernel
   Objects (Kernel Software Environment)

OSFATMOSFATMBIN,および OSFATMBINCOM サブセットがインストールされていない場合は,setld コマンドを使用してインストールします。 これらのサブセットのインストール方法の詳細については,『インストレーション・ガイド』を参照してください。


必要な ATM がカーネルに構成されていることを確認します。 次のコマンドを入力します。

# sysconfig -q atm

何も表示されない場合は,ATM がカーネルに構成されていません。 ATM オプション,および必要に応じて追加の ATM オプションを使用して,カーネルを再構成します。 ATM カーネル・オプションのリストとカーネルを再構成する方法の詳細については,6.2.2 項 を参照してください。

ATM が構成されている場合は,sysconfig -q コマンドを使用して,追加の ATM カーネル・オプションが構成されていることを確認します。 必要に応じて,追加のオプションを使用してカーネルを再構成します。

CLIP (Classical IP) については 10.6.1 項 へ,LAN エミュレーションについては 10.6.2 項 へ,また,IP スイッチングについては 10.6.3 項 へ進んでください。

atmconfig drvlist コマンドを使用して,ドライバが構成されていることを確認します。 ドライバが構成されている場合は,次のような出力が表示されます。

Name: lta0      Type: STS-3      State: UP
Driver ID: 1   ESIs: 8   PPAs: 9  VCs: 6

ドライバのエントリが存在しない場合は,genvmunix カーネルを使用してシステムをリブートしてから,doconfig ユーティリティを実行して,必要なドライバを使用してカーネルを構築します。

ドライバの状態が UP でない場合は,必要な ATM サービスについて atmsetup ユーティリティを実行します。 CLIP (Classical IP)については 6.3.2.4 項を,LANE (LAN エミュレーション) については 6.3.3.3 項を,IP スイッチングについては 6.3.4.2 項をそれぞれ参照してください。

10.6.1    CLIP に関する問題の解決


シグナリングが構成されていることを確認します。 次のコマンドを入力します。

# atmsig status driver=driver_name

UNI のバージョン番号が表示されない場合,または ILMI 状態が Unknown の場合は,atmsetup ユーティリティを実行して,シグナリングを構成します。 詳細については,6.3.2.4 項 を参照してください。


CLIP の lis インタフェースが作成されていることを確認します。 次のコマンドを入力します。

# atmarp -h

lis インタフェースが作成されている場合は,作成された全部の LIS のステータス,およびホストが ARP クライアントか ARP サーバかを示すデータが表示されます。

LIS が作成されていない場合は,atmsetup ユーティリティを実行して CLIP を構成します。 詳細については,6.3.2.4 項 を参照してください。


lis インタフェースが構成されていることを確認します。 次のコマンドを入力します。

# ifconfig lisx

lis インタフェースが構成されている場合,次のような情報が表示されます。

lis0: flags=c23<UP,BROADCAST,NOTRAILERS,MULTICAST,SIMPLEX>
    inet 10.140.120.52 netmask ffffff00 broadcast 10.140.120.255
   ipmtu 1500

lis インタフェースが構成されていない場合は,netconfig ユーティリティを実行してそれを構成するか,SysMan Menu から Interfaces アプリケーションを使用します。 詳細については,6.3.2.5 項 を参照してください。


リモート・ホストが認識されない場合は,次のメッセージが表示されます。

unknown host

この場合は,次の手順に従ってください。

  1. リモート・ホストに到達するために,ユーザが有効なホスト名を使用しているかどうか確認します。

  2. リモート・ホストが他のネーム・ドメインに属すること,およびユーザが完全なドメイン名を指定していることを確認します。

  3. 名前からアドレスへの変換に DNS を使用しているサイトの場合は,/etc/svc.conf ファイルの内容を調べ,hosts データベース・エントリのサービスとして bind が指定されているか確認します。 指定されていない場合は,それを追加します。

    また,DNS がリモート・ホストについての情報を持っていることも確認します。 『ネットワーク管理ガイド:サービス編』の「DNS/BIND クライアントに関する問題の解決」の手順を参照してください。

  4. 名前からアドレスへの変換に NIS ネーム・サービスを使用しているサイトの場合は,/etc/svc.conf ファイルの内容を調べ,hosts データベース・エントリのサービスとして nis が指定されているか確認します。 指定されていない場合は,ファイルを編集してそれを追加します。

    また,NIS サービスがリモート・ホストについての情報を持っていることも確認します。 『ネットワーク管理ガイド:サービス編』の「NIS クライアントに関する問題の解決」の手順を参照してください。

  5. /etc/svc.conf ファイルで,名前からアドレスへの変換メカニズムとして,local しか記載されていない場合は,/etc/hosts ファイルにリモート・ホストについての情報がありません。 詳細については, svc.conf(4) を参照してください。


リモート・ホストに到達できない場合は,次のメッセージが表示されます。

host is unreachable

この場合は,次の手順に従ってください。

  1. ローカル・ホストとスイッチ間のケーブルが正しく接続されており,ケーブルに損傷がないことを確認します。

  2. ping コマンドを使用して,スイッチの IP コントローラへのネットワーク接続を確認します。 このコマンドが失敗した場合は,ifconfig コマンド・パラメータが誤っているか,または IP コントローラがダウンしているかそのインタフェースに問題があることが考えられます。 スイッチ管理者に問い合わせてください。

  3. ping コマンドを使用して,対象のリモート・ホストへのネットワーク接続を確認します。 コマンドが失敗する場合は,traceroute コマンドを使用してリモート・ホストへのルートを確認してください。

まだ問題がある場合は,サービス担当者に報告してください。 第 12 章 を参照。

接続が異常終了した場合は,次の手順に従ってください。

  1. ネットワークをテストして,問題がローカル・ホストにあるのか,リモート・ホストにあるのか,またはそれらの間のパスにあるのかを判断します。 詳細については,10.3 節 を参照してください。

  2. どのホストに問題があるかが分かったら,次の手順に従ってください。

    1. ネットワーク・デバイスが正しく構成されていることを確認します。 ローカル・ホストのブロードキャスト・アドレスおよびアドレス・マスクが正しいことを確認します。 ネットワーク・デバイスの構成については,2.3 節 を参照してください。

    2. ローカル・ホストの hosts データベース中の IP アドレスが正しいことを確認します。

    3. ローカル・ホストからネットワークへの配線に誤りがなく,正しく接続されていることを確認します。

    4. LAN 接続の場合は,ARP エントリが適切であること,およびシステムが LAN に正しく接続されていることを確認します。

10.6.2    LANE に関する問題の解決


シグナリングが構成されていることを確認します。 次のコマンドを入力します。

# atmsig status driver=driver_name

UNI (User-Network Interface) のバージョン番号が表示されない場合,または ILMI (Integrated Layer Management Interface) の状態が Unknown の場合は,atmsetup ユーティリティを実行して,シグナリングを構成します。 詳細については,6.3.3.3 項 を参照してください。


elan インタフェースが作成されていることを確認します。 次のコマンドを入力します。

# atmelan show

elan インタフェースが作成されている場合は,次のような情報が表示されます。


.
.
.
control state: S_OPERATIONAL
.
.
.

制御状態が S_OPERATIONAL でない場合は,次の手順を実行します。

  1. lane サブシステムのメッセージ・ロギング・レベルを上げます。 詳細は,6.4.6 項を参照してください。

  2. スイッチの UNI バージョンがシステムの UNI バージョンと一致していることを確認します。

  3. スイッチ上の LES (LAN Emulation Server) が正しく構成されていることを確認します。


elan インタフェースが構成されていることを確認します。 次のコマンドを入力します。

# ifconfig elanx

elan インタフェースが構成されている場合は,次のような情報が表示されます。

elan0: flags=c23<UP,BROADCAST,NOTRAILERS,MULTICAST,SIMPLEX>
     inet 10.140.120.52 netmask ffffff00 broadcast 10.140.120.255
   ipmtu 1500

elanインタフェースが構成されていない場合は,netconfig ユーティリティを実行してそれを構成するか,SysMan Menu から Interfaces アプリケーションを使用します。 詳細については,6.3.3.4 項 を参照してください。


リモート・ホストが認識されない場合は,次のメッセージが表示されます。

unknown host

この場合は,次の手順に従ってください。

  1. リモート・ホストに到達するために,ユーザが有効なホスト名を使用していることを確認します。

  2. リモート・ホストが他のネーム・ドメインに属していること,およびユーザが完全なドメイン名を指定していることを確認します。

  3. 名前からアドレスへの変換に DNS を使用しているサイトの場合は,/etc/svc.conf ファイルの内容を調べ,hosts データベース・エントリのサービスとして bind が指定されているか確認します。 指定されていない場合は,それを追加します。

    また,DNS がリモート・ホストについての情報を持っていることも確認します。 『ネットワーク管理ガイド:サービス編』の「DNS/BIND クライアントに関する問題の解決」の手順を参照してください。

  4. 名前からアドレスへの変換に NIS ネーム・サービスを使用しているサイトの場合は,/etc/svc.conf ファイルの内容を調べ,hosts データベース・エントリのサービスとして nis が指定されているか確認します。 指定されていない場合は,ファイルを編集してそれを追加します。

    また,NIS サービスがリモート・ホストについての情報を持っていることも確認します。 『ネットワーク管理ガイド:サービス編』の「NIS クライアントに関する問題の解決」の手順を参照してください。

  5. /etc/svc.conf ファイルで,名前からアドレスへの変換メカニズムとして,local しか記載されていない場合は,/etc/hosts ファイルにリモート・ホストについての情報がありません。 詳細については, svc.conf(4) を参照してください。


リモート・ホストに到達できない場合は,次のメッセージが表示されます。

host is unreachable

この場合は,次の手順に従ってください。

  1. ローカル・ホストとスイッチ間のケーブルが正しく接続されており,ケーブルに損傷がないことを確認します。

  2. ifconfig elanx コマンドを使用して,リンク上のアドレスが正しいことを確認します。

  3. ping コマンドを使用して,対象のリモート・ホストへのネットワーク接続を確認します。 コマンドが失敗する場合は,traceroute コマンドを使用してリモート・ホストへのルートを確認してください。

まだ問題がある場合は,サービス担当者に報告してください。 第 12 章 を参照。

接続が異常終了した場合は,次の手順に従ってください。

  1. ネットワークをテストして,問題がローカル・ホストにあるのか,リモート・ホストにあるのか,またはそれらの間のパスにあるのかを判断します。 詳細については,10.3 節を参照してください。

  2. どのホストに問題があるかが分かったら,次の手順に従ってください。

    1. ネットワーク・デバイスが正しく構成されていることを確認します。 ローカル・ホストのブロードキャスト・アドレスおよびアドレス・マスクが正しいことを確認します。 ネットワーク・デバイスの構成については,2.3 節 を参照してください。

    2. ローカル・ホストの hosts データベース中の IP アドレスが正しいことを確認します。

    3. ローカル・ホストからネットワークへの配線に誤りがなく,正しく接続されていることを確認します。

    4. LAN 接続の場合は,ARP エントリが適切であること,およびシステムが LAN に正しく接続されていることを確認します。

10.6.3    IP スイッチに関する問題の解決


IP スイッチングの ips インタフェースが作成されていることを確認します。 次のコマンドを入力します。

# atmifmp showips

ips インタフェースが作成されている場合は,作成された ips インタフェースごとに,次のような情報が表示されます。

ips0:
         Attached to driver lta0
         Default (SNAP) VC = 32
         IP Traffic VC = 1850 (Unused - peer does
                not support Flow Type 0)
         Min Tx VC = 1
         Max Tx VC = 2048
         Min Rx VC = 1
         Max Rx VC = 2048
         Driver Min Tx VC = 1
         Driver Max Tx VC = 2048
         Driver Min Rx VC = 1
         Driver Max Rx VC = 2048
         Peer does not support Flow Type 0

この例は,ips0 インタフェースが作成され,ドライバ lta0 にアタッチされていることを示します。

ips がまったく見つからない場合は,ips を 1 つまたはそれ以上作成します。 詳細については,6.3.4 項 を参照してください。


ips インタフェースが構成されていることを確認します。 次のコマンドを入力します。

# ifconfig ipsx

ips インタフェースが構成されている場合は,次のような情報が表示されます。

ips0: flags=4d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>
   inet 16.142.128.129 --> 16.142.128.130 netmask fffffffc  ipmtu 1500

この例は,インタフェースが起動されて動作中で,アドレスがポイント・ツー・ポイント・リンクの各エンドに対して構成されていることを示します。

ips インタフェースが構成されていない場合は,netconfig ユーティリティを実行してそれを構成するか,SysMan Menu から Interfaces アプリケーションを使用します。 詳細については,6.3.4.3 項 を参照してください。


リモート・ホストが認識されない場合は,次のメッセージが表示されます。

unknown host

この場合は,次の手順に従ってください。

  1. リモート・ホストに到達するために,ユーザが有効なホスト名を使用していることを確認します。

  2. リモート・ホストが他のネーム・ドメインに属していること,およびユーザが完全なドメイン名を指定していることを確認します。

  3. 名前からアドレスへの変換に DNS を使用しているサイトの場合は,/etc/svc.conf ファイルの内容を調べ,hosts データベース・エントリのサービスとして bind が指定されているか確認します。 指定されていない場合は,ファイルを編集してそれを追加します。

    また,DNS がリモート・ホストについての情報を持っていることも確認します。 『ネットワーク管理ガイド:サービス編』の「DNS/BIND クライアントに関する問題の解決」の手順を参照してください。

  4. 名前からアドレスへの変換に NIS ネーム・サービスを使用しているサイトの場合は,/etc/svc.conf ファイルの内容を調べ,hosts データベース・エントリのサービスとして nis が指定されているか確認します。 指定されていない場合は,ファイルを編集してそれを追加します。

    また,NIS サービスがリモート・ホストについての情報を持っていることも確認します。 『ネットワーク管理ガイド:サービス編』の「NIS クライアントに関する問題の解決」の手順を参照してください。

  5. /etc/svc.conf ファイルで,名前からアドレスへの変換メカニズムとして,local しか記載されていない場合は,/etc/hosts ファイルにリモート・ホストについての情報がありません。 詳細については,『システム管理ガイド』を参照してください。


リモート・ホストに到達できない場合は,次のメッセージが表示されます。

host is unreachable

この場合は,次の手順に従ってください。

  1. ifconfig ipsx コマンドを使用して,ポイント・ツー・ポイント・リンク上の,スイッチへのアドレスが正しいことを確認します。

  2. ping コマンドを使用して,スイッチ上の IP コントローラへのネットワーク接続を確認します。 このコマンドが失敗した場合は,ローカル・ホストの ifconfig コマンド・パラメータが誤っていることが考えられます。 また,スイッチ上で IP コントローラがダウンしているか,そのインタフェースに問題があることも考えられます。 スイッチ管理者に問い合わせてください。

  3. netstat -r コマンドを使用して,リモート・ホストのサブネットへの ips ルートが存在することを確認します。


ping コマンドが失敗する場合,次の手順に従ってください。

  1. ローカル・ホストとスイッチ間のケーブルが正しく接続されており,ケーブルに損傷がないことを確認します。

  2. ローカル・ホストで指定されている SNAP (Subnetwork Attachment Point) VC (仮想回線) が,スイッチの SNAP VC に一致していることを確認します。

  3. リモート・システムの管理者に連絡して,リモート・システムが起動されて動作中であり,IP スイッチングが正しく構成されていることを確認します。

  4. traceroute コマンドを使用して,リモート・ホストへのルートを確認します。 出力の最初のホップが IP コントローラではなく省略時のネットワーク・インタフェースを示す場合,IP コントローラ経由でリモート・サブネットに至る静的ルートを,ルーティング・テーブルに追加します。 変更内容の確認には,netstat -r コマンドを使用します。

    ルートが IP コントローラに到達しているが,それより先に到達しない場合は,リモート・システムの管理者に連絡して,システムが正しく構成され,ルーティング・テーブルが正しいことを確認します。

まだ問題がある場合は,サービス担当者に報告してください。 第 12 章 を参照。

接続が異常終了した場合は,次の手順に従ってください。

  1. ネットワークをテストして,問題がローカル・ホストにあるのか,リモート・ホストにあるのか,またはそれらの間のパスにあるのかを判断します。 詳細については,10.3 節 を参照してください。

  2. どのホストに問題があるかが分かったら,次の手順に従ってください。

    1. ネットワーク・デバイスが正しく構成されていることを確認します。 ローカル・ホストのブロードキャスト・アドレスおよびアドレス・マスクが正しいことを確認します。 ネットワーク・デバイスの構成については,2.3 節 を参照してください。

    2. ローカル・ホストの hosts データベース中の IP アドレスが正しいことを確認します。

    3. ローカル・ホストからネットワークへの配線に誤りがなく,正しく接続されていることを確認します。

10.7    DHCP に関する問題の解決


Additional Networking Services サブセットがインストールされていることを確認します。 次のコマンドを入力します。

# setld -i | grep OSFINET

このサブセットがインストール済みであれば,次のメッセージが表示されます。

OSFINETnnn installed Additional Networking Services
  (Network-Server/Communications)

サブセットがインストールされていない場合は,setld コマンドを使用してインストールします。 このサブセットのインストール方法の詳細については,『インストレーション・ガイド』を参照してください。


次の手順を実行して,DHCP (Dynamic Host Configuration Protocol) がサーバとクライアントの両方で構成されていることを確認します。

  1. rcmgr ユーティリティを使用して,DHCP サーバにある /etc/rc.config.common ファイルの JOIND エントリの値を表示します。

    # rcmgr get JOIND
    

    何も返されない場合は,SysMan Menu ユーティリティを実行して DHCP サーバを構成します。 詳細については,7.3.7 項 を参照してください。

  2. rcmgr ユーティリティを使用して,DHCP クライアントにある /etc/rc.config ファイルの IFCONFIG_n エントリの値を表示します。 次に例を示します。

    # rcmgr get IFCONFIG_0
    

    次のような値が表示されます。

    DYNAMIC netmask n.n.n.n
    

    このような値が返されない場合は,SysMan Menu ユーティリティを実行して DHCP クライアントを構成します。 詳細については,2.3 節 を参照してください。


ping コマンドを使用して,DHCP サーバが動作状態にあり,到達可能であることを確認します。


DHCP デーモン (joind) がサーバ上で動作状態にあることを確認します。 次のコマンドを入力します。

# ps -e | grep joind

または,SysMan Menu ユーティリティを使用して,DHCP デーモンのステータスを表示することも可能です。 次のコマンドを入力すれば,「status」ダイアログ・ボックスに直接進むことができます。

# /usr/sbin/sysman dmnstatus

DHCP デーモンが動作状態にない場合,次のコマンドを使用して起動します。

# /usr/sbin/joind

まだ問題がある場合は,サービス担当者に報告してください。 第 12 章 を参照。

DHCP クライアントがサーバから DHCP 情報を取得できない場合は,次の手順に従ってください。

  1. クライアントのために入力した MAC (Media Access Control) を確認します。 特に Microsoft クライアントのユーザは,必ず 7.3.5 項 を参照してください。 Microsoft クライアントが MAC アドレスを DHCP サーバに送信する前に,MAC アドレスをどのように変更するかが説明されています。

  2. 次の手順に従って,joind デーモンにデバッグ・フラグを付けて実行します。

    1. kill -HUP コマンドを使用して,joind デーモンを停止します。

      注意

      kill -9 コマンドで DHCP サーバ・デーモンを停止してはいけません。 データベース・ファイルが破壊されるおそれがあります。

    2. 次のように,joind デーモンにデバッグ・フラグを付けて再起動します。

      # /usr/sbin/joind -d4
      

      joind/etc/inetd.conf ファイルから実行している場合は,次の手順に従ってください。

      1. /etc/inetd.conf ファイルを編集して,-d4 フラグを追加します。

      2. kill -HUP コマンドで joind デーモンを停止します。

      3. inetd -h コマンドで inetd デーモンを停止します。 これにより,inetd デーモンが /etc/inetd.conf ファイルを再度読み取ります。

      代わりに,SysMan Menu ユーティリティを使用して,デバッグ・オプションで DHCP サーバを構成することも可能です。 詳細については,7.3.7 項 を参照してください。

  3. /var/join/log ファイルで,DHCP クライアントの問題の原因が解消されたか確認します。

以下は /var/join/log ファイル・メッセージの例で,DHCP がサーバ・システムにメッセージが到着したことを検出したが,IP サブネットワークのアドレス・レンジが未定義であることを示しています。

DHCPDISCOVER from HW address 08:00:2b:96:79:b6 :
 network not administered by server

この問題は,アドレス・レンジが定義されていても,/etc/join/netmasks ファイルに,この IP ネットワークのサブネットワーク・マスク定義がない場合にも生じます。 この場合はネットマスク・ファイルを編集し,サブネットワークのエントリを追加してから,DHCP サーバ /usr/sbin/joind を再起動します。

10.8    SLIP に関する問題の解決


netstat -in コマンドを使用して,正しい数の SLIP (Serial Line Internet Protocol) 擬似デバイスが,カーネルでサポートされていることを確認します。 SLIP がサポートされている場合は,各インタフェースに対して次のような出力が表示されます。

sl0* 296 <Link> 0 0 0 0 0

接頭文字 sl は,SLIP がシステムでサポートされていることを示します。 この例では,SLIP 擬似デバイスは 1 つです。

SLIPインタフェースを追加する場合は,/etc/sysconfigtab ファイルで,net: サブシステムの下に nslip=x 属性を追加して指定します。 SLIP インタフェースの追加についての説明は,『システム管理ガイド』を参照してください。

24 MB メモリのシステムでは,SLIP はカーネルに組み込まれません。 SLIP をカーネルに追加する場合は,システム構成ファイル (/usr/sys/confhostname) を編集して次のようなエントリを追加してください。

options SL

詳細については,『システム管理ガイド』 を参照してください。


ネットワーク・ハードウェアを次のように構成します。

  • 正しいハードウェアを使用していることを確認します。 詳細は 8.1.2.1 項 を参照してください。

  • モデムが次のように構成されていることを確認します。

    • パリティなしの 8 ビット文字を使用していること。

    • ソフトウェアのフロー制御 (XON/XOFF) を禁止していること。

    • ダイアル・イン・システムの場合は,8.1.3.1 項 のガイドラインに従う。

    • ダイアル・アウト・システムの場合は,8.1.3.2 項 のガイドラインに従う。


リモート・システムが正しくダイアル・インできない場合は,次の手順に従います。

  1. /usr/spool/locks ディレクトリ内で LCK..ttynn ロック・ファイルの有無を調べます。 SLIP 用に構成している端末デバイスのロック・ファイルがあれば,それを削除してください。

    端末デバイス経由で接続を確立すると,他のアプリケーションによって接続が切られないようにするために,システムがロック・ファイルを生成します。 この接続が正しい手続きを経ずに切断されると,ロック・ファイルが残り,新しい接続が確立できなくなります。

  2. /etc/slhosts ファイルを編集して,ログインできないログイン・エントリに debug オプションを追加します。 詳細については, slhosts(4) を参照してください。

  3. リモート・ユーザに再度ダイアル・インするよう指示します。

  4. /var/adm/syslog.dated/current/daemon.log ファイル内で,ダイアル・イン・システムでの SLIP の問題に関する情報を調べます。 詳細については,11.9 節を参照してくだい。


リモート・システムにダイアル・アウトできない場合は,次の手順に従います。

  1. /usr/spool/locks ディレクトリ内で LCK..ttynn ロック・ファイルの有無を調べます。 SLIP 用に構成している端末デバイスのロック・ファイルがあれば,それを削除してください。

    端末デバイス経由で接続を確立すると,他のアプリケーションによって接続が切られないようにするために,システムがロック・ファイルを生成します。 この接続が正しい手続きを経ずに切断されると,ロック・ファイルが残り,新しい接続が確立できなくなります。

  2. モデムが正しく動作していることを確認します。

    /etc/acucap ファイルを編集して モデムのエントリに db オプションを含めます。 このオプションにより,新しいエントリのデバッグに役立つ情報が出力されます。 詳細については, acucap(4) を参照してください。

  3. 次の手順で,SLIP の設定を確認します。

    1. startslip ダイアル・アウト・スクリプト・ファイルを編集して debug サブコマンドとデバッグ・ログ・ファイルを指定します。

    2. 再度ダイアル・アウトを試みます。

    3. デバッグ・ログファイル内で,SLIP ダイアル・アウトに関する情報を調べます。


リモート・ホストと通信できず,デバッグ・メッセージがエラーを表示しない場合は,次の手順に従ってください。

  1. 接続している両方のシステムで,IP アドレスとネットマスクが正しく設定されていることを確認します。

  2. 接続している両方のシステムで,次の SLIP 構成パラメータを調べます。

    • ICMP (Internet Control Message Protocol) 通信量抑制

      ローカル・エンドまたはリモート・エンドで可能にされていると,ping コマンドは異常終了します。

    • TCP ヘッダ圧縮

      ローカル・エンドまたはリモート・エンドの一方で可能にされている場合は,他方でも TCP ヘッダ圧縮を可能にするか,または自動で可能にしておく必要があります。


リモート・ホストとは通信できるが,そのリモート・ホストが接続されているネットワークと通信できない場合は,次の手順に従います。

  1. ローカル・システムがリモート・システムをゲートウェイ・システムとして使用している場合,ローカル・システムで netstat -rn コマンドを実行して,リモート SLIP アドレスが省略時のゲートウェイであることを確認します。

  2. ゲートウェイ・システム (リモート・システム) で iprsetup -d コマンドを実行して,ipforwardingipgateway 変数がオンになっているかどうか調べます。 オフになっている場合は,iprsetup -s コマンドでオンにします。

  3. ゲートウェイ・システムで gated デーモンが実行されているか確認します。 詳細については gated(8) を参照してください。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

startslipコマンドが異常終了する場合は,次の手順に従ってください。

  1. PACKETFILTER オプションを指定してカーネルを構築します。

  2. tcpdump コマンドを使用して,SLIP インタフェースを介して送受信されたパケットを調べます。 詳細については, tcpdump(8) を参照してください。

10.9    PPP に関する問題の解決


sysconfig -s | fgrep ppp コマンドを使用して,PPP (Point-to-Point Protocol) がカーネルでサポートされていることを確認します。 PPP がサポートされている場合は,次のような出力が表示されます。

ppp: loaded and configured

PPP がサポートされていない場合,PPP オプションを /sys/conf/MACHINE システム構成ファイルに追加し,カーネルを再構築します。


ネットワーク・ハードウェアを次のように構成します。

  • リモート・ホストへの直接接続

    ヌル・モデム・ケーブルまたはモデム・エリミネータ・ケーブルを使用して,システムをリモート・ホストと接続します。

  • リモート・ホストへの電話回線接続

    2 本のケーブルを使用して,モデムと電話回線,システムとモデムをそれぞれ接続します。 使用するモデムは,リモート・ホストのモデムと互換性がなければなりません。 モデムを次のように構成します。

    • パリティなしの 8 ビット文字を使用する。

    • すべてのフロー制御を禁止する。


メッセージをコンソールへ出力するよう設定している場合,リンクが正常に行われるとコンソールに次のメッセージが表示されます。

Local IP address: xx.xx.xx.xx
Remote IP address: yy.yy.yy.yy

リンクが確立されない場合は,次の手順を実行します。

  • /usr/spool/locks ディレクトリ内で LCK..ttynn ロック・ファイルの有無を調べます。 PPP 用に構成している端末デバイスのロック・ファイルがあれば,それを削除してください。

    端末デバイス経由で接続を確立すると,他のアプリケーションによって接続が切られないようにするために,システムがロック・ファイルを生成します。 この接続が正しい手続きを経ずに切断されると,ロック・ファイルが残り,新しい接続が確立できなくなります。

  • シリアル接続が正常に設定されていることを確認します。 chat -v コマンドを実行して,chat プログラムが送受信する文字をログに取ります。

  • リモート・システムで pppd デーモンが起動されていることを確認します。 chat -v コマンドを実行して,chat プログラムが送受信する文字をログに取ります。

  • 2 つのピア間の PPP 折衝を調べます。 pppd コマンドを debug オプション付きで実行して,送受信されるすべての制御パケットの内容をログに取ります。

  • MRU の値が正しく設定されていることを確認します。 MRU の値が小さすぎると,トラフィックはリンク上を正しく流れません。 IPv4 の場合,最小値は 128 バイトですが,値を 296 にすることをお勧めします。 IPv6 の場合,最小値は 1298 バイトですが,値を 1500 にすることをお勧めします。

    カーネルで IPv6 が有効になっている場合,使用するしないにかかわらず,PPP は自動的に IPv6 アドレスを構成します。 そのため,MRU の値は 1298 またはそれ以上に設定する必要があります。 あるいは,PPP リンクで IPv6 を使用しない場合は,noip6 オプションを指定します。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

ネットワーク・アプリケーションが異常終了する場合,これは IP アドレス割り当て問題またはルーティング問題を示しています。 次の手順に従ってください。

  1. netstat -inetstat -rpingtraceroute の各コマンドを使って問題を診断します。

  2. ピア・マシンとは通信できるが,ピア・マシンを越えてネットワーク内の他のマシンと通信できない場合は,ルーティング問題が発生しています。 たとえば,ローカル・マシンがピアを介してインターネットと接続される場合は,次のことを実行します。

    1. リモート・マシンと同じサブネットの IP アドレスをローカル・マシンに割り当てます。

    2. ローカルの pppd デーモンを defaultroute オプション付きで実行します。

    3. リモートの pppd デーモンを proxyarp オプション付きで実行します。

    4. ピア・システム (リモート・システム) で iprsetup -d コマンドを実行して,ipforwarding および ipgateway 変数がオンになっているとを確認します。 オフの場合は,iprsetup -s コマンドでオンにします。

10.10    LAT に関する問題の解決


LAT のサブセットがインストールされていることを確認します。 次のコマンドを入力します。

# setld -i | grep OSFLAT

このサブセットがインストールされている場合は,次のメッセージが表示されます。

OSFLATnnn installed Local Area Transport (LAT)
  (General Applications)

サブセットがインストールされていない場合は,setld コマンドを使用してインストールします。 サブセットのインストールについての説明は,『インストレーション・ガイド』を参照してください。


カーネルにローカル・エリア・トランスポートが構成されていることを確認します。 次のコマンドを入力します。

# sysconfig -q lat

何も表示されない場合は,LAT がカーネルに構成されていません。 LAT オプションを使用してカーネルを再構成します。 カーネルの再構成についての説明は,『システム管理ガイド』を参照してください。


rcmgr ユーティリティを使用して,/etc/rc.config ファイル内の LAT_SETUP エントリの値を表示します。

# rcmgr get LAT_SETUP

0 が返された場合は,latsetup ユーティリティを実行します。 詳細については,9.3.1 項 を参照してください。


latsetup ユーティリティが新しい LAT tty を作成しようとすると異常終了する場合は,/usr/sbin ディレクトリが検索パスに含まれていることを確かめます。 次のコマンドを入力します。

# echo $PATH

含まれていない場合は,それを PATH 環境変数に指定します。 次に,latsetup コマンドを使用して新しい LAT tty を作成します。


LAT がスタートしていることを確認します。 次のコマンドを入力します。

# latcp -d

LAT がスタートしている場合は,次の行が表示されます。

LAT Protocol is active

LAT がスタートしていない場合は,スタートさせます。 次のコマンドを入力します。

# latcp -s


LAT がスタートしてメッセージがシステム・コンソールに連続的に表示される場合は,次の各メッセージを探し,必要な手順に従ってください。

メッセージ 1

getty: cannot open "/dev/lat/xx".
errno: 2

これは,LAT ターミナル・デバイス・ファイル (tty) が存在しないにもかかわらず,このファイルのエントリが /etc/inittab ファイルに存在することを示します。 また,latsetup ユーティリティによって,使用可能な LAT エントリがないことが報告されます。 次のことを行います。

  1. /etc/inittab ファイルを編集し,LAT getty エントリを削除します。

  2. LAT ターミナル・デバイスが必要な場合は,latsetup コマンドを使用して,LAT ターミナル・デバイス・ファイルを作成し,それに対応するエントリを /etc/inittab ファイル内に作成します。 詳細については, latsetup(8) を参照してください。

メッセージ 2

getty: cannot open "/dev/lat/xx".
errno: 19

これは,カーネルが LAT オプションを使用して構成されなかったにもかかわらず,最低でも 1 つの LAT getty エントリが,/etc/inittab ファイルに存在していることを意味します。 次のいずれかを行います。

  • LAT を組み込んでカーネルを構成します。 LAT を組み込むカーネルの構成については,『システム管理ガイド』を参照してください。

  • 手動によって,または latsetup コマンドを使用して,LAT getty エントリを /etc/inittab ファイルから削除します。

メッセージ 3

INIT: Command is respawning too rapidly.

このメッセージは,次のいずれかのことを示します。

  • lattelnet などのオプション・サービスを使用しようとしているが,不正なサービス名が定義されています。 次の手順に従ってください。

    1. latcp -d コマンドを使用して,latcp -A コマンドによって定義されたオプション・サービス名が正しいことを確認します。

    2. /etc/inittab ファイルを編集し,LAT エントリに指定されているオプション・サービス名が正しいことを確認します。

  • 存在しない LAT ターミナル・デバイス (tty) を使用しようとしました。 次の手順に従ってください。

    1. /etc/inittab ファイルを編集し,存在しないターミナル・デバイス名が記述されているエントリを削除します。

    2. LAT ターミナル・デバイスが必要な場合は,latsetup コマンドを使用して,LAT ターミナル・デバイス・ファイルを作成し,それに対応するエントリを /etc/inittab ファイル内に作成します。 詳細については, latsetup(8) を参照してください。


ユーザがターミナル・サーバから LAT を介して,サービスに接続できないか,またはサービスを表示できない場合は,Tru64 UNIX システムで次の手順に従ってください。

  1. latcp -d コマンドを使用して,サービス名が正しいことを確認します。 サービス名が不正な場合は,そのサービスを削除します。 次のコマンドを入力します。

    # latcp -D -aservice_name
    

    次に,サービスを正しい名前で登録します。 次のコマンドを入力します。

    # latcp -A -aservice_name
    

    詳細については, latcp(8) を参照してください。

  2. latcp -d コマンドを使用して,接続しようとしているサービスのグループ・コードを表示します。 ターミナル・サーバで,show port コマンドによって表示されるグループと一致するグループ・コードがあるかどうかを確かめます。 一致するグループ・コードがない場合は,次のいずれかを行います。

    • そのポートに対して表示されたグループの中から最低でも 1 つ,サービスに追加してみます。 次のコマンドを入力します。

      # latcp -glist -aservice_name
      

    • サービスと一致するグループを追加して,ターミナル・サーバのポート特性を変更します。

    詳細については, latcp(8) を参照してください。

  3. LAT がシステムでスタートしているかを確かめます。 スタートしていなければ,スタートさせます。 次のコマンドを入力します。

    # latcp -s
    

  4. それでも問題が解決しない場合は,LAT を再起動させます。 次のコマンドを入力します。

    # latcp -s
    


オプション・サービスを使用すると問題が発生する場合は,次の手順に従ってください。

  1. そのサービスがオプション・サービスとして追加されたことを確認します。 次のコマンドを入力します。

    # latcp -d
    

    次の行を探します。

    Service name: name (Optional)
    

    Optional が表示されない場合は,このオプション・サービスが -o オプションによって定義されていなかったことになります。 このサービスを削除します。 次のコマンドを入力します。

    # latcp -D -aservice_name
    

    次に,正しい名前と -o オプションを指定して,サービスを追加します。 次のコマンドを入力します。

    # latcp -A -aservice_name -o
    

    詳細については, latcp(8) を参照してください。

  2. オプション・サービス名が /etc/inittab ファイルに定義されている名前と一致することを確認します。 一致しない場合は,次のいずれかを行います。

    • /etc/inittab ファイルを編集して,オプション・サービス名を指定します。

    • そのサービスを削除します。 次のコマンドを入力します。

      # latcp -D -aservice_name
      

      次に,正しい名前と-o オプションを指定して,サービスを追加します。 次のコマンドを入力します。

      # latcp -A -aservice_name -o
      

    詳細については, latcp(8) を参照してください。


LATを使用してもホストに接続できない場合は,次のメッセージが表示されます。

Connection
to node-name not established.
Service in use.

/etc/inittab ファイル内の getty エントリの数が不足しています。 latsetup コマンドを使用して,LAT ターミナル・デバイス (tty) を追加作成し,対応するエントリを /etc/inittab ファイルに追加します。 次に,LAT を再起動して,使用できるサービスをアドバタイズさせてみます。 次のコマンドを入力します。

# latcp -s

詳細については,9.3.1 項を参照してください。


ホストから開始される接続が失敗する場合は,ポート,ホスト,およびサービス名が正確に指定されていることを確認します。 次のコマンドを入力します。

# latcp -d -P -L

これらの名前が正しく指定されていない場合は,不正な名前のアプリケーション・ポートを削除します。 次のコマンドを入力します。

# latcp -D -pport_name

次に,正確なスペルを使用してアプリケーション・ポートを追加します。 LAT ターミナル・デバイスのマッピング先となるリモート・ポートを指定してアプリケーション・ポートを作成するには,次のコマンドを使用します。

# latcp -A -plocal_port -Hnode -Rrem_port

LAT ターミナル・デバイスのマッピング先となるリモート・サービス名を指定してアプリケーション・ポートを作成する場合には,次のコマンドを使用します。

# latcp -A -plocal_port -Hnode -Vsvc_name

詳細については, latcp(8) を参照してください。

注意

LAT プリンタのアプリケーション・ポートを削除した場合に,現在実行されているプリント動作が続行されるのは,プリンタ・バッファが空になるまでです。 プリント・ジョブが終了しないこともあります。


LAT アプリケーション・ポートに接続された,オンラインになっているプリンタへファイルをプリントしてもプリントが実行されない場合は,プリント・キューの状態をチェックします。 次のコマンドを入力します。

# lpc status

次の行が表示されます。

waiting for printer to become ready (offline ?)

この行が表示された場合は,LAT がスタートしていることを確認します。 次のコマンドを入力します。

# latcp -d

LAT がスタートしていない場合は,それをスタートします。 次のコマンドを入力します。

# latcp -s


LAT/Telnet ゲートウェイの問題が検出された場合は,/var/adm/syslog.dated/current/daemon.log ファイル内にエラー・メッセージがあるか探します。 そして,そのエラー・メッセージを使用して問題を診断します。 daemon.log ファイルについては,11.9 節 を参照してください。

lattelnet ユーティリティは,LOG_INFO の syslog メッセージ・プライオリティを使用します。 たとえば,ターミナルの getty プロセスの処理中に,/etc/inittab ファイル内の LAT ターミナル・エントリを編集してそれを lattelnet に再び割り当て,LAT/Telnet に接続しようとすると,接続は失敗します。 daemon.log ファイルに,次のエラー・メッセージが記録されます。

No such file or directory

ターミナル・ポートの getty プロセスを終了します。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

LAT 接続が失敗する場合は,次の手順に従ってください。

  1. LAT ターミナル・デバイス (tty) ファイル内で,副デバイス番号の重複の有無を調べます。 次のコマンドを入力します。

    # ls -l /dev/lat/*
    

    重複している副デバイス番号が存在する場合は,重複しているデバイス・ファイルを削除してオリジナルのファイルを残します。

  2. /etc/inittab ファイル内で,LAT エントリの重複の有無を調べます。 重複しているエントリを削除して,オリジナルのエントリを残します。