ソケットサイトパケットロスのトラブルシューティング

問題

パケットロスの発信元を特定し、その原因を解明するのは簡単ではありません。 パケットは、インターネットを通じて、異なるISPおよび組織の所有する複数のネットワークを通過し、リンクの状態やCPU負荷などを確認するための経路上のすべてのルーターにアクセスすることはできません。 その上、パケットロスはネットワーク経路のどのポイントでも発生する可能性があります。

可能な原因

パケットが途中でドロップされる理由は多岐にわたります。 よくある理由のいくつかは以下の通りです：

  • ISPのピアリングの問題
  • リンクの輻輳
  • 誤った構成（帯域幅の設定やNICの速度と全二重設定）
  • ハードウェアの故障
  • ネットワークデバイスのCPU使用率が高い
  • マイクロバーストの処理

Catoでのパケットロスを理解する

Catoのパケットロスを特定する良い方法の一つは、Cato管理画面のアナリティクス画面を使用することです。 パケットロスおよび破棄したグラフは、時間と共にパケットロスを示し、特定の時間枠に焦点を当てることができます。 これらのグラフは、パケットロスが発生しているかどうか、過去にいつ発生したかを特定するために役立ちます。 さらに、パケットロスの種類を特定することができます：プロバイダーによる損失またはCatoによる破棄。

注意: アナリティクス グラフでの最小データ バケット サンプルサイズは5秒です。 その結果、5ms以内のマイクロバーストは表示される平均値の中で正規化され、アナリティクスグラフにはピークとして表示されません。

1. プロバイダによる損失

これは、ソケットとPoPの間のパケットロスの例です。 ほとんどのプロバイダーのパケットロスは、Catoの制御外にある最終区間のネットワーク接続の問題によって引き起こされますが、これがCato関連の問題を必ずしも除外するわけではありません。

Catoによるプロバイダ損失の測定方法 

プロバイダの損失は、指定されたリンク上でソケットとPoPの両方が送信したパケット数と受信したパケット数を比較することで測定されます。

  • 下りのパケットロスは、PoPが送信したパケット数とソケットが受信したパケット数の違いをパーセンテージで表したものです。

公式：

  • 上りのパケットロスは、ソケットが送信したパケット数とPoPが受信したパケット数の違いをパーセンテージで表したものです。

数式：

Catoがプロバイダのパケットロスを計算する方法では、簡単なように見えても、すぐにすべての責任をISPに押し付けられません。 ソケットとISPルーターの間にパケット損失に関与する機器がある可能性があります。または、ISPの管理を超えたPoPに近いネットワーク経路に問題があるかもしれません。

2. Cato破棄

Catoが破棄したパケットロスはCato QoSによって引き起こされます。 リンクが輻輳中やトラフィックバースト中、QoSエンジンは低優先度のパケットを破棄し始めます。 リンクの総スループットがそのリンクに設定された帯域幅に一致する場合、輻輳が発生します。 帯域管理の優先度が厳格なスループット制限で設定され、その優先度に一致するトラフィックがその制限に達した場合、Catoはパケットも破棄します。 Catoによって破棄されたパケットロスは予想された動作であり、必ずしも問題の兆候ではありません。

Catoによって破棄されたパケットロスに関連するすべての問題は、誤った設定が原因で発生する可能性があります。 VoIPのような重大なアプリケーションには、最高の帯域管理優先度を付与する必要があります。 輻輳が発生すると、Catoによって低優先度のトラフィックがドロップされますが、高優先度のトラフィックはドロップされません。 常に適切な帯域管理優先度がトラフィックに割り当てられていることを確認してください。

アナリティクスはパケットロスの広範なビューを提供します。 しかし、Catoによって破棄されたパケットロスを処理していない限り、アナリティクスだけではパケットロスの原因や発生場所を特定することはできません。 

 

パケットロスのトラブルシューティング方法

1. パケットロスのスコープを決定

