ルーターの Ping と VLAN ホスト：どの PBR ポリシーが適用されるか

VLAN 10 は VPN、VLAN 20 は WAN を使うべきなので、最初のテストは VLAN 10 のインターフェースアドレスを送信元にしたルーターからの Ping になる。これは成功し、route-map のカウンターが増えるので、誰もが設計は機能すると結論する。しかし機能しない。その Ping はローカルで生成されたものであり、ローカル生成のトラフィックは VLAN インターフェースに到着するパケットとは別のポリシー適用点に達する。

本当にどのポリシーをテストしているかは、三つの条件で決まる：パケットがどこで生成されるか、どこから入るか、何に一致するか。

パケットがどこから入るかで、どのポリシーが動くかが決まる

ip policy route-map で付けたインターフェース route-map は、IOS XE PBR ガイド が説明するとおり、そのインターフェースに到着するパケットに適用される。VLAN 10 のホストが要求を送り、フレームが VLAN サブインターフェースに到着し、ルーターはそこでポリシーを評価する。ルーター自身のパケットはルーターの中で生まれたため、そのインターフェースには決して到着しない。

VLAN アドレスを送信元に選んでも、ヘッダーが変わるだけだ。起点は変わらない。

送信元付きの Ping が依然としてホストでない理由

送信元アドレスは ACL の一致に重要であり、それがこのテストをこれほど説得力のあるものにしている。パケットは送信元条件に一致し、カウンターが増え、出力は正しく見える。テストが示せないのは、入力インターフェース、到着のコンテキスト、そしてホストのパケットが同じ分岐を取るかどうかだ。

一致だけを再現し、コンテキストを再現しないテストは設計の半分しか証明せず、設計が間違ったポリシーを付けたまま出荷されるのはまさにこの半分の証明による。

ローカルポリシーが正解になる場合

Cisco は、ルーター自身が生成するトラフィック向けに ip local policy route-map を文書化している。これは別の適用範囲であり、要件が本当にルーター自身のトラフィックに関わる場合に正しいツールとなる。すべての VLAN 誘導設計に必要な、欠けている手順ではない。そこでの広い一致は管理接続や補助接続にも影響し得るので、見た目よりずっと大きな変更になる。

ローカル生成の TCP には、ポリシーが別の経路を選ぶ場合でもルーティングテーブルに該当する宛先エントリが必要だという追加の前提がある。ICMP の結果は TCP でも同じ動作を証明しない。

代わりにホストでテストすべきこと

VLAN 10 内の許可されたホストから、実際の送信元アドレス、宛先、プロトコル、ポートを使ってテストを実行する。入力インターフェースと route-map の一致を結果と並べて記録し、証拠が実行されたポリシーを示すようにする。次に VLAN 20 のホストで繰り返し、別の経路を通ることを確認する。

両方の経路には、機能するネクストホップ、戻りの到達性、該当する場合は VPN のカバレッジが必要だ。PBR は転送の判断を選ぶだけで、リモートサービスを作ったり、アプリケーションに許可を与えたりはしない。

結果が証明できることとできないこと

ホストのフローが成功したことは、ポリシーが一致し、選んだ経路がその時点で機能したことを証明する。ルーター自身のトラフィックが誘導されていることも、アプリケーションが許可されていたことも証明しないのは、別の問いであり別の証拠が必要だからだ。

Ping はローカルパケットに関する証拠として記録に残す。そして、二つのテストがたまたま似て見えるまでポリシーの範囲を広げるのではなく、ホストフローの証拠を取りに行く。