2026年版 Cisco DMVPN：IKEv2・Manual PPKとEIGRPによるIPv4/IPv6 transport冗長化

Last updated at 2026-10-21Posted at 2026-10-21

はじめに

2019年に「NTTフレッツ IPv6上でCisco DMVPN (IPv4 over IPv6)を組んでみた」を書きました。今回は、IOS XE の実機4台を使った現在の構成を、IKEv2 の鍵管理と経路冗長化の観点からまとめます。

構成のポイントは次の3点です。

IKEv2 の認証用 PSK を keyring に集約する。
IPv4／IPv6 transport の両方で Manual PPK を使用する。
IPv4 LAN の経路を EIGRP で交換し、Tunnel6 を優先、Tunnel4 を待機経路にする。

特に、認証用 PSK、追加の PPK、ML-KEM による鍵交換は役割が異なります。設定の参照関係と、使用中 SA の確認を分けて説明します。

検証記録は2026年10月21日 JST のものです。ホスト名と IP アドレスは記事用のダミー値に統一し、機種・IOS XE バージョン・経路メトリック・パケット数・実測 RTT は採取時の値を保持しています。設定例は必要部分に絞った説明用の抜粋で、鍵の値や peer の照合条件などを省略しています。

2019年版から変わったこと

項目	2019年の記事	今回の構成
機器・OS	C891FJ、Classic IOS 15.7(3)M4	Secure Router、ISR、Catalyst Edge の混在。IOS XE 26.02.01／17.18.05
IKE	`crypto isakmp` を使う IKEv1	IKEv2 の proposal／policy／profile／keyring
認証用の鍵	IKEv1 の共有鍵	`keyring local DMVPN_KR` で認証用 PSK を参照
追加の鍵	記載なし	`keyring ppk DMVPN_KR` で Manual PPK を参照
IPsec データ暗号	AES-CBC＋SHA-256	`esp-gcm 256`、transport mode
transport	IPv6 transport の単一クラウド	IPv4／IPv6 transport の2クラウド
経路制御	IPv6 上の DMVPN 構成を説明	EIGRP で優先経路と待機経路を保持

今回は Manual PPK の利用を実機で確認しました。ML-KEM の成立については、後述のとおり別の確認が必要です。

検証構成：外側はIPv4／IPv6、内側はIPv4

使用機器とアドレス

役割	ホスト名	機種	IOS XE
Hub、東京側	HUB1	C8235-G2	26.02.01
Spoke	SPOKE1	C1161X-8PLTEP	17.18.05
Spoke、山梨県	SPOKE2	C1111-8P	17.18.05
Spoke	SPOKE3	Catalyst C8300-1N1S-6T	17.18.05

ホスト名	Tunnel4	Tunnel6	LAN の例示プレフィックス
HUB1	10.255.4.1/24	10.255.6.1/24	10.10.0.0/19
SPOKE1	10.255.4.11/24	10.255.6.11/24	10.16.0.0/22
SPOKE2	10.255.4.12/24	10.255.6.12/24	10.20.0.0/22
SPOKE3	10.255.4.13/24	10.255.6.13/24	10.40.0.0/14

以下は2つの DMVPN クラウドを表した論理構成です。本文では HUB1 と SPOKE2 の間を中心に確認します。

Tunnel6でも、運んでいるLANの経路はIPv4

項目	Tunnel4	Tunnel6
外側の transport	IPv4	IPv6
mGRE	`tunnel mode gre multipoint`	`tunnel mode gre multipoint ipv6`
内側の overlay	IPv4、10.255.4.0/24	IPv4、10.255.6.0/24
EIGRP	IPv4 AS 65000	IPv4 AS 65000
認証	PSK、`keyring local`	PSK、`keyring local`
追加 PPK（最終状態）	`keyring ppk`、Manual PPK 使用確認済み	`keyring ppk`、Manual PPK 使用確認済み
HUB1／SPOKE2 の `delay`	100	10
IP MTU／TCP MSS	1386／1346	1400／1360
SPOKE2 の tunnel source	Dialer1	GigabitEthernet0/0/0

ここでの「IPv4／IPv6 冗長化」は、IPv4 LAN の経路を、外側が IPv4／IPv6 の2つのクラウドで運ぶ構成を指します。4台とも EIGRP for IPv6 の隣接と EIGRP 学習 IPv6 経路は確認されていません。

