3-18 SSM / PIM-DM — RP を使わない 2 つの配信方式
RP を使わない 2 つのマルチキャスト配信方式を扱う第3章の締め。PIM-DM の flood & prune と SSM の (S,G) 直接 join を、CML2.9 IOS-XE 17.x の show ip mroute で実機検証する。
1. 前節の振り返りと本節の内容
前節 3-17 では、配信ツリーを実際に張る PIM-SM (Protocol Independent Multicast - Sparse Mode) を実機で扱いました。送信元側 DR (First-Hop Router = FHR) が送信元を RP (Rendezvous Point) に登録する register プロセス、RP を根とする遠回りの共有ツリー RPT (Rendezvous Point Tree)、そして送信元への近道である SPT (Shortest Path Tree) への切替です。show ip mroute の Incoming interface が RP 方向から送信元方向へ変わる様子を、切替前後で対比しました。PIM-SM は「必要な枝だけ張る」方式で、配信の合流点として必ず RP を介する点が特徴でした。
前々節 3-16 では、その土台となる 4 要素 — クラス D のグループアドレスと 01:00:5e から始まる MAC マッピング、ホストがグループ参加を伝える IGMP (Internet Group Management Protocol)、ループ防止の RPF (Reverse Path Forwarding) チェック、共有ツリー (*,G) と送信元ツリー (S,G) という配信ツリーの考え方 — を扱いました。マルチキャストはこの 3-16 (基礎)・3-17 (PIM-SM) の上に本節が乗る 3 節構成です。
本節 3-18 では、RP を使わない 2 つの配信方式を扱います。1 つ目は PIM-DM (Protocol Independent Multicast - Dense Mode) で、いったん全方向へ流してから不要な枝を刈り取る flood & prune 方式です。2 つ目は SSM (Source-Specific Multicast) で、受信者が「このグループのこの送信元から」を直接指定し、RP も RPT も介さず最初から SPT を張る方式です。どちらも 3-17 で必須だった RP を使いません。この 2 方式を PIM-SM と対比しながら CML2.9 の csr1000v IOS-XE 17.x で実機検証し、最後に PIM-SM / PIM-DM / SSM の 3 方式を一覧で整理します。マルチキャスト 3 節の締めであり、第 3 章 L3 編の総まとめとなる節です。
本節の検証は 2 つの独立したラボで行います。トポロジは以下のとおりです。
PIM-DM ラボはグループ 239.20.20.20、SSM ラボはグループ 232.1.1.1 (送信元 10.0.1.1) を使います。3-16 の 239.1.1.1・3-17 の 239.10.10.10 と区別するためです。
2. PIM-DM (Dense Mode) — まず全方向へ流す
PIM-DM (Dense Mode) は、配信ツリーの張り方が PIM-SM とは対照的な方式です。PIM-SM が「受信者がいる枝だけ張る (sparse)」のに対し、PIM-DM は 「いったんすべての枝へ流してから、不要な枝を刈り取る (dense)」 という考え方をとります。名前の Dense (密) が示すとおり、受信者がネットワークのほぼ全域に密に分布している環境を想定した方式です。受信者がどこにでもいるなら、最初から全方向へ流したほうが手間が少ない、という発想です。
PIM-DM は RP を使いません。PIM-SM では送信元と受信者の合流点として RP が必須でしたが、PIM-DM には RP の概念がありません。実機で確認すると、PIM-DM ラボのルータの show ip pim rp mapping は中身が空で、RP マッピングを 1 件も持ちません。
R-MID#show ip pim rp mapping
PIM Group-to-RP MappingsPIM Group-to-RP Mappings のヘッダだけで、その下に RP のエントリが 1 行もありません。3-17 で Group(s): 224.0.0.0/4, Static / RP: 10.0.100.5 のように RP が並んでいたのとは対照的で、PIM-DM は RP を設定しないため空になります。
PIM-DM を有効にする設定は、各 IF を ip pim dense-mode にするだけです。RP アドレスの設定 (ip pim rp-address) は一切書きません。
ip multicast-routing distributed
!
interface GigabitEthernet2
ip ospf 1 area 0
ip pim dense-mode
! ★ RP 設定 (ip pim rp-address) は書かない各 IF が dense-mode で動いていることは show ip pim interface の Mode 欄で確認できます。R-MID の Gi3 / Gi4 はいずれも v2/D (PIM version 2 の Dense mode) で動作します。3-17 の PIM-SM が v2/S (Sparse) だったのに対し、PIM-DM は D になる点が両者の見分け方です。
3. flood & prune — 不要な枝を刈る
PIM-DM の配信は、送信元が最初のパケットを送った時点で 全方向への flood (氾濫) から始まります。分岐ルータは受信した IF (RPF interface) を除く全 IF へパケットを複製し、いったんすべての枝へ流します。この時点では、受信者がいる枝もいない枝も区別なく Forward 状態です。flood の直後の R-MID の mroute は、(*,G) のフラグに D が立ち、両方の枝が Forward/Dense になります。
(*, 239.20.20.20), 00:02:06/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet3, Forward/Dense, ...
GigabitEthernet2, Forward/Dense, ...(*,G) (*, 239.20.20.20) の flags: D が Dense mode で動作中であることを示します。RP 0.0.0.0 が PIM-SM と決定的に異なる点で、RP が存在しないため 0.0.0.0 (= RP なし) と表示されます。3-17 の (*,G) が RP 10.0.100.5 を持っていたのと対比すると、PIM-DM に RP がないことが一目で分かります。なおこの flood 直後の (*,G) は Incoming interface: Null の過渡的な状態で、まだ送信元方向 (RPF) が確定していないため OIL にも複数 IF が並びます。配信の本体である (S,G) が立つと、後述のとおり Incoming が送信元方向の Gi2 に確定し、下流の枝 (Gi3 / Gi4) が OIL に整理されます。「両方の枝が Forward」というのは、この下流の Gi3 / Gi4 が flood 段階ではいずれも Forward である、という意味で読んでください。
flood は無駄が多いため、受信者のいない枝はそのまま流し続けません。受信者がいない下流のルータは、上流に向けて Prune (剪定) メッセージを送り、自分への配信を止めるよう要求します。これが flood & prune の prune (刈り取り) の部分です。本ラボでは R-RECV (Gi3 の先) に受信者がいて R-LEAF (Gi4 の先) には受信者がいないため、R-LEAF が Prune を送り、R-MID の Gi4 が配信から外れます。flood & prune が落ち着いた後の R-MID の (S,G) は、受信者のいる Gi3 だけが Forward/Dense、受信者のいない Gi4 が Prune/Dense になります。
(10.0.1.1, 239.20.20.20), 00:02:06/00:00:53, flags: T
Incoming interface: GigabitEthernet2, RPF nbr 10.0.1.1
Outgoing interface list:
GigabitEthernet3, Forward/Dense, 00:02:06/stopped
GigabitEthernet4, Prune/Dense, 00:02:06/00:00:53(S,G) (10.0.1.1, 239.20.20.20) の OIL を見ると、受信者あり = Gi3 が Forward/Dense、受信者なし = Gi4 が Prune/Dense で、枝ごとに状態が分かれています。これが flood & prune の核心となる証跡です。Incoming interface = Gi2 は送信元 R-SRC の方向で、送信元アドレス 10.0.1.1 は R-SRC が source 指定で送ったものです。
R-LEAF が Prune を送っている様子は、R-MID で debug ip pim を仕掛けると捕捉できます。R-LEAF (10.0.35.5) から Gi4 で Prune を受信し、(S,G) を Prune している記録が残ります。
PIM(0): Received v2 Join/Prune on GigabitEthernet4 from 10.0.35.5, to us
PIM(0): Prune-list: (10.0.1.1/32, 239.20.20.20)
PIM(0): Prune GigabitEthernet4/239.20.20.20 from (10.0.1.1/32, 239.20.20.20)Received v2 Join/Prune on GigabitEthernet4 from 10.0.35.5 で R-LEAF から Prune を受け取り、Prune GigabitEthernet4/239.20.20.20 で Gi4 を配信から外しています。Prune を送った R-LEAF 自身は、flood を受けたうえで自分を Prune するため、(S,G) のフラグに P (Pruned) が立ち、OIL が Null になります。
(10.0.1.1, 239.20.20.20), flags: PT
...
Outgoing interface list: NullR-LEAF の (S,G) flags: PT の P (Pruned) と OIL = Null は、「自分の下流に受信者がいないので、この枝の配信を止めた」ことを表します。
4. Graft — 刈った枝を再接続する
PIM-DM で Prune によって刈り取られた枝は、永久に切れたままではありません。Prune した枝の下流に受信者が新たに現れると、そのルータは上流へ Graft (接ぎ木) メッセージを送り、刈られた枝を配信ツリーへ再接続します。flood & prune が「不要な枝を刈る」動作なら、Graft は「必要になった枝を戻す」動作です。Prune と Graft が対になって、受信者の増減に追従します。
ここで PIM-DM の特徴的な挙動が、Prune には確認応答がないのに対し、Graft には Graft-Ack という確認応答がある点です。Prune は「いらない」という要求で、仮に取りこぼしても起きるのは「不要なトラフィックが止まらずに流れ続ける」(帯域の無駄) だけで、受信者の通信が壊れるわけではありません。さらに prune state はタイマー満了で消えて次の flood でまた流れてくるため、取りこぼしは自然に復旧します。だから Prune には Graft-Ack のような確認応答や再送を設けていません。一方 Graft は「もう一度欲しい」という要求で、取りこぼすと受信者が配信を受けられない (致命的) ため、上流が Graft-Ack を返し、届かなければ再送して確実に届いたことを保証します。
本ラボでは、当初受信者のいなかった R-LEAF の Loopback1 に ip igmp join-group 239.20.20.20 を後付けして受信者を出現させます。すると R-LEAF が R-MID へ Graft を送り、R-MID の Gi4 が Prune/Dense から Forward/Dense へ復帰します。
(10.0.1.1, 239.20.20.20), ...
Outgoing interface list:
GigabitEthernet3, Forward/Dense, ...
GigabitEthernet4, Forward/Dense, ...R-MID の (S,G) の OIL を見ると、§3 で Prune/Dense だった Gi4 が Forward/Dense に戻り、Gi3・Gi4 の両枝が Forward に揃いました。Graft によって刈られていた枝が配信ツリーへ復帰したことを示します。受信者を後付けした R-LEAF 自身の (*,G) は、自分が直結メンバになるためフラグに C (Connected) と L (Local) が立ち、OIL に Loopback1 が入ります。
(*, 239.20.20.20), flags: DCL
...
Outgoing interface list:
Loopback1, Forward/Dense, ...R-LEAF の (*,G) flags: DCL は、D=Dense mode、C=Connected (直結メンバあり)、L=Local (ルータ自身が join-group でメンバ) を表します。OIL = Loopback1 が後付けした受信者で、ここへ配信が届くようになりました。
5. SSM (Source-Specific Multicast) — 送信元を直接指定する
ここからは RP を使わないもう 1 つの方式、SSM (Source-Specific Multicast) を扱います。PIM-DM が「全方向へ流してから刈る」方式だったのに対し、SSM は 受信者が「このグループのこの送信元から受け取りたい」と送信元を名指しで指定する方式です。受信者は (S,G) — 送信元 S とグループ G の組 — を直接指定するため、ネットワークは送信元の在りかを RP に問い合わせる必要がありません。動画配信のように「誰が配信しているか (送信元) が受信者に分かっている」用途に向いた方式です。
SSM は専用のグループアドレス範囲 232.0.0.0/8 を使います。クラス D 全体 (224.0.0.0/4) のうち 232.0.0.0〜232.255.255.255 が SSM 用に予約されており、この範囲のグループは SSM として扱われます。IOS-XE では ip pim ssm default の 1 行で 232.0.0.0/8 を SSM レンジに指定します。設定は以下のとおりです。
ip multicast-routing distributed
ip pim ssm default ! 232.0.0.0/8 を SSM レンジに
!
interface GigabitEthernet2
ip ospf 1 area 0
ip pim sparse-mode注意すべきは、IF 自体は ip pim sparse-mode で設定する点です。SSM は PIM-SM と同じ sparse-mode の IF 上で動き、グループが 232.0.0.0/8 の範囲に入るかどうかで SSM か通常の PIM-SM かが分かれます。ip pim ssm default がそのレンジ判定を有効にします。RP アドレスの設定 (ip pim rp-address) は SSM では一切書きません。
受信者側は、Loopback1 に IGMPv3 を有効にしたうえで、グループと送信元を組で指定して join します。
interface Loopback1
ip pim sparse-mode
ip igmp version 3
ip igmp join-group 232.1.1.1 source 10.0.1.1ip igmp join-group 232.1.1.1 source 10.0.1.1 が SSM の肝です。グループ 232.1.1.1 を、送信元 10.0.1.1 に限定して join しています。ip igmp version 3 が必須なのは、送信元を指定する join が IGMPv3 でのみ表現できるためで、その理由は §7 で IGMP のモードとともに扱います。
6. SSM は RPT を作らない — 最初から (S,G) の SPT
SSM の最大の特徴は、RP を根とする (*,G) 共有ツリー (RPT) を作らず、最初から (S,G) の SPT を張る点です。3-17 の PIM-SM では、まず RP を根とする (*,G) で配信を始め、その後 (S,G) の SPT へ切り替えるという 2 段階の動きをしました。SSM では受信者が最初から送信元 S を名指しするため、RP に問い合わせる (*,G) の段階が不要で、いきなり送信元への最短パス (S,G) が張られます。register も RPT も SPT 切替も発生しません (IOS-XE では SSM レンジでも (*, 232.x.x.x) の placeholder エントリが mroute に出る実装もありますが、それは RPT による配信ではなく、配信は (S,G) だけで行われます。本ラボの実機では下記のとおり (*,G) エントリ自体も現れませんでした)。
実機で R-RECV の mroute を確認すると、(*,G) は存在せず、(S,G) (10.0.1.1, 232.1.1.1) だけが現れます。
(10.0.1.1, 232.1.1.1), 00:01:50/00:02:07, flags: sLTI
Incoming interface: GigabitEthernet2, RPF nbr 10.0.23.2
Outgoing interface list:
Loopback1, Forward/Sparse, 00:01:50/00:02:07(S,G) のフラグ sLTI が SSM の状態を表します。s は SSM Group (このエントリが SSM レンジのグループであること)、L は Local (ルータ自身が join-group でメンバ)、T は SPT-bit set (送信元ツリーで配信中)、I は Received Source Specific Host Report (送信元指定の Host Report を受けた) を意味します。Incoming interface が最初から Gi2 (RPF neighbor 10.0.23.2 経由で送信元 10.0.1.1 へ向かう方向) になっており、RP を経由せず送信元へ向かう SPT がいきなり成立しています。10.0.23.2 はエントリ先頭の送信元 10.0.1.1 へ向かう次ホップ隣接 (RPF nbr) であって送信元アドレスそのものではない点に注意します。3-17 では切替前に Incoming が RP 方向だったのに対し、SSM では切替という段階がそもそもありません。
(*,G) が作られないことは、全ルータの mroute を見渡しても確認できます。SSM ラボのどのルータにも (*, 232.1.1.1) のエントリが存在せず、(S,G) だけが並びます。
R-RECV#show ip mroute 232.1.1.1
...
(10.0.1.1, 232.1.1.1), 00:01:50/00:02:07, flags: sLTI
...mroute 全体には (*, 224.0.1.40) が現れることがありますが、これは Auto-RP の discovery 用に常時存在するエントリで、本節の SSM とは無関係です。232.1.1.1 については本ラボの実機では (*,G) が現れず (S,G) のみで、RPT を介さず (S,G) で配信する、というのが SSM の動きです。
SSM で RP を使っていないことは、設定からも裏付けられます。show running-config | include ssm には ip pim ssm default が現れる一方、show running-config | include rp-address は何も返さず空です。show ip pim rp mapping も空で、RP が存在しないことが確認できます。3-17 の register プロセス・RP の Tunnel0・RPT→SPT 切替という一連の仕組みが、SSM では丸ごと不要になります。
7. INCLUDE モードと IGMPv3 — 3-16 との対比
SSM が送信元を指定できるのは、受信者側の IGMPv3 の INCLUDE モードを使っているためです。IGMPv3 のグループメンバシップには 2 つのモードがあります。INCLUDE モードは「指定した送信元だけを受信する」、**EXCLUDE モードは「指定した送信元を除外して受信する (= 残り全部を受信)」**という対照的な意味を持ちます。3-16 で扱った通常のグループ参加は EXCLUDE モードで、Source list が空のため「どの送信元も除外しない = すべての送信元を受信する (any-source)」状態でした。
SSM は受信者が送信元を名指しするため INCLUDE モードを使います。R-RECV の show ip igmp groups 232.1.1.1 detail を見ると、Group mode が INCLUDE で、Source list に指定した送信元 10.0.1.1 が並びます。
Group: 232.1.1.1
Flags: L SSM
Group mode: INCLUDE
Group source list:
Source Address Uptime v3 Exp CSR Exp Fwd Flags
10.0.1.1 00:03:40 00:02:22 stopped Yes RLGroup mode: INCLUDE が SSM の受信モードで、Group source list の 10.0.1.1 が受信を許可した唯一の送信元です。Fwd 欄が Yes で、この送信元からの配信が転送されていることを示します。Flags: L SSM の SSM は、このグループが SSM レンジ (232.0.0.0/8) であることを表します。INCLUDE モードでは Source list に挙げた送信元だけが受信対象になり、それ以外の送信元からのトラフィックは届きません。
これを 3-16 / PIM-DM の plain join と対比すると違いが鮮明です。3-16 の通常 join や PIM-DM の join は EXCLUDE モード (Source list 空 = any-source) で、どの送信元からでも受信します。一方 SSM の INCLUDE モードは、指定した送信元からだけ受信します。
| 受信モード | 意味 | Source list | 使う場面 |
|---|---|---|---|
| EXCLUDE | 指定送信元を除外して受信 (空なら any-source) | 空 = 全送信元受信 | 3-16 の通常 join / PIM-DM / PIM-SM の (*,G) |
| INCLUDE | 指定送信元だけ受信 | 受信したい送信元を列挙 | SSM の (S,G) join |
IGMPv2 では送信元を指定する手段がないため、SSM には IGMPv3 が必須です。§5 の受信者設定で ip igmp version 3 を入れたのはこのためで、IGMPv2 のままでは INCLUDE モードの (S,G) join を表現できません。
8. 3 つの配信方式の対比 — PIM-SM / PIM-DM / SSM
マルチキャストの配信方式として、3-17 の PIM-SM と本節の PIM-DM・SSM の 3 つを扱いました。3 方式の違いを一覧で整理すると以下のとおりです。
| 軸 | PIM-SM (3-17) | PIM-DM (本節) | SSM (本節) |
|---|---|---|---|
| RP の有無 | あり (合流点として必須) | なし | なし |
| 配信ツリーの張り方 | 必要な枝だけ張る (sparse) | 全方向へ flood → 不要枝を prune | 送信元へ直接 SPT |
| (*,G) 共有ツリー (RPT) | あり (RP を根とする RPT) | なし (mroute に (*,G) 状態表示は出るが RP 0.0.0.0 = RPT ではない) | なし (RPT を作らず (S,G) のみで配信。本ラボでは (*,G) エントリも現れず) |
| (S,G) 送信元ツリー | SPT 切替で形成 | flood & prune で形成 | 最初から SPT |
| register プロセス | あり (FHR が RP へ登録) | なし | なし |
| 不要枝の扱い | 最初から流さない | Prune で刈り、Graft で戻す | 該当なし (名指しのみ配信) |
| IGMP モード | EXCLUDE (any-source) | EXCLUDE (any-source) | INCLUDE (source 指定) |
| IGMP バージョン | v2 / v3 | v2 / v3 | v3 必須 |
| グループ範囲 | 224.0.0.0/4 (一般) | 224.0.0.0/4 (一般) | 232.0.0.0/8 (専用) |
| 向いている環境 | 受信者がまばらな広域 | 受信者が密な環境 | 送信元が既知の配信 |
この表が示すとおり、RP を使うのは PIM-SM だけで、PIM-DM と SSM はいずれも RP なしで配信します。RP なしの 2 方式は、不要枝への対処が対照的です。PIM-DM は「いったん全部流してから刈る」、SSM は「最初から名指しの送信元だけ流す」というアプローチをとります。
3 方式の使い分けは、受信者の分布と送信元の既知性で決まります。受信者が広域にまばらに分布するなら PIM-SM、受信者がほぼ全域に密に分布するなら PIM-DM、受信者が送信元を最初から知っているなら SSM が向きます。マルチキャストは 3-16 で基礎 (IGMP / RPF / 配信ツリー)、3-17 で RP を使う PIM-SM、本節で RP を使わない PIM-DM・SSM、と RP の有無の両側を揃えて全体像を扱いました。
9. 落とし穴・補足
実機検証で確認できた、教科書の記述と実機挙動のギャップや注意点を記録します。
PIM-DM は RP を設定しない — PIM-SM では RP が必須でしたが、PIM-DM に RP の概念はありません。各 IF を
ip pim dense-modeにするだけで、ip pim rp-addressは書きません (§2)。show ip pim rp mappingが空 (ヘッダのみ) なのは異常ではなく、PIM-DM では正常です。(*,G) のRP 0.0.0.0も「RP なし」の表示で、PIM-SM のRP 10.0.100.5と見比べると区別できます。flood は一瞬、prune が定常状態 — PIM-DM は「全方向へ流す」と説明されますが、全方向 flood が続くのは prune が落ち着くまでの一時的な状態です。受信者のいない枝はすぐに Prune され、定常状態では受信者のいる枝だけが
Forward/Dense、いない枝はPrune/Denseになります (§3)。「PIM-DM は常に全方向へ垂れ流す」という理解は誤りで、flood & prune の組で必要な枝だけに収束します。ただし Prune には寿命があり、定期的に再 flood と再 prune を繰り返すため、まばらな受信者の環境では PIM-SM より無駄が多くなります。SSM は RPT を作らず (S,G) のみで配信する — PIM-SM は RP を根とする (*,G) で始めて (S,G) へ切り替えますが、SSM は最初から (S,G) のみで配信し、RP を根とする (*,G) 共有ツリー (RPT) を作りません (§6)。
show ip mrouteで SSM グループ (232.x.x.x) を見たとき、本ラボの実機では (*,G) が現れず (S,G) だけが並びました (IOS-XE の実装によっては(*, 232.x.x.x)の placeholder エントリが出ることもありますが、その場合も配信は (S,G) で行われ RPT は使われません)。register・RPT・SPT 切替という PIM-SM の一連のプロセスが SSM では丸ごと省かれます。(*, 224.0.1.40)が mroute に現れることがありますが、これは Auto-RP discovery 用の別エントリで SSM とは無関係です。SSM は IGMPv3 が必須 — SSM の受信者は送信元を名指しで join するため、送信元指定ができる IGMPv3 が必要です (§5・§7)。受信者 IF に
ip igmp version 3を入れ忘れると、IGMPv2 のままでは (S,G) join を表現できず、SSM の配信が成立しません。SSM が機能しないときは、まず受信者 IF の IGMP バージョンを確認します。INCLUDE と EXCLUDE を取り違えない — IGMPv3 の INCLUDE は「指定した送信元だけ受信」、EXCLUDE は「指定した送信元を除外して受信 (空なら any-source)」で、意味が逆です (§7)。SSM の受信者は INCLUDE モードで Source list に送信元を列挙します。一方 3-16 の通常 join や PIM-DM は EXCLUDE モード (Source list 空 = any-source) です。
show ip igmp groups ... detailのGroup modeが INCLUDE か EXCLUDE かで、どちらの受信形態かを見分けられます。
10. 第 3 章のまとめと第 4 章の内容
本節では、RP を使わない 2 つの配信方式を実機で確認しました。PIM-DM は送信元が送ると全方向へ flood し、受信者のいない枝を Prune で刈り (Forward/Dense ↔ Prune/Dense)、受信者が後から現れると Graft で枝を戻す flood & prune 方式でした。SSM は受信者が IGMPv3 の INCLUDE モードで送信元を名指しし、RP も (*,G) も介さず最初から (S,G) の SPT を張る方式でした (flags: sLTI)。PIM-SM / PIM-DM / SSM の 3 方式を、RP の有無・配信ツリーの張り方・IGMP モードで一覧に整理し、RP を使うのは PIM-SM だけであることを確認しました。これでマルチキャスト 3 節 (3-16 基礎 / 3-17 PIM-SM / 3-18 本節) が揃い、RP ありと RP なしの両方の配信方式の全体像が出そろいました。
本節をもって 第 3 章 L3 編 全 18 節が完走します。第 3 章は次の流れで L3 (ネットワーク層) を扱いました。3-1 で IP アドレッシングの詳細、3-2 でルーティングの基礎を固め、3-3 RIP・3-4 EIGRP・3-5 OSPF で IGP (Interior Gateway Protocol) を、3-6 BGP から 3-9 Confederation までで EGP (Exterior Gateway Protocol) としての BGP とその応用 (Route Reflector・BGP コミュニティ・Confederation) を扱いました。3-10 ルート再配送、3-11 ルーティングポリシーの総括で複数プロトコルの連携を整理し、3-12 FHRP (First Hop Redundancy Protocol) でゲートウェイ冗長を扱いました。3-13 から 3-15 で IPv6 (アドレス体系・NDP/SLAAC・ルーティング) を 3 節に分け、3-16 から 3-18 でマルチキャスト (基礎・PIM-SM・SSM/PIM-DM) を 3 節に分けて締めくくりました。ユニキャストの経路選択からマルチキャストの配信ツリーまで、L3 の経路制御を一通り扱った章です。
第 4 章はセキュリティ編 (8 節予定) に進みます。ACL (Access Control List) によるトラフィック制御、AAA (Authentication / Authorization / Accounting) による認証認可、ポートセキュリティによる L2 の保護、IPsec による暗号化トンネルなど、ネットワーク機器でトラフィックを守る仕組みを CML2.9 の実機検証とともに扱います。L3 編で築いた経路制御の土台の上に、通信を保護する層を重ねていきましょう。
次章
- 4-1 ACL の基礎（第 4 章セキュリティ編、準備中）