capability vrf-lite と DN Bit の役割｜OSPF Multi-VRF の落とし穴

はじめに

OSPF の Multi-VRF 環境を構築する際、データベース上にはルートが存在するにもかかわらず、ルーティングテーブルに LSA Type-3 のルートが反映されないという事象に遭遇することがあります。

本記事では、このルート学習トラブルの原因となる DN Bit の仕様と、解決策となる capability vrf-lite コマンドの役割を整理します。検証は Cisco IOS XE 16.9 / 17.x 系（17.x が現行トレイン）を前提とし、NX-OS / IOS XR での挙動の違いも後半で補足します。

VRF と VRF-lite の違い

本題に入る前に、VRF と VRF-lite の関係を整理します。

VRF（Virtual Routing and Forwarding）は、1 台の機器内でルーティングテーブルを論理的に分割し、複数の独立した経路表を持たせる技術です。これに対して VRF-lite は、MPLS / MP-BGP を使わずに、VRF をインターフェース単位で機器間に接続し、複数の機器にまたがらせる構成を指します。各機器が個別に VRF を定義し、リンクごとに対応づけます。

フルの MPLS L3VPN との違いは、コア網（MP-BGP + MPLS）を共有するかどうかです。L3VPN では PE 間を MP-BGP と MPLS で結んでコアを共有しますが、VRF-lite ではコアを使わず、CE 相当の機器どうしが VRF インターフェースで直接接続します。

この違いが、本記事のトラブルに直結します。OSPF を VRF 上で動作させると、Cisco の機器はその機器を PE 相当とみなし、ループ防止のための「PE チェック」を実行します。VRF-lite では機器は実際には PE ではないため、このチェックが意図しないルート除外を招くことになります。

OSPF Multi-VRF 環境でルートが反映されない事象

検証構成と発生したトラブルの概要

一般的な OSPF ネットワークでは、エリアを跨いでルート情報を伝播させる際に、ABR（Area Border Router）が生成する LSA Type-3（Summary LSA）が利用されます（エリア設計と ABR の基礎は関連記事『OSPF とは｜仕組みを図解で理解する LSA・エリア・コストの基礎』を参照）しかし Multi-VRF 環境では、データベース上に該当の LSA が存在しているにもかかわらず、ルーティングテーブルに反映されないトラブルが発生することがあります。

LSA Type-3（Summary LSA）のみが反映されない原因

LSA Type-1（Router LSA）や、再配布によって生成される LSA Type-5（AS External LSA）は、Multi-VRF 環境でも問題なく学習され、ルーティングテーブルに反映されます。一方で、LSA Type-3 だけが計算から除外される事象は、OSPF プロセスがループ防止のために PE チェックを実行しているために起こります。具体的には、DN Bit（down bit）と呼ばれるフラグと、それに付随するチェック機構がこの挙動に関わっています。

参考: Cisco「OSPF Support for Multi-VRF on CE Routers」（IOS XE）
“suppress provider edge (PE) checks that are needed to prevent loops”
（ループ防止のために必要な PE チェックを抑制する。）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-16-9/iro-xe-16-9-book/iro-sup-vrf.html

DN Bit によるループ防止機能の仕組み

DN Bit（Downward Bit）とは

DN Bit は、主に MP-BGP を用いた L3VPN 環境で、PE ルーター間のルーティングループを防止するためのフラグです。仕様は RFC 4576（OSPFv2 における DN Bit）および RFC 4577（OSPF を CE-PE 間で使う場合の仕様）に定義されています。

PE ルーターが MP-BGP から学習したルートを OSPF へ再配布して CE ルーターへ広報する際、該当 LSA の Options フィールドに DN Bit を付与します。別の PE ルーターがこの DN Bit 付き LSA を受信すると、そのルートは SPF 計算の対象外となります。これにより、拠点側へ配信したルートが再びバックボーン網へループする現象を防げます。

MP-BGP を使用しない環境での挙動

今回検証したような MP-BGP を使用しない VRF-lite 環境では、本来 DN Bit は付与されません。実機で show ip ospf database summary を実行して LSA の詳細を確認しても、Options 項目に Downward は表示されません。

