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

3-17 PIM-SM — RP・register・SPT 切替

実際の配信ツリーを張る PIM-SM を扱う。FHR が送信元を RP に登録する register、RP を根とする共有ツリー RPT、送信元への近道 SPT への切替を、RP 独立構成の CML2.9 IOS-XE 17.x で実機検証する。

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

前節 3-16 では、マルチキャストの土台となる 4 つの要素を扱いました。クラス D のグループアドレスと 01:00:5e から始まる MAC マッピング、ホストがグループ参加を伝える IGMP (Internet Group Management Protocol)、ループ防止の根幹となる RPF (Reverse Path Forwarding) チェック、そして共有ツリー (*,G) と送信元ツリー (S,G) という配信ツリーの考え方です。受信者が join すると (*,G) が、送信元が実際に送ると (S,G) が現れる、という mroute エントリの出現タイミングの差も実機で確認しました。

3-16 の検証では、RP (Rendezvous Point) と分岐ルータを同一のルータが兼ねていたため、(*,G) の Incoming interface が Null になり、共有ツリーから送信元ツリーへの切替が観察できませんでした。3-16 §10 では、この続きとして「RP が果たす役割、送信元が RP へ自分を登録する register プロセス、共有ツリー (RPT) から送信元ツリー (SPT) へ切り替わる SPT 切替を次節 3-17 で実機検証する」と予告しています。本節はこの予告を回収する節です。

本節 3-17 では、配信ツリーを実際にどう張るかを担う PIM-SM (Protocol Independent Multicast - Sparse Mode) の中身に踏み込みます。RP を独立したノードにした構成へ組み替え、(a) 送信元側 DR (Designated Router) が送信元を RP に登録する register プロセス、(b) RP を根とする遠回りの共有ツリー RPT (Rendezvous Point Tree)、(c) 送信元への近道である SPT (Shortest Path Tree) への切替を、CML2.9 の csr1000v IOS-XE 17.x で順に検証します。3-16 で扱った IGMP・RPF・(*,G)/(S,G) の読み方は前提とし、本節は RP register と RPT→SPT 切替という動的プロセスに徹します。

2. PIM-SM とは — 配信ツリーを張るプロトコル

PIM (Protocol Independent Multicast) は、マルチキャストの配信ツリーを張るためのプロトコルです。名前の Protocol Independent (プロトコル非依存) が示すとおり、PIM 自身は経路計算を行いません。配信ツリーをどの IF で受け、どの IF へ複製するかを決める際、PIM は ユニキャストの経路表 (RIB) を流用します。3-16 で扱った RPF チェックが show ip route のユニキャスト経路を参照していたのと同じ考え方で、PIM は OSPF / EIGRP / BGP など下位のユニキャストプロトコルが何であっても、その結果だけを使います。

PIM-SM (Sparse Mode) は、配信ツリーの張り方が 「必要な人がいる枝だけ張る」 方式である点が特徴です。受信者が join したセグメントに向けてだけ配信ツリーを伸ばし、受信者がいない枝にはトラフィックを流しません。これに対し、次節 3-18 で扱う PIM-DM (Dense Mode) は「いったん全方向へ流してから不要な枝を刈り取る (flood & prune)」方式で、両者は配信ツリーの作り方が対照的です。受信者がまばら (sparse) に分布する広域ネットワークでは、無駄なトラフィックを最初から流さない PIM-SM が標準的に使われます。

PIM-SM の配信ツリーには、3-16 で扱った 2 種類があります。受信者の希望を集約する RP を根とする共有ツリー (RPT) と、送信元を根とする 最短パスツリー (SPT) です。PIM-SM は最初に RPT で配信を開始し、その後 SPT へ切り替えるという 2 段階の動きをします。この切替こそが本節の核心です。

本節の検証ラボは、RPT (遠回り) と SPT (近道) が別々の IF を通る構成にします。トポロジは以下のとおりです。

