HSRP のフラッピング対処｜状態変化ログからの切り分け手順

はじめに

運用中のログに%HSRP-6-STATECHANGEが並んでいる、あるいは通信が断続的に途切れるという報告を受けて調査を始める場面があります。HSRP の状態が Active と Standby の間で頻繁に切り替わる、いわゆるフラッピングです。

このとき押さえておきたいのは、HSRP そのものに問題があるケースは多くないという点です。HSRP の状態変化は、対向からの Hello パケットを受信できなかった結果として発生します。原因を探すべきなのは、Hello の欠落を引き起こした別の要因です。

結論から述べます。HSRP は対向から 3 回連続で Hello を受信できないと状態を変えます。既定値では約 10 秒の欠落で切り替わる計算です。原因として頻度が高いのは物理層の問題と、スパニングツリーに起因する過剰なトラフィックです。%HSRP-6-STATECHANGE自体は状態が変わったことを記録するログであり、Cisco の推奨アクションは対処不要とされています。このログを追いかけても原因には到達しません。

症状から原因を絞り込む

まず、確認したい症状から該当セクションへ進む形で整理します。

複数の症状が同時に出ている場合、物理層から確認を始めることをおすすめします。Cisco のトラブルシューティング手順でも、物理層の確認が上位に置かれています。上位レイヤーから調べ始めると、根本原因にたどり着くまでに時間がかかります。

HSRP の状態変化が示すこと

原因を探す前に、ログが何を意味しているかを整理します。

状態が変わる条件

HSRP は、対向から Hello パケットを受信できなくなると状態を変えます。判定の条件は明確です。

3 回連続で Hello パケットを受信できなかった場合に、状態変化が発生します。

参考: Cisco Community / HSRP status flaps between active and standby state
“HSRP changes its state when it fails to receive three consecutive HSRP hello packets”
（HSRP は、3 回連続で Hello パケットの受信に失敗すると状態を変更します）
https://community.cisco.com/t5/networking-knowledge-base/hsrp-status-flaps-between-active-and-standby-state-and-user/ta-p/3132219

既定値で計算すると次のようになります。

Hello 3 秒 × 3 回で 9 秒、Hold 時間が 10 秒のため、約 10 秒の欠落で Standby が Active へ遷移します。

逆に言えば、10 秒未満の瞬断であれば状態は変わりません。フラッピングが発生しているということは、10 秒以上にわたって Hello が届かない状態が繰り返し発生していることを意味します。

各パラメーターの設定方法は、関連記事『HSRP の設定手順｜priority と preempt の設計ポイント』で扱っています。

ログの読み方

代表的な 2 つのログを整理します。

%HSRP-6-STATECHANGE

%HSRP-6-STATECHANGE: GigabitEthernet0/1 Grp 1 state Standby -> Active

グループの状態が変わったことを示すログです。Cisco の推奨アクションは「対処不要」とされています。ログとしては情報レベル（重大度 6）であり、それ自体が異常を示すものではありません。

初期構築時や意図した切り替えテストの際には正常に記録されます。問題になるのは、意図しないタイミングで繰り返し記録される場合です。

%STANDBY-3-DUPADDR

%STANDBY-3-DUPADDR: Duplicate address 192.168.100.254 on GigabitEthernet0/1

こちらは重大度 3 のログで、より注意が必要です。詳細は後半のセクションで扱います。

ログから読み取れること・読み取れないこと

状態変化のログを集めても、原因の特定には直結しません。整理すると次のようになります。

ログから得られる最も有用な情報は「発生の頻度とパターン」です。

• 一定間隔で規則的に発生: STP の再計算やタイマーに起因する可能性
• 特定の時間帯に集中: トラフィック増や CPU 使用率の高騰
• 機器の追加や設定変更の直後から: 変更内容との関連

まずログの時刻を並べ、パターンを確認することをおすすめします。この段階で当たりを付けておくと、以降の切り分けが速くなります。

状態遷移の履歴を確認する

show standbyの出力にも、切り分けに使える情報があります。

R1# show standby
GigabitEthernet0/1 - Group 1 (version 2)
  State is Active
    12 state changes, last state change 00:02:15
  Virtual IP address is 192.168.100.254
  Active virtual MAC address is 0000.0c9f.f001 (MAC In Use)
  Hello time 3 sec, hold time 10 sec
  Preemption enabled
  Standby router is 192.168.100.252, priority 100 (expires in 8.512 sec)
  Priority 110 (configured 110)

確認したいのはstate changesの値です。この例では 12 回の状態変化が記録されており、最後の変化が 2 分 15 秒前です。

