This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Multi-IP virtual servers
The Citrix ADC supports creating a single load balancing virtual server with multiple non-consecutive/consecutive IPv4 and IPv6 addresses of type VIP. Each VIP address bound to a virtual server is treated as an individual virtual server. These virtual servers have the same protocol and other virtual server level settings. A virtual server with multiple VIP addresses is also called multi-IP virtual server.
The following are some advantages of using multi-IP virtual servers:
- A multi-IP virtual server offloads the work of creating many virtual servers with the same settings and service bindings.
- Multi-IP virtual servers effectively reduces the possibility of reaching the maximum limit on virtual server entities.
- One multi-IP virtual server can be used for clients in different subnets to connect to the same set of servers.
- Only one multi-IP virtual server can be used for IPv6 and IPv4 clients to connect to the same set of servers.
Configuring a multi-IP virtual server consists of the following tasks:
- Create an IPset and bind multiple IP addresses to it.
- Bind the IPset to load balancing virtual servers.
Note the following points related to IPset configuration:
- An IPset can have:
- non-consecutive/consecutive IPv4 addresses and IPv6 addresses
- combinations of IPv4 and IPv6 addresses.
- All IPv4/IPv6 addresses to be associated with virtual servers using IPset must be of type VIP.
- A single IPset can be bound to multiple virtual servers.
- IPv4/IPv6 addresses can be bound/unbound to/from IPset irrespective any existing IPset bindings to virtual servers.
- You must unset the IPset binding to a virtual server before binding a new IPset to it.
To add an IPset and bind multiple VIP addresses to it by using the CLI
At the command prompt, type:
add ipset <name> bind ipset <name> <IPaddress1 …> bind ipset <name> <IPaddress2…> show ipset <name> <!--NeedCopy-->
To bind the IPset to a virtual server by using the CLI
At the command prompt, type:
set lb vserver <name> -ipset <ipset name> show lb vserver <name> <!--NeedCopy-->
To add an IPset and bind multiple VIP addresses to it by using the GUI
Navigate to System > Network > IPSets, and create an IPset with multiple VIP addresses.
To bind the IPSet to a virtual server by using the GUI
- Navigate to Traffic Management > Load Balancing > Virtual Servers, and open a virtual server to which you want to bind the created IPset.
- In Basic Settings, set the IPset parameter to the name of the created IPset.
> add ipset IPSET-1 Done > bind ipset IPSET-1 188.8.131.52 Done > bind ipset IPSET-1 1000::20 Done > add lb vserver LBVS-1 HTTP 184.108.40.206 80 –ipset IPSET-1 Done > add service SVC-1 220.127.116.11 HTTP 80 Done > add service SVC-2 18.104.22.168 HTTP 80 Done > bind lb vserver LBVS-1 SVC-1 Done > bind lb vserver LBVS-1 SVC-2 Done
Floating IP addresses are required for the high availability deployments. Cloud deployments do not support floating IP addresses. So, the IP set feature helps you support high availability in cloud deployments. With the IP set feature, you can associate a private IP address to each of the primary and secondary instances. One of the private IP addresses is added when creating the virtual server. The other IP address is bound to an IP set. The IP set is then associated with the virtual server. Typically a public IP address is mapped to one of the private IP addresses based on which appliance is taking the traffic. During failover, this mapping changes dynamically to route the traffic to the new primary.
In GSLB deployments, the GSLB service represents the virtual server and it requires both the private and public IP address of the virtual server. In cloud deployments, there are multiple private IP addresses represented as an IP set but the GSLB service can accept only one private IP address. So while configuring the GSLB service it is recommended to give the IP address that is configured while adding the virtual server or one of the IP addresses in the IP set. You need not configure the IP set feature on the GSLB service. The IP set configured on the load balancing virtual server associated with the GSLB service is sufficient.
In GSLB Parent-child topology, the load balancing virtual servers on the child sites can have the IP set associated with it. The GSLB service corresponding to this topology carries the public IP address and one of the private IP addresses. The private IP address can be an IP address in the IP set or the one configured while adding the virtual server on the child site. Communication between the parent and the child sites is always using the public IP address and the public port of the GSLB service.
Also, with IP set support, you can have a single virtual server endpoint for both IPv4 and IPv6 traffic. Previously, you had to configure different virtual servers for IPv4 and IPv6 traffic. With IP set support, you can associate IPv4 and IPv6 IP addresses to the same IP set. You can add different GSLB services representing the IPv4 and IPv6 endpoints.
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select Do Not Agree to exit.