0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

DMVPN Phase1-3 & IGP 【CCIEメモ_20251005-09】

Last updated at Posted at 2025-10-09

本当にDMVPN関連は資料が虚無いというか、毎回頭から説明してわずかな違いが有ったりなかったりでやる気でないですね。
手は動かしてるんだけど、興味が湧くポイントが薄すぎて真剣みが出ないというか…AIにまとめて貰って要点だけの方が良いのかもしれない…

参考資料・時間

資料:
CCIE Enterprise Infrastructure Foundation lab
DMVPN Lab 2

勉強時間:
20251005 : 約3.5時間
20251006 : 約3時間
20251007 : 約2.5時間
20251008 : 約2.5時間
20251009 : 約3.5時間

学習内容

DMVPNのフェーズごとに最適なルーティングプロトコルの設定

構成はSingle Hub, Multi-Cloud

Multi-Cloud構成で、ルータには複数の2つのトンネルセッションを作成。
等コストマルチパスは採用せず、主系を優先する。

OSPFドメインに参加するルータは、エリア内の全てのルータのプレフィックスを持っている。

〇ネットワークタイプがBroadcastの場合

Spoke1 - HUB - Spoke2という構成の場合、
Spoke1はSpoke2のLAN側IPにアクセスする際のNext-hopはSpoke2となる。

〇ネットワークタイプがpoint-to-pointの場合

Spoke1 - HUB(point-to-multipoint) - Spoke2という構成の場合、
Spoke1がSpoke2のLAN側IPにアクセスする際のNext-hopはHUBとなる。
P2Pは隣接機器とネイバーを形成するため、ネクストホップは隣接機器になるためである。

以下、特記事項あれば記載

BGP
デフォルトではkeepalive 60secが3回タイムアウトするとピアをDownにするため、切り替えが遅くなってしまう。
対処法としては、keepalive間隔を狭める。もしくはタイムアウト価の変更となる。

R1(config)# router bgp 100 
R1(config-router)# neighbor SPOKES timers 6 20

Phase2 + EIGRP

Tunnel 100を優先にした状態で、Spoke-to-Spokeで通信を行う。
この状態でSpokeルータのTunnnell100がDownした場合

Spoke1
tunnne200での通信

Spoke2
Tunnnel100での通信

となり、HUBを介した状態で通信が継続される。
これはEIGRPの特性によるもので、OSPFと異なりエリア内で完全なルートを保持せず、ネイバーからアドバタイズされたルートとネットワーク情報のみしか知らない為。

SLA/Objec-Tracking/EEM等で経路切り替えするような対応が必要

Phase2 + iBGP

update-source loopbackを設定しない場合、主系の通信が落ちた際に、ネクストホップに対しての経路を失うため通信できなくなってしまう。

Phase2 + eBGP

R2からR3への通信では主系はネクストホップが100.1.1.3だが、
副系は200.1.1.1(HUB経由)となっている。
これは、主系の通信だと100.1.1.0/24のネクストホップにアクセスできるが、
副系のアドレスだとそれができないので、HUBのアドレスをネクストホップとする。

SLA/Objec-Tracking/EEM等で経路切り替えするような対応が必要

解決策

これらの問題の解決策として、Loopbackを元にTunnel Sourceに設定。
ループバックをNBMAアドレスにすることで、片系が落ちても疎通性が残っていれば問題なく通信できるようにする。

この際、トンネルインターフェースは一つだけで問題ない。
トンネルの数ではなく、NBMAアドレスを冗長化することがポイントとなる。


Phase3 + OSPF

ルーティング情報の完全な要約ができない為、Phase3のオーバレイプロトコルとしては不適切。

Phase3 + EIGRP

Spoke-to-Spoke通信の際、主系の通信がなくなると副系に切り替わる。
送信元はセッションが切れたことを認識して切り替えても、対向はセッションの切り替わりを認識できないので、通信できない。
対向側の NHRPで学習している情報をクリアしてあげる必要がある。
古いNHRP学習情報を使ってるのが原因。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?