ExpressRouteの設計のポイント

はじめに

こんにちは。株式会社プログライブ コンサルティングの酒見（さけみ）です。

今回は、ExpressRouteで障害が発生する可能性のあるポイントとその対応策の内容を踏まえつつ、ExpressRouteの設計のポイントについて解説します。

ExpressRoute接続パートナーによる設計のポイントの違い

ExpressRouteは、Azureとユーザーのオンプレミス ネットワークの間を接続するサービスですが、ほとんどの場合ではExpressRoute接続パートナーを介して接続されます。

設計が必要な項目については、ExpressRoute接続パートナーによって大きく異なるのですが、ここでは一番シンプルなATBeXのサービスを利用した場合を最初に説明します。

そのほかのExpressRoute接続パートナーを利用する場合でも、設計の項目が増減することがありますが、基本的な内容を踏まえておけば他のパターンでも対応が可能ですね。

基本的な設計項目

Azure portal上でPrivate Peeringのために設定が必要な内容は、以下のとおりです。

• ASN（AS 番号）
• オンプレミス機器とAzure機器間を接続するネットワークのためのサブネット（/30を2つ）
• VLAN ID
• 共有キー（必須ではない）

ASNは、Azure portal上で設定する値としては接続パートナーが指定する場合や、ユーザーがプライベートASのために利用できる64512～65534の範囲から選択する場合があります。

オンプレミス機器とのネットワークに利用する2つの/30のサブネットに関しては、他のネットワークで利用していないネットワークアドレスを選択することが推奨されます。

厳密にはBGPで交換される経路に含まれないためあまり大きな影響はありませんが、トラブルシューティングの観点からも他のネットワークアドレスと重複しないことが望ましいです。

VLAN IDについてもASN同様、接続パートナーが指定する場合や、ユーザーが指定する場合があります。

なお、2つの/30のサブネットは同じVLAN IDで接続することになるため、ユーザー側でスタックしたL3スイッチなどで接続する場合には設計上の考慮点が発生します。

このVLAN IDは仕様上、異なる値にすることはできません。

共有キーは、/30のネットワーク上で利用可能なIPアドレスが2つしかないこと、また閉じた接続となっているためIPアドレスの詐称などのリスクも低いケースが多いため、あまり設定することはありません。

何らかの理由で設定が必要な場合には、オンプレミス機器との間で同じ値を設定する必要があります。

ExpressRouteの物理的な設計項目

やや順序が前後しますが、ExpressRouteの物理的な観点についても設計が必要です。

Azure portal上では "ExpressRoute 回線" というリソース自体を作成する際の設計項目となります。

• サブスクリプション
• リソース グループ
• 回復性
• リージョン
• 回線名
• ポートの種類
• ピアリングの場所
• プロバイダー
• 帯域幅
• SKU
• 課金モデル

サブスクリプションやリソース グループ、回線名については一般的な内容のためここでは割愛します。

回復性は、比較的最近出てきた項目ではありますが、複数のExpressRoute回線を利用した冗長化の構成などが提示されます。

リージョンは、ExpressRoute回線として重要なのはロケーション（場所）なため厳密には異なってもいいのですが、tokyo/tokyo2/tokyo3などを選ぶ場合は東日本（Japan East）などを選べば問題ありません。

ポートの種類は、ほとんどのケースではプロバイダーを選択しますが、10Gbpsを超えるような帯域幅が必要な場合や、より高いレベルのセキュリティが求められる場合は直接（ExpressRoute Direct）を選択することもあります。

ピアリングの場所は、利用するExpressRoute接続パートナーが対応している場所を選択します。

日本には、東日本にtokyo/tokyo2/tokyo3という3か所、西日本にはosakaという1か所がありますが、ExpressRoute 接続パートナーとピアリングの場所にあるとおり、それぞれの場所に対応しているプロバイダーが異なります。

ATBeXサービスを提供しているアット東京の場合、現時点ではtokyo2とosakaに対応しています。

帯域幅は必要な容量を見積もる必要がありますが、増速（帯域幅の増加）が可能なため、ある程度スモールスタートという形で始めても問題ありません。

まれなケースとしては、ExpressRoute接続パートナーの都合で帯域幅を変更できない場合はあります。

その場合は、ExpressRoute 回線を切り替えるときの考慮事項 (Private Peering 編)に記載したように、新しい回線を追加して古い回線を解約する、という方法が必要です。

SKUは、基本的にはStandard、国をまたぐ接続が必要な場合にはPremium、逆に接続が必要なリージョンが限定されている場合にはローカル（ExpressRoute Local）も選択が可能です。

詳細については、ExpressRoute の FAQをご確認ください。

最後に課金モデルですが、ExpressRoute上で24時間通信し続けるようなケースでなければ、従量課金モデルを選択することが一般的です。

まとめ

ExpressRouteに関して、物理的・論理的の2つの設計項目について簡単に解説しました。

項目自体は多いように思いますが、利用するExpressRoute接続パートナーが決まっていればあまり悩むポイントも多くはありません。

この記事では1つのExpressRoute回線のPrivate Peeringについて説明しましたが、実際のエンタープライズ環境では、東日本・西日本の冗長構成やMicrosoft Peeringとの組合せも検討が必要です。

求められる要件に合わせて、コストとのバランスを見ながら設計を進めていく、その際にこの記事が参考になれば幸いです。

この記事を書いた人　プログライブ コンサルティング 酒見

同じカテゴリーの記事