An LTM Specialist sees these entries in /var/log/ltm: Oct 25 03:34:31 tmm warning tmm[7150]: 01260017:4: Connection attempt to insecure SSL server (see RFC5746) aborteD. 172.16.20.1:443 Oct 25 03:34:32 tmm warning tmm[7150]: 01260017:4: Connection attempt to insecure SSL server (see RFC5746) aborteD. 172.16.20.1:443 Oct 25 03:34:32 tmm warning tmm[7150]: 01260017:4: Connection attempt to insecure SSL server (see RFC5746) aborteD. 172.16.20.1:443 Oct 25 03:34:32 tmm warning tmm[7150]: 01260017:4: Connection attempt to insecure SSL server (see RFC5746) aborteD. 172.16.20.1:443 Oct 25 03:34:32 tmm warning tmm[7150]: 01260017:4: Connection attempt to insecure SSL server (see RFC5746) aborteD. 172.16.20.1:443 Oct 25 03:34:33 tmm warning tmm[7150]: 01260017:4: Connection attempt to insecure SSL server (see RFC5746) aborteD. 172.16.20.1:443 Assume 172.16.20.0/24 is attached to the VLAN "internal." What should the LTM Specialist use to troubleshoot this issue?
A virtual server for a set of web services is constructed on an LTM device. The LTM Specialist has created an iRule and applied this iRule to the virtual server: when HTTP_REQUEST { switch [HTTP::uri] { "/WS1/ws.jsp" { log local0. "[HTTP::uri]-Redirected to JSP Pool" pool JSP } default { log local0. "[HTTP::uri]-Redirected to Non-JSP Pool" pool NonJSP } } } However, the iRule is NOT behaving as expected. Below is a snapshot of the log: /WS1/ws.jsp-Redirected to JSP Pool /WS1/ws.jsp-Redirected to JSP Pool /WS1/ws.jsp-Redirected to JSP Pool /WS1/WS.jsp-Redirected to Non-JSP Pool /ws1/WS.jsp-Redirected to Non-JSP Pool /WS1/ws.jsp-Redirected to JSP Pool /ws1/ws.jsp-Redirected to Non-JSP Pool What is the problem?
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?
Given a tcpdump on an LTM device from both sides of a connection on the External and Internal VLANs, how should an LTM Specialist determine if SNAT is enabled for a particular pool?
An LTM Specialist has a OneConnect profile and HTTP profile configured on a virtual server to load balance an HTTP application. The following HTTP headers are seen in a network trace when a client connects to the virtual server: Clientside: GET / HTTP/1.1 Host: 192.168.136.100 User-Agent: Mozilla/5.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-EncodinG. gzip, deflate Connection: keep-alive Serverside: HTTP/1.1 200 OK DatE. 5 Jun 1989 17:06:55 GMT Server: Apache/2.2.14 (Ubuntu) Vary: Accept-Encoding Content-EncodinG. gzip Content-LengtH. 3729 X-Cnection: close Content-TypE. text/html The LTM Specialist notices the OneConnect feature is working incorrectly. Why is OneConnect functioning incorrectly?
A OneConnect profile is applied to a virtual server. The LTM Specialist would like the client source IP addresses within the 10.10.10.0/25 range to reuse an existing server side connection. Which OneConnect profile source mask should the LTM Specialist use?