送信元 R-SRC が 239.10.10.10 へ送るパケットを、送信元側 DR の R-FHR が register で独立 RP の R-RP (Lo0 = 10.0.100.5) に登録する。受信側 DR の R-LHR は Loopback1 に ip igmp join-group 239.10.10.10 を設定して受信者になる。配信は最初 R-FHR→R-RP→R-LHR の RP 経由 (青、遠回り) で始まり、SPT 切替後は R-FHR→R-LHR の直結 (橙、近道) へ移る。全リンクで OSPF area 0 と PIM sparse-mode を有効化し、静的 RP に 10.0.100.5 を指定する

各ルータの役割は以下のとおりです。

  • R-SRC — 送信元。ping 239.10.10.10 source GigabitEthernet2 でマルチキャストトラフィックを生成します (送信元アドレス = 10.0.1.1)。
  • R-FHR — 送信元側 DR (FHR = First-Hop Router)。R-SRC からのトラフィックを受け、register で RP へ登録します。R-RP (RPT 方向、Gi3) と R-LHR (SPT 直結方向、Gi4) の両方に接続します。
  • R-RP — 独立した RP (Lo0 = 10.0.100.5 を RP アドレスに)。3-16 と違い、分岐点でも送信元側でもない純粋な RP です。
  • R-LHR — 受信側 DR (LHR = Last-Hop Router)。Loopback1 (10.0.40.4) に ip igmp join-group 239.10.10.10 を設定して受信者を作り、SPT 切替を判断します。

3-16 のグループ 239.1.1.1 と区別するため、本節は 239.10.10.10 を使います。

3. DR (Designated Router) — FHR と LHR の役割分担

PIM-SM では、ルータ同士が PIM Hello を 30 秒間隔で交換し、マルチキャストが流れる各セグメントで 1 台の DR (Designated Router) を選出します。DR の選出はデフォルトでは PIM の DR priority (既定 1) が同値なら 最も大きい IP アドレスを持つルータが選ばれ、ip pim dr-priority でも調整できます。DR は、そのセグメント上で送信元の登録や受信者からの join 送出を代表して担う役です。

DR は接続する位置によって 2 つの役割に分かれます。送信元に最も近い DR を FHR (First-Hop Router)、受信者に最も近い DR を LHR (Last-Hop Router) と呼びます。FHR は送信元が出したトラフィックを最初に受け、RP へ register する役を担います。LHR は受信者の IGMP join を受け取り、RP へ向けて (*,G) Join を送り、後述する SPT 切替を判断する役を担います。同じ DR でも、トポロジ上のどこに位置するかで担当する仕事が変わります。

送信元側の DR である R-FHR (FHR) は送信元を RP に register する役、受信者側の DR である R-LHR (LHR) は受信者の IGMP join を受けて RP へ (*,G) Join を送り SPT 切替を判断する役。同じ DR でも送信元寄りか受信者寄りかで担当が分かれる。DR はデフォルトで最も大きい IP アドレスを持つルータが選ばれる

実機の show ip pim neighbor と show ip pim interface で、PIM 隣接と各 IF の DR を確認します。R-FHR の出力は以下のとおりです。

snippet 
show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
      L - DR Load-balancing Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
10.0.1.1          GigabitEthernet2         00:21:25/00:01:34 v2    1 / S P G
10.0.15.5         GigabitEthernet3         00:21:18/00:01:39 v2    1 / DR S P G
10.0.45.4         GigabitEthernet4         00:21:10/00:01:44 v2    1 / DR S P G
R-FHR#show ip pim interface

Address          Interface                Ver/   Nbr    Query  DR         DR
                                          Mode   Count  Intvl  Prior
10.0.0.2         Loopback0                v2/S   0      30     1          10.0.0.2
10.0.1.2         GigabitEthernet2         v2/S   1      30     1          10.0.1.2
10.0.15.2        GigabitEthernet3         v2/S   1      30     1          10.0.15.5
10.0.45.2        GigabitEthernet4         v2/S   1      30     1          10.0.45.4

show ip pim interface の DR 欄を見ると、R-FHR–R-SRC セグメント (Gi2) では DR が 10.0.1.2 = R-FHR 自身になっており、R-FHR が送信元 LAN の DR (= FHR) であることが分かります。Ver/Mode 列の v2/S は PIM version 2 の sparse mode、Query Intvl の 30 は Hello/Query 間隔です。同様に R-LHR では受信者 LAN (Loopback1、10.0.40.4) の DR が R-LHR 自身になり、LHR の役を担います。