開始時に、誰がまたは何がパケットロスを経験しているのかを特定することが非常に重要です。 サイトのすべてのユーザーがパケットロスを経験しているのか、それとも特定のエンドポイントに限定されているのか？ パケットロスはインターネット上で発生しているのか、WAN上で発生しているのか？ 複数のサイトがパケットロスの影響を受けているのか、それとも一つだけなのか？ すべてのトラフィックに影響があるのか、それとも特定のアプリケーションだけなのか？ パケットロスは一定なのか、断続的にのみ発生するのか？

上記の質問に対する答えを知っていれば、関連するCMAイベントを特定するのに役立ち、トラブルシューティングプロセス中の時間を節約できます。 事前に知っている詳細が多いほど、トラブルシューティングはより集中できます。

2. サイトアナリティクスの確認 - パケットロスグラフ

パケットロスはサイトアナリティクスのパケットロスグラフに表示されていますか？ パケットロスと破棄されたパケットを表示する可能性のあるアナリティカルグラフに基づいて、異なる推奨事項があります。

パケットロスなし

アナリティクス画面にパケットロスが表示されなくても、パケットロスが存在する可能性があります。 ローカルネットワークに問題がある可能性がありますが、PoPに関連する問題の可能性もあります。 SocketからLAN側のIPにpingを送信するためにUIネットワークツールを使用することは、根本原因を特定するための優れた方法となり得ます。

パケットロス

グラフにパケットロスが表示される場合、帯域幅の構成ミスが原因である可能性があります。 以下の帯域幅の設定を確認に記載されているように、構成された帯域幅を確認してください。

プロバイダーによるパケットロスの場合、トラフィックの急上昇（バースト）が発生する場合にドロップが発生するかどうかを確認してください。 その場合は、アプリケーションアナリティクスページを使用してバーストの原因となっているトラフィックを特定します。 制限付きの帯域管理プロファイルにアプリケーショントラフィックを割り当てることで、アプリケーショントラフィックを制限できます。

一般的にスループットが低いが、バーストスパイクがパケットロスを引き起こすケースを見ることがよくあります。 ISPには独自のトラフィックシャーピングポリシーがあることを考慮する必要があり、そのような場合にはISPのポリシーとCatoのトラフィックシャーピングポリシーとに異なるバースト性ポリシーがある可能性があります。 バースト性の詳細情報は、下記のマイクロバーストの確認をご覧ください

3. サイトアナリティクスの確認 - 破棄されたパケットグラフ

Catoによって破棄されたパケットの場合、帯域幅優先度も調査する必要があります。 サイトのアナリティクス画面の下では、どの優先度が破棄されたかを見るためにプライオリティアナライザーを確認してください。 その優先度の上位アプリケーションを表示するために優先度セクションを拡張できます。 パケットロスが特定のアプリケーションにのみ影響を与える場合、ネットワークルールでそのアプリケーションの優先度を上げる必要があるかもしれません。 覚えておいてください、Cato QoSは輻輳が発生した際に低優先度のパケットを破棄するように設計されているため、Catoによるパケットロスは必ずしも問題ではありません。

キューでバーストが発生した場合、カトQoSは任意のパケットを優先度に関係なく破棄することもあります。 この動作はバースト管理の性質によるものです。 プライオリティアナライザーページを使用して、トラフィックのバーストがパケットが破棄されたと同じタイミングで発生しているか確認できます。 詳細については、ソケットトラフィックの優先順位付けとQoSをご覧ください。

Use_as_placeholder_for_now.png

アナリティクス画面のプライオリティアナライザーは、各QoS優先度の上りおよび下りの方向でのパケットロスを表示します。

4. (オプション) 最終区間のエクスペリエンスモニタリング

エクスペリエンスモニタリングライセンスを持つ顧客は、パケットロスやパケット破棄の可能性を確認するために、最終区間とアプリケーションパフォーマンスタブを確認できます。 データはサイトネットワークアナリティクスページの所見と関連付けて、問題の発生源をよりよく理解することができます。

5. サイトアナリティクスの確認 - 最終区間でのパケットロス

