令和7年（2025年）ネスペ午後Ⅰ　問１　解答解説

設問１
（２）不正なOSPFルータと隣接関係になり経路交換してしまう問題
不正なOSPFルータと経路交換をすると自分の内部アドレスの情報が漏れたり、逆に悪意のあるルートを注入されたりしてしまい正常な通信の妨害となる。

なお、余談だがOSPFの認証方法はv2とv3で大きく異なる
▼OSPFv2

#インタフェースで有効化する
int g0/0
ip ospf authentication message-digest
ip ospf message-digest-key キーID md5 パスワード


#ルータコンフィギュレーション内で有効化
router ospf プロセス番号
area エリア番号 authentication message-digest #エリア全体で認証を有効化

int g0/0
ip ospf message-digest-key キーID md5 パスワード

▼OSPFv3（初期）
v3の場合はキー、パスワードは使わずにIPsecのSPIと16進数の暗号キーを指定する

#インタフェース単位で有効化する方法
interface GigabitEthernet0/0
#IPsec (SHA1 や MD5) を使って認証を設定する
 ospfv3 authentication ipsec spi 256 sha1 1234567890123456789012345678901234567890
 
 
#エリア全体で有効化する方法
router ospfv3 1
 address-family ipv6 unicast
  area 0 authentication ipsec spi 256 sha1 1234567890123456789012345678901234567890

▼OSPFv3（現在）
初期の設定方法を見ると、ハッシュ化した値を直書きしているのが分かる。これはエンジニアにとってとても面倒だし、間違える可能性も内在する。そこで、Key-Chainという方法がつかわれるようになった。

▼インタフェース単位の有効化---------------
#Key Cahinの作成
key chain キーチェイン名
 key 1
  key-string パスワード
  cryptographic-algorithm hmac-sha-256
  
int g0/0
ospfv3 authentication key-chain キーチェイン名 

▼エリア単位の有効化---------------------
#key-chainの作成
key chain キーチェイン名
 key 1
  key-string パスワード
  cryptographic-algorithm hmac-sha-256
  
#ルータコンフィグ
router ospfv3 プロセス番号
 address-family ipv6 unicast
  area エリア番号 authentication key-chain キーチェイン
 exit-address-family

（４）OSPFの経路情報が収束した状態

再起動直後にマスタールータに昇格すると、OSPFが収束していない状態で引き継ぐことになる。これはすなわち、適切なルーティング情報が手元にない状態であるにもかかわらずパケットがどんどん届いてしまうことを意味する。もちろん、ルーティング情報がないので破棄、または意図しないルートへの転送をしてしまい正常な通信ができなくなってしまう。それを防ぐために、再起動直後からある程度の時間を待機させて、経路情報が安定してからマスタを引き継ぐことで正常な通信を維持できる。

int g0/0
 vrrp グループ番号 preempt delay minimum 秒数
 
#秒数に関しては、基本的に60秒程度を設定する（大規模なら120~180秒）
#OSPF自体は30秒程度で収束するが起動直後などはCPU負荷が高くなるため余裕をもって60秒程度に設定しておこう

設問２
（２）65535といった十分大きな値に変更する
OSPFは宛先までの経路でコストが最も小さな経路が選択される。すなわち、経由させたくなければ、より大きなコストを設定すればよい。そのため、コスト値の最大値である65535を設定する

ちなみに、コスト値だけを見ると1001以上に設定すれば無事に迂回できそうに見える。しかし、ここで気にしておかなければならないのが、ルート１とルート２が全く同じ経路であるかということ。もし、ルート２がもともとルート１よりも多くのルータを経由しなければならない場合、ルート１側の１つのルータのOSPFを少し変更させただけでは迂回しなくなる。なぜならOSPFはインタフェース単体ではなく、経路までの合計のOSPFコストを計算するから。そのため、余裕をもって、65535という値に設定しておくのがベストプラクティスとなっている。

▼OSPFコストの変更方法

int g0/0
ip ospf cost 65535

（３）物理インタフェース閉塞へいそくの方が素早く切り戻せるから

切り離すという観点で言うと、電源をオフにしても、物理インタフェースをダウンにさせても切り離すことが可能。しかし、切り離し中に問題が発生した場合、電源をオフにしてしまうと、再起動までに時間がかかってしまう。その点で、物理インタフェースの閉塞であれば、以上を検知したらすぐに切り戻せるという利点がある。なので、まずは物理インタフェースで様子見をして大丈夫そうなら最終的に電源を切るという手順でやるのがベター。