R1# show ip ospf database summary
            OSPF Router with ID (192.168.1.101) (Process ID 1)
                Summary Net Link States (Area 1)
  LS age: 751
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.2.2.1 (summary Network Number)
  Advertising Router: 192.168.1.102
  ...

公式のコマンドリファレンスでは、受信した LSA Type-3 は DN Bit が確認され、DN Bit が設定されている場合は SPF 計算の対象から除外されると説明されています（Cisco IOS OSPF Command Reference: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/command/iro-cr-book/ospf-a1.html ）

この説明を文面どおり解釈すると「DN Bit が付与されていない LSA Type-3 は SPF 計算の対象になる」と読み取れます。一方で実際には、OSPF プロセスを VRF 上で稼働させた時点で、DN Bit チェックだけでなく、後述の Domain-Tag チェックや OSPF ABR 自動ステータスを含む「PE チェック」と総称される処理が有効になり、結果として LSA Type-3 がルーティングテーブルから除外される挙動となります。

過去にメーカーへ問い合わせた際にも、公式ドキュメントの記述と実際の動作との間に乖離があるとの指摘を受けた経緯があるとの回答を得ています。なお、IOS XE 16.9 以降の公式ドキュメントでは「PE チェックを抑制する機能」として明確に位置づけられ、現行リリースでは仕様として整理されています。

解決策: capability vrf-lite コマンド

コマンドの機能範囲

VRF 環境下でも LSA Type-3 をルーティングテーブルに反映させるには、capability vrf-lite コマンドを使用します。該当する OSPF プロセス（VRF 側）に適用することで、PE チェックを構成する 3 つの動作が同時に無効化されます。

参考: Cisco「Routing Command Reference」（capability vrf-lite）
“ignore DN bit in LSAs received from peers in the given VRF”
（指定した VRF で、対向から受信した LSA の DN Bit を無視する。）
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/routing/command/reference/b-routing-cr-asr9000/ospf-commands.html

設定手順

設定は OSPF プロセス（VRF 側）の配下に 1 行追加するだけです。

R1(config)# router ospf 1 vrf poc
R1(config-router)# capability vrf-lite
R1(config-router)# end

設定適用後のルーティングテーブルの変化

適用前は、Type-1 と Type-5 のルートのみが学習されていました。

R1# show ip route vrf poc ospf | begin Gateway
Gateway of last resort is not set
      10.0.0.0/32 is subnetted, 1 subnets
O        10.2.2.2 [110/2] via 192.168.1.102, 00:08:33, GigabitEthernet2
      172.16.0.0/32 is subnetted, 1 subnets
O E2     172.16.2.1 [110/1] via 192.168.1.102, 00:08:33, GigabitEthernet2

適用後は、除外されていた LSA Type-3 が SPF 計算の対象となり、O IA としてルート（10.2.2.1）が反映されます。

R1# show ip route vrf poc ospf | begin Gateway
Gateway of last resort is not set
      10.0.0.0/32 is subnetted, 2 subnets
O IA     10.2.2.1 [110/2] via 192.168.1.102, 00:04:37, GigabitEthernet2
O        10.2.2.2 [110/2] via 192.168.1.102, 00:04:37, GigabitEthernet2
      172.16.0.0/32 is subnetted, 1 subnets
O E2     172.16.2.1 [110/1] via 192.168.1.102, 00:04:37, GigabitEthernet2

show ip ospf 出力の変化

capability vrf-lite を適用すると、show ip ospf の出力から「Connected to MPLS VPN Superbackbone」の行が表示されなくなります。この行の有無で、コマンドが正しく適用されているかを確認できます（参考: 前掲 Cisco「OSPF Support for Multi-VRF on CE Routers」 https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-16-9/iro-xe-16-9-book/iro-sup-vrf.html ）

プラットフォーム別コマンドの違い

capability vrf-lite は IOS / IOS XE / NX-OS で共通のコマンド名ですが、IOS XR では DN Bit チェックのみを無効化する別コマンド disable-dn-bit-check が用意されています。OSPF ABR 動作の抑止まで含めて無効化したい場合は、IOS XR でも capability vrf-lite を使用します。

IOS XR の disable-dn-bit-check を使う場面

