はじめに
FastConnect で、仮想回線の優先度を下げてトラフィックを退避させるドレイン機能が利用できるようになりました。
今回は OCI と Megaport を接続し、ドレイン機能の有効化・解除によって、双方の優先経路と BGP 属性がどのように変化するかを検証しました。
本記事で確認するのは、経路表と BGP 属性の変化です。実際の通信における瞬断の有無、パケットロス、切替時間は測定していません。
前提
ドレイン機能は、対象の仮想回線を非優先にして、別の経路へトラフィックを退避させるための機能です。
公式ドキュメントでは、FastConnect Partner または FastConnect Direct の仮想回線ごとに設定でき、OCI から対向へ広告する経路に次の処理を行うと説明されています。
- Graceful Shutdown community（
65535:0）を付与する。 - AS Path Prepend を行う。
対向機器が Graceful Shutdown community に対応したポリシーを持つ場合、受信した経路の Local Preference を下げることで、別の回線を優先できます。Local Preference は対向機器内で扱う属性であり、OCI からその値を直接広告するわけではありません。
この処理は、Oracle が FastConnect の計画メンテナンスで行う経路の非優先化と同様のものです。ドレイン機能によって、メンテナンス前の経路退避に相当する挙動を確認できます。
利用を検討するケースとして、次が挙げられます。
- メンテナンス前に、冗長回線への経路切替が想定どおりに行われるか確認する。
- 現在の経路設計や機器の動作ではメンテナンス時に通信断が懸念されるため、あらかじめ対象回線を非優先にする。
- オンプレミス側のルータメンテナンスで、CPE の停止や BGP の再計算に備え、OCI 側から経路退避を操作する。
- 対向が他社クラウドなどで、利用サービスや接続構成によって BGP 設定の変更が制限される場合に、OCI 側からの制御を検討する。
いずれも、利用可能な代替経路があることと、対向側の経路ポリシーを確認する必要があります。
参考：
構成
OCI の DRG と Megaport Cloud Router（MCR）を、2本の FastConnect プライベート仮想回線で接続しました。同じ宛先に対して2つの経路を用意し、回線1をドレインしたときの経路選択を確認します。
Megaport と OCI の接続については、こちらの記事も参考になります。
パラメータ
今回の検証で確認する主な BGP パラメータをまとめます。
| 項目 | 回線1 | 回線2 |
|---|---|---|
| OCI 側 ASN | 31898 |
31898 |
| Megaport MCR 側 ASN | 133937 |
133937 |
| OCI 側 BGP ピアアドレス | 192.168.0.1 |
192.168.0.5 |
| Megaport 側 BGP ピアアドレス | 192.168.0.2 |
192.168.0.6 |
| Megaport 側の「AS パス追加」設定 | 追加なし | 1 |
| ドレイン前に MCR が表示した Local Preference | 100 |
100 |
| ドレイン前に MCR が表示した OCI 宛て経路の AS_PATH | 31898 |
31898 |
| 今回のドレイン対象 | 対象 | 対象外 |
OCI → Megaport の経路については、回線1を優先するため、Megaport 側で回線2に AS Path Prepend を1回追加しています。これは、Megaport から OCI に広告する経路に対する設定です。
一方、Megaport → OCI の経路については、Local Preference による通常時の優先度差を設定せず、ドレイン機能による属性の変化を確認します。ドレイン前は、両回線の Local Preference が 100、AS_PATH が 31898 です。
ドレイン機能を使う前の優先経路
ドレイン前は、OCI 側と Megaport 側の両方で回線1が選択されています。
OCI 側の DRG ルート表では、回線1が「アクティブ」、回線2が「競合」と表示されています。
Megaport 側では、OCI のプレフィックス 10.1.0.0/24 に対して、回線1のネクストホップ 192.168.0.1 が最適な経路として選択されています。
両回線とも、表示されている Local Preference は 100、AS_PATH は 31898 です。この画像で確認できる属性には差がないため、回線1が選択された理由までは特定していません。
MCR のルッキング・グラスを使うと、BGP 情報や経路情報を確認できます。
パラメータの確認作業があるときに非常にうれしい機能です。
ドレイン機能をオンにします
OCI コンソールから回線1のドレインを実行します。
ドレイン中の状態表示です。ドレイン状態は「ドレイン済」で、IPv4 BGP 状態は「稼働中」と表示されています。
ドレイン後、OCI 側の DRG ルート表では回線1が「競合」、回線2が「アクティブ」になりました。
OCI → Megaport の経路についても、回線1が非優先になったことを確認できます。ただし、この画面から OCI 内部の Local Preference や AS_PATH の変更内容は確認できません。内部でどの属性を変更しているかは本検証では特定していませんが、挙動から Local Preferenceを低くしているか、AS_PATH を回線1自身に追記していると推測できます。
Megaport 側でも回線2が最適な経路になりました。回線1の BGP 属性には、次の変化がありました。
| MCR 上で確認した項目 | 回線1：ドレイン前 | 回線1：ドレイン中 | 回線2：ドレイン中 |
|---|---|---|---|
| Local Preference | 100 |
0 |
100 |
| AS_PATH | 31898 |
31898 31898 31898 31898 |
31898 |
| 最適な経路 | - | 非優先 | 優先 |
回線1は、Local Preference が 100 から 0 に下がり、AS_PATH には Oracle の ASN 31898 が3回追加されています。Megaport → OCI の経路も、回線2が優先されています。
公式ドキュメントの説明どおり、Local Preference の低下と AS Path Prepend の追加を確認できました。ただし、今回の画像では Graceful Shutdown community（65535:0）自体は表示されておらず、受信を直接確認できたわけではないですが、受信をして Local Preference の低下が起きたのだと推測できます。
ドレイン機能をオン → オフにします
続いて回線1のドレインを解除します。
解除後、ドレイン状態は「ドレイン解除済」と表示されます。
OCI 側では回線1が再び「アクティブ」となり、回線2は「競合」に戻りました。回線2に設定した AS Path Prepend による通常時の経路設計と整合する結果です。
Megaport 側では、回線1の Local Preference と AS_PATH が元の値に戻りました。一方、最適な経路は回線2のままでした。
表示されている Local Preference と AS_PATH は両回線で同じです。これらの属性が同じ状態で、回線2が選択され続けた理由は、本検証では特定できませんでした。
| MCR 上で確認した項目 | 回線1：解除後 | 回線2：解除後 |
|---|---|---|
| Local Preference | 100 |
100 |
| AS_PATH | 31898 |
31898 |
| 最適な経路 | 非優先 | 優先 |
Megaport → OCI でも通常時に回線1を優先させたい場合、回線1の Local Preference を高く設定する方法が候補になります。
今回の結果を方向別にまとめると、次のとおりです。
| 確認した方向 | ドレイン前 | 回線1のドレイン中 | ドレイン解除後 |
|---|---|---|---|
| OCI → Megaport：DRG ルート表の選択経路 | 回線1 | 回線2 | 回線1 |
| Megaport → OCI：MCR の選択経路 | 回線1 | 回線2 | 回線2※ |
※回線1の Local Preference を高く設定すれば回線2ではなく回線1が優先される
終わりに
FastConnect のドレイン機能を使い、OCI 側と Megaport 側で回線1が非優先になり、回線2が選択されることを確認しました。Megaport 側では、Local Preference の低下と AS Path Prepend の追加も確認できました。
対向ルータ側での経路制御に加えて、OCI 側の設定から対象回線をドレインできるようになったことで、計画メンテナンスの事前検証や経路退避の選択肢が増えたと考えます。
経路が切り替わることと、実際の通信に影響がないことは分けて確認する必要があります。対向機器の Graceful Shutdown 対応、経路ポリシー、収束中の非対称経路の扱い、退避先の帯域、ワークロードが許容できる通信断などによって、運用上の判断は変わります。