インターネットサービスプロバイダーに問題があるかどうかを評価するには、アナリティクス画面の最終区間タブを使用して、WANリンクでのレイテンシーの変化やパケットロスを確認してください。 プロバイダーのパケットロスとは異なり、最終区間データは人気のあるウェブサイトへのICMPテストに基づいています。 推奨として、Ping可能な追加サービスのIPを最終区間の監視ページに追加することができます。 例えば、VoIP関連の問題がある場合、SIPサーバーのIPをIPの一つとして設定することができます。

ISP関連のパケットロスが疑われる場合は、ISPに次の質問をしてください：

  1. UDP/443またはUDP/1337（DTLS）トラフィックにQoSを適用していますか？
  2. UDPトラフィックにDoS保護を適用していて、それがPoP IPへのパケットロスを引き起こしていませんか？
  3. PoP IPへの経路上で、ルーターに輻輳やCPU使用率の高さがありますか？
  4. 契約している回線速度を超えてバーストが許可されていますか？

6. 帯域幅設定の確認

パケットロスはリンクの輻輳によって引き起こされる可能性があります。Cato管理画面で各WANリンクの帯域幅を正しく設定することが重要です。 サイト設定でISPが提供する帯域幅と設定された帯域幅が一致することを確認してください。 Catoサイトライセンスの条件に従って、ソケットWANインタフェースの帯域幅設定を行ってください。

Azure/AWSの環境では、従来の帯域幅制限がありません。 代わりに、設定されたサイトの帯域幅はvSocketのサポートされている帯域幅を超えてはなりません。 Azureのバージョン21から、Standard_D8ls_v5 VMサイズは最大2Gbpsをサポートしています。 AWSでは、c5n.xlargeインスタンスサイズが2Gbpsを超える帯域幅を提供します。 サイトの設定帯域幅がサポートされている制限内に収まるようにすることが最適なパフォーマンスを確保するために重要です。

設定された帯域幅がISPの提供するよりも低い場合、設定された帯域幅制限を超えるとCatoのQoSエンジンがパケットを破棄し始める可能性があります。 この場合、サイトのアナリティクススループットグラフには、Catoが破棄したパケットに加えて、サイトの設定された帯域幅と同じフラットラインが表示されます。

この同じ動作は、帯域幅が正しく設定されていても、ISPリンクが輻輳している場合に発生する可能性があります。 この動作が問題を保証するわけではありませんが、この状況で帯域幅が正しく設定されていることを確認するのは良い方法です。

設定された帯域幅がISPの提供するものよりも高い場合、ISPの帯域幅制限を超えてもCatoのQoSエンジンは開始せず、ISPがランダムにパケットを破棄し始める可能性があります。 この場合、プロバイダーのパケットロスに加えて、設定された帯域幅レベル以下でのサイトアナリティクススループットグラフにフラットラインが見られます。

Socketの各モデルにおけるスループットと容量の情報はSocketデータシートで利用できます。この記事をご覧ください：X1700、X1600 & X1500ソケットガイド。

7. ソケットCPU使用率をチェック

CMAのネットワークアナリティクスからハードウェアタブを選択します。 このセクションは、各コアの過去のCPU使用率を表示します。

90%以上の一貫したCPU使用率は、ソケットパフォーマンスに悪影響を及ぼし、パケットロスや高いレイテンシーを引き起こす可能性があります。 一貫した高いCPU使用率が観察された場合、潜在的なハードウェアの交換を評価するためにアカウント代表者に連絡してください（例：X1500からX1600へ）。

さらなるトラブルシューティングについては、サポートに連絡

リアルタイムのソケットCPU使用率は、ソケットWebUIのHWステータスタブから確認できます。 アクティブな使用状況を過去のデータと比較して、パフォーマンストレンドを特定します。

8. サイト再接続を除外

サイトがCatoクラウドに再接続するとパケットロスの原因となります。 パケットロスが再接続イベントと関連しているか確認するには、ホーム>イベントを確認してください。 イベントをサブタイプ = 「再接続済み」でフィルターしてください。

再接続イベントは、切断の理由を説明するメッセージを表示します。 See Understanding Reconnected Events

9. Catoをバイパスする

