ちらりんブログ ロゴ ちらりんブログ
STUDY · NETWORK GUIDE

3-12 FHRP — HSRP / VRRP / GLBP によるデフォルトゲートウェイ冗長化

デフォルトゲートウェイの単一障害点を解消する FHRP を扱う。HSRP / VRRP / GLBP の仮想 MAC・preempt 差・負荷分散の違いを、CML2.9 IOS-XE 17.x の R1/R2 に同時設定して実機比較する。

1. 前節の振り返りと本節の内容

3-3 から 3-11 まで、第 3 章では経路制御を扱ってきました。距離ベクトル型とリンクステート型の IGP (Interior Gateway Protocol)、パスベクトル型の BGP (Border Gateway Protocol)、プロトコル間の再配送、そして route-map を中核とするルーティングポリシーまで、「経路をどう計算し、どう選び、どう制御するか」が一貫したテーマでした。これらはいずれも、ルータ同士が経路情報を交換して最適な転送先を決める仕組みです。

本節 3-12 は視点を移し、エンドホストから見た最初のルータ (デフォルトゲートウェイ) そのものの冗長化を扱います。経路がどれほど正しく計算されていても、ホストが外部へ出る入り口となるデフォルトゲートウェイが 1 台で、その 1 台が落ちればセグメント全体が孤立します。この単一障害点 (Single Point of Failure) を、複数のルータで 1 つの仮想ゲートウェイを構成して解消するのが FHRP (First Hop Redundancy Protocol) です。

実機検証では、FHRP の 3 大プロトコルである HSRP (Hot Standby Router Protocol) / VRRP (Virtual Router Redundancy Protocol) / GLBP (Gateway Load Balancing Protocol) を、CML2.9 IOS-XE 17.x の R1 / R2 に別々のグループ番号で同時に設定します。3 プロトコルの仮想 MAC 体系・用語・preempt のデフォルト・タイマー・負荷分散の可否を、show standby / show vrrp / show glbp の出力を 1 つのラボのなかに並べて比較します。

2. FHRP とは — デフォルトゲートウェイの単一障害点を解消する

FHRP は、複数のルータで 1 つの仮想ゲートウェイ (仮想 IP + 仮想 MAC) を共有し、デフォルトゲートウェイを冗長化する仕組みです。エンドホストは通常、デフォルトゲートウェイ IP を 1 つしか設定できません。そのゲートウェイ役のルータが故障すると、ホストは外部へ出る経路を失い、セグメント全体が外部と通信できなくなります。

この問題は、ルーティングプロトコルの冗長化では解決できません。ルータ同士はダイナミックルーティングで複数の経路を持てますが、ホスト側はゲートウェイ IP を静的に 1 つ持つだけで、ゲートウェイが落ちても別のルータへ自動で切り替わりません。仮にホストの設定を手動で書き換えるとしても、セグメント上の全ホストを即座に直すことは現実的ではありません。

FHRP は、この問題をホストの設定を変えずに解決します。複数のルータが協調して 1 つの仮想 IP (VIP = Virtual IP) と仮想 MAC を持ち、ホストはこの仮想 IP をデフォルトゲートウェイにします。実際に転送を担当するルータが落ちても、別のルータが同じ仮想 IP / 仮想 MAC を引き継ぐため、ホストから見れば「1 台の落ちないゲートウェイ」が存在し続けます。ホストは仮想 MAC しか知らず、物理的にどのルータが応えているかを意識しません。

3. 本ラボのトポロジ — 2 ルータ + ホスト + 3 グループ同時設定

検証ラボは、10.1.1.0/24 セグメント上に R1 と R2 の 2 台のルータを置き、その下に HOST (PC 役) をぶら下げる最小構成です。R1 を高 priority、R2 を低 priority にして、R1 に主役 (HSRP Active / VRRP Master / GLBP AVG) を握らせ、R2 を冗長側にします。3 プロトコルを 1 ラボで比較するため、HSRP / VRRP / GLBP を別々のグループ番号で R1 / R2 の両方に同時設定します。

ここで前提を明確にします。実運用では、1 つのセグメントに対して FHRP は 3 プロトコルのうち 1 つだけを選んで使うのが原則です。HSRP・VRRP・GLBP は同じ目的 (デフォルトゲートウェイの冗長化) を達成する代替手段であり、本来は要件に応じてどれか 1 つを採用します。本ラボで 3 つを同時に設定するのは、あくまで 3 プロトコルの仮想 IP / 仮想 MAC・用語・preempt のデフォルト・負荷分散の有無を 1 つの環境で並べて比較するための検証用構成です。3 プロトコルを併用する設計を推奨するものではありません。

各ノードの役割は以下のとおりです。

ノードGi2 (セグメント)priority役割
R110.1.1.1/24110 (高)HSRP Active / VRRP Master / GLBP AVG
R210.1.1.2/2490 (低)HSRP Standby / VRRP Backup / GLBP AVF
HOST10.1.1.10/24—PC 役。デフォルトゲートウェイ = 10.1.1.252 (GLBP VIP)

