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 アドレスです。

サービス エンドポイント ポリシーを RouteServerSubnet または GatewaySubnet に関連付けた後、接続できなくなるのはなぜですか?

サービス エンドポイント ポリシーを RouteServerSubnet または GatewaySubnet に関連付けた場合、Azure の基になる管理プラットフォームと、それぞれの Azure サービス (ルート サーバーと VPN/ExpressRoute ゲートウェイ) との間で、通信が中断される可能性があります。 これにより、これらの Azure リソースが異常状態になり、結果としてオンプレミスと Azure のワークロード間の接続が失われる可能性があります。

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 の構成で "マルチホップ" を必ず有効にしてください。

NVA と Route Server の間で BGP ピアリングが稼働しています。 これらの間で正しく交換されたルートが表示されます。 NVA ルートが、VM の有効なルーティング テーブルにないのはなぜですか。

• VM が NVA および Route Server と同じ仮想ネットワーク内にある場合:

  Route Server によって公開される 2 つの BGP ピア IP は、仮想ネットワーク内で稼働する他のすべての VM にルートを送信する責任を共有する 2 つの VM でホストされます。 各 NVA で、2 つの VM に対して 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 を作成して構成する方法については、以下をご覧ください。

Azure Route Server を作成して構成する