Hi Joao,
When the ISVA Front-end load-balancer (FELB) is working at layer 4, it is reading and forwarding TCP packets. A layer 4 load-balancer doesn't break an SSL session. This means that the SSL session is still end-to-end between the client and the target server. A layer 4 load balancer can't see or modify anything above layer 4 so it can't be "sticky" based on a cookie (because it can't see or inject into HTTP stream). Usually layer 4 load balancing is done based on (physical) source IP which is often not very good when dealing with a large number of clients behind a NAT gateway (or similar).
When the ISVA FELB is working at layer 7 it needs to see (and manipulate) the HTTP traffic. For this reason, it must terminate the SSL session. Depending on configuration it may forward traffic to target servers over HTTP (SSL-offload) or it may have a new SSL session to the target server.
A layer 7 load-balancer can inject a cookie into responses to uniquely tag the connecting device. This allows a layer 7 load-balancer to perform "stickiness" for each individual client regardless of network architecture. In my opinion, this is the main reason to use layer 7 vs layer 4.
Because the whole connection stack is terminated at a layer-7 load-balancer, it must forward information about the original connection to the target server if this is need for target server processing. For example, it might forward the original IP address or information about a received client certificate in HTTP headers. Dealing with this need to handle the lower-level communication and forward results (and the overhead this implies) is the "downside" of a layer 7 load-balancer.
This is a good topic in the IBM Docs:
https://www.ibm.com/docs/en/sva/10.0.1?topic=administration-front-end-load-balancerJon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------