p.3 そもそもなんでVLANを分けているの？———————–

構成図を確認すると、L3SWでは複数のVLANを設定している。なぜか。。見ていこう！

１．フィルタリングの適用
同一VLANではL3機器のフィルタリングを経由せずL2によるMACアドレスによる直接通信が可能。そのため、L3の詳細なフィルタリングを適用するという意味も含めてVLANを別にして、L3を跨がせるという運用方法をとっている。
２．通信量の削減
同一VLANは、同一ブロードキャストドメインを意味する。つまり、すべてを同一VLANにしてしまうと、すべての機器にARPなどのブロードキャストが届いてしまい帯域を圧迫してしまう。そのため、VLANを設定した方が帯域への負荷も軽減できるよね、という考えがある。

３．局所化
もし、１つのVLANで運用してしまうと、その１つに攻撃が成立するとすべてに広まってしまう。しかし、VLANで分けておけば、たとえ１つに攻撃が成立しても、攻撃範囲を局所化できる。これによってセキュリティ的に強度が高まる。

👆以上、よりVLANにわけると様々なメリットがある

p.4 DMVPNとは？———————–

DMVPN（DynamicMultipointVPN）は、IPsecの弱点を補った仕組み。通常IPsecでは、接続前に事前設定が必要になる。つまり、拠点が増えれば増えるほど、それに伴って事前設定が必要になる。これはとてもタフな作業。しかし、DMVPNを使えば、新たに拠点が追加されても動的に設定を完了させることができる。なお、DMVPNにはPhase１～３まで存在する。まずは、Phase１からやっていこう！

▼通常のIPsecとDMVPN Phase1の違い

▼DMVPN Phase1の流れ———————–

表層の説明だけをしていても理解が難しいと思うので、実際のコマンドと照らし合わせつつ流れを見ていこう！

０．NHRPでハブへ通知する
　実際の通信を始める前に、ルータでは起動直後にNHRPを使いハブルータへ自身の物理IPとトンネルIPを紐づけさせる。
　ちなみにこの通信もトンネルからでるので、暗号化対象となる。宛先については、nhsやmapコマンドなどを参照する。

interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.1                  #親玉となるハブのトンネルIPアドレス
 ip nhrp map 10.0.0.1 203.0.113.1      #ハブのトンネルIPアドレスと物理IPアドレスの対応 
 ip nhrp map multicast 203.0.113.1     #マルチキャスト送信先をハブの物理IPアドレスに指定
 ip nhrp holdtime 7200                 #ハブに対して自分の情報を何秒保持してと伝える
 ip nhrp registration timeout 30       #RegistrationRequestを送信する秒間隔

＊正直、技術的には手順２のtunnel destination 203.0.113.1コマンドをかけば、ip nhrp map multicast 203.0.113.1はいらない可能性がある。しかし、nhrpを有効にするとマルチキャストをnhrpのテーブルから探してしまう。そのため、あえて明示的に書く必要がある。

１．GREトンネルへ流す
　・支社端末から本社へのパケット送信を試みる
　・ルータは、宛先が本社の10.2.0.88であることを確認する。
＊OSPFなどのルーティングプロトコルが動作しているならスタティック設定は不要

#支社スポークルータの設定
#スタティック設定によりGREトンネルへ流す判断をする
ip route 10.2.0.0 255.255.255.0 Tunnel0

interface Tunnel0
ip ospf network point-to-multipoint

２．GRE処理
　・パケットがGREトンネルへ届くとGRE処理を実施する
　・具体的には、トンネルの宛先/送信元のカプセル化処理
＊tunnel destinationで指定された宛先を物理的な宛先に、tunnel sourceとして指定されたアドレスを物理的な送信元としてカプセル化する

#支社スポークルータの設定
interface Tunnel0
 ip address 10.0.0.2 255.255.255.0 #トンネルIP
 tunnel source 203.0.113.50      #支社物理IP
 tunnel destination 203.0.113.1  #ハブ物理IP
 tunnel protection ipsec profile DMVPN-PROFILE #トンネルにIPsecを紐づける

