問題
パケットロスの原因を特定することと、その発生理由を見つけることは常に簡単ではありません。 パケットは、インターネット上で異なるISPや組織が所有する複数のネットワークを通過し、ルータのリンク状態やCPU負荷を確認するために、すべてのルーターにアクセス権を持っているわけではありません。 さらに、パケットロスはネットワークパスのどの地点でも発生する可能性があります。
可能性のある原因
パケットが途中でドロップされる理由はいくつもあります。 いくつかの一般的な例は次のとおりです：
ISPピアリングの問題
リンクの輻輳
ミスコンフィギュレーション（帯域幅設定またはNICスピードとデュプレックス）
ハードウェアの故障
ネットワークデバイスでの高いCPU使用率
マイクロバーストの処理
Catoでのパケットロスの理解
Catoでのパケットロスを特定する良い方法は、Cato管理アプリケーションのアナリティクス画面を使用することです。 パケットロスと破棄のグラフは、時間とともにパケットロスを示し、特定の時間枠に集中することができます。 これらのグラフは、パケットロスが発生しているか、過去いつ発生したかを特定するのに役立ちます。
注：
アナリティクスグラフの最小データバケツサンプルサイズは5秒です。 その結果、5ms以内のマイクロバーストは、表示される平均値に正規化され、アナリティクスグラフにピークとして表示されません。
1. プロバイダーの損失
ソケットとPoPの間で発生します。 ほとんどのプロバイダーパケットロスは、Catoの制御外のラストマイルでのネットワーク接続の問題によって引き起こされますが、Cato関連の問題を除外するわけではありません。
Catoはプロバイダーの損失をどのように測定するか
プロバイダーの損失は、ソケットとPoPの両方で、特定のリンク上で送信されたパケット数と受信されたパケット数を比較することによって測定されます。
下流のパケットロスは、PoPによって送信されたパケット数とソケットによって受信されたパケット数の差異を百分率で表したものです。
式：
上流のパケットロスは、ソケットによって送信されたパケット数とPoPによって受信されたパケット数の差異を百分率で表したものです。
式：
Catoがプロバイダーパケットロスを計算する方法は、簡単にできても、すぐにISPにすべての責任を負わせることができないことを意味します。 パケットロスに寄与するソケットとISPルーターの間に機器があるか、ISPの制御外のPoPに近いネットワークパスに問題がある可能性があります。
2. 破棄されたCato
発生するのは、Cato QoSが意図的にパケットをドロップする時です。 QoSエンジンは、以下の時に低優先度のパケットを破棄し始めます:
輻輳は、リンク全体の合計スループットがリンクの設定された帯域幅と一致する場合に発生します。
Catoはまた、厳格なスループット制限を持つ帯域管理優先度が設定されており、その優先度に一致するトラフィックが制限に達した場合、パケットを破棄します。
バーストの間（高優先度のキューでもパケットをドロップする可能性があります）。
破棄されたCatoのパケットロスは予想される動作であり、必ずしも問題の兆候ではありません。
Catoがパケットロスを破棄した場合も、問題の原因は設定ミスに起因している可能性が高いです。 VoIPのような重要なアプリケーションには、最も高い帯域管理優先度を与えるべきです。 輻輳が発生した場合、Catoは低優先度のトラフィックをドロップしますが、高優先度のトラフィックはドロップしません。 適切な帯域管理優先度をトラフィックに割り当てることを常に確認してください。
アナリティクスは、パケットロスの広範なビューを提供します。 ただし、Catoの破棄されたパケットロスを扱わない限り、アナリティクスだけではその原因や発生場所を特定できません。
パケットロスをトラブルシューティングする方法
1. パケットロスの範囲を特定する
開始する際、誰かまたは何かがパケットロスを経験しているのを見つけることが重要です。
すべてのユーザーがサイトでパケットロスを経験しているのか、それとも単一のエンドポイントに限られているのか？
パケットロスはインターネット上で発生しているのか、WAN上で発生しているのか？
複数のサイトがパケットロスの影響を受けているのか、それとも一つだけか？
すべてのトラフィックが影響を受けているのか、それとも特定のアプリケーションだけが影響を受けているのか？
パケットロスは常に存在しているのか、それとも断続的にしか発生しないのか？
上記の質問に対する回答を知っていることは、関連情報を特定し、トラブルシューティングのプロセス中に時間を節約するのに役立ちます。 事前に知っている詳細が多ければ多いほど、トラブルシューティングがより効率的になります。
2. サイトのアナリティクス - パケットロスグラフのチェック
サイトのアナリティクスパケットロスグラフにパケットロスが表示されていますか？ パケットロスと破棄されたパケットを示す可能性のあるアナリストグラフに基づいて、異なる推奨事項があります。
パケットロスなし
アナリティクススクリーンにパケットロスが表示されないまま、パケットロスが存在する可能性があります。 ローカルネットワークに問題があるか、PoP関連の問題である可能性があります。 ソケットからLAN側IPにpingを実行するネットワークツールを使用することは、根本原因を特定する良い方法です。
パケットロス
グラフでパケットロスが表示されている場合、その原因は帯域幅設定ミスによる可能性があります。 以下の構成を確認してください帯域幅設定のチェック。
プロバイダーパケットロスについては、トラフィックのスパイク（バースト）が発生した時のみドロップが存在するか確認します。 その場合は、使用しているトラフィックの詳しい分析を行い、アプリケーションアナリティクスページで原因を特定してください。 アプリケーショントラフィックを制限するために、制限的な帯域幅管理プロファイルに割り当てることができます。
しばしば、スループットが全体的に低い場合でも、バーストスパイクがパケットロスを引き起こすケースを目にします。 ISPとCatoのトラフィック整形ポリシーが異なる可能性があるため、ISP独自のトラフィック整形ポリシーがあることを考慮する必要があります。 バーストに関する詳細は、以下のマイクロバーストのチェックを参照してください。
3. サイトのアナリティクス - 破棄されたパケットグラフ
破棄されたCatoのパケットについては、帯域幅優先度を調査する必要があります。 サイトのアナリティクス画面下でプライオリティアナライザーをチェックして、どの優先度が落ちているかを確認してください。 優先段階を拡大して、その優先度内での上位アプリケーションを表示することができます。 特定のアプリケーションにのみパケットロスの影響がある場合、ネットワークルールでそのアプリケーションの優先度を上げる必要があるかもしれません。 Cono QoSは輻輳が発生した場合に低優先度のパケットをドロップするように設計されているため、破棄されたCatoのパケットロスは必ずしも問題ではありません。
Cato QoSは、優先度に関係なく、キュー内のバーストによってすべてのパケットを破棄することもあります。 この動作はバースト管理の特性によるものであるため、予想されます。 プライオリティアナライザーページを使用して、パケットが破棄されたときにトラフィックのバーストが発生しているかどうかを確認できます。 詳細はSocket トラフィックの優先順位付けとQoSを参照してください。
アナリティクス画面にあるプライオリティアナライザーは、各QoS優先度についての上流および下流ディレクションでのパケットロスを示します。
4. サイトのアナリティクス - ラストマイルパケットロスの確認
ISPが問題を経験しているかどうかを評価するには、アナリティクス画面のラストマイルタブを使用して、WANリンクに表示されるレイテンシーの変化やパケットロスを確認してください。 プロバイダーのパケットロスとは異なり、ラストマイルデータは人気のあるウェブサイトへのICMPテストに基づいています。 推奨として、ping可能な追加のサービスIPをラストマイルモニタリングページに追加できます。 例えば、VoIPに関連した問題がある場合、SIPサーバーのIPを一つのIPとして設定できます。
ISP関連のパケットロスが疑われる場合は、ISPに次の質問をしてください：
UDP/443またはUDP/1337（DTLS）トラフィックでQoSを適用していますか？
PoP IPへのパケットロスを引き起こす可能性のあるUDPトラフィックへのDoS保護を適用していますか？
PoP IPへのパスにおいて、ルーターで輻輳または高CPU使用率がありますか？
加入したライン速度を超えるバーストを許可していますか？
5. (オプション) ラストマイルの監視体験
体験モニタリングライセンスを持つ顧客は、ラストマイルおよびアプリケーションパフォーマンスタブを確認できます。 データはサイトネットワークアナリティクスページの所見と相関させて、問題の発生場所をよりよく理解することができます。
6. DTLSポートUDP/443の変更
いくつかのISPはUDP/443に対してトラフィック整形またはQoSを適用する可能性があります。 これによりリンクが安定しているにもかかわらず、パケットロスが発生することがあります。
ソケット構成で、DTLSトンネルポートを 443 から 1337 に変更します。
変更を適用した後、アナリティクス画面でパケットロスとレイテンシーを監視してください。
パケットロスが改善した場合、ISPがUDP/443トラフィックを整形していることを確認します。 その場合、トンネルを1337のままにしておくか、ISPに問題をエスカレーションします。
7. 帯域幅設定の確認
パケットロスはリンクの輻輳によって引き起こされる可能性があり、各WANリンクの帯域幅がCato管理アプリケーションで正しく設定されていることが重要です。 設定された帯域幅が、サイト設定で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はランダムにパケットをドロップし始める可能性があります。 その場合、プロバイダーのパケットロスとともに、構成された帯域幅のレベルを下回るサイトアナリティクス スループット グラフ全体にフラットラインとして表示されます。
各ソケットモデルごとのソケットスループットと容量情報は、ソケットデータシートにあります。この資料をご覧ください:X1700、X1600 & X1500 ソケットガイド。
8. ソケット CPUパフォーマンスのチェック
CMAのネットワークアナリティクスから、ハードウェアタブを選択します。 このセクションには、各コアの履歴的なCPU使用率が表示されます。
CPU使用率が一貫して90%を超えると、ソケットパフォーマンスに悪影響を及ぼし、パケットロスや高いレイテンシーを引き起こす可能性があります。 常に高いCPU使用率が観察される場合は、アカウント代表者に連絡してハードウェアの交換（例: X1500からX1600への移行）の可能性を評価してください。
さらなるトラブルシューティングについてはサポートに連絡する
リアルタイムのソケットCPU使用率は、Socket WebUIのHWステータスタブで確認できます。 アクティブな使用状況を履歴データと比較して、パフォーマンスのトレンドを特定します。
9. サイト再接続を排除する
サイトがCatoクラウドに再接続することは、パケットロスの原因となります。 パケットロスが再接続イベントと関連しているかどうかを確認するには、ホーム > イベントを確認します。 イベントを「再接続」としてフィルタリングします。
再接続イベントには接続解除の理由を説明するメッセージが表示されます。 再接続イベントの理解を参照してください。
10. Catoのバイパス
インターネットでのパケットロスの場合、バイパスを設定して、Catoクラウドの問題を迅速に排除します。 これを行う最も簡単な方法は、サイトの設定で単一ユーザーのIPアドレスに対してソースバイパスを設定し、パケットロスが継続するかどうかを確認することです。 パケットロスが続く場合、問題はLAN、ソケット、またはISPにある可能性がありますが、PoPに関連する問題ではありません。
11. Pingテストの実行
パケットロスが発生しているソースと宛先のIPアドレス間で継続的なpingを開始します。 pingはトレースが簡単で、パケットキャプチャで分析できます。 ping要求の一部が宛先に到達しない場合、パケットロスが発生している可能性があり、要求タイムアウトとして表示されます。
注意: パケットキャプチャはCPUリソースを大量に消費するため、パフォーマンスの低下を引き起こす可能性があります。 トラブルシューティングを行っていない限り、パケットキャプチャを無効にするようにしてください。
ソケットUIでホスト名またはIPでpingを送信することもできます pingツールを使用して。 pingの送信先インターフェースを選択することができ、Cato経由またはWANリンク経由で直接行うことができます。 ping結果の不整合を確認し、パケットロスや 高い遅延があるかどうか確認します。 Catoの有無に関わらずパケットロスが発生している場合、ISPの問題を示している可能性があります。 また、リンクが4G/LTE の場合、これらのリンクはパケットロスに対してより敏感であることを覚えておいてください。
UIは10回のping要求のみを送信するので、より多くのpingが必要な場合はPing ボタンを再度クリックしてください。
注意: pingテストは基本的なネットワークの健康状態を確認するためには良いですが、pingのドロップがなくてもクリーンなラインを示すわけではありません。
12. Tracerouteテストの実行
Tracerouteはソースと宛先の間のルーター（ホップ）を識別するために使用されます。 各ホップでのパケットロスと遅延が表示されます。
TracerouteはソケットUIのツールで実行できます Tracerouteツール。 ソケットと宛先の間のWANリンクのどのホップでもパケットロスや予期しない高い遅延を探すためにTracerouteを実行します。 テストを実行し、パケットロスを検証する際には、最大カウント（200）と最低間隔（0.1）を設定することを推奨します。
Traceroute結果の分析
どの単一のホップでも表示されるパケットロスが問題の兆候であるとは限りません。 ICMPがルーターで有効になっていないため、一つのホップで100%のパケットロスが表示されることがあります。 ホップがICMPのレート制限のために問題なく100％未満のパケットロスを表示することもあります。 あるホップでいくつかのパケットロスが見られ、次のホップで0％のパケットロスが見られる場合、おそらくICMPのレート制限に遭遇しているでしょう。
パケットロスに実際の問題がある場合、それは一つのホップから始まり、複数のホップに亘って続き、各ホップはパケットロスを示します。 パス上の複数のルーターがパケットロスに寄与している場合もあり、ホップごとにパケットロスの量が異なることがあります。 例えば、ルート上に八つのホップがあり、Tracerouteはホップ3-7でパケットロスを示します。
13. Speedtestでリンクをテスト
リアルタイム画面で現在のスループットの変化を確認し、即座にパケットロスと破棄されたパケットを特定できます。 トラブルシューティング時にはソケットのspeedtestツールで高負荷をシミュレートし、需要が高いために発生するパケットロスを再現します。
ソケットSpeedtest結果は、Cato管理アプリケーションでのリンクに設定された帯域幅に近いことが期待されます。 しかし、DTLSトンネルのオーバーヘッド（117バイト）によりスループットがわずかに低下する可能性があります。
テストはリンクを飽和させ、ネットワークアナリティクス画面にISP関連のパケットロスを表示します。 設定されたリンク帯域幅がISP提供の帯域幅よりも低い場合、テスト中にパケットが破棄されることが予想されます。
ダイレクトSpeedtest
SpeedtestをWANポート経由で直接実行すると、上り結果がCato管理アプリケーションで設定された帯域幅ライセンスに近いはずです。 ソケットはサイトの帯域幅ライセンスに従って上りダイレクトSpeedtestでもQoSを使用します。 一方で、下り結果はローカルISPの完全な容量を示します。
14. iPerfでリンクをテスト
ソケットWebUIを使ってiPerfツールでソケットとCatoクラウド内の接続されたPoP間のラストマイルパフォーマンスの問題をトラブルシューティングします。 ソケットがiPerfクライアントを実行し、接続されたPoPで実行中のiPerfサーバーに対してテストを行います。
Cato経由およびソケットUIのツールページのWAN経由で直接iPerfテストを実行します。 プロトコルとしてUDPを選択し（TCPフロー制御を排除するため）、方向（上りまたは下り）を設定し、ターゲットレートを設定された帯域幅として設定します。 このツールは、CatoとWAN経由のスループットが予想通りであることをよりよく確認できます。 DTLSトンネルのオーバーヘッド（117バイト）によりスループットがわずかに低下する可能性があることに注意してください。
以下の例では、45Mbpsをターゲットレートとして設定しています（これはCato管理アプリケーションで設定されている同じBWです）受信レートが期待より低く、パケットロスが3.7％という状況です。
15. リンクアグリゲーション（LAG）リンクの確認
パケットロスや高遅延は、ソケットと内部スイッチとの間のリンクアグリゲーション（LAG）設定ミスによって引き起こされる可能性があります。 この特定の問題はネットワークアナリティクスでは検出できず、むしろLAN内でトラブルシュートする必要があります。 Catoは静的LAGのみをサポートしており、LAGピアは同じモードをサポートする必要があります。 LAG設定の不一致はパケットロスを引き起こします。
詳しいトラブルシューティング情報については、リンクアグリゲーション（LAG）リンクの高い遅延とパケットロスの経験 を参照してください。
16. ソケットのリンク速度の確認
プロバイダの損失の一つの可能性の原因はソケットリンクが半二重で動作していることです。 これは、パケットが一度に一つの方向（送信または受信）にしか移動できないことを意味し、スループットが大幅に低下し、パケットロスの原因になります。 すべてのソケットリンクは例外なく常に全二重であるべきです。
また、WANおよびLANリンク速度がサイトに設定されている帯域幅以上であることを必ず確認してください。 リンク速度はスループットの制限要因となる可能性があります。 例えば、サイトの設定された帯域幅が200 Mbpsであるのに対して、LANリンクが100 Mbps全二重でしか交渉されていない場合、ソケットに接続されたコンピュータは100 Mbpsを超えるスループットを達成できません。
リンク状態を確認するには、ソケットUIにログインしてモニタページでリンクステータスを表示します。 以下の例では、100 Mbpsの半二重でWAN1リンクが示されています。
もしリンクが半二重であるか、間違った速度に設定されていることに気付いた場合、ソケットのリンクが接続されているデバイスのポート設定を確認してください。 それが自動ネゴシエートに設定されているか、ソケットの速度設定と一致していることを確認してください。 すべてのソケットリンクはデフォルトで自動ネゴシエートに設定されていますが、ネットワーク設定ページで速度を強制することができます。
他のデバイスでポート設定が正しい場合、イーサネットケーブルが損傷している可能性があります。 既知の良好なケーブルと交換し、このデュプレックスまたは速度が変更されるか確認してください。 それでも解決しない場合は、ソケットのポートにノートPCやその他のデバイスを接続し、リンクステータスを確認します。 他のデバイスでも同じことを行います。 ソケットのリンクが期待される速度で全二重でアップするが他のデバイスのリンクがしない場合、問題は他のデバイスにあります。
17. 重複IPの確認
ソケットレベルでパケットロスを引き起こす可能性のあるもう一つの問題はネットワーク内の重複IPです。 ソケットは通常、設定されたインターフェースIPアドレスでIPの競合を検出することができます。 同じネットワーク上の二台のデバイスに同じIPアドレスが割り当てられた場合、IP競合が存在します。 この場合、ソケットUIのモニタページに次のエラーが表示されます。
重複IPがWANインターフェースで静的IPアドレスが設定されている場合、ソケットがIP競合のためにパッシブモニタリングするだけなので、検出されない可能性があります。 ソケットが競合するIPを持つデバイスからのARPを受信した場合にのみIP競合を検出します。
競合IP問題が解決されたら、警告がWebUIから消えるまで最大24時間かかることがあります。 解決後もソケットUIに報告されたIPアドレスの競合を参照してください。
18. マイクロバーストの確認
別のパケットロスの潜在的原因はマイクロバースト（バースト性）です。 マイクロバーストは、通常、わずかに数マイクロ秒からミリ秒間の非常に短い時間枠内で発生するパケットまたはデータフレームの突然の急増として特徴付けられます。 マイクロバーストが発生し、リンクのレート制限を超えると、ラストマイルプロバイダー（ISP）は過剰なトラフィックをドロップすることがあり、これによりパケットロスが生じます。
以下のグラフで、マイクロバーストによって引き起こされた典型的なパケットロスの例と、バースト性値設定を調整した後の改善を見ることができます。
上記の例で、バースト性レベルの値はデフォルト値の0.2から0.01に変更され、ソケットとPoPがトラフィックにより積極的なシェーピングを適用し、パケットロスの問題を解決します。
パケットロスを緩和するためのバースト性レベル設定の調整
デフォルトのバースト性値は上りと下りの方向に適用され、0.2です。 この値で、ソケットとPoPはパケットを可能な限り速くメディアにシリアル化し、時間枠バケットの最初のマイクロ秒に送信されるバイト数を増やします。 この設定は直列化遅延と全体的な遅延を削減することによってパフォーマンスを最適化します。
このトラブルシューティング手順として、バースト性レベルを徐々に減らしてパケットロスが緩和されるまで必要です。 バースト性レベルの値を削減すると、ソケットとPoPはトラフィックに対してより積極的なシェーピングを適用し、したがってマイクロバーストを平滑化します。 設定可能な最低値は0.001です。
バースト性レベルを調整するベストプラクティスは、値を徐々に（例：0.2から0.18）減らすことです。値を減らした後、サイト監視のリアルタイムまたはネットワークアナリティクス画面でパケットロスを分析して影響をモニタリングします。 サイトメトリックは通常、更新されるまでに数分かかることを念頭に置いてください。 バースト性を減らし続けてパケットロスが緩和されるまで続けます。
この手順でもパケットロスが解決されない場合、マイクロバーストとは異なる原因であることを意味します。この場合、デフォルトのバースト性値0.2に戻し、サポートに連絡を依頼して追加の支援を求めてください。
バースト性レベルの修正
バースト性レベルは上りと下りの方向に応じて調整できます。 この設定はすべてのサイトのWANリンクに影響します。
設定はサイトレベルまたはアカウントレベルで適用されます。 サイトレベルの構成はアカウントレベルよりも優先されます。
バースト性レベルを設定する：
ナビゲーションメニューから リソース > 高度な設定 > アカウントレベル または サイト設定 > 高度な設定 を選択します。
バースト性下り値かバースト性上り値を選択します。
設定を有効にし、値を0.001から0.2の範囲で調整します。
適用をクリック
保存をクリック
注意事項:
以前にCatoサポートによってバースト性が調整された場合、調整された値がデフォルトの0.2ではなく表示されます
バースト性の値はソケットサイトのみに調整可能です
Cato管理アプリケーションの最小データバケットは5秒で、マイクロバーストは最小データバケット内で正規化されるため、特定が困難です。
帯域幅が10Mbpsおよびそれ以下のサイトではバースト性の値を0.001に設定することは推奨されません。サイトの接続性の問題を引き起こす可能性があります。