3 つのグループは、それぞれ別の仮想 IP を持ちます。HSRP がグループ 1 で VIP 10.1.1.254、VRRP がグループ 2 で VIP 10.1.1.253、GLBP がグループ 10 で VIP 10.1.1.252 です。同一セグメント上で 3 プロトコルが衝突せずに共存し、それぞれの仮想 IP / 仮想 MAC を持つ様子を観察します。

3-12 FHRP ラボトポロジ。R1 (priority 110) と R2 (priority 90) が 10.1.1.0/24 セグメントで 1 つの仮想ゲートウェイを構成する。HSRP grp1 (VIP 10.1.1.254) / VRRP grp2 (VIP 10.1.1.253) / GLBP grp10 (VIP 10.1.1.252) の 3 グループを R1/R2 の両方に設定し、HOST は GLBP VIP をデフォルトゲートウェイにする

R1 / R2 の GigabitEthernet2 には、3 プロトコルの設定が並んで投入されています。実機の running-config は以下のとおりです。1 つのインタフェースに standby (HSRP) / vrrp / glbp のコマンドが共存しています。

snippet 
interface GigabitEthernet2
 description FHRP segment 10.1.1.0/24
 ip address 10.1.1.1 255.255.255.0
 standby 1 ip 10.1.1.254
 standby 1 priority 110
 standby 1 preempt
 negotiation auto
 vrrp 2 ip 10.1.1.253
 vrrp 2 priority 110
 no mop enabled
 no mop sysid
 glbp 10 ip 10.1.1.252
 glbp 10 priority 110
 glbp 10 preempt
end

この running-config には、本節の核心の 1 つが既に表れています。HSRP には standby 1 preempt、GLBP には glbp 10 preempt の行があるのに対し、VRRP の vrrp 2 には preempt 行がありません。これは設定漏れではなく、VRRP では preempt がデフォルトで有効なためです。この差は §6・§7・§10 で改めて扱います。

4. HSRP — Active / Standby と仮想 IP/MAC

HSRP は、Cisco 独自の FHRP で、Active / Standby という用語で 2 台のルータの役割を決めるプロトコルです。priority の高いルータが Active となって仮想 IP / 仮想 MAC を保持し、実際の転送を担当します。priority の低いルータは Standby となって待機し、Active が落ちたときに昇格する準備をします。priority のデフォルトは 100 で、本ラボでは R1 を 110、R2 を 90 に設定しています。

Active / Standby の選出結果は、show standby brief で確認できます。R1 が Active、R2 が Standby になり、両者が同じ仮想 IP 10.1.1.254 を共有しています。P の列は preempt が設定されていることを示します。

snippet 
show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Gi2         1    110 P Active  local           10.1.1.2        10.1.1.254

詳細表示の show standby では、仮想 MAC とタイマーが確認できます。HSRP のデフォルト (version 1) では、仮想 MAC が 0000.0c07.ac01 です。この末尾の 01 は HSRP グループ番号 (グループ 1) を 16 進で表したもので、0000.0c07.acXX の XX にグループ番号が入ります。Hello は 3 秒、Hold は 10 秒で、priority 110、Preemption enabled (preempt 有効) が表示されています。

snippet 
show standby GigabitEthernet2 1
GigabitEthernet2 - Group 1
  State is Active
    2 state changes, last state change 00:04:20
  Virtual IP address is 10.1.1.254
  Active virtual MAC address is 0000.0c07.ac01 (MAC In Use)
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.904 secs
  Preemption enabled
  Active router is local
  Standby router is 10.1.1.2, priority 90 (expires in 8.880 sec)
  Priority 110 (configured 110)
  Group name is "hsrp-Gi2-1" (default)
  FLAGS: 1/1

ホスト側から見ると、この仮想 MAC が実際に使われていることが分かります。HOST から仮想 IP 10.1.1.254 へ ping を打ち、ARP テーブルを確認すると、10.1.1.254 が仮想 MAC 00:00:0c:07:ac:01 に解決されています。これは show 出力の 0000.0c07.ac01 と同じ MAC です。HOST は R1 の物理 MAC ではなく、仮想 MAC を学習しています。

snippet 
HOST:~$ ping -c 3 10.1.1.254
PING 10.1.1.254 (10.1.1.254): 56 data bytes
64 bytes from 10.1.1.254: seq=1 ttl=42 time=0.928 ms
64 bytes from 10.1.1.254: seq=2 ttl=42 time=0.973 ms
...
HOST:~$ arp -a
? (10.1.1.254) at 00:00:0c:07:ac:01 [ether]  on eth0

HSRP には version 1 と version 2 があり、version によって仮想 MAC 体系が変わります。standby version 2 を投入すると、仮想 MAC が 0000.0c07.ac01 から 0000.0c9f.f001 に変化します。version 2 では 0000.0c9f.fXXX という体系で、末尾 3 桁 (001) にグループ番号が入り、グループ範囲が 0-255 から 0-4095 に拡張されます。

