LTM スペシャリストは、SSL トラフィックを単に通過させるのではなく、LTM デバイスでオフロードすることを決定します。LTM スペシャリストは、構成をパフォーマンス (レイヤー 40 仮想サーバー) から SSL オフロードを備えた標準仮想サーバーに変更する必要があります。
LTM スペシャリストがこのタスクを遂行する際に考慮する 2 つの要素はどれですか? （2つ選んでください。）

- 示す -

- 示す -
展示を参照してください。
LTM スペシャリストが、LTM デバイスで構成されたアプリケーションの問題をトラブルシューティングしています。サーバー経由で直接アクセスすると、アプリケーションは正常に動作します。ただし、LTM デバイス経由でアクセスした場合は機能しません。仮想サーバー 192.168.1.211:443 は、アドレスを使用して SNAT に構成されています。
192.168.1.144 であり、メンバー 192.168.10.80:443 を持つプールを参照します。仮想サーバーには、クライアントまたはサーバーの SSL プロファイルが関連付けられていません。
アプリケーションが仮想サーバーを介して機能できるようにするための構成変更はどれですか?

ユーザーはアプリケーションにアクセスできません。BIG-IP 管理者が構成ユーティリティを確認すると、仮想サーバーのステータスの前に赤いひし形が表示されていることがわかります。この問題の原因は何ですか?

新しい HITP サーバーが LTM デバイスにデプロイされました。サーバー上で実行されているアプリケーションは、LIM デバイスによって監視する必要があります。以下が必要です。
新しい HITP サーバーが LTM デバイスにデプロイされました。サーバー上で実行されているアプリケーションは、LIM デバイスによって監視する必要があります。以下が必要です。
サーバーが利用できない場合、ステータス HTML ページのリクエストに応答して HTTP ステータス コード 200 を送信します。
サーバーが利用可能な場合。ステータスhtmlページのリクエストに対してHTTPステータスコード201を送信します。
200 ステータス コードを受信すると、プール メンバーは新しい接続なしを受信する必要があります。
これらの要件を満たすには、どの構成変更を行う必要がありますか?

LTM デバイスは、クライアントの送信元 IP アドレスに基づいてアクセス制御リスト (ACL) を実装する一連の Web サーバーに負荷分散を提供するように構成されています。ACL はネットワーク レベルであり、Web サーバーは、接続が許可されていない場合にクライアントに TCP リセットを送信するように構成されています。
仮想サーバーは、デフォルトの OneConnect プロファイルで構成されています。
ACL は Web サーバーで次のように定義されます。
許可: 192.168.136.0/24
拒否: 192.168.116.0/24
パケット キャプチャは、IP アドレス 192.168.136.100 の仮想サーバーへの 2 つの個別のクライアント フローから取得されます。
クライアント A - ソース IP 192.168.136.1 - 仮想サーバー 192.168.136.100:
クライアント側：
09:35:11.073623 IP 192.168.136.1.55684 > 192.168.136.100.80: S 869998901:869998901(0) 勝利 8192 <mss
1460,いいえ,wscale 2,いいえ,いいえ,sackOK>
09:35:11.073931 IP 192.168.136.100.80 > 192.168.136.1.55684: S 2273668949:2273668949(0) ack
869998902 win 4380 <mss 1460,nop,wscale 0,sackOK,eol>
09:35:11.074928 IP 192.168.136.1.55684 > 192.168.136.100.80: . 1 勝 16425
09:35:11.080936 IP 192.168.136.1.55684 > 192.168.136.100.80: P 1:299(298) ack 1 勝 16425
09:35:11.081029 IP 192.168.136.100.80 > 192.168.136.1.55684: . ack 299 win 4678 サーバー側:
09:35:11.081022 IP 192.168.136.1.55684 > 192.168.116.128.80: S 685865802:685865802(0) 勝利 4380 <mss
1460,nop,wscale 0,sackOK,eol>
09:35:11.081928 IP 192.168.116.128.80 > 192.168.136.1.55684: S 4193259095:4193259095(0) ack
685865803 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
09:35:11.081943 IP 192.168.136.1.55684 > 192.168.116.128.80: . 1 勝 4380
09:35:11.081955 IP 192.168.136.1.55684 > 192.168.116.128.80: P 1:299(298) ack 1 勝 4380
09:35:11.083765 IP 192.168.116.128.80 > 192.168.136.1.55684: . ack 299 win 108 クライアント B - ソース IP 192.168.116.1 - 仮想サーバー 192.168.136.100:
クライアント側：
09:36:11.244040 IP 192.168.116.1.55769 > 192.168.136.100.80: S 3320618938:3320618938(0) 8192 を獲得
<mss 1460,nop,wscale 2,nop,nop,sackOK>
09:36:11.244152 IP 192.168.136.100.80 > 192.168.116.1.55769: S 3878120666:3878120666(0) ack
3320618939 win 4380 <mss 1460,nop,wscale 0,sackOK,eol>
09:36:11.244839 IP 192.168.116.1.55769 > 192.168.136.100.80: . 1 勝 16425
09:36:11.245830 IP 192.168.116.1.55769 > 192.168.136.100.80: P 1:299(298) ack 1 勝 16425
09:36:11.245922 IP 192.168.136.100.80 > 192.168.116.1.55769: . ack 299 win 4678 サーバー側:
09:36:11.245940 IP 192.168.136.1.55684 > 192.168.116.128.80: P 599:897(298) ack 4525 勝利 8904
09:36:11.247847 IP 192.168.116.128.80 > 192.168.136.1.55684: P 4525:5001(476) ack 897 win 142 2 番目のクライアント フローが Web サーバーによって許可されたのはなぜですか?