インターネット上のパケットロスには、Catoクラウドに問題がないことを迅速に確認するために、 送信元または送信先バイパスを設定してください。 最も簡単な方法は、サイト構成で単一のユーザーのIPアドレスのために送信元バイパスを設定してパケットロスが続くかどうか確認することです。 パケットロスが続く場合、問題はLAN、ソケット、またはISPにある可能性がありますが、PoPに関連する問題ではないでしょう。

3._バイパス_Cato_.png

10. Pingテストの実行

パケットロスが発生している送信元と宛先のIPアドレス間で連続的なPingを開始します。 Pingはトレースしやすく、パケットキャプチャで分析することができます。 一部のpingリクエストが宛先に到達しない場合、パケットロスが発生している可能性があり、要求タイムアウトとして表示されます。

ソケットUIでは、pingツールを使用してホスト名またはIPでpingを送信することもできます。 Catoを使用するか、直接WANリンクを介してpingを送信するインターフェースを選択できます。 ping結果におけるパケットロスや高いレイテンシーなどの不一致を確認してください。 Catoを使用しても使用しなくてもパケットロスが発生する場合、ISPの問題を示している可能性があります。 さらに、リンクの1つが4G/LTEの場合、これらのリンクがパケットロスに敏感であることを覚えておく必要があります。

UIは10個のPingリクエストしか送信しません。もっと必要な場合はPingボタンを再度クリックする必要があります。 

注意: Pingテストは基本的なネットワーク健全性を確認するのに優れていますが、Pingのドロップがないことが必ずしもクリーンなラインを示すわけではありません。

Ping.png

11. トレースルートテストの実行

トレースルートは、送信元と宛先間のルーター（ホップ）を特定するために使用されます。 各ホップのパケットロスとレイテンシーを表示します。

トレースルートは、ソケットUIからトレースルートツールを使用して実行できます。 ソケットと宛先間のWANリンク上の任意のホップでパケットロスや予期せぬ高いレイテンシーを見つけるためにトレースルートを実行します。 UIは各ホップに対して1つのパケットを送信し、各ホップのパケットロスを表示します。 1つのパケットしか送信されないため、0%または100%のロスのみを見ることができます。

トレースルート結果分析

単一のホップで表示されるパケットロスは必ずしも問題の兆候とは限りません。 単一のホップが100%のパケットロスを示すことがありえますが、これはルーターにICMPが有効でないためです。 ICMPのレート制限により、問題がなくても100%未満のパケットロスを示すことがあります。 あるホップでいくつかのパケットロスが見られ、次のホップで0%のロスがある場合、これはICMPのレート制限を目撃している可能性があります。

もし実際にパケットロスの問題がある場合、それは一つのホップで始まり、複数のホップで続き、それぞれのホップでパケットロスが見られます。 また、経路上の複数のルーターがパケットロスに寄与している可能性があり、そのため各ホップでのパケットロスの量が異なることがあります。 例として、そのルートには8つのホップがあり、トレースルートはホップ3-7のパケットロスを示します。

Traceroute.png

12. パケットロスを検出するための高トラフィックロードの生成

リアルタイム画面は、現在のスループットの変化を識別し、即時のパケットロスおよび破棄されたパケットを検出するのに役立ちます。 ソケットのスピードテストツールを使用して、高負荷をシミュレートし、トラブルシューティング中に高需要によるパケットロスを再現します。

Socket Speedtest の結果は、Cato管理アプリケーションでリンクに設定された帯域幅に近い値であると予想されます。 DTLSトンネルのオーバーヘッド(117バイト)がスループットをわずかに減少させる可能性があることに注意してください。 

テストはリンクを飽和させ、ネットワークアナリティクス画面でISP関連のパケットロスが表示されます。 設定されたリンク帯域幅がISPから提供された帯域幅よりも低い場合、テストを実行すると破棄されたパケットが予期されます。

ダイレクトスピードテスト 

WANポートを介して直接スピードテストを実行する際、 アップストリーム の結果は、Cato管理アプリケーションで設定された帯域幅ライセンスに近い値である必要があります。 ソケットは、サイトの帯域幅ライセンスに従って、アップストリームダイレクトスピードテストに対してQoSを引き続き使用します。 一方、 ダウンストリーム の結果は、ローカルISPの全容量を表示します。

