SD-WAN制御トラフィックのオーバーヘッドユーザガイド

はじめに

このドキュメントでは、SD-WANオーバーレイ展開での制御トラフィックのオーバーヘッドを計算する方法について説明します。20.10.xより前のviptelaコードおよびIOS-XE SD-WAN 17.10.x以下（20.10.x /17.10.x以降のシスコではデータ収集用のプッシュモデルを実装）では、次の文書ガイダンスを使用する必要があります。 

問題

設計フェーズ時にユーザから受ける一般的な質問は、「SD-WANソリューションによってブランチ回線にどれだけのオーバーヘッドが生じるか」です。答えは、いくつかの変数によって異なるということです。

解決方法

このケーススタディは、その答えを見つけるのに役立ちます。 ブランチロール発信時のユーザのほとんどは、インターネット回線をプロビジョニングできる場合とできない場合があります。通常、図1のような形式になります。

図1.インターネットとマルチプロトコルラベルスイッチング(MPLS)回線の両方を備えたSD-WANブランチ

これは必ずしも当てはまらない可能性があり、一部のユーザは通常、最小限の変更と新しい回線導入、および図2のようなインターネット回線のない後のフェーズで計画される回線の追加を伴うSD-WANへの移行を好みます。

図 2：MPLS回線のみのSD-WANブランチ。

段階を設定するために、2つのヘッドエンドを持つ100のブランチがあり、ブランチとヘッドエンドの間に提案されたフルメッシュトポロジがあり、ユーザが音声用のLow Latency Queue（LLQ；低遅延キュー）に20 %割り当てるという厳格なQOS標準を持っている場合。

SD-WANへの移行に伴い、これらのブランチで考慮すべきオーバーヘッドがあれば、どれくらいになるでしょうか。もっと深く掘り下げましょう。

注：これらの計算は、ピーク要件を含む通常の運用要件で考慮されます。 ただし、考えられるすべてのシナリオを考慮しないでください。

これらの数値は、1vManage、1vBond、1vSmart、255のBFDセッションで実施されたラボテストから導き出されたものです。 

表 1.セッションあたりの帯域幅。

1 BFDセッション/ネイバー	2 X 132 X 8 = 2.2 Kbps 2:1秒間に最大2つのBFDパケットを送受信します 132:B単位のBFDパケットサイズ
DTLSからvSmart	最大80 Kbps*
データのvManageポーリング	最大1.2 Mbps**
DPIの有効化	200 Kbps

Kbps =キロビット/秒

B =バイト

Mbps = Megabits per second（メガビット/秒）

*ポリシーとルートによって異なります。この計算は最初の交換時にのみ必要であり、安定状態は約200 Bと非常に低い/最小限です。

**リモートコマンドの実行やadmin techなど、ユーザがトリガするアクティビティは考慮されません。1.2 Mbpsがピークに達しています。

ここで、100のフルメッシュサイトすべてが200 BFDセッション(ブランチあたり2台のルータ、ルータあたり2台のTLOCでrestrictの色が付いています)であると仮定すると、前述の表は.xになります。

表 2 vSmartおよびvManageポーリングを含む、200 BFDセッション[100 Sites]のQueue0 Bandwidth。

200 BFDセッション	440 Kbps [2.2 X 200]
DTLSからvSmart	最大80 Kbps*
vManageポーリング	最大1.2 Mbps**
合計	1.72 Mbps

*ポリシーとルートによって異なります。この計算は最初の交換時にのみ必要であり、安定状態は約200 Bと非常に低い/最小限です。

**リモートコマンドの実行やadmin techなど、ユーザがトリガするアクティビティは考慮されません。1.2 Mbpsがピークに達しています。

これらのすべてのトラフィックがQueue0 LLQにヒットすることに留意してください。この制御トラフィックには常にファーストクラスの市民プライオリティが与えられ、LLQでポリシングされる最後のトラフィックとなります。

QoS設計時に、音声トラフィックがQueue0(LLQ)に配置されることもよくあります。100のブランチに対する1.72 Mbpsの要件と、SD-WAN用のTlocを備えたフルメッシュの場合には、低帯域幅回線ブランチを持つLLQでポリシングとドロップを確認できます。

ここで、Queue0に寄与しないが全体的なキャパシティ要件を構成するTloc拡張オーバーヘッドを考慮する場合について説明します。

表 3 Tloc拡張でトラフィックを制御する方法を検討した後の全体的な帯域幅要件。

キュー0の要件	1.72 Mbps
200 BFD Session for Tloc Extension [Encrypted] Non Queue0	520 Kbps [440 + 80*]                [BFD + DTLS]
合計	2.24 Mbps

*ポリシーとルートによって異なります。この計算は最初の交換時にのみ必要であり、安定状態は約200 Bと非常に低い/最小限です。

カラー制限を持つTLOC拡張機能とフルメッシュの100ブランチごとに、極端な要件で最大2.5 Mbpsの容量計画を検討してください。また、リアルタイムコマンドを収集できます。admin techは前述の計算では考慮されません。通常の運用状況でこれを検討してください。 

