先日CCNPイージスを参照しながらOSPFの学習をしており、以下のコマンドを何も考えず投入したところエンド間で通信できない事象が発生しました。
上記コマンドが原因とはわかったのですが、日本語で解説された記事が一つもなかったため今回投稿させていただきました（初投稿）。
※レイアウトは徐々によくしていきます…ご勘弁を
①事の発端
CCNPイージスにある以下のリンクの記事を見ながらルータにコマンドを投入(R5のGi0/0へ投入と仮定)
【コマンド】
・ip ospf database-filter all out
・ip ospf flood-reduction
https://www.infraexpert.com/study/ospfz29.html (OSPF LSA control)
その結果、
・図１のトポロジでR4のみ仮想リンクがダウン。
・R4のルーティングテーブルのみ、Area20とRIPから再配送されているルート情報が載らない事態となった。
■図１：トポロジ図
※補足：EIGRP↔OSPF、OSPF↔RIPは再配送を実施
②調査
・まずR4,5,6でdebug ip ospf adjを投入し、clear ip ospf processを投入してプロセス再起動を実施。
R4のデバッグ画面に表示される情報からR3,R5とネイバー関係・アジャセンシー関係ともに成立していることを確認。
・R4,5,6へshow ip routeを投入し、R4のみルーティングテーブルを確認してもOSPFで配布されているルートが一部ないことを確認。
・その後、R4,5,6のshow ip ospf databaseを確認すると R4のみ一部のType3以降のルート情報がないことを確認。
⇒以上から、LSAは正常に交換されているが、LSAの中身が空の可能性であることに気づく。
③調査その２
・上記のコマンドを投入したからR1-R9にて通信不可となった。上記コマンドが悪さをしていることはわかったため、ググってみる。
すると、コマンド内容について解説している記事は海外サイトのみ！Cisco Communityにも解説はあったがいまいちわかりにくい。
さらにいくつかリンクを踏んでみると、丁寧に解説しているサイトがあった(以下参照)。
https://lpmazariegos.com/2016/04/06/ospf-lsa-database-filtering-and-flood-reduction/
上記のサイトを見れば解説が書かれているが英語苦手な人向けに説明すると(以下転載)
■OSPF database-filter:
With OSPF database-filter is possible the blocking of LSA flooding in the outbound direction. To configure this feature use the command ip ospf database-filter all out to the interface that connects to the area to be filtered. This command can also be used to block LSA flooding to specific neighbors in point-to-multipoint networks. This is achieved by using the OSPF process command neighbor {ip-address} database-filter all out, where the ip address is the one assigned to the interface connecting to the area, not be confused with the neighbor’s router-id.
⇒LSAを受信したI/F以外から出さなくなる(通常はLSAを受信すると、そのLSAを受信したI/F以外の同じエリアに属しているI/Fから、同じLSAを送信する)
■OSPF flood-reduction:
With OSPF flood-reduction, the unwanted flooding is achieved by setting the DoNotAge (DNA) bit in the LSAs, therefore, the LSAs do not have to be refreshed every 30 minutes. To configure this feature use the ip ospf flood-reduction command to the desired interface.
⇒LSAパケットにDNA bitを付与することで、30分毎にLSAの更新を行わなくなる(更新期間はデフォルトで30分。変更可能。)
When any of the above-described techniques is configured on an already established neighbor relationship, the adjacency will flap.
⇒ネイバー関係が成立しているルータに上記2つのコマンドを投入すると、I/Fがフラップする。
・上記より、どうやらip ospf database-filter all outが悪さをしていることが判明。
このコマンドを削除したところ無事にR1-R9で通信できるようになった。
③showコマンド出力結果からわかることの確認
検証用にR5のGi0/0にip ospf database-filter all outを投入した後のR4,R5,R6のshowコマンド出力結果について解説します。
※投入後にclear ip ospf process実施済
■図２：R5へコマンド投入後のR4のshow ip ospf neighbor, show ip ospf databaseの出力結果
【わかること】
・ネイバー関係は成立
・データベースに本来あるべきArea 20の情報とRIPから再配送された情報が記載されていない
■図３：R5へコマンド投入後のR4のshow ip route, show ip ospf virtual-linkの出力結果
【わかること】
・Area10のR5とR6のloopbackアドレス、Area20のルート情報、RIPから再配送されているルート情報が存在しない
・仮想リンクがdownしている
■図４：R5へコマンド投入後のR5のshow ip routeの出力結果
【わかること】
・全てのセグメント、loopbackアドレスへ通信可能
※172.18.0.0/24宛が載っていないのは設定ミスのため問題なし。
■図５：R5へコマンド投入後のR6のshow ip route, show ip ospf virtual-linkの出力結果
【わかること】
・全てのセグメント、loopbackアドレスへ通信可能
・仮想リンクはUpしている
④show出力結果から言えること
・R6(ABR)で作成されたArea20のLSA Type3やR8(ASBR)で作成されたLSA Type7(R6のGI0/0から送られるときにType5へと変換)がR5のGi1/0で受信はするものの
Gi0/0から送信されなくなることでR4ではルート情報を認識できない、と思われる。
・R4では仮想リンクを識別するのに必要な情報もR6から受信できないことで、仮想リンクがdownする。
・R5のGi0/0でArea 0のLSA Type3やR2(ASBR)で再配送されたLSA Type5の情報を受信するとGi1/0から送信するため、R6ではルート情報を認識可能。
・R6では、仮想リンクを識別するのに必要な情報もR4から受信できるので、仮想リンクがupする。
⑤総括
ip ospf database-filter all outを何も考えずに投入すると痛い目に遭います。
ip ospf flood-reductionを投入するとLSAの更新を実施しなくなる結果、帯域の節約に寄与します。
長文となりましたが、最後までお付き合いいただきありがとうございました。
時間あるときに編集して見やすさを向上するようにします。