静的 RP は全ルータに同じ ip pim rp-address 10.0.100.5 を設定して教えます。R-FHR の show ip pim rp mapping は以下のとおりで、グループ範囲 224.0.0.0/4 全体が静的に RP 10.0.100.5 へマップされています。

snippet 
R-FHR#show ip pim rp mapping
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
    RP: 10.0.100.5 (?)

Static は手動設定であること、(?) は RP のホスト名が DNS 解決されていないことを表します。この同じ 1 行が全 4 ルータに設定されており、それが静的 RP の限界 (§8) につながります。

4. register プロセス — 送信元を RP に登録する

PIM-SM では、送信元が出したマルチキャストトラフィックを RP へ伝える最初の手段が register プロセスです。送信元が最初のパケットを送ると、送信元側 DR (FHR) はそのパケットを PIM Register メッセージにユニキャストでカプセル化し、RP へ届けます。RP はそれをデカプセル化して共有ツリーへ流し、送信元の存在を知ります。RP が送信元方向へ向けて直接 (S,G) Join を送り、SPT が確立すると、register でのカプセル化は不要になるため、RP は Register-Stop を FHR へ返して register を止めます。

① R-SRC が 239.10.10.10 へ最初のパケットを送る。② R-FHR (送信元側 DR) がそれを PIM Register でユニキャストカプセル化し、RP の Tunnel0 へ送る。③ R-RP がデカプセル化して共有ツリーへ流し、送信元方向へ (S,G) Join を送って SPT を張る。④ SPT が確立すると RP は Register-Stop を R-FHR へ返し、R-FHR は Registering flag をクリアして register を止める

RP は register を受けてデカプセル化するための Tunnel0 を持ちます。R-RP の show interfaces Tunnel0 で、この register tunnel の存在を確認できます。

snippet 
R-RP#show interfaces Tunnel0
Tunnel0 is up, line protocol is up 
  Hardware is Tunnel
  Description: Pim Register Tunnel (Encap) for RP 10.0.100.5
  Interface is unnumbered. Using address of Loopback0 (10.0.100.5)
  MTU 9972 bytes, BW 100 Kbit/sec, DLY 50000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
...
  Tunnel source 10.0.100.5 (Loopback0), destination 10.0.100.5
...
  Tunnel protocol/transport PIM/IPv4

Description: Pim Register Tunnel (Encap) for RP 10.0.100.5 が register 専用のトンネルであること、Tunnel protocol/transport PIM/IPv4 が PIM の register カプセル化に使われることを示しています。3-16 では RP が分岐点を兼ねていたため (*,G) の Incoming が Null でしたが、独立した RP ではこの register tunnel が現れる点が異なります。

register の一連の動きは、R-FHR で debug ip pim を仕掛けてから R-SRC が ping を送ることで捕捉できます。

snippet 
*Jun  7 02:35:03.734: PIM(0): Adding register encap tunnel (Tunnel0) as forwarding interface of (10.0.1.1, 239.10.10.10).
*Jun  7 02:35:03.765: PIM(0):  Adding v2 (10.0.1.1/32, 239.10.10.10), S-bit Join
*Jun  7 02:35:03.765: PIM(0): Send v2 join/prune to 10.0.1.1 (GigabitEthernet2)
*Jun  7 02:35:13.728: PIM(0): Received v2 Register-Stop on GigabitEthernet3 from 10.0.100.5
*Jun  7 02:35:13.729: PIM(0):   for source 10.0.1.1, group 239.10.10.10
*Jun  7 02:35:13.729: PIM(0): Removing register encap tunnel (Tunnel0) as forwarding interface of (10.0.1.1, 239.10.10.10).
*Jun  7 02:35:13.729: PIM(0): Clear Registering flag to 10.0.100.5 for (10.0.1.1/32, 239.10.10.10)

Adding register encap tunnel (Tunnel0) で R-FHR が register カプセル化を開始し、約 10 秒後に RP (10.0.100.5) から Received v2 Register-Stop を受けています。その直後に Removing register encap tunnel と Clear Registering flag で register を止めています。register でカプセル化していた間に、送信元方向への (S,G) Join (Adding v2 (10.0.1.1/32, 239.10.10.10), S-bit Join / Send v2 join/prune to 10.0.1.1) が並行して送られ、SPT が張られています。SPT が完成したので、もはやユニキャストカプセル化での中継 (register) は不要になり、Register-Stop に至るという因果です。