３．IPsec処理
　先ほどの最後のコマンドでtunnel protection ipsec profile DMVPN-PROFILEでトンネルがIPsecと紐づいていることが分かる。なので、そのプロファイルに従ったIPsec処理をする

#支社スポークルータの設定
crypto isakmp key secretKEY address 203.0.113.1 #ハブの物理IP

#IPsecーPhase1の設定
crypto isakmp policy 1
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400

#IPsecーPhase2の設定
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode transport

#Profile作成（これをトンネルに割り当てる）
crypto ipsec profile DMVPN-PROFILE
 set transform-set TS

４．ルーティング
　tunnel destinationより物理的な宛先が203.0.113.1であることが分かるので、ルーティングテーブルに従って転送処理をする

５．ハブに届く
　ハブでもスポークと同様の設定をしておく。
＊ハブの場合は、ip nhrp map や　ip nhrp map nhsなどは不要。
①宛先を確認して本社であることが分かる。
②本社へはトンネル経由であることが分かる。
＊OSPFなどのルーティングプロトコルをトンネル内で動作させておくことで、ハブルータは、「あ、この宛先はこのトンネルインタフェースからもらったから、このトンネルをネクストホップとして流せばよい！」と判断する。結果的に、トンネルに流せばIPsecが適用される
③トンネルへ流す
④GREカプセル化
⑤IPsec処理
⑥転送

以上が、DMVPN phase1の流れである。
完了！！！

Q.DMVPN Phase1とPhase２の大枠の流れ———————–

▼Phase１におけるルーティングの大枠

#スポークAからスポークB
【事前準備（通信が発生する前）】
⓪ NHRPパケット（自己紹介）の発行
   ・ルータ起動直後「NHRPの登録要求（Registration）を送るぞ。宛先トンネルIPは 10.0.0.1（nhs）だな」
   ・ルータ「10.0.0.1 宛ての物理IPは…… ip nhrp map を見ると 203.0.113.1（ハブ）だな！」
   ・結果 ➔ ハブに向けて自身の「トンネルIP ↔ 物理IP」のペアを暗号化して通知し、登録を完了させる。


【実際のデータ送信時（スポークA ➔ スポークB）】
① ルーティング（OSPF）処理の発動
   ・ルータ「スポークB配下の PC（10.3.0.88）宛てのパケットが来たぞ」
   ・参照場所 ➔ ルーティングテーブル（OSPF）を見る！
   ・結果 ➔「ネクストホップ（次の行き先）は、スポークBのトンネルIP 10.0.0.3 だ！
             Tunnel0 インターフェースへ流せ！」

② GRE処理の発動
   ・ルータ「Tunnel0 からパケットを出すぞ。外側の宛先物理IPは何にすればいい？」
   ・参照場所 ➔ tunnel destination 203.0.113.1 を見る！
   ・結果 ➔（ネクストホップが 10.0.0.3 であっても関係なく）設定に従い、
             外側宛先IPを 203.0.113.1（ハブ）に設定してGREカプセル化！

③ IPsec処理（暗号化）の発動
   ・ルータ「203.0.113.200（ハブ）宛てのパケットが出ようとしている。暗号化（IKE交渉）が必要だな！」
   ・参照場所 ➔ crypto isakmp key ... address 203.0.113.1 を見る！
   ・結果 ➔ 203.0.113.1 用の鍵（secretKEY）を使って暗号化トンネルを確立・適用し、ハブへ向けて送信！

▼Phase２におけるルーティングの大枠

#スポークAからスポークBへの通信
① ルーティング（OSPF）処理の発動
   ・ルータ「スポークB配下の PC（10.3.0.88）宛てのパケットが来たぞ」
   ・参照場所 ➔ ルーティングテーブル（OSPF）を見る！
   ・結果 ➔「ネクストホップ（次の行き先）は、スポークBのトンネルIP 10.0.0.3 だ！
             Tunnel0 インターフェースへ流せ！」

② GRE処理の発動（★ここがフェーズ1と大違い！）
   ・ルータ「Tunnel0 からパケットを出すぞ。外側の宛先物理IPは何にすればいい？」
   ・参照場所 ➔ `tunnel destination` を探す……が無い！（mGREモードだから）
   ・ルータ「よし、【NHRP部署】に問い合わせだ！
             『ネクストホップ 10.0.0.3 に対応する物理IPを教えてくれ！』」

