ネットワーク
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

DefaultGatewayがFireWallだった場合

J_Sak
時折のビジター

DefaultGatewayがFireWallだった場合

HP-UX B.11.11 を使用しております。

このサーバ(A)のDefaultGatewayとして指定してある機器がFireWallで、AからのICMPを受け付けておりません。

ただし、FireWallでは、このサーバとFireWallを通過して通信が必要な別セグメント上のサーバ(B)と通信を許可しております。

この時、OS起動後しばらくするとAから通信ができなくなってしまいます。

AからBに通信しようとしてもFireWallまでパケットが到着していないようです。

ちなみに、Aと同じセグメント上にいるWindows2000などは問題なく通信できてしまいます。

また、FireWallでAからのICMP要求を受け付けると問題なく通信できます。

HP-UXではDefaultGatewayに設定した機器がICMP要求を返さないと、ルーティングできなくなってしまうのでしょうか?

3 件の返信
st
頻繁なアドバイザー

DefaultGatewayがFireWallだった場合

Default Gateway の生死を調べる Dead Gateway Detection 機能がデフォルト

で ON になっています。デフォルトで 190 秒間 (ip_ire_gw_probe_interval

+ 10000 ミリ秒) 調べています。この時間を越えて ICMP パケットが戻ってこ

ないため、ご質問の現象が発生しています。

% ndd -get /dev/ip ip_ire_gw_probe

1

%

1 の場合 probing、0 の場合 not probing を意味しています。

したがって、root 権限にて以下のようにすると、一時的に Dead Gateway

Detection 機能を OFF にすることが可能です。

# ndd -set /dev/lp ip_ire_gw_probe 0

なお、以下の 3 行を /etc/rc.config.d/nddconf に追加すれば、恒常的に対

策を取ることが可能です。

TRANSPORT_NAME=ip

NDD_NAME=ip_ire_gw_probe

NDD_VALUE=0

お試しあれ。
J_Sak
時折のビジター

DefaultGatewayがFireWallだった場合

早速の返信ありがとうございます。

なるほど、確かに、ip_ire_gw_probeは1となっていました。

実機検証はまだ行えていないですが、状況からこれに間違いなさそうですね。

さらに調べたところ、この項目はバージョンによってデフォルト値が変わることもわかりました。

初期導入時に注意する必要があるんですね。
st
頻繁なアドバイザー

DefaultGatewayがFireWallだった場合

HP-UX 11.0 から Dead Gateway Detection 機能が導入されているようです。

なお、昨今の OS (例えば、HP-UX 11i v2 (B.11.23)) になるとホスト要塞化

ツール Bastille をインストールしたりすることがありますね。この場合、

ip_ire_gw_probe を含むいくつかのネットワーク調整パラメータの値がデフォ

ルトの 1 から 0 に変更されます。