An LTM Specialist needs to rewrite text within an HTML response from a web server. A client is sending the HTTP request below:
GET / HTTP/1.1
Host: www.f5.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-LanguagE. en-US,en;q=0.5
Accept-EncodinG. gzip, deflate
Cache-Control: no-cache
Connection: keep-alive
CookiE. somecookie=1
Although a stream profile has been added to the virtual server, the content within the HTTP response is NOT being matched, and therefore NOT modified.
Which HTTP header should the LTM Specialist remove from the request to ensure the content can be matched and modified?
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?
-- Exhibit -
-- Exhibit --
Refer to the exhibit.
An LTM Specialist creates a virtual server to load balance traffic to a pool of HTTPS servers. The servers use client certificates for user authentication. The virtual server has clientssl, serverssl, and http profiles enabled. Clients are unable to connect to the application through the virtual server, but they are able to connect to the application servers directly.
Which change to the LTM device configuration will resolve the problem?
-- Exhibit-
-- Exhibit --
Refer to the exhibit.
Which two items can be consolidated to simplify the LTM configuration? (Choose two.)
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 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?
