翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Outposts ラックネットワークのトラブルシューティングチェックリスト
このチェックリストは、ステータスが DOWN
のサービス リンクのトラブルシューティングに役立ちます。

Outpost ネットワーク デバイスとの接続
Outpost ネットワーク デバイスに接続されている顧客のローカル ネットワーク デバイスの BGP ピアリング ステータスを確認します。BGP ピアリングのステータスが DOWN
の場合は、次の手順に従います。
-
顧客のデバイスから Outpost ネットワーク デバイス上のリモート ピア IP アドレスに ping を実行します。ピア IP アドレスは、デバイスの BGP 設定で確認できます。ネットワーク準備チェックリスト インストール時に提供される を参照することもできます。
-
ping が失敗した場合は、物理接続をチェックし、接続ステータスが
UP
であることを確認します。-
お客様のローカルネットワーク機器の LACP 状態を確認します。
-
デバイスのインターフェイスのステータスを確認します。ステータスが の場合
UP
は、手順 3 に進みます。 -
お客様のローカル ネットワーク デバイスをチェックし、光モジュールが動作していることを確認します。
-
障害のあるファイバーを交換し、ライト (Tx/Rx) が許容範囲内にあることを確認します。
-
-
ping が成功した場合は、顧客のローカル ネットワーク デバイスをチェックし、次の BGP 構成が正しいことを確認します。
-
ローカル自律システム番号 (顧客 ASN) が正しく構成されていることを確認します。
-
リモート自律システム番号 (Outpost ASN) が正しく構成されていることを確認します。
-
インターフェイスの IP アドレスとリモート ピアの IP アドレスが正しく構成されていることを確認します。
-
広告および受信したルートが正しいことを確認します。
-
-
BGP セッションがアクティブ状態と接続状態の間でフラッピングしている場合は、TCP ポート 179 およびその他の関連する一時ポートが顧客のローカル ネットワーク デバイスでブロックされていないことを確認してください。
-
さらにトラブルシューティングが必要な場合は、顧客のローカル ネットワーク デバイスで次の点を確認してください。
-
BGP および TCP のデバッグ ログ
-
BGP ログ
-
パケットキャプチャ
-
-
問題が解決しない場合は、Outpost に接続されているルーターから Outpost ネットワーク デバイスのピア IP アドレスに対して MTR/traceroute/パケット キャプチャを実行します。エンタープライズ AWS サポートプランを使用して、テスト結果を サポートと共有します。
BGP ピアリング ステータスが顧客のローカル ネットワーク デバイスと UP
Outpost ネットワーク デバイスの間であるにもかかわらず、サービス リンクがまだ である場合は DOWN
、顧客のローカル ネットワーク デバイス上の次のデバイスを確認することで、さらにトラブルシューティングを行うことができます。サービス リンク接続のプロビジョニング方法に応じて、次のチェックリストのいずれかを使用してください。
-
に接続されたエッジルーター AWS Direct Connect — サービスリンク接続に使用されているパブリック仮想インターフェイス。詳細については、「AWS Direct Connect リージョンへの AWS パブリック仮想インターフェイス接続」を参照してください。
-
に接続されたエッジルーター AWS Direct Connect — サービスリンク接続に使用されているプライベート仮想インターフェイス。詳細については、「AWS Direct Connect リージョンへの AWS プライベート仮想インターフェイス接続」を参照してください。
-
インターネット サービス プロバイダー (ISP) に接続されたエッジ ルーター - サービス リンク接続に使用されるパブリック インターネット。詳細については、「リージョンへの ISP パブリック インターネット接続 AWS」を参照してください。
AWS Direct Connect リージョンへの AWS パブリック仮想インターフェイス接続
次のチェックリストを使用して、パブリック仮想インターフェイスがサービスリンク接続に使用されている AWS Direct Connect ときに に接続されたエッジルーターのトラブルシューティングを行います。
-
Outpost ネットワーク デバイスに直接接続しているデバイスが、BGP 経由でサービス リンク IP アドレス範囲を受信していることを確認します。
-
デバイスから BGP 経由で受信されているルートを確認します。
-
サービス リンクの Virtual Routing and Forwarding インスタンス (VRF) のルート テーブルを確認します。IP アドレス範囲を使用していることが表示されます。
-
-
リージョンの接続を確認するには、サービス リンク VRF のルート テーブルを確認します。これには、 AWS パブリック IP アドレス範囲またはデフォルトルートを含める必要があります。
-
サービスリンク VRF で AWS パブリック IP アドレス範囲を受信しない場合は、次の項目を確認してください。
-
エッジルーターまたは からの AWS Direct Connect リンクステータスを確認します AWS Management Console。
-
物理リンクが の場合は
UP
、エッジ ルータから BGP ピアリングのステータスを確認します。 -
BGP ピアリングのステータスが の場合
DOWN
、ピア AWS IP アドレスに ping を送信し、エッジルーターの BGP 設定を確認します。詳細については、AWS Direct Connect 「 ユーザーガイド」の「トラブルシューティング AWS Direct Connect」と「 AWS コンソールで仮想インターフェイスの BGP ステータスがダウンしています」を参照してください。「どうすればよいですか?」。 -
BGP が確立され、VRF にデフォルトルートまたは AWS パブリック IP アドレス範囲が表示されない場合は、エンタープライズ AWS サポートプランを使用して サポートにお問い合わせください。
-
-
オンプレミスのファイアウォールを使用している場合は、次の項目を確認してください。
-
サービス リンク接続に必要なポートがネットワーク ファイアウォールで許可されていることを確認します。ポート 443 での traceroute またはその他のネットワーク トラブルシューティング ツールを使用して、ファイアウォールとネットワーク デバイスを介した接続を確認します。次のポートは、サービス リンク接続用のファイアウォール ポリシーで設定する必要があります。
-
TCP プロトコル - 送信元ポート: TCP 1025-65535、宛先ポート: 443。
-
UDP プロトコル — 送信元ポート: TCP 1025-65535、宛先ポート: 443。
-
-
ファイアウォールがステートフルである場合は、アウトバウンドルールで Outpost のサービスリンク IP アドレス範囲と AWS パブリック IP アドレス範囲が許可されていることを確認します。詳細については、「AWS OutpostsAWS リージョンへの接続」を参照してください。
-
ファイアウォールがステートフルでない場合は、インバウンドフローも許可してください ( AWS パブリック IP アドレス範囲からサービスリンク IP アドレス範囲まで)。
-
ファイアウォールで仮想ルーターを構成している場合は、Outpost と AWS リージョン間のトラフィックに対して適切なルーティングが構成されていることを確認してください。
-
-
Outpost のサービス リンク IP アドレス範囲を独自のパブリック IP アドレスに変換するようにオンプレミス ネットワークで NAT を構成している場合は、次の項目を確認してください。
-
NAT デバイスが過負荷になっておらず、新しいセッションに割り当てる空きポートがあることを確認します。
-
NAT デバイスがアドレス変換を実行するように正しく構成されていることを確認します。
-
-
問題が解決しない場合は、エッジルーターから AWS Direct Connect ピア IP アドレスへの MTR / traceroute / packet captures を実行します。エンタープライズ AWS サポートプランを使用して、テスト結果を サポートと共有します。
AWS Direct Connect リージョンへの AWS プライベート仮想インターフェイス接続
次のチェックリストを使用して、プライベート仮想インターフェイスがサービスリンク接続に使用されている AWS Direct Connect ときに に接続されたエッジルーターのトラブルシューティングを行います。
-
Outposts ラックと AWS リージョン間の接続でプライベート接続機能を使用している場合 AWS Outposts は、次の項目を確認してください。
-
エッジルーターからリモートピアリング AWS IP アドレスに Ping を実行し、BGP ピアリングのステータスを確認します。
-
サービスリンクエンドポイント VPC とオンプレミスにインストールされている Outpost 間の AWS Direct Connect プライベート仮想インターフェイスを介した BGP ピアリングが であることを確認します
UP
。詳細については、AWS Direct Connect 「 ユーザーガイド」の「トラブルシューティング AWS Direct Connect」、「 AWS コンソールで仮想インターフェイスの BGP ステータスがダウンしています」を参照してください。「どうすればよいですか?」および「Direct Connect 経由の BGP 接続の問題をトラブルシューティングするにはどうすればよいですか? 」 -
AWS Direct Connect プライベート仮想インターフェイスは、選択した AWS Direct Connect ロケーションのエッジルーターへのプライベート接続であり、BGP を使用してルートを交換します。プライベート仮想プライベートクラウド (VPC) CIDR 範囲は、この BGP セッションを通じてエッジ ルーターにアドバタイズされます。同様に、Outpost サービス リンクの IP アドレス範囲は、エッジ ルーターから BGP 経由でリージョンにアドバタイズされます。
-
VPC 内のサービス リンク プライベート エンドポイントに関連付けられたネットワーク ACL が関連するトラフィックを許可していることを確認します。詳細については、「ネットワーク準備チェックリスト」を参照してください。
-
オンプレミスのファイアウォールがある場合は、VPC または VPC CIDR にあるサービス リンクの IP アドレス範囲と Outpost サービス エンドポイント (ネットワーク インターフェイスの IP アドレス) を許可するアウトバウンド ルールがファイアウォールにあることを確認してください。TCP 1025-65535 および UDP 443 ポートがブロックされていないことを確認してください。詳細については、AWS Outposts 「プライベート接続の紹介
」を参照してください。 -
ファイアウォールがステートフルでない場合は、VPC 内の Outpost サービス エンドポイントから Outpost への受信トラフィックを許可するルールとポリシーがファイアウォールにあることを確認してください。
-
-
オンプレミスネットワークに 100 を超えるネットワークがある場合は、BGP セッション経由でデフォルトルートをプライベート仮想インターフェイス AWS の にアドバタイズできます。デフォルトルートを広告したくない場合は、広告する経路数が 100 未満になるように経路を集約してください。
-
問題が解決しない場合は、エッジルーターから AWS Direct Connect ピア IP アドレスへの MTR / traceroute / packet captures を実行します。エンタープライズ AWS サポートプランを使用して、テスト結果を サポートと共有します。
リージョンへの ISP パブリック インターネット接続 AWS
サービス リンク接続にパブリック インターネットを使用する場合、ISP 経由で接続されているエッジ ルーターのトラブルシューティングを行うには、次のチェックリストを使用してください。
-
インターネット リンクが確立されていることを確認します。
-
ISP 経由で接続されたエッジ デバイスからパブリック サーバーにアクセスできることを確認します。
ISP リンク経由でインターネットまたはパブリック サーバーにアクセスできない場合は、次の手順を実行します。
-
ISP ルーターとの BGP ピアリング状態が確立されているか確認してください。
-
BGP がフラッピングしていないことを確認します。
-
BGP が ISP から必要なルートを受信してアドバタイズしていることを確認します。
-
-
スタティック ルート設定の場合は、エッジ デバイス上でデフォルト ルートが適切に設定されていることを確認してください。
-
別の ISP 接続を使用してインターネットに接続できるかどうかを確認します。
-
問題が解決しない場合は、エッジ ルーターで MTR/traceroute/パケット キャプチャを実行します。さらにトラブルシューティングを行うために、結果を ISP のテクニカル サポート チームと共有してください。
ISP リンクを通じてインターネットとパブリック サーバーにアクセスできる場合は、次の手順を実行します。
-
Outpost ホーム リージョン内のパブリックにアクセス可能な EC2 インスタンスまたはロード バランサーのいずれかがエッジ デバイスからアクセス可能かどうかを確認します。ping または telnet を使用して接続を確認し、traceroute を使用してネットワーク パスを確認できます。
-
VRF を使用してネットワーク内のトラフィックを分離する場合は、サービス リンク VRF に、ISP (インターネット) と VRF の間でトラフィックを送受信するルートまたはポリシーがあることを確認してください。次のチェックポイントを参照してください。
-
ISP に接続するエッジ ルーター。エッジ ルータの ISP VRF ルート テーブルを調べて、サービス リンクの IP アドレス範囲が存在することを確認します。
-
Outpost に接続する顧客のローカル ネットワーク デバイス。VRF の設定をチェックし、サービス リンク VRF と ISP VRF の間の接続に必要なルーティングとポリシーが適切に設定されていることを確認します。通常、デフォルト ルートは、インターネットへのトラフィックのために ISP VRF からサービス リンク VRF に送信されます。
-
Outpost に接続されているルーターでソースベースのルーティングを構成した場合は、構成が正しいことを確認してください。
-
-
Outpost サービスリンク IP アドレス範囲からパブリック IP AWS アドレス範囲へのアウトバウンド接続 (TCP 1025-65535 および UDP 443 ポート) を許可するようにオンプレミスファイアウォールが設定されていることを確認します。ファイアウォールがステートフルでない場合は、Outpost への受信接続も構成されていることを確認してください。
-
Outpost のサービス リンク IP アドレス範囲をパブリック IP アドレスに変換するために、オンプレミス ネットワークで NAT が構成されていることを確認します。また、以下の項目についても確認してください。
-
NAT デバイスは過負荷になっておらず、新しいセッションに割り当てるための空きポートがあります。
-
NAT デバイスはアドレス変換を実行するように正しく構成されています。
-
問題が解決しない場合は、MTR/traceroute/パケット キャプチャを実行します。
-
オンプレミス ネットワークでパケットがドロップまたはブロックされていることが結果で示された場合は、ネットワークまたは技術チームに追加のガイダンスを確認してください。
-
結果から、パケットが ISP のネットワークでドロップまたはブロックされていることが示された場合は、ISP のテクニカルサポートチームに連絡してください。
-
結果に問題が表示されない場合は、すべてのテスト (MTR、telnet、tracerroute、パケットキャプチャ、BGP ログなど) から結果を収集し、エンタープライズサポートプランを使用して AWS サポートにお問い合わせください。
Outposts は 2 つのファイアウォールデバイスの内側にあります。
Outpost を同期したファイアウォールの高可用性ペアまたは 2 つのスタンドアロンのファイアウォールの内側に置くと、サービスリンクの非対称ルーティングが発生する可能性があります。つまり、インバウンドトラフィックはファイアウォール 1 を通過し、アウトバウンドトラフィックはファイアウォール 2 を通過することになります。特に以前に正しく機能していた場合、以下のチェックリストを使用して、サービスリンクの非対称ルーティングの可能性を見極めます。
-
ファイアウォールを介したサービスリンクの非対称ルーティングにつながる可能性がある企業ネットワークのルーティング設定で、最近行われた変更や継続中のメンテナンスがあるかどうかを確認します。
-
ファイアウォールのトラフィックグラフを使用して、サービスリンクの問題の開始と一致するトラフィックパターンの変化を確認します。
-
ファイアウォールに部分的な障害や、ファイアウォールが相互に接続テーブルを同期しなくなった可能性のある、スプリットブレインが発生したファイアウォールペアのケースがないかを確認してください。
-
企業ネットワークで、サービスリンクの問題発生と一致するリンクダウンやルーティングの変更 (OSPF/ISIS/EIGRP のメトリクス変更、BGP ルートマップの変更) がないかを確認してください。
-
-
ホームリージョンへのサービスリンクにパブリックインターネット接続を使用している場合、サービスプロバイダーのメンテナンスにより、ファイアウォールを介したサービスリンクの非対称ルーティングが発生する可能性があります。
-
トラフィックグラフで、ISP へのリンクのトラフィックパターンに、サービスリンクの問題発生と一致する変化がないかを確認します。
-
-
サービスリンク AWS Direct Connect の接続を使用している場合、 AWS 計画されたメンテナンスによってサービスリンクの非対称ルーティングがトリガーされる可能性があります。
-
AWS Direct Connect サービスの計画されたメンテナンスの通知を確認します (複数可)。
-
冗長 AWS Direct Connect サービスがある場合は、メンテナンス条件下で、考えられる各ネットワークパスでの Outposts サービスリンクのルーティングを事前にテストできます。これにより、いずれかの AWS Direct Connect サービスが中断された場合に、サービスリンクの非対称ルーティングにつながるかどうかをテストできます。エンドツーエンドのネットワーク接続の AWS Direct Connect 部分の耐障害性は、 AWS Direct Connect Resiliency Toolkit でテストできます。詳細については、AWS Direct Connect 「Resiliency Toolkit による障害耐性のテスト – フェイルオーバーテスト
」を参照してください。
-
上記のチェックリストをすべて確認し、サービスリンクの非対称ルーティングが根本原因である可能性が高いと特定した後は、さらにいくつかの対応策があります。
-
企業ネットワークの変更を元に戻すか、プロバイダーが計画したメンテナンスが完了するまで待機して、対称ルーティングを復元します。
-
ファイアウォールのいずれか一方または両方にログインし、コマンドラインからすべてのフローのフロー状態の情報をすべてクリアします (ファイアウォールベンダーがサポートしている場合)。
-
一方のファイアウォールを介して BGP アナウンスを一時的にフィルタリングするか、もう一方のファイアウォールのインターフェイスをシャットダウンして、もう一方のファイアウォールを介して対称ルーティングを強制的に行います。
-
各ファイアウォールを再起動して、ファイアウォールのメモリ内のサービスリンクトラフィックのフロー状態追跡における破損の可能性を排除します。
-
ファイアウォールベンダーと協力して、ポート 443 宛ての UDP 接続の UDP フロー状態の追跡を検証するか緩和します。