- 示す -

- 示す -
展示を参照してください。
ユーザーは、仮想サーバー経由で安全なアプリケーションにアクセスできません。
問題の原因は何ですか?

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 サーバーによって許可されたのはなぜですか?

- 示す -

- 示す -
展示を参照してください。
仮想サーバーは、次のように LTM デバイスにセットアップされます。
仮想サーバーアドレス 78.24.213.79
デフォルト持続性プロファイル。source_addr、600 秒。
プール名。プール1
プール メンバー: 10.72.250.52:80 および 10.72.250.60:80 (両方とも内部 VLAN 上) 仮想サーバーへの現在の接続がいくつかあり、プール メンバー 10.72.250.52:80 は「無効」状態に設定されています。
内部 VLAN の tcpdump は、10.72.250.52:80 に向かうトラフィックを示しています。
永続テーブルのクエリが実行された後、リクエストが 10.72.250.52 に送信されないようにするために、既存の接続を更新/更新できるのはどれくらいの時間ですか?

LTM HTTP プールには、'GET /test.html' に等しい文字列を送信するモニターが関連付けられています。
サーバー管理者がLTMデバイスにログインせずにプールメンバーサーバーを無効にできるようにするために、LTMスペシャリストが実装できる2つの構成はどれですか? （2つ選んでください。）

フェイルオーバー イベントはログ メッセージに記録されます。
Jan 01 00:00:50 BIG-IP 通知 sod[5855]: 01140029:5: HA proc_running tmm がアクションに失敗し、オフラインになり、リンクがダウンします。
Jan 01 00:00:50 BIG-IP 通知 sod[5855]: 010c0050:5: Sod 要求のリンクがダウンしています。
Jan 01 00:00:50 BIG-IP 通知 sod[5855]: 010c0054:5: トラフィック グループ /Common/traffic-group-1 がオフラインです。
Jan 01 00:00:50 BIG-IP 通知 sod[5855]: 010c003e:5: オフライン
Jan 01 00:00:50 BIG-IP 通知ロガー: /usr/bin/tmipsecd --tmmcount 4 ==> /usr/bin/bigstart stop racoon Jan 01 00:00:50 BIG-IP 情報 lacpd[5502]: 01160016:6: フェールオーバー イベントが検出されました。(オフライン中はスイッチボードのフェールセーフが無効になっています) Jan 01 00:00:51 BIG-IP エラー bcm56xxd[5296]: 012c0010:3: フェールオーバー イベントが検出されました。外部インターフェイスをダウンとしてマークします。bsx.c(3633) 1 月 1 日 00:00:51 BIG-IP 情報 bcm56xxd[5296]: 012c0015:6: リンク: 1.1 は 1 月 1 日 00:00:56 BIG-IP 通知 mcpd[5318]: 0107143c:5 : CMI ピア 10.0.0.3 への接続が削除されました Jan 01 00:00:56 BIG-IP 通知 mcpd[5318]: 0107143a:5: CMI 再接続タイマー: 有効 Jan 01 00:00:56 BIG-IP 通知 mcpd[5318 ]: 01071431:5: CMI ピア 10.0.0.3 ポート 6699 に接続しようとしています。フェイルオーバーの原因は何ですか?