13. iPerfでリンクをテストする

ソケットWebUIを使用すると、iPerfツールを使用して、ソケットとCatoクラウド内の接続済みPoPとの間のラストマイルパフォーマンスの問題をトラブルシューティングできます。 iPerfクライアントを実行中のSocketは、接続されたPoPで実行中のiPerfサーバーに対してテストを行います。

Catoを介して、ソケットUIのツールページからWAN経由で直接iPerfテストを実行します。 プロトコルとしてUDPを選択し（TCPフロー制御を除外するため）、方向（アップストリームまたはダウンストリーム）を設定し、ターゲットレートを設定済みの帯域幅として設定します。 このツールを使用すると、CatoおよびWANを介したスループットが予想通りであることをよりよく確認できます。 DTLSトンネルのオーバーヘッド(117バイト)がスループットをわずかに減少させる可能性があることに注意してください。 

下記の例では、45Mbpsを目標速度として設定しています（これはCato管理画面で設定されている帯域幅と同じです）。受信速度は予想より低く、パケットロスは3.7%です。

14. リンク集約（LAG）リンクの確認

パケットロスと高レイテンシーは、ソケットと内部スイッチ間のリンク集約（LAG）の構成ミスが原因で発生する可能性があります。 この特定の問題はネットワークアナリティクスで検出できませんが、LAN内でトラブルシューティングする必要があります。 Catoは静的LAGのみをサポートしており、LAGピアは同じモードをサポートする必要があります。 LAGの構成不一致はパケットロスを引き起こします。

さらなるトラブルシューティング情報については、高いレイテンシーとパケットロスを経験するリンク集約（LAG）リンクを参照してください。

15. ソケットのリンク速度の確認

プロバイダーの損失の可能性のある原因の一つは、ソケットリンクが半二重で動作していることです。 これは、パケットが一度に一方向（アウトバウンドまたはインバウンド）にしか移動できず、スループットが大幅に減少し、パケットロスが発生することを意味します。 すべてのソケットリンクは例外なく常に全二重であるべきです。

また、WANとLANの両方のリンク速度がサイトの構成済み帯域幅と等しいかそれ以上であることを確認してください。 リンク速度がスループットの制限要因になる可能性があります。 例えば、サイトの設定済み帯域幅が200 Mbpsであるにもかかわらず、LANリンクが100 Mbpsの全二重でしか交渉されていない場合、ソケットに接続されたコンピュータは100 Mbps以上のスループットを達成できません。

リンク状態を確認するには、ソケットUIにログインし、監視ページでリンクのステータスを表示します。 下記の例は、100 Mbpsの半二重状態にあるWAN1リンクを示しています。

半二重、または誤った速度に設定されているリンクに気づいた場合は、ソケットのリンクが接続されているデバイスのポート設定を確認してください。 それが自動交渉に設定されているか、ソケットの速度設定と一致していることを確認してください。 すべてのソケットリンクはデフォルトで自動交渉に設定されていますが、ネットワーク設定ページで速度を強制することもできます。

_7.png

他のデバイスでポート設定が正しい場合、イーサネットケーブルが損傷している可能性があります。 既知の良品ケーブルと交換し、二重または速度が変わるかどうかを確認してください。 それでも解決しない場合は、ノートPCや他のデバイスをソケットのポートに接続し、リンク状態を確認してください。 他のデバイスでも同じ操作を行ってください。 もしソケットのリンクが期待通りの速度と全二重で接続されているが、他のデバイスのリンクがそうでない場合、問題は他のデバイスにあることがわかります。

16. 重複したIPアドレスの確認

ネットワーク内でパケット損失を引き起こす可能性のあるもう一つの問題は重複したIPアドレスです。 ソケットは通常、自分の設定済みのインタフェースIPアドレスでIPアドレスの競合を検出できます。 同じネットワーク上の2台のデバイスに同じIPアドレスが割り当てられると、IPアドレスの競合が発生します。 これが起こると、ソケットUIのモニターページに以下のエラーが表示されます。