③ NHRP処理の発動（電話帳検索 ＆ 解決要求）
   ・【NHRP部署】「自分のキャッシュ（電話帳）に 10.0.0.3 の物理IPはあるか？」
   
   【パターンA：まだ知らない場合（1発目のパケット）】
   ・NHRP「まだ知らない！とりあえずハブ（10.0.0.1 ➔ 203.0.113.1）に一時的に送っておくぞ！」
   ・NHRP「同時に、ハブへ『10.0.0.3 の物理IPを教えて！』と Resolution Request を送信！」
   ・ハブ「10.0.0.3 の物理IPは 203.0.113.200 だよ！」と回答が届く ➔ キャッシュに保存！

   【パターンB：もう知っている場合（2発目以降のパケット）】
   ・NHRP「キャッシュにあったぞ！10.0.0.3 の物理IPは 203.0.113.200 だ！」

   ・結果 ➔ 外側宛先IPを 203.0.113.200 に設定してGREカプセル化！

④ IPsec処理（暗号化）の発動（★スポーク間ダイレクト！）
   ・ルータ「203.0.113.200（スポークB）宛てのパケットが出ようとしている。暗号化が必要だな！」
   ・参照場所 ➔ `crypto isakmp key ... address 0.0.0.0` を見る！
   ・結果 ➔ スポークB（203.0.113.200）と直接 IKE/IPsec の鍵交換を行い、
             暗号化（ESP化）して直接インターネットへ発射！

Q.NHRPの具体的な挙動———————–

NHRP（NextHopResolutionProtocol）について、なんとなく「物理IPとトンネルIPの対応を解決してくれるプロトコル」という理解まではできる人が多い。しかし、実際の挙動をイメージした場合、どうなっているのか説明できる人まではなかなかいない。なので、実際の挙動を見ていこう！NHRPには大きく分けて、登録とリクエストの２つがある。その二つの挙動についてやっていこう！
１．Registration
・Spoke 起動時：ip nhrp nhs と ip nhrp map を参照し、ハブの物理IPを特定。
・パケット：Registration Request（自身の トンネルIP ↔ 物理IP を格納）をハブへ送信。
・ハブの動作：NHRP データベースに登録し、Spoke の居場所を把握する。
２．Resolution
① Spoke A ➔ ハブ（リクエスト送信）
・Resolution Request（ターゲットのトンネルIP、自身の トンネルIP ＆ 物理IP）を送信。
② ハブ ➔ Spoke B（転送）
・ハブは中身を書き換えずにそのまま Spoke B へ転送。
③ Spoke B（相互学習 ＆ ダイレクト応答）
・Spoke B はパケット内の Spoke A の情報（物理IPなど）を NHRP キャッシュに登録（相互学習）。
・Spoke A 宛てに直接 IPsec を確立し、暗号化した状態で Resolution Reply（自身の情報）を返答！
④ Spoke A（学習完了 ＆ ダイレクト通信確立）
・Spoke B からの直接返答を受け取り、NHRP キャッシュに Spoke B の情報を登録。
・以後、Spoke A ↔ Spoke B 間でハブを介さない直接通信が開始！

▼DMVPN Phase2の流れ———————–

Phase2も基本的にPhase1と同じ流れ。しかし、わずかに相違点もある。
相違点１：スポーク側もハブと同じtunnel mode gre multipointをする
相違点２：スポーク間で動的にIPsec＋GREトンネルが自動生成される
では、そのような相違点に着目しながらPhase2を見ていこう！

０．NHRPでハブへ通知
　実際の通信が始まる前に、ルータ起動直後にNHRPを使ってハブルータへ自身の物理IPとトンネルIPアドレスを紐づけさせる（＊ここはPhase１と同じ）

interface Tunnel 0
ip address 10.0.0.2 255.255.255.0
ip nhrp network-id 1
ip nhrp nhs 10.0.0.1
ip nhrp map 10.0.0.1 203.0.113.1 

ip nhrp map multicast 203.0.113.1 
ip nhrp holdtime 7200             #ハブに対して自分の情報を何秒保持してと伝える
ip nhrp registration timeout 300　#ハブに登録しに行く秒間隔

