#CiscoACI Multi-Site Architecture and Deployment

Takao Setaka @twtko

BRKACI-2125 “ACI Multi-Site Architecture and Deployment”は、ステキなイタリアン英語!?で解説される #CiscoACI Multi-SiteについてのDeep Diveセッションです。Multi-Podと異なりMulti-Siteは完全に自立したAZとなる各サイトを統合したポリシー管理とL2/L3接続性を実現します。 pic.twitter.com/WXAAiSSn3y

拡大

Takao Setaka @twtko

#CiscoACI Multi-Siteは、必ずしも遠隔拠点を結ぶためだけのソリューションではありません。たとえば、同一拠点であったとしても非常に大規模なNetwork Fabricを統合管理すると共に一部ネットワークは横断的に接続したい場合などにもご利用頂くことが可能です。 pic.twitter.com/xkk5sW2jzN

拡大

Takao Setaka @twtko

#CiscoACI Multi-Siteの場合、各サイト毎に独立したAPICクラスタがあるわけですが、サイトを超えてEPG間をContractで結びつける仕組みを実現するためにMulti-Site Controller (MSC) はサイトを超えたContract接続を必要とするEPGを各APICにダミー的に複製したMirrored EPGを構成します。 pic.twitter.com/veP1lyU1Pn

拡大

Takao Setaka @twtko

#CiscoACI Multi-SiteはACI 3.0からサポートされています(9364Cは3.1以降)。全Leafモデルをご利用頂けますが、Spineについては第2世代以降が必要となります。ただし、Fabricを構成するSpineとしては第1世代を含めたままでMulti-Siteを構成することは問題ありません(第2世代LeafのみMulti-Site接続)。 pic.twitter.com/s70KJgJrCv

拡大

Takao Setaka @twtko

#CiscoACI Multi-Siteでは当然サイト毎にコントローラ(APIC)が存在するため、サイト毎に異なるVXLAN ID (VNID)やEPGを識別するためのClass-IDをマッピングして結びつける必要があります。ACIのMulti-Site構成においては、サイト間接続の出入口となるSpineにおいて紐付けと変換が行われます。 pic.twitter.com/a5XkDfw5IJ

拡大

Takao Setaka @twtko

#CiscoACI Multi-Siteには、ポリシー共通化とネットワーク延伸の2つが含まれています。ネットワークとしては、L3接続のみのパターン、DRサイトとしてBUMトラフィック転送は不要なL2接続のパターン、そしてActive/Active運用が可能となるBUMトラフィック転送も含むL2延伸パターンいずれも構成可能です。 pic.twitter.com/hUy1pBVADz

拡大

Takao Setaka @twtko

#CiscoACI Multi-Siteのスケーラビリティは単一サイトのスケーラビリティとは別に定められています。Multi-Siteのスケーラビリティは、各サイトのローカルなスケーラビリティとは無関係にサイトをまたいで構成する要素の数としてサイジング頂くことが可能です。これら全ての数値は公開されています。 pic.twitter.com/5gZTqfjHyK

拡大

Takao Setaka @twtko

#CiscoACI Multi-Siteのスケーラビリティはソフトウェアとしての制限というよりも、単なる検証済スケーラビリティとしてサポートする範囲を意味しています。よって、検証が進めば当然ながらサポートされるスケーラビリティは拡大されていきます。 pic.twitter.com/z64CwxH4Ew

拡大

Takao Setaka @twtko

#CiscoACI Multi-Siteでは、ACI 3.2よりSpine間でのBack-to-Back接続構成もサポートされています(現時点では2サイト構成のみ)。必ずL3を介す必要があるMulti-Podとは異なり、HERが可能なMulti-Podではサイト間ネットワークにMulticast要件もありませn。 pic.twitter.com/rKV5lNsHSX

拡大

Takao Setaka @twtko

#CiscoACI 4.0からはMulti-Site間の通信を暗号化するCloudSecの利用もサポートされる予定です。Hop-by-HopなMACsecに対して、CloudSecはサイト間通信をEnd-to-Endで暗号化します。 pic.twitter.com/kaYkA93aRs

拡大

Takao Setaka @twtko

#CiscoACI Multi-Site Orchestrator (MSO)は、その名の通りコントローラというよりはオーケストレーターで、サイト間のポリシーと接続性を各サイトのAPICとの間で調停する役割を持ちます。内部的にはコンテナベースのアプリケーションとして動作しており、分散Active/Active冗長で配置できます。 pic.twitter.com/U9xG6cF9yk

拡大

Takao Setaka @twtko

Multi-Site構成となったとしても、 #CiscoACI のコントローラがAPICであることは変わりません。MSOはサイト間ポリシー展開と調停、可視化等のオペレーションを行うためのオーケストレーターとなる位置付けです。MSOの停止が各サイトはもちろん、サイト間通信においても影響を与えることはありません。 pic.twitter.com/HRoad7QTPy

拡大

Takao Setaka @twtko

#CiscoACI Multi-Siteのサイト間を接続する”Inter-Site Network”にはAPICが管理していないネットワークを利用します。サイト間に距離的な制限はなく、First HopがSpineとの間でOSPFを用いたルート情報の交換のピアとなることと、必要なMTUサイズにEnd-to-Endで対応していることが必要要件となります。 pic.twitter.com/XXPa9zXbyr

