概要
アルタナティブWAN (Alt.)。 WAN)は、柔軟で耐障害性のあるWANトラフィック管理ソリューションを提供することにより、組織がネットワーク接続性を向上させることを可能にします。 それは、同じサブネット上のソケット用のLayer-2および異なるネットワーク上のソケット用のLayer-3のタイプの設定をサポートします。 展開の詳細については、Integrating-Cato-with-Alternative-WAN-Networkを参照してください。
この記事は、Alt.に関する一般的な問題をカバーしています。 WANに共通する問題をカバーし、それらを解決するためのトラブルシューティングステップを提供します。
症状
ここにAlt.のときの一般的な症状があります。 WANが期待どおりに機能しないときの一般的な症状を以下に示します:
Alt.について。 WAN接続が確立されません
CMAはサイトを切断として表示しますが、Altを介してトラフィックが流れています。 WAN
Altを使用しているときにサーバーによってTLS接続がリセットされます。 WAN
AltへのWANリカバリー。 WANはプライマリトンネルがダウンしたときに失敗しました
BGP接続がAlt.を介して確立されませんでした。 WAN
考えられる原因
設定ミス
UDP/20049がAltの間でブロックされています。 WANサイト
高いソケットCPU
問題のトラブルシューティング
アルタナティブWANトンネルが確立されない
設定を確認
正しい設定を確保するために、アルタナティブWANが有効なソケットサイトに移動します。 ネットワーク > サイト > ソケット に移動し、アルタナティブWANインターフェースのポートステータスがUPとして表示されていることを確認します。
ステータスがダウンと表示されている場合は、ネットワークに正しく接続されているかを確認するためにポート接続を確認してください。

インタフェースが正しいオプションで構成されていることを確認します。—アルタナティブWAN(Layer-2)またはアルタナティブWAN(Layer-3)。

次に、IPアドレスとサブネット設定が正しく設定されていることを確認してください。

アルタナティブWANトンネルがアクティブかどうかを確認するために、ソケットWebUIを使用してソケットにアクセスします。 アルタナティブWANトンネルが正常に確立されると、SDWANトンネルの下で接続されたチャネルの数が表示されます。
.

UDPポート20049がブロックされていないことを確認します
アルタナティブWANトンネルはUDP/20049で確立されます。
両方のソケットのSocketUIにアクセスし、トラフィックキャプチャタブに移動します。
Alt.用に設定されているWANインターフェースを選択し、UDPプロトコルのキャプチャを開始します。 WANは設定され、UDPプロトコルのキャプチャを開始します。

PCAPは、UDPポート20049上の双方向トラフィックを表示するはずです。 双方向のフローが見られない場合は、2つのサイト間のいずれかのデバイスがUDP/20049をブロックしているかどうか確認してください。
注意: アルタナティブWAN Layer 2設定では、トンネルはアルタナティブWAN IPを使用して開始されます。 対照的に、アルタナティブWAN Layer 3設定では、トンネルは特定のサブネットのローカルIPを使用して開始されます。 以下の表は、Layer 2とLayer 3設定の間のトラフィックフローの違いを強調しており、具体的にはトンネルの送信元IPに焦点を当てています。 レイヤー2
レイヤー3

アルタナティブWANトンネルは、アルタナティブWAN IPから起動します。 アルタナティブWANインタフェースからのパケットキャプチャは、トンネルがIPアドレス192.168.20.2から始まり、リモートサイトのアルタナティブWAN IP 192.168.20.3および192.168.20.4との接続を確立したことを示します。


Socket UIには、192.168.20.2として設定されていますが、トンネルはこのIPから始まりません。 アルタナティブWANインタフェースからのパケットキャプチャは、トンネルが192.168.2.1から開始され、アルタナティブWAN用に設定されたリモートサイトのネイティブローカルIP 192.168.3.1および192.168.4.1と接続を確立したことを示します。

CMAでのサイトはAltによるトラフィックが流れているにもかかわらず、切断されています。 WAN
CMAでサイトが切断されているように見えるのは、Cato Cloudへのトンネルがダウンしているからです。
トラフィックはAlt.を通して流れ続けます。 WANリンクはネットワークの操作を確保しますが、CMAはそのサイトをオフラインとして登録します。
CMAの可視性を回復するには、Cato Cloudへのトンネル接続をトラブルシューティングして再確立します。 詳細なトラブルシューティング手順については、Socket-Site-Tunnel-Connectivity-Troubleshootingを参照してください。
Alt.でのTLS接続失敗。 WANリンクにおけるTLS接続の失敗
ネットワールールが、Alt.を使用するように明示的に設定されました。 WANをプライマリトランスポートとして使用するように明示的に設定されました。

Socket UIで確認すると、Alt.がわかります。 WANトンネルはアップしています。