snippet 
show standby GigabitEthernet2 1
GigabitEthernet2 - Group 1 (version 2)
  State is Active
    5 state changes, last state change 00:00:20
  Virtual IP address is 10.1.1.254
  Active virtual MAC address is 0000.0c9f.f001 (MAC In Use)
    Local virtual MAC address is 0000.0c9f.f001 (v2 default)
  Hello time 3 sec, hold time 10 sec
  Preemption enabled
  Active router is local
  Priority 110 (configured 110)

version 1 と version 2 は仮想 MAC・グループ範囲・マルチキャストアドレスが異なり、同一グループで混在できません。ペアを組むルータは version を揃える必要があります。本節の以降の検証では、version の差を観察し終えた後 version 1 に戻して進めます。

HSRP の Active / Standby 選出。priority の高い R1 (110) が Active になり、仮想 IP 10.1.1.254 と仮想 MAC 0000.0c07.ac01 を保持する。R2 (90) は Standby として待機し転送しない。HOST は ARP 要求でこの仮想 MAC を学習し、以後フレームを仮想 MAC 宛に送る。HOST は仮想 MAC しか知らず、物理的に R1/R2 のどちらが応えているかを意識しない

5. HSRP の failover — Active 落下と Standby 昇格

failover は、Active が落ちたときに Standby が Active へ昇格し、仮想 IP / 仮想 MAC を引き継ぐ動作です。Standby は Active が送る Hello を監視しており、Hold タイマー (デフォルト 10 秒) の間 Hello が届かなければ、Active がダウンしたと判断して自身が Active に昇格します。

R1 の Gi2 を shutdown して Active を落とすと、R2 が Active に昇格します。show standby brief で R2 の State が Active になり、priority 90 のまま Active を担っていることが分かります。最も重要なのは、R2 が自身の物理 MAC ではなく、同じ仮想 MAC 0000.0c07.ac01 を引き継いでいる点です。

snippet 
show standby GigabitEthernet2 1
GigabitEthernet2 - Group 1
  State is Active
    8 state changes, last state change 00:00:33
  Virtual IP address is 10.1.1.254
  Active virtual MAC address is 0000.0c07.ac01 (MAC In Use)
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
  Preemption enabled
  Active router is local
  Standby router is unknown
  Priority 90 (configured 90)

ホスト側では、この引き継ぎが「ホストが何もしないで済む」仕組みであることが確認できます。failover 後の HOST の ARP テーブルでは、10.1.1.254 が依然として仮想 MAC 00:00:0c:07:ac:01 に解決されています。failover 前 (§4) と同じ MAC です。HOST は ARP をやり直さず、これまでどおり仮想 MAC 宛にフレームを送るだけで、フレームは新しい Active である R2 に届きます。

snippet 
HOST:~$ arp -a
? (10.1.1.2) at 52:54:00:37:d4:08 [ether]  on eth0
? (10.1.1.254) at 00:00:0c:07:ac:01 [ether]  on eth0

ここに、仮想 MAC を使う意味が表れています。仮に新しい Active が自身の物理 MAC で応えるなら、ホストは古い MAC エントリが期限切れになるまで通信できません。FHRP は仮想 MAC を引き継ぐことで、ホスト側の ARP 再解決を待たずに通信を継続させます。HOST の ARP テーブルにある 10.1.1.2 (R2 の物理 MAC) と 10.1.1.254 (仮想 MAC) が別物である点も、仮想 MAC が物理 MAC と独立していることを示します。

R1 を復旧 (no shutdown) すると、preempt が有効なため R1 が Active に復帰します。R1 が priority 110 で再び Active、R2 が priority 90 で Standby に戻ります。

snippet 
R1#show standby brief
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Gi2         1    110 P Active  local           10.1.1.2        10.1.1.254
R2#show standby brief
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Gi2         1    90  P Standby 10.1.1.1        local           10.1.1.254

この preempt による自動復帰は、HSRP ではデフォルト無効で、本ラボのように standby 1 preempt を明示したときだけ働きます。preempt を設定しないと、R1 が復旧しても priority 90 の R2 が Active のまま留まります。preempt のデフォルト挙動の差は §10 で整理します。

HSRP failover のフロー (上段=前 / 下段=後)。前は R1 が Active で、HOST は仮想 MAC ...ac01 宛 = R1 経由で転送する。後は R1 が落ちて Hello が停止し Hold タイマーが失効すると、R2 が Active に昇格して同じ仮想 IP 10.1.1.254 / 仮想 MAC ...ac01 を引き継ぐ。HOST の ARP は仮想 MAC のまま不変なので、転送先が R2 に変わっても通信は途切れない

6. VRRP — Master / Backup と preempt デフォルトの差

VRRP は、RFC 5798 で標準化されたマルチベンダ対応の FHRP で、Master / Backup という用語で役割を決めるプロトコルです。役割は HSRP の Active / Standby に対応し、priority の高いルータが Master、低いルータが Backup になります。HSRP が Cisco 独自であるのに対し、VRRP は IETF 標準のため異なるベンダの機器間でも相互運用できます。

VRRP の選出結果は show vrrp brief で確認できます。R1 が Master、R2 が Backup になり、仮想 IP 10.1.1.253 を共有しています。Pre の列が Y で、preempt が有効であることを示します。

