Forum Discussion

Michael_Harpe's avatar
Michael_Harpe
Icon for Altostratus rankAltostratus
Nov 23, 2022
Solved

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!

 

  • 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 

4 Replies

  • 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 

    • Michael_Harpe's avatar
      Michael_Harpe
      Icon for Altostratus rankAltostratus

      Thank you for that! Ours is easy, Just one URL is allowed to start a session. 

      I will implement this ASAP!

      Thanks again!

      Michael Harpe

  • How many concurrent users do you typically see? Do a large number of them traverse a NAT device to reach your APM VIP?

    The 128 default (i believe) is set to strike a balance for usability in most cases and also to prevent resource exhaustion from a single source.