要点

  • RFC 8092 は12オクテットのトランジティブ値を定義するが、二つのローカルフィールドの意味は名前空間を持つ運用者が決める。
  • アクション community は処理要求にすぎず、受信側ポリシーが正しい段階で値を認識し、動作を適用して初めて結果になる。
  • 完了判定には、経路、辞書版、ポリシー版、マッチ結果、処理後属性、広告先、下流観測を結ぶ記録が必要だ。

正しいラベルと誤った結果

経路には期待した ASN:機能:パラメータ が付いている。変更票では、ある peer 群への広告を止める値だとされている。しかし下流の route collector は、除外されるはずの peer 経由で同じ prefix を観測している。

community が消えていたわけではない。最初の観測点には存在した。根拠がないのは、その事実を「ポリシーが実行された」と読み替えた部分だ。古い辞書、逆向きに適用されたポリシー、破壊的な書き換え後のマッチ、実装ごとの set の違い、後段の export ルールはいずれも、ラベルを残したまま意図を壊し得る。

RFC 8092 の Large Communities は optional transitive 属性である。値は4オクテットの Global Administrator と、運用者が定義する二つの4オクテット Local Data から成る。4オクテット ASN に適した形式だが、私的な数値の意味までは標準化しない。

したがって 64496:100:7 の観測は、その値が特定の speaker と処理段階に届いた証拠である。100 と 7 の現行の意味、消費したポリシー、別 AS での保持までは示さない。

属性自体に完全性保護もない。中間 AS は値を追加、削除、変更できる。順序に意味はなく、重複は除かれ、長さが不正なら treat-as-withdraw となる。どれも実行確認ではない。

動作を作るのはローカルポリシー

RFC 8195 は informational community と action community を分ける。前者は取得地点などの属性を示し、後者は優先度や伝播の変更を要求する。値を動作へ変換するのは受信 AS のポリシーである。

そのため、community の一覧とアクション処理順の公開が推奨される。正しい値でも古い辞書で読めば誤動作する。二つの正当なアクションが競合すれば、順序が優先、抑止、広告の結果を左右する。

RFC 1997 も、community を受信、優先、配布の制御に使い、ローカルポリシーで変更できるとしている。NO_EXPORT と NO_ADVERTISE は標準動作を持つが、運用者定義の Large Community に普遍的な意味はない。

後段の処理が成功を消す

RFC 8642 は、community を set する似た設定でも、well-known community を全て置換する実装と保持する実装があることを示す。同じに見える設定が異なる属性を生む。

import のマッチが成功しても後段で相殺される。local preference は正しくても export set が誤ることがある。境界で値が除去され、route reflector や段階配備が別の版を実行する場合もある。

検証では prefix と AS_PATH、受信値、辞書版、適用方向、マッチ trace、処理後属性、best path、peer ごとの advertised-routes、独立した下流観測を追跡する。

出典