snippet 
R1#show vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Gi2                2   110 3570       Y  Master  10.1.1.1        10.1.1.253
R2#show vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Gi2                2   90  3648       Y  Backup  10.1.1.1        10.1.1.253

詳細表示の show vrrp では、仮想 MAC とタイマーが確認できます。VRRP の仮想 MAC は 0000.5e00.0102 で、末尾の 02 が VRID (Virtual Router ID = グループ番号 2) を 16 進で表したものです。HSRP とは全く異なる体系 (0000.5e00.01XX) を使います。タイマーは Advertisement interval が 1 秒で、HSRP の Hello 3 秒より短い間隔です。Master Down interval (Master がダウンと判断するまでの時間) は 3.570 秒で、これは Advertisement interval の 3 倍に skew time (priority に応じた微小な遅延) を加えた値です。

snippet 
show vrrp
GigabitEthernet2 - Group 2
  State is Master
  Virtual IP address is 10.1.1.253
  Virtual MAC address is 0000.5e00.0102
  Advertisement interval is 1.000 sec
  Preemption enabled
  Priority is 110
  Master Router is 10.1.1.1 (local), priority is 110
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.570 sec
  FLAGS: 1/1

ここで、本節の核心である preempt のデフォルト差が明確になります。§3 の running-config で見たとおり、VRRP の vrrp 2 には preempt 行が無いにもかかわらず、show vrrp は Preemption enabled と表示します。これは、VRRP では preempt がデフォルトで有効だからです。HSRP では preempt がデフォルト無効で standby 1 preempt の明示が必要だった (§5) のとは対照的です。

snippet 
show running-config interface GigabitEthernet2
...
 standby 1 ip 10.1.1.254
 standby 1 priority 110
 standby 1 preempt
 negotiation auto
 vrrp 2 ip 10.1.1.253
 vrrp 2 priority 110
...

VRRP の failover も HSRP と同じ流れで動きます。R1 (Master) を落とすと R2 が Master に昇格し、R1 を復旧すると preempt がデフォルト有効のため R1 が自動的に Master に復帰します。R2 が Master に昇格した状態と、R1 復旧後に Master が R1 に戻った状態が以下です。

snippet 
R2#show vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Gi2                2   90  3648       Y  Master  10.1.1.2        10.1.1.253
R1#show vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Gi2                2   110 3570       Y  Master  10.1.1.1        10.1.1.253

R1 を復旧させただけで、明示的な preempt 設定なしに Master が R1 に戻っている点が、VRRP のデフォルト有効の表れです。

7. HSRP と VRRP の比較 — 設定・表示・デフォルトの差

HSRP と VRRP は、デフォルトゲートウェイを冗長化するという役割は同じですが、標準化・用語・仮想 MAC 体系・タイマー・preempt デフォルト・グループ範囲がそれぞれ異なります。両者の show 出力を並べると、同じ目的のプロトコルが異なる語彙と既定値を持つことが分かります。R1 上で show standby brief と show vrrp brief を並べると、HSRP が Active / Standby、VRRP が Master / Backup という別の用語で同じ状態を表現していることが読み取れます。

snippet 
R1#show standby brief
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Gi2         1    110 P Active  local           10.1.1.2        10.1.1.254
R1#show vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Gi2                2   110 3570       Y  Master  10.1.1.1        10.1.1.253

実機で確定した両者の差を整理すると、以下のとおりです。いずれも本ラボの show standby / show vrrp / running-config で裏付けた値です。

観点HSRPVRRP
標準化Cisco 独自 (マルチベンダ非互換)RFC 5798 標準 (マルチベンダ相互運用)
用語 (主 / 副)Active / StandbyMaster / Backup
仮想 MACv1: 0000.0c07.ac01 (0000.0c07.acXX)v2: 0000.0c9f.f001 (0000.0c9f.fXXX)0000.5e00.0102 (0000.5e00.01XX)
既定タイマーHello 3 秒 / Hold 10 秒Advertisement 1 秒
preempt デフォルト無効 (明示 preempt が要る)有効 (自動で復帰)
グループ範囲v1: 0-255 / v2: 0-40951-255

仮想 MAC の体系がプロトコルごとに固有である点は、トラブルシューティングで役立ちます。スイッチの show mac address-table に現れた仮想 MAC の先頭部分を見れば、それが HSRP (0000.0c07 / 0000.0c9f) なのか VRRP (0000.5e00) なのかを即座に判別できます。

HSRP と VRRP の比較。役割は同じだが、標準化 (Cisco 独自 vs RFC 5798)・用語 (Active/Standby vs Master/Backup)・仮想 MAC 体系 (0000.0c07.acXX/0000.0c9f.fXXX vs 0000.5e00.01XX)・タイマー (Hello 3s/Hold 10s vs Advertisement 1s)・preempt デフォルト (HSRP 無効 / VRRP 有効)・グループ範囲が異なる。preempt の既定差は運用事故の元になる

