Azure Route Server の問題のトラブルシューティング
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 自身に送り返し続けます。 詳しくは、ユーザー定義ルートに関する記事をご覧ください。
| ルート | 次ホップ |
|---|---|
| 0.0.0.0/0 | インターネット |
GatewaySubnet 上のユーザー定義ルート (UDR) を使ってすべてのトラフィックをファイアウォールに強制的に転送すると、NVA が Route Server に接続できなくなるのはなぜですか?
ファイアウォールを使ってオンプレミスのトラフィックを検査する場合は、GatewaySubnet (ユーザー定義ルート (UDR) が存在する GatewaySubnet に関連付けられているルート テーブル) 上の UDR を使って、すべてのオンプレミス トラフィックをファイアウォールに強制的に転送できます。 ただし、この UDR では、コントロール プレーン トラフィック (BGP) をファイアウォールに強制的に転送することで、Route Server とゲートウェイの間の通信が途絶する可能性があります (この問題は、Route Server が存在する仮想ネットワーク宛てのトラフィックを調べる場合に発生します)。 この問題を回避するには、別の UDR を GatewaySubnet ルート テーブルに追加して、コントロール プレーン トラフィックがファイアウォールに強制的に転送されないようにする必要があります (ファイアウォールに BGP 規則を追加することが望ましくない場合、または不可能な場合)。
| ルート | 次ホップ |
|---|---|
| 10.0.0.0/16 | 10.0.2.1 |
| 10.0.1.0/27 | VirtualNetwork |
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 にアドバタイズする場合は、アドバタイズされたルートのネクスト ホップが有効である必要があります。 アドバタイズされたネクスト ホップがバックエンド プールが構成されていないロード バランサーである場合、この無効なルートがユーザー定義ルートよりも優先されます。 ネットワーク インターフェイスの有効なルートでは、無効なアドバタイズされたルートが、ネクスト ホップの種類が [なし] に設定されたユーザー定義ルートとして表示されます。
サービス エンドポイント ポリシーを RouteServerSubnet または GatewaySubnet に関連付けた後、接続できなくなるのはなぜですか?
サービス エンドポイント ポリシーを RouteServerSubnet または GatewaySubnet に関連付けた場合、Azure の基になる管理プラットフォームと、それぞれの Azure サービス (ルート サーバーと VPN/ExpressRoute ゲートウェイ) との間で、通信が中断される可能性があります。 これにより、これらの Azure リソースが異常状態になり、結果としてオンプレミスと Azure のワークロード間の接続が失われる可能性があります。
Route Server の仮想ネットワークに既定値 (Azure 提供の DNS) ではなくカスタム DNS を使用すると、接続が失われるのはなぜですか?
仮想ネットワークに Route Server がデプロイされていて、既定の (Azure 提供の) DNS を使用していない場合は、そのカスタム DNS 構成でパブリック ドメイン名を解決できることを確認してください。 これにより、Azure サービス (Route Server と 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 と Route Server は仮想ネットワークの異なるサブネットにあるため、BGP の構成で "マルチホップ" を必ず有効にしてください。
AS-Path で ASN が 0 のルートをアドバタイズすると、接続が機能しないのはなぜですか?
Azure Route Server は、AS-Path で ASN が 0 のルートをドロップします。 これらのルートが Azure に正常にアドバタイズされるようにするには、AS-Path に 0 を含めないようにする必要があります。
NVA と Route Server の間で BGP ピアリングが稼働しています。 これらの間で正しく交換されたルートが表示されます。 NVA ルートが、VM の有効なルーティング テーブルの中にないのはなぜですか?
VM が NVA および Route Server と同じ仮想ネットワーク内にある場合:
Route Server によって公開される 2 つの BGP ピア IP は、仮想ネットワーク内で実行されている他のすべての VM にルートを送信する責任を共有します。 各 NVA で、2 つの BGP ピア IP に対して 2 つの同じ BGP セッションを設定し (たとえば、同じ AS 番号と同じ AS パスを使用し、同じルートのセットをアドバタイズして)、仮想ネットワーク内の VM が Azure Route Server から一貫したルーティング情報を取得できるようにする必要があります。
NVA のインスタンスが 2 つ以上ある場合は、1 つの NVA インスタンスをアクティブ、その他をパッシブとして指定したければ、異なる NVA インスタンスから同じルートの異なる AS パスをアドバタイズ "できます"。
NVA と Route Server をホストするものとは異なる仮想ネットワークに VM が存在する場合。 2 つの VNet 間で VNet ピアリングが有効になっていて "かつ" VM の仮想ネットワークで [Use Remote Route Server] (リモート Route Server を使用する) が有効になっているかどうかを調べます。
Route Server を仮想ネットワークにデプロイすると、ExpressRoute の等コスト マルチパス (ECMP) 機能がオフになるのはなぜですか?
複数の ExpressRoute 接続を介してオンプレミスのネットワークから Azure に同じルートをアドバタイズすると、通常、Azure からオンプレミスのネットワークに送り返されるトラフィックに対して、ECMP が既定で有効になります。 現在、Route Server をデプロイすると、ExpressRoute と Route Server 間の BGP 交換でマルチパス情報が失われ、その結果、Azure からのトラフィックは ExpressRoute 接続の 1 つのみを移動するようになります。
次のステップ
Azure Route Server を作成して構成する方法については、以下をご覧ください。