トンネル単位のQoSはハブの総アップリンクを制限しない

この思い込みは算数のように聞こえます。五本のスポークをそれぞれ5 Mbit/sに整形するのだから、ハブが運ぶのは最大25 Mbit/sだというわけです。前半は正しく、結論は正しくありません。トンネル単位のポリシーはハブごとに一度ではなく、トンネルごとに一度適用され、五本すべてのトンネルが通る共有アップリンクはその計算に一切現れません。アップリンクの輻輳はそのまま残ります。

思い込みの出どころ

混乱は理解できます。NHRPグループ情報を使えば、ひとつのポリシー定義をスポークの集合全体に適用できるからです。これは設定ファイル上の共有予算のように読めてしまいます。実際の意味は、各スポークがその定義のインスタンスをそれぞれ受け取るということです。

つまりスポークあたり5 Mbit/sはトンネル単位の上限であり、上限の数はトンネルの数だけあります。

ひとつのポリシーインスタンスが制御するもの

CiscoのIOS XEにおけるDMVPNのトンネル単位QoSガイドは、NHRPグループ情報で選択され、各スポークに個別に適用されるハブの出力ポリシーを説明しています。この一文から二つの限界が導かれ、どちらも無視されます。レートは共有のバケツではなくひとつのスポークに属し、この機能が制御するのはハブからスポークへのトラフィックであり、その逆ではありません。

スポークの送信方向は独立に計画してください。ハブの出力ポリシーには、支店がアップロードするものを制限する要素はありません。

総量の制限は共有ボトルネックに置く

総量は実際に競合する場所で整形する必要があります、つまり、すべてのトンネルが共有する物理インターフェースです。Ciscoはこの機能でサポートされる同時物理ポリシーとして、物理インターフェース上のclass-defaultシェーパーを文書化しています。これは入力できるどんな階層よりも狭い記述です。自分で考案した任意の第二物理ポリシーは、誰かが反証するまでサポートされないと想定してください。

次に、すべてのスポークが同時にビジーになったときに何が起きるかを決めます。どのトラフィックを受け入れ、どのクラスを優先し、どのキューが競合を担うのか。スポーク単位の上限はこれらの問いに一つも答えません。各スポークが単独で評価されるからです。

整形の単位とオーバーヘッドの計上を実際の受け渡しに合わせてください。レート計算から外したカプセル化オーバーヘッドは、設定した数値より早く飽和するリンクとして現れます。

カウンターはひとつの特定の仕方で嘘をつく

整形している層でカウンターを読んでください。同じCiscoのガイドは、この構成ではメインインターフェースのポリシーカウンターが不正確になることがあると警告しています。それはカウンターについての注意であり、クラスが一致しているかドロップしているかの証拠ではありません。アプリケーションの結果とは切り離してください。ユーザーが体験するのはそれだけです。

古いtraffic-shapeの例を無関係なポリシーマップの隣にコピーしても、二つのレートが同じパケットを制御していることにはなりません。

上限だけでなく総量をテストする

まずひとつのスポークをビジーにして、上限に達することを確認します。次に承認済みの計画の下で全スポークから同時にトラフィックを流し、トンネル単位の数値と並べて物理インターフェースを観察します。各スポークが上限に張り付いたままアップリンクが飽和し遅延が増えるなら、スポーク単位のポリシーは設計どおりに機能しており、予算は依然として間違っています。

その時点での修正は、容量かアドミッションの判断です。スポーク単位の数値を調整し直しても、どの支店が最初に苦情を言うかが変わるだけです。