シナリオ 1.

Queue0への制御トラフィック要件に対応する必要があり、ブランチに10 Mbps回線しかない場合は、音声トラフィックと制御トラフィックの両方に対してわずか20 %のLLQのQoSポリシーを使用して、SD-WANオーバーレイにその回線をオンボーディングする必要があります。vManageからのピーク時のポーリング時に、低下したエクスペリエンスを確認できます。この場合、ハブアンドスポークソリューションは約1.28 Mbpsを消費するため、役に立たない可能性があります。

表 4 ハブアンドスポークQueue0の帯域幅要件。

ヘッドエンドへの4 BFDセッション	8.8 Kbps [2.2 X 4]
DTLSからvSmart	最大80 Kbps*
vManageポーリング	最大1.2 Mbps**
合計	1.28 Mbps

*ポリシーとルートによって異なります。この計算は最初の交換時にのみ必要であり、安定状態は約200 Bと非常に低い/最小限です。

**リモートコマンドの実行やadmin techなど、ユーザがトリガするアクティビティは考慮されません。1.2 Mbpsがピークに達しています。

シナリオ 2.

QoSポリシーを再設計して、最大2 Mbpsの追加帯域幅要件に対応する場合は、QoS LLQを20 %から40 %に増やすことができます。ただし、これは帯域幅の大きい回線に悪影響を及ぼします。

図 3：QoSのための通常の20 %のQueue0割り当て。

10 Mbps回線の場合、Queue0は20 %で2 Mbpsを取得します。 これが会社の一般的なQoS標準であると仮定します。SD-WANの採用にはフルメッシュが必要なため、図に示すようにQoSの割り当てを40 %に増やすことをユーザが決定した場合は、Queue0への2 Mbpsオーバーヘッドに対応するために、Queue0の割り当てを増やす必要があります。

ある回線に対して大量のQueue0が存在し、他のキューのリソースが奪われていることを確認します。ただし、その違いは帯域幅回線が大きい場合に顕著です。

制御トラフィック用に固定の割り当てを持ち、音声トラフィック用に別のキューを持つLLQが理想的ですが、どちらもプライオリティキューが必要です。Ciscoルータでは、スプリットLLQと呼ばれる2つのレベルを持つプライオリティキューがサポートされています。これもまた、最小要件を満たした後の最小帯域幅要件の問題に対処するものではなく、スプリットLLQが優先されるQoS設計です

スプリットLLQ:

 

 

スプリットLLQでは、必要な帯域幅をキューに追加しても、プライオリティキューは維持されます。

スプリットLLQは現在、アドオンCLIでのみサポートされています。スプリットLLQでは、プライオリティキューに2つのレベルを設定できます。次に設定例を示します。設定は変数を使用してカスタマイズできます。このスニペットでは、制御トラフィック用に4 Mbpsが予約され、キューの残りの部分は割り当てられた帯域幅の割合として予約されます。

分割キューの例：

policy-map GBL_edges_qosmap_rev1

class Queue0

  priority level 1

  police cir 2000000 bc 250000

   conform-action transmit

   exceed-action drop

  !

!

class Queue1

  bandwidth remaining ratio 16

  random-detect precedence-based

!

class class-default

  bandwidth remaining ratio 8

  random-detect precedence-based

!

class Queue3

  bandwidth remaining ratio 16

  random-detect precedence-based

!

class Queue4

  bandwidth remaining ratio 32

  random-detect precedence-based

!

class Queue5

  bandwidth remaining ratio 8

  random-detect precedence-based

!

class Queue6

  priority level 2

  police rate percent 20

  !

!

!

注：これらの設定は、17.3.xを実行するISR/ASRおよび20.3.xを実行するコントローラでテストされています。

間接費計算の一般的なガイドライン

次の表は、SD-WAN制御オーバーヘッドに対する回線ごとのキャパシティを計画する際に役立ちます。

表 5 一般的なガイドラインの計算（カラー制限があることを前提）。

間接費計算の例

ここで示すような100サイトのMPLS回線のオーバーヘッドを計算する必要がある場合は、各カラーでrestrictが有効であると仮定できます。

サイト数= 100

WAN TlocからサイトへのBFD数= 2。

表 6 100サイトの導入に対するMPLSオーバーヘッドを計算します。

プロトコル/セッション	必要な帯域幅
キュー0	2.2 x [100 x 2] + 80 + 1200 BFDサイズx [サイト数x WAN TlocからサイトへのBFD数] + DTLS +vManage = 1.72 Mbps
TLOC経由の制御トラフィック	2.2倍 [100 X 2] + 80 BFDサイズx [サイトx TLOC/ルータあたり] + DTLS = 520 Kbps
合計	1720 Kbps + 520 Kbps = 2.24 Mbps

Queue0のオーバーヘッドは1.72 Mbpsで、オーバーヘッドの合計は2.24 Mbpsです。