IPv6 LAN の経路も運ぶ場合は、overlay の IPv6 アドレス、IPv6 NHRP、EIGRP for IPv6 を別途設計します。詳細は Cisco の IPv6 over DMVPN ガイドを参照してください。

また、Hub は1台で、SPOKE2 は同一装置の WAN と Dialer を利用しています。図の2クラウドは、物理回線・装置・電源の独立性まで示すものではありません。回線断や装置故障にどこまで耐えられるかは、共有する物理区間も含めて考える必要があります。

IKEv2とkeyringの参照関係

認証方式、鍵の保存先、暗号方式を分ける

IKEv2 の設定は、次のように役割を分けると追いやすくなります。Cisco の IKEv2 設定ガイドでも、proposal、policy、profile、keyring をそれぞれ定義します。

Tunnel4 / Tunnel6
  └─ IPsec profile
       ├─ transform-set（ESP の暗号方式・モード）
       └─ IKEv2 profile
            ├─ peer identity・認証方式・DPD
            ├─ keyring local → 認証用 PSK
            └─ keyring ppk   → 追加 PPK

IKEv2 policy → proposal（IKE SA の暗号・PRF・DH 等）

今回の参照先は次のとおりです。

Tunnel	IPsec profile	IKEv2 profile	認証用 PSK／PPK の keyring
Tunnel4	DMVPN_IPSEC_PROFILE_V4	DMVPN_PROFILE_V4	DMVPN_KR
Tunnel6	DMVPN_IPSEC_PROFILE_V6	DMVPN_PROFILE_V6	DMVPN_KR

keyring local と keyring ppk は同じ keyring 名を参照できますが、取り出す鍵の用途が異なります。keyring に鍵が定義されているだけでは、その鍵を使っているとは判断できません。Tunnel から profile、profile から keyring へ参照をたどります。

認証用PSKとPPKをkeyringにまとめる

以下は、両 transport の鍵と参照関係を示した説明用の抜粋です。<...> は伏せた鍵の値を表し、実際の設定文字列ではありません。peer の address／identity、profile の match／DPD、IPsec の transform-set 参照などは省略しています。

crypto ikev2 keyring DMVPN_KR
 peer DMVPN_PEER_V4
  ! peer の照合条件は省略
  pre-shared-key <PSK_FOR_IPV4>
  ppk manual id 4 key <PPK_FOR_IPV4>
 !
 peer DMVPN_PEER_V6
  ! peer の照合条件は省略
  pre-shared-key <PSK_FOR_IPV6>
  ppk manual id 6 key <PPK_FOR_IPV6>
!
crypto ikev2 profile DMVPN_PROFILE_V4
 ! match / DPD 等は省略
 authentication local pre-share
 authentication remote pre-share
 keyring local DMVPN_KR
 keyring ppk DMVPN_KR
!
crypto ikev2 profile DMVPN_PROFILE_V6
 ! match / DPD 等は省略
 authentication local pre-share
 authentication remote pre-share
 keyring local DMVPN_KR
 keyring ppk DMVPN_KR
!
crypto ipsec profile DMVPN_IPSEC_PROFILE_V4
 ! transform-set の参照等は省略
 set ikev2-profile DMVPN_PROFILE_V4
!
crypto ipsec profile DMVPN_IPSEC_PROFILE_V6
 ! transform-set の参照等は省略
 set ikev2-profile DMVPN_PROFILE_V6

authentication local pre-share と authentication remote pre-share は認証方式を指定し、認証用 PSK の参照先を keyring local DMVPN_KR に揃えています。policy／proposal は PSK の保存先ではありません。

動的な WAN アドレスからの接続を許す場合も、peer の照合範囲と鍵の共有単位を明確にします。共有範囲が広ければ鍵更新の影響範囲も広がるため、接続を許す相手と更新手順を合わせて設計します。

なお、SPOKE3 の IPv4 policy／profile／Tunnel4 には fvrf 条件があります。この抜粋を4台へそのまま一括適用できる構成としては扱いません。

Manual PPKとML-KEMは何が違うのか

3種類の鍵の役割

