ExpressRoute 接続をトラブルシューティングする

  • 8 分

ExpressRoute では、インターネット経由で直接接続する場合と比較して、Azure への高速な接続を提供するため、プライベート光ファイバー接続を介して動作します。 このユニットでは、ExpressRoute 接続で発生する可能性のある問題のトラブルシューティング方法について説明します。

お使いのネットワーク (顧客ネットワーク) と Azure (Microsoft Datacenter) 間の接続を次の図に示しています。

Screenshot showing connectivity between your network (Customer network) and Azure (Microsoft Datacenter).

ExpressRoute を使用するには、アクティブな Microsoft Azure アカウントが必要です。

Microsoft 365 サービスにも接続する場合は、少なくとも 1 つの Microsoft 365 アカウントが必要です。 ただし、Microsoft 365 はインターネット経由での接続に最適化されているため、特定の場合にのみお勧めします。

また、サービス プロバイダーと連携してプライベート接続を管理する必要があります。

サブスクリプションは必須です Microsoft Azure のみ Microsoft Azure と Microsoft 365
Microsoft Azure アカウント 推奨 推奨
Microsoft 365 非推奨 推奨

ゲートウェイと SKU

ExpressRoute では、仮想ゲートウェイを使用して、Azure 仮想ネットワークがオンプレミス ネットワークに接続されます。

仮想ネットワーク ゲートウェイは、ゲートウェイ サブネットにデプロイされた、2 台以上の VM です。 ゲートウェイ VM には、ルーティング テーブルが含まれ、特定のゲートウェイ サービスが実行されます。

ゲートウェイには、VPN と ExpressRoute の 2 種類があります。 VPN ゲートウェイでは、暗号化されたトラフィックがインターネット経由で送信されます。 ExpressRoute ゲートウェイでは、暗号化されていないプライベート接続を介してトラフィックが送信されます。 ゲートウェイを構成するときは、種類を ExpressRoute に指定する必要があります。

各仮想ネットワークには、種類ごとに 1 つのゲートウェイを割り当てることができます。そのため、次のように構成できます。

  • VPN トラフィック用の仮想ネットワーク ゲートウェイ: VPN 型。

  • ExpressRoute トラフィック用の仮想ネットワーク ゲートウェイ: ExpressRoute 型。

使用するゲートウェイ SKU を構成することもできます。 SKU は、ゲートウェイに割り当てられる帯域幅を指します。 ゲートウェイ SKU が高いほど、CPU とネットワーク帯域幅のスループットが向上します。 ExpressRoute ゲートウェイでは、次の SKU がサポートされています。

  • Standard

  • HighPerformance

  • UltraPerformance

  • ErGw1Az

  • ErGw2Az

  • ErGw3Az

ゲートウェイ SKU をアップグレードするには、次の PowerShell コマンドレットを使用できます。

Resize-AzVirtualNetworkGateway

または、Azure portal 仮想ネットワーク ゲートウェイの構成ウィンドウで構成を変更します。 次のアップグレードがサポートされています。

  • Standard から High Performance

  • Standard から Ultra Performance

  • High Performance から Ultra Performance

  • ErGw1Az から ErGw2Az

  • ErGw1Az から ErGw3Az

  • ErGw2Az から ErGw3Az

  • 既定値から Standard

次のダウングレードがサポートされています。

  • High Performance から Standard

  • ErGw2Az から ErGw1Az

必要なアップグレードまたはダウングレードがサポートされていない場合は、ゲートウェイを削除して再作成します。

ExpressRoute ゲートウェイを作成する前に、サブネットの IP アドレスを含むゲートウェイ サブネットを確立する必要があります。