register 直後の R-FHR の (S,G) は、送信元方向 (Gi2) から受け、F (Register flag) と T (SPT-bit set) のフラグが付きます。

snippet 
R-FHR#show ip mroute 239.10.10.10
...
(*, 239.10.10.10), 00:01:03/stopped, RP 10.0.100.5, flags: SPF
  Incoming interface: GigabitEthernet3, RPF nbr 10.0.15.5
  Outgoing interface list: Null

(10.0.1.1, 239.10.10.10), 00:01:03/00:02:36, flags: FT
  Incoming interface: GigabitEthernet2, RPF nbr 10.0.1.1
  Outgoing interface list:
    GigabitEthernet4, Forward/Sparse, 00:01:03/00:03:26

(S,G) (10.0.1.1, 239.10.10.10) の flags: FT のうち、F は register を担っていること、T は送信元ツリー (SPT) で配信中であることを示します。Incoming interface = Gi2 は送信元 R-SRC の方向です。送信元アドレスが 10.0.1.1 なのは R-SRC が source GigabitEthernet2 (= 10.0.1.1) で送ったためで、3-16 で扱った「(S,G) の S には送出 IF のアドレスが入る」という性質どおりです。

5. 共有ツリー (RPT) — RP を根とする遠回りの配信

PIM-SM の配信は、まず RP を根とする共有ツリー (RPT) で始まります。受信者側の LHR は IGMP join を受けると、RP へ向けて (*,G) Join を送り、RP を頂点とする配信ツリーを張ります。送信元のトラフィックは register を経て RP まで届き、RP から RPT に沿って受信者へ配られます。このとき、配信経路は必ず RP を経由するため、トポロジによっては送信元から受信者への最短経路より遠回りになります。

本節のラボは、この「遠回り」を観察できるよう、RP 経由 (R-LHR→R-RP→R-FHR→R-SRC) と送信元への直結 (R-LHR→R-FHR→R-SRC) が別の IF を通る構成にしています。SPT 切替がデフォルトでは即時に起きてしまうため (§6)、RPT の状態を意図的に固定するには R-LHR に ip pim spt-threshold infinity を設定します。

snippet 
R-LHR(config)#ip pim spt-threshold infinity
R-LHR(config)#end
R-LHR#clear ip mroute *
R-LHR#show running-config | include spt-threshold
ip pim spt-threshold infinity

この状態で R-SRC が ping を送ると、R-LHR の mroute は共有ツリー (*,G) だけになります。

R-LHR (LHR) が RP へ (*,G) Join を送り、RP を根とする共有ツリー RPT が張られる。送信元 R-SRC のトラフィックは register で RP まで届き、RP から R-LHR へ配られるため、R-SRC→R-FHR→R-RP→R-LHR と RP を経由する遠回りになる。R-LHR の mroute は (*, 239.10.10.10) の Incoming が Gi3 (RP 方向) で、(S,G) はまだ無い
snippet 
R-LHR#show ip mroute 239.10.10.10
...
(*, 239.10.10.10), 00:01:56/00:02:38, RP 10.0.100.5, flags: SCL
  Incoming interface: GigabitEthernet3, RPF nbr 10.0.35.5
  Outgoing interface list:
    Loopback1, Forward/Sparse, 00:01:56/00:02:38

(*,G) (*, 239.10.10.10) の flags: SCL は S=Sparse、C=Connected (直結メンバあり)、L=Local (ルータ自身が join-group でメンバ) を表し、T (SPT-bit) も J (Join SPT) もありません。Incoming interface が Gi3 (RP 10.0.35.5 方向) になっており、RP を経由して配信を受けている状態です。OIL は受信者である Loopback1 です。

