2.2データパス仮想化の設定と検証（VRF・GRE・IPsec）

前節が「箱の仮想化」だとすれば、この節は経路そのものの仮想化です。物理的には1本のリンク・1台のルータでも、論理的には複数の独立した経路空間を重ねられます。VRFは1台の中にルーティングテーブルを複数持たせて顧客/部門ごとに経路を完全分離し、GREは中間のネットワークを気にせず「2点を直結したかのような」論理リンクを張ります。ただしGREには暗号化がないため、公衆網を跨ぐならIPsecと組み合わせる必要があります。ここで問われるのは概念の定義ではなく、どの要件にどれを選ぶかと、トンネルが上がらない/フラップするときにどこを見るかです。

2.2.1VRF による経路分離

• VRF（Virtual Routing and Forwarding）＝1台のルータ/L3スイッチの中に独立したルーティングテーブル（と転送テーブル）を複数持たせる仕組み。VRFごとに経路空間が完全に分かれるため、異なるVRFであれば同じIPアドレス空間（例：どちらも 10.1.1.0/24）が重複していても共存できる。機器を分けずに顧客/部門/管理系トラフィックを分離できるのが最大の利点。
• 設定はVRFを定義し、インタフェースをVRFに所属させ、そのVRFにIPを付けるという順序が要点。vrf definition CUST_A で定義し（アドレスファミリを address-family ipv4 で有効化）、インタフェース配下で vrf forwarding CUST_A を入れてから ip address ... を設定する。インタフェースをVRFに入れると既存のIPアドレス設定は消えるため、順序を誤ると既存の疎通が落ちる。
• 検証もVRFを明示するのが鉄則。既定（グローバル）テーブルを見る show ip route には VRF の経路は出ないため、show ip route vrf CUST_A を使う。疎通確認も ping vrf CUST_A 10.1.1.1、traceroute vrf CUST_A ... のようにVRF指定が要る。所属の一覧は show vrf（またはインタフェース別に show ip vrf interfaces）で確認する。

2.2.2GRE トンネルの構成と検証

• GRE（Generic Routing Encapsulation）＝任意のL3プロトコルを新しいIPヘッダで包み、中間網を「1ホップの論理リンク」に見せるトンネル。マルチキャストやIGP（OSPF/EIGRP）といったIPsec単体では運べないトラフィックを運べるのが利点。ただしカプセル化のみで暗号化は一切行わない——ペイロードは平文のまま流れる。
• 設定は interface tunnel 0 に対し tunnel source（自分側の実IF/IP）・tunnel destination（相手側の到達可能な実IP）・トンネル内側の ip address を与える。既定のトンネルモードが GRE over IP（tunnel mode gre ip）である。検証は show interfaces tunnel 0 で line protocol の状態と入出力を見る。
• GREの典型障害は3つ。(1) トンネル宛先へ実網で到達できない（tunnel destination へのルート/疎通がない）→ line protocol が down。(2) 再帰ルーティング（recursive routing）＝トンネルの宛先アドレスへの経路自体をトンネル経由で学習してしまい、%TUN-5-RECURDOWN とともにトンネルがフラップする。→ トンネル宛先をトンネル内で広報しない（あるいはスタティック/別経路で到達させる）。(3) MTU/フラグメント＝GREヘッダ24バイト分でパスMTUを超え、DFビット付きの大きなパケットが落ちる → ip mtu 1400 や ip tcp adjust-mss 1360 で緩和する。

2.2.3IPsec と GRE over IPsec