項目	役割	今回確認できたこと
認証用 PSK	IKEv2 の相手認証に使う共有鍵	両 transport の新しい SA で PSK 認証が成功
Manual PPK	事前共有した追加の鍵を、セッション鍵の導出に混ぜる	両 transport の DMVPN SA で Manual PPK の使用を確認
ML-KEM	従来方式と組み合わせて使うハイブリッド鍵交換	今回の4台では成立を示す SA 表示を確認していない

Manual PPK の設定は Cisco の PPK 設定ガイドに基づきます。PPK ID と鍵の値を両端で揃え、profile から PPK の keyring を参照します。

PPK の利用には、鍵そのものの強度と配布・更新の運用が伴います。RFC 8784 のセキュリティ考慮事項では、少なくとも256 bitのエントロピーを持つ PPK を強い実践として挙げています。人が覚えやすいパスワードを設定しただけで、同じ強度が得られるわけではありません。

また、「今回の SA で PPK が使われたこと」と「PPK が使えない相手との接続を拒否すること」は別の確認です。Cisco の ppk manual ... required は、PPK を必須とするための指定です。PPK なしへのフォールバックを禁止する要件がある場合は、この指定と非対応 peer への挙動も確認します。

proposalのML-KEM設定だけで成立を判断しない

HUB1 の IPv4 policy は default proposal を使い、そこには次の設定があります。

pqc mlkem768 mlkem1024 optional

一方、IPv6 policy は専用の DMVPN-PROPOSAL を参照しています。

Cisco の IKEv2 PQC ガイドでは、optional は peer が ML-KEM に対応しない場合の従来方式へのフォールバックを許します。したがって、この行があることだけでは ML-KEM の交渉成功を示せません。

また、同ガイドの対象となる Cisco 8000 Series Secure Routers と、今回の Catalyst C8300-1N1S-6T は区別して対応条件を確認する必要があります。

今回の記事で実機確認済みとして扱うのは Manual PPK です。ML-KEM の確認観点は、別記事の「Cisco IOS XE 26.1.1 で IKEv2/IPsec の PQC対応が来た」も参照してください。

両transportでPPKを確認した時点

検証途中は、IPv4 側の peer に PPK ID 4 の定義があっても、IPv4 profile からは参照していませんでした。その後、4台の DMVPN_PROFILE_V4 に keyring ppk DMVPN_KR を追加しています。

各 Spoke の Hub 向け IPv4 SA を1接続ずつ再確立し、新しい SPI、PSK 認証、Manual PPK、Hub 側との送受信 SPI の対応、ping と EIGRP の復旧を確認しました。IPv6 側も、それ以前に新しい SA による PSK 認証と Manual PPK の使用を確認しています。

最終確認では、4台の両 profile が PPK を参照し、両 transport のすべての DMVPN READY SA で Manual PPK が使われていました。Hub―各 Spoke の両方向、Tunnel4／Tunnel6 の計12組はすべて ping 5/5 成功です。2026年10月21日00:45 JST に保存し、startup-config の読戻しでも参照先を確認済みです。

既存 SA が維持されていることに加えて、新しい SA で認証できることまで確認した点が、鍵の参照先を変える際の重要な確認になります。

EIGRPでTunnel6を優先し、Tunnel4を待機経路にする

delayで経路の優先順位をつける

HUB1 と SPOKE2 は帯域設定を揃え、Tunnel6 を delay 10、Tunnel4 を delay 100 としています。

EIGRP の通常のメトリック計算では、経路上の帯域と設定された delay を使います。delay は測定した ICMP RTT や EIGRP neighbor の SRTT を自動的に反映する値ではありません。Cisco の EIGRP 解説

SPOKE2 の Tunnel 設定から、アドレス・メトリック・MTU・source・IPsec profile の関係を抜き出すと次のようになります。NHRP、tunnel key、帯域などの設定は省略しています。

SPOKE2：Tunnel4／Tunnel6の設定値の抜粋

interface Tunnel4
 ip address 10.255.4.12 255.255.255.0
 ip mtu 1386
 ip tcp adjust-mss 1346
 delay 100
 tunnel source Dialer1
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN_IPSEC_PROFILE_V4
!
interface Tunnel6
 ip address 10.255.6.12 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 delay 10
 tunnel source GigabitEthernet0/0/0
 tunnel mode gre multipoint ipv6
 tunnel protection ipsec profile DMVPN_IPSEC_PROFILE_V6