WANインタフェースに静的IPアドレスを設定するとき、ソケットがIPアドレス競合をパッシブに監視するため、重複したIPアドレスが検出されない可能性があります。 ソケットが競合IPアドレスを持つデバイスからARPを受信した場合にのみ、IPアドレスの競合を検出します。

競合IPアドレス問題が解決されると、WebUIから警告が消えるまで最大24時間かかることがあります。 参照 解決された後でもソケットUIで報告されるIPアドレス競合

17. マイクロバーストを確認

パケット損失の別の潜在的な原因はマイクロバースト（急激なデータトラフィックの増加）です。 マイクロバーストは、非常に短い時間枠で発生する急激なパケットまたはデータフレームの増加を特徴とし、通常はわずか数マイクロ秒から数ミリ秒だけ持続します。 マイクロバーストが発生しリンクのレート制限を超える状況では、ラストマイルプロバイダー（ISP）が過剰なトラフィックをドロップする可能性があり、パケット損失が発生します。

以下のグラフでは、マイクロバーストによる典型的なパケット損失の例と、バースト性の値設定を調整した後の改善を確認できます。 

Inserting image...

上の例では、バースト性レベルの値がデフォルト値の0.2から0.01へ変更されました。これは、SocketとPoPがトラフィックに対してより積極的に整形を適用し、結果としてパケットロスの問題を解決することを意味します。  

パケットロスを軽減するためのバーストレベル設定の調整

上りと下りの方向に適用されるデフォルトのバースト値は0.2です。 この値を使用すると、SocketとPoPはパケットをできるだけ早くメディアにシリアル化し、時間バケットの最初のマイクロ秒でより多くのバイトを送信できます。 この設定は、シリアル化の遅延と全体的なレイテンシーを減少させてパフォーマンスを最適化します。 

このトラブルシューティングの一環として、パケットロスが軽減されるまでバーストレベルを徐々に減少させる必要があります。 バーストレベル値を下げると、SocketとPoPはトラフィックに対してよりアグレッシブなシェーピングを適用し、マイクロバーストを滑らかにします。 構成可能な最小値は0.001です。

バーストレベルを調整するためのベストプラクティスは、値を段階的に減らすことです（例：0.2から0.18）。  値を減らした後、サイト監視のリアルタイムやネットワークアナリティクス画面でパケットロスを分析して影響をモニタリングします。 サイトのメトリックが通常更新されるまで数分かかることを覚えておいてください。 パケットロスが軽減されるまでバースト値を減らし続けます。 

この手順でパケットロスが解決されない場合、それはマイクロバーストとは異なる理由であることを意味します。  この場合、デフォルトのバースト値0.2を復元し、さらなるサポートが必要な場合はサポートへのお問い合わせください。 

バーストレベルの変更

バーストレベルは上りおよび下りの方向に応じて調整可能です。 この設定は、サイトのすべてのWANリンクに影響を与えます。 

構成はサイトレベルまたはアカウントレベルで適用されます。 サイトレベルの構成は、アカウントレベルよりも優先されます。

 

バーストレベルを構成するには：

  1. ナビゲーションメニューから、アカウントレベルの設定にはリソース > 高度な設定、またはサイトレベルの設定にはサイト設定 > 高度な設定を選択します。
  2. ダウンストリームのバースト値またはアップストリームのバースト値を選択します。
  3. 設定を有効にして、値を0.001〜0.2の範囲に調整します。
  4. 適用をクリックします。
  5. 保存をクリックしてください。

注意： 

  • バースト性が以前にCatoサポートによって調整された場合、デフォルトの値0.2の代わりに調整された値が表示されます
  • バースト性の値はソケットサイトに対してのみ調整できます
  • Cato管理画面での最小のデータバケットは5秒で、マイクロバーストは最小のデータバケット内で標準化され、通常は識別が困難です。 

 

 

 

この記事は役に立ちましたか？

5人中5人がこの記事が役に立ったと言っています

0件のコメント