IOS XR では、Domain-Tag チェックや自動 ABR ステータスは維持したまま、DN Bit のみを無視したいケースがあります。たとえば、自機を意図的に ABR として扱いつつ、対向の PE から DN Bit 付き LSA を受け取って SPF 計算に含めたい構成では、capability vrf-lite を使うと ABR 動作まで変わってしまうため、disable-dn-bit-check が適しています。

RP/0/RP0/CPU0:router(config)# router ospf 1
RP/0/RP0/CPU0:router(config-ospf)# vrf v1
RP/0/RP0/CPU0:router(config-ospf-vrf)# disable-dn-bit-check

参考: Cisco「Routing Command Reference for Cisco CRS Routers」（IOS XR）
“To specify that down bits should be ignored, use the disable-dn-bit-check command”
（DN Bit を無視する設定には disable-dn-bit-check コマンドを使用する。）
https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs-r6-2/routing/command/reference/b-routing-cr-crs-62x/m-ospf-commands.html

NX-OS の capability vrf-lite [evpn] オプション

NX-OS（Nexus 9000 / 7000 系）では、capability vrf-lite に evpn オプションを追加で指定できます。VXLAN EVPN 環境で OSPF を CE として併用する場合に有効化する形で、データセンターファブリックの構成検討時に押さえておきたい差異です。

N9K(config)# router ospf 1
N9K(config-router)# vrf TENANT-A
N9K(config-router-vrf)# capability vrf-lite

参考: Cisco「Nexus 9000 Series NX-OS Command Reference」
“[no] capability vrf-lite [ evpn ]”
（構文。設定モードは router-ospf/vrf 配下。）
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/command_references/configuration_commands/b_N9K_Config_Commands_703i5x/b_N9K_Config_Commands_703i5x_chapter_011.html

設計時に押さえたい制約事項

capability vrf-lite は便利な機能ですが、設計段階で把握しておかないと意図しない挙動につながります。導入前に確認したい制約を整理します。

MPLS L3VPN 環境との併用に関する制約

capability vrf-lite を有効化すると、OSPF プロセスが MPLS Superbackbone と論理的に切り離されます。show ip ospf の出力から「Connected to MPLS VPN Superbackbone」の行が消え、MP-BGP 経由で広告される LSA との連携を前提とした動作（Domain-Tag による Type 変換など）が無効になります。

このため、MPLS L3VPN の PE ルーターを兼ねる装置で capability vrf-lite を有効化することは推奨されません。Inter-AS Option A（Back-to-Back VRF 構成）など、PE と CE の境界が曖昧な構成で利用する場合は、トポロジ全体への影響を事前に検証することをおすすめします。

OSPF ABR 動作の変化

capability vrf-lite を有効化すると、OSPF VRF プロセスが自動的に ABR 扱いになる動作が抑制されます。適用後に当該ルーターが ABR として動作するのは、Area 0（バックボーンエリア）と非バックボーンエリアの両方が同一 VRF 内に存在する場合のみに限定されます。意図せず ABR でなくなることでサマリ LSA の生成が止まる可能性があるため、エリア設計を確認したうえで適用することをおすすめします。

冗長構成・複数再配布ポイントでのループリスク

冗長 PE 環境や、複数地点で OSPF と他プロトコル（BGP / EIGRP）の相互再配布を行う構成では、PE チェックを無効化することで意図しないルーティングループが発生する可能性があります。以下の対策の併用をおすすめします。

• OSPF tag による識別: 再配布時にタグを付与し、再度の再配布時にタグでフィルタする。
• route-map による方向制御: 再配布する方向と対象プレフィックスを明示的に制御する。
• distribute-list による経路フィルタ: 特定方向への経路の流入・流出を制限する。

これらの再配布・広報制御の具体的な設定は、関連記事『Cisco ルーターでの OSPF 設定手順とマルチエリア構成のコンフィグ例』で扱っています。実運用環境への適用前には、シミュレーター等でトポロジ全体の動作を検証することをおすすめします。手軽な検証環境の構築については、当ブログの関連記事『Cisco Packet Tracer の使い方｜実機なしで CCNA 学習を進める手順』も参考にしてください。