Azure portal で、仮想ネットワークを選択し、[サブネット] を選択して、[ゲートウェイ サブネットの作成] を選択します。 ゲートウェイ サブネットの IP アドレス範囲を構成する場合、ExpressRoute ゲートウェイと VPN ゲートウェイが共存する構成には、大規模なゲートウェイ サブネットが必要になります。 また、ゲートウェイ サブネットに、将来の追加構成を含めるのに十分な IP アドレスが用意されていることも確認する必要があります。 Microsoft では、/27 またはより大きい (/27、/26 などの) ゲートウェイ サブネットをお勧めしています。

  • ゲートウェイ サブネットは、ExpressRoute でのみ使用されます。 ゲートウェイ サブネットには何も割り当てないでください。

  • GatewaySubnet という名前にする必要があります。

  • 0.0.0.0/0 が宛先のユーザー定義のルートはサポートされていません。

  • GatewaySubnet の NSG はサポートされていません。

  • [BGP ルートの伝達] を [有効] に設定します。 これが [無効] に設定されていると、ゲートウェイは機能しません。

仮想ネットワーク ゲートウェイを作成すると、ゲートウェイ VM はゲートウェイ サブネットにデプロイされ、必要な ExpressRoute ゲートウェイ設定で構成されます。

Note

ゲートウェイが作成され、使用できる状態になるまでに最大 45 分かかる場合があります。

ExpressRoute 回線が動作しているかどうかを判断する

Azure portal で、左側のメニューから [すべてのサービス]>[ネットワーク]>[ExpressRoute 回線] を選択して、既存の ExpressRoute 回線を表示します。

Screenshot of Expressroute circuits settings.

サブスクリプション内で作成されたすべての ExpressRoute 回線がここに表示されます。

Screenshot of Expressroute circuits list.

回線を動作させるには、サービス プロバイダーにサービス キーを送信する必要があります。 各サービス キーは 1 つの回線に固有です。 関連する回線を選択し、[概要] ページでプロバイダーのサービス キー フィールドを見つけます。

Screenshot of service key field.

[プロバイダーの状態] には、サービス プロバイダー側でのプロビジョニングの状態が表示されます。

[回線の状態] には、Microsoft 側でのプロビジョニングの状態が表示されます。

新しい ExpressRoute 回線を作成する場合、この回線は次の状態になります。

[プロバイダーの状態]: [未プロビジョニング] [回線の状態]: [有効]

サービス プロバイダーがプロビジョニングするときに回線が変更されます。

[プロバイダーの状態]: [プロビジョニング中] [回線の状態]: [有効]

ExpressRoute 回線は、次の状態の場合に動作します。

[プロバイダーの状態]: [プロビジョニング済み] [回線の状態]: [有効]

Azure PowerShell コマンドレットを使用して、プロビジョニングの状態を確認することもできます。

Get-AzExpressRouteCircuit -ResourceGroupName "Test-Resource" -Name "Test-Circuit"

出力には、回線のプロビジョニングの状態とサービス プロバイダーのプロビジョニングの状態の両方が表示されます。

[回線の状態] が [無効] でスタックしている場合は、Microsoft サポートにお問い合わせください。

[プロバイダーの状態] が [未プロビジョニング] でスタックしている場合は、お使いのサービス プロバイダーにお問い合わせください。

回線のピアリング構成を検証する

各 ExpressRoute 回線には、Azure プライベート ピアリングと Microsoft ピアリングを含めることができます。 Azure プライベート ピアリングは、Azure 内のプライベート仮想ネットワークへのトラフィックです。 Microsoft ピアリングは、PaaS と SaaS のパブリック エンドポイントへのトラフィックです。

ピアリングは、サービス プロバイダーによって構成されます。 ポータルのピアリングがまだ空白の場合は、更新を使用して回線から現在のルーティング構成をプルしてみてください。

ExpressRoute 回線ピアリングの状態は、Azure portal にある ExpressRoute 回線の [概要] ページで確認できます。 ExpressRoute ピアリングは、[ピアリング] セクションの下に表示されます。

Screenshot of Expressroute peerings.

上のスクリーンショットでは、Azure プライベート ピアリングはプロビジョニングされていますが、Azure パブリックと Microsoft のピアリングはされていません。 正常にプロビジョニングされたピアリングでは、プライマリとセカンダリのポイント ツー ポイントのサブネットも表示されます。

