ExpressRoute 接続を確認する
この記事は、Azure ExpressRoute 接続の確認とトラブルシューティングに役立ちます。 ExpressRoute は、接続プロバイダーが一般的に提供するプライベート接続を介して、オンプレミス ネットワークを Microsoft クラウドへと拡張します。 ExpressRoute 接続には従来、3 つの異なるネットワーク ゾーンが含まれます。
- カスタマー ネットワーク
- プロバイダーのネットワーク
- Microsoft のデータセンター
Note
ExpressRoute Direct の接続モデルでは、顧客は Microsoft Enterprise Edge (MSEE) ルーターのポートに直接接続できます。 直接接続モデルには、お客様のネットワークと Microsoft のネットワーク ゾーンのみが含まれます。
この記事は、接続の問題が存在するかどうか、またどこに問題があるかを特定するのに役立ちます。 その後、適切なチームにサポートを求め、問題を解決することができます。
重要
単純な問題の診断と解決を支援することが、この記事の目的です。 Microsoft サポートに代わるものではありません。 この記事のガイダンスを使用して問題を解決できない場合は、Microsoft サポートでサポート チケットを開きます。
概要
次の図は、ExpressRoute を使用した顧客のネットワークから Microsoft ネットワークへの論理的な接続を示します。
上の図の中の番号は、重要なネットワーク ポイントを示しています。
- 顧客のコンピューティング デバイス (例: サーバーや PC)。
- 顧客のエッジ ルーター (CE)。
- 顧客のエッジ ルーターに接続している、プロバイダーのエッジ ルーターまたはスイッチ (PE)。
- Microsoft Enterprise Edge ExpressRoute ルーター (MSEE) に接続している PE。 この記事では、これを PE-MSEEと呼びます。
- MSEE。
- 仮想ネットワーク ゲートウェイ
- Azure 仮想ネットワーク上のコンピューティングデバイス。
この記事では、これらのネットワーク ポイントを関連付けられた番号で参照することがあります。
ExpressRoute 接続モデルによっては、ネットワーク ポイント 3 と 4 がスイッチ（レイヤー 2 デバイス）またはルーター（レイヤー 3 デバイス）になる場合があります。 ExpressRoute 接続モデルは、クラウド交換コロケーション、ポイント ツー ポイントの イーサネット接続、または Any-to-Any (IPVPN) です。
直接接続モデルでは、ネットワーク ポイント 3 と 4 は存在しません。 代わりに、CE (2) は、ダーク ファイバー経由で MSEE に直接接続されます。
クラウド交換コロケーション、ポイント ツー ポイントのイーサネット、または直接接続のモデルが使用されている場合は、CE (2) が MSEE (5) との Border Gateway Protocol (BGP) ピアリングを確立します。
Any-to-Any (IPVPN) 接続モデルが使用されている場合は、PE-MSEE (4) が MSEE (5) との BGP ピアリングを確立します。 PE-MSEE により Microsoft から受信したルートが IPVPN サービス プロバイダーのネットワークを介して顧客のネットワークに反映されます。
Note
高可用性を実現するために、Microsoft は MSEE と PE-MSEE のペアの間に完全に冗長なパラレル接続を確立します。 顧客のネットワークと PE/CE ペアの間にも、完全に冗長なパラレル ネットワーク パスが推奨されます。 高可用性に関する詳細については、記事「 ExpressRoute を使用した高可用性のための設計」を参照してください。
以下のセクションは、ExpressRoute 回線のトラブルシューティングの論理的ステップを示します。
回線のプロビジョニングと状態を確認する
ExpressRoute 回線をプロビジョニングすると、CE/PE-MSEE (2/4) と MSEE (5) の間に冗長なレイヤー 2 接続が確立します。 ExpressRoute 回線の作成、変更、プロビジョニング、検証を行う方法の詳細については、「ExpressRoute 回線の作成と変更」を参照してください。
ヒント
サービス キーは ExpressRoute 回線を一意に識別します。 ExpressRoute の問題のトラブルシューティングを行うために Microsoft または ExpressRoute パートナーによるサポートが必要な場合は、回線を簡単に特定できるようにサービス キーを提供してください。
Azure Portal を使用した検証
Azure portal で、[ExpressRoute 回線] ページを開きます。 このページの 
セクションに、次のスクリーンショットのように ExpressRoute の要点が表示されます。
ExpressRoute の [要点] にある [回線の状態] は Microsoft 側の回線の状態を示します。 [Provider status (プロバイダーの状態)] は、サービス プロバイダー側で回線が "プロビジョニング済みまたは未プロビジョニング" かどうかを示します。
ExpressRoute 回線を運用可能にするには、[回線の状態] が [有効]、[Provider status (プロバイダーの状態)] が [プロビジョニング済み]である必要があります。
Note
ExpressRoute 回線を構成した後、[回線の状態] が 非有効 状態のままになる場合は、Microsoft サポートにお問い合わせください。 [プロバイダーの状態] が 未プロビジョニング 状態のままになる場合は、サービス プロバイダーにお問い合わせください。
PowerShell を使用した検証
リソース グループ内のすべての ExpressRoute 回線を一覧表示するには、次のコマンドを使用します。
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"
ヒント
リソース グループの名前を探している場合は、 コマンド Get-AzResourceGroup を使用して、サブスクリプション内のすべてのリソース グループを一覧表示することで取得できます。
リソース グループ内の特定の ExpressRoute 回線を選択するには、次のコマンドを使用します。
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
次は応答の例です。
Name : Test-ER-Ckt
ResourceGroupName : Test-ER-RG
Location : westus2
Id : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt
Etag : W/"################################"
ProvisioningState : Succeeded
Sku : {
"Name": "Standard_UnlimitedData",
"Tier": "Standard",
"Family": "UnlimitedData"
}
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
ServiceProviderNotes :
ServiceProviderProperties : {
"ServiceProviderName": "****",
"PeeringLocation": "******",
"BandwidthInMbps": 100
}
ServiceKey : **************************************
Peerings : []
Authorizations : []
ExpressRoute 回線が運用可能かどうかを確認するには、特に次のフィールドに注目してください。
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Note
ExpressRoute 回線を構成した後、[回線の状態] が非有効状態のままになる場合は、Microsoft サポートにお問い合わせください。 [プロバイダーの状態] が未プロビジョニング状態のままになる場合は、サービス プロバイダーにお問い合わせください。
ピアリング構成を検証する
サービス プロバイダーが ExpressRoute 回線のプロビジョニングを完了すると、CE/MSEE-PE (2/4) と MSEE (5) の間の ExpressRoute 回線で外部 BGP (eBGP) ベースの複数のルーティング構成を作成できます。 各 ExpressRoute 回線では、次のいずれかまたは両方のピアリング構成を設定できます。
- Azure プライベート ピアリング: Azure 内のプライベート仮想ネットワークへのトラフィック
- Microsoft ピアリング: サービスとしてのプラットフォーム (PaaS) とサービスとしてのソフトウェア (SaaS) のパブリック エンドポイントへのトラフィック
ルーティング構成の作成と変更方法の詳細については、「ExpressRoute 回線のルーティングの作成と変更を行う」を参照してください。
Azure Portal を使用した検証
Note
IPVPN 接続モデルでは、サービス プロバイダーがピアリング (レイヤー 3 サービス) を構成する責任を担います。 このようなモデルでは、サービス プロバイダーがピアリングを構成した後、ポータルのピアリングが空の場合、ポータルの更新ボタンを使用して回線の構成を更新します。 この操作により、現在のルーティング構成が回線からプルされます。
Azure portal では、ExpressRoute 回線の状態をその回線のページで確認できます。 このページの セクションに、次のスクリーンショットのように ExpressRoute ピアリングが表示されます。
上の例では、Azure プライベート ピアリングはプロビジョニングされていますが、Azure パブリックと Microsoft のピアリングはプロビジョニングされません。 正常にプロビジョニングされたピアリング コンテキストでは、プライマリとセカンダリのポイント ツー ポイントのサブネットも表示されます。 /30 サブネットは、MSEE と CE/PE-MSEE のインターフェイス IP アドレスに使用されます。 この一覧では、プロビジョニングされているピアリングについて、最後に構成を変更したユーザーも表示されます。
Note
ピアリングの有効化が失敗する場合は、割り当てられたプライマリ サブネットとセカンダリ サブネットが、リンクされた CE/PE-MSEE 上の構成と一致するかどうかを確認してください。 さらに、適切な VlanId, AzureASN, PeerASN の値が MSEE で使用されているかどうかと、これらの値がリンクされた CE/PE-MSEE で使用されている値に対応しているかどうかも確認してください。
MD5 ハッシュが選択されている場合は、MSEE と CE/PE-MSEE のペアで共有キーは同じものにする必要があります。 以前に構成した共有キーは、セキュリティ上の理由で表示されません。
MSEE ルーター上のこれらの構成のいずれかを変更する必要がある場合は、「 ExpressRoute 回線のルーティングの作成と変更を行う」を参照してください。
Note
インターフェイスに割り当てられた /30 サブネットでは、サブネットの 2 番目の使用可能な IP アドレスが MSEE インターフェイス用に選択されます。 そのため、サブネットの最初の使用可能な IP アドレスが、ピアリングされた CE/PE-MSEE で確実に割り当てられているようにします。
PowerShell を使用した検証
Azure プライベート ピアリング構成の詳細を取得するには、次のコマンドを使用します。
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt
正常に構成されたプライベート ピアリングの応答のサンプルは次のとおりです。
Name : AzurePrivatePeering
Id : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt/peerings/AzurePrivatePeering
Etag : W/"################################"
PeeringType : AzurePrivatePeering
AzureASN : 12076
PeerASN : 123##
PrimaryPeerAddressPrefix : 172.16.0.0/30
SecondaryPeerAddressPrefix : 172.16.0.4/30
PrimaryAzurePort :
SecondaryAzurePort :
SharedKey :
VlanId : 200
MicrosoftPeeringConfig : null
ProvisioningState : Succeeded
正常に有効にされたピアリング コンテキストでは、プライマリとセカンダリのアドレス プレフィックスが表示されます。 /30 サブネットは、MSEE と CE/PE-MSEE のインターフェイス IP アドレスに使用されます。
Microsoft ピアリング構成の詳細を取得するには、次のコマンドを使用します。
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt
ピアリングが構成されていない場合は、エラー メッセージが表示されます。 記述されているピアリングが回線内で構成されていない場合の応答のサンプルは次のとおりです。
Get-AzExpressRouteCircuitPeeringConfig : Sequence contains no matching element
At line:1 char:1
+ Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Get-AzExpr...itPeeringConfig], InvalidOperationException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.Network.GetAzureExpressRouteCircuitPeeringConfigCommand
Note
ピアリングの有効化が失敗する場合は、割り当てられたプライマリ サブネットとセカンダリ サブネットが、リンクされた CE/PE-MSEE 上の構成と一致するかどうかを確認してください。 さらに、適切な VlanId, AzureASN, PeerASN の値が MSEE で使用されているかどうかと、これらの値がリンクされた CE/PE-MSEE で使用されている値に対応しているかどうかも確認してください。
MD5 ハッシュが選択されている場合は、MSEE と CE/PE-MSEE のペアで共有キーは同じものにする必要があります。 以前に構成した共有キーは、セキュリティ上の理由で表示されません。
MSEE ルーター上のこれらの構成のいずれかを変更する必要がある場合は、「 ExpressRoute 回線のルーティングの作成と変更を行う」を参照してください。
Note
インターフェイスに割り当てられた /30 サブネットでは、サブネットの 2 番目の使用可能な IP アドレスが MSEE インターフェイス用に選択されます。 そのため、サブネットの最初の使用可能な IP アドレスが、ピアリングされた CE/PE-MSEE で確実に割り当てられているようにします。
ARP を検証する
Address Resolution Protocol (ARP) テーブルから、特定のピアリングに関する IP アドレスと MAC アドレスのマッピングを得ることができます。 ExpressRoute 回線のピアリングで使用される ARP テーブルは、プライマリ インターフェイスとセカンダリ インターフェイスのそれぞれに関して次の情報を提供します。
- オンプレミス ルーター インターフェイスの IP アドレスから MAC アドレスへのマッピング
- ExpressRoute ルーター インターフェイスの IP アドレスから MAC アドレスへのマッピング (省略可能)
- マッピングがキャッシュされてからの経過時間
レイヤー 2 の構成を検証したり、レイヤー 2 の基本的な接続の問題をトラブルシューティングしたりする際に、ARP テーブルを役立てることができます。
Note
ハードウェア プラットフォームによっては、ARP の結果が異なる場合があり、オンプレミス インターフェイスのみが表示されます。
ExpressRoute ピアリングの ARP テーブルの表示方法、およびこの情報を使用してレイヤー 2 の接続に関する問題のトラブルシューティングを行う方法については、「 Resource Manager デプロイ モデルでの ARP テーブルの取得」を参照してください。
MSEE 上の BGP とルートを検証する
プライベート ルーティング コンテキストについて、Primary パスで MSEE からルーティング テーブルを取得するには、次のコマンドを使用します。
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName ******* -PeeringType AzurePrivatePeering -ResourceGroupName ****
次は応答の例です。
Network : 10.1.0.0/16
NextHop : 10.17.17.141
LocPrf :
Weight : 0
Path : 65515
Network : 10.1.0.0/16
NextHop : 10.17.17.140*
LocPrf :
Weight : 0
Path : 65515
Network : 10.2.20.0/25
NextHop : 172.16.0.1
LocPrf :
Weight : 0
Path : 123##
Note
MSEE と CE/PE-MSEE の間の eBGP ピアリングの状態が アクティブ または アイドルの場合は、割り当てられたプライマリ ピアとセカンダリ ピアのサブネットが、リンクされた CE/PE-MSEE 上の構成と一致するかどうかを確認してください。 さらに、適切な VlanId, AzureASN, PeerASN の値が MSEE で使用されているかどうかと、これらの値がリンクされた CE/PE-MSEE で使用されている値に対応しているかどうかも確認してください。 MD5 ハッシュが選択されている場合は、MSEE と CE/PE-MSEE のペアで共有キーは同じものにする必要があります。 MSEE ルーター上のこれらの構成のいずれかを変更する必要がある場合は、「 ExpressRoute 回線のルーティングの作成と変更を行う」を参照してください。
Note
特定の宛先にピアリングを介して到達できない場合は、対応するピアリング コンテキストの MSEE のルーティング テーブルを確認してください。 一致するプレフィックス (NAT された IP の場合があります) がルーティング テーブルに存在する場合は、パス上のファイアウォール、ネットワーク セキュリティ グループ、またはアクセス制御リスト (ACL) がトラフィックをブロックしていないかどうかを確認します。
次の例は、ピアリングに対するコマンドの応答が存在しないことを示します。
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
トラフィック フローを確認する
ピアリング コンテキストのプライマリ パスとセカンダリ パスを組み合わせたトラフィックの統計情報 (入出力バイト数) を取得するには、次のコマンドを使用します。
Get-AzExpressRouteCircuitStats -ResourceGroupName $RG -ExpressRouteCircuitName $CircuitName -PeeringType 'AzurePrivatePeering'
このコマンドの出力例は次のとおりです。
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
存在しないピアリングに対するコマンドの出力例は次のとおりです。
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
プライベート ピアリング接続をテストする
MSEE デバイスで ExpressRoute 回線の Microsoft エッジから送受信されるパケットをカウントして、プライベート ピアリング接続をテストします。 この診断ツールは、アクセス制御リスト (ACL) を MSEE に適用して、特定の ACL 規則にヒットしたパケットの数をカウントすることで機能します。 このツールを使用すると、次のような質問に答えて接続を確認できます。
- パケットは Azure に到達しているか
- オンプレミスに戻ってきているか
テストを実行する
診断ツールにアクセスするには、Azure portal で ExpressRoute 回線から [問題の診断と解決] を選択します。
接続とパフォーマンスの問題を選択します。
発生している問題の詳細を教えてください ドロップダウンリストで、プライベートピアリングの問題 を選択します。
プライベート ピアリング接続をテストする セクションまで下にスクロールして、展開します。
オンプレミスの IP アドレスから Azure の IP アドレスへの PsPing テストを実行し、接続テストの間、その実行を継続します。
フォームのフィールドに入力します。 手順 5 で使用したのと同じオンプレミスと Azure の IP アドレスを入力するようにします。 次に、[送信] を選択し、結果が読み込まれるのを待ちます。
結果を解釈する
結果の準備ができたら、プライマリおよびセカンダリの MSEE デバイスについて 2 セットの結果が提供されます。 送受信の一致の数を確認し、次のシナリオを使用して結果を解釈します。
両方の MSEE で送受信されたパケット一致が表示されます。この結果は、回線上の MSEE 間の正常な受信および送信トラフィックを示しています。 オンプレミスまたは Azure 内のいずれかで損失が発生している場合は、MSEE からのダウンストリームで発生しています。
オンプレミスから Azure への PsPing をテストしている場合、 受信結果には一致が示されるが、送信結果には一致なしと示される場合: この結果は、トラフィックが Azure に到達しているが、オンプレミスに戻っていないことを示しています。 戻りパス ルーティングの問題を確認します。 たとえば、Azure に適したプレフィックスをアドバタイズしているか。 ユーザー定義ルート (UDR) はプレフィックスをオーバーライドしていますか。
Azure からオンプレミスへの PsPing をテストしている場合、送信結果には一致が示されるが、受信結果には一致は表示されない場合: この結果は、トラフィックがオンプレミスに到達しているが、Azure に戻っていないことを示しています。 ExpressRoute 回線経由でトラフィックが Azure にルーティングされていない理由については、プロバイダーと協力して確認します。
一方の MSEE では一致なしと示されるが、他方では適切な一致が示される: この結果は、1 つの MSEE がトラフィックの受信や引き渡しを行っていないことを示しています。 これはオフライン (BGP/ARP がダウンしているなど) である可能性があります。
- このパスで BGP セッションを介して一意の /32 オンプレミス ルートをアドバタイズすることで、異常なパスを確認する追加のテストを実行できます。
- オンプレミスの宛先としてアドバタイズされた一意の /32 を使用して「プライベート ピアリング接続をテストする」を実行し、結果を調べてパスの正常性を確認します。
各 MSEE デバイスのテスト結果は、次の例のようになります。
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 仮想ネットワーク ゲートウェイを使用すると、Azure 仮想ネットワークにデプロイされたプライベート リンク サービスとプライベート IP に対する管理およびコントロール プレーン接続が容易になります。 仮想ネットワーク ゲートウェイ インフラストラクチャは Microsoft によって管理されるため、メンテナンスが実行される場合があります。
メンテナンス期間中は、仮想ネットワーク ゲートウェイのパフォーマンスが低下することがあります。 仮想ネットワークへの接続の問題をトラブルシューティングし、最近のメンテナンス イベントによって容量が減少したかどうかを確認するには、次の手順に従います。
Azure portal で ExpressRoute 回線から [問題の診断と解決] を選択します。
[パフォーマンスの問題] オプションを選択します。
診断が実行され、結果が解釈されるまで待ちます。
パケット損失または待機時間が発生した期間中に仮想ネットワーク ゲートウェイでメンテナンスを行った場合、 ゲートウェイの容量が減少したことが、対象となる仮想ネットワークで発生している接続の問題に寄与している可能性があります。 推奨される手順に従ってください。 より高いネットワーク スループットをサポートし、将来のメンテナンス イベント中の接続の問題を回避するには、仮想ネットワーク ゲートウェイ SKUのアップグレードも検討してください。
次の手順
詳細やヘルプについては、次のリンク先を確認してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示