301b試験無料問題集「F5 LTM Specialist: Maintain & Troubleshoot 認定」
There are three servers in the pool: 172.16.20.1, 172.16.20.2, and 172.16.20.3, with the virtual IP address 10.0.20.88.
A user CANNOT connect to an HTTP application. To understand the problem and find a solution, the LTM Specialist runs two concurrent traces on the LTM device, with the following results:
Trace on client side:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
22:22:07.423759 IP 172.16.20.100.53875 > 10.0.20.88.80: S 998346084:998346084(0)
win 5840 <mss 1460,sackOK,timestamp 67942058 0,nop,wscale 4>
22:22:07.424056 IP 10.0.20.88.80 > 172.16.20.100.53875: S 4671780:4671780(0) ack
998346085 win 4380 <mss 1460,nop,wscale 0,nop,nop,timestamp 2392362490 67942058,sackOK,eol> 22:22:07.424776 IP 172.16.20.100.53875 > 10.0.20.88.80: . ack 1 win 365
<nop,nop,timestamp 67942058 2392362490>
22:22:07.424790 IP 172.16.20.100.53875 > 10.0.20.88.80: P 1:149(148) ack 1 win 365 <nop,nop,timestamp 67942058 2392362490> 22:22:07.424891 IP 10.0.20.88.80 > 172.16.20.100.53875: . ack 149 win 4528
<nop,nop,timestamp 2392362491 67942058>
22:22:12.024850 IP 10.0.20.88.80 > 172.16.20.100.53875: R 1:1(0) ack 149 win 4528
6 packets captured
6 packets received by filter
0 packets dropped by kernel
Trace on server side:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on internal, link-type EN10MB (Ethernet), capture size 96 bytes
22:22:07.424881 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win
4380 <mss 1460,nop,wscale 0,nop,nop,timestamp 2392362491 0,sackOK,eol>
22:22:08.424893 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win 4380 <mss 1460,nop,wscale 0,nop,nop,timestamp 2392363491 0,sackOK,eol>
22:22:09.625082 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win 4380 <mss 1460,nop,wscale 0,nop,nop,timestamp 2392364691 0,sackOK,eol>
22:22:10.825194 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win 4380 <mss 1460,sackOK,eol>
4 packets captured 4 packets received by filter 0 packets dropped by kernel
What should the LTM Specialist do to solve the problem?
A user CANNOT connect to an HTTP application. To understand the problem and find a solution, the LTM Specialist runs two concurrent traces on the LTM device, with the following results:
Trace on client side:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
22:22:07.423759 IP 172.16.20.100.53875 > 10.0.20.88.80: S 998346084:998346084(0)
win 5840 <mss 1460,sackOK,timestamp 67942058 0,nop,wscale 4>
22:22:07.424056 IP 10.0.20.88.80 > 172.16.20.100.53875: S 4671780:4671780(0) ack
998346085 win 4380 <mss 1460,nop,wscale 0,nop,nop,timestamp 2392362490 67942058,sackOK,eol> 22:22:07.424776 IP 172.16.20.100.53875 > 10.0.20.88.80: . ack 1 win 365
<nop,nop,timestamp 67942058 2392362490>
22:22:07.424790 IP 172.16.20.100.53875 > 10.0.20.88.80: P 1:149(148) ack 1 win 365 <nop,nop,timestamp 67942058 2392362490> 22:22:07.424891 IP 10.0.20.88.80 > 172.16.20.100.53875: . ack 149 win 4528
<nop,nop,timestamp 2392362491 67942058>
22:22:12.024850 IP 10.0.20.88.80 > 172.16.20.100.53875: R 1:1(0) ack 149 win 4528
6 packets captured
6 packets received by filter
0 packets dropped by kernel
Trace on server side:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on internal, link-type EN10MB (Ethernet), capture size 96 bytes
22:22:07.424881 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win
4380 <mss 1460,nop,wscale 0,nop,nop,timestamp 2392362491 0,sackOK,eol>
22:22:08.424893 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win 4380 <mss 1460,nop,wscale 0,nop,nop,timestamp 2392363491 0,sackOK,eol>
22:22:09.625082 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win 4380 <mss 1460,nop,wscale 0,nop,nop,timestamp 2392364691 0,sackOK,eol>
22:22:10.825194 IP 172.16.20.100.53875 > 172.16.20.2.80: S 51116678:51116678(0) win 4380 <mss 1460,sackOK,eol>
4 packets captured 4 packets received by filter 0 packets dropped by kernel
What should the LTM Specialist do to solve the problem?
正解:B
解答を投票する
-- Exhibit- -- Exhibit -
Refer to the exhibit.
An LTM Specialist is troubleshooting a new HTTP monitor on a pool. The pool member is functioning correctly when accessed directly through a browser. However, the monitor is marking the member as down. The LTM Specialist captures the monitor traffic via tcpdump.
What is the issue?
Refer to the exhibit.
An LTM Specialist is troubleshooting a new HTTP monitor on a pool. The pool member is functioning correctly when accessed directly through a browser. However, the monitor is marking the member as down. The LTM Specialist captures the monitor traffic via tcpdump.
What is the issue?
正解:D
解答を投票する
An LTM Specialist needs to modify the logging level for tcpdump execution events. Checking the BigDB Key, the following is currently configured:
sys db log.tcpdump.level {
value "Notice"
}
Which command should the LTM Specialist execute on the LTM device to change the
logging level to informational?
sys db log.tcpdump.level {
value "Notice"
}
Which command should the LTM Specialist execute on the LTM device to change the
logging level to informational?
正解:B
解答を投票する
An application is configured on an LTM device:
Virtual server: 10.0.0.1:80 (VLAN vlan301)
SNAT IP: 10.0.0.1
Pool members: 10.0.1.1:8080, 10.0.1.2:8080, 10.0.1.3:8080 (VLAN vlan302)
Which packet capture should the LTM Specialist perform on the LTM device command line interface to capture only client traffic specifically for this virtual server?
Virtual server: 10.0.0.1:80 (VLAN vlan301)
SNAT IP: 10.0.0.1
Pool members: 10.0.1.1:8080, 10.0.1.2:8080, 10.0.1.3:8080 (VLAN vlan302)
Which packet capture should the LTM Specialist perform on the LTM device command line interface to capture only client traffic specifically for this virtual server?
正解:D
解答を投票する
An LTM Specialist is investigating reports from users that SSH connections are being terminated unexpectedly. SSH connections are load balanced through a virtual server. The users experiencing this problem are running SQL queries that take upwards of 15 minutes to return with no screen output. The virtual server is standard with a pool associated and no other customizations.
What is causing the SSH connections to terminate?
What is causing the SSH connections to terminate?
正解:A
解答を投票する
An LTM Specialist is tasked with ensuring that the syslogs for the LTM device are sent to a remote syslog server.
The following is an extract from the config file detailing the node and monitor that the LTM device is using for the
remote syslog server:
monitor Syslog_15002 { defaults from udp dest *:15002 }
node 91.223.45.231 { monitor Syslog_15002 screen RemoteSYSLOG }
There seem to be problems communicating with the remote syslog server. However, the pool monitor shows that the remote server is up.
The network department has confirmed that there are no firewall rules or networking issues preventing the LTM device from
communicating with the syslog server. The department responsible for the remote syslog server indicates that there may
be problems with the syslog server. The LTM Specialist checks the BIG-IP LTM logs for errors relating to the remote syslog server. None are found. The LTM Specialist does a tcpdump:
tcpdump -nn port 15002, with the following results: 21:28:36.395543 IP 192.168.100.100.44772 > 91.223.45.231.15002: UDP, length 19 21:28:36.429073 IP 192.168.100.100.39499 > 91.223.45.231.15002: UDP, length 169 21:28:36.430714 IP 192.168.100.100.39499 > 91.223.45.231.15002: UDP, length 181 21:28:36.840524 IP 192.168.100.100.39499 > 91.223.45.231.15002: UDP, length 169 21:28:36.846547 IP 192.168.100.100.39499 > 91.223.45.231.15002: UDP, length 181 21:28:39.886343 IP 192.168.100.100.39499 > 91.223.45.231.15002: UDP, length 144
NotE.192.168.100.100 is the self IP of the LTM device.
Why are there no errors for the remote syslog server in the log files?
The following is an extract from the config file detailing the node and monitor that the LTM device is using for the
remote syslog server:
monitor Syslog_15002 { defaults from udp dest *:15002 }
node 91.223.45.231 { monitor Syslog_15002 screen RemoteSYSLOG }
There seem to be problems communicating with the remote syslog server. However, the pool monitor shows that the remote server is up.
The network department has confirmed that there are no firewall rules or networking issues preventing the LTM device from
communicating with the syslog server. The department responsible for the remote syslog server indicates that there may
be problems with the syslog server. The LTM Specialist checks the BIG-IP LTM logs for errors relating to the remote syslog server. None are found. The LTM Specialist does a tcpdump:
tcpdump -nn port 15002, with the following results: 21:28:36.395543 IP 192.168.100.100.44772 > 91.223.45.231.15002: UDP, length 19 21:28:36.429073 IP 192.168.100.100.39499 > 91.223.45.231.15002: UDP, length 169 21:28:36.430714 IP 192.168.100.100.39499 > 91.223.45.231.15002: UDP, length 181 21:28:36.840524 IP 192.168.100.100.39499 > 91.223.45.231.15002: UDP, length 169 21:28:36.846547 IP 192.168.100.100.39499 > 91.223.45.231.15002: UDP, length 181 21:28:39.886343 IP 192.168.100.100.39499 > 91.223.45.231.15002: UDP, length 144
NotE.192.168.100.100 is the self IP of the LTM device.
Why are there no errors for the remote syslog server in the log files?
正解:D
解答を投票する
An LTM Specialist configures an HTTP monitor as follows:
ltm monitor http stats_http_monitor {
defaults-from http
destination *:*
interval 5
recv "Health check: OK"
send "GET /stats/stats.html 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 }
The monitor is marking all nodes as down. A trace of the HTTP conversation shows the following:
GET /stats/stats.html HTTP/1.1 Host: www.example.com Accept-EncodinG.gzip, deflate Connection: close
HTTP/1.1 401 Authorization Required DatE.Tue, 23 Oct 2012 19:38:56 GMT Server: Apache/2.2.15 (Unix) WWW-AuthenticatE.Basic realm="Please enter your credentials" Content-LengtH.480 Connection: close Content-TypE.text/html; charset=iso-8859-1
Which action will resolve the problem?
ltm monitor http stats_http_monitor {
defaults-from http
destination *:*
interval 5
recv "Health check: OK"
send "GET /stats/stats.html 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 }
The monitor is marking all nodes as down. A trace of the HTTP conversation shows the following:
GET /stats/stats.html HTTP/1.1 Host: www.example.com Accept-EncodinG.gzip, deflate Connection: close
HTTP/1.1 401 Authorization Required DatE.Tue, 23 Oct 2012 19:38:56 GMT Server: Apache/2.2.15 (Unix) WWW-AuthenticatE.Basic realm="Please enter your credentials" Content-LengtH.480 Connection: close Content-TypE.text/html; charset=iso-8859-1
Which action will resolve the problem?
正解:D
解答を投票する
Given LTM device ltm log:
Sep 26 20:51:08 local/lb-d-1 notice promptstatusd[3695]: 01460006:5: semaphore mcpd.running(1) held
Sep 26 20:51:08 local/lb-d-1 notice promptstatusd[3695]: 01460006:5:
Sep 26 20:51:08 local/lb-d-1 warning promptstatusd[3695]: 01460005:4: mcpd.running(1) held, wait for mcpd
Sep 26 20:51:08 local/lb-d-1 info sod[3925]: 010c0009:6: Lost connection to mcpd reestablishing.
Sep 26 20:51:08 local/lb-d-1 err bcm56xxd[3847]: 012c0004:3: Lost connection with MCP: 16908291 ... Exiting bsx_connect.cpp(174)
Sep 26 20:51:08 local/lb-d-1 info bcm56xxd[3847]: 012c0012:6: MCP Exit Status Sep 26 20:51:08 local/lb-d-1 info bcm56xxd[3847]: 012c0012:6: Info: LACP stats (time now:1348717868) : no traffic
Sep 26 20:51:08 local/lb-d-1 info bcm56xxd[3847]: 012c0014:6: Exiting...
Sep 26 20:51:08 local/lb-d-1 err lind[3842]: 013c0004:3: IO error on recv from mcpd connection lost Sep 26 20:51:08 local/lb-d-1 notice bigd[3837]: 01060110:5: Lost connection to mcpd with
error 16908291, will reinit connection.
Sep 26 20:51:08 local/lb-d-1 err statsd[3857]: 011b0004:3: Initial subscription for system configuration failed with error '' Sep 26 20:51:08 local/lb-d-1 err statsd[3857]: 011b0001:3: Connection to mcpd failed with
error '011b0004:3: Initial subscription for system configuration failed with error '''
Sep 26 20:51:08 local/lb-d-1 err csyncd[3851]: 013b0004:3: IO error on recv from mcpd connection lost .............skipping more logs..... Sep 26 20:51:30 local/lb-d-1 notice sod[3925]: 01140030:5: HA proc_running bcm56xxd is
now responding.
Sep 26 20:51:34 local/lb-d-1 notice sod[3925]: 01140030:5: HA proc_running mcpd is now responding. Sep 26 20:51:34 local/lb-d-1 notice sod[3925]: 010c0018:5: Standby
Which daemon failed?
Sep 26 20:51:08 local/lb-d-1 notice promptstatusd[3695]: 01460006:5: semaphore mcpd.running(1) held
Sep 26 20:51:08 local/lb-d-1 notice promptstatusd[3695]: 01460006:5:
Sep 26 20:51:08 local/lb-d-1 warning promptstatusd[3695]: 01460005:4: mcpd.running(1) held, wait for mcpd
Sep 26 20:51:08 local/lb-d-1 info sod[3925]: 010c0009:6: Lost connection to mcpd reestablishing.
Sep 26 20:51:08 local/lb-d-1 err bcm56xxd[3847]: 012c0004:3: Lost connection with MCP: 16908291 ... Exiting bsx_connect.cpp(174)
Sep 26 20:51:08 local/lb-d-1 info bcm56xxd[3847]: 012c0012:6: MCP Exit Status Sep 26 20:51:08 local/lb-d-1 info bcm56xxd[3847]: 012c0012:6: Info: LACP stats (time now:1348717868) : no traffic
Sep 26 20:51:08 local/lb-d-1 info bcm56xxd[3847]: 012c0014:6: Exiting...
Sep 26 20:51:08 local/lb-d-1 err lind[3842]: 013c0004:3: IO error on recv from mcpd connection lost Sep 26 20:51:08 local/lb-d-1 notice bigd[3837]: 01060110:5: Lost connection to mcpd with
error 16908291, will reinit connection.
Sep 26 20:51:08 local/lb-d-1 err statsd[3857]: 011b0004:3: Initial subscription for system configuration failed with error '' Sep 26 20:51:08 local/lb-d-1 err statsd[3857]: 011b0001:3: Connection to mcpd failed with
error '011b0004:3: Initial subscription for system configuration failed with error '''
Sep 26 20:51:08 local/lb-d-1 err csyncd[3851]: 013b0004:3: IO error on recv from mcpd connection lost .............skipping more logs..... Sep 26 20:51:30 local/lb-d-1 notice sod[3925]: 01140030:5: HA proc_running bcm56xxd is
now responding.
Sep 26 20:51:34 local/lb-d-1 notice sod[3925]: 01140030:5: HA proc_running mcpd is now responding. Sep 26 20:51:34 local/lb-d-1 notice sod[3925]: 010c0018:5: Standby
Which daemon failed?
正解:B
解答を投票する