専用線とIPsecバックアップの併用における切替遅延と転送性能
ある企業は、オンプレミスのデータセンター（AS 65001）とクラウド（AS 64512）を、1Gbpsの専用線接続とインターネット経由のIPsec VPN（実効200Mbps）で接続している。専用線側はeBGPで経路交換し、クラウドのVPC CIDR（/16）をローカルプリファレンス200で受信している。VPN側も同じ経路をローカルプリファレンス100で受けており、通常は専用線が優先される。BGPのKeepaliveは60秒、Holdtimeは180秒で、BFDは未設定である。オンプレ側の境界ルータは1台構成で、VPN終端も同一機器で行っている。先月、専用線の保守作業で回線が10分間切断された際、VPNへの切り替えに約3分かかり、その間の業務システムのセッションが切れ、復旧後もアプリケーションを手動で再起動するまで回復しなかった。さらに、VPN経由で通信している間、大容量ファイル転送が極端に遅いという報告があった。VPN区間のMTUは1,400バイトに設定されているが、MSS調整は行っていない。監視担当からの要望は「次回の保守までに切り替えを速くしてほしい」という一点のみである。
1. 切替に約3分を要した原因を、BGPのタイマと経路選択の観点から説明せよ。そのうえで、切替時間を10秒以内に短縮する設計を、実現可能性と副作用を含めて提案せよ。
Read the worked answer
原因の分解
- BGPの障害検出はKeepalive 60秒／Holdtime 180秒に依存する。Holdtimeは「3回分のKeepaliveが届かない場合にピアダウンとみなす」設計であり、最悪180秒（3分）検出できない。実測3分はこの値と一致する。
- 物理インターフェースのダウンなら即時検出されるが、伝送装置の障害や片方向断、保守作業に伴う論理的な停止ではインターフェースがUpのまま残る。今回はこのケースである。
- BGPは「経路の撤回を受けてから」代替経路に切り替わる。VPN側のセッションが常時Establishedで、VPN経由の経路が事前にRIBへ入っていなければ、切替はさらに遅れる。
短縮設計（複合が必要）
- BFDの導入：専用線区間にBFD（例：300ms×3）を設定する。BFDエコーモードが使えるか、クラウド側／キャリア側がBFDに対応しているかを事前に確認する。対応していない場合はこの案は成立しない。
- BGPタイマの短縮：Keepalive 10秒／Holdtime 30秒。両端で設定が必要で、ピア間でネゴシエーションされるため片側だけでは効かない。CPU負荷の増加と、瞬断時のフラップ誘発に注意する。
- 事前準備の徹底：VPN側のBGPを常時Upにし、より長いAS_PATHまたは低いローカルプリファレンスで待機させる。切替は「経路選択の変更」だけで済むようにする。
- BFD＋経路追跡：ルータのIP SLAで上位回線の到達性を監視し、スタティックのバックアップへ切り替える構成も併用候補になる。
副作用
- BFDの誤検出（マイクロバーストやCPU高負荷時）で不要な切替が起きる。しきい値は保守的にし、切替ログを監視する。
- タイマ短縮はフラップを増幅させるため、結局セッション断が増える可能性がある。BFDがあればBGPタイマは据え置きでよい。
- 同一機器でVPN終端しているため、機器障害時は両系が同時に落ちる。冗長性の観点では別機器化を検討する必要がある。
2. VPN経由時の大容量ファイル転送が極端に遅い原因を説明し、対策を示せ。数値の根拠も示すこと。
Read the worked answer
原因1：MTUとMSSの不整合
- VPN区間のMTUは1,400バイトだがMSS調整を行っていない。サーバは自身のMTU 1,500から算出したMSS（1,460バイト）を通知してしまう。
- IPsec（ESP）でさらにヘッダが付加されるため、1,400バイトを超えるパケットはカプセル化後に破棄されるか、フラグメントされる。フラグメントは1個でも欠けると再送になり、実効スループットが大きく落ちる。
- PMTUDがICMP遮断で機能していれば、この症状は恒久化する。
対策
- 両端ルータのトンネルインターフェースでTCP MSSクランプを設定する。目安は1,400 − 20（IPヘッダ）− 20（TCPヘッダ）＝1,360、IPsecのオーバーヘッド（ESPヘッダ・トレーラ、新IPヘッダで概ね50〜70バイト）を見込むなら1,340程度とする。
- サーバ側OSのMSS上限設定を併用し、経路変更時の影響を抑える。
- PMTUDに必要なICMP（Type 3 Code 4／ICMPv6 Type 2）を、確立済みセッションに関連する範囲で許可する。
原因2：帯域遅延積（BDP）とTCPウィンドウ
- 例えばRTT 30ms、帯域200Mbpsの場合、BDP＝200Mbps×0.03s＝約750KBである。TCPウィンドウが64KBのままだと、理論値でも64KB÷0.03s≒17Mbpsしか出ない。
- 対策としてウィンドウスケーリングの有効化、受信バッファの拡大、必要であればWAN最適化装置やマルチストリーム転送を検討する。
評価 MSSクランプは即効性があり副作用も小さい。BDP対策はアプリケーションの実装依存であり、ベンダと協議が必要になる。切り分けとしては、まずiperf等で「帯域が出ないのか、ロスで減っているのか」を測るのが先である。
3. 監視担当の要望は「切替を速くする」ことだけである。この要望のまま設計を進めることの問題点を指摘し、業務要件として定義し直すべき項目を挙げよ。
Read the worked answer
問題点
- 切替時間を短縮しても、TCPセッションは切替の瞬間に必ず切断される。今回の「手動再起動するまで回復しなかった」事象は、切替時間ではなくアプリケーションのリトライ設計と状態管理の問題である。切替を3秒にしても同じ事象は再発する。
- 対策の対象が「ネットワークの検出時間」に限定され、アプリ・DNS・認証・セッションの継続性が抜け落ちる。
- 「速くする」は測定方法が定義されていないため、受入試験ができない。
業務要件として定義し直すべき項目
- 目標復旧時間（RTO）と目標復旧時点（RPO）：業務システムごとに、何秒の停止まで許容できるかを決める。決めるのはネットワーク部門ではなく業務部門である。
- 切替の測定定義：何をもって切替完了とするか（BGP経路の切替か、アプリの疎通回復か）を明文化する。
- アプリケーションの耐障害性：短いタイムアウトでのリトライ、冪等性の確保、コネクションプールの再作成、DNSのTTL短縮。
- 状態の引き継ぎ：VPN側へ切り替わった際に、セッションを維持できるのか、再ログインが必要なのかを業務側と合意する。
- 切替の起動条件：自動切替か手動判断か。誤切替のリスクと、保守作業時の事前切替手順を決める。
- 監視と訓練：実際に専用線を止める障害訓練を定期的に実施し、切替時間と業務影響を実測する。
ネットワーク設計は「機器の設定値」ではなく「業務がどこまでの停止を許容するか」から逆算して決めるべきである。