LTM スペシャリストは、デバイスのフェイルオーバーの原因を調査しているときに、次のイベントを発見しました。
/var/log/ltm:
01010029:5: クロックが 518 ティック進みました
01010029:5: クロックが 505 ティック進みました
01010029:5: クロックが 590 ティック進みました
01010029:5: クロックが 568 ティック進みました
01010029:5: クロックが 1681 ティック進みました
01010029:5: クロックが 6584 ティック進みました
01140029:5: HA daemon_heartbeat tmm のアクションはフェイルオーバーと再起動に失敗しました。
010c0026:5: フェイルオーバー状態、アクティブがスタンバイに移行しようとしています。
フェイルオーバーの原因となったのはどの問題ですか?

HTTP モニターが作成され、次のデフォルト以外の構成でプールに割り当てられます。
間隔：7秒
タイムアウト: 22 秒
リバース: はい
送信文字列: GET/status.htmlHTTP/1.1/r/nHost:test.example.com/r/nConnector:Close 受信文字列: Up HTTP サーバーは次の応答を送信します。

結果としてプールのステータスはどうなりますか?

次の iRule コマンドは、同じ iRule で使用されるとどうなりますか?
set hsl [HSL::open -proto UDP -pool syslog_server_pool]
HSL::send $hsl "<190> [HTTP::host] from [whereis [IP::client_addr] 国 大陸 州 都市 zip] 、IP:
[IP::クライアントアドレス]"

- 展示する -

- 展示する -
展示を参照してください。
LTM スペシャリストが、プール上の新しい HTTP モニターのトラブルシューティングを行っています。ブラウザ経由で直接アクセスすると、プール メンバーは正しく機能します。しかし、モニターはメンバーをダウンとしてマークしています。
LTM スペシャリストは、tcpdump 経由で監視トラフィックをキャプチャします。
どうした？

単一サーバーを使用するカスタム TCP アプリケーションが LTM デバイスに移行されます。サーバーがプールに追加されています。このアプリケーションは TCP プロトコル RFC に違反していることが知られています。アプリケーションは現在、ユーザーの観点からはエラーなく動作しています。
この状況ではどの仮想サーバーのタイプが適切ですか?