HUB1 の Tunnel IP はそれぞれ 10.255.4.1、10.255.6.1 です。LAN 側は passive とし、SPOKE2 は 10.20.0.0/22 を両クラウドに集約広告しています。Hub では、同じ multipoint インターフェースの他 Spoke へ経路を広告できるよう、EIGRP の split horizon を無効にしています。

topologyとCEFで主系・待機系を見る

HUB1 の 10.20.0.0/22 に対しては、Tunnel6 経由が選ばれていました。

HUB1：EIGRP topologyとCEFの実機出力の抜粋

確認コマンド：

show ip eigrp topology

出力の該当部分：

P 10.20.0.0/22, 1 successors, FD is 5376
        via 10.255.6.12 (5376/2816), Tunnel6
        via 10.255.4.12 (28416/2816), Tunnel4

確認コマンド：

show ip cef 10.20.0.1 detail

出力：

10.20.0.0/22, epoch 2
  QOS: Precedence routine (0)
  nexthop 10.255.6.12 Tunnel6

(5376/2816) の左側はその隣接経由の合計メトリック、右側は隣接が通知した Reported Distance（RD）です。Tunnel4 側は合計メトリックが28416と大きいため、通常時の優先経路にはなりません。

一方、待機側の RD は2816で、表示されている Feasible Distance（FD）の5376より小さく、2816 < 5376 を満たします。つまり、この採取時点の Tunnel4 直接経路は Feasible Successor の条件を満たしています。Cisco の EIGRP コマンドリファレンス

ここまでで確認できたのは、優先経路が転送に使われ、待機経路が topology に保持されていることです。主系を止めた際のパケット欠落数や切替時間は、停止試験による別の確認が必要です。

支店をトランジットにするかも決める

現行 Spoke に eigrp stub はなく、HUB1 の詳細 topology には、別の Spoke を経由して山梨側 LAN へ向かう候補も表示されました。

このような経路を許容するかは拠点の役割次第です。支店をトランジットとして使わない設計にする場合は、stub や経路フィルターを含めて設計します。今回、その変更は行っていません。

default route の再配送と受信フィルター、WAN 宛経路が overlay へ再帰しないこと、往復でどの経路が選ばれるかも、2クラウド構成で確認したい点です。Front-door VRF を使う設計は Cisco の DMVPN Spoke の ISP 冗長化例が参考になります。

IKEv2から転送経路までを順に確認する

確認は、鍵の参照関係、SA、NHRP、EIGRP、RIB／CEF、実通信の順に進めると切り分けやすくなります。

確認対象	主なコマンド	見る点
鍵の参照	`show crypto ikev2 profile`	Keyring と PPK の参照先。running-config とも照合
IKEv2 SA	`show crypto ikev2 sa detailed`	READY、PSK 認証、PPK 使用、再確立前後の SPI
DMVPN／NHRP	`show dmvpn detail`、`show ip nhrp`	peer の状態、Tunnel IP と外側アドレスの対応
EIGRP 隣接	`show ip eigrp neighbors detail`	両 Tunnel の隣接、Hello／Hold、稼働時間
EIGRP 経路候補	`show ip eigrp topology`	successor、FD、待機側のメトリックと RD
RIB	`show ip route 10.20.0.1`	選択された経路
CEF	`show ip cef 10.20.0.1 detail`	実際の転送先 Tunnel と next hop
IPsec データ通信	`show crypto ipsec sa`	データ暗号方式、実通信前後の送受信カウンター

最後の IPsec カウンター確認は追加検証項目です。IKEv2 SA が READY であることと、意図した経路でデータが送受信されることを分けて確認します。

また、17.18.05 の今回の機器では、NETCONF の native／modelled CLI 表示に PPK 定義や keyring ppk が出ないケースがありました。取得したモデル表示だけで「PPK 設定がない」と判断せず、SSH の running-config と runtime 表示でも照合しています。

東京―山梨間のICMP実測

測定条件

2026年10月21日 00:38:35〜00:38:56 JST に、HUB1 と SPOKE2 の両方向で測定しました。

各方向・各 transport で事前に5回 ping した後、100回を3セット実行。
パケットサイズは100 byte、timeout は1秒。
東京側と山梨側の測定は並行して実施。
宛先を各 Tunnel の相手アドレスに分け、CEF が対応する Tunnel を示すことを確認。

