はじめに
DRGv1 の自動アップグレードが 2026 年に行われるという通知がありました。
本記事では、DRGv1 からアップグレード中に、IPSec VPN と FastConnect にどの程度の通信断が見えるかを実測します。
本記事の結果は、あくまでも一例です。
DRGのアップグレード状況、ネットワーク設計、ルーティング設定、BGP タイマー、BFD の有無、アプリケーションのタイムアウト値によって挙動は変わります。
十分なメンテナンス時間を確保したうえでアップグレードすることを推奨します。
構成
検証構成は以下です。
| 項目 | 内容 |
|---|---|
| DRGv1 にアタッチされる VCN | 10.0.0.0/16 |
| Libreswan がある VCN | 10.3.0.0/16 |
| FastConnect キャリア ×2 | Megaport |
| IPSec VPN 対向機器 | Libreswan |
| Hub DRG | DRGv1 -> DRGv2 |
確認した経路は以下です。
| 経路 | 確認内容 |
|---|---|
| VCN1 のインスタンス -> DRGv1 -> IPSec VPN -> IGW -> Libreswan | IPSec VPN 経由のインスタンス同士の ICMP 到達性 |
| VCN1 のインスタンス -> DRGv1 -> FastConnect -> Megaport の BGP セッション用 endpoint | FastConnect/BGP 側の ICMP 到達性 |
検証中は ping とパケットキャプチャを取得しました。
その後 DRGv1 をアップグレードし、各経路でどのような通信断が発生するかを確認しました。
環境作成
検証で利用した主な宛先は以下です。
| 対象 | 値 |
|---|---|
| VCN1 インスタンス | 10.1.0.11 |
| Libreswan | 10.3.0.33 |
| FastConnect BGP endpoint 1 | 172.16.0.1 |
| FastConnect BGP endpoint 2 | 172.16.0.5 |
測定方法
VCN1 のインスタンスから IPSec VPN 側と FastConnect 側に対して継続 ping を実行しました。
Libreswan 側から VCN1 のインスタンスへも継続 ping を実行しました。
例です。
ping -O 10.3.0.33 2>&1 | while IFS= read -r line; do
printf '%s %s\n' "$(date '+%Y-%m-%d %H:%M:%S')" "$line"
done | tee ~/drg-test-logs/ins1-to-libres3.log
ping -O 172.16.0.1 2>&1 | while IFS= read -r line; do
printf '%s %s\n' "$(date '+%Y-%m-%d %H:%M:%S')" "$line"
done | tee ~/drg-test-logs/ins1-to-fastconnect-bgp1.log
パケットキャプチャも取得しました。
sudo tcpdump -i ens3 -nn 'icmp and src net 10.0.0.0/8 and dst net 10.0.0.0/8' \
-w ~/drg-test-logs/ins1-ens3-icmp-10net-only.pcap
DRG アップグレード
検証結果としてIPsec VPN -> FastConnect1 -> FastConnect2の順番で接続断が発生したので、ドキュメント通り、順番にアップグレードされることを確認しました。
IPSec VPN
IPSec VPN 側では、約 24 秒の通信断が観測されました。（エンドツーエンドの通信）
Libreswan から VCN1 インスタンスへの ping では、2026-05-28 09:34:53 から 09:35:16 まで応答断が発生しました。
2026-05-28 09:34:51 64 bytes from 10.1.0.11: icmp_seq=138 ttl=61 time=1.91 ms
2026-05-28 09:34:52 64 bytes from 10.1.0.11: icmp_seq=139 ttl=61 time=1.87 ms
2026-05-28 09:34:53 From 10.3.0.33 icmp_seq=140 Destination Host Unreachable
...
2026-05-28 09:35:16 no answer yet for icmp_seq=162
2026-05-28 09:35:16 64 bytes from 10.1.0.11: icmp_seq=163 ttl=61 time=1.82 ms
2026-05-28 09:35:17 64 bytes from 10.1.0.11: icmp_seq=164 ttl=61 time=1.76 ms
VCN1 インスタンスから Libreswan への ping でも、同じ時間帯に応答断が見えました。
アップグレード後のルート一覧では、IPSec Tunnel T2 が active、T1 が競合として見えています。
この結果だけでは、トンネルごとの正確なアップグレード順序は判断できません。
観測結果からは次のような流れだった可能性があります。
- Tunnel2 側が先にアップグレードされ、この時点では通信影響はなし。
- その後 Tunnel1 側がアップグレードされ、IPSec VPN の DPD タイマーに達した。
- 経路が Tunnel2 側へ切り替わり、通信が復旧した。
- 復旧後も Tunnel2 側が優先経路として使われ続けた。
FastConnect
FastConnect の BGP endpoint 1 では、約 14 秒の応答断が観測されました。
2026-05-28 09:36:55 64 bytes from 172.16.0.1: icmp_seq=252 ttl=62 time=0.541 ms
2026-05-28 09:36:56 64 bytes from 172.16.0.1: icmp_seq=253 ttl=62 time=0.594 ms
2026-05-28 09:36:58 no answer yet for icmp_seq=254
...
2026-05-28 09:37:10 no answer yet for icmp_seq=266
2026-05-28 09:37:10 64 bytes from 172.16.0.1: icmp_seq=267 ttl=62 time=0.524 ms
FastConnect の BGP endpoint 2 では、2026-05-28 09:39:54 以降に Destination Net Unreachable と no answer yet が観測されました。
Megaport 側ログでは 09:39 時点で BGP セッションの再確立が見えています。
このため、すぐにアップグレードが完了したことを確認できました。
アップグレード後の確認
DRG がアップグレードされると、DRG 画面の列に「ルーティング」が出てきてDRGv2になったことを確認できるようになります。
終わりに
今回の検証では、DRGv1 から DRGv2 へアップグレードする際に、IPSec VPN 側で約 24 秒、FastConnect 側で約 14 秒の通信断を観測しました。
メンテナンス時間を十分に確保し、復旧後の確認手順を準備しておけば、作業自体は大きく複雑ではないと思います。
一方で、本番環境の通信が流れている状態でネットワーク変更の影響を見積もるには、より多くの確認が必要になります。
例えば、BGP attribute、BGP timer、BFD の有無、IPSec VPN の DPD、アプリケーションのタイムアウト値などを事前に確認しようとすると、調査、検証、監視、切り戻し判断まで含めて相応の工数が必要です。
そのため、自動アップグレードを待つよりも、事前にアップグレードしておく方が全体の工数を抑えやすいケースもあると思います。
最後に、今回の結果はあくまでも一例なので、実際の環境では異なる可能性があることにご留意ください。