１．ルーティングの準備
　＊Phase２ではSpokeToSpokeを実現したい。しかし、そのまま設定すると、OSPFのルーティングテーブルとNHRPのテーブル情報で不正が生まれてしまう。それを避けるための設定が必要になる。

#ルーティングプロトコル（OSPF）の有効化

router ospf 1
network トンネルIP ワイルドカード area エリアID
network 内部LANIP ワイルドカード area エリアID

#インタフェース設定
interface Tunnel 0
ip ospf priority 0  #DR/BDRにならないようにする
ip ospf network broadcast

？なぜnetworkタイプをbroadcastにするのか
phase２ではSpoke-to-Spokeの通信をさせるために、ネクストホップをスポークのままにしてハブは転送しなくてはならない。もし、point-to-multipointにしてしまうと、ハブがネクストホップを上書きしてスポーク間に広告してしまう。そのため、phase2ではbroadcastを設定する。
？なぜスポークのpriorityを0にするのか
broadcastだとDR/BDRの選出が行われる。もし、スポーク側がDR/BDRに選出されてしまい、ハブがDRotherになってしまうと、ハブは224.0.0.6を破棄してしまう。
確かにnhrpの設定でハブはマルチキャストを転送する役割がある。しかしそれよりも優先的にOSPFのDRotherという役割が上書きされるので、224.0.0.6はマルチキャストといえどDRotherの役割をまっとうして問答無用で破棄する。

２．GRE処理
トンネルを経由するパケットに関してはGRE over IPsecを適用したいので、GRE処理を追加する

interface Tunnel0
tunnel source 自身物理IP
tunnel mode gre multipoint #pahse1の時はtunnel destination ハブの物理IPだった
tunnel protection ipsec profile IPsecプロファイル

*tunnel mode gre multipointはpahse1の時はtunnel destination ハブの物理IPだった。
？tunnel mode gre multipointは物理IPが分からないけどどうやってカプセル化するの？
A.そもそも、tunnel mode gre multipointがnhrpテーブルを使うためのトリガーとなるので、これを見た瞬間に、「あ、multipointが指定されているから、実際の物理IPはnhrpで確認しよう！」となるので心配ご無用！

３．IPsec処理
ここまでで、「パケットの宛先がリモートスポークの配下であること判明→そのリモートへは自身のトンネルから流す→自身のトンネルにはGRE処理がある→tunnel mode gre multipointからnhrpで物理IPを知る→判明した物理IPでカプセル化→IPsecの処理もトンネルにはあるのでその処理をする」という流れができている。なので、ここではIPsec処理をやっていく。

#事前共有鍵の定義
crypto isakmp key パスワード address 0.0.0.0 0.0.0.0

#ISAKMP SA(Phase 1)の作成
crypto isakmp policy ポリシー番号
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400
 
#IPsec SA(Phase 2)の作成
crypto ipsec transform-set トランスフォーム名 esp-aes 256 esp-sha256-hmac
 mode transport
 
#IPsecプロファイルの作成
crypto ipsec profile プロファイル名
 set transform-set トランスフォーム名

４．ルーティング
カプセル化には相手スポークの物理IPが設定されているので、SpokeToSpokeで直接届かせることができる。
完了！！！！！！

OSPFのネットワークタイプ———————–

DMVPNのphase1とphase2ではOSPFのネットワークタイプが重要になってくる。そのため、ここで一度、確認しておこう！

OSPFにおけるDR＆BDRとは？———————–

DRとBDRの選出をすることによって、セグメント内のルータがフルメッシュでネイバー関係にならなくてもよくなる。その結果、CPU負荷や帯域の使用率を下げることができる。
また、LSAの統合役がいることで、個々のルータによる差異が起きにくくループ発生を防ぎやすくなる。

▼OSPFのフロー（Down～FULL）———————–

前提：
・同一セグメントに１０台以上のルータが存在する環境
・ネットワークタイプはBroadcast
０．Down
相手からHelloパケットが１度も届いていない状態
１．Helloパケットの送信（Init）
ルータを起動すると、まずは224.0.0.5宛てのマルチキャストを送信する。
▼Helloパケットには以下の情報が含まれる

