らくがきちょう

なんとなく

Cisco ACI における Contract の基本を理解する

今回は Cisco ACI で通信制御に用いる Contract の基本的概念について説明します。 誤っている箇所があればコメント欄等でご指摘頂けると大変、有り難いです。

前提

今回の説明は以下を前提にしています。

  • お読み頂く方が EPG の基本的な概念を理解していること
  • Application EPG 間の Contract 設定を想定

Contract =「EPG 同士を接続する概念」

Contract とは「EPG 同士を接続する概念」です。 ですから、一般的には「EPGEPG の間に挟み込む」ような形で設定することで効果を発揮します (vzAny と呼ばれる、個々の EPG では無く VRF 全体に適用する設定方法もあります)。

f:id:sig9:20170708172428p:plain

Contract に以下のような設定を施すことで、接続した EPG 間の通信を制御することが出来ます。

  • 通信の許可 (Contract)
  • 通信の拒否 (Taboo)
  • QoS
  • リダイレクト
  • ServiceGraph

基本的に Contract で接続されていない EPG 間は通信することが出来ません (但し VRF の Policy Control Enforcement PreferenceUnenforced に設定している場合は Contract が無くても通信が可能です。 詳しくは後述します)。 「通信の許可設定を行う」というのが、最も多い Contract の使い方だと思います。

ServiceGraph は外部デバイスとの連携機能のことですが、詳細は別の機会に書いてみたいと思います。

「向き」の概念

Contract には「向き」(方向) の概念があります。 ACI の用語では Consumer や Provider と表現します。 ACI の GUI 画面上で Contract を選択すると EPG と Contract の接続関係が以下のような矢印で表示されます (Provider から Consumer へ伸びる矢印で表現されます。後述しますが、実際のトラフィックとは矢印の向きが逆です)

f:id:sig9:20170708172436p:plain

Consumer や Provider は、従来の用語である Source と Destination に置き換えて理解すると分かりやすいと思います。

ACI の用語 従来の用語 備考
Consumer Source クライアント側 (送信側)
Provider Destination サーバ側 (宛先側)

備考欄で「宛先側」を「サーバ」と書いていますが、例えばサーバが名前解決をする場合、その瞬間サーバは「クライアント」と考える必要があります。 つまり、「サーバは常に Provider」と捉えるのでは無く、「サーバであっても自発トラフィックを発生させる瞬間はクライアントである」「クライアントであってもトラフィックを Listen する瞬間があれば、サーバである」と理解して Contract の向きを設定していく必要があります。

尚、実際のトラフィックは以下のように、GUI 上の Consumer / Provider の矢印とは逆向きになります。

f:id:sig9:20170708172445p:plain

Contract の構造

Contract は以下の 3 つの概念から構成されます。 Contract は Subject を含み、Subject は Filter を含みます。

  • Contract
    • Subject
      • Filter

図示すると以下のようになります。

f:id:sig9:20170708172459p:plain

Contract : Subject : Filter を個数の観点から見た場合、以下のように表現出来ます。

  • Contract の中には複数の Subject を含めることが出来る (1 つでも良い)
  • Subject の中には複数の Filter を含めることが出来る (1 つでも良い)

Subject とは

Subject とは「Filter を収容する入れ物」のような概念です。 以下の場合を考えてみます。

  1. Contract を定義する
  2. Contract 内には、ひとつの Subject を定義する
  3. Subject 内には、以下 3 つの Filter を定義する
    1. HTTP
    2. HTTPS
    3. ICMPv4

この設定を図示すると、以下のようになります。

f:id:sig9:20170709000859p:plain

これを複数の Subject に分割し、以下のように設定することも可能です。 この場合は単純に Subject を分割しただけであり、全体で見れば設定されている Filter の内容は同じである為、Contract 全体としての制御は変わりません (=同じ結果になります)。 どちらの場合も「HTTP、HTTPS、ICMPv4 を許可する」という振る舞いをします。

f:id:sig9:20170709000908p:plain

Subject を分割するのは以下のような場合が考えられると思います。

  1. プロトコル毎に Subject を分割する
    • 「Web Subject には HTTP と HTTPS」「ICMP Subject には ICMPv4 と ICMPv6」のように、プロトコル毎に Subject を分割する
    • 管理上、見通しが良くなる (場合がある)
    • 合計した Filter が同じであれば「Subject を分割する | しない」に関わらず、Contract 全体としての機能は同じ
  2. 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 を設定してみた」場合の設定を図示すると以下のようになります。

f:id:sig9:20170708172512p:plain

従来の ACL 設定と比較した場合、要点は以下です。

  1. EPG
    • Source Address が Consumer EPG に該当
    • Destination Address が Provider EPG に該当
  2. Subject
    • ACL (Access Control List) の定義そのものに該当
  3. Filter
    • ACE (Access Control Entry) に該当
    • 具体的には permit tcp 〜 eq 80permit icmp といった、一致させる通信の定義部分が該当

Filter で許可された通信

Filter で定義されていれば通信は許可されます。 以下の図では ICMPv4 のトラフィックを流しています。 これは Filter で定義されているので通信は許可されます。

f:id:sig9:20170708172523p:plain

Filter で許可されていない通信

トラフィックが Filter で 定義されていない 場合、通信は拒否されます。 以下の図では DNSトラフィックを流しています。 これは Filter で 定義されていない ので通信は拒否されます。

f:id:sig9:20170708181230p:plain