最も注意すべき差が、preempt のデフォルトです。HSRP は preempt 無効がデフォルトのため、Active が落ちて Standby が昇格した後、元 Active が復旧しても Active に戻りません。VRRP はデフォルト有効のため自動で復帰します。同じ感覚で両者を運用すると「HSRP は戻らないのに VRRP は戻る」という挙動の違いに戸惑うため、この差は §10 で改めて整理します。

8. GLBP — 冗長化と負荷分散の両立

GLBP は、Cisco 独自の FHRP で、冗長化に加えて複数のルータへの負荷分散も同時に実現するプロトコルです。HSRP / VRRP では Active / Master の 1 台だけが転送を担当し、Standby / Backup は完全に待機するため、待機側のルータの転送能力は使われません。これに対し GLBP は、複数のルータを同時に転送に参加させることで、冗長化しながら帯域も有効活用します。

GLBP は 2 種類の役割を使います。AVG (Active Virtual Gateway) は、グループ内で 1 台だけ存在し、ARP 要求への応答を司ります。AVF (Active Virtual Forwarder) は、実際にフレームを転送するルータで、複数台が同時に Active になれます。AVG は AVF ごとに別々の仮想 MAC を割り当て、ホストからの ARP 要求に対して AVF の仮想 MAC をround-robin (順番) で配ることで、ホストごとに異なるルータへ転送を振り分けます。

GLBP の状態は show glbp brief / show glbp で確認できます。R1 が AVG (State is Active) であり、かつ Forwarder 1 (AVF1、MAC 0007.b400.0a01) を Active で担当しています。Forwarder ごとに別の仮想 MAC が割り当てられ、ロードバランシングのアルゴリズムは round-robin がデフォルトです。GLBP の仮想 MAC は 0007.b4xx.xxyy の体系で、xxxx が グループ ID の 16 進表現 (グループ 10 = 000a)、末尾の yy が Forwarder 番号です。本ラボのグループ 10・Forwarder 1 / 2 では 0007.b400.0a01 / 0007.b400.0a02 になります (グループ ID が 255 を超える構成では下位 1 バイトに収まらないため、GGFF という 1 バイト表記は厳密には正しくありません)。

snippet 
show glbp brief
Interface   Grp  Fwd Pri State    Address         Active router   Standby router
Gi2         10   -   110 Active   10.1.1.252      local           10.1.1.2
Gi2         10   1   -   Active   0007.b400.0a01  local           -
Gi2         10   2   -   Listen   0007.b400.0a02  10.1.1.2        -
R1#show glbp
GigabitEthernet2 - Group 10
  State is Active
  Virtual IP address is 10.1.1.252
  Hello time 3 sec, hold time 10 sec
  Redirect time 600 sec, forwarder time-out 14400 sec
  Preemption enabled, min delay 0 sec
  Active is local
  Standby is 10.1.1.2, priority 90 (expires in 8.544 sec)
  Priority 110 (configured)
  Weighting 100 (default 100), thresholds: lower 1, upper 100
  Load balancing: round-robin
  Group members:
    5254.0037.d408 (10.1.1.2)
    5254.00d9.3889 (10.1.1.1) local
  There are 2 forwarders (1 active)
  Forwarder 1
    State is Active
    MAC address is 0007.b400.0a01 (default)
    Owner ID is 5254.00d9.3889
  Forwarder 2
    State is Listen
    MAC address is 0007.b400.0a02 (learnt)
    Owner ID is 5254.0037.d408

R2 の視点を見ると、負荷分散の仕組みがさらに明確になります。R2 は AVG としては Standby (R1 が AVG) ですが、Forwarder 2 (AVF2、MAC 0007.b400.0a02) を Active で担当しています。つまり R1 と R2 は異なる仮想 MAC を持つ別々の AVF として、同時にフレーム転送に参加しています。これが GLBP の負荷分散の根幹です。

snippet 
R2#show glbp brief
Interface   Grp  Fwd Pri State    Address         Active router   Standby router
Gi2         10   -   90  Standby  10.1.1.252      10.1.1.1        local
Gi2         10   1   -   Listen   0007.b400.0a01  10.1.1.1        -
Gi2         10   2   -   Active   0007.b400.0a02  local           -

AVG が AVF の仮想 MAC を round-robin で配る結果、ホスト群はクライアントごとに別のルータをデフォルトゲートウェイの転送先として使い、転送が R1 / R2 に分散します。HSRP / VRRP では仮想 MAC が 1 つで、ARP 応答も常に Active / Master の MAC を返すため転送が 1 台に集中するのに対し、GLBP は AVF ごとに別の仮想 MAC を配ることで複数ルータに分散させます。

GLBP の負荷分散。AVG (= R1) が ARP 応答で AVF ごとの異なる仮想 MAC を round-robin で配る。あるホストには AVF1 (R1) の MAC 0007.b400.0a01、別のホストには AVF2 (R2) の MAC 0007.b400.0a02 を返すため、両ホストの転送が R1/R2 に分散する。HSRP/VRRP は仮想 MAC が 1 つで Active/Master 1 台に集中するのに対し、GLBP だけが冗長化と負荷分散を両立する