ピアリングの有効化が失敗する場合は、割り当てられたプライマリ サブネットとセカンダリ サブネットが、リンクされた CE/PE-MSEE 上の構成と一致するかどうかを確認してください。 また、MSEE で適切な VlanId、AzureASN、PeerASN が使用されているかどうかと、リンクされた CE/PE-MSEE で使用されている値に、これらの値が対応しているかどうかを確認してください。 MD5 ハッシュが選択されている場合は、MSEE と PE-MSEE/CE のペアで共有キーは同じものにする必要があります。 セキュリティ上の理由から、以前に構成した共有キーは表示されません。

Note

[ピアリングの場所] は、Microsoft とピアリングしている物理的な場所を示します。 [場所] プロパティは、Azure ネットワーク リソース プロバイダーが配置されている場所を示します。 回線のピアリングの場所と地理的に近いネットワーク リソース プロバイダーを選択することをお勧めします。

Microsoft Enterprise Edge (MSEE) デバイスで送受信されるパケットをカウントして、プライベート ピアリング接続をテストすることもできます。 このツールでは、次のような質問に答えて接続を確認できます。

  • パケットは Azure に到達しているか

  • 自分のオンプレミス ネットワークに戻っていますか?

Azure portal からこの診断ツールにアクセスするには、ExpressRoute 回線を選択し、[問題の診断と解決] を選択します。

ルートがライブで正しく構成されていることを確認する

ピアリング接続をテストすれば、ルートがライブであり、正しく構成されていることを検証できます。 Microsoft Enterprise Edge (MSEE) デバイスの ExpressRoute 回線のエッジで送受信されるパケットをカウントします。 この診断ツールは、アクセス制御リスト (ACL) を MSEE に適用して、特定の ACL 規則にヒットしたパケットの数をカウントすることで機能します。 このツールを使用すると、接続が期待どおりに動作していることを確認できます。

  1. この診断ツールにアクセスするには、Azure portal で ExpressRoute 回線から [問題の診断と解決] を選択します。

    Screenshot showing the diagnose and solve problems from the ExpressRoute circuit in the Azure portal.

  2. [一般的な問題] の下で [接続の問題] を選択します。

    Screenshot of connectivity issues.

  3. [発生している問題の詳細をお知らせください] のドロップダウンで、[Azure プライベート、Azure パブリック、または Dynamics 365 サービスへの接続] を選択します。

    Screenshot showing connection to Azure Private, Azure Public, or Dynamics 365 services.

  4. [プライベート ピアリング接続をテストする] セクションまで下にスクロールして、展開します。

    Screenshot showing Testing of private peering connectivity.

  5. オンプレミスの IP アドレスから Azure の IP アドレスへの PsPing テストを実行し、接続テストの間、その実行を継続します。

  6. フォームのフィールドに入力します。以前使用したものと同じオンプレミスと Azure の IP アドレスを入力するようにしてください。 [送信] を選択し、結果を待ちます。 結果の準備ができたら、情報を確認して以下で解釈します。

    Screenshot of connectivity test.

    プライマリおよびセカンダリの MSEE デバイスについて 2 セットの結果が提供されます。 送受信の一致の数を確認し、次のシナリオを使用して結果を解釈します。

    • 両方の MSEE で送受信されたパケットの一致が表示される: これは、回線上の MSEE 間の正常な受信および送信トラフィックを示しています。 オンプレミスまたは Azure 内のいずれかで損失が発生している場合は、MSEE からのダウンストリームで発生しています。

    • オンプレミスから Azure への PsPing のテスト (受信) 結果には一致が表示されるが、送信結果には一致なしと表示される場合: これは、トラフィックが Azure で受信されているが、オンプレミスに戻ってきていないことを示しています。 リターン パスのルーティングの問題を確認します。 適切なプレフィックスを Azure に公開しているかどうかを確認します。 UDR オーバーライド プレフィックスがあるかどうかを確認します。

    • Azure からオンプレミスへの PsPing のテスト (送信) 結果には一致なしと表示されるが、受信結果には一致が表示される場合: これは、トラフィックがオンプレミスに到達しているが、戻ってきていないことを示しています。 ExpressRoute 回線経由でトラフィックが Azure にルーティングされていない理由については、プロバイダーと協力する必要があります。

    • 一方の MSEE では一致なしと表示されるのに対して、他方では適切な一致が表示される: これは、1 つの MSEE でトラフィックの受信や引き渡しが行われていないことを示しています。 BGP/ARP がダウンしているなど、オフラインかどうかを確認します。

