An LTM device has been configured to log the reasons for generating TCP RST packets.
The following log entry occurs:
"01230140:3: RST sent from 192.168.1.100:80 to 192.168.1.124:39272, [0x112d82a:1721] {peer} TCP RST from remote system." Which condition will trigger this log entry?
-- Exhibit -
-- Exhibit --
Refer to the exhibit.
A virtual server is set up on an LTM device as follows:
Virtual server address 78.24.213.79
Default Persistence ProfilE. source_addr, 600s.
Pool NamE. Pool1
Pool Members: 10.72.250.52:80 and 10.72.250.60:80 (both on Internal Vlan) There are several current connections to the virtual server, and pool member 10.72.250.52:80 has been set to a "Disabled" state.
A tcpdump on the Internal Vlan shows traffic going to 10.72.250.52:80.
How soon after the persistence table query was run can existing connections be refreshed/renewed to ensure that no requests are sent to 10.72.250.52?
In preparation for a maintenance task, an LTM Specialist performs a "Force to Standby" on LTM device Unit 1.
LTM device Unit 2 becomes active as expected. The maintenance task requires the reboot of Unit 1. Shortly after the reboot is complete, the LTM Specialist discovers that Unit 1 has become active and Unit 2 has returned to standby.
What would cause this behavior?
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?
-- 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?