シスコサポートコミュニティ (CSC) Live Expert Webcast 第 3 版 Cisco LAN スイッチ教科書 番外編 山下薫 (kaoru@cisco.com) シスコシステムズ合同会社 2014 年 9 月 9 日 (Rev. 1)
はじめに 第 3 版 Cisco LAN スイッチ教科書 3 月 20 日の出版から半年弱が経ちました 表紙には Catalyst の写真しかありませんが 実は Nexus 含有率 30% くらいの本です なので書名から "Catalyst" が無くなりました 出版後のアップデートや 時間と体力が足りず書き切れなかった点がいくつかあります 今回のセッション : 番外編 質問箱 にいただいたご質問と プレゼンタが用意した話題の計 4 つについて解説します Cisco Public 2
今日の Agenda はじめに 1. ACL が TCAM に書き込めないとどうなるのか (20 分 ) 2. STP 安定化技術を実際に 発動 させてみる (10 分 ) 3. FabricPath の高度なループ防止メカニズムと vpc+ (20 分 ) 4. HSRP Preempt 使用時に 再起動の際のパケットロスを防ぐには (10 分 ) 難易度 (Nexus 含有率 ) 1.5 2 2 3 Q&A (20 分 ) + 受講者プレゼントについてのお知らせ + おわりに Cisco Public 3
進め方 4 つのご質問 ( 話題 / テーマ ) について まずは直接ご回答します その後 そのご質問に関して LAN スイッチ教科書 に書き切れなかった関連情報や 出版後に判明したことをご紹介します 追加のご質問は このセッションの最後にまとめてお受けします Cisco Public 4
[ その 1] ACL を TCAM に書き込めない (TCAM の容量が足りない ) 場合 スイッチはどのように動作するのか Catalyst メイン ( 一部 Nexus にも適用 ) 難易度 1.5 ( やや低 ) Cisco Public 5
最初にご回答 テーマその 1 ACL(RACL) を TCAM に書き込めない場合の挙動を 一部の機種で確認しました 1. 代わりに 該当 ACL とパケット転送をソフトウェアで処理する (Catalyst 3750-X) 2. ACL の設定は入るが 実際には TCAM に書き込まず ソフトウェア処理もしない ACLの設定を無視する OSPF, ICMPなどもともとソフトウェア処理されるパケットには効く (Catalyst 3650, IOS-XE 3.6.0E) 3850も同じとのBUの回答あり 今後リリースされる IOS や IOS-XE では 挙動が変わる可能性があります Catalyst の他の機種や Nexus では挙動が異なる場合があります RACL 以外の機能を併用する場合 TCAM を共用している機種では制限事項や挙動の変化があり得ます ( 参考 : P.180 コラム ) Cisco Public 6
P.133-135 LAN スイッチの内部構造 ( アーキテクチャ ) 他の機器から学習 ( ダイナミックルーティングプロトコルなど ) テーマその 1 コンフィグ投入 (ACL など ) MAC 学習 コントロールプレーン 書き込み or プログラミング データプレーン (TCAM) に書き込めれば スイッチはワイヤレートでパケット ( フレーム ) を転送できる これは TCAM がテーブルの大きさに無関係に一定時間で検索できるため 複数の機能を同時に利用していても 性能は変わらない ( 一部例外あり ) TCAM データプレーン パケット ( フレーム ) 転送 パケット ( フレーム ) ハードウェアによる MAC 学習 (Nexus, Cat6k など ) Cisco Public 7
Catalyst 3750-X と 3650 の挙動の違い (RACL の場合 抜粋 ) 3750-X, 15.2(2)E C3750X-04(config)#int Te1/1/1 C3750X-04(config-if)#ip access-group simple-acl-2k in %ACLMGR-4-UNLOADING: Unloading ACL input label 1 Te1/1/1, IPv4/Mac feature %ACLMGR-4-ACLTCAMFULL: ACL TCAM Full. Software Forwarding packets on Input label 1 on L3 L2 3650, 3.6.0E C3650-01(config)#int Te1/1/3 C3650-01(config-if)#do show platform tcam utilization asic 1 inc Security Access Security Access Control Entries 1536 184 C3650-01(config-if)#ip access-group simple-acl-1850 in %ACL_ERRMSG-4-UNLOADED: 1 fed: Input IPv4 L3 ACL on interface Te1/1/3 for label 4 on asic255 could not be programmed in hardware and traffic will be dropped. C3650-01(config-if)#do show platform tcam utilization asic 1 inc Security Access Security Access Control Entries 1536 184 RACL は効きますが ソフトウェア処理になります RACLのコンフィグは入りますが 効きません 黄色の部分は 制御パケットに対して という意味です ( 確認中 ) テーマその 1 Cisco Public 8
P.134 図 3.4 --- ACL が TCAM に書き込めている場合 テーマその 1 制御パケット / フレームに対する ACL はここで適用 TCAM ( 検索 ) ACL も適用 Cisco Public 9
ACL が TCAM に書き込めない場合の 3750-X と 3650 の挙動の違いの詳細 テーマその 1 制御パケットにはいずれも ACL が効く ACL 処理 Catalyst 3650 (3850 も同様 ) Catalyst 3750-X ACL 処理なし Cisco Public 10
TCAM に ACL を書き込まずに事前確認する機能があります Catalyst 6500/6800 Sup2T --- Dry Run (IPv4 RACL のみ ) Nexus 7000/7700 --- Session Manager Cat6k ACL Dry Run の例 Sup2T-VSS#configure session test1 Sup2T-VSS(dry-run-config)#ip access-list extended test-acl1 Sup2T-VSS(dr-config-ext-nacl)#permit ip host 1.1.32.1 host 2.2.33.1 ( 大量の RACL) Sup2T-VSS(dr-config-ext-nacl)#permit ip host 1.1.48.1 host 2.2.49.1 Sup2T-VSS(dr-config-ext-nacl)#exit Sup2T-VSS(dry-run-config)#validate Jan 16 11:39:57.653: %FM-6-SESSION_VALIDATION_RESULT_INFO: Session validation result: Validation Completed.. Please use 'show config session test1 status' for details. Sup2T-VSS(dry-run-config)#end Sup2T-VSS#show config session test1 status ==================================== Status of last config validation: Timestamp: 2014-01-16@11:39:57 ====================================== SLOT = [17] SLOT = [19] SLOT = [33] SLOT = [35] Sup2T-VSS# Result = Configuration will fit in TCAM. Result = Configuration will fit in TCAM. Result = Configuration will fit in TCAM. Result = Configuration will fit in TCAM. この構成には PFC と DFC が合計 4 個あるため RACL は 4 つの TCAM にそれぞれ書き込まれます Cisco Public 11
(ACL ではなく ルーティングテーブルと TCAM の話題です ) Cat6k FIB TCAM > 512K : Field Notice 63866 8 月に インターネットの IPv4 経路数 ( フルルート ) が 512,000 を超えました このため SUP720-3BXL 等を搭載した Catalyst 6500 や Cisco 7600で FIB TCAMが溢れ一部のパケット転送がソフトウェア処理になる現象が発生しました (FIB TCAMの合計容量 = 1M) FIB TCAM の割り当ては変更可能なので上記の現象は予防または回避できます Sup2T-XL Catalyst 6880-X (2M FIB), Nexus 7000 M1-XL, M2-XL モジュールでは挙動がどう異なるかの詳細を 現在調査中です デフォルト割り当てが 512,000 エントリ P.147 テーマその1 BGP Cisco Public 12
なぜ TCAM を使い続けるのか? テーマその 1 [ 終了 ] 性能 (Gbps) 19,200G ( 約 20Tbps) TCAM を用いたスイッチ ( 例 : Nexus 7718 F3 100G 最大構成 ) 複数機能を組み合わせても性能は一定 パケット / フレーム長が短くなる (pps が増大 ) 複数機能の併用 各種テーブルのエントリ増加 TCAM 容量の限界 80G ピーク性能 ソフトウェアベースのスイッチ ( ルータ ) Next Theme Cisco Public 13
[ その 2] STP 安定化技術を 実際に 発動 させてみる Catalyst & Nexus 共通難易度 2 ( 中 ) Cisco Public 14
STP 安定化技術 --- 何が難しいのか? 1. 発動させることが難しい場合がある そもそも想定外の状態に対処する機能なので正常時は動作しない エアバッグやブレーカのようなもの BPDU や他の制御フレームを選択的に かつ片方向だけ止められる構成を作り 想定外の状態 を意図的に作り出す必要あり エアバッグテーマその 2 (C) IIHS (iihs.org) 2. 種類が多すぎて覚えられない 実際に 発動 させられると 挙動が肌で分かるので 頭に残ります Catalyst を物理的に壊すわけではないので ご安心ください Cisco Public 15
P.280 表 7.1 STP 安定化技術の一覧 テーマその 2 この表に加えて - Dispute - BA (Bridge Assurance) が Cat6kとNexusでサポートされています (P.278-279) Dispute: BPDU が正常に届かず対向のポートが想定外の状態になった時に ポートをブロックする BA: BPDU を双方向に送受信することにより コントロールプレーン全体の障害などが原因で正常に STP が動作していない機器を認識し ループを防ぐ 実機で確認せずに 全部暗記するの大変です!!! Cisco Public 16
試してみよう --- 行きと帰り ( 上りと下り ) を分離する ( 光ファイバが必要 ) 選択的に制御フレームを止める 装置 スイッチ ( 同下 ) 選択的に制御フレームを止める 装置 テーマその 2 途中に何かが挟まっていることや 行きと帰りが分かれていることには気付かない ( 透過性 ) スイッチ Cisco Public 17
選択的に制御フレームを止める構成例 テーマその 2 Tx のみだと Link Up しないので Rx にもファイバをつなぐ speed nonegotiate (4 ポートとも 対向も ) Gi1/1/3 (Tx) (Rx) Gi1/1/4 (Tx) Gi1/1/1 (Rx) 3750-X + C3KX-NM-10G 15.2(2)E Gi1/1/1 (Rx) Gi1/1/1 を shutdown するだけで UDLD の試験が可能 Gi1/1/4 (Tx) 3750-X + C3KX-NM-10G 15.2(2)E (Rx) Gi1/1/3 (Tx) switchport mode dot1q-tunnel と L2 Protocol Tunnel を使用 止めたいプロトコルに対するコマンドを消す l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel point-to-point pagp l2protocol-tunnel point-to-point lacp l2protocol-tunnel point-to-point udld あくまでも試験用です TAC サポートはありません Cisco Public 18
実際に検証している様子 テーマその 2 [ 終了 ] Gi1/1/3 (Tx) (Rx) Gi1/1/4 (Tx) Gi1/1/1 (Rx) 3750-X + C3KX-NM-10G 15.2(2)E Gi1/1/1 (Rx) Gi1/1/4 (Tx) 3750-X + C3KX-NM-10G 15.2(2)E (Rx) Gi1/1/3 (Tx) あくまでも試験用です TAC サポートはありません Next Theme Cisco Public 19
検証結果の一部 -- Dispute 追加スライド BLK が誤って解除され BPDU が上向きに送信 Dispute 発生 正常状態 左のリンクの下りだけ BPDU が通らなくなる Cisco Public 20
検証結果の一部 -- BA 追加スライド 正常状態 双方向に BPDU が飛んでいる 左のリンク経由の下向きの BPDU が通らなくなる "BA Inconsistent" 発生 Cisco Public 21
[ その 3] FabricPath の高度なループ防止メカニズムと vpc+ Nexus 限定難易度 3 ( 高 ) Cisco Public 22
(2013 年 1 月の Webcast より ) テーマその 3 FabricPath: vpc+ とツリー ( 上り ) Broadcast も分散する VLAN ID CE Bridge (VLAN) SWID V100 FabricPath Routing Bridge V100 1 V100 2 V100 3 V100 4 Tree 1 Root Tree 2 Root Tree 1, 2 両方の枝 V100 11 V100 12 Tree 1 Tree 2 10 V100 (ES) Tree 1 Tree 2 V100 ES : Emulated Switch Cisco Public 23
(2013 年 1 月の Webcast より ) テーマその 3 FabricPath: vpc+ とツリー ( 上り ) Broadcast も分散するなぜ黄色と赤色の 2 本のTreeを Root 使い分けるのか? Tree 1 Root Tree 2 VLAN ID CE Bridge (VLAN) SWID V100 FabricPath Routing Bridge V100 1 V100 2 V100 3 V100 4 Tree 1 Tree 2 Tree 1, 2 両方の枝 その解説に先立って FabricPath (FP) の基本 vpc+ Tree について復習します V100 11 V100 12 10 V100 (ES) Tree 1 Tree 2 V100 ES : Emulated Switch Cisco Public 24
FabricPath の概要 (P.248) FabricPath ヘッダ SW102 SW101 FTag 他 B A VLAN DATA 入力側スイッチ SW101 SW101 SW102 マルチパス FabricPath(FP) 網 SW102 出力側スイッチ テーマその 3 レイヤ 3(IP) ルーティングの長所をレイヤ 2 に応用する マルチキャストの考え方も利用している (Tree の部分 ) B A DATA A B 従来の Ethernet (CE) A FabricPath 網内ではスパニングツリーは一切動作しない ホスト A と B は同じ VLAN に接続 従来の Ethernet B B A DATA A B Cisco Public 25
vpc+ とは何か (P.258 図 6.16 を単純化 ) テーマその 3 SW101 SW11 FP 非対応スイッチ SW103 ホストC 0. vpc+ を使用すると FP 非対応 スイッチを従来のイーサチャネル ( ポートチャネル ) でFP 網に接続できる SW12 A SW101? SW102? SW102 ホスト A 1. FP 非対応スイッチ配下のホスト A がホスト C 宛のフレームを送信する 2. 左側へ振り分けられると フレームは SW101 を経由して FP 網に入ってくる 3. ホスト C が接続している SW103 は ホスト A を SW101 とセットで学習する 4. 右側へ振り分けられると フレームは SW102 経由でホスト C に届く 5. SW103 では ホスト A が SW101 と SW102 のあいだでフラップしているように見えてしまう Cisco Public 26
Emulated Switch (ES) を導入し解決テーマその 3 物理構成 SW11 SW103 SW12 ホスト C 11 V10 103 12 ホスト C A SW100 論理構成 101 102 SW101 FP 非対応スイッチ SW102 ホスト A 100 V10 SW101 と 102 が 結託 して作り出した FP Routing Bridge ホスト A Cisco Public 27
Tree を用いてルーティングできないフレームを転送 (P.262) テーマその 3 11 V10 103 12 101 102 100 ホスト C A SW100 FP ルーティングテーブルを用いて転送 (Known Unicast) V10 103 11 12 101 102 100 ホスト C A ( 未学習 ) Tree 経由でフレームを届ける (Unknown Unicast, Broadcast, Multicast) V10 ホスト A V10 ホスト A Cisco Public 28
FP は Tree 経由の転送において 3 つの方法でループを防止する 1. リンクステート型ルーティングプロトコル (IS-IS) の利用 ネットワークの全体像を各スイッチが把握してからそれぞれが Tree を構築 2. TTL の減算 フレームの破棄 Tree 1 Root 3. RPF Check (Reverse Path Forwarding Check) IP マルチキャストでおなじみ --- ですよね? 11 12 101 102 100 V10 Tree 2 Root いずれも 従来の STP ( スパニングツリー ) には無い テーマその 3 Cisco Public 29
Tree 1 のみに着目 vpc+ 配下から Broadcast 等を受信した場合 Tree 1 Root e9/2 論理構成 11 e9/1 e9/3 12 101 102 SW100 SW102 SW11 の経路でフレーム (Broadcast 等 ) が転送されてきたら? 左右に振り分けているのは FP 非対応スイッチなので FP 側からは制御できない テーマその 3 100 V10 物理構成 FP 非対応スイッチ Cisco Public 30
Unicast Route と RPF インターフェイス 11 e9/1 e9/3 12 101 102 テーマその 3 e9/2 SW11# show fabricpath multicast trees ftag 1 SW11# show fabricpath route switchid 100 (ftag/1, topo/0, Switch-id 100), uptime: 00:2 ( 略 ) Outgoing interface list: (count: 1, '*' is t 1/100/0, number of next-hops: 2 * Interface Ethernet9/2, [RPF] [admin distan via Eth9/2, [115/400], 0 day/s 00:20:43, isis_fabricpath-default via Eth9/3, [115/400], 0 day/s 00:20:43, isis_fabricpath-default SW11 から見ると Unicast Routing Table では SW100 への経路は等コストのエントリ (e9/2, e9/3) が 2 つある (SW101-100, 102-100 のコストは 0) Tree 1 (FTag=1) 100 V10 SW11 の Tree 1 (FTag=1) においては SW100 に対する RPF インターフェイスは e9/2 のみ e9/3 に誤って着信した Tree 1 経由のフレームは破棄 Cisco Public 31
なぜ vpc+ では 2 本の Tree を使い分けるのか SW100 から SW101 と 102 の両方を経由してフレーム (Broadcast 等 ) が SW11 に着信する もし Tree が 1 本しか無いと RPF インターフェイスは 1 つなので 片方しか RPF Check が成功しない ( 反対側は常に失敗 ) 対策 : Tree を 2 本に分けて RPF インターフェイスを 1 つに限定する e9/2 11 12 101 102 Tree 1 (FTag=1) e9/1 e9/3 100 V10 テーマその 3 Cisco Public 32
Tree を 2 本にすることで RPF Check も大丈夫テーマその 3 [ 終了 ] Tree 1 Root Tree 1 と Tree 2 で RPF インターフェイスが分けられる 11 e9/1 e9/2 e9/3 12 Tree 2 Root Tree 1 : SW12 e9/1 SW101と100 e9/2 SW102 e9/3 Tree 2 : SW12 e9/1 SW101と100 e9/1 SW102 e9/1 101 102 100 V10 2013 年 1 月の Webcast でご説明した赤色と黄色の 2 本の Tree には このような背景がありました Next Theme Cisco Public 33
vpc+ の下りは Designated Forwarder (DF) で制御 追加スライド 物理構成 101 102 Po10 Po20 Po30 100 V10 論理構成 Po10 下りのフレームが重複しないために vpc+ 毎 (10,20,30) に一方だけが転送する DF により実現 Po20 Po30 Cisco Public 34
vpc+ の下りは Designated Forwarder (DF) で制御 Tree 1 Tree 2 Tree 1 Tree 2 Tree 1 Po10, Po30 に対して DF 追加スライド Tree 2 Po20 に対して DF Po10 Po20 Po30 下りは vpc+ の両方の Peer にそれぞれ着信する 両方の Peer が下へ転送するとフレームが重複 DF だけが転送 Po10 Po20 Po30 vpc+ の状態 Partial: Tree 1 か 2 の一方に対して DF Full: Tree 1 と 2 の両方に対して DF None: DF ではない vpc+ のメンバがダウンすると Po 毎にDFが変わる Cisco Public 35
[ その 4] HSRP Preempt 使用時に 再起動の際のパケットロスを防ぐには Catalyst & Nexus 共通 (Nexus 分多め ) 難易度 2 ( 中 ) Cisco Public 36
ご回答 テーマその 4 HSRP Preempt は もし明確な理由がないのであれば 使用しない方が楽です ( プレゼンタ個人の見解です ) もし どうしても Preempt を使わなければならない のであれば "preempt delay reload < 秒 >" コマンドを利用することにより スイッチ再起動時に指定された時間だけ待ってから Active に昇格します (Catalyst Nexus 共通 ) ただし SVI に HSRP Preempt を設定する場合には 再起動時に SVI の Up や HSRP Hello の受信開始が遅くなり タイマーの調整が必要になることがあります STP Forwarding 状態への遷移の遅れ モジュール型機種で ラインカード / モジュールの初期化に時間が必要な場合 P.268 FabricPath の拡張機能 による別のソリューションを紹介します Cisco Public 37
FP Anycast HSRP を利用すると (P.268, 269) テーマその 4 4 台が全て Active Gateway として動作する 4 台いずれも SW40 (AS) を兼任している L3 網 SW1 VLAN 100 HSRPv2 仮想ルータ MAC 0000.0c9f.f064 SW2 L3 網 Gateway 経由で L3 網へ抜けるトラフィック Anycast Aware L3 網 SW3 e1/1-4 SW40 FP 網 Anycast Switch (AS) SW4 L3 網 Anycast Capable Cisco Public 38
FP Anycast HSRP + Overload Bit (P.270) テーマその 4 Overload Bit がセットされているあいだ 自分が Gateway ではないと 周囲に通知し続ける L3 網 SW1 SW2 は SW40 との一人二役状態をすぐには再開しない SW2 L3 網 再起動 Gateway 経由で L3 網へ抜けるトラフィック Anycast Aware L3 網 SW3 e1/1-4 SW40 FP 網 # fabricpath domain default # set-overload-bit on-startup < 秒 > L3 側が安定するまでセット SW4 L3 網 トラフィックは残りの 3 台に分散 Anycast Capable Cisco Public 39
FP Anycast HSRP の地味な長所テーマその 4 [ 終了 ] 2 台や 3 台でも構成可能 障害発生時に Standby が Active に昇格するのではなく Active x 4 台が 3 台に縮退するので 切り替わりが非常に速い FabricPath ルーティングの収束が早いため HSRP Timer をチューニング (e.g. 250msec / 750msec) する必要がない 例えばホストが 100 台あって デフォルトゲートウェイを均等に分散して使用していれば 25 台だけが影響を受ける 再起動後の切り戻りの時も 同じ 25 台が復旧したデフォルトゲートウェイを使うようになり 残りの 75 台には影響がない Overload Bit は 起動時以外にも必要に応じて On/Off できるので トラフィックへの影響を最小限にしてメンテナンスや構成変更が可能 # fabricpath domain default # set-overload-bit always # no set-overload-bit always End of Theme Cisco Public 40
お疲れさまでした! 以上で ご用意した 4 つの話題に関するご説明は終了です それでは これからご質問をお受けします 可能な限りこの場で回答します が 即答できない場合は 質問箱 で後日お答えします 最後に 受講者プレゼントについてのお知らせがあります Cisco Public 41
Thank you.