この Incoming = Gi3 (RP 方向) が SPT 切替後に変わる、という理解の土台が RP への RPF と送信元方向への RPF が別 IF になる点です。R-LHR で show ip rpf を RP と送信元方向の双方に対して実行すると、別 IF が返ります。なお実際の (S,G) の送信元は §3・§4 のとおり R-SRC Gi2 の 10.0.1.1 で、PIM-SM の (S,G) Join / RPF は本来この 10.0.1.1 に対して評価されます。以下の show ip rpf では R-FHR 方向 (Gi4) が RP 方向 (Gi3) と別 IF になることを示すため 10.0.0.1 を引いていますが、これは「R-FHR / 送信元側ネットワーク方向」と「RP 方向」が別 IF であることの確認であり、本来の RPF 検算対象は 10.0.1.1 である点を補足します。

snippet 
R-LHR#show ip rpf 10.0.0.1
RPF information for ? (10.0.0.1)
  RPF interface: GigabitEthernet4
  RPF neighbor: ? (10.0.45.2)
  RPF route/mask: 10.0.0.1/32
  RPF type: unicast (ospf 1)
...
R-LHR#show ip rpf 10.0.100.5
RPF information for ? (10.0.100.5)
  RPF interface: GigabitEthernet3
  RPF neighbor: ? (10.0.35.5)
  RPF route/mask: 10.0.100.5/32
  RPF type: unicast (ospf 1)
...
R-LHR#show ip route 10.0.0.1
Routing entry for 10.0.0.1/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  * 10.0.45.2, from 10.0.0.1, 00:26:36 ago, via GigabitEthernet4
R-LHR#show ip route 10.0.100.5
Routing entry for 10.0.100.5/32
  Known via "ospf 1", distance 110, metric 2, type intra area
  * 10.0.35.5, from 10.0.100.5, 00:12:14 ago, via GigabitEthernet3

送信元側ネットワーク方向 (10.0.0.1) への RPF interface は Gi4 (R-FHR 直結方向)、RP 10.0.100.5 への RPF interface は Gi3 (R-RP 直結方向) で、別の IF です (実際の (S,G) 送信元 10.0.1.1 も R-FHR を経由するため、RPF interface は同じく Gi4 方向になります)。背後のユニキャスト経路 (show ip route) を見ると、RP へは [110/2] via Gi3、送信元方向へは [110/3] via Gi4 で、OSPF metric は RP が 2、送信元方向が 3 です。GigE の OSPF コストは 1 なので、RP へは「R-LHR–R-RP 直結リンク 1 + R-RP の Lo0 1 = 2」、送信元方向へは「R-LHR–R-FHR 直結リンク 1 + R-FHR 中継 1 + Lo0 1 = 3」と検算と一致します。RPT は RP 方向 (Gi3) を入口にし、SPT は送信元方向 (Gi4) を入口にする、という別 IF の土台がここにあります。

RPT でも配信自体は成立します。R-SRC の ping 239.10.10.10 には、受信者である R-LHR の Loopback1 (10.0.40.4) から全て応答が返ります。

snippet 
R-SRC#ping 239.10.10.10 source GigabitEthernet2 repeat 20
Sending 20, 100-byte ICMP Echos to 239.10.10.10, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1 

Reply to request 0 from 10.0.40.4, 38 ms
Reply to request 1 from 10.0.40.4, 9 ms
...
Reply to request 19 from 10.0.40.4, 3 ms

RP 経由の遠回りでも、受信者まで確かに届いています。

6. SPT 切替 — 送信元への近道に切り替える

RPT は必ず RP を経由するため、送信元から受信者への最短経路より遠回りになりがちです。そこで PIM-SM は、受信側 DR (LHR) が送信元 (S,G) を学習すると、RP 経由をやめて送信元へ向かう最短パスツリー (SPT) へ切り替えます。これを SPT 切替 (SPT switchover) と呼びます。LHR が送信元方向へ向けて (S,G) Join を送り、送信元への直結パスに新しい配信ツリーを張り、RPT 経由のトラフィックを止めます。本節の核心がこの切替です。