拡大

Takao Setaka @twtko

#CiscoACI Multi-SiteにおけるMTUサイズは、Endpointが送受信する“Data Plane MTU”と、サイト間EVPN通信のために設定される“Control Plane MTU”の2つを考慮する必要があります。Data Plane MTUはEndpoint生成パケットサイズ+50B、Control Plane MTUはISN最大パケットサイズに基づいて決定します。 pic.twitter.com/URMQi1TUxl

拡大

Takao Setaka @twtko

#CiscoACI Multi-SiteでMTUサイズの考慮が必要となる2つの要素のうち、Control Plane MTUについてはデフォルトでは9000 byteが設定されています。ISNで疎通可能なMTUサイズに合わせて各サイトのAPICにおいてポリシーとして定義が必要となります。 pic.twitter.com/fETP7gzdPf

拡大

Takao Setaka @twtko

#CiscoACI Multi-SiteでISNに接続したSpineには、対向のSpineとの間でMP-BGP EVPNピアリングを構成することと、Data-planeトラフィックを転送することの2つの役割があります。MP-BGP EVPNピアリングのためのCP ETEPはSpine毎に、Data Plane転送のためのDP ETEP / HER ETEPはサイト毎に共通となります。 pic.twitter.com/YUCEKhC6Dk

拡大

Takao Setaka @twtko

#CiscoACI Multi-Siteのために、全てのExternal TEP (ETEP)のアドレスはOSPFによりサイト間で交換される必要があります。各サイト内で利用されているInternal TEPアドレスはサイト間には広告されませんが、管理上各サイトのTEP Poolのアドレス範囲は重複しないように設定することが推奨されます。 pic.twitter.com/Bf2pB504Au

拡大

Takao Setaka @twtko

#CiscoACI Multi-Site間Unicast通信。宛先Leafを知らない送信元LeafがSpineに転送するところまでは単一サイトの場合と同様。Spineはサイト間MP-BGP EVPNで得ていた情報を元に宛先Spineに転送、その後はまた単一サイトの場合と同様です。ISNではDP ETEP間でのUnicast通信となります。 pic.twitter.com/xL3kFydBlZ

拡大

Takao Setaka @twtko

#CiscoACI Multi-Site間Unicast通信の続き。戻り通信では、宛先Leafは既に送信元Leafが存在するサイトを把握しているため、送信元サイトのDP ETEP宛に直接VXLANトンネルを張ります。また、ポリシーも宛先Leaf側で適用します。最後に、送信元Leafも宛先Leafがあるサイトを把握します。 pic.twitter.com/GJFTuKpwxr

拡大

Takao Setaka @twtko

#CiscoACI Multi-Site間Unicast通信。両Leafが相互に宛先サイトを把握した状態となると、VXLANトンネルは相互に相手先SpineのDP ETEPと張ると共に、ポリシーの適用もEndpointにとって直近のLeaf側で適用できるようになるため、通信処理が分散し最適化されます。 pic.twitter.com/q4ocAQ1Jpv

拡大

Takao Setaka @twtko

#CiscoACI Multi-Siteにおいても、VXLANはとても活用されています。ACI Fabric内でもSpineはAnycast Proxy TEPやMulticast TEPを持っていますが、Multi-Site構成のInter-Site Network接続SpineではControl-Plane・Data-PlaneのためのExternal TEPが構成され、サイト間通信のトンネルに利用されます。 pic.twitter.com/71FH1SaCya

拡大

Takao Setaka @twtko

#CiscoACI Multi-Site環境でSite1のEP1とSite2のEP2の間で初めて通信が行われる際の動作。 1. EP1がEP2宛のパケットを送信 2. Leafスイッチは宛先EPがあるEPのLeaf情報を保持していないためSpineのProxy TEP宛に送信 ここまではMulti-Site構成ではない場合と全く同様の動作となります。 pic.twitter.com/LDq1j53Zbv

拡大

Takao Setaka @twtko

#CiscoACI Multi-Site環境での通信の流れの続き。 3. SpineはEP2が存在するSite2のData-Plane ETEP宛に送信 ここでなぜSpineが宛先Siteがわかるかというと、事前にCP-ETEP間でのMP-BGP EVPNによってInter-Site通信を必要とするEndpointの情報がISN接続Spine間で交換されているため。 pic.twitter.com/ZCh1nyJfpx

拡大

Takao Setaka @twtko

#CiscoACI Multi-Site環境での通信の流れの続き。 4. 対向Spineからパケット受け取ったEP2側Spineは、まずVRF/BDを示すVNIDとEPGを示すClass-IDをLocalのものと変換 この様にVNIDとClass-IDはSpineによって変換されるため、各SiteのAPICによってそれぞれ管理されたまま横断したポリシー適用が可能に。 pic.twitter.com/1U8ZtGQFKA

拡大

Takao Setaka @twtko

#CiscoACI Multi-Site環境での通信の流れの続き。 5. EP2を配下に持つLeafはEP1からのパケットを受け取る この際、送信元TEPとしてはSite1のLeafではなくDP-ETEPとなっており、EP2接続LeafはEP1の送信元を把握する 6. iVXLANヘッダを外したパケットをEP2が受信し、行きの通信は成立。 pic.twitter.com/dWVWft9mEW

拡大