Pseudowireの状態とトラフィックカウンタ：どちらが配信を証明するか
運用状態はサービスが設定済みで稼働中であることを示し、カウンタはフレームが流れたことを示す。両方をVCインデックスで結合し、方向、不連続、MIB対応を確認する。
pseudowireがupを報告しているということは、サービスが存在し、両方向が「トラフィックを運ぶべき」で一致していることを示す。しかし、顧客フレームが一つでも実際に通過したことは示していない。状態オブジェクトとカウンタオブジェクトは異なる目的で書かれており、一方を他方の証明とみなすことが、こうしたダッシュボードの大半の誤りの原因である。両者を比較することが仕事であり、どちらか一方だけを信じるのは誰も尋ねていない問いに答えることになる。
状態とカウンタは異なる問いに答える
メインのVCエントリは統合された運用状態を持ち、その状態は両方向の状態がupのときだけupになる。その背後にあるのは制御プレーンと設定の知識、つまりローカルのアタッチメント回路、ピア、シグナリングである。この状態の行は意図と準備に関する記述であり、転送されたフレームについての記述ではない。
トラフィックはパケットとバイトの大容量カウンタの別テーブルに存在し、その行は同じVCインデックスを持つ。そこでの増加は、測定した区間中にフレームがまさにその行を通った証拠である。 変化しないカウンタは単独では曖昧である。アイドル状態のサービス、誤った行を読むコレクタ、静かに壊れた経路は、いずれも同じ平坦な線を描く。
| Question | Object | What it can establish |
|---|---|---|
| Is the service up? | cpwVcOperStatus | Both direction states agree the VC should carry traffic. |
| Which side is down? | cpwVcInboundOperStatus, cpwVcOutboundOperStatus | Direction of the reported fault. |
| Did frames move? | cpwVcPerfTotalTable HC counters | Observed forwarding on that row between two polls. |
| Is the interval clean? | cpwVcPerfTotalDiscontinuityTime | Whether the counter was reset inside the window. |
テーブルは深刻度の階段ではなく、証拠の二列として読む。カウンタが平坦なupは、増加するupの劣った版ではなく、次の手順が異なる別の観測である。
チケットの番号ではなくVCインデックスで結合する
VCテーブルは一つの整数でインデックスされ、VC ID、ピアアドレス、サービスの種類と名前はその行の属性である。これらの属性で自分のサービスを見つけ、インデックスで最初のポーリング以降も見つけ続ける。インターフェースインデックス、表示された回線名、MPLSラベルは、数字が一致していてもこのインデックスではない。
数値OIDはブログ記事ではなくコレクタ上のMIBファイルから導き、そのうえでテーブルを一回たどって見つけた識別情報を保存する。
snmptranslate -On CPW-VC-MIB::cpwVcIndex
snmptranslate -On CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime
snmpwalk -v2c -c monitor 10.60.4.21 -On CPW-VC-MIB::cpwVcTable管理アドレスとインデックスを一緒に監視システムへ記録する。プロビジョニングし直すとサービスが別の行へ移る可能性があり、名前でVC IDに結合したコレクタは古いインデックスを描き続け、それは今も丁寧に応答する。
方向とはpseudowireの方向であり、加入者の方向ではない
入力方向のカウンタはVCがパケット交換網から受け取ったもの、出力方向のカウンタはVCがその網へ向けて転送したものを表す。顧客に向かうPEでは、これは多くの場合ダウンロードとアップロードに何らかの順序で対応する。ハブPEや、コアとピアを張るPEでは、同じオブジェクト名が逆の顧客体験を表す。
割り当てはデバイス役割ごとに一度書き、ダッシュボードのラベルに残す。顧客アップロードという題名ながら実際にはコア向けトラフィックを描くグラフはレビューを通過し、容量判断に使うすべての人を静かに誤らせる。同じリスクはそうしたグラフに基づくアラートにも当てはまり、誤ったチームを呼び出す。各グラフはpseudowireに対する進行方向でラベル付けし、顧客向けの割り当ては必要とするパネルの中に置く。
一回の試験はオブジェクト記述をどれだけ読むより勝る。既知のファイルをサービス経由で流し、直後に両方向をポーリングして、どちらのカウンタが動いたかを見る。結果はデバイス役割の隣に記録する。次の人も同じ問いを立てるからだ。
レートは一つの不連続ウィンドウの中でしか有効でない
レートはバイトカウンタの増加を経過秒で割り、ビット毎秒にするには八を掛けて計算する。カウンタが減った、エージェントが再起動した、行が変わった、不連続オブジェクトが動いた、のいずれかなら区間を無効と扱う。このオブジェクトはシステム稼働時間に対して表されるため、デバイスの再起動でも無効になる。スパイクを描くのではなく、サンプルを捨てて新しいウィンドウを開く。
既知の間隔で二つのサンプルを取り、タイムスタンプは端末の履歴ではなくコレクタから保持する。
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
sleep 60
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime.7大容量カウンタでは単一のpseudowireでラップは問題にならないため、減少はほぼ常にリセット、エージェントの交換、別の行のいずれかを意味し、算術的なオーバーフローではない。だからこそ三番目のコマンドは最初の二つと同じくらい重要である。
導入済みリリースが実際に何をサポートするか確認する
MIB定義は仕様であり、あなたのイメージについての約束ではない。テーブルが存在しない、一部だけ実装されている、機能が有効になるまで存在するが埋まらない、といったことがあり、同じプラットフォームでもリリース間で異なる。 CISCO-IETF-PW-MIBの定義はオブジェクト名を与え、応答するかどうかはデバイスが示す。
両方のテーブルとファームウェア文字列を一回のパスでポーリングし、リリースノートの主張と比較する。
snmpget -v2c -c monitor -Oqv 10.60.4.21 SNMPv2-MIB::sysDescr.0
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcTable | wc -l
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalTable | wc -l空のウォークと未サポートのウォークは別の失敗であるため、行数だけでなくエラーを読む。状態テーブルが応答し性能テーブルが応答しないなら、最初の節で設計した結合は着地点を失い、修正は回線変更ではなくコレクタ変更になる。
係争中の回線での手順は短い。インデックスから行の同一性を確認し、既知の転送一回で方向の割り当てを確認し、きれいな不連続ウィンドウの中だけでレートを計算し、そのリリースで両方のテーブルが応答することを確認する。各手順は候補となる説明を一つずつ除外する。四つすべてが成り立ち、それでもカウンタが動かないなら、証拠はpseudowireから離れた方向を指す。そこでこそ、アタッチメント回線でのパケットキャプチャが価値を発揮する。