ここで重要なのが切替の閾値です。多くの教科書は「一定の閾値を超えたら SPT へ切り替わる」と説明しますが、Cisco IOS-XE のデフォルト閾値は 0 で、最初のパケットを受け取った時点で即時に SPT へ切り替わります。閾値を超えるまで RPT に留まる、という挙動は標準では起きません。RPT の状態を観察するには、§5 のように ip pim spt-threshold infinity を明示設定して切替を抑止する必要があります。本ラボはこの設定を入れて RPT を観察し (§5)、設定を外して SPT 切替を起こす (本節)、という 2 段で切替前後を対比します。

設定を外してデフォルト (閾値 0) に戻し、mroute を再学習させます。

snippet 
R-LHR(config)#no ip pim spt-threshold infinity
R-LHR(config)#end
R-LHR#clear ip mroute *
R-LHR#show running-config | include spt-threshold
R-LHR#

show running-config | include spt-threshold が空行を返し、infinity 設定が消えてデフォルト (閾値 0) に戻ったことを示します。この状態で R-SRC が再び ping を送ると、SPT 切替が起きます。

RP 経由の RPT で配信中の状態から、R-LHR (LHR) が送信元 (S,G) を学習して SPT 切替を決断。R-LHR が送信元方向 (Gi4 = R-FHR 直結) へ (S,G) Join を送り、配信パスが R-SRC→R-FHR→R-RP→R-LHR の遠回りから R-SRC→R-FHR→R-LHR の近道に切り替わる。R-LHR の mroute に新規 (S,G) が出現し、その Incoming が Gi3 (RP 方向) から Gi4 (送信元方向) へ変わり T (SPT-bit) フラグが付く

切替後の R-LHR の mroute は以下のとおりです。§5 の RPT 状態と並べると違いが明確になります。

snippet 
R-LHR#show ip mroute 239.10.10.10
...
(*, 239.10.10.10), 00:02:28/stopped, RP 10.0.100.5, flags: SJCL
  Incoming interface: GigabitEthernet3, RPF nbr 10.0.35.5
  Outgoing interface list:
    Loopback1, Forward/Sparse, 00:02:28/00:02:38

(10.0.1.1, 239.10.10.10), 00:02:10/00:00:49, flags: LJT
  Incoming interface: GigabitEthernet4, RPF nbr 10.0.45.2
  Outgoing interface list:
    Loopback1, Forward/Sparse, 00:02:10/00:02:38

変化は 2 点です。第 1 に、(*,G) のフラグが §5 の SCL から SJCL になり、J (Join SPT) が加わりました。これは LHR が SPT への切替を決めたことを示します。第 2 に、新規の (S,G) (10.0.1.1, 239.10.10.10) が flags: LJT で出現し、その Incoming interface が Gi4 (送信元 = R-FHR 直結方向、RPF nbr 10.0.45.2) になっています。L は Local、J は Join SPT、T は SPT-bit set です。

§5 の RPT 状態では (*,G) のみで Incoming = Gi3 (RP 方向) でしたが、SPT 切替後は (S,G) が現れ、その Incoming が Gi4 (送信元方向) に変わりました。Incoming interface が RP 方向 (Gi3) から送信元方向 (Gi4) へ移ったことが、RPT から SPT への切替を実機で示す決定的な証跡です。配信は RP を経由する遠回りから、R-FHR を介する近道へ移りました。

7. SPT 切替後の各ルータ — RP の役割の縮退

SPT が確立すると、配信は FHR から LHR へ直結で流れ、RP を経由する必要がなくなります。この結果、各ルータの mroute は三者三様の状態に落ち着きます。

受信側 DR の R-LHR は、§6 で見たとおり (S,G) の Incoming = Gi4 (送信元方向)、OIL = Loopback1 で受信者へ配ります。送信元側 DR の R-FHR は、(S,G) の Incoming = Gi2 (送信元 R-SRC 方向)、OIL = Gi4 (R-LHR 直結) で、RP を経由せず LHR へ直接配信します。

snippet 
R-FHR#show ip mroute 239.10.10.10
...
(10.0.1.1, 239.10.10.10), 00:07:41/00:02:58, flags: FT
  Incoming interface: GigabitEthernet2, RPF nbr 10.0.1.1
  Outgoing interface list:
    GigabitEthernet4, Forward/Sparse, 00:02:31/00:02:56

R-FHR の (S,G) は flags: FT、OIL = Gi4 (R-LHR 直結) で、RP 方向 (Gi3) ではなく LHR へ最短パスで配っています。