例:

src 10.0.0.0 dst 20.0.0.0 dstport 3389 (received): 120 matches
src 20.0.0.0 srcport 3389 dst 10.0.0.0 (sent): 120 matches

このテスト結果には、次のプロパティがあります。

  • IP ポート: 3389

  • オンプレミスの IP アドレス CIDR: 10.0.0.0

  • Azure の IP アドレス CIDR: 20.0.0.0

ExpressRoute 回線をリセットする

ExpressRoute 回線での操作が正常に完了しないと、回線が "障害" 状態になることがあります。 障害が発生した ExpressRoute 回線は、Azure PowerShell を使用してリセットできます。 Azure Resource Manager PowerShell コマンドレットの最新版をインストールする必要があります。

  1. 昇格された特権で PowerShell コンソールを開き、アカウントに接続します。 接続については、次の例を参考にしてください。

    Connect-AzAccount

  2. 複数の Azure サブスクリプションを所有している場合には、アカウントのサブスクリプションをすべて確認します。

    Get-AzSubscription

  3. 使用するサブスクリプションを指定します。

    Select-AzSubscription -SubscriptionName "Replace_with_your_subscription_name"

  4. 次のコマンドを実行して、障害状態の回線をリセットします。

    $ckt = Get-AzExpressRouteCircuit -Name "ExpressRouteARMCircuit" -ResourceGroupName "ExpressRouteResourceGroup"

Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

回線はすぐにリセットされます。

非対称ルーティングに関する問題のトラブルシューティング

非対称ルーティングでは、戻りのネットワーク トラフィックは元の送信フローとは異なるパスを経由します。 たとえば、インターネット パスと、同じ宛先に向かうプライベート パスがある場合です。 また、同じ宛先に複数のプライベート パスが接続されている場合にも発生します。

traceroute は、ネットワーク トラフィックが予想されるパスを経由していることを確認するうえで、最善の手段です。

Azure ExpressRoute を介して接続する際は、Microsoft への複数のリンクがあります。 既存のインターネット接続と ExpressRoute 接続があります。 Microsoft 宛てのトラフィックは、インターネット接続を通過しますが、ExpressRoute 接続で返されることがあります。 または、トラフィックが ExpressRoute を通過し、インターネット パス経由で返される可能性があります。

ExpressRoute 回線からより具体的な IP アドレスを受信します。 そのため、ExpressRoute 経由で提供されるサービスに対してネットワークからのトラフィックが Microsoft に送信される場合、トラフィックは ExpressRoute 接続にルーティングされます。

非対称ルーティングを解決するには 2 つのオプションがあります。ルーティングを使用するか、ソース ベースの NAT (SNAT) を使用するかです。

ルーティング オプションを使用する場合、パブリック IP アドレスを適切なワイド エリア ネットワーク (WAN) リンクに公開します。 たとえば、認証トラフィックにはインターネット、電子メール トラフィックには ExpressRoute を使用する場合は、Active Directory フェデレーション サービス (AD FS) パブリック IP アドレスを ExpressRoute 経由で公開しないよう求められます。 同様に、ルーターが ExpressRoute 経由で受信する IP アドレスに、オンプレミスの AD FS サーバーを公開しないようにしてください。 ExpressRoute 経由で受け取ったルートはより具体的であるため、Microsoft への認証トラフィックのパスとして ExpressRoute が優先されます。

ExpressRoute を認証に使用する場合は、NAT を使用せずに ExpressRoute 経由で AD FS パブリック IP アドレスを公開してください。 これにより、ExpressRoute 経由で Microsoft から送信されたトラフィックがオンプレミスの AD FS サーバーに送信されます。 ネットワークから Microsoft に戻るトラフィックには ExpressRoute が使用されます。これは、ExpressRoute がインターネットより優先されるルートであるためです。

