Connection limit per node and source IP persistence conflict; who wins?

Now suppose the are a few hundred clients behind the same public NAT. They call end up on the same web server, node A, due to the persistence rule. What happens when the 101st user from that same public NAT makes a connection?

Depends on a number of things

• Status of

  Override Connection Limit

  setting (Persistence Profile)
  Assuming this is enabled, 101th connection will go to node A
  When disabled, the persistence record will be discarded and connection will go to another node (load-balancing occurs)
• If

  Override Connection Limit

  setting is disabled and no other pool members are available, TCP-RST will be sent to client which results in a generic "Connection Has Been Reset" web-browser error

Regards,

Now suppose the are a few hundred clients behind the same public NAT. They call end up on the same web server, node A, due to the persistence rule. What happens when the 101st user from that same public NAT makes a connection?

Depends on a number of things

• Status of

  Override Connection Limit

  setting (Persistence Profile)
  Assuming this is enabled, 101th connection will go to node A
  When disabled, the persistence record will be discarded and connection will go to another node (load-balancing occurs)
• If

  Override Connection Limit

  setting is disabled and no other pool members are available, TCP-RST will be sent to client which results in a generic "Connection Has Been Reset" web-browser error

Regards,

•Status of Override Connection Limit setting (Persistence Profile)

When disabled, the persistence record will be discarded and connection will go to another node (load-balancing occurs)

Assuming Override is disabled, the F5 will be able to keep track of client to node session/socket information, correct? Client session data is currently on the web server (though in the process of migrating off).