一方、RP である R-RP は役割が縮退します。SPT が完成すると RP 経由のトラフィックは不要になるため、RP は (S,G) を Prune して RP 経由の配信を止めます。

snippet 
R-RP#show ip mroute 239.10.10.10
...
(*, 239.10.10.10), 00:14:49/00:02:47, RP 10.0.100.5, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet3, Forward/Sparse, 00:14:49/00:02:47

(10.0.1.1, 239.10.10.10), 00:07:49/00:02:15, flags: PT
  Incoming interface: GigabitEthernet2, RPF nbr 10.0.15.2
  Outgoing interface list: Null

R-RP の (S,G) は flags: PT (P = Pruned)、OIL = Null で、RP 経由のトラフィックが止まっていることを示します。この縮退はパケットカウンタにも表れます。

snippet 
R-RP#show ip mroute 239.10.10.10 count
...
Group: 239.10.10.10, Source count: 1, Packets forwarded: 22, Packets received: 24
  RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
  Source: 10.0.1.1/32, Forwarding: 21/0/114/0, Other: 23/1/1

この出力で RP-tree: 行は (*,G) 共有ツリー、Source: 行は RP 自身が持つ個別 (S,G) state のカウンタです。RP-tree の Forwarding が 1 まで減っていることから、RP 経由の共有ツリー配信が縮退したことが読み取れます。ただし Source: 行の数字は RP 上の (S,G) state のカウンタであって、RP を迂回する FHR→LHR の SPT 直結トラフィックを RP 上で直接数えたものではない点に注意します。SPT 直結配信が成立したことの主証跡は、本節で別途示している RP の (S,G) が P (Pruned) / OIL = Null であること、および R-LHR の (S,G) Incoming = Gi4 (送信元方向)・R-FHR の OIL = Gi4 です。これらを合わせると、RP は「送信元と受信者が最初に出会う合流点」としての役を終え、データ配信の中継からは退き、配信が FHR→LHR の SPT 直結へ移ったことが確認できます。

ここで注意すべきは、SPT に切り替わっても (*,G) 共有ツリーは消えない点です。R-RP / R-LHR の mroute には SPT 切替後も (*,G) が残っています。これは新しい受信者の join や別の送信元のために共有ツリーを維持しておく必要があるためで、「SPT になったら RPT は消える」は誤りです。

8. 静的 RP の限界 — 次の課題

本節の検証は、3-16 と同じく 静的 RP (ip pim rp-address) を使いました。静的 RP は、全ルータに同じ RP アドレスを手動で設定する方式です。実際、全 4 ルータの設定を確認すると、同じ 1 行が並んでいます。

snippet 
R-FHR#show running-config | include rp-address
ip pim rp-address 10.0.100.5

R-SRC / R-FHR / R-RP / R-LHR のいずれも ip pim rp-address 10.0.100.5 の 1 行を持ち、4 台すべてに手動で同じ RP を教えています。ここに静的 RP の限界が 2 つあります。第 1 に、全ルータに手動設定が必要で、ルータが増えるほど設定漏れや不一致のリスクが上がります。第 2 に、RP 障害時の冗長性がありません。RP が 1 台に固定されているため、その RP が落ちると RPT が張れなくなり、SPT 切替前の新規受信者は配信を受けられなくなります。

この限界を解決する動的な仕組みとして、Cisco 独自の Auto-RP や標準の BSR (Bootstrap Router) があります。どちらも RP の情報をネットワーク全体へ自動的に配布し、複数の候補 RP から実際の RP を動的に決める方式で、手動設定の手間と冗長性の問題を緩和します。本節は静的 RP の中身 (register / RPT→SPT 切替) に集中するため、動的方式の実機検証は扱いません。RP を使わずに配信する別系統の方式は、次節 3-18 で扱います。

9. 落とし穴・補足