または、SNAT を使用して非対称ルーティングを防止します。 たとえば、SMTP トラフィックをインターネット経由で送信する場合は、ExpressRoute 経由でオンプレミス SMTP サーバーのパブリック IP アドレスを公開しないでください。

Microsoft からオンプレミスの SMTP サーバーに送信される要求はインターネットを経由します。 SNAT を使用して受信要求を内部 IP アドレスに変換します。 SMTP サーバーからの戻りトラフィックは、ExpressRoute を経由せず、(NAT に使用する) エッジ ファイアウォールに届くことで、戻りトラフィックがインターネット パスを経由するよう保証されます。

ルート フィルター処理のトラブルシューティング

ExpressRoute 回線にピアリングを構成するとき、エッジ ルーターでは、接続プロバイダーを介してエッジ ルーターとの間に一対の Border Gateway Protocol (BGP) セッションが確立されます。 この時点で、お使いのネットワークに公開されるルートはありません。 ネットワークに対するルートの公開を有効にするには、ルート フィルターを構成する必要があります。

ルート フィルターによって利用するサービスが識別されます。 これは、許可されている BGP コミュニティ値のリストです。 ルート フィルター リソースを定義して ExpressRoute 回線にアタッチすると、BGP コミュニティ値にマッピングされたすべてのプレフィックスがお使いのネットワークに公開されます。

ルート フィルターを Microsoft 365 サービスにアタッチするには、ExpressRoute 経由で Microsoft 365 サービスを使用する認可が必要です。 この認可がない場合、操作は失敗します。

Microsoft ピアリング経由でアクセスできるサービスに関連付けられた BGP コミュニティ値は、「ExpressRoute のルーティングの要件」で確認できます。

ルート フィルターに割り当てることができるルールは 1 つだけで、許可タイプであることが必要です。 ルールに関連付けられている BGP コミュニティ値のリストを関連付けることができます。

フィルター ルールを作成する

  • ルールを追加および更新するには、ルート フィルターの [ルールの管理] タブを選択します。

    Screenshot of Manage rule tab.

  • ドロップダウン リストから、接続する許可されたサービス コミュニティを選択します。 完了したら、ルールを保存します。

Screenshot of Rule settings.

冗長構成のトラブルシューティング

各 ExpressRoute 回線にはクロス接続の冗長ペアが設定され、高可用性を実現しています。 いずれかのクロス接続が失敗しても、接続は失われません。 冗長接続は、接続性と高可用性を実現します。

各 Azure VPN ゲートウェイは 2 つのインスタンスで構成され、どちらもアクティブ/スタンバイ状態です。 アクティブなインスタンスに対してメンテナンスまたは計画外の中断が発生すると、スタンバイ インスタンスによって自動的に引き継ぎ (フェールオーバー) が行われます。

ルート更新プログラムのトラブルシューティング

ネットワーク ルーティングは、ネットワーク トラフィックが宛先に到達するためのパスを決定する方法です。 ルート テーブルは、ネットワーク トポロジ情報を一覧表示してルーティング パスを決定するために使用されます。 お使いの仮想ネットワークにネットワーク仮想アプライアンス (NVA) が含まれている場合、ルート テーブルを手動で構成して更新する必要があります。

Azure Route Server を使用すると、仮想ネットワークで NVA を構成、維持、デプロイできます。 また、Route Server では、仮想ネットワーク アドレス情報が最新の状態に保たれます。 Route Server により、ルート テーブルを維持するための管理オーバーヘッドがなくなります。

または、Azure の既定のルートをオーバーライドする静的ルートを定義することもできます。 または、サブネットのルート テーブルにルートを追加することもできます。 カスタム ルートを作成するには、ユーザー定義ルートを作成するか、オンプレミス ネットワーク ゲートウェイと Azure 仮想ネットワーク ゲートウェイの間で Border Gateway Protocol (BGP) ルートを交換します。

