F.2.1 ネットワークが期待通りの動作をしない(IPv4/IPv6で共通)

現象: システム起動時に/etc/defaultrouter において定義したデフォルトゲートウェイが有効とならない。

原因および対策: /etc/defaultrouter において定義したデフォルトゲートウェイの設定はシステム起動時に /etc/rc2.d/S69inet において設定されます。この時、指定されたルータと同一のセグメントのインタフェースが存在しない、または非活性状態の場合デフォルトゲートウェイの設定はできません。伝送路二重化機能ではクラスタ運用の場合、クラスタアプリケーション起動時に仮想インタフェースが活性化されるため、デフォルトゲートウェイの設定ができない場合があります。

高速切替方式: クラスタ運用時に仮想インタフェースをデフォルトゲートウェイに対する送信インタフェースとして使用する場合は、hanetparamコマンドにより仮想インタフェースを活性化するタイミングを変更してください。

NIC切替方式: 物理IPアドレス引継機能を使用する場合で、かつ、待機ノードでインタフェースを活性化しない場合には、物理インタフェースをデフォルトゲートウェイに対する送信インタフェースとして使用することはできません。

GS/SURE連携方式: クラスタ運用時に仮想インタフェースをデフォルトゲートウェイに対する送信インタフェースとして使用することはできません。

F.2.1.2 NIS環境でシステムの起動やインタフェースの活性化に失敗する

現象

以下のようなメッセージが表示され、システムの起動またはインタフェースの活性化がハングする。

ypbind[xxxx]: [ID xxxxxx daemon.error] NIS server not responding for domain "domain_name"; still trying

原因および対策: 伝送路二重化機能が動作するシステムがNISクライアントとして設定されている場合、伝送路二重化機能が行うインタフェースの非活性処理により、一時的にNISサーバに接続できなくなる場合があります。その場合、ifconfigコマンドによりインタフェースにネットマスクの設定をしようとすると、ifconfigコマンドにおいてサブネットマスクを取得するためにNISサーバとの接続を待合せるため、システムの起動やインタフェースの活性化処理がハングする場合があります。
NIS環境で伝送路二重化機能を使用する場合には、必ず以下の設定を行ってください。

/etc/nsswitch.conf において netmasksの参照にfilesを先頭に指定する。

【設定例】

netmasks: files

または

netmasks: files [NOTFOUND=return] nis

また、NISサーバへのアクセスについては、伝送路二重化機能による制御(活性/非活性)の対象となっているインタフェースはできる限り使用しないようネットワークの設計を行ってください。

F.2.1.3 IPv6アドレスのアドレス自動構成が即座に行われない

現象: IPv6インタフェースの活性化時にIPv6アドレスのステートレスアドレス自動構成が即座に行われず、サイトローカル／グローバルアドレスが付加されるのに時間がかかる場合がある。

原因および対策: IPv6のインタフェースを活性化する場合、通常は物理インタフェースに対してリンクローカルアドレスを付加して活性化した後、ステートレスアドレス自動構成によるサイトローカル／グローバルアドレスの生成を即座に行うため、ルータ請求メッセージを送信して隣接ルータに対してルータ広報メッセージを即座に送信するよう要求します。しかし、使用しているHUBでSTP(スパニングツリープロトコル)が動作している場合等は、インタフェースの活性化後、実際に通信ができるようになるまでにある程度の時間がかかるため、ルータ広報メッセージの要求に失敗する場合があります。一般に、IPv6ルータでは定期的にルータ広報メッセージを送信しているため、このような場合でもある程度時間が経過すれば、ステートレスアドレス自動構成が動作し、サイトローカル／グローバルアドレスによる通信が可能となりますが、ルータがルータ広報メッセージを送信する際の間隔が長い場合、ステートレスアドレス自動構成が動作し通信が可能となるまでに時間がかかる場合があります。このような場合は、待機パトロールを使用し運用NIC、待機NICの双方で常時リンクが確立されるようにするか、ルータの設定を変更し、ルータ広報メッセージが1～2分程度の間隔で送信されるようにしてください。

F.2.1.4 ホットスタンバイ構成のGSと通信ができない

現象: ホットスタンバイ構成のGSと通信ができない。

原因および対策

hanetobservコマンドの設定の誤りが原因です。

以下のようにGSの仮想IPアドレスがノード間で移動する場合、GSのノード単位でhanetobserv createコマンドを実行して設定してください。

# /opt/FJSVhanet/usr/sbin/hanetobserv create -n GS -i 192.168.120.20 -t 192.168.10.20,192.168.20.20 -m on -r on
# /opt/FJSVhanet/usr/sbin/hanetobserv create -n GS -i 192.168.120.20 -t 192.168.10.30,192.168.20.30
# /opt/FJSVhanet/usr/sbin/hanetobserv print
 Destination Host Virtual Address  POLL RIP  NIC Address(:PMgroupID)
+----------------+----------------+----+----+---------------------------------+
 GS               192.168.120.20   ON   ON   192.168.10.20,192.168.20.20
                                             192.168.10.30,192.168.20.30

以下のように設定した場合は通信相手が1ノードとして設定されます。クラスタ構成として設定したい場合は、1ノードずつコマンドを実行して設定してください。なお、上記の設定との違いは、hanetobserv printコマンドで表示される"NIC Address"欄のIPアドレスのリストがカンマでつながっているかで判別してください。カンマ（,）がある場合は、通信相手が4つのIPアドレスを持つ1ノードとして認識されます。(192.168.10.20,192.168.20.20,192.168.30.20,192.168.40.20)

# /opt/FJSVhanet/usr/sbin/hanetobserv create -n GS -i 192.168.120.20 -t 192.168.10.20,192.168.20.20,192.168.30.20,192.168.40.20 -m on -r on
# /opt/FJSVhanet/usr/sbin/hanetobserv print
 Destination Host Virtual Address  POLL RIP  NIC Address(:PMgroupID)
+----------------+----------------+----+----+---------------------------------+
 GS               192.168.120.20   ON   ON   192.168.10.20,192.168.20.20,
                                             192.168.30.20,192.168.40.20