#CiscoACI Endpoint学習と通信の仕組み

Takao Setaka @twtko

#CiscoACI のLeaf-Spine間で用いられているVXLANは”iVXLAN”と呼ばれます。VXLANヘッダには予約領域があるため、ACIではその領域を活用し「ポリシーを送信元・送信先どちらで適用したのかのフラグ」や「送信元EPGを示すタグ(pcTag)」などが含められています。 pic.twitter.com/BQfWd2idxs

拡大

Takao Setaka @twtko

#CiscoACI で使われるiVXLANに送信元EPGを示すpcTagを含めている理由はVRF/Bridge Domain/Subnetなどのネットワーク的なパラメータと分離してセキュリティ定義を可能とするためです。VXLANのVNIDはL2VNIにしろL3VNIにしろネットワークに紐付くため、ネットワークに依存しないタグが識別には必要です。 pic.twitter.com/BOgo2iXw4x

拡大

Takao Setaka @twtko

#CiscoACI のファブリック内では従来のLPMではなくEndpoint Databaseによって全ての接続デバイスの存在が管理されています。1つのEndpoint Tableには、必ず1つのMACアドレスが含まれ、必要に応じて1つもしくはそれ以上のIPアドレスが紐づけて管理されます。 pic.twitter.com/1mDZuehLCT

拡大

Takao Setaka @twtko

#CiscoACI の学習動作は、基本的に内部はEndpoint Table、外部はARPとLPMに基づくIP Route Tableですが、IPの学習が不要な対象についてはMACアドレスのみの学習を行いますし、外部との接続においては対向側で一切の特別な対応の必要がない、標準化された仕様に基づいたL2/L3接続が可能です。 pic.twitter.com/cKkEHDv4si

拡大

Takao Setaka @twtko

#CiscoACI でUnknown L2 Unicast通信がHardware Proxy構成で行われる場合、送信元Endpointの接続先Leafで宛先Endpointが存在するLeafが不明の場合Spine全台が共通して持つAnycast MAC Proxy VTEP宛に転送されます。Spineは全EndpointのTableを保持しているため宛先EndpointのあるLeafに再転送します。 pic.twitter.com/Pz1fCr0TEV

拡大

Takao Setaka @twtko

#CiscoACI でUnkown L2 Unicast通信がL2 Flood構成で行われる場合、送信元Endpoint接続先Leafで宛先Endpointが存在するLeafが不明の場合当該BDのVNIDをVXLANヘッダにセットしたGIPo宛でFlood flameを送信、Spineは当該BDが構成されているLeafに転送、各Leafは当該BD範囲でL2 flameをFloodingします。 pic.twitter.com/295fbb3pwM

拡大

Takao Setaka @twtko

#CiscoACI のL2 Unicast通信において宛先Endpointが存在するLeafを送信元Endpointが接続しているLeafがキャッシュしていた場合には、VXLANの送信先は直接当該Leaf宛となります。この仕組みにより、Spine側でのEndpoint TableのLookup処理は必要最小限となり、ポリシーの適用も送信側で可能となります。 pic.twitter.com/CqDYEkokZX

拡大

Takao Setaka @twtko

#CiscoACI でL3 Unicast通信を行う場合も、基本的にはL2 Unicastの場合と同様です。宛先Leafを送信元Leafが把握している場合、SpineのProxy VTEPを介した処理も不要ですし、送信元Leaf側でポリシーを適用をしてしまえるので、ポリシーに合致していなければ無駄な転送処理は行われません。 pic.twitter.com/UBicQCunvL

拡大

Takao Setaka @twtko

#CiscoACI でARPによる宛先EndpointのIPアドレス確認が行われた場合、送信元Leafで宛先IPが存在するLeafが不明の場合にはIPv4 / IPv6それぞれに用意されているSpineのAnycast Proxy VTEP宛に転送、Spineも情報を持っていない場合は特別なGleanパケットを全Leafに送りGARPによる存在確認が行われます。 pic.twitter.com/cFhGkgmsUg

拡大

Takao Setaka @twtko

#CiscoACI のContractはService Graphを使わなければACLと大差ないように思えるかもしれませんが、適用先が物理ポート・IP/MACアドレス・サブネットなどに直接紐付くACLとは異なり論理的なグループであるEPGであること、そしてEPGとは分離して定義できることで大幅に柔軟性と管理性が向上しています。 pic.twitter.com/QN1qrIG8sB

拡大

Takao Setaka @twtko

#CiscoACI のContractは「どこで適用するのか」についても柔軟性を持っています。送信元・送信先両方のEPGを送信元Leafの段階で判定できるならば送信元の時点で適用すればいいですし、識別できないのであれば送信先の時点で適用すれば良いのです。ポート・IP/MAC・サブネットなどは関係ありません。 pic.twitter.com/MyjbQ0ovlA

拡大

Takao Setaka @twtko

#CiscoACI のContractには適用範囲を定義するScopeというパラメータがあります。デフォルトはVRFとなっており、同一VRF範囲であればApplication Profileが異なるEPG間に対しても有効ですし、GlobalとすればTenantを跨いで利用することも可能となります。 pic.twitter.com/GgffNLNtWM

拡大

Takao Setaka @twtko

#CiscoACI のContractはConsume(消費)とProvide(供給)の方向性と組み合わせてEPGに対してマッピングします。ContractをConsumeしたEPGから、ProvideしたEPGに対して、Contractで定義された通信ルールに基づく通信が可能となります。複数のProvide EPG・Consume EPGを1つのContractに定義できます。 pic.twitter.com/o85m4rpxCo

拡大

Takao Setaka @twtko

#CiscoACI のContractはstatelessなフィルタですが、行きと戻りのフィルタを個別に定義することもできますし、行きに対する戻りは自動的に定義される指定とすることも可能です。 pic.twitter.com/e0QoRFYryX

拡大

Takao Setaka @twtko

#CiscoACI のContractは、デフォルトでは[Apply Both Directions]と[Reverse Filter Ports]が有効となっており、行き方向のフィルタルールを定義すると、自動的に逆方向で逆向きの戻り用フィルタルールが自動的に適用されます。 pic.twitter.com/7aTyVbfTZd

拡大

Takao Setaka @twtko

#CiscoACI のContract定義は、最終的には各LeafのPolicy CAMにプログラミングされることによってHardware処理されます。TCAMリソースは有限ですので、Contractの使い方や定義の仕方によって効率性に差が出ますので、大量の定義を行う際には注意が必要です。 pic.twitter.com/Tp3KuBEmoo

拡大

Takao Setaka @twtko

#CiscoACI のContractにおいて、例えば送信元ポート範囲を”1-65535”と定義するか、範囲を定義しない”Unspecified”を利用するかだけで、TCAMリソースの消費量は全く違ってきます。APICのWeb UIやNetwork Assurance Engine ( #CiscoNAE )を利用することでTCAM消費量を確認することが可能です。 pic.twitter.com/TN6LRbU57T

拡大

Takao Setaka @twtko

#CiscoACI のContractをVRF範囲全体に対して適用するのであれば、vzAnyを利用することが可能です。個別EPG間に定義されたContractの方が優先されます。vzAnyを上手く使えばTCAMリソースの消費量を劇的に下げることができます。 pic.twitter.com/LMAFHIjB8r

拡大

Takao Setaka @twtko

#CiscoACI でどのL3outに対してどの内部経路を広告するのか管理する手法として、BDに紐づけることで構成することができましたが、現在では一部の範囲除外等のより柔軟な経路制御のこうせいが可能となるL3out側のRoute Mapを用いた構成方法の利用が推奨されています。 pic.twitter.com/b2qH88mkof

拡大

Takao Setaka @twtko

#CiscoACI は提供を開始してから早5年が経過しました。ACIはネットワークソリューションですが、目的はアプリケーションを構成するコンピューティング要素に対して接続性を適切に管理・提供することにあります。ACIではVLANやSubnetに依存しないEnd Point Group (EPG)という仕組みこそがその根幹です。 pic.twitter.com/UjHJf4HEmm

拡大

Takao Setaka @twtko

EPGと対をなして #CiscoACI をアプリケーションのためのネットワークたらしめているのが、Contractです。EPG間の通信ルールを定めるContractはACL的な役割だけではなく、L4-L7との連携やQoSなど、接続性に関係するポリシーを体現している要素がこのContractであるといえます。 pic.twitter.com/2h7gnrhQPH

拡大

Takao Setaka @twtko

VXLANを単なるOverlayとしてしか使っていない他のSDNに対して、 #CiscoACI ではACI Fabric内の通信の識別のためだけではなく、ポリシーの適用ステータスを示すフラグや、EPGを示すClass IDを付加するなど、未定義部分として確保されているVXLANのヘッダ範囲を活用した仕組みが提供されています。 pic.twitter.com/U0YULEuGTp

拡大

Takao Setaka @twtko

VRF範囲全体で共通の通信ルールがあるのであれば、一括してそのルールを全てのEPGに透過的に適用することができるvzAny (EPG Collection for VRF)という仕組みが用意されています。vzAnyに対して紐付けられたContractは自動的にVRF範囲の全EPG/L3outに適用されたものとして扱われます。 pic.twitter.com/pWFBkWiruz

拡大

Takao Setaka @twtko

EPG-Aと同じポリシー+独自ポリシーを提供したいEPGがあるのであれば、EPG-Aのポリシーを継承することができるContract Inheritance機能が提供されています。EPG-AとEPG-Bの2つの親EPGを構成することなども可能です。特にVM情報などに基づいて分類するuSeg EPG等と組み合わせてご活用頂けるでしょう。 pic.twitter.com/C5jd5Z6NJX

拡大