実機検証で確認できた、教科書の記述と実機挙動のギャップや注意点を記録します。

  1. SPT 切替のデフォルト閾値は 0 (即時切替) — 多くの教科書は「閾値を超えたら SPT へ切り替える」と説明しますが、Cisco IOS-XE のデフォルト閾値は 0 で、最初のパケットで即時に SPT へ切り替わります。閾値超えを待つ挙動は標準では起きません。RPT に留めたい場合は ip pim spt-threshold infinity を明示設定する必要があり、本ラボはこの設定の有無で切替前後を対比しました。

  2. RP 自身の (*,G) Incoming は Tunnel ではなく構成次第 — 3-16 では RP が分岐点を兼ねていたため (*,G) の Incoming が Null でしたが、register をデカプセル化する Tunnel0 は独立 RP に必ず現れます (§4)。show ip mroute の Incoming が Tunnel・Null・実 IF のいずれになるかは RP の配置で変わるため、Incoming の見え方だけで異常と判断しないよう注意します。

  3. register は FHR (送信元側 DR) が担い、LHR ではない — 「ルータが RP に登録する」と曖昧に覚えると、どのルータが register するか混乱します。register = 送信元側 DR (FHR)、SPT 切替の判断 = 受信側 DR (LHR) と役割が分かれます。debug の Adding register encap tunnel が出るのは FHR (本ラボでは R-FHR) です。

  4. SPT 切替後も (*,G) は残る — SPT に切り替わっても共有ツリー (*,G) のエントリは消えず、新規受信者や別送信元のために維持されます (§7)。「SPT になったら RPT は消える」は誤りで、(*,G) と (S,G) は併存します。RP 経由のトラフィックが止まるのは、RP 側で (S,G) が Pruned になるためです。

  5. DR はデフォルトで最も大きい IP アドレス — PIM DR の選出は、DR priority (既定 1) が同値ならセグメント上で最も大きい IP アドレスを持つルータが選ばれます。意図したルータを FHR / LHR にしたい場合は ip pim dr-priority で調整します。本ラボのトポロジでは送信元 LAN・受信者 LAN の構成上 DR は自明ですが、複数ルータが同一セグメントにいると DR 選出を意識する必要があります。

加えて、本ラボの構築過程で踏んだ 2 点を、観察を仕組む際の注意として正直に記録します。

  • 受信者の join は up し続ける IF に置く — 当初は受信者の ip igmp join-group を未接続の物理 IF に設定したところ、line protocol が down のため OIL に入らず、配信ツリーが受信者まで伸びずに ping が全て失敗しました。ip igmp join-group はメンバ登録自体は行われますが、IF が down だと転送には使えません。本ラボは join を常時 up の Loopback1 に置いて確実に受信者を作りました。
  • RPT と SPT を別 IF にするのに cost 操作は不要だった — 当初は RPT を遠回りにする保険として R-LHR の RP 方向 IF に OSPF コストを上げる設定を入れましたが、RP への経路まで送信元方向へ寄ってしまい、RP と送信元の RPF が同じ IF に潰れて切替が観察できなくなりました。コスト操作を撤去すると、RP への直結パス (Gi3) と送信元への直結パス (Gi4) がトポロジ上で自然に分かれ、RPF が別 IF になりました。RPT と SPT を別 IF にするには「RP への直結パス」と「送信元への直結パス」がトポロジで分かれていれば十分で、人為的な cost 調整はかえって観察を壊す場合があります。

10. 次節

本節では、配信ツリーを張る PIM-SM の中身を実機で確認しました。送信元側 DR (FHR) が送信元を RP に登録する register プロセスと RP の Tunnel0、RP を根とする遠回りの共有ツリー RPT、そして送信元への近道である SPT への切替を扱いました。show ip mroute の Incoming interface が RP 方向 (Gi3) から送信元方向 (Gi4) へ変わり、SPT 切替後は RP が (S,G) を Prune して配信の中継から退く、という一連の動的プロセスを spt-threshold infinity の有無で切替前後を対比しながら追いました。

次節 3-18 SSM / PIM-DM では、RP を使わないマルチキャストの配信方式を扱います。送信元を受信者が直接指定する SSM (Source-Specific Multicast) と、いったん全方向へ流してから不要な枝を刈り取る PIM-DM (Dense Mode) の flood & prune を、本節の PIM-SM と対比しながら CML2.9 で見ていきます。マルチキャスト 3 節の 3 節目であり、第 3 章 L3 編の締めとなります。

次節