２．２WAY
同一セグメントからのHelloパケットのNeighborフィールドに自身のルータIDが記載されている場合、相互認識完了。
ここで、DRとBDRを選出する
DRとBDRが決まったので、以降の通信はマルチキャストではなくユニキャストで実行される
▼選出基準
①プライオリティ（デフォルトは１）が１番大きいルータがDRに、２番目がBDRになる
②①が同一の場合はルータIDで決める
＊ルータIDは重複が禁止なのでこの２ステップで確実に決まる
３．EXstrat
マスターとスレーブを決める。
▼選出方法
①DBDパケット（ルータID、MTU、制御フラグ、シーケンス番号が格納）を送信する
＊MTUが不一致だとshow ip ospf neighbor 時にExstartで止まる
②ルータIDを比較し、大きなほうがマスターになる。
③スレーブはシーケンス番号をマスターに合わせる
▼詳細

[ ルータ A (RID: 1.1.1.1) ]                       [ ルータ B (RID: 2.2.2.2) ]

 1) 「僕がマスターだ！(MS=1)」 ── (ユニキャスト) ──>  「僕がマスターだ！(MS=1)」
    (RID: 1.1.1.1, Seq: 100)                         (RID: 2.2.2.2, Seq: 500)
                              <── (ユニキャスト) ──

 2)  ルータ A は「相手（2.2.2.2）の方が RID が大きい！」と気づき、スレーブ（Slave）を認める。
     ルータ B は「自分（2.2.2.2）の方が RID が大きい！」と確信し、マスター（Master）になる。

 3) スレーブ（ルータ A）が折れて、相手の Seq: 500 を使って返事をする：
    「了解、君がマスターね。(MS=0)」 ───>  「よし、じゃあ僕（マスター）から目録を送るね！」
    (Seq: 500 で返信)                         (ここから Exchange ステートへ移行！)
    
    
 #制御フラグ
 M(More)ビット：１→まだ続きがあるよ。１回でLSA目次が入りきらなかったら使う
 MS(Master/Slave)ビット：１→俺がマスターだよ！
 I(Init)ビット：１→これが最初のDBDだよ！つまりExstartを意味する
 

４．Exchange
お互いのLSDB情報を同期するためのフェーズがExchange。お互いのLSAの差分の有無によって挙動が変わる。
▼Exchange詳細フロー
①マスターがDBDにLSAの概要を載せてスレーブへ送信する
②スレーブも、マスターへDBDにLSAの概要を載せて送信する
③Mビットが０になるまでお互い交互にDBDを送り合う
＊Mビット：１がまだ続きがあるよ！の意。０がLSAの目次送り切りましたよ！と伝えるフラグ
送り合っている最中も自分のLSDBと相手のDBDを見比べて差分をLSRリスト（後で要求するLSAのリスト）を作成しておく。
→Mビットが０になった時点で差分がない場合はLoadingをスキップしてFULLへ
→Mビットが０になった時点で差分がある場合はLoadingへ
５．Loading
LSRリストをもとに欲しい情報を取得してLSDBを完成させるというプロセスを担うのがLoading。基本的にはLSR→LSU→LSAckという流れで進んでいく。では、詳細を見ていこう！
▼Loading詳細フロー
①LSR(LinkStateReques)の送信
Exchangeステートで準備しておいたLSRリストをもとに、「このLSAの詳細をください」と請求するLSRパケットを送信する
②LSU(LinkStateUpdate)の送信
LSRを受信した相手は、請求されたLSAの詳細データを詰め込んだLSUパケットを返す。
（１つのLSUに複数のLSA詳細データをまとめて送れる）
③LSAck(LinkStateAcknowledgment)
LSUを受け取ったら自身のLSDBに保存する。保存が完了したら「LSUを受け取ったよ！」という確認メッセージであるLSAckパケットを返す。
④LSRリストが空になったらFULLへ移行
LSRリスト内のLSAをすべて受け取り、手元のLSRリストが完全に０件になったらFullへ移行
６．FULL
・FULLになったら、あとはタイマーに従ってHelloパケットを送信し合う。
FULLになった後に経路の追加、削除が検知されると、検知したルータがLSUをDR/BDRにマルチキャスト(224.0.0.6)送信する。それをDR/BDRがマルチキャスト(224.0.0.5)して全体に広がる。
▼経路削除
当該LSAを「シーケンスを＋１にする＆Maxageを3600」にしてLSUを送る。
＊MaxageはLSAを保持する期間。これが切れると削除されるので、3600でLSUを送ると自動的に相手側から削除される
▼経路追加
通常のLSUを送る流れでパケット送信する

