CCNA学習89日目|FHRP基礎(第3回)HSRPの切替速度と役割交代の仕組み

CCNA学習89日目のFHRP基礎(第3回)アイキャッチ画像。HSRPの切替速度と役割交代の仕組みとして、Hello timer・Hold timer、Priority、Preempt、Tracking、Failoverの関係を図解した学習用サムネイル 資格学習ログ

前回は、FHRPがデフォルトゲートウェイを止まりにくくするための仕組みだと整理しました。今回は、その代表例である HSRP(Hot Standby Router Protocol) をもう少し深掘りします。HSRPはCisco独自の冗長化プロトコルで、普段は1台が主担当として動き、もう1台が待機し、障害が起きたときに役割を引き継ぐ仕組みです。今回は特に、切り替えまでの速さを決めるtimer と、どの機器を主担当にするかに関わるpreempt・tracking の考え方を中心に整理していきます。

Timerとは何か

HSRPでは、切り替えの速さに大きく関わるのがtimerです。特に基本として押さえたいのが、Hello timer と Hold timer の2つです。Hello timerは、Active側が自分の生存を知らせるメッセージを送る間隔で、一般的な学習の入り口としては3秒で理解すると分かりやすいです。一方のHold timerは、Standby側が「もうActiveから応答が来ない」と判断するまでの待ち時間で、こちらは10秒として整理するとイメージしやすいです。

つまり、Standbyは単にぼんやり待っているのではなく、Helloメッセージを受け取りながらActiveの状態を見ています。そして一定時間Helloが来なければ、「Activeに障害が起きた」と判断して自分が引き継ぐ流れになります。今回の1枚目のキャプチャでは、この流れが時間軸つきで整理されていて、とても分かりやすいです。

HSRPにおけるHello timerとHold timerの基本、および障害発生からStandbyがActiveへ切り替わるまでの時間の流れを示した図解
HSRPでは、Hello timerで生存確認を行い、Hold timerが満了するとStandbyが新しいActiveとして引き継ぎます。

Hello timerとHold timerの関係

Hello timerとHold timerは、単独で覚えるよりセットで理解するほうが頭に入りやすいです。Helloは「元気ですという定期連絡」、Holdは「それが来なくなってからあきらめるまでの猶予時間」と考えると自然です。ActiveがHelloを送り続けている間はStandbyは待機し、Helloが止まってHold timerが満了すると、Standbyが新しいActiveになります。

この考え方から分かるように、timerを短くすれば障害検知と切り替えは速くなります。ただし、そのぶん誤検知制御負荷の影響を受けやすくなる点には注意が必要です。速ければよい、ではなく、ネットワーク全体の安定性とのバランスで考える必要がある、というのが今回のポイントだと感じました。

Preemptとは何か

Preemptは、優先度の高い機器に主担当を取り戻させるための設定です。preemption機能を有効にすると、より高いpriorityを持つルータが参加したときに即座にActiveの役割を取れるようになります。つまり、構成上「本来この機器が主担当であるべき」と決めているなら、その意図を反映するための設定がPreemptです。

ただし、Preemptは便利な反面、復旧直後に再切り替えを起こす可能性がある点も意識しておきたいところです。障害から戻った機器が高priorityだからといってすぐActiveを取り戻すと、短時間で役割交代がもう一度発生することがあります。学習段階では、Preemptは「主担当に戻すための設定」である一方、「再度の切り替えを起こしうる設定」でもある、と両面で理解しておくとよさそうです。

HSRPにおけるPreemptとTrackingの考え方、WAN障害時のpriority低下による役割切り替え、そしてPriority・Preempt・Trackingの違いを整理した学習用図解
HSRPでは、Trackingで状態悪化をpriorityに反映し、必要に応じてPreemptでより適切な機器へ主担当を切り替えられます。

Trackingとは何か

Trackingは、別のインターフェースの状態を監視し、その結果に応じてHSRP priorityを下げる仕組みです。

ここで大事なのは、LAN側のインターフェースが生きているだけでは「そのルータが本当に主担当のままでよい」とは限らないことです。たとえば上流のWANが切れているのに、LAN側だけ正常だからという理由でActiveを続けてしまうと、端末から見た出口としては困る状況になります。そこでTrackingを使うことで、上流断などの異常を反映してpriorityを下げ、より健全な機器へ役割を渡しやすくするわけです。

Priority・Preempt・Trackingの整理

この3つは似て見えますが、役割はそれぞれ違います。
Priority は、「誰が主担当にふさわしいか」を数値で決める基準です。
Preempt は、「高priorityの機器が主担当を取り戻すかどうか」を決める動作です。
Tracking は、「状態悪化を検知したときにpriorityを下げて、役割を渡しやすくする仕組み」です。

言い換えると、Priorityは強さの数値、Preemptは取り戻す意思、Trackingは状態悪化を反映する判断材料です。この3つを別々に覚えるより、セットで関係づけて理解したほうが、HSRPの動き全体がかなり見えやすくなると思います。

障害時にどう役割が切り替わるのか

今回の2枚のキャプチャを並べて見ると、HSRPの切り替わりには大きく2つの視点があることが分かります。1つは、Hello / Hold timerによる障害検知の速さです。Helloが来なくなり、Hold timerが満了した時点でStandbyがActiveへ切り替わるため、timerは障害検知の速さそのものに関わります。

もう1つは、Priority / Preempt / Trackingによる「誰が主担当になるべきか」の判断です。単にActiveが落ちたからStandbyが上がるだけでなく、上流断などの状態変化によってpriorityを下げたり、復旧した高priority機器が主担当を取り戻したりすることで、より適切な機器へ役割を渡せるようになります。

今回のまとめ

今回整理してみて、HSRPの切り替えは単に「故障したら交代する」というだけではなく、どのくらい早く異常を見つけるかと、どの機器に役割を持たせるべきかの2つで成り立っているのだと見えてきました。前者を担うのがHello timerとHold timer、後者を支えるのがPriority・Preempt・Trackingです。

特に今回は、Trackingの考え方がとても重要だと感じました。LAN側が生きていても、上流が切れていれば「主担当のままでよい」とは言えません。その状況をHSRPの役割選出に反映するためにTrackingがあり、そこへPreemptやPriorityが組み合わさることで、より現実的な冗長化が実現されるのだと理解できました。

コメント

タイトルとURLをコピーしました