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

  • URLをコピーしました!
目次

はじめに

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

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

この記事でわかること
  • OSPF Multi-VRF 環境で LSA Type-3 が反映されない原因
  • DN Bit の仕組みとループ防止機能の概要
  • capability vrf-lite の機能範囲(DN Bit 無効化・Domain-Tag チェック無効化・自動 ABR 抑止)
  • IOS / IOS XE / IOS XR / NX-OS におけるコマンド差異
  • VRF-lite 環境における設計上の注意点とトラブルシューティング

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

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

一般的な OSPF ネットワークにおいて、エリアを跨いでルート情報を伝播させる際には、ABR(Area Border Router)によって生成される LSA Type-3(Summary 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 チェックを実行している ために起こります。具体的には、ospf dn bit(down bit / dnbit)と呼ばれるフラグの存在と、それに付随するチェック機構が、この挙動に関わっています。

参考: Cisco / IP Routing: OSPF Configuration Guide, IOS XE Fuji 16.9.x – OSPF Support for Multi-VRF on CE Routers
“The OSPF Support for Multi-VRF on CE Routers feature provides the capability to suppress provider edge (PE) checks that are needed to prevent loops when the PE is performing a mutual redistribution of packets between the OSPF and BGP protocols.”
(Multi-VRF on CE Routers 機能は、PE が OSPF と BGP 間で相互再配送を行う際にループ防止のために必要な 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(Downward)を付与します。別の 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
  LS Seq Number: 8000000C
  Checksum: 0x4908
  Length: 28
  Network Mask: /32
        MTID: 0         Metric: 1

公式ドキュメント(OSPF Command Reference)には、DN Bit の取り扱いについて以下のような記述があります。

参考: Cisco / OSPF Command Reference
“Type-3 LSA received: The DN bit is checked. If the DN bit is set, the Type-3 LSA is not considered during the shortest path first (SPF) calculation.”
(受信した LSA Type-3 は DN Bit が確認され、DN Bit が立っている場合は SPF 計算の対象外となります)

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

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

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

コマンドの機能範囲

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

無効化される動作内容
DN Bit チェック受信した LSA の DN Bit が立っていても SPF 計算の対象に含める
Domain-Tag チェックLSA に付与された Domain-Tag(OSPF プロセス番号由来)の整合確認をスキップ
OSPF 自動 ABR ステータスVRF 内で OSPF が稼働すると自動的に ABR 扱いになる動作を無効化(Area 0 と非バックボーンエリアの両方が VRF 内に存在する場合のみ ABR として動作)

参考: Knowledge Base / Multi-VRF or VRF-Lite
“The capability vrf-lite command disables the DN-bit (down bit) and domain-tag checks in OSPF. Since the CE router acts as the PE router in VRF-lite, these checks should be disabled, because the PE routers advertise VPN routes with DN-bit set.”
capability vrf-lite コマンドは OSPF の DN-bit と Domain-Tag のチェックを無効化します。VRF-lite では CE ルータが PE ルータと同等の動作になるため、これらのチェックを無効化する必要があります)
https://sites.google.com/site/amitsciscozone/mpls/multi-vrf-or-vrf

設定手順

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

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

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

capability vrf-lite コマンドの適用前は、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 / IP Routing: OSPF Configuration Guide, IOS XE Fuji 16.9.x – OSPF Support for Multi-VRF on CE Routers
“When the OSPF VRF process is configured with the capability vrf-lite command under the router ospf command, the ‘Connected to MPLS VPN Superbackbone’ line will not be present in the display.”
(OSPF VRF プロセスに capability vrf-lite コマンドを設定すると、Connected to MPLS VPN Superbackbone の行は表示されなくなります)
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 を選ぶ形になります。プラットフォームごとの差異を整理します。

プラットフォームDN Bit のみを無効化PE チェック全体を無効化 ※DN Bit + Domain-Tag + 自動 ABR設定箇所
IOS / IOS XE(個別コマンドなし)capability vrf-literouter ospf <process> vrf <name> 配下
IOS XRdisable-dn-bit-checkcapability vrf-literouter ospf または router ospfv3 の VRF コンフィグ配下
NX-OS(個別コマンドなし)capability vrf-lite [evpn]router ospf <tag>vrf 配下

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 Release 6.2.x
“To specify that down bits should be ignored, use the disable-dn-bit-check command in VPN routing and forwarding (VRF) configuration mode.”
(DN Bit を無視する設定には、VRF コンフィグレーションモードで 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-liteevpn オプション が追加で指定できます。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 (Configuration Commands)
“[no] capability vrf-lite [ evpn ]”
(構文: [no] capability vrf-lite [evpn]、設定モード: /exec/configure/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 による経路フィルタ: 特定方向への経路の流入・流出を制限する

実運用環境への適用前には、シミュレータ等を用いてトポロジ全体の動作を検証することをおすすめします。手軽な検証環境の構築については、当ブログの関連記事『Packet Tracer のインストールから使い方まで』(https://mytech-blog.com/cisco-packet-tracer/)も参考にしてください。

CEF 必須要件

公式ドキュメントには、本機能の前提として 「CEF must be running on the network」 と明記されています。CEF(Cisco Express Forwarding)が無効化されている環境では本機能の動作が想定通りにならない可能性があるため、show ip cef summary などで動作状況を確認しておくことをおすすめします。

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

公式ドキュメントには、本機能専用の show / debug コマンドは用意されていない旨が明記されています。適用確認は「Connected to MPLS VPN Superbackbone」の表示有無や、ルーティングテーブルの変化で間接的に行う形になります。

参考: Cisco / IP Routing: OSPF Configuration Guide, IOS XE Fuji 16.9.x – OSPF Support for Multi-VRF on CE Routers
“CEF must be running on the network. … No specific debug or show commands are associated with this feature.”
(ネットワーク上で CEF が動作している必要があります。本機能に紐づく専用の debug / show コマンドは用意されていません)
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

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

設定変更後もルートが反映されない場合、以下のコマンドを順に実行することで原因を切り分けることができます。

STEP
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 ステータスが意図どおりか確認

capability vrf-lite 適用前は「Connected to MPLS VPN Superbackbone」が表示され、適用後は消えます。これがコマンド適用の最も確実な確認手段です。

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

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

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

確認ポイント

  • Options フィールドに Downward が表示されている → DN Bit が立っている(対向が DN Bit を付与する装置の可能性)
  • Options フィールドに Upward のみが表示されている → DN Bit は付与されていない(VRF-lite 純粋構成)

VRF-lite 構成にもかかわらず Downward が表示される場合、対向側がすでに PE 動作になっている可能性があります。

STEP
OSPF ネイバー関係の確認

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

R1#show ip ospf neighbor vrf poc

確認ポイント

  • StateFULL/DR または FULL/BDR(broadcast 系)、FULL/-(point-to-point 系)になっているか
  • Neighbor ID が想定どおりの対向ルーター ID か
STEP
ルーティングテーブルへの反映確認

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

R1#show ip route vrf poc ospf | begin Gateway

確認ポイント

  • O IA 行が新たに表示されているか(適用前は表示されない)
  • 該当ネクストホップが想定どおりのインターフェース・対向 IP を指しているか
STEP
設定の最終確認

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

R1#show running-config | section router ospf

確認ポイント

  • router ospf <プロセス番号> vrf <VRF 名> 配下に capability vrf-lite の行が存在するか
  • グローバル OSPF プロセス(VRF を持たないプロセス)に誤って設定していないか

コマンドの適用箇所が VRF プロセス配下になっているかは見落としやすいポイントです。 VRF を伴わない OSPF プロセスにこのコマンドを設定しても、PE チェックは VRF プロセスでのみ働くため効果はありません。

まとめ

本記事では、OSPF Multi-VRF 環境で発生する LSA Type-3 の学習不能トラブルと、その解決策である capability vrf-lite コマンドについて整理しました。

  • OSPF Multi-VRF 環境では PE チェックの動作によって LSA Type-3 が SPF 計算から除外される仕様がある
  • MP-BGP を使わない VRF-lite 構成でも PE チェックが働き、DN Bit の有無に関わらずルートが除外される動作になる
  • 解決には OSPF プロセス(VRF 側)への capability vrf-lite コマンドの設定で対応できる
  • このコマンドは DN Bit チェック・Domain-Tag チェック・自動 ABR ステータスの 3 つを同時に無効化する
  • IOS XR では DN Bit のみを無効化する disable-dn-bit-check という別コマンドが用意されており、用途に応じて使い分けが必要
  • NX-OS では capability vrf-lite [evpn] として evpn オプションが追加されている
  • ループ防止機構をオフにするため、冗長構成での再配送設計には route-map や OSPF tag によるループ対策の併用をおすすめする

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

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ(ネットワーク・サーバ・クラウド・セキュリティ)の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus(取得から20年以上)/ VCAP-DCA / Azure Solutions Architect Expert

▶ 運営者プロフィール(詳細)

目次