The different types of virtual services can use the same pool for backend traffic.

The supported pool sharing matrix is as follows:

  • Multiple L4 virtual services can share the same pool

  • L4 SSL and L7 virtual services can share the pool

  • L4 SSL and L4 virtual services can share the pool

  • L4, L4 SSL and L7 can share the same pool

With the pool sharing feature, you can:

  • Avoid creating duplicate pools and hence preserve resources

  • Apply persistence across virtual services

  • Have less configuration, and therefore easy management

An example use case for pool sharing is client IP persistence shared between L4 and L7 virtual services.

Note:

  • Syslog/ DNS/ SIP Application profiles do not support Pool sharing.

  • With L4/ L7 Pool sharing , only client IP persistence is supported. Other persistence types are specific to L7 and are not applicable when pool is shared between L4 and L7. The system displays the following error message that is displayed when the persistence is changed to some other type:

    "Cannot change Pool because of referred virtual service. Only clien-ip persistence is applicable for Layer-4 virtual service."

  • When client IP persistence is required and persistence to be shared between virtual services: The virtual services should be scaled out to the same SEs. If different virtual services are scaled out to different set of SEs, use override_application_profile for L4 service ports with a single virtual service .

  • The use_service_port/ Disable Port Translation is a pool-level property, not a virtual service property. Hence L4 and L7 virtual services sharing the same pool cannot have use_service_port for one virtual service and have it disabled for the other virtual service.

  • L4 SL does not support use_service_port. So, if the use case is to disable port translation on pool level, then pool cannot be shared with an L4-SSL type virtual service.