要約

  • RFC 5190では、一つのMIDCOM設定トランザクションが複数のSNMP操作に展開される。通知は処理終了を知らせても、正の応答値やエラーの全体は後続GETに残ることがある。
  • 通知は失われ得る。ポーリングは操作数を増やすが再観測できるため、RFCはより信頼できる方法とする。ただし複数GETは原子的スナップショットではない。

運用チームは当初、trapを正本、ポーリングを代替手段と呼んでいた。RFC 5190の構造は逆の問いを要求する。どの経路が、論理応答を再構成するために必要な状態へもう一度到達できるか。

設定要求は一つのSNMPメッセージに収まらない場合がある。クライアントは行を作り、複数SETで要求値を埋め、管理状態を書いて処理を始める。最後のSET応答は入力が揃った証拠であり、処理結果ではない。

終了後のsolicited notificationが運ぶのは運用状態とlifetimeである。成功時のアドレスやポート、失敗時の詳細は行からGETする。イベントは完結した報告書ではなく、読み取りを開始する相関信号だ。

通知経路の速さと欠落

SNMP通知は通常、信頼性を保証しないUDPで送られる。失われたイベントは、それだけでは処理失敗を意味しない。クライアントは待機時間を定め、期限後に状態を問い合わせる必要がある。

イベントが届いた場合も、保存すべきなのは実際のvarbindだけである。後続GETの値を、最初からtrapに含まれていたかのように合成してはならない。観測時刻と取得経路が違うからだ。

通知中心の設計は平常時に効率的である。しかし障害時に「イベントが無い」と「操作が無い」を同一視すると、欠落したデータグラムへ実在判断を委ねることになる。

ポーリングは、状態を再び尋ねられる。RFCがより信頼できると述べる理由はそこにあり、すべてのGETが真実を固定するからではない。

ポーリングも一瞬を凍結しない

運用状態を読み、次に応答パラメータを読み、さらに関連資源を読む間に、ルールは変化し得る。長い一覧では追加と削除が同じ収集中に起こる。

RFC 5190は、読み取り中に届いた通知を結果へ統合するか、監視トランザクションをやり直す方法を示す。したがって収集物には開始時刻、終了時刻、途中イベントと調整方法が必要だ。

一つの「取得時刻」を付けた一覧は、同時に存在しなかった行を同じスナップショットとして見せる恐れがある。再実行可能性は原子性ではない。

運用判断では、通知とポーリングを競合する真実源ではなく、欠点の異なる二つの観測面として扱うべきである。

SET応答が失われた時の二つの現実

SET requestとreplyもUDP上で失われ得る。requestが届かなければ書き込みは無い。requestが届きreplyだけ消えれば、変更は既に始まっている。クライアントが見るtimeoutは同じである。

そこでRFCは、GETで最初の書き込みを確認してから必要な場合だけSETを繰り返す方法を挙げる。snmpSetSerialNo、最小lifetimeより短い再送タイマー、再送自体を止める選択肢も示す。

これらは曖昧さを管理する仕組みであり、エンドツーエンドのexactly-once証明ではない。再送前に値が減少し始めていれば、同じSETに見える二回目の操作が別の時点の状態へ作用する。

証跡はtimeout、確認GET、再送判断を残す。「再送成功」だけでは一回目の現実を消してしまう。

一時状態を完了へ昇格させない

midcomRuleOperStatusは、行の作成、値の設定、要求検査、処理、拒否、予約、有効化、終了を分ける。checkingRequestとprocessingRequestは外部操作なしに次へ移る一時状態である。

最後のSETが成功した瞬間にダッシュボードを緑へ変えると、この一時状態を飛ばす。SNMP書き込みの成功は正しいが、その意味をMIDCOM結果まで広げるのが誤りだ。

各層に別のreceiptを与える必要がある。SETは値の受理、運用状態はローカル処理、資源表はNATやfirewallとの関係、packet observationは通過、remote endpointは受領を証言する。

一つの状態名でこれらを代表させると、最も早い層だけが常に勝つ。

結果行は監査保管庫ではない

エラーまたは終了後、midcomRuleStorageTimeは行が残り得る時間を示す。だが実装は、その値がゼロになる前でも終了行を削除できる。削除後、格納情報は利用できない。

trapを受けてから低優先度キューでGETする設計は、この保持窓を失うことがある。通知は残っても、エラー理由や返却値は消える。

行が見つからないことは、要求が無かった証明ではない。既に完了し削除された可能性、アクセス権が無い可能性、別のowner/group/indexを見ている可能性を分けなければならない。

デバイス内のstorage timeを監査SLAとみなさず、終状態を観測した時点で外部の耐久記録へ複製する必要がある。

正しく認証された混成要求

複数SETで一行を作る間、同じ権限を持つ別クライアントが値を変更できる。全メッセージがUSM認証とVACM認可を通っても、最終行が一人の意図を表すとは限らない。

RFCはアクセス時刻の分離、group indexの分離、rule index範囲の非重複を提案する。これは「通常は協調する」という期待を検証可能な運用規則へ変える。

記録には各フィールドの書き手、変更前後、行バージョン、最終triggerが必要である。共通ownerは名前空間を示すが、著者性を一つにするものではない。

必要な証拠オブジェクト

論理要求ID、middlebox、rule/group/interface、責任主体、期待パラメータを固定する。すべてのSETについてprincipal、VACM判断、varbind、serial、replyまたはtimeoutを追加する。

処理を開始したtriggerと運用状態の遷移を分ける。終了検知が通知かpollingかを記録し、通知の実フィールドと補完GETを別々に保存する。

storage type/time、外部へ複製した時刻、早期削除、同時書き込みを残す。最後にローカル資源、両側packet capture、遠端receipt、application outcomeへ結ぶ。

trapが無くても状態は存在し得る。trapがあっても完全応答はまだ無い。この二文を同時に維持できる設計だけが、障害時の現実を取り戻せる。

出典

  1. RFC 5190 HTML
  2. RFC 5190 text
  3. RFC 5190 record
  4. IETF Datatracker RFC 5190
  5. RFC 5190 history
  6. RFC 5190 references
  7. RFC 5190 errata
  8. RFC 5189
  9. RFC 5189 record
  10. RFC 3416
  11. RFC 3418
  12. RFC 3414
  13. RFC 3415
  14. RFC 2578
  15. RFC 2579
  16. RFC 2580
  17. RFC 3304
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy