ASA VTI 上の OSPF と EIGRP：あなたのリリースが対応するのはどちらか
OSPFv2 と EIGRP が ASA VTI を通るのは 9.19(1) 以降で、しかも multicast を有効にした場合だけです。使用中のリリースで両者を比較し、その後でネイバーを確認してください。
OSPF 対 EIGRP の議論の多くは、トンネルがすでにプロトコルを運べることを前提にしていますが、ASA ではまず確認すべきなのはまさにその前提です。比較が意味を持つのは、イメージ、VTI の種類、multicast の経路が確認できた後です。この順序を誤ると、隣接が決して形成されないトンネルでタイマーを調整して半日を費やすことになります。私はこの種の設計をいつも、リリースノートと稼働中の設定から始め、プロトコルの好みからは始めません。
プロトコルより先にリリースが決める
Cisco の ASA 9.24 VTI ガイド は使える文書の土台で、静的 VTI と動的 VTI を説明し、静的ルーティング、BGP、OSPF、EIGRP を列挙しています。機能履歴では、VTI 上の OSPFv2 と EIGRP の対応が 9.19(1) とされています。それより古い話は別の議論です。
つまり最初の二つの問いは地味ですが決定的です：
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
ASA は VTI を使えない、あるいは IGP を運べないという記述は、一部の古いイメージには当てはまりましたが、現在のサポート表ではありません。同様に、9.24 のガイドはすべての機器を更新せよという指示ではありません。そのリリースが何を支えるかを示すもので、導入済みのリリースが自分で答えなければなりません。
unicast が通ることと IGP が形成されることは別です
同じガイドは、unicast は既定で通るが multicast は VTI 上の OSPFv2 または EIGRP のために有効にする必要があると述べ、multicast グループの制限も文書化しています。この一文が、この設計で私が見てきた隣接失敗のほとんどを説明します。トンネル越しに通る ping や緑の IPsec ステータスは、unicast の経路しか証明しません。プロトコルの検出には multicast の経路が必要で、両者は別々に設定します。
hello や hold のタイマーに触れる前に、トンネルインターフェースの設定でその multicast 設定を確認してください。設定がなければ、隣接は遅いのではなく不可能です。
同じトンネル上で OSPF と EIGRP を並べる
トンネル上では、両プロトコルは他の場所と同じ姿をしています。OSPF には 一致するネットワーク種別、エリア、認証、ネイバーパラメータが必要で、EIGRP には AS 番号と、それに付随するインターフェース単位の設定が必要です。
罠は、別のトンネルモデルからネイバーの記述をコピーすることです。VTI を使わない設計での静的ネイバーの助言は multicast を避けるためのもので、プロトコルをネイティブに運ぶことを期待する VTI には当てはまりません。対応するインターフェース動作を設定し、あとはプロトコル自身に隣接を形成させてください。
そのうえで、自分のトポロジーで実際に差が出る軸、つまり相手側との相互運用性、試せる収束の挙動、チームの運用知識で比較します。あるプロトコルのほうが速い、軽いという歴史的な逸話は、あなたのネットワークの測定値ではありません。
ネイバーはインストール済みルートと同じではありません
隣接が上がったら、生成されるものと受け入れられるものを分けてください。各側がどの支店プレフィックスを広告し、どれが受信され、どれが選択され、どれが実際にルーティングテーブルに届くかを見ます。インポート、エクスポート、再配布の範囲は、機器が知るすべてを一律に広告するのではなく、意図的に決めるべきです。
show ospf neighbor と show eigrp neighbors は、セッションが生きていることを示します。 show route は、支店プレフィックスが届いたかどうかを示し、これは別の問いです。
アプリケーションの経路はまた別の三つ目の問いです。ネイバー関係は到達性を配布しますが、ファイアウォール越しの許可を与えるものではなく、トラフィックセレクタとフィルタ規則が一致することも証明しません。許可されたフローとその戻り経路は、ルートがポリシーを意味すると決めつけず、承認済みの試験で確認してください。
完成した比較に記録すべきこと
トンネルインターフェース、それを支えるリリース、確認した制御交換、範囲を定めたルートポリシーを書き留め、multicast 設定も加えてください。残りが機能するかどうかを静かに決めるのはこの細部です。その記録を導入済みリリースのそばに置けば、後の機能変更を、いまや期限切れの前提からやり直さずに検討できます。
この四つのどれかが欠けていれば、それは設計ではなく好みです。まず欠けた事実を直すべきで、プロトコルの選択は簡単な部分です。