ACI Design Webinar 4th Season
第3回 Cisco ACI Forwarding Behavior Deep Dive 資料 |
ACI Design Webinar 4th Season 第3回 ACI Forwarding Behavior Deep Dive をお届けします。
合わせて、Webinar時に頂いたご質問と回答を記載しておきます。
| ご質問 |
回答 |
|
Spine-Proxyを行う場合のAnycast TEP宛通信に関して、どのSpineに転送されるのかは、LeafのECMPで決まるのでしょうか？またECMPで決まる場合、そのハッシュに使用されるのはinnerの情報でしょうか？outerの情報でしょうか？
先の質問は、単一LeafからのSpine-Proxyが各Spineに分散されるか？という意図での質問でした。たとえばiVXLANのUDP sPortで結果的に分散されるのであれば、その旨をご回答頂けますと幸いです。
|
ACI Fabric内のECMPについては、Anycast TEP宛の場合を含め、全ての場合において "Load Balancer Policy" に基づいて動作します。デフォルトではECMP動作となります。
ACI Fundamentals - Chapter: Forwarding Within the ACI Fabric - Fabric Load Balancing において、以下のように記載されております。
"Static hash load balancing is the traditional load balancing mechanism used in networks where each flow is allocated to an uplink based on a hash of its 5-tuple. This load balancing gives a distribution of flows across the available links that is roughly even."
ハッシュ計算は、"an uplink based on a hash of its 5-tuple" と記載があるように、LeafのFabricポート側のヘッダに基づいて行われるため、Outer側が利用されます。特定のLeafからSpineのAnycast TEP宛の通信の場合、sPort以外のパラメータは全て同一となりますので、結果的にはご認識の通り特定Spineだけに集中することはなく分散されます。
(ただし、Innerヘッダの5-tupleを直接ハッシュ計算に利用しているわけではないため、Endpointとしての通信を均等に分散させて通信したとしても、短期もしくは少量の通信ではFabric内のTEP間通信では分散の均等性にばらつきが出る場合があります。)
|
| Spine-proxyと比較してMulticast-proxyを利用するメリットを教えていただけますか？ |
資料のスライド14 [Spine Proxy設定の場合] におけるAnycast TEP利用の場合と、スライド15 [Flood設定の場合] におけるMulticast TEP利用の場合の比較についてのご質問と判断して回答させて頂きます。認識違いをしてしまっている場合等はコメントもしくはご連絡頂ければ幸いです。
Multicast TEPを利用する = L2 Unknown Unicast 設定を Flood に設定するべきケースとしては、以下のケースとなります。
- BD において [Unicast Routing] が無効 = IPアドレスの学習が無効となっている場合
- サイレントホストなEndpoint宛のL2通信が必要な場合
[Unicast Routing]が有効の場合は、宛先Endpointがサイレントホストの場合であってもSpine ProxyによるARP Glean動作によってEndpointの検出が行われることによって、いずれかのLeafがLocal Endpointとして宛先Endpointを検出 = Spineに通知されCOOP DBにエントリされるため、Hardware Proxy = Anycast TEPを利用する構成のほうがACI Fabric内のFloodパケットを削減できるため効率的です。
|