以上がOSPFのフロー説明である。
完了！！！

DMVPN Phase3——————–

phase2まででSpokeToSpokeが完了した。しかし、これには弱点がある。各スポークがほかのスポーク配下の情報をすべて保持していなければならず、ルーティングテーブルが莫大になってしまい大規模環境には向いていないとされている。それを解消できるのがphase3である。

phase2はなぜ大規模に向かないのか?——————–

phase２では各スポークが、ほかのスポーク配下のルート情報をすべて保持する必要がある。そのため大規模環境には向かないとされている。でも、経路集約を使えば解決できるのでは？と疑問が浮かぶ。しかし、そこにはいくつもの壁（厳格なルール）がある。それを見ていこう！
①エリア内ルータは経路集約できないというルールがある
大抵の場合、ハブと各スポークは同一エリアのエリア０で動作している。OSPFのルールでは経路集約ができるのはABRとASBRとなっているため、スポーク側のエリア内ルータでは集約ができないという制限がある。
②スポーク側で経路集約してもそもそも効果が薄い
エリアを分割すれば、スポーク側で経路集約ができるという考えもある。しかし、そもそも拠点が1000以上である場合、少なくとも1000のルーティング情報は保持しなければならいため、スポーク側で集約してもさほど効果がないというそもそも論が生まれる。
③ハブがデフォルトルート流すとネクストホップが変わる
ハブがデフォルトルートを流せば、全スポークの経路を１行で抑えることができる。これをやるとルーティングテーブルは抑えることができるが、そもそもすべての通信がハブ経由になるのでSpokeToSpokeが破綻する。

インターネット用のデフォルトルートとDMVPN用のデフォルトルートは重複しないの？
①パターン１
インターネット宛先もDMVPNもすべてハブへ流す構成にする。届いた後に、ハブ側がDMVPNかインターネットかを判断してルーティングさせれば、重複していても問題ない。
②パターン2
社内LANの集約ルートを使う。実際の現場では、0.0.0.0ではなく10.0.0.0/8や192.168.0.0/16として社内全体をまとめた大きな集約ルートを流す。

なぜPhase3はPhase2よりもすぐれているのか？——————-

ShortCutとRedirectと呼ばれる新機能追加により、スポーク側に動的なルート生成を可能としているから。どういうことなのか、簡単に見ていこう！
①ハブが社内集約ルートを配る
＊これにより、スポークには、ほかのスポークのトンネルIPも内部LAN情報を届かなくなる
＊社内集約ルート（10.0.0.0/8や192.168.0.0/16など）を流すのではなく、インターネットもハブを経由させたいという場合はそのまま0.0.0.0のデフォルトルートを流すこともある。
②スポークAがスポークBへ
DNSなどの名前解決により、社内LANのIPアドレスが割り当てられたサーバへアクセスしたいと考える。しかし、ネクストホップが分からないので、社内サマリーを持つハブへ丸投げする
③ハブのRedirect指令！
・ハブは、トンネルから受け取ったパケットをトンネルから流すルーティングであることが判明すると送信元に対して「次からこの通信は俺を経由せず、直接行ってね（NHRP Redirect)」と指令を出す。
・パケット自体は宛先のスポークBへ転送してあげる。
④スポークAがスポークBにNHRP Resolution Request
スポークAはハブから「直接やりなさい」と命令されたら、「よし、じゃあNHRP Resolution Requestを送ろう。ターゲットIPはサーバのプライベートIPとして送ろう」とハブに送り、ハブはOSPFやNHRP情報からスポークBへ転送する。
⑤スポークBがスポークAへNHRP Resolution Reqlyを返す
パターン１：スポークBはNHRP Requestの送信元を確認し、自身のトンネルIP、物理IP、配下のサブネット情報(192.168.2.0/24 など)などを格納し、スポークAへ直接NHRP Responseを返す。
パターン２：パケットの応答を返す際にスポークBも宛先を知らないためデフォルトルートのハブに流すが、ハブからはNHRP Redirectが来るのでスポークBもNHRP Resolution Requestを送りスポークAの物理IP、トンネルIP、サブネット情報などを得る
※なお、この間に発生するサーバーからの1回目のデータ応答パケットもハブ経由で送られ、ハブからスポークB側にも Redirect が発行される。
⑥スポーク間でIPsecトンネルを確立
・手順⑤によってIPsecトンネルが確立するので、あとの通信はSpokeToSpokeでやり取りをする。
・同時にShortCut機能により、各スポークのテーブルに、動的に物理IPとトンネルIPとリモートスポーク配下のサブネットが登録される。→これにより以降はSpokeToSpokeでやり取りできる。

