Junosのエクスポートポリシー：名前は一致条件ではない

誰かがポリシーに EXPORT-STATIC と名付け、アタッチしたが、VPN ルーティングインスタンスからのプレフィックスがなぜ遠端に届かないのかと不思議に思っている。名前は選択に何の影響も与えない。ポリシーとは定義とアタッチであり、何をエクスポートするかは、その一致条件、順序付きの項、そしてそれを使うコンテキストによって決まる。この三つをその順に読めば、謎はたいてい一度も一致しなかった一つの項に収束する。

名前はラベルであり、条件ではない

Junos はポリシー名を解釈しない。静的エクスポートと呼ぶのが妥当なポリシーが、static プロトコルに一致することもあれば、アドレスプレフィックスに一致することもあり、何にも一致せず通過するすべてを受け入れることもある。ラベルは作成者が書いたドキュメントであり、その人物の意図に関する記憶と同じ程度にしか信頼できない。

意外なエクスポート結果は、定義を読むべき要求として扱い、アタッチが壊れている証拠とはみなさない。定義を読み、ラベルと矛盾させてみる。

項より先にアタッチを見つける

正しい定義でも間違った場所にアタッチされていれば、別の交換を変えてしまう。どのルーティングインスタンス、プロトコル、そしてどのネイバーまたはグループが実際にポリシーを参照しているかを突き止めるべきであり、ある BGP グループの下にアタッチされたポリシーは別のグループには影響せず、インスタンスにアタッチされたポリシーはその中のすべてのプロトコルに必ず適用されるわけではない。Junos はこれらのレベルを区別しており、意図がインスタンスレベルで表現されたときにグループレベルでエクスポートが欠けるのはよくあることだ。

一つの項を読む前に、アタッチの経路を書き留める。こうした調査の半分は、定義は手つかずのままでエクスポート文だけが移された状態で終わる。変更履歴に差分を記録し、誰も誤りとして巻き戻さないようにする。

項は順に評価され、最初の判断が勝つ

項は最初から最後まで実行され、受け入れるか拒否する項は終端の判断となる。後ろの項が意図した例外に見えても、前の項がすでにルートの運命を決めていれば決して実行されないので、ポリシーは上から下まで正しく読めても意図とは逆に振る舞うことがある。順序は、気にしているルートに対して確認するのであり、項が入力された順序に対してではない。

アクションを省略した項は終端せず、評価は次の項へ続き、最終結果はその後に続くものと適用されるデフォルトに依存する。これは本当に有用な構文であり、意図しない場合には確実な驚きの源になる。

静的ルートだけをエクスポートする例で、アタッチはグループ側にある：

policy-options {
    policy-statement EXPORT-STATIC {
        term statics { from protocol static; then accept; }
    }
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }

OSPF で学習され、静的ルートとして設定されていないプレフィックスは、ポリシーの名前が何であっても一致に失敗して落ちる。

アクションが変えるのはコピーであり、元のルートではない

ポリシーのアクションは、その広告のために評価される時点のルート、つまりルーティングテーブルのエントリではなくコピーに対して作用する。したがってローカルの show route はある属性の組を持つルートを表示しても、エクスポートされる版は別の属性を運ぶことがあり、元のルートはエクスポートによって書き換えられない。この区別は、どちらの出力が正しいかという議論の多くを説明する：両方とも正しく、異なるオブジェクトを記述しているのだ。ルート属性について二人の技術者が意見を異にするときは、どちらのビューを引用しているのかを明言する。

受け入れることと拒否することは終端の判断であり、属性の変更は必ずしもそうではない。community を設定すればポリシーが終わると考えてはいけないのは、評価が考慮していなかった項へ続くことがあるからだ。

広告されるビューと期待を比較する

実際のピアで、たとえば show route advertising-protocol bgp 192.0.2.1 のようなプロトコル固有のビューを使い、正しいルーティングインスタンスのコンテキストで読む。VRF に存在するルートがエクスポートポリシーを通過したとは限らず、広告される出力に現れるルートが遠端に受け入れられたとも限らない。これは三つの別個の状態であり、それぞれ異なる形で失敗する。

広告しなければならないプレフィックスと、ローカルに残さなければならないプレフィックスの二つで設計を受け入れる。そうすればポリシーに検証可能な契約が生まれ、名前付きのルートがようやく現れるまでエクスポートを広げるという代替の修正を避けられる。