正常に稼働している環境であれば、この値は構築時や計画的な切り替え作業の回数程度にとどまります。稼働時間に対して値が大きい場合、フラッピングが継続していると判断できます。

もう 1 点、Standby router isの行に表示される expires の値も確認します。Hold 時間である 10 秒に対して余裕がある値であれば、Hello は正常に届いています。この値が小さいまま推移する場合、Hello の到達が不安定になっている可能性があります。

対向機と両方の出力を確認する

切り分けでは、両機のshow standbyを並べて確認することをおすすめします。

片方向の問題であれば、経路上の特定のポートやリンクに絞り込めます。この段階で範囲を狭められると、以降の物理層の確認が効率的になります。

原因別の確認と対処

ここからは、原因ごとに症状・仕組み・確認方法・対処の順で整理します。上から順に確認を進めることをおすすめします。頻度の高い原因から並べているためです。

原因 1: 物理層の問題

Cisco のトラブルシューティング手順でも、物理層の確認は優先度の高い項目として扱われています。HSRP パケットの欠落を引き起こす原因として、もっとも頻度が高いとされているためです。

症状

• 両機のstate changesがともに増加している
• 特定のポートやリンクに関連して発生している
• 機器の移設やケーブル交換の後から発生し始めた

確認方法

インターフェースのエラーカウンターを確認します。

R1# show interfaces GigabitEthernet0/1

確認したい項目を整理します。

とくに注目したいのがlate collisionsです。全二重で動作しているはずのリンクにこの値が計上されている場合、片側が全二重、片側が半二重という不一致が疑われます。

デュプレックスとスピードの設定を、両端で確認します。

R1# show interfaces status

オートネゴシエーションを使う場合は両端をオートに、固定する場合は両端を固定に揃えます。片側だけ固定にすると不一致が生じます。

継続的な監視

エラーカウンターは累積値のため、いつ発生したかが分かりません。切り分けでは、カウンターをクリアしてから一定時間の増加を観察する方法が有効です。

R1# clear counters GigabitEthernet0/1

数分後に再度show interfacesを実行し、増加の有無を確認します。増加が続いていれば物理層の問題が継続しています。

なお、clear countersは運用中の機器でも実行できますが、他の調査で使用中のカウンターも消える点には注意が必要です。実行前に関係者への確認をおすすめします。

対処

物理層の問題が特定できた場合の対処です。

物理層の問題であれば、対処後に状態変化が止まることで確認できます。show standbyのstate changesが増加しなくなるかを、しばらく観察することをおすすめします。

原因 2: STP に起因する問題

物理層に問題が見つからない場合、次に疑うのがスパニングツリーです。とくに、高優先度の機器を追加した直後から不安定になった場合、この原因である可能性が高くなります。

症状

• 高い priority と preempt を設定した機器を LAN に追加した直後から発生
• 低優先度側の状態が Active → Speaking → Standby → Active と循環している
• スイッチのログに STP のトポロジー変化が記録されている

Cisco の公式ドキュメントでは、この循環する状態変化が典型例として示されています。

発生する仕組み

一見すると HSRP の問題に見えますが、実際には HSRP と STP の相互作用によるものです。連鎖は次のように進みます。

1. 高優先度のルーターが LAN に追加されます
2. 低優先度側の HSRP 状態が Active から Speaking へ変化します
3. この変化に伴い、リンクステート変化が発生します（プラットフォームによる）
4. スイッチのポートがリンクステート変化を検知し、STP の遷移が始まります
5. ポートが listening、learning、forwarding の各段階を通過するのに約 30 秒かかります
6. この 30 秒が HSRP の Hold 時間（既定 10 秒）を超えます
7. Standby へ到達した低優先度側が、Hello を受信できないため Active になります
8. 状態変化が再び発生し、2 に戻ります

HSRP の Hold 時間が STP の収束時間より短いことが、循環の原因です。

参考: Avoiding HSRP Instability in a Switching Environment with Various Router Platforms
“This time period exceeds the default timeouts of the HSRP hello processes”
（この時間は HSRP の Hello プロセスの既定のタイムアウトを超えます）
https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/13782-8.html

確認方法

スイッチ側で STP の状態を確認します。

Switch# show spanning-tree vlan 100
Switch# show spanning-tree detail

確認したい項目です。

HSRP の状態変化とスイッチの STP トポロジー変化の時刻を突き合わせると、因果関係を確認できます。両者が対応していれば、この原因である可能性が高くなります。

対処 1: STP の収束時間を短縮する

もっとも根本的な対処です。ルーターやサーバーが接続されるアクセスポートでは、STP の遷移を待つ必要がありません。

Switch(config)# interface GigabitEthernet1/0/1
Switch(config-if)# spanning-tree portfast

PortFast を設定すると、ポートが listening と learning を経由せず、即座に forwarding 状態になります。30 秒の待ち時間が発生しなくなるため、連鎖の起点が解消されます。

ただし、PortFast はループを発生させる可能性があるポートには設定できません。スイッチやハブが接続される可能性があるポートでは使用を避けます。あわせて BPDU Guard を設定し、想定外の BPDU を受信した場合にポートを遮断する構成を推奨します。

Switch(config-if)# spanning-tree bpduguard enable

対処 2: HSRP のタイマーを調整する

STP 側を変更できない場合の選択肢です。Cisco のドキュメントでは、STP の Forward Delay（既定 15 秒）が HSRP の Hold 時間の半分より小さくなるようタイマーを調整する方法が案内されています。推奨値として Hold 時間 40 秒が示されています。

R1(config-if)# standby 1 timers 10 40

Hello 10 秒、Hold 40 秒という設定です。

この対処にはトレードオフがあります。同じドキュメントに、Hold 時間を延ばすと HSRP による Active ルーターのダウン検知が遅くなり、Standby が Active になるまでの時間が長くなると明記されています。

実際の障害時に約 40 秒の通信断が発生することになります。可用性要件によっては受け入れられない値です。

対処の選択

2 つの対処の使い分けを整理します。

可能であれば PortFast による対処を推奨します。タイマー調整は症状を抑える対処であり、STP の収束時間そのものは変わりません。

なお、タイマーを変更する場合は Master と Backup の両機で同じ値に揃えます。片側だけ変更すると、意図しない挙動になります。

原因 3: CPU 使用率の高騰

物理層にも STP にも問題が見つからない場合、機器の処理能力を疑います。HSRP の状態変化は CPU 使用率の高騰に起因することが多いと、Cisco のドキュメントでも指摘されています。

症状

• 特定の時間帯に集中して発生する
• バックアップやウイルス定義の配信など、定期的な処理と時刻が重なる
• 物理層のエラーカウンターが増加していない
• 機器全体のレスポンスが遅い

時間帯との相関がある場合、この原因の可能性が高くなります。前述したログのパターン確認が、ここで役に立ちます。

仕組み

HSRP の Hello はソフトウェアで処理されます。CPU の負荷が高い状態では、受信した Hello の処理が遅延したり、送信が間に合わなかったりする状況が発生します。

パケット自体は経路上を届いていても、機器内部で処理されなければ受信していないのと同じ結果になります。ケーブルやスイッチには問題がないため、物理層の確認では原因が見つかりません。

確認方法

CPU 使用率と、その内訳を確認します。

R1# show processes cpu sorted
R1# show processes cpu history

show processes cpu historyは、過去 60 秒・60 分・72 時間の推移をグラフで表示します。HSRP の状態変化が記録された時刻と、CPU 使用率のピークが対応しているかを確認できます。

show processes cpu sortedでは、使用率の高いプロセスから順に表示されます。特定のプロセスが突出している場合、そのプロセスに関連する処理を調査します。

インターフェースの負荷も確認します。

R1# show interfaces GigabitEthernet0/1 | include rate

入出力のレートが機器の処理能力に対して過大でないかを確認します。

対処

原因となっている処理を特定できた場合の対処です。

Cisco のドキュメントでは、CPU 使用率の高騰が原因である場合、ネットワークにアナライザーを設置して原因となるシステムをトレースする手順が案内されています。トラフィックの発生源を特定できれば、対処の方向が定まります。

暫定対処としては、HSRP のタイマーを延長する方法もあります。処理の遅延を許容できる範囲まで Hold 時間を延ばせば、状態変化は抑えられます。ただし前述のとおり、障害検知が遅くなるトレードオフを伴います。根本原因の解消とセットで検討することをおすすめします。

原因 4: 重複アドレスのログ

%STANDBY-3-DUPADDRは重大度 3 のログで、状態変化のログより注意が必要です。

ログの内容

%STANDBY-3-DUPADDR: Duplicate address 192.168.100.254 on GigabitEthernet0/1

仮想 IP アドレスが重複していることを示すログですが、実際には設定の重複ではないケースが多くを占めます。

報告された MAC アドレスで判断が分かれる

このログを切り分ける際の分岐点は明確です。ログに含まれる MAC アドレスが、HSRP の仮想 MAC アドレスかどうかを確認します。