• IPsec＝IP層で機密性（暗号化）・完全性・認証・リプレイ防護を提供するフレームワーク。IKEで鍵交換とSA（セキュリティアソシエーション）確立を行い、ESPでペイロードを暗号化する（AHは認証のみで暗号化しない）。ただし素の IPsec（従来のcrypto map方式）はユニキャストのIPトラフィックが主対象で、マルチキャストやIGPのHelloをそのままでは運べない。
• そこで実務ではGRE over IPsec＝GREで包んでからIPsecで暗号化する組み合わせを使う。GREがマルチキャスト/IGPを運べるようにし、IPsecが機密性を与えるため、動的ルーティングが動く暗号化WANが作れる。設定はトンネルIFに tunnel mode gre ip を置いたうえで、IPsecプロファイルを tunnel protection ipsec profile <名前> で適用するのが現在の標準的な書き方。
• 検証は層ごとに分ける。トンネルの上下は show interfaces tunnel 0、IKEのフェーズ1は show crypto isakmp sa（IKEv2 は show crypto ikev2 sa）、フェーズ2/実データの暗号化は show crypto ipsec sa で encaps/decaps のカウンタが両方向で増えているかを見る。片方向しか増えないなら、戻り経路の遮断や相手側のポリシー不一致（トランスフォームセット/暗号スイート・対象トラフィック定義）を疑う。

本社と支社をインターネット越しに結ぶWANを、GREトンネル上で OSPF を走らせる構成で新設しました。トンネルは一度 up になり OSPF 隣接も張れたのですが、数十秒おきにトンネルが down/up を繰り返し、ログには %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing が出続けています。ここで「回線品質が悪い」「ISP障害だ」と外部要因に流れるのは、メッセージが明確に原因を告げているのに読み飛ばした判断です。再帰ルーティングとは、トンネルの宛先（tunnel destination に指定した相手の実IP）へ至る経路を、そのトンネル自身を経由して学習してしまった状態を指します。今回の直接の引き金は、OSPFの network 文の範囲が広すぎて、トンネルの終端に使っている外部向けIF/実IPのネットワークまで OSPF で広報してしまったことです。すると相手から「その宛先はトンネル経由で行ける」と学習し、トンネルを張るためにトンネルを通る、という自己参照が成立します。IOS はこれを検知してトンネルを一時的に落とすので、down → 経路が消える → 実網経由に戻る → up → また学習する、というフラップのループになります。是正の筋は明確で、トンネルの宛先へは、トンネルの内側で学習しない経路（実網のスタティックルート、あるいは別のIGP/プロバイダ経路）で到達させることです。具体的には OSPF の広報対象から外部向けIFのネットワークを外す（network 文を精緻化する、あるいは当該IFを passive-interface にするだけでは不十分で広報自体を止める）、必要ならトンネル宛先へのスタティックルートを明示する、という手を打ちます。切り分けの手順としては、まず show ip route <tunnel destinationのIP> を打ち、その経路の出力インタフェースが Tunnel0 になっていないかを見るのが決定打です。ここが Tunnel0 を指していれば再帰ルーティングが確定します。なお同じ構成でよく併発するのがMTU起因の症状で、こちらはトンネルは安定して up のまま大きなパケットだけが通らない（小さな ping は通るがファイル転送やHTTPSが固まる）という別の見え方をします。「トンネルが落ちる＝再帰ルーティング/宛先到達性」「トンネルは上がっているのに大きい通信だけ落ちる＝MTU/MSS」と症状で切り分けられることが、この節の実務的な核心です。

2.2.4この節のまとめ

• VRFは1台の中に独立したルーティングテーブルを複数持ち、異なるVRFならアドレスが重複しても共存できる。設定は vrf forwarding → ip address の順、検証は show ip route vrf X／ping vrf X
• GREはカプセル化のみ（暗号化なし）だがマルチキャスト/IGPを運べ、IPsecは暗号化するが単体ではマルチキャストを運べない。両立はGRE over IPsec
• トンネル障害は症状で切り分ける：フラップ＋%TUN-5-RECURDOWN＝再帰ルーティング（show ip route <宛先> の出力IFがTunnelなら確定）、up のまま大きい通信だけ失敗＝MTU/MSS（ip mtu／ip tcp adjust-mss）