IP Multicast Topic 2006/07/13 JANOG18 吉村浩 hyoshimu@cisco.com ( hiroshi1201@mbh.nifty.com )
Disclaimer and Agenda 本日は既存の Multicast 技術をベースに話しをさせて頂きます PIM Sparse Mode と PIM SSM の違い IP Multicast 冗長化の実情 IGMPv3/MLDv2 の簡単理解 本日触れない内容 Multicast over PPPoE/L2TPv2 Multicast AAA 2
PIM の概要 Sparse Mode 概要 省略 ( 話しが長くなるので ) 3
PIM Sparse Mode の鬼門 RP 折り返し (AKA RP-on-a-stick, RP Turnaround) RP が Source と離れた場所に置かれている場合の Sparse Mode の複雑な動作 (S,G) ツリー分岐点 Source Tree が無ければ Source への (S,G)Join は最初は必ず RP で折り返す (S,G) トラフィック 先に Join 中 SP-Tree 0 Join(*,G)/Prune(S,G,rpt) Rcvr1 2 Join(S,G,rpt) 3 Join(S,G) RP-Tree RP Join(*,G) 1 Rcvr2 IGMP Join(G) 1 4
PIM Sparse Mode の鬼門 RP 折り返し ( 続き ) (S,G) (S,G) トラフィック 先に Join 中 SP-Tree RP の折り返し動作は Prune(S,G,rpt) 受信で止まる ( 右図 4 5) draft-ietf-pim-sm-v2-new-xx ベースの実装 ( に近い 注 ) Rcvr1 (S,G) トラフ 4 ィック検出 Join(S,G) 6 4 Prune(S,G) RP-Tree Prune(S,G,rpt) 5 RP IOS の 3 動作の Proxy Join は Cisco 独自用語. 4 5 には数秒の Delay がある ( 独自動作 ) Rcvr2 5
PIM Sparse Mode の鬼門 RP 折り返し ( 続き ) Sparse Mode がややこしいなぁと思ったら... PIM SSM を使いましょう! 6
PIM SSM の場合 (S,G) (S,G)Data Rcvr1 Source-Tree RP Join(S,G) 2 Rcvr2 IGMPv3 Allow_new_sources(S,G) 1 7
小ネタ IPv6 での PIM Hello Option による RPF 解決 8
PIM Hello Address Option の RPF への応用例 IPv6 PIM の場合 RPFルール Sourceへのnext hop は同時に PIM Neighborでなければならない (Join/Prune 送信先 ) IPv6でstatic routeのnext hopをroutable addressに指定する場合の解決方法 2001:db8:0:1::/64 ::254 Rtr-A Source (2001:db8:0:2::1, FF3E::AB:CD) PIM Hello Source IP: FE80::1:254 (link-local) Address option 24: 2001:db8:0:1::254 ::253 Rtr-B マッチ! RPF OK ipv6 route ::/0 2001:db8:0:1::254 show ipv6 pim neighbor: FE80::1:254 Addr Opt. 2001:db8:0:1::254 9
IP Multicast の冗長化 10
IP Multicast の冗長化 Convergence: Primary Backup PIM Adjacency Rtr-D PIM Adjacency backup path Join(S,G) 6 backup path 5 Join(S,G) Join(S,G) Rtr-A 4 Source 2 Prune(S,G) 右側が primary path 4 1 Link Down Rtr-B Prune(S,G) Backup Path への切り替え時間は Unicast Routing の収束 + RPF 検出時間 + Join(S,G) の伝播時間 RPF 検出時間は IOS の場合 Triggered RPF 機能 Backup Path への Join は上流にスムーズに中継されていく 一番近い Source Tree まで 例えば Rtr-A の配下に Receiver がいると左図の 6 の Join(S,G) は不要 最悪 First Hop Router まで Rtr-C 3 Next Hop が Rtr-B から Rtr-D に変った... Join をトリガーしよう... 11
IP Multicast の冗長化 Triggered RPF Cisco 独自機能 コマンド ip multicast rpf backoff initial backoff は500msec 昔は RPF チェックは 5 秒周期 復旧時間がばらつく 12
IP Multicast の冗長化 Unicast との差 結局 Unicast と比較すると Multicast の復旧は PIM Join の片道伝播時間が余計にかかるため遅延が目立つ + 現 IOS の場合 Triggered RPF 時間 13
IP Multicast の冗長化 ( 痛いところ ) Backup Primary Path 復旧 Backup Primary Path 復旧時の課題 : Case1: Unicast の収束よりも Primary Path 上で PIM Neighbor 検出が遅れる (PIM Hello 問題 ) Case2: 上流の Router が下流の Router よりも Unicast の収束が遅れる (Micro-Loop 問題 ) 14
IP Multicast のパス復旧時の問題 PIM Hello 問題 右側が Primary Path 5 Rtr-D Prune(S,G) 60Sec 経った... periodic Join を送ろう... Source 3 Rtr-A Join(S,G) 5 Rtr-C Join(S,G) Hello 6 Rtr-B 4 1 Link Up! RPF Path が Primary Path に変わったが Next Hop が PIM Neighbor として未だ見えていない : Join(S,G) を復旧した Primary Path に直ちに送信できない. 最悪 60 秒の復旧遅延. 2 Next Hop が Rtr-B に変った, 古い Path を Prune しかし...Rtr-B が PIM ルータかどうか分からないから Join 出すのは止め... 15
IP Multicast のパス復旧時の問題 PIM Hello 問題の解決は... 右側が Primary Path Source Rtr-A Join(S,G) Next Hop からの PIM Hello をトリガーに Join(S,G) を送信 PIM Hello が来るまでは遅延が出てしまう Hello Timer のチューニング 6 Rtr-D 5 Helloが来た! Joinをトリガーしよう Prune(S,G) 3 Join(S,G) 5 Rtr-C Hello Rtr-B 4 1 Link Up! 2 Next HopがRtr-Bに変った... 古いPathをPrune... Helloが見えるまで待とう... 16
IP Multicast のパス復旧時の問題 Micro-Loop 右側が Primary Path Rtr-D 4 Prune(S,G) Source Rtr-A Next-Hop から Join 受けてもしょうがないんだよな... Join(S,G) 6 Rtr-B RFC2362 では 入力インタフェースからJoin を受けても それを OIL に入れられないから OIL= 空 1 Rtr-A との回線 Up! Join が出せない 最悪 60 秒の復旧遅延 5 60 秒経ったから periodic Join 送ろう... 3 Join(S,G) 3 Rtr-C Join(S,G) 5 2 Next HopがRtr-Bに変った. 古いツリーを Pruneして新しいツリーにJoinを送ろう... 17
IP Multicast のパス復旧時の問題 Micro-Loop 対策は... Source iif から Join を受信すると Next Hop が変るまで待って iif を OIL に入れて Join を上流に出す 右側が Primary Path Rtr-D 3 Rtr-A iif から Join が来た... しばらく待ってみよう... Prune(S,G) 3 Rtr-C Join(S,G) 3 Join(S,G) 4' Rtr-B 4 1 Rtr-A との回線 Up! お Next Hop が Rtr-A に変った. Join を上に送ろう... 2 Next HopがRtr-Bに変った. 古いツリーを Pruneして新しいツリーにJoinを送ろう... あるいは draft-ietf-pim-sm-v2-new-xx ベースの実装だと iif を OIL に入れても構わないので元々この問題は起きない (iif は forwarding に使ってはならない という基本ルールでガードされている ) 18
IGMPv3 & MLDv2 19
IGMPv3/MLDv2 の最大の難点 RFC の内容が複雑かつ難解 ( 私にとっては...) 既に実装されてしまっているため 簡易版作るのも大変そうな... 20
IGMPv3/MLDv2 の難点直感的に理解し難いメッセージ 略号 Mode TYPE1:IS_INCLUDE ;IS_IN ({S},G) 1 TYPE2:IS_EXCLUDE ;IS_EX({S},G) 2 TYPE3:CHANGE_TO_INCLUDE ;TO_IN({S},G) 3 TYPE4:CHANGE_TO_EXCLUDE ;TO_EX ({S},G) 4 TYPE5:ALLOW_NEW_SOURCES ;ALLOW({S},G) 5 TYPE6:BLOCK_OLD_SOURCES ;BLOCK({S},G) 6 {S} は Source のリスト 21
IGMPv3/MLDv2 と SSM SSM では以下のメッセージだけで十分なはず... ALLOW ({S},G) : 受信要求 IS_IN ({S}, G) : 上記 interestの状態 (queryへの返事) BLOCK({S},G) : 停止要求 いつの間にか TO_IN({S},G) も許容すべきと メッセージを増やすメリットあり? Appendix 参照 22
IGMPv3 SSM Join 時 ALLOW({10.1.248.120}, 232.255.1.1) 1 (10.1.248.120, 232.255.1.1) に Join したい Eth1/0 R105 PIM Join(S,G) R105#show ip igmp group 232.255.1.1 detail <snip> Interface: Ethernet1/0 Group: 232.255.1.1 Flags: SSM Uptime: 00:01:51 Group mode: INCLUDE Last reporter: 10.1.249.128 Group source list: (C - Cisco Src Report, U - URD, R - Remote, S - Static, V - Virtual, Ac - Accounted towards access control limit, M - SSM Mapping, L - Local) Source Address Uptime v3 Exp CSR Exp Fwd Flags 10.1.248.120 00:01:51 00:02:10 stopped Yes R Src-A (10.1.248.120, 232.255.1.1) Src-B (10.1.248.121, 232.255.1.1) 23
IGMPv3 SSM Join 中 (10.1.248.120, 232.255.1.1) に Join 中 3 IS_IN({10.1.248.120}, 232.255.1.1) Eth1/0 R105 2 General Query R105#show ip mroute 232.255.1.1 IP Multicast Routing Table Flags:...snip... s - SSM Group...snip... T - SPT-bit set...snip... I - Received Source...snip... (10.1.248.120, 232.255.1.1), 00:07:32/00:02:59, flags: sti Incoming interface: Ethernet4/0, RPF nbr 10.1.20.103 Outgoing interface list: Ethernet1/0, Forward/Sparse, 00:07:32/00:02:32 Src-A (10.1.248.120, 232.255.1.1) Src-B (10.1.248.121, 232.255.1.1) 24
IGMPv3 SSM Leave 時 BLOCK({10.1.248.120}, 232.255.1.1) 4 (10.1.248.120, 232.255.1.1) はもう要らない PIM Prune (S,G) 6 Eth1/0 R105 5 Group/Source Specific Query Query for: (10.1.248.120, 232.255.1.1) Src-A (10.1.248.120, 232.255.1.1) Src-B (10.1.248.121, 232.255.1.1) 25
IGMPv3/MLDv2 EXCLUDE って何だ? Sparse Mode の世界で 特定の Source を EXCLUDE( 排除 ) し それ以外の全ての Source(Any Source) への受信を要求するもの 特定の Source のみ受信したくない という要求をレシーバ間で完全合意することは可能か??? 使い道無し RP でフィルタすればいい 26
IGMPv3/MLDv2 の痛いところ LAN Switch の snooping によるフィルタリングが MAC アドレスベース (S1,G1), (S2,G1) は本来違う Channel として峻別できるはずなのだが... Src-A (10.1.248.120, 232.255.1.1) Src-B (10.1.248.121, 232.255.1.1) Gi1/3 vlan group-mac-address port --------------------------------------------------------- 10 0100.5E7F.0101 Gi1/1, Gi1/2, Gi1/3 IS_IN(10.1.248.120, 232.255.1.1) Gi1/1 Gi1/2 IS_IN(10.1.248.121, 232.255.1.1) 27
SSM の大きなメリット Hot-Hot Redundancy が可能 Src-2 (S2, G1) Src-1 (S1, G1) Sparse Mode の場合 Group の一意性をグローバルに保証しなければならない不可能 アイデア自体は古い Rtr-D backup channel Rtr-B レガシーな Hot-Hot Redundancy( 例 ) 神戸大阪 神戸エリア 明石市 岡山瀬戸内エリア STB Rtr-C IGMPv3 or MLDv2 ALLOW{Src-1, Src-2}, G1) 28
まとめ ( 提言 ) SSM に移行を本格的に検討しましょう ネットワークとしては Ready Sparse Modeよりも楽 Multicast の冗長化 Unicastとの差分は PIM Joinの伝播遅延 ( 直近ツリーまで ) 許すか... 許せない場合 P2MP RSVP-TE + Fast Rerouteの出番か... 運用実績は? P2MP RSVP-TEはスケールし得るか??? が課題 IGMPv3/MLDv2 (+ SSM との絡み ) をどうするか SSMではメッセージ 3 種類 (ALLOW, IS_IN, BLOCK) で十分 CHANGE_TO_INCLUDEはやめましょう ALLOW と IS_INCLUDE を ALLOW だけにまとめてしまうことも出来るかも... 同一 Group 間のチャネル (e.g. (S1,G), (S2,G)) 識別をどう考えるか残念ながらL2 SwitchはReadyではない Hot-Hot Redundancyに応用すべきではないか
Appendix. RFC3376 引用 RFC3376Internet Group ManagementProtocol, Version3 5.1. Action on ChangeofInterface State...snip.. a per-interface record), thenthe"non-existent" state is considered to have afilter modeofinclude andanemptysource list. Old State New State State-Change RecordSent ------- ------- ----------------- INCLUDE(A) INCLUDE(B) ALLOW (B-A), BLOCK (A-B) OLDState New State State-Change Record Sent ------- ------ ---------------- 最初のチャンネル Join INCLUDE (NONE) INCLUDE (Src-A) ALOW(Src-A) チャンネル変更 INCLUDE(Src-A)INCLUDE (Src-B) ALOW(Src-B),BLOCK(Src-A) チャンネル追加 INCLUDE(Src-A)INCLUDE (Src-A,Src-B) ALOW(Src-B)