Forum Discussion

Altostratus

Nov 23, 2022

APM TCP connection limit K38157145

I encountered this issue today when trying to troubleshoot a problem that presented as TCP ACK/RSTs being sent from a VS using APM.

I found the problem while getting data together for a ticket. Error Message: 01490547:4: Access Profile <name>: Per IP in-progress sessions limit (<#>) exceeded for <IP_address> (f5.com) explains the issue. Apparently this has been around for several major versions but this is the first time we have encountered it and we have been using APM since version 12. We are running BIG-IP 15.1.6.1 Build 0.0.10 Point Release 1

My question is, how do we right-size that number and how does this happen? 128 seems like a low number for a defaiult.

Thanks for any help!

security

Kai_Wilke

Nov 24, 2022

Hi Michael,

you may check the landing URI's of such in-progress sessions. It happens very often that APM timed out browser session still performing certain API calls which are starting lots of new APM sessions.

I regulary use a black-list of URI's which should not create a new APM session to avoid exhaustion of the Per-IP limits.

when HTTP_REQUEST {

	#log "Unset all Temporary and HTTP-Request variables (if exists) on each received HTTP request."
	
	unset -nocomplain req temp
	
}
when ACCESS_SESSION_STARTED priority 170 {

	#log "Fetch the landing URI from APM session."

	set temp(landinguri) [ACCESS::session data get "session.server.landinguri"]

	#log "Checking if the landing URI is eliglible to start a new APM session."

	switch -glob -- $temp(landinguri) {

		"/api.jsp" -
		"/some-other-api.jsp" -
		"/some-api-related-path*" {

			#log "The landing URI is not eliglible to start a new APM session. Redirecting the user to the APM hangup page."

			ACCESS::respond 302 \
							noserver \
							"Location" "/vdesk/hangup.php3"

			#log "Marking the APM session to get killed during HTTP_RESPONSE_RELEASE event."

			set req(kill_apm_session_on_http_response_release) 1
		}
	}

}
when HTTP_RESPONSE_RELEASE {

	if { [info exists req(kill_apm_session_on_http_response_release)] } then {
			
		#log "Passing the ongoing HTTP response to client while killing the APM user session."

		ACCESS::session remove
	}
}

Beside of killing those automated session creations as soon as they start a new APM session, you may also check if certain IPs of Proxy Servers are exhausting the limits regulary. In this case you may take a look to an iRule snipped I used in the past to enforce relaxed APM Per-IP session limits for well-known high traffic sources.

Enforcing individual APM Policy "In Progress Sessi... - DevCentral (f5.com)

Cheers, Kai