現象
以下のようなメッセージ(*1)がシステムログに出力されてNICの切替えが発生しました。
hanet: ERROR: 87000: polling status changed: Primary polling failed. (eth0,target=192.168.70.100) |
# /opt/FJSVhanet/usr/sbin/dsppoll Polling Status = ON interval(idle) = 5( 60) times = 5 repair_time = 5 link detection = NO FAILOVER Status = YES Status Name Mode Primary Target/Secondary Target HUB-HUB +------+------+----+-------------------------------------------+-------+ ON sha0 d 192.168.70.100(FAIL)/192.168.70.101(ON) OFF |
*1) セカンダリNICを運用NICとして使用している時は、“Primary polling”ではなく、“Secondary polling”と出力されます。
原因と対策
NIC切替方式では、指定された監視先にpingを実行し伝送路監視を行っています。pingの疎通ができなくなったことを検出したため、本メッセージが出力され、NICの切替えが行われました。以下の項目について確認を行ってください。
導入/構成変更時に切替えが発生した場合
導入/構成変更時はGLSの設定およびネットワーク構成の誤りによる切替えが多いため以下について確認してください。
確認項目 | |
|---|---|
ケーブル | 接続確認 |
種別 | |
GLSの設定 | 監視先の設定 |
監視パラメタの設定 | |
ネットマスクの設定 | |
HUBの設定 | STPの設定確認 |
VLAN-ID | |
ネットワーク状態 | 通信負荷 |
システムログ | |
自ノードの設定 | IPフィルタリング |
ネットワークアドレスの設定 | |
IPアドレス | |
運用中に切替えが発生した場合
運用中は伝送路異常による切替えが多いため以下について確認してください。
確認項目 | |
|---|---|
ケーブル | 接続確認 |
種別 | |
HUBの設定 | 通信モードの確認 |
QoS | |
ネットワーク状態 | 保守作業状況の確認 |
通信負荷 | |
HUBの状態 | |
システムログ | |
GLSの設定 | 監視先の設定 |
各確認項目の詳細は以下のとおりです。
確認項目 | 内容 | |
|---|---|---|
ケーブル | 接続確認 | 1) ケーブルが抜けている可能性があります。 |
種別 | 1) 使用しているケーブルの種類(ストレートケーブル、クロスケーブル)が正しいことを確認してください。なお、ケーブルの種別を自動認識する機能(Auto-MDIX)は、通信モードをオートネゴシエーションに設定しないと有効にならない場合があります。詳細は、HUBのマニュアルを確認してください。 | |
GLSの設定 | 監視先の設定 | 監視先のHUBのIPアドレスと監視先として定義したIPアドレスが異なった場合、監視に失敗し切替えが発生します。監視先のHUBのIPアドレスと監視先として定義したIPアドレスが一致していることをhanetpollコマンドで確認してください。 |
監視パラメタの設定 | デフォルトではpingによる監視は、5秒間隔で5回連続失敗した場合に伝送路異常と判断するよう設定されています。このパラメタを短く設定した場合、誤切替え(伝送路が正常にも関わらず、誤って切替えを行ってしまうこと)が発生する可能性があります。誤切替えが頻繁に発生する場合は伝送路異常の検出時間の設定値を長くしてください。 | |
ネットマスクの設定 | ネットマスクの設定が誤っている場合、通信に失敗する可能性があります。ifconfigコマンドでネットマスクの設定を確認してください。また、hanetmaskコマンドで行った設定を確認してください。 | |
HUBの設定 | 通信モード | 自ノードで使用しているインタフェースとHUBのポートに設定されている通信モードに不整合がないか確認してください。HUBと自ノードで通信モードが異なる場合、コリジョンが発生しパケットロストが多発する場合があります。(例：自ノード側をオートネゴシエーション、HUB側を全二重固定に設定した場合)。なお、Ethernetで接続する機器同士は以下の通信モードである必要があります。 |
STPの設定 | STP(スパニングツリープロトコル)を有効にしている場合、GLSで使用しているインタフェースの活性化直後や切替え直後、30秒程度通信ができなくなります。この間GLSは、HUB監視の失敗によりNICの切替えを行わないよう抑止しています。抑止を行う時間は“リンクアップ遅延時間”というパラメタとしてhanetpollコマンドで設定されています(デフォルトで60秒)。このパラメタ値が小さいと、NICの誤切替えが発生する場合があります。以下の方法で対処を行ってください。 | |
VLAN－ID | VLAN-IDの設定に誤りがある可能性があります。以下のVLAN-IDが一致しているか確認してください。 | |
QoS | HUBのQoS(Quality of Service)設定で、pingに対する処理の優先度を低く設定した場合、ネットワーク高負荷時に、HUBからのping応答が遅延する場合があります。この場合、伝送路が正常にも関わらず、NICの切替えが発生することがあります。QoSの設定を見直してください。 | |
ネットワーク状態 | 保守作業 | 切替えが発生した時間帯で、監視先に設定しているHUBの再起動や交換等の保守作業を行っていないことを確認してください。なお、監視先としているHUBの交換を行う場合は、必ず、HUB監視を停止した後にHUBの交換を行ってください。 |
通信負荷 | 切替えが発生した時間帯で、一時的にネットワークのトラフィックが高かったためにpingの遅延やパケットロストが発生した可能性があります。HUBの統計情報やログから、コリジョンやパケットロストの有無を確認してください。Linuxの場合は、sarコマンドで、切替えが発生した時間帯の送受信パケット数等を確認してください。なお、異なる速度(1Gbpsと100Mbps等)のネットワークが混在している環境では、高速なネットワークで帯域に余裕があっても、低速なネットワークに中継するHUBでパケットロストが発生する場合があります。トラフィックの見積もりが正しく行われているかを確認してください。 | |
HUBの状態 | HUBの故障および電源が切れた可能性があります。システムログにリンクダウンメッセージが出力されていないか確認してください。HUB故障の際はパケットがループしている場合がありますので、netstatコマンドでコリジョンが発生していないか確認してください。また、隣接HUB以外をHUB監視機能の監視先に設定している場合は、HUBと監視先の間のケーブルが抜けている可能性があります。 | |
システムログ | 1) HUB監視を行っていたNICがリンクダウンした可能性があります。切替えが発生した時間帯でシステムログにリンクダウンメッセージが出力されているか確認してください。 | |
自ノードの設定 | IPフィルタリング | GLSが使用しているインタフェースに対して、IPパケットのフィルタリングが行われている場合があります。IPフィルタリングを行っている場合は、ファイアウォールの設定を確認してください。ファイアウォールにおいて、pingのパケットが通過するよう設定してください。 |
ネットワークアドレスの設定 | netstat -rnコマンドを実行し、GLSの仮想IPアドレスと同一ネットワークの伝送路が無い事を確認してください。ネットワークが重複している場合、正しい経路でpingの送信(HUB監視)ができないため、GLSが使用している伝送路で異常が発生した際に、NICの切り替えが行われなかったり、逆に、GLSの使用していない伝送路で異常が発生した際に、切り替えが発生したりします。IPアドレス、ネットマスクの設定を見直してください。また、ネットワーク構成が、同一サブネットに3枚以上のNICを接続している構成(1つのサブネットに対して、仮想インタフェースが束ねるNICの組み合わせが2種類以上ある構成)になっていないことを確認してください。ある場合は、構成を見直してください。 | |
IPアドレス | 自ノードで設定したIPアドレスが、他のノードで使用しているIPアドレスと重複していないことを確認してください。重複している場合、通信相手からのpingの応答が、pingの送信元ノードと異なるノードあてに送信され、通信できなくなる場合があります。この場合、HUB監視が失敗します。 | |
