The LTM Specialist is writing a custom HTTP monitor for a web application and has viewed the content by accessing the site directly via their browser. The monitor continually fails. The monitor configuration is:
ltm monitor http /Common/exampleComMonitor {
defaults-from /Common/http
destination *:*
interval 5
recv "Recent Searches"
send "GET /app/feed/current\?uid=20145 HTTP/1.1\\r\\nHost:
www.example.com\\r\\nAccept-EncodinG.gzip, deflate\\r\\nConnection: close\\r\\n\\r\\n"
time-until-up 0
timeout 16
}
A trace shows the following request and response:
Request:
GET /app/feed/current?uid=20145 HTTP/1.1
Host www.example.com
Accept-Encoding gzip, deflate
Connection: close
Response: HTTP/1.1 302 Moved Temporarily Date Wed, 17 Oct 2012 18:45:52 GMT Server Apache Location https://example.com/login.jsp Content-Encoding gzip Content-Type text/html;charset=UTF-8 Set-CookiE.JSESSIONID=261EFFBDA8EC3036FBCC22D991AC6835;
Path=/app/feed/current?uid=20145
What is the problem?

• A.The request includes an Accept-Encoding so the server is responding with a gzipped result and LTM monitors CANNOT handle gzipped responses.
• B.The HTTP monitor does NOT support monitoring jsp pages.
• C.The request does NOT include any cookies and the application is expecting a session cookie.
• D.The request does NOT include a User-Agent header.

Comment: *

Name: *

Email: *

Verification: *

-- Exhibit -


-- Exhibit -
Refer to the exhibits.
When observing the AVR statistics for the HTTPS_VS, an LTM Specialist realizes that HTTP status codes are NOT being recorded.
How should the LTM Specialist modify the configuration to record the HTTP status codes?

• A.enable Collected Entities, Response Codes on the analytics profile
• B.enable Statistics Logging Type, External on the analytics profile
• C.assign client SSL and server SSL profiles to the virtual server
• D.assign a streaming profile to the virtual server

Comment: *

Name: *

Email: *

Verification: *

-- Exhibit -

-- Exhibit -
Refer to the exhibit.
A company uses a complex piece of client software that connects to one or more virtual servers (VS) hosted on an LTM device. The client software is experiencing issues. An LTM Specialist must determine the cause of the problem. The LTM Specialist has the tcpdump extract. The client loses connection with the LTM device.
Where is the reset originating?

• A.the device initiating the connection
• B.the local switch
• C.the application server
• D.the destination device of the initial connection

Comment: *

Name: *

Email: *

Verification: *

-- Exhibit- -- Exhibit -

Refer to the exhibit.
Which URL should be reported to the server/application team as getting user-visible errors?

• A./env.cgi
• B./reflector.php
• C./browserspecific.html
• D./page14.cgi

Comment: *

Name: *

Email: *

Verification: *

The LTM device is configured to provide load balancing to a set of web servers that implement access control lists (ACL) based on the source IP address of the client. The ACL is at the network level and the web server is configured to send a TCP reset back to the client if it is NOT permitted to connect.
The virtual server is configured with the default OneConnect profile.
The ACL is defined on the web server as:
Permit: 192.168.136.0/24 Deny: 192.168.116.0/24
The packet capture is taken of two individual client flows to a virtual server with IP address
192.168.136.100.
Client A - Src IP 192.168.136.1 - Virtual Server 192.168.136.100:
Clientside:
09:35:11.073623 IP 192.168.136.1.55684 > 192.168.136.100.80: S 869998901:869998901(0) win
8192 <mss 1460,nop,wscale 2,nop,nop,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: . ack 1 win 16425 09:35:11.080936 IP 192.168.136.1.55684 > 192.168.136.100.80: P 1:299(298) ack 1 win 16425 09:35:11.081029 IP 192.168.136.100.80 > 192.168.136.1.55684: . ack 299 win 4678
Serverside:
09:35:11.081022 IP 192.168.136.1.55684 > 192.168.116.128.80: S 685865802:685865802(0) win
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: . ack 1 win 4380 09:35:11.081955 IP 192.168.136.1.55684 > 192.168.116.128.80: P 1:299(298) ack 1 win 4380 09:35:11.083765 IP 192.168.116.128.80 > 192.168.136.1.55684: . ack 299 win 108
Client B - Src IP 192.168.116.1 - Virtual Server 192.168.136.100:
Clientside:
09:36:11.244040 IP 192.168.116.1.55769 > 192.168.136.100.80: S 3320618938:3320618938(0)
win 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: . ack 1 win 16425 09:36:11.245830 IP 192.168.116.1.55769 > 192.168.136.100.80: P 1:299(298) ack 1 win 16425 09:36:11.245922 IP 192.168.136.100.80 > 192.168.116.1.55769: . ack 299 win 4678
Serverside:
09:36:11.245940 IP 192.168.136.1.55684 > 192.168.116.128.80: P 599:897(298) ack 4525 win 09:36:11.247847 IP 192.168.116.128.80 > 192.168.136.1.55684: P 4525:5001(476) ack 897 win
Why was the second client flow permitted by the web server?

• A.A source address persistence profile is assigned to the virtual server.
• B.The idle TCP session from the first client was re-used.
• C.A global SNAT is defined.
• D.SNAT automap was enabled on the virtual server.

Comment: *

Name: *

Email: *

Verification: *