カスタマーサクセスでは、ACIを運用されているエンドユーザー様同士の交流の場として、サクセスコミュニティ（ユーザー会）を定期的に開催しており、これまで多くのお客様にご参加頂いています。
ユーザ会の一番のポイントは、ユーザー様同士のコミュニケーションが図れる点です。ACI運用の問題点や課題、日頃感じている不満や、こんなことできますよといった事例紹介など、色々なテーマでコミュニケーション頂けます。
第５回の記事はこちら
第8回
- 日時： 2024 年 7 月 26 日（金）14:00 〜 17:30
- 第１部： ラーニングセッション
- 内容：
- ACIの使い方をセキュリティ、アーキテクチャーの観点から改めて考えてみる
- Nexus Dashboard Insightsの利用方法をご紹介
ACIのセキュリティを実装する機能紹介、アーキテクチャー、NDIについての利用方法についてデモを通じてご理解頂くセッションです。
・テーマ１ 「⾼いセキュリティと運用負荷低減の両得を目指すACIのポイント（45 min）」
データセンターにおけるセキュリティの担保は必須項目であり、ACIを導入する理由の一つになっていると思います。ただし、あまりにも機密性の⾼いセキュリティ実装を目指したがゆえに、運用負荷が⾼くなりすぎてしまった、また逆に、構築後に、新しいルールとして、ファイアウォールやセキュリティデバイスを配置したいといった要件が出てくることもあると思います。ACIは、一度構築した後でも柔軟にNWを変更することができるのがメリットであり、細かくし過ぎてしまったゾーニングルールを少し緩和する、とあるサーバーだけマイクロセグメンテーションで分離するといった柔軟な変更を行うことが可能です。ケーススタディを通して、このようなACIのカスタマイズを行う方法について理解頂けます。（資料は、下に添付）
・テーマ２ 「おさらいするACIアーキテクチャー ～ VXLAN-EVPNファブリックと何が違う？～ （30 min）」
ACIは独自実装のアーキテクチャーを採用していますが、標準のVXLAN EPVNをベースにしています。改めて、ACIとVXLAN EPVNのアーキテクチャー、プロトコルの違いを説明します。CiscoのデータセンターネットワークコントローラであるAPICとNDFCによる実装の違いも簡単にご紹介します。（資料は、下に添付）
・テーマ３ 「この障害、NDIならこんなに簡単に対応できる (45min)」
Nexus Dashboard Insightsを使って、トラブルシューティングを行う実践例をご紹介します。Contractドロップ、IPアドレスの重複、バーストトラフィック発生によるインターフェースでQueue Drop、外部ネットワークにおける再送発生などの事例において、NDIを使用する事でどのようにトラブルシューティングが行えるかをデモを通じて学習できます。このセッションに参加すれば、NDIを気に入ってくださること間違いなしです。
- 第２部：質問タイム＆意見交換会
- 第２部では、参加者各社様における質問や意見交換が活発に行われました。第一部の質問内容や、その他機能に関するディスカッションが行われました。
- 質疑
- vzAnyはL3outのExtEPGにも作用しますか？
- はい。同一VRF内のApplication EPG、External EPGに作用します。
- 「ある通信について、上り方向が発生しているが、そのACK・戻りの通信が返ってきていないようだ」という類のものをanormalyとして検知できますか？
- Ackが返ってこず、再送をした場合はACI内部、外部を問わずNDIで検知が可能です。ただし、ACI自体がドロップした情報と異なり細かい情報は取得できません。
- NDIデモでは手動で特定のフローに対して分析を実行されていましたが、実際の使い様としては、「発生している通信のフロー情報を保存・蓄積しているので、その情報をもとに、調子悪いものがないか”自動”で分析して、あればanoromalyとしてあげる」という動作イメージで理解正しいですか？
- デモで見せていただいたフロー分析は、実際に通信が発生していない状況で、定義をもとにチェックする、といった形は可能ですか？
-
Connectivity Analysis は、実際にフローが流れているときに効果のあるツールになります。フローが発生していない状況では、NDI の Explorer 機能を使うと便利です。
Explorer を使うと「どの Endpoint やEPGが」「どこへ」通信できるかを調べることができます。この機能は NDI が APIC から定期的に収集している snapshot を元に結果を出しますので、最新の情報だけでなく過去の時点での状況も確認できます。
ただし、こちらはあくまで定義上の動作使用になっていて、Endpoint TableやRouting Tableの状況によっては実際の環境とは異なるケースは発生する可能性があります。
- ESGについて、EPGのサブネットの単位でZoningルールをリーフに展開するため、TCAM消費を抑えられない、設定の簡素化を実現するだけのもの、という理解で正しいですか。
- EPGからESGに置き換えられると、その時点でpcTagがEPGからESGのものに置き換わります。なので、Contractの精査の結果、ESG-ESGのルールしか最終的になくなるのであれば、TCAM消費は抑えられることになります。
- Zoningの状況について、以前別の資料を見たときに、「ingress側のリーフにのみ存在」「egress側には存在しない」という内容で理解をしました。ただし、実際にはEndpointの学習状況だったり、片方がL3outだったり、ケースによって異なるものと想像していますが、ロジックがあるのでしょうか？
-
基本は、IngressでSecurity EnforcementをやるのがACIの基本ロジックです。
1.EPG-EPG間
・Ingress Leafが宛先の端末のEPG情報を知っていれば（Endpoint学習していれば）IngressでEnforcement実施。知らなければ、VXLAN のタグに送信元EPG情報を載せてEgressでEnforcement実施。
2. External EPG - EPG
・VRFにEnforcementを指定する項目があります。デフォルトはingressになっていて、その場合は厳密にはingressではなくBorder Leafではない、通常LeafでEnforcementが実行されます。Border LeafにはZoning Ruleが展開されません。
- EPGをESGに加えるとき、外すときに通信断は発生する可能性ありますか？
- 知覚できるほどの断は発生しないと思いますが、EPGとESGではpcTagが異なるので、その付け替えのタイミングで瞬断等が発生する可能性はゼロではないと思います。また、EPGとESGで異なるContractが適用されている場合などは注意が必要だと思います。
- ディスカッション
- セキュリティ機能の利用状況のアンケート結果の共有
- Dynamic EPG Classificationの実用例のディスカッション
- DECのEIGRPの採用計画はあるか？ ⇒ 現状プランとしては無いようです。
- PBR（Policy Based RoutingとPolicy Based Redirect）の名前が似ている
- ACIのラーニングや、ドキュメントの整理がなされるとより学習コストが下がる
- 当日のセッション内容に関して、ご質問や今後のACIサクセスコミュニティで取り扱ってほしい内容などありましたら、本記事の返信でコメントください。
次回は 2025年 初旬開催を予定しています。他のユーザ様と交流できる貴重な機会ですので、ご興味がありましたらぜひご参加ください。