一方で、サーバーはAltを経由してトラバースするときにTLSアプリケーションを常にリセットします。 WAN。
このシナリオでは、Altの上位に複雑なネットワールールが存在しないことを確認することが重要です。 WANルールは、ネットワーク内で複雑なルールがどのように処理されるかによるものです。 Socketが直接評価できないネットワールールを複雑とする。 したがって、Alt.の上に複雑なルールが現れると。 WANルールがあると、Socketは適切なネットワーク処理を決定するためにトラフィックをPoPに送信します。
このプロセスはAltを経由してリターントラフィックがトラバースするときに非対称のフローを引き起こす可能性があります。 WANリンクが接続をリセットするサーバーを引き起こします。
この複雑なルールの詳細については、「複雑なネットワークルールを使用することの解説」セクションの下で、Explaining-the-Cato-TCP-Acceleration-and-Best-Practicesを参照してください
この問題の解決方法については、ソリューションTLS接続失敗に関するAlt.を参照してください。 WANリンクを参照してください。
WANのリカバリーがAlt.に対して発生しませんでした。 WANのリカバリーはプライマリトンネルがダウンしたときに発生しませんでした
デフォルトでは、Alt.のWANリカバリーは有効になっていません。 WAN。 これは限定された機能とみなされており、このオプションを選択したい場合、Catoの担当者にリクエストを送信することで利用できます。
詳細についてはRecovering-Connectivity-with-Alt-WAN-Linksを参照してください。
BGP接続の確立の失敗
BGPピアリングは、顧客のBGPルータとSocket間でAlt.を介して設定されました。 WANリンクですが、BGP接続が確立されません。
このケースでは、Alt.です。 Socket上のWAN設定は次のとおりです:

BGPルータのログは、指定されたネクストホップが無効であることを示しています。 考えられる一つの理由は、BGPアップデートで通告されたネクストホップがBGPピア経由では到達不可能なことです。
%BGP-5-ADJCHANGE: neighbor 192.168.200.1 Up %BGP-3-NOTIFICATION: received from neighbor 192.168.200.1 3/8 (invalid next hop specified) 4 bytes 0AFD0011潜在的な解決策は、BGP設定でnext-hop-selfコマンドを使用することです。 このコマンドは、ルータが自らをルートのネクストホップとして通告し、次のルートのネクストホップIPアドレスが受信側のBGPピアに対して到達可能であることを保証します。
詳細については「BGP接続の確立失敗に関するソリューション」をご覧ください。
Socket CPUパフォーマンスの確認
90%以上の一定したCPU使用率は、ソケットパフォーマンスに悪影響を与え、パケットロスとトンネルの確立失敗または頻繁な切断を引き起こす可能性があります。
各コアごとの過去のCPU使用率を表示するには、ネットワークアナリティクスにアクセスし、ハードウェアタブを選択します。

リアルタイムのSocket CPU使用率を表示するには、Socket WebUIに移動し、HWステータスタブを選択してください。

検出されたCPUが常に高い場合はサポートにお問い合わせください。
発見された問題の解決
Alt.でのTLS接続失敗の解決方法。 WANリンクでのTLS接続失敗に対するソリューション
Off-CloudまたはAlt-WANリンクを使用する場合、2つのCatoサイト間のTLS接続が失敗し、定義されたアプリケーションを含む複雑なルールの下に単純なネットワークルールが配置されると失敗することがあります。
これは、TCPプロキシが強制され、TCPハンドシェイクがCato Cloudを通過しながらデータパケットがAlt.を経由してトラバースするために発生します。 WANにより接続がリセットされます。
解決策は、単純なOff-CloudまたはAlt-WANルールを複雑なルールの上に移動するか、あるいはTCPプロキシ強制を避けるためにTLSインスペクションを無効にすることです。
この問題の詳細については、TLS-Connection-Failure-Over-Off-Cloud-or-Alt-WAN-Linksを参照してください
BGP接続の確立失敗に対するソリューション
顧客は、そのBGPルータでデフォルトルートのネクストホップが正しく設定されていることを確認する必要があります。 顧客のルータ上で、次のオプションのいずれかを使用してデフォルトルートを構成します:
次のコマンドを使用して、ネクストホップをBGPピアの代替WAN IPとして設定します:
neighbor <Socket Alternate WAN IP> next-hop-selfルータの代替WANインターフェースIPにネクストホップを明示的に設定するためにルートマップを適用します:
route-map <map-name> permit 10 set ip next-hop <Router Alternate WAN Interface IP>
制限/注釈
Alt.のとき。 WANがHAサイトに設定されているときは、Alt.です。 WANトンネルはマスターソケットとのみ確立されます。 したがって、通常の条件下ではマスターソケットだけがAlt.を確立します。 リモートサイトとのWANトンネルを確立します。