PrepAway - Latest Free Exam Questions & Answers

Category: 301b

Exam F5 301b : LTM Specialist: Maintain & Troubleshoot

What issue is the LTM Specialist experiencing?

An LTM Specialist is troubleshooting an issue with a new virtual server. When connecting through the
virtual server, clients receive the message “Unable to connect” in the browser, although connections directly
to the pool member show the application is functioning correctly.
The LTM device configuration is:
ltm virtual /Common/vs_https {
destination /Common/10.10.1.110:443
ip-protocol udp
mask 255.255.255.255
pool /Common/pool_https
profiles {
/Common/udp { }
}
translate-address enabled
translate-port enabled
vlans-disabled
}
ltm pool /Common/pool_https {
members {
/Common/172.16.20.1:443 {
address 172.16.20.1
}}}
What issue is the LTM Specialist experiencing?

Which issue is the pool member having?

An LTM Specialist is troubleshooting an HTTP monitor. The pool member is accessible directly through a
browser, but the HTTP monitor is marking the pool member as down.
GET / HTTP/1.1
HTTP/1.1 400 Bad Request
DatE. Tue, 23 Oct 2012 21:39:07 GTM
Server: Apache/2.2.22 (FreeBSD) PHP/5.4.4
mod_ssl/2.2.22 OpenSSL/0.9.8q DAV/2
Content-LengtH. 226
Connection: close
Content-TypE. text/html; charset=iso-8859-1
Which issue is the pool member having?

Why was the second client flow permitted by the web server?

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 theweb 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 8904
09:36:11.247847 IP 192.168.116.128.80 > 192.168.136.1.55684: P 4525:5001(476) ack 897 win 142
Why was the second client flow permitted by the web server?

What is the reason the destination web server is sendin…

A client is attempting to log in to a web application that requires authentication. The following HTTP
headers are sent by the client:
GET /owa/ HTTP/1.1
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
User-Agent: curl/7.26.0
Host: 10.0.0.14
Accept: */*
Accept-EncodinG. gzip,deflate
The web server is responding with the following HTTP headers:
HTTP/1.1 401 Unauthorized
Content-TypE. text/html
Server: Microsoft-IIS/7.5
WWW-AuthenticatE. NTLM
DatE. Wed, 16 Aug 1977 19:12:31 GMT
Content-LengtH. 1293
The client has checked the login credentials and believes the correct details are being entered.
What is the reason the destination web server is sending an HTTP 401 response?

Why is the HTTP web server responding with a HTTP 400 B…

A web developer has created a custom HTTP call to a backend application. The HTTP headers being sent
by the HTTP call are:
GET / HTTP/1.1
User-Agent: MyCustomApp (v1.0)
Accept: text/html
Cache-Control: no-cacheConnection: keep-alive
CookiE. somecookie=1
The backend server is responding with the following:
HTTP/1.1 400 Bad Request
DatE. Wed, 20 Jul 2012 17:22:41 GMT
Connection: close
Why is the HTTP web server responding with a HTTP 400 Bad Request?


Page 13 of 21« First...1112131415...20...Last »