ルート更新プログラムのトラブルシューティングを行うには、以下を試してください。

  • トラフィックをルーティングするルート テーブルと同じサブネットに仮想アプライアンスをデプロイしないでください。 これにより、ルーティング ループが発生する可能性があります。つまり、トラフィックがサブネットから出ることは決してありません。

  • ネクスト ホップのプライベート IP アドレスは、ExpressRoute ゲートウェイまたは Virtual WAN 経由でルーティングせず、直接接続する必要があります。 直接接続せずにネクスト ホップを IP アドレスに設定すると、ユーザー定義のルーティング構成が無効になります。

ExpressRoute 待機時間の問題の根本原因を特定する

ExpressRoute に関する待機時間の問題をトラブルシューティングするために、Azure Connectivity Toolkit には iPerf というツールが含まれています。

ホスト上のディレクトリにファイルをコピーすることで、基本的なパフォーマンス テストに iPerf を使用します。 パフォーマンスをテストするには、次のステップに従います。

  1. PowerShell モジュールをインストールします。

    (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression

    このコマンドは、PowerShell モジュールをダウンロードしてローカルにインストールします。

  2. 関連アプリケーションをインストールします。

    Install-LinkPerformance

    AzureCT のこのコマンドにより、iPerf と PSPing が新しいディレクトリ "C:\ACTTools" にインストールされます。 また、Windows ファイアウォールのポートが開き、ICMP とポート 5201 (iPerf) のトラフィックが許可されます。

  3. パフォーマンス テストを実行します。

    まず、リモート ホストに iPerf をインストールし、サーバー モードで実行する必要があります。 リモート ホストは 3389 (Windows の RDP) または 22 (Linux の SSH) のいずれかでリッスンし、iPerf 用のポート 5201 でトラフィックが許可されていることを確認します。 リモート ホストが Windows の場合は、AzureCT をインストールし、Install LinkPerformance コマンドを実行します。 コマンドでは、iPerf と必要なファイアウォール規則が設定されます。

    リモート マシンの準備ができたら、ローカル コンピューターで PowerShell を開き、テストを開始します。

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10

    このコマンドにより、負荷と待機時間に関する一連のテストが同時に実行されます。これらのテストは、ネットワーク リンクの帯域幅容量と待機時間の評価に役立ちます。

  4. テストの出力を確認します。

iPerf テストの詳細な結果は、AzureCT ツールのディレクトリ (C:\ACTTools) 内の、個々のテキスト ファイルで確認できます。

PowerShell の出力形式は次のようになります。

Screenshot of PowerShell output of test.

パフォーマンス テストで期待した結果が得られない場合は、ステップ バイ ステップ プロセスを使用して問題を解決します。

まず、想定を見直します。 1 Gbps の ExpressRoute 回線と 100 ミリ秒の待機時間がある場合、待機時間が長いリンクでの TCP の特性を考慮すると、1 Gbps の完全なトラフィックを期待するのは妥当ではありません。

次に、ルーティング ドメイン間のエッジの部分から始めて、1 つの主要なルーティング ドメインに問題を絞り込んでください。 企業ネットワーク、WAN、または Azure ネットワークから開始できます。 これはユーザーによって制御できないので、サービス プロバイダーまたは ISP に連絡する妥当な原因があることを確認してください。 ユーザーの制御下にある修正が遅れる可能性があります。

問題が含まれるとみられる主要なルーティング ドメインを特定したら、図を作成します。 図に領域を表示すると、テストするポイントを計画して体系的に作業できます。 ネットワークをセグメントに分割して問題を絞り込み、結果が得られたら図を更新します。

また、OSI モデルの他の層も忘れずに確認します。 ネットワークと 1-3 層 (物理、データ、およびネットワーク) に的を絞りがちですが、アプリケーション層の 7 層にも問題が見つかる場合があります。 先入観を抱かずに、想定を確認します。

Note

エンドポイント間の地理的な待機時間は、待機時間の最大の要素です。 物理および仮想コンポーネント、ホップ数などの機器の待機時間が関係します。 しかし、WAN 接続を処理する際の全体的な待機時間に大きな影響を与える地理情報が示されています。 ファイバー実行の距離は、直線距離や道路地図上の距離ではないことに注意してください。 市距離計算ツールの使用は不正確ですが、十分です。