この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第23回です。
第3章では、BGP、インターネット冗長化、ゲートウェイ冗長化、 QoS、SD-WAN、SASEなど、企業ネットワークで使われる 高度なネットワーク技術を学びます。
冗長インターネット接続とは？2回線・2ISP・BGPの設計ポイントを解説
「インターネット回線を2本にすれば冗長化できる」と考えがちですが、 実際には回線、ISP、ルーター、ファイアウォール、ルーティング、 NAT、障害検知まで考えなければ、本当に止まりにくい構成にはなりません。 この記事では、企業ネットワークで冗長インターネット接続を設計するときの 考え方を体系的に解説します。
インターネット接続は、多くの企業ネットワークで 最も重要な外部接続の一つです。
SaaS、クラウド、Web会議、VPN、メールなどをインターネット経由で利用している場合、 インターネット回線の停止が、そのまま業務停止につながることもあります。
そのため設計者は、「2回線にするか」だけではなく、 どの障害まで耐えたいのかを考えながら冗長化範囲を決める必要があります。
この記事を読み終えるとできること
- 冗長インターネット接続の目的を説明できる
- 同一ISPと異なるISPの違いを比較できる
- BGPを使う場合・使わない場合を判断できる
- 送信方向と受信方向の経路制御を区別できる
- 障害検知と経路切り替えを設計できる
- NAT・公開サービスへの影響を説明できる
- 冗長化構成の単一障害点を洗い出せる
- 顧客要件から適切な構成案を比較できる
冗長インターネット接続とは何か
冗長インターネット接続とは、 回線・ISP・ルーターなどを複数用意し、 一部に障害が発生しても別経路を使って インターネット通信を継続できるようにする設計です。
最も単純なインターネット接続は、1本の回線と1台のルーターで構成できます。
単一インターネット接続
この構成では、次のどこか一つが停止すると インターネット通信が失われる可能性があります。
- アクセス回線
- 回線終端装置
- エッジルーター
- ファイアウォール
- ISP設備
- 収容局・上位ネットワーク
冗長化の本質は「台数を増やすこと」ではありません。
単一障害点を洗い出し、 どこが故障しても許容範囲内で通信を継続できるようにすることが目的です。
まず全体を1枚の図で理解する
代表的な企業向け冗長インターネット構成では、 ISP・回線・エッジルーターを複数系統にします。
2ISP・2ルーターによる冗長構成イメージ
Firewall
Core Network
正常時はISP-Aを優先し、 ISP-A側に障害が発生したらISP-Bへ切り替える Active／Standby構成が分かりやすい例です。
ISP-Aを利用
A側の異常を検知
A側経路を無効化
ISP-Bから通信
しかし、実際の設計では 「何をもってISP-Aが故障したと判断するか」が重要です。
インターフェースがDownした場合だけでなく、 ルーターの先にあるISPネットワークで障害が発生する可能性もあります。
冗長インターネット接続の代表的な構成
冗長インターネット接続には、 要件や予算に応じて複数の構成があります。
1回線・1ISP
最もシンプルですが、 回線やISP障害に対する冗長性はありません。
2回線・同一ISP
アクセス回線障害には強くできますが、 ISP全体の障害には弱さが残ります。
2回線・異なるISP
ISP障害まで考慮できます。 企業ネットワークで代表的な冗長化方式です。
BGPマルチホーミング
複数ISPへBGP接続し、 経路広告と経路選択を動的に制御します。
Active／StandbyとActive／Active
| 方式 | 正常時 | メリット | 注意点 |
|---|---|---|---|
| Active／Standby | 一方を主回線として利用 | 設計・運用が比較的シンプル | 待機回線の帯域を通常時に活用しにくい |
| Active／Active | 両方を利用 | 回線帯域を有効利用できる | 経路制御、非対称通信、NAT、FW状態管理が複雑 |
冗長化の目的が「障害時の業務継続」であれば、 必ずしもActive／Activeにする必要はありません。
複雑性と運用負荷も含めて方式を選びます。
同一ISPと異なるISPの違い
2回線を契約しただけでは、 必ずしもISP障害への対策にはなりません。
| 項目 | 2回線・同一ISP | 2回線・異なるISP |
|---|---|---|
| 回線断への耐性 | ○ | ○ |
| ISP設備障害への耐性 | △ | ○ |
| 契約・運用 | 比較的シンプル | 複雑になりやすい |
| 経路制御 | 比較的容易 | BGPなどの検討が重要 |
| 障害ドメイン分離 | 限定的 | 大きく分離しやすい |
2回線でも物理経路が同じ場合がある
ISPを分けても、 建物から外へ出る光ファイバーや配管、 電柱、通信局舎などが共通している場合があります。
「回線契約が2つある」ことと 「物理的に独立した2経路である」ことは同じではありません。
高い可用性が求められる場合は、 回線事業者へ次の点を確認します。
- 建物への引き込み経路
- 収容局
- アクセス回線設備
- キャリア網内の冗長性
- 電源設備
- 保守体制・障害対応時間
可用性を高めるほど、 論理構成だけでなく物理経路も確認する必要があります。
BGPを使う構成と使わない構成
インターネット回線を冗長化するからといって、 必ずBGPが必要になるわけではありません。
BGPを使わない構成
小〜中規模ネットワークでは、 デフォルトルートと死活監視を組み合わせることで 冗長化できる場合があります。
デフォルトルートによるPrimary／Backup構成
例えば、 主回線側のデフォルトルートを優先し、 障害時にバックアップ側のデフォルトルートへ切り替えます。
BGPを使う構成
複数ISPから経路情報を受け取り、 自社ネットワークのプレフィックスを複数ISPへ広告するような構成では、 BGPを利用します。
BGPマルチホーミングでは、 インターネットから自社への経路と、 自社からインターネットへの経路を ポリシーによって調整できます。
| 判断項目 | デフォルトルート中心 | BGP |
|---|---|---|
| 構成規模 | 小〜中規模向け | 中〜大規模向け |
| 経路制御 | シンプル | 細かく制御可能 |
| 複数ISP | 実現可能な場合あり | 代表的な方式 |
| 自社プレフィックス広告 | 基本的に行わない | 可能 |
| 運用難易度 | 低め | 高め |
BGPは「冗長化するために必ず使うプロトコル」ではありません。
必要な経路制御レベル、アドレス設計、ISP契約、 運用スキルを踏まえて採用します。
BGPで送信・受信経路を制御する
BGPマルチホーミングで特に重要なのが、 OutboundとInboundを分けて考えることです。
Outbound
自社からインターネットへ出ていく通信です。
自社AS内のBGPポリシーで 比較的直接制御できます。
Inbound
インターネットから自社へ入ってくる通信です。
相手側ASの経路選択にも依存するため、 完全に自社だけで決定できるわけではありません。
Outbound：どちらのISPから出すか
自社ASからインターネットへ出る経路では、 BGPのLOCAL_PREFなどを使って 優先ISPを決める方法があります。
Outboundの考え方
例えばISP-A経由で受信した経路へ 高いLOCAL_PREFを設定すれば、 ISP-Aを主経路として選択させる設計ができます。
Inbound：どちらのISPから入ってきてもらうか
外部から自社への通信では、 自社が広告するBGP経路を調整します。
代表的な方法には次があります。
- AS_PATH Prepending
- MED
- ISPが提供するBGP Community
- 広告するプレフィックスの調整
AS_PATH Prepending
バックアップ側へ広告するときに 自AS番号をAS_PATHへ追加し、 経路を相対的に長く見せる方法です。
ただし、インターネット上のすべてのASが AS_PATHの長さだけで経路を決めるわけではありません。
Inbound経路制御は「希望を伝える」設計に近いと考えましょう。
相手ネットワーク側のLOCAL_PREFなど、 より優先度の高いポリシーによって 想定と異なる経路になることがあります。
MED
MEDは、複数の接続点がある場合に、 隣接ASへ「こちらの入口を優先してほしい」と 伝えるために使われます。
特に同一ISPとの複数接続など、 同じ隣接ASとの経路選択で利用しやすい属性です。
BGP Community
ISPによっては、 Communityを利用して次のような経路制御サービスを提供しています。
- ISP内部のLOCAL_PREFを変更する
- 特定地域への広告方法を変更する
- 特定ピアへの広告を制御する
- AS_PATH PrependingをISP側で実施する
実案件では、 ISPのBGP接続仕様書を確認して設計します。
障害をどう検知して切り替えるか
冗長回線を用意していても、 障害を正しく検知できなければ切り替わりません。
そのため、 「何の障害をどの方法で検知するか」 を設計します。
| 障害 | 代表的な検知方法 | 注意点 |
|---|---|---|
| 物理リンク断 | Interface Down | 検知しやすい |
| BGP隣接障害 | BGPセッションDown | 経路Withdrawにつなげられる |
| 隣接ルーターまでの障害 | BFD等 | 高速な障害検知に利用可能 |
| ISP上流障害 | 経路監視・Probe等 | PeerがUpのままの場合がある |
| Internet到達性障害 | 複数宛先への疎通監視 | 監視先の選定が重要 |
Interface Upだけを見てはいけない
例えば、企業ルーターとISPルーターの間は正常でも、 ISP内部の上流側で障害が発生することがあります。
物理リンクは正常でもインターネットへ到達できない例
したがって、 「回線がUpか」だけでなく サービスとしてインターネットを利用できるかまで 確認する設計が必要な場合があります。
切り替え時間を要件化する
「自動で切り替わる」だけでは十分ではありません。
例えば次のように要件化します。
主回線障害発生後、30秒以内にバックアップ回線へ切り替わり、 新規インターネット通信を再開できること。
切り替え時間を決めることで、 BGPタイマー、BFD、経路監視方式などを 設計する根拠ができます。
NAT・公開サービスで注意すること
冗長インターネット接続では、 ルーティングだけ見て設計すると問題が起こることがあります。
特に重要なのが NATとPublic IPアドレスです。
ISPごとにPublic IPが違う場合
ISP-AとISP-Bからそれぞれ異なるPublic IPアドレスを 割り当てられているケースを考えます。
| 回線 | Public IP例 | NAT |
|---|---|---|
| ISP-A | 203.0.113.x | ISP-A用Public IPへ変換 |
| ISP-B | 198.51.100.x | ISP-B用Public IPへ変換 |
ISP-AからISP-Bへ切り替わると、 インターネット側から見える送信元IPアドレスが変わる可能性があります。
その結果、 既存セッションが継続できない場合があります。
回線が切り替わったからといって、 既存のTCPセッションまで無停止で継続できるとは限りません。
公開Webサーバーがある場合
社内から外へ出るだけでなく、 インターネットから社内・DMZのサービスへ接続される場合は さらに設計が複雑になります。
確認する項目には次があります。
- どのPublic IPで公開するか
- ISP切り替え後も同じIPを利用できるか
- BGPで同一プレフィックスを広告できるか
- DNS切り替えを使用するか
- DNS TTLをどう設定するか
- NAT設定を両系統へ用意するか
- ファイアウォールセッションを引き継げるか
自社アドレスを複数ISPへ広告する構成
より高度なBGPマルチホーミングでは、 自社で利用するアドレスプレフィックスを 複数ISPへ広告する構成があります。
この場合は、 AS番号、アドレス割り当て、ISPの経路受け入れポリシー、 BGPフィルタリングなどを含めて設計します。
自社プレフィックスをインターネットへ広告できるかどうかは、 アドレスの割り当て条件やISPのポリシーにも依存します。
実案件では必ずISP・RIR等の条件を確認します。
冗長インターネット接続を設計するときの判断基準
構成を先に決めるのではなく、 要件から方式を選びます。
1．どの障害まで継続したいか
- 回線断だけか
- ルーター故障も対象か
- ファイアウォール故障も対象か
- ISP障害も対象か
- 建物引き込み経路の障害も対象か
2．許容停止時間
- 数分停止してよい
- 1分以内
- 30秒以内
- 数秒以内
必要な切り替え速度が高いほど、 障害検知方式や機器構成も高度になります。
3．Internet経由で利用する業務
- SaaS
- Web会議
- クラウド
- メール
- リモートアクセスVPN
- 外部公開Webサービス
- 外部API連携
4．回線帯域
バックアップ回線が主回線より細い場合、 障害時に全通信を収容できない可能性があります。
主回線1Gbps、バックアップ回線100Mbpsの場合、 「通信できる」ことと 「通常業務を同じ性能で継続できる」ことは別です。
5．運用できるか
高度なBGP設計を導入しても、 運用担当者が経路を確認・変更・障害解析できなければ 運用品質が低下します。
| 要件 | 構成候補 |
|---|---|
| 低コストで回線断だけに備えたい | 2回線＋デフォルトルート切り替え |
| ISP障害にも備えたい | 異なる2ISP |
| 経路を細かく制御したい | BGPマルチホーミング |
| Internet公開サービスを高可用化したい | BGP・DNS・LB等を含めた総合設計 |
冗長インターネット接続でよくある設計ミス
ルーター、ファイアウォール、引き込み経路、 ISP設備などに単一障害点が残っている可能性があります。
ISP内部の障害では、 自社側インターフェースがUpのまま通信できなくなる場合があります。
BGPでは経路受信、経路広告、フィルタリング、 LOCAL_PREF、AS_PATHなどのポリシー設計が必要です。
切り替え後に通信量を処理できず、 強い遅延やパケットロスが発生する可能性があります。
ISP切り替えによってPublic IPが変わると、 セッションやIP制限を利用する外部サービスへ影響する場合があります。
設定上は冗長化されていても、 実際の切り替え時間や通信影響は 試験しなければ確認できません。
「回線断」「ルーター故障」「ISP障害」などの 障害シナリオごとに、 検知・切り替え・通信影響を整理します。
顧客・上司へ冗長インターネット接続をどう説明するか
技術に詳しくない相手へ BGPやLOCAL_PREFから説明する必要はありません。
最初に業務継続の観点で説明します。
説明例：
「現在は1本のインターネット回線に依存しているため、 回線や通信事業者側で障害が発生すると、 クラウドやWeb会議などのインターネットを利用する業務が 一斉に停止する可能性があります。
そこで別系統の回線を用意し、 主回線に障害が発生した場合は 自動的にバックアップ回線へ切り替える構成とします。」
方式比較ではコストとリスクをセットで説明する
| 構成案 | コスト | 可用性 | 運用難易度 |
|---|---|---|---|
| 1回線 | 低 | 低 | 低 |
| 同一ISP 2回線 | 中 | 中 | 中 |
| 異なる2ISP | 中〜高 | 高 | 中〜高 |
| BGPマルチホーミング | 高 | 高 | 高 |
上級エンジニアには、 「最も冗長な構成」を提案するのではなく、 業務影響とコストのバランスを説明する力が求められます。
冗長インターネット接続で使われる英語表現
よく使われる単語
| 英語 | 意味 |
|---|---|
| Internet redundancy | インターネット接続冗長化 |
| Multihoming | 複数の回線・ISPへ接続すること |
| Primary link | 主回線 |
| Backup link | バックアップ回線 |
| Failover | 障害時の切り替え |
| Failback | 復旧後に元経路へ戻すこと |
| Upstream provider | 上位ISP・トランジット事業者 |
| Outbound traffic | 外向き通信 |
| Inbound traffic | 内向き通信 |
| Path preference | 経路優先度 |
設計・問い合わせで使える表現
Do the two Internet circuits use physically diverse paths?
2本のインターネット回線は物理的に異なる経路を使用していますか？
How long does failover normally take?
通常、フェイルオーバーにはどの程度時間がかかりますか？
Do you support BGP multihoming?
BGPマルチホーミングをサポートしていますか？
Can we advertise our own prefixes through both connections?
両方の接続から自社プレフィックスを広告できますか？
Which BGP communities are available for traffic engineering?
トラフィックエンジニアリングに利用できるBGP Communityはどれですか？
理解度チェック
用語暗記ではなく、 冗長インターネット接続を設計できるか確認しましょう。
問題1．インターネット回線を2本契約しただけでは 完全な冗長化とはいえない主な理由はどれですか。
- IPアドレスが必ず同じになるため
- ルーターや物理経路、ISP設備などに単一障害点が残る可能性があるため
- BGPは3回線以上でしか使えないため
- 2回線ではNATを利用できないため
解答を見る
回線数だけではなく、 ルーター、FW、ISP、引き込み経路など、 システム全体の単一障害点を確認する必要があります。
問題2．自社からインターネットへ出ていくBGP経路を 優先させる代表的な属性はどれですか。
- LOCAL_PREF
- TTL
- VLAN ID
- TCP Window Size
解答を見る
LOCAL_PREFは自AS内で、 どの出口を優先するかを決めるために利用できます。
問題3．AS_PATH Prependingの主な目的として適切なものはどれですか。
- LAN内のSTP経路を変更する
- 外部ASから自社へ入ってくる経路へ影響を与える
- NAT変換速度を高速化する
- BGPセッションを暗号化する
解答を見る
バックアップ側のAS_PATHを長く見せることで、 外部からのInbound経路へ影響を与える方法です。 ただし、必ず意図した経路になるとは限りません。
問題4．自社ルーターとISPルーター間のInterfaceがUpでも、 インターネット通信できないことはありますか。
解答を見る
ISP内部やその先で障害が発生している場合、 自社側の物理リンクはUpでも インターネットへ到達できない場合があります。
問題5．主回線1Gbps、バックアップ回線100Mbpsの構成で、 設計時に特に確認すべきことは何ですか。
解答を見る
障害時の通信量を100Mbpsのバックアップ回線で収容できるか を確認します。
必要に応じて、障害時に利用できるアプリケーションを制限するなどの 運用も検討します。
実践演習：企業の冗長インターネット接続を設計する
あなたは、 500名規模の企業のインターネット接続更改を担当しています。
顧客要件
- 現在はISP-Aの1Gbps回線1本
- Microsoft 365やクラウドサービスを業務で利用
- Web会議を常時利用
- インターネット停止時はほぼ全社員へ影響
- 回線障害時も自動で通信を継続したい
- 復旧まで数分待つのは難しい
- 公開Webサーバーはない
- 現在BGPは利用していない
- 運用担当者のBGP経験は少ない
- コストは必要以上に増やしたくない
課題1．障害シナリオを洗い出す
この企業で考慮すべき障害を5つ以上挙げてください。
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
4．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
5．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
- アクセス回線断
- 回線終端装置故障
- インターネットルーター故障
- ファイアウォール故障
- ISP設備障害
- ISP内部の上流障害
- 建物引き込み経路の断線
課題2．構成案を比較する
次の3案を比較してください。
| 案 | 構成 |
|---|---|
| A | ISP-A 1回線のまま |
| B | ISP-A＋ISP-B、Primary／Backup、デフォルトルート切り替え |
| C | ISP-A＋ISP-B、フルルート受信のBGPマルチホーミング |
理由：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
推奨案例：B
顧客はインターネット停止の影響が大きいため、 異なるISPへの冗長化は有効です。
一方、公開サービスがなく、 運用担当者のBGP経験も少ないため、 最初からフルルートを受ける高度なBGP構成は 必ずしも必要とは限りません。
要件を満たせるのであれば、 Primary／Backup方式と適切な死活監視による シンプルな構成を第一候補として比較します。
課題3．監視対象を決める
主回線の障害を検知するために、 何を監視すべきか考えてください。
解答例を見る
- インターフェース状態
- ISP側Next-Hopへの到達性
- BGPを利用する場合はBGPセッション状態
- 必要に応じてISP上流や外部宛先への到達性
- 経路表に必要なDefault Routeが存在するか
1種類だけに依存せず、 要件に応じて複数の情報から判断します。
課題4．切り替え試験を作る
本番導入前に実施する試験項目を考えてください。
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
4．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
5．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
- 正常時に主回線を使用していること
- 主回線断でバックアップへ自動切り替えすること
- 切り替え時間が要件以内であること
- 切り替え後に主要クラウド・Webサービスへ接続できること
- 主回線復旧後に想定どおりFailbackすること
- 障害・復旧時に監視通知が発生すること
- NAT後の送信元IPが想定どおりであること
課題5．簡易設計表を作る
| 項目 | 設計内容 |
|---|---|
| 主回線 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
| 副回線 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
| 正常時の経路 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
| 障害検知 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
| 切り替え条件 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
| 許容切り替え時間 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
| 復旧時動作 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
| 監視 | ＿＿＿＿＿＿＿＿＿＿＿＿ |
自分の言葉で説明する課題
顧客から次のように質問されました。
「インターネット回線を2本にするだけではダメなんですか？」
説明例を見る
回線を2本にすると回線断への対策にはなりますが、 2本が同じ通信事業者や同じ物理経路を利用している場合、 共通部分の障害で両方とも停止する可能性があります。
また、ルーターやファイアウォールが1台しかなければ、 その機器が単一障害点になります。
そのため、必要な可用性に応じて 回線、ISP、機器、物理経路、障害検知まで含めて 冗長化範囲を決める必要があります。
まとめ
- 冗長インターネット接続とは、 一部障害時にも別経路でInternet通信を継続するための設計
- 2回線にするだけでなく、 ISP、エッジルーター、FW、物理経路などの 単一障害点を確認する
- 同一ISP 2回線と異なる2ISPでは、 耐えられる障害範囲が異なる
- BGPは冗長化で必須ではなく、 必要な経路制御レベルに応じて採用する
- OutboundとInboundは分けて考え、 LOCAL_PREF、AS_PATH、MED、Communityなどを使い分ける
- Interface Downだけではなく、 ISP内部やInternetへの到達性障害も検討する
- NATやPublic IPが変わる場合、 既存セッションや公開サービスへ影響することがある
- バックアップ回線は、 障害時の通信量を収容できる帯域か確認する
- 設計後は必ず回線断、機器障害、復旧を含む フェイルオーバー試験を実施する
冗長化設計で重要なのは、 「2系統あるか」ではなく 「想定した障害が発生したとき、本当に業務を継続できるか」です。
上級編では、要件定義から基本設計、 BGP、クラウド、セキュリティ、自動化、 設計レビュー・顧客提案までを順番に学びます。
コメント