参考: Troubleshoot HSRP Common Issues
“The most common causes for the move of MAC addresses are spanning tree problems”
（MAC アドレスが移動する原因として最も多いのは、スパニングツリーの問題か物理層の問題です）
https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/10583-62.html

仮想 MAC アドレスはグループ番号から計算できます。HSRPv2 でグループ 1 であれば0000.0C9F.F001です。計算方法は関連記事『HSRP 仮想 MAC と use-bia｜使ってはいけない場面の判断』で扱っています。

切り分けの手順

Cisco のドキュメントには、このログに対する切り分け手順が示されています。

Switch# show mac address-table address 0000.0c9f.f001

Switch# show spanning-tree vlan 100 detail

Switch# show etherchannel summary
Switch# show interfaces port-channel 1

非対称ルーティングとの関連

Cisco のドキュメントには、非対称ルーティングに関するケーススタディも含まれています。往路と復路で異なる経路を通る構成では、ユニキャストトラフィックの過剰なフラッディングが発生する可能性があります。

PBR で往路を固定している構成では、この状況が生じやすくなります。設計上の対処は、関連記事『PBR と HSRP・VRRP の組み合わせ｜ブラックホール化の回避』で扱っています。

なお、Cisco のドキュメントでは、このログが初期構築時以外に発生する場合、HSRP そのものが原因である可能性は低いとされています。ネットワークの不安定さがログを引き起こし、その結果として通信の遅延やパケットロスが生じる、という因果関係になります。

切り分けの手順

ここまでの内容を、実施する順序として整理します。Cisco のトラブルシューティングモジュールの構成に沿った流れです。

段階的な確認手順

上から順に進めることをおすすめします。設定の不一致という単純な原因を先に除外しておくと、以降の調査が効率的になります。

R1# debug standby terse

R1# undebug all

use-bia を検討する前に

HSRP のフラッピングを調べていると、対処法としてstandby use-biaを紹介する情報に行き当たることがあります。適用の判断について整理します。

効果がある範囲

このコマンドは、HSRP の仮想 MAC アドレスの代わりにインターフェースの焼き付け MAC アドレスを使わせるものです。フラッピングに対して効果があるのは、次の 2 つのケースに限られます。

前者は、本記事で扱った原因 2 の連鎖の起点になり得ます。リンクステート変化が抑えられれば、STP の遷移も発生しません。

すべてのフラッピングに効くわけではない

一方で、物理層の問題、CPU 使用率の高騰、STP のループといった原因には効果がありません。原因を特定しないまま適用しても、症状は改善しません。

Cisco のドキュメントでも、Token Ring インターフェース以外では特殊な状況に限って使用するよう案内されています。

適用に伴う副作用

さらに、このコマンドには無視できない副作用があります。

• Proxy ARP が機能しなくなります。Standby は障害機の Proxy ARP データベースを引き継げません
• フェイルオーバー時に仮想 IP に対応する MAC が変わります。復旧がホスト側の Gratuitous ARP の処理実装に依存する構成になります
• サブインターフェースに設定すると、scope interfaceを付けない限りメインインターフェースへ適用が波及します

原因が特定できていない段階での適用は推奨しません。詳細な制約と代替手段は、関連記事『HSRP 仮想 MAC と use-bia｜使ってはいけない場面の判断』で扱っています。

判断の順序

use-bia を検討する場合の順序を整理します。

多くのケースは第 1 段階から第 3 段階で結論が出ます。use-bia まで到達するのは、原因が絞り込めた限られた場合です。

まとめ

HSRP のフラッピングは、HSRP そのものではなく Hello パケットの欠落を引き起こす要因が原因となっているケースがほとんどです。状態変化のログは発生の事実を示すもので、原因の特定には物理層から段階的に絞り込む手順が有効になります。対処として提示される設定変更の多くはトレードオフを伴うため、副作用を把握したうえで選択することをおすすめします。

• HSRP は 3 回連続で Hello を受信できないと状態を変える
• %HSRP-6-STATECHANGE は情報レベルのログで対処不要とされる
• ログの時刻とパターンから当たりを付けると切り分けが速くなる
• 高優先度機の追加による不安定化は STP の収束時間が原因
• Hold 時間 40 秒への調整は切り替わりも 40 秒に延ばすトレードオフ
• %STANDBY-3-DUPADDR は報告された MAC が仮想 MAC かで判断が分かれる
• use-bia は原因を特定してから検討し、Proxy ARP の有無を確認する

以上、最後までお読みいただきありがとうございました。