From within a Virtual Service you can create one or more ‘Sub-Virtual Services’ (SubVSs). A SubVS is linked to, and uses the IP address of, the ‘parent’ Virtual Service. The SubVSs may have different settings (such as health check methods, content rules etc.) to the parent Virtual Service and to each other. This allows the grouping of related Virtual Services, all using the same IP address. This could be useful when there are complex configurations such as Exchange which typically are comprised of a number of Virtual Services.

There are many advantages to using SubVSs, such as:

  • SubVSs are linked to, and use the IP address of, the ‘parent’ Virtual Service

  • Using SubVSs reduces the number of IP addresses required by applications such as Lync or Exchange

  • Virtual Service to SubVS traffic is always transparent (no changes are required). SubVS to Real Server traffic can optionally be transparent (if it is transparent, the rules for transparency must be followed). Restrictions for using transparency still apply, for example, you cannot use transparency with re-encryption.

  • SubVSs may have different settings (such as content rules) to the parent Virtual Service and to each other

  • Using a SubVS provides the ability to have content switching and persistency on the same Virtual Service

  • Using a SubVS gives the ability to perform multiple health checks on the same Virtual Service

  • SubVSs work well with ESP, but ESP is not required