この RTT 測定は IPv4 側への PPK 追加前の結果です。 この時点では Tunnel6 で PPK を使用し、Tunnel4 は PPK 未使用でした。00:45 JST の保存後に、同条件の100回×3セットを測り直した結果は含めていません。

経路別ICMPの実行コマンド

HUB1 → SPOKE2。各コマンドを3セット実行：

ping 10.255.4.12 source Tunnel4 repeat 100 size 100 timeout 1
ping 10.255.6.12 source Tunnel6 repeat 100 size 100 timeout 1

SPOKE2 → HUB1。各コマンドを3セット実行：

ping 10.255.4.1 source Tunnel4 repeat 100 size 100 timeout 1
ping 10.255.6.1 source Tunnel6 repeat 100 size 100 timeout 1

送信元の source Tunnel4 指定だけで、任意の LAN 宛通信の出口を固定できるわけではありません。今回は相手の Tunnel IP を宛先とし、対応する経路を確認して測っています。

結果

下表の成功数と RTT には、事前の5回を含めていません。

方向	transport／Tunnel	成功数	各100回の平均 RTT	全セットの最小／最大 RTT
HUB1 → SPOKE2	IPv4／Tunnel4	300/300	21、16、15 ms	12／60 ms
HUB1 → SPOKE2	IPv6／Tunnel6	300/300	10、10、10 ms	8／12 ms
SPOKE2 → HUB1	IPv4／Tunnel4	300/300	21、15、15 ms	12／64 ms
SPOKE2 → HUB1	IPv6／Tunnel6	300/300	10、10、10 ms	8／36 ms

測定したのは、IPv4 ICMP を各 DMVPN トンネルに通した RTT です。IPv6 ICMP 自体の比較ではありません。

加えて、HUB1 の LAN 側アドレス 10.10.0.1 を送信元に、SPOKE2 の 10.20.0.1 へ20回 ping した結果は、20/20成功、RTT の最小／平均／最大が 8/11/12 ms でした。採取時の CEF は Tunnel6 を示しています。これはルータ自身への疎通で、拠点端末同士の通信は別途確認が必要です。

この測定では IPv6 transport 側の RTT が低くなりました。ただし、回線経路、PPPoE／IPoE、時刻などの条件を分離した試験ではありません。IPv6 一般の優位性や、PPK／PQC による負荷の差を示す結果とは扱いません。2019年の測定とも回線・機器・時間帯が異なるため、単純な性能向上率は算出していません。

BFDとMTUの確認ポイント

BFDのUpとEIGRPの切替時間を分ける

Tunnel6 では BFD の Up を確認しています。送受信タイマーは1000 ms、multiplier 5、echo なしです。一方、登録プロトコルは NHRP CEF で、採取した出力に EIGRP の登録はありませんでした。EIGRP の Hello／Hold は両 Tunnel とも5秒／15秒です。

そのため、BFD が Up であることから EIGRP の切替時間を断定できません。Cisco の DMVPN BFD ガイドと照合し、BFD の障害検出、NHRP／CEF の反応、EIGRP の経路切替を分けて確認する必要があります。

MTUとMSSは採取時の設定値

今回の IP MTU／TCP MSS は、Tunnel4 が1386／1346、Tunnel6 が1400／1360でした。これらは採取時の設定値で、すべての回線で使える推奨値として示しているわけではありません。100 byte の ping 成功だけでは、大きなパケットや TCP 通信時の動作までは確認できません。

DF 付き ping や実際の TCP 通信を使って、MTU、MSS、PMTUD の関係を追加確認します。

まとめ

今回の実機構成では、IKEv2 の認証用 PSK を keyring に集約し、IPv4／IPv6 transport の両方で Manual PPK を使うところまで確認できました。鍵の定義、profile の参照、使用中 SA、さらに新しい SA での再認証を順に確認すると、設定と動作を対応づけられます。

経路制御では、EIGRP によって Tunnel6 が優先され、Tunnel4 が Feasible Successor の条件を満たしていました。東京―山梨間では各方向・各 transport とも300/300の ping が成功し、採取時は IPv6 transport 側の RTT が低い結果でした。

参考資料

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up