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

設問１
（１）l:トランスポート　m:順不同　n:重複　o:同期　p:バックオフ

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の違い

項目通常のIPsec（拠点間メッシュ）DMVPN Phase 1（Hub & Spoke）
トンネルの方式Point-to-Point GRE / IPsec
（1対1の固定トンネル）		mGRE (Multipoint GRE)
（1つのポートで不特定多数と繋がる）
トンネル宛先設定手動で固定指定
(tunnel destination <相手の物理IP>)		指定不要（動的）
(tunnel mode gre multipoint を指定
＊ハブのみ。スポークはハブ宛てにする
アドレス解決不要（人間が事前にコマンドで指定するため）NHRP（Next Hop Resolution Protocol）
（動的に「トンネルIP ⇔ 物理IP」を電話帳に登録）
通信ルート拠点 $\leftrightarrow$ 拠点 の直接通信必ずハブを経由（折り返し通信）
新拠点追加時の作業激重（地獄）
既存の全ルータに新しい鍵とトンネル設定の追記が必要		超絶楽
新拠点ルータの設定のみ。ハブや既存拠点の設定変更はゼロ
鍵（PSK）の設定相手の物理IPごとに個別で設定0.0.0.0 0.0.0.0（共通鍵で動的受け入れ）
＊ハブとスポーク両方で設定。
ただしスポーク側に限っては、ハブの物理IPでも正常作動する

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

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

区分項目IPアドレスの例補足・役割
通信の送信元
（A社 支社）		端末（PC）IP10.1.0.5通信をスタートする実際のPC等
ルータ物理IP (WAN)203.0.113.50 支社ルータがインターネットに出るための物理IP
ルータトンネルIP10.0.0.2 mGREトンネル網（仮想NW）内の支社アドレス
通信の中継役
（DMVPN ハブ）		ルータ物理IP (WAN)203.0.113.1全スポークが最初に目指す親玉の物理IP
ルータトンネルIP10.0.0.1NHRPサーバー（電話帳）として機能するトンネルIP
通信の目的地
（A社 本社）		ルータ物理IP (WAN)203.0.113.100 本社ルータがインターネットに出るための物理IP
ルータトンネルIP10.0.0.3mGREトンネル網（仮想NW）内の本社アドレス
社内サーバ/PC IP10.2.0.88最終的にアクセスしたい本社のサーバ等


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

Wolfram
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などのルーティングプロトコルが動作しているならスタティック設定は不要

Wolfram
#支社スポークルータの設定
#スタティック設定により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として指定されたアドレスを物理的な送信元としてカプセル化する

Wolfram
#支社スポークルータの設定
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処理をする

Wolfram
#支社スポークルータの設定
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１におけるルーティングの大枠

Wolfram
#スポーク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２におけるルーティングの大枠

Wolfram
#スポーク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１と同じ）

Wolfram
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のテーブル情報で不正が生まれてしまう。それを避けるための設定が必要になる。

Wolfram
#ルーティングプロトコル（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処理を追加する

Wolfram
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処理をやっていく。

ShellScript
#事前共有鍵の定義
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のネットワークタイプが重要になってくる。そのため、ここで一度、確認しておこう！

ネットワークタイプトポロジのイメージDR/BDR選出Hello / Dead タイマー主な用途・デフォルトで使われる場所その他
Point-to-Point1対1なし10秒 / 40秒シリアル線、GREトンネルのデフォルト
Broadcast多対多 (LAN)あり10秒 / 40秒イーサネット（LAN）のデフォルトネクストホップをそのままにして転送
Point-to-Multipoint1対多 (放射状)なし30秒 / 120秒DMVPN (Phase 1) や Frame Relayネクストホップをハブに上書きして転送
Non-Broadcast (NBMA)多対多 (レガシー)あり30秒 / 120秒古い Frame Relay / ATM 回線

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

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

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

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

パケット内のフィールド内容ネイバー成立のチェック
Router ID送信元ルータの ID一致するとエラー（重複不可）
重複すると、show ip ospf neighborで2way以上には進まない
Area ID所属するエリア番号（例: 0）一致が必須
Network Mask送信元インターフェースのサブネットマスク一致が必須（※P2P除く）
Hello IntervalHello を送る間隔（例: 10秒）一致が必須
不一致だと、show ip ospf で表示すらされない
Dead Intervalネイバー障害とみなす時間（例: 40秒）一致が必須
不一致だと、show ip ospf で表示すらされない
Router PriorityDR/BDR 選出用の優先度（デフォルト 1）チェックなし（選出に使用）
Designated Router (DR)現在認識している DR の IP アドレスチェックなし（情報共有）
Backup DR (BDR)現在認識している BDR の IP アドレスチェックなし（情報共有）
Neighbor自分（送信元）が受信を確認した相手の Router ID リストここに自分のIDがあれば 2-Way
Options (E/N bit)スタブエリアなどのオプション機能フラグ一致が必須
Authentication認証タイプおよびパスワード等一致が必須

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

Wolfram
[ ルータ 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––––––––––––––––––––











　




タイトルとURLをコピーしました