帯域幅測定サボテングラフで大きな変動が生じるのはなぜですか？

ネットワーク上のEtherchannelとルーティングの冗長性テストを実施しました。この介入中に、いくつかの測定を行いました。私たちの監視ツールはグラフ用のCactiです。監視対象の機器は、VSS上の4500-Xです。各リンクは異なる物理シャーシ上にあります。

スキーマ：

年表のテスト：
[t0] te1 / 1/14ポートのリンクが物理的に削除されました。Te2 / 1/14はアクティブです。Po1は動作可能です。
[t0 + 15] Te1 / 1/14ポートのリンクがサービスに戻り、etherchannel Po1
[t0 + 20] te1 / 1/14ポートのポートが物理的に削除されたことを確認しました。Te2 / 1/14はアクティブです。Po1は動作可能です。
[t0 + 35] Te1 / 1/14ポートのリンクがサービスに戻り、ポートがイーサチャネルPo1に戻ることを確認しました

テストでは、Cactiを介してトラフィックイーサチャネルPo1を監視し（下のグラフ）、リバース中にかなり安定したte1 / 1/14リンク（リンクte2 / 1/14アセット）を無効にすると、フローの値に大きな変化が見られました。int Po1のカウンターもチェックしましたが、これらはかなり安定して維持されていました。

10Gの2つのインターフェイスは、LACPが設定されたEtherchannelにバンドルされています。イーサチャネル内には2つのVLANがあります。1つはマルチキャストトラフィック用で、もう1つはインターネット/すべてのトラフィック用です。

この動作の考えられる原因を知っていますか？

yttiのコメントを拡張するため。

あなたのポーリング間隔は、私が正しく読んでいる場合は10秒ごとに非常に小さく見えます。その結果が得られる理由はいくつかあります。

機器側：

• カウンタの選択が不適切です。32ビットカウンタを使用している場合、ラインレートで10gインターフェイスを実行していると、〜3.4秒ごとにロールオーバーする可能性があります。
• カウンタの更新、より大きなデバイスの多くは、カウンタを1分間に2〜3回しか更新せず、同期に依存することはできません。30秒ごとにポーリングの手間がかかりますが、それでもアラートをトリガーしたりアクションを実行したりする前に、少なくとも2ポイントは必要です。
• CPU処理のために送信されたパケット（おそらくネットフロー）は、バッチ処理されているREに送信されないパケットに対して、すぐにカウントされる可能性があります（Juniper MXでこれを確認しました）

ポーラー側：

• ポーラーは間隔で正確にポーリングしますか？そうでない場合は、実際のポーリング時間（たとえば、yz秒のxビット）を結果に注入して、適切なレートを計算できるようにします
• カウンターがリセットされた場合、またはSNMP GETが応答しない場合に起こること

あなたの問題は、ルーターのサンプリングとあなた自身のポーリングが同じ瞬間に当たらないということです。つまり、ポーリング間隔は静的ですが、ポーリング間隔にはさまざまな量のサンプルが含まれており、数学では考慮されません。
t1、t2、t3をポーリングしたが、ルーターはt1、t2間隔で何もサンプリングしなかったため、t1、t3間のすべてのトラフィックはt2、t3ポーリング値で終了したと考えてください。t1、t2でレートが0になり、t2、t3でラインレートを超過する

次に、1つの解決策を提案しますが、数学を大まかに理解している人とこれを確認してください。

興味のあるインターフェイスを最初に把握します（ge-1 / 1/1の場合）：

snmpbulkwalk SWITCH ifDescr | grep ge-1 / 1/1

次に、ifIndex番号が表示されます。「42」と仮定します。

次に、次のようなことを行います：

while true; do
  snmpbulkwalk SWITCH ifHCInOctets.42 >> DATA
  date >> DATA
  sleep 1
done

次に、結果を分析して、実際にカウンタが実際に更新される頻度を判断します。（必要に応じて分析用のスクリプトを作成できます）

次に、数学が必要になる部分がありますが、1つの素朴な解決策を提案します。

更新間隔が10秒の場合、5秒ごとに、つまり、更新の2倍の頻度でボックスをポーリングします。その後、あなたのサンプルは

t0、t5、t10、t15、t20、t25、t30

これは、使用しない生データになりますが、実際のサンプルはこのように回復する必要があります

s1 = (t0+t5+t10)/3
s2 = (t10+t15+t20)/3
s3 = (t20+t25+t30)/3

ここでの理由は、スイッチでの不正確なポーリング間隔の影響を減らすために、境界を越えてリークすることです。

次に、s1、s2、s3をプロットすると、現在表示されているものよりもはるかに滑らかで正確な結果が得られます。

しかし、これは目新しい問題ではなく、最適な精度を回復する正式な解決策があると確信しています。残念ながら、その解決策は私のスキルの範囲外です。math.stackexchangeの人々が取り組む方が良いでしょう。

カウンタの更新と同じレートでポーリングしているため、同期が取れていない可能性があります。

構成することにより

snmp-server hc poll <<hundredths of a second>>

SNMPカウンターが更新される間隔を1秒などに短縮できます。これにより、10秒ごとにポーリングしているときのスループットの値がより正確になります。

参考までに、これは隠しコマンドです。