これで大まかな流れは完了！！！

DMVPN Phase3でハブはどうやってOSPFの設定をしているの？

phase3の勉強をしていると、ハブがサマリールートやデフォルトルートを流し、通信の１step目は必ずハブを通るようにしている。でも、OSPFの設定を間違っていると、そもそも、あるスポークの情報をそのまま別のスポークに流してしまうということもある。なので、ここではハブはどうやってphase3の経路制御をしているのかをコマンドとともに見ていこう！

解決策：Totally Stubby Area
１．ハブとスポークでエリアを分割する
２．ハブにarea 1 stub no-summaryを実施
→タイプ３～５がデフォルトルートに変換される。つまり同一エリアの情報しか渡されない。
３．スポークにarea 1 stubを設定する
→タイプ4～5を受け取らない設定
＊まぁ正直、スポーク側でもno summaryを設定しても正常に動作する。
しかし、Cisco以外のメーカーではABRでもないのにno summaryが設定されているとはじかれたりしてしまうので、KISS(Keep is Simple,Stupid：シンプルにしておけ)の原則に則って設定する。

#ハブ
router ospf 1
 router-id 1.1.1.1
 
#本社内部LAN側は Area 0
 network 172.16.0.0 0.0.255.255 area 0
 
 #DMVPN トンネル側（Tunnel0）は Area 1 に設定
 network 10.0.0.0 0.0.255.255 area 1
 
 #★ここが核心コマンド！
 #Area 1 を「Totally Stubby Area」に指定する
 area 1 stub no-summary

#スポーク
router ospf 1
 router-id 2.2.2.2
 
#DMVPN トンネル側および配下LANを Area 1 に設定
network 10.0.0.0 0.0.255.255 area 1
network 192.168.2.0 0.0.0.255 area 1
 
#★スポーク側は「no-summary」なしの「stub」のみでOK
area 1 stub

こんな感じでいったん完了！！！

p.4 OSPFでデフォルトルートを配布するには—————-

デフォルトルートの配布とはいったい何なのだろうか。。。前提としてOSPFではインタフェース単位でOSPFに参加する。しかし、デフォルトルートはどのインタフェースにも属していないため、明示的に配布する必要がある。その旨を表現しているのが、本文中の「デフォルトルートの配布」である。
▼デフォルトルートの配布方法

ip route 0.0.0.0 0.0.0.0 出力先

router ospf プロセス番号
 default-information originate

▼そのほかのプロトコルでのデフォルトルートの流し方

▼BGP
router bgp AS番号
neighbor ネイバーIP default-originate

▼BGP（スタティックで準備しておく）
ip route 0.0.0.0 0.0.0.0 Null0

router bgp AS番号
 network 0.0.0.0 mask 0.0.0.0

▼EIGRP
int G0/0
 ip summary-address eigrp AS番号 0.0.0.0 0.0.0.0
 
▼EIGRP（スタティックで準備しておく）
ip route 0.0.0.0 0.0.0.0 Null0

router eigrp AS番号
　redistribute static

こんな感じでいったん完了！！！

p.5 BGPで認証はどうやってやるの？—————–

router bgp AS番号
 neighbor ネイバーIP password パスワード
 
 
以上！これでネイバーと一致すれば認証が完了する

こんな感じで完了！！

p.5 AS-PATHプリペンドの設定方法

route map マップ名 permit シーケンス番号
 set as-path prepend 自分のAS番号 自分のAS番号
 
router bgp AS番号
 neighbor ネイバーIP route-map マップ名 out

こんな感じで完了！

p.5 経路フィルタリングのやり方

route map マップ名 permit シーケンス番号
 set as-path prepend 自分のAS番号 自分のAS番号
 
router bgp AS番号
 neighbor ネイバーIP route-map マップ名 out