この記事は、Azure Route Server を使用する際の一般的な問題を診断して解決するのに役立ちます。 この記事のガイダンスを使用して、接続の問題、コントロール プレーンの問題、および運用上の問題のトラブルシューティングを行います。
接続の問題
ネットワーク仮想アプライアンス (NVA) が、既定のルート (0.0.0.0/0) を Route Server にアドバタイズした後で、インターネットに接続できなくなるのはなぜですか?
NVA が既定のルートをアドバタイズすると、Route Server は、NVA 自体を含む仮想ネットワーク内のすべての仮想マシン (VM) に対してそれをプログラムします。 この既定のルートでは、インターネットにバインドされたすべてのトラフィックのネクスト ホップとして NVA が設定されます。 NVA でインターネット接続が必要な場合は、ユーザー定義ルート (UDR) を構成して、NVA からのこの既定のルートをオーバーライドし、NVA がホストされているサブネットに UDR をアタッチする必要があります。 それ以外の場合、NVA ホスト マシンは、NVA によって送信されたトラフィックを含め、インターネットにバインドされたトラフィックを NVA 自体に送信し続けます。
詳細については、「 ユーザー定義ルート」を参照してください。
必要な UDR 構成:
| ルート | 次のホップ |
|---|---|
| 0.0.0.0/0 | インターネット |
GatewaySubnet 上のユーザー定義ルート (UDR) を使ってすべてのトラフィックをファイアウォールに強制的に転送すると、NVA が Route Server に接続できなくなるのはなぜですか?
ファイアウォールを使用してオンプレミスのトラフィックを検査する場合は、GatewaySubnet 上のユーザー定義ルート (UDR) を使用して、すべてのオンプレミス トラフィックをファイアウォールに強制的に送信できます。 ただし、この UDR は、コントロール プレーン トラフィック (BGP) をファイアウォールに強制することで、ルート サーバーとゲートウェイ間の通信を中断する可能性があります。 この問題は、ルート サーバーを持つ仮想ネットワーク宛てのトラフィックを調べる場合に発生します。
この問題を回避するには、別の UDR を GatewaySubnet ルート テーブルに追加して、コントロール プレーン トラフィックがファイアウォールに強制されるのを除外します (ファイアウォールへの BGP 規則の追加が望ましくないか、可能ではない場合)。
UDR 構成の例:
| ルート | 次のホップ |
|---|---|
| 10.0.0.0/16 | 10.0.2.1 |
| 10.0.1.0/27 | 仮想ネットワーク |
この例では：
- 10.0.0.0/16 は仮想ネットワークのアドレス空間です
- 10.0.1.0/27 は RouteServerSubnet のアドレス空間です
- 10.0.2.1 はファイアウォールの IP アドレスです
ネクスト ホップの種類を仮想ネットワーク ゲートウェイとしてユーザー定義ルート (UDR) を追加しましたが、この UDR が有効になりません。 これは想定される動作ですか。
はい、これは正しい動作です。 ネクスト ホップの種類が [仮想ネットワーク ゲートウェイ] であるユーザー定義ルートは、Route Server の仮想ネットワークおよびピアリングされた仮想ネットワーク内のサブネットではサポートされていません。 ただし、次ホップをネットワーク仮想アプライアンス (NVA) またはインターネットに構成する場合は、次ホップの種類 が VirtualAppliance または インターネットのユーザー定義ルートを追加できます。
VM のネットワーク インターフェイスの有効なルートで、ネクスト ホップの種類が [なし] に設定されているユーザー定義ルート (UDR) があるのはなぜですか?
他のユーザー定義ルートとプレフィックスが完全に一致するルートを NVA から Route Server にアドバタイズする場合は、アドバタイズされたルートのネクスト ホップが有効である必要があります。 アドバタイズされた次ホップがバックエンド プールが構成されていないロード バランサーである場合、この無効なルートはユーザー定義ルートよりも優先されます。 ネットワーク インターフェイスの有効なルートでは、無効なアドバタイズされたルートは、次ホップの種類が None に設定されたユーザー定義ルートとして表示されます。
Azure へのルートを再びアドバタイズした後に接続の課題が発生する理由
仮想ネットワークと UDR ルートから Azure BGP コミュニティを削除する予定がある場合は、ルーティングの問題が発生するため、これらのルートを Azure にアドバタイズし直さないでください。 Azure ルートを再び Azure にアドバタイズすることはお勧めしません。
サービス エンドポイント ポリシーを RouteServerSubnet または GatewaySubnet に関連付けた後、接続できなくなるのはなぜですか?
サービス エンドポイント ポリシーを RouteServerSubnet または GatewaySubnet に関連付ける場合、Azure の基になる管理プラットフォームと、それぞれの Azure サービス (ルート サーバーと VPN/ExpressRoute ゲートウェイ) の間で通信が中断される可能性があります。 これにより、これらの Azure リソースが異常状態になり、結果としてオンプレミスと Azure のワークロード間の接続が失われる可能性があります。
Route Server の仮想ネットワークに既定値 (Azure 提供の DNS) ではなくカスタム DNS を使用すると、接続が失われるのはなぜですか?
Route Server がデプロイされている仮想ネットワークで、既定の (Azure 提供の) DNS を使用していない場合は、カスタム DNS 構成でパブリック ドメイン名を解決できることを確認します。 これにより、Azure サービス (ルート サーバーと VPN/ExpressRoute ゲートウェイ) が Azure の基になる管理プレーンと通信できるようになります。
詳細については、Azure DNS Private Resolver のドキュメントのワイルドカード規則に関する注意事項を参照してください。
NVA から、Route Server の BGP ピア IP への TCP ping が、それらの間に BGP ピアリングを設定した後で実行できなくなるのはなぜですか?
一部の NVA では、NVA から Route Server に TCP ping を実行できるようにして、BGP ピアリングのフラッピングを回避するには、Route Server サブネットへの静的ルートを追加する必要があります。 たとえば、Route Server が 10.0.255.0/27 にあり、NVA が 10.0.1.0/24 にある場合は、NVA のルーティング テーブルに次のルートを追加する必要があります。
必要な静的ルート:
| ルート | 次のホップ |
|---|---|
| 10.0.255.0/27 | 10.0.1.1 |
この例では、10.0.1.1 は、NVA (またはより正確には NIC の 1 つ) がホストされているサブネット内の既定のゲートウェイ IP です。
ExpressRoute ゲートウェイや Azure VPN ゲートウェイが既に存在している仮想ネットワークに Route Server をデプロイしているときに、ExpressRoute や Azure VPN を経由するオンプレミス ネットワークへの接続が失われるのはなぜですか?
Route Server を仮想ネットワークにデプロイするときは、ゲートウェイと仮想ネットワークの間のコントロール プレーンを更新する必要があります。 この更新中、しばらくの間、仮想ネットワーク内の VM からオンプレミス ネットワークへの接続が失われます。 運用環境に Route Server をデプロイするには、メンテナンスをスケジュールすることを強くお勧めします。
コントロール プレーンの問題
Azure VPN ゲートウェイに接続されているオンプレミス ネットワークが、Route Server によってアドバタイズされた既定のルートを受信しないのはなぜですか?
Azure VPN ゲートウェイは、Route Server を含む BGP ピアから既定のルートを受信できますが、他のピアには既定のルートをアドバタイズしません。
BGP ピアリングが稼働しているのに、NVA が Route Server からルートを受信しないのはなぜですか?
Route Server が使用する ASN は 65515 です。 NVA と Route Server の間で eBGP セッションを確立できるように、NVA 用に別の ASN を構成し、ルート伝達が自動的に行われるようにしてください。 NVA とルート サーバーは仮想ネットワーク内の異なるサブネットにあるため、BGP 構成で マルチホップ を有効にしてください。
AS-Path で ASN が 0 のルートをアドバタイズすると、接続が機能しないのはなぜですか?
Azure Route Server は、AS-Path で ASN が 0 のルートをドロップします。 これらのルートが Azure に正常にアドバタイズされるようにするには、AS パスに 0 を含めないようにする必要があります。
NVA と Route Server の間で BGP ピアリングが稼働しています。 これらの間で正しく交換されたルートが表示されます。 NVA ルートが、VM の有効なルーティング テーブルの中にないのはなぜですか?
VM が NVA およびルート サーバーと同じ仮想ネットワーク内にある場合:
Route Server によって公開される 2 つの BGP ピア IP は、仮想ネットワーク内で実行されている他のすべての VM にルートを送信する責任を共有します。 仮想ネットワーク内の VM が Azure Route Server から一貫したルーティング情報を取得できるように、各 NVA は 2 つの同じ BGP セッション (たとえば、同じ AS 番号、同じ AS パスを使用し、同じルート セットをアドバタイズする) を 2 つの BGP ピア IP に設定する必要があります。
NVA のインスタンスが 2 つ以上ある場合は、1 つの NVA インスタンスをアクティブ、その他をパッシブとして指定したければ、異なる NVA インスタンスから同じルートの異なる AS パスをアドバタイズ "できます"。
VM が NVA とルート サーバーをホストする仮想ネットワークとは異なる仮想ネットワークにある場合:
2 つの仮想ネットワーク間で仮想ネットワーク ピアリングが有効になっているかどうか 、および VM の仮想ネットワークでリモート ルート サーバーの使用が有効になっているかどうかを確認します。
Route Server を仮想ネットワークにデプロイすると、ExpressRoute の等コスト マルチパス (ECMP) 機能がオフになるのはなぜですか?
複数の ExpressRoute 接続を介してオンプレミスのネットワークから Azure に同じルートをアドバタイズすると、通常、Azure からオンプレミスのネットワークに送り返されるトラフィックに対して、ECMP が既定で有効になります。 現在、ルート サーバーをデプロイすると、ExpressRoute とルート サーバー間の BGP 交換で複数パス情報が失われ、その結果、Azure からのトラフィックはいずれかの ExpressRoute 接続でのみ通過します。
運用上の問題
ルート サーバー操作を実行するための無効なスコープと認可に関するエラーが表示されるのはなぜですか?
次の形式のエラーが表示される場合は、次のアクセス許可が構成されていることを確認します: ルート サーバーの役割とアクセス許可。
エラー メッセージの形式:"オブジェクト ID {}を持つクライアントは、スコープ {}に対してアクション {}を実行する権限を持っていないか、スコープが無効です。 アクセスが許可されたのが最近である場合は、資格情報を更新してください。"
次のステップ
Azure Route Server を作成して構成する方法については、以下をご覧ください。