Cisco ACI における Contract の基本を理解する
今回は Cisco ACI で通信制御に用いる Contract の基本的概念について説明します。 誤っている箇所があればコメント欄等でご指摘頂けると大変、有り難いです。
前提¶
今回の説明は以下を前提にしています。
- お読み頂く方が EPG の基本的な概念を理解していること
- Application EPG 間の Contract 設定を想定
Contract ＝「EPG 同士を接続する概念」¶
Contract とは「EPG 同士を接続する概念」です。 ですから、一般的には「EPG と EPG の間に挟み込む」ような形で設定することで効果を発揮します (vzAny と呼ばれる、個々の EPG では無く VRF 全体に適用する設定方法もあります)。
Contract に以下のような設定を施すことで、接続した EPG 間の通信を制御することが出来ます。
- 通信の許可 (Contract)
- 通信の拒否 (Taboo)
- QoS
- リダイレクト
- ServiceGraph
基本的に Contract で接続されていない EPG 間は通信することが出来ません (但し VRF の Policy Control Enforcement Preference を Unenforced に設定している場合は Contract が無くても通信が可能です。 詳しくは後述します)。 「通信の許可設定を行う」というのが、最も多い Contract の使い方だと思います。
ServiceGraph は外部デバイスとの連携機能のことですが、詳細は別の機会に書いてみたいと思います。
「向き」の概念¶
Contract には「向き」(方向) の概念があります。 ACI の用語では Consumer や Provider と表現します。 ACI の GUI 画面上で Contract を選択すると EPG と Contract の接続関係が以下のような矢印で表示されます (Provider から Consumer へ伸びる矢印で表現されます。後述しますが、実際のトラフィックとは矢印の向きが逆です)
Consumer や Provider は、従来の用語である Source と Destination に置き換えて理解すると分かりやすいと思います。
| ACI の用語 | 従来の用語 | 備考 |
|---|---|---|
| Consumer | Source | クライアント側 (送信側) |
| Provider | Destination | サーバ側 (宛先側) |
備考欄で「宛先側」を「サーバ」と書いていますが、例えばサーバが名前解決をする場合、その瞬間サーバは「クライアント」と考える必要があります。 つまり、「サーバは常に Provider」と捉えるのでは無く、「サーバであっても自発トラフィックを発生させる瞬間はクライアントである」「クライアントであってもトラフィックを Listen する瞬間があれば、サーバである」と理解して Contract の向きを設定していく必要があります。
尚、実際のトラフィックは以下のように、GUI 上の Consumer / Provider の矢印とは逆向きになります。
Contract の構造¶
Contract は以下の 3 つの概念から構成されます。 Contract は Subject を含み、Subject は Filter を含みます。
- Contract
- Subject
- Filter
- Subject
図示すると以下のようになります。
Contract : Subject : Filter を個数の観点から見た場合、以下のように表現出来ます。
- Contract の中には複数の Subject を含めることが出来る (1 つでも良い)
- Subject の中には複数の Filter を含めることが出来る (1 つでも良い)
Subject とは¶
Subject とは「Filter を収容する入れ物」のような概念です。 以下の場合を考えてみます。
- Contract を定義する
- Contract 内には、ひとつの Subject を定義する
- Subject 内には、以下 3 つの Filter を定義する
- HTTP
- HTTPS
- ICMPv4
この設定を図示すると、以下のようになります。
これを複数の Subject に分割し、以下のように設定することも可能です。 この場合は単純に Subject を分割しただけであり、全体で見れば設定されている Filter の内容は同じである為、Contract 全体としての制御は変わりません (＝同じ結果になります)。 どちらの場合も「HTTP、HTTPS、ICMPv4 を許可する」という振る舞いをします。
Subject を分割するのは以下のような場合が考えられると思います。
- プロトコル毎に Subject を分割する
- 「Web Subject には HTTP と HTTPS」「ICMP Subject には ICMPv4 と ICMPv6」のように、プロトコル毎に Subject を分割する
- 管理上、見通しが良くなる (場合がある)
- 合計した Filter が同じであれば「Subject を分割する | しない」に関わらず、Contract 全体としての機能は同じ
- Label と組み合わせて設定する
- Subject 毎に Label を設定する
- EPG にも Label を設定する
- 同じ Label が設定された Subject / EPG のみ、Filter の効果を受ける
- 従って「同一の Contract に接続しているものの、限定された EPG にだけ特定の Filter を適用したい」という場合に用いる
Label を用いた通信制御については別途、記事を書いてみたいと思います。
Filter とは¶
Filter とは「一致させる通信のプロトコルやポートを定義する」概念です。 実際には Filter は単体だけでは無く、Contract または Taboo と組み合わせて利用します。 各々、組み合わせによって以下のような効果があります。
| 組み合わせ | どういった制御になるか？ |
|---|---|
| Contract と組み合わせた場合 | 一致する通信を 許可する |
| Taboo と組み合わせた場合 | 一致する通信を 拒否する |
「Filter ＝ 許可する通信を書く」と思い込んでいるケースを見たことがあるのですが、Filter は組み合わせる対象によって「許可」「拒否」のどちらになるのか、効果が変わります。 つまり、Permit_ICMP のような名前で Filter を作成してしまうと Taboo では (名称的に) 使いづらくなってしまいます。
Filter は common Tenant に設定し、各 Tenant から参照させることも可能です。 「Web (HTTP と HTTPS)」や「ICMP」、「Any」といった『頻繁に使う、有り触れたルール』は common Tenant に作成することで、各 Tenant で設定する手間が省けます。
従来の ACL 設定と比較してみる¶
例として「HTTP、HTTPS、ICMPv4 を許可する Filter を設定してみた」場合の設定を図示すると以下のようになります。
従来の ACL 設定と比較した場合、要点は以下です。
- EPG
- Source Address が Consumer EPG に該当
- Destination Address が Provider EPG に該当
- Subject
- ACL (Access Control List) の定義そのものに該当
- Filter
- ACE (Access Control Entry) に該当
- 具体的には
permit tcp 〜 eq 80やpermit icmpといった、一致させる通信の定義部分が該当
Filter で許可された通信¶
Filter で定義されていれば通信は許可されます。 以下の図では ICMPv4 のトラフィックを流しています。 これは Filter で定義されているので通信は許可されます。
Filter で許可されていない通信¶
トラフィックが Filter で 定義されていない 場合、通信は拒否されます。 以下の図では DNS のトラフィックを流しています。 これは Filter で 定義されていない ので通信は拒否されます。