CEF 必須要件

公式ドキュメントでは、本機能の前提として CEF（Cisco Express Forwarding）がネットワーク上で動作している必要があると明記されています。CEF が無効化されている環境では動作が想定どおりにならない可能性があるため、show ip cef summary などで動作状況を確認することをおすすめします。

専用の show / debug コマンドが用意されていない

公式ドキュメントでは、本機能に紐づく専用の show / debug コマンドは用意されていないと明記されています。適用確認は「Connected to MPLS VPN Superbackbone」の表示有無や、ルーティングテーブルの変化で間接的に行います（参考: 前掲 Cisco「OSPF Support for Multi-VRF on CE Routers」 https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-16-9/iro-xe-16-9-book/iro-sup-vrf.html ）

動作確認とトラブルシューティングの基本コマンド

設定変更後もルートが反映されない場合、以下を順に実行して原因を切り分けます。

1. OSPF プロセスへの適用確認

capability vrf-lite が正しく適用されているかは、show ip ospf の出力で確認します。

R1# show ip ospf 1 vrf poc | include Border|MPLS

「Connected to MPLS VPN Superbackbone」の行が表示されなければ適用済みです。あわせて「It is an area border router」の表示有無で、ABR ステータスが意図どおりかを確認します。この行の有無が、コマンド適用の最も確実な確認手段になります。

2. LSA データベース上の DN Bit 確認

該当の LSA Type-3 が DN Bit 付きで広告されているかを確認します。

R1# show ip ospf database summary <ネットワークアドレス>

Options フィールドに Downward が表示されていれば DN Bit が立っています（対向が DN Bit を付与する装置の可能性）。Upward のみであれば DN Bit は付与されていません（VRF-lite の純粋構成）。VRF-lite 構成にもかかわらず Downward が表示される場合、対向側がすでに PE 動作になっている可能性があります。

3. OSPF ネイバー関係の確認

ネイバーが FULL で確立していなければ、そもそも LSA が交換されていません。VRF を指定して確認します。

R1# show ip ospf neighbor vrf poc

State が FULL（broadcast 系は FULL/DR・FULL/BDR、point-to-point 系は FULL/-）か、Neighbor ID が想定どおりの対向ルーター ID かを確認します。ネイバーが確立しない場合の切り分けは、関連記事『OSPF ネイバーが確立できない原因｜状態別の切り分け手順』を参照してください。

4. ルーティングテーブルへの反映確認

capability vrf-lite 適用後、O IA ルートが学習されているかを確認します。

R1# show ip route vrf poc ospf | begin Gateway

O IA 行が新たに表示されているか、ネクストホップが想定どおりのインターフェース・対向 IP を指しているかを確認します。

5. 設定の最終確認

OSPF プロセス（VRF 側）に capability vrf-lite が記述されているか、設定そのものを確認します。

R1# show running-config | section router ospf

router ospf <プロセス番号> vrf <VRF 名> 配下に capability vrf-lite の行が存在するか、グローバル OSPF プロセス（VRF を持たないプロセス）に誤って設定していないかを確認します。PE チェックは VRF プロセスでのみ働くため、VRF を伴わない OSPF プロセスにこのコマンドを設定しても効果はありません。

まとめ

OSPF を VRF 上で動作させると、Cisco の機器は PE 相当とみなして PE チェックを実行し、VRF-lite では LSA Type-3 が意図せず SPF 計算から除外されます。capability vrf-lite はこのチェックを無効化してルートを学習可能にしますが、ループ防止機構をオフにするため、冗長構成では併用するループ対策の設計が必要です。

• VRF 上の OSPF で働く PE チェックによる LSA Type-3 の除外
• MP-BGP を使わない VRF-lite でも DN Bit の有無に関わらず除外
• 解決は VRF 側 OSPF プロセスへの capability vrf-lite 適用
• DN Bit・Domain-Tag・自動 ABR の 3 チェックを同時に無効化
• IOS XR は DN Bit のみ無効化する disable-dn-bit-check を併設
• NX-OS は evpn オプション付きの capability vrf-lite
• 冗長構成では route-map・OSPF tag によるループ対策の併用

以上、最後までお読みいただきありがとうございました。