GLBP の failover では、片方のルータが落ちても残ったルータが両方の AVF を引き継ぎます。R1 を落とすと、R2 が AVG に昇格し、かつ Forwarder 1 (0007.b400.0a01) と Forwarder 2 (0007.b400.0a02) の両方を Active で担当します。There are 2 forwarders (2 active) の表示が、R2 が 2 つの仮想 MAC を 1 台で引き受けたことを示します。

snippet 
R2#show glbp brief
Interface   Grp  Fwd Pri State    Address         Active router   Standby router
Gi2         10   -   90  Active   10.1.1.252      local           unknown
Gi2         10   1   -   Active   0007.b400.0a01  local           -
Gi2         10   2   -   Active   0007.b400.0a02  local           -
R2#show glbp GigabitEthernet2 10
GigabitEthernet2 - Group 10
  State is Active
  ...
  Load balancing: round-robin
  There are 2 forwarders (2 active)
  Forwarder 1
    State is Active
    MAC address is 0007.b400.0a01 (learnt)
  Forwarder 2
    State is Active
    MAC address is 0007.b400.0a02 (default)

通常時は R1 / R2 で転送を分散し、片方が落ちれば残った 1 台がすべての仮想 MAC を引き受けることで、GLBP は負荷分散と冗長化を両立します。

round-robin の交互配布を AVG 側で確認する

ここまでは「2 つの AVF が別の仮想 MAC を Active で持つ」という構成を show glbp で示しました。では、AVG が ARP 要求に対して実際にその仮想 MAC を round-robin で交互に配っているのかを、もう一段深く確かめます。観測点は AVG (R1) 側に置きます。AVG で debug arp を有効にすると、AVG が受け取った ARP 要求 (rcvd req) と、それに対して返した ARP 応答 (sent rep) が 1 件ずつ記録されます。GLBP VIP 10.1.1.252 宛の ARP 要求に対して AVG がどの仮想 MAC を src に入れて応答したかを見れば、round-robin の交互配布が因果として読み取れます。

別の MAC を持つ 2 台のクライアント (HOST 10.1.1.10 / HOST2 10.1.1.20) から GLBP VIP に ARP を発生させ、AVG (R1) の debug arp を撮ったのが次の出力です。

snippet 
R1#debug arp
ARP packet debugging is on
*Jun 13 10:03:35.791: IP ARP: rcvd req src 10.1.1.10 5254.00c5.51a6, dst 10.1.1.252 GigabitEthernet2 tableid 0
*Jun 13 10:03:35.792: IP ARP: sent rep src 10.1.1.252 0007.b400.0a02,
                 dst 10.1.1.10 5254.00c5.51a6 GigabitEthernet2
*Jun 13 10:03:36.831: IP ARP: rcvd req src 10.1.1.10 5254.00c5.51a6, dst 10.1.1.252 GigabitEthernet2 tableid 0
*Jun 13 10:03:36.831: IP ARP: sent rep src 10.1.1.252 0007.b400.0a01,
                 dst 10.1.1.10 5254.00c5.51a6 GigabitEthernet2
*Jun 13 10:04:00.265: IP ARP: rcvd req src 10.1.1.20 5254.0077.87c2, dst 10.1.1.252 GigabitEthernet2 tableid 0
*Jun 13 10:04:00.265: IP ARP: sent rep src 10.1.1.252 0007.b400.0a02,
                 dst 10.1.1.20 5254.0077.87c2 GigabitEthernet2

GLBP VIP 10.1.1.252 宛の ARP 要求 (dst 10.1.1.252) に対して、AVG が応答に入れた仮想 MAC (sent rep src 10.1.1.252 の MAC) が、0007.b400.0a02 → 0007.b400.0a01 → 0007.b400.0a02 と要求のたびに切り替わっています。これが AVG が AVF の仮想 MAC を round-robin で順番に配っている因果そのものです。AVG は応答を返す側 (sent rep) なので、HOST 側のキャッシュ状態に依存せず、ルータ視点で交互配布を観察できます。

この交互配布の結果は、AVG 自身が持つカウンタにも現れます。show glbp の各 Forwarder には Client selection count という、その仮想 MAC を何件のクライアントに割り当てたかを数えるカウンタがあり、本ラボでは Forwarder 1 / Forwarder 2 がともに 4 で揃っていました。round-robin が両 AVF に均等にクライアントを振り分けていることを、AVG 側の数値で裏づけられます。

snippet 
R1#show glbp GigabitEthernet2 10
  ...
  Load balancing: round-robin
  Forwarder 1
    State is Active
    MAC address is 0007.b400.0a01 (default)
    Client selection count: 4
  Forwarder 2
    State is Listen
    MAC address is 0007.b400.0a02 (learnt)
    Client selection count: 4

最後に、配られた結果をクライアント側でも対照します。2 台のクライアントの ARP テーブルを見ると、HOST は GLBP VIP の MAC を 00:07:b4:00:0a:01 (AVF1) として、HOST2 は 00:07:b4:00:0a:02 (AVF2) として学習しており、別々の AVF の仮想 MAC が配られていることが確認できます。クライアントごとに異なる仮想 MAC を使う = フレームの転送先ルータが分散する、という負荷分散の効果が、AVG 側の応答ロジックとクライアント側の学習結果の両面で揃いました。

snippet 
HOST:~$ arp -a
? (10.1.1.252) at 00:07:b4:00:0a:01 [ether]  on eth0
HOST2:~$ arp -a
? (10.1.1.252) at 00:07:b4:00:0a:02 [ether]  on eth0

なお、単一のクライアントが ARP キャッシュをクリアして繰り返し ARP し、自分だけで交互配布を観察しようとすると、本ラボの非特権ホストでは制約があります。その点は §10 で正直に記録します。

9. 3 プロトコルの使い分け

3 プロトコルは役割が重なる一方で、標準化の有無と負荷分散の可否によって選択基準が分かれます。HSRP と GLBP は Cisco 独自で、VRRP は RFC 5798 の業界標準です。単一の仮想 IP / 単一グループで自動的に複数ルータへ負荷分散できるのは GLBP だけで、HSRP / VRRP は 1 グループでは Active / Master 1 台に転送が集中します (HSRP / VRRP も複数グループ・複数仮想ルータを作り、ホストや VLAN ごとに異なるデフォルトゲートウェイを使い分ければロードシェアは可能ですが、ホスト側の GW 設定の振り分けが必要です)。

選択の目安を整理すると、以下のとおりです。

プロトコル標準化負荷分散主な選択基準
HSRPCisco 独自なしCisco 機器で統一された環境。実績と運用ノウハウが豊富
VRRPRFC 5798 標準なしマルチベンダ環境。異なるベンダの機器間で冗長構成を組む
GLBPCisco 独自あり待機側ルータの帯域も使いたい。複数ルータで転送を分散したい

機器がすべて Cisco で統一されているなら、実績の豊富な HSRP が選ばれることが多くあります。異なるベンダの機器を混在させる環境では、標準の VRRP が相互運用性の点で適します。待機側ルータを遊ばせず帯域を有効活用したいなら、負荷分散ができる GLBP が候補になります。どのプロトコルでも、ホストから見れば「1 つの落ちない仮想ゲートウェイ」を提供する点は共通で、違いは「標準か独自か」「待機側を使うか使わないか」に集約されます。

10. 落とし穴・補足

本節で押さえておきたい論点と、教科書 / Web 解説の記述との差を 5 件まとめます。3-3〜3-11 と同じ「正直記録」枠で、Cisco IOS-XE 17.x (csr1000v) の実装の振る舞いを優先します。

落とし穴 1: preempt のデフォルト差が復帰挙動を分ける

HSRP は preempt がデフォルト無効、VRRP はデフォルト有効です。この差は、Active / Master が落ちて昇格が起きた後の「元の主役の復帰」で表面化します。HSRP では standby preempt を明示しないと、高 priority のルータが復旧しても、昇格した低 priority のルータが主役のまま留まります。一方 VRRP は preempt 行が無くても自動で復帰します (§5・§6 で実機確認)。

この差を見落とすと、「HSRP で組んだら復旧後も Active が戻らない」「VRRP に切り替えたら戻るようになった」という挙動の違いに混乱します。HSRP / VRRP を混在運用する環境では、両者で復帰挙動が逆になる前提を持つ必要があります。HSRP で復帰させたいなら standby <grp> preempt を必ず明示し、VRRP で意図的に復帰させたくないなら vrrp <grp> preempt を no で無効化します。

落とし穴 2: 仮想 MAC の体系がプロトコルごとに全く違う

仮想 MAC の先頭部分は、プロトコルと version を識別する手がかりになります。HSRP version 1 は 0000.0c07.acXX、HSRP version 2 は 0000.0c9f.fXXX、VRRP は 0000.5e00.01XX、GLBP は 0007.b4xx.xxyy (xxxx = グループ ID、yy = Forwarder 番号) です。トラブル時にスイッチの show mac address-table で仮想 MAC を見れば、それがどの FHRP に由来するかを即座に判別できます。

本ラボでは、HSRP grp1 が v1 で 0000.0c07.ac01・v2 で 0000.0c9f.f001、VRRP grp2 が 0000.5e00.0102、GLBP grp10 が 0007.b400.0a01 / 0007.b400.0a02 でした。末尾のグループ番号 / VRID / Forwarder 番号は 16 進で表記されるため、グループ 10 が末尾 0a になる点 (10 = 16 進 0a) は注意が必要です。10 進のグループ番号と 16 進の仮想 MAC を混同しないようにします。

落とし穴 3: GLBP だけが負荷分散できる理由

HSRP / VRRP と GLBP の本質的な違いは、1 グループあたりの仮想 MAC の個数にあります。HSRP / VRRP は 1 グループの仮想 MAC が 1 つで、ARP 応答も常に Active / Master の MAC を返すため、そのグループでは全ホストのフレームが 1 台に集中します。Standby / Backup は完全に待機し、転送には参加しません (複数グループを作って GW を振り分ければ HSRP / VRRP でもロードシェアできますが、それはホスト側の設定で実現する話で、1 グループ内での自動分散ではありません)。これに対し GLBP は、AVF ごとに別の仮想 MAC を持ち、AVG が ARP 応答を round-robin で配ることで、単一グループ内でホストごとに異なるルータへ転送を振り分けます (§8)。

ここで「冗長化」と「負荷分散」は別概念であることを押さえておきます。HSRP / VRRP も冗長化はできますが、負荷分散はできません。GLBP は冗長化に負荷分散を加えたプロトコルです。ただし、待機側ルータも転送に使う分、構成と挙動は HSRP / VRRP より複雑になります。単純な冗長化で十分なら HSRP / VRRP、帯域も活用したいなら GLBP という使い分けになります。

落とし穴 4: round-robin の交互配布は AVG 側 debug で観察し、単一の非特権ホストの再 ARP には制約がある

GLBP の round-robin 負荷分散は、§8 で示したとおり AVG 側の debug arp で交互配布の因果を観察できます。GLBP VIP 宛の ARP 要求に対して AVG が応答に入れる仮想 MAC が 0007.b400.0a02 → 0007.b400.0a01 → … と要求のたびに切り替わり、show glbp の Client selection count が両 AVF で揃う事実が主たる証跡です。AVG は応答を返す側なので、観測点を AVG に置けばクライアント側のキャッシュ状態に依存せず交互配布を撮れます。

一方で、単一のホストが自分だけで「ARP のたびに 0a01 / 0a02 が交互に返る」のを観察するのは、本ラボの環境では制約がありました。それを見せるにはホストが ARP キャッシュをクリアして繰り返し ARP し直す必要がありますが、本ラボの HOST は非特権ユーザーで動作する alpine Linux だったため、ARP キャッシュをクリアする ip neigh flush all が Operation not permitted で拒否され、2 つ目の送信元アドレスを追加する ip addr add も失敗しました。結果として、単一ホストはキャッシュをクリアできず、最初に学習した仮想 MAC を使い続けます。

snippet 
HOST:~$ ip neigh flush all
...
ip: can't send flush request: Operation not permitted
HOST:~$ ip addr add 10.1.1.11/24 dev eth0
ip: RTNETLINK answers: Operation not permitted

この制約は GLBP 側の問題ではなく、ホスト OS の権限の問題です。round-robin の本質である「クライアントごとに別の AVF 仮想 MAC を配る」という挙動は、§8 のとおり別の MAC を持つ 2 台のクライアント (HOST / HOST2) がそれぞれ 0007.b400.0a01 / 0007.b400.0a02 を学習することで対照できました。交互配布の因果は AVG 側の debug で、その結果は複数クライアントの ARP テーブルで観察するのが、本ラボ環境での確実な見せ方です。単一の非特権ホストの再 ARP に頼ると、権限制約で観察できないことに注意します。

落とし穴 5: csr1000v IOS-XE で GLBP は完全動作した

GLBP は一部の仮想プラットフォームで制限されることがあると見聞きする場合がありますが、本ラボの CML2.9 csr1000v (IOS-XE 17.x) では GLBP は完全に動作しました。glbp コマンドが投入でき、show glbp が AVG / AVF の状態・複数の仮想 MAC・Load balancing: round-robin・failover での AVF 引き継ぎまで、すべて教科書どおりに表示されました。HSRP / VRRP / GLBP の 3 プロトコルを同一インタフェースに同時設定しても衝突は起きませんでした。

このように、本節の実機検証では HSRP / VRRP / GLBP のいずれも IOS-XE 17.x で期待どおりに動作しました。プラットフォームによる GLBP の可否はバージョンやイメージに依存するため、教科書の一般論を鵜呑みにせず、使用する実機で show glbp の挙動を確認するのが確実です。

11. 次節

3-1 から本節 3-12 まで、第 3 章 L3 編では IP ルーティングの基礎 (3-1〜3-2)、距離ベクトル型とリンクステート型の IGP (3-3 RIP / 3-4 EIGRP / 3-5 OSPF)、パスベクトル型の BGP とその応用 (3-6〜3-9)、プロトコル間の再配送 (3-10)、ルーティングポリシー総括 (3-11)、そして本節のデフォルトゲートウェイ冗長化を扱いました。本節では、FHRP で単一障害点を解消する仕組みを、HSRP / VRRP / GLBP の 3 プロトコルを同時設定して比較し、仮想 MAC 体系・preempt のデフォルト差・GLBP だけが負荷分散できる理由を実機の show 出力で裏付けました。

次節 3-13 からは、ここまでの IPv4 を前提とした世界から視点を移し、IPv6 を扱います。IPv6 は範囲が広いため 3 節に分けます。3-13 IPv6 アドレス体系 でアドレスの表記・種別・プレフィックスと複数アドレスを、3-14 で NDP (Neighbor Discovery Protocol) と SLAAC (StateLess Address AutoConfiguration) を、3-15 で OSPFv3 / MP-BGP (Multiprotocol BGP) による IPv6 ルーティングを扱います。その後、3-16 以降でマルチキャストルーティング (PIM-SM / RP / IGMP) を扱い、第 3 章 L3 編を締めくくります。まずは IPv6 のアドレス体系から見ていきましょう。

次節