-
Getting Started with Citrix NetScaler
-
Deploy a Citrix NetScaler VPX instance
-
Install a Citrix NetScaler VPX instance on Microsoft Hyper-V servers
-
Install a NetScaler VPX instance on Linux-KVM platform
-
Prerequisites for Installing NetScaler VPX Virtual Appliances on Linux-KVM Platform
-
Provisioning the NetScaler Virtual Appliance by using OpenStack
-
Provisioning the NetScaler Virtual Appliance by using the Virtual Machine Manager
-
Configuring NetScaler Virtual Appliances to Use SR-IOV Network Interface
-
Configuring NetScaler Virtual Appliances to use PCI Passthrough Network Interface
-
Provisioning the NetScaler Virtual Appliance by using the virsh Program
-
-
Deploying NetScaler VPX Instances on AWS
-
Upgrade and downgrade a NetScaler appliance
-
-
-
-
-
-
Overriding Static Proximity Behavior by Configuring Preferred Locations
-
Example of a Complete Parent-Child Configuration Using the Metrics Exchange Protocol
-
Configuring Global Server Load Balancing for DNS Queries with NAPTR records
-
Using the EDNS0 Client Subnet Option for Global Server Load Balancing
-
-
Persistence and persistent connections
-
Advanced load balancing settings
-
Gradually stepping up the load on a new service with virtual server–level slow start
-
Protect applications on protected servers against traffic surges
-
Use source IP address of the client when connecting to the server
-
Set a limit on number of requests per connection to the server
-
Configure automatic state transition based on percentage health of bound services
-
-
Use case 2: Configure rule based persistence based on a name-value pair in a TCP byte stream
-
Use case 3: Configure load balancing in direct server return mode
-
Use case 6: Configure load balancing in DSR mode for IPv6 networks by using the TOS field
-
Use case 7: Configure load balancing in DSR mode by using IP Over IP
-
Use case 10: Load balancing of intrusion detection system servers
-
Use case 11: Isolating network traffic using listen policies
-
Use case 14: ShareFile wizard for load balancing Citrix ShareFile
-
-
-
-
-
Configuring a CloudBridge Connector Tunnel between two Datacenters
-
Configuring CloudBridge Connector between Datacenter and AWS Cloud
-
Configuring a CloudBridge Connector Tunnel Between a Datacenter and Azure Cloud
-
Configuring CloudBridge Connector Tunnel between Datacenter and SoftLayer Enterprise Cloud
-
Configuring a CloudBridge Connector Tunnel Between a NetScaler Appliance and Cisco IOS Device
-
CloudBridge Connector Tunnel Diagnostics and Troubleshooting
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)
此内容已动态机器翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
This content has been machine translated dynamically.
This content has been machine translated dynamically.
This content has been machine translated dynamically.
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.
这篇文章已经过机器翻译.放弃
Translation failed!
Configuring VRRP Communication Intervals
In an active-active deployment, all NetScaler nodes use the Virtual Router Redundancy Protocol (VRRP) to advertise their master VIP addresses and the corresponding priorities in VRRP advertisement packets (hello messages) at regular intervals.
VRRP uses the following communication intervals:
- Hello Interval. Interval between the VRRP hello messages that a node of a master VIP address sends to its peer nodes.
- Dead Interval. Time after which a node of a backup VIP address considers the state of the master VIP address as DOWN if VRRP hello messages are not received from the node of the master VIP address. After the dead interval, the backup VIP address takes over and becomes the master VIP address.
You can change these intervals to a desired value. Both of these communication intervals are per node setting for all VIP addresses in that node.
To configure VRRP communication intervals by using the NetScaler command line:
At the command prompt, type:
- set vrIDParam [-helloInterval <msecs>] [-deadInterval <secs>]
- sh vrIDParam
Example:
> set vrIDParam -helloInterval 500 -deadInterval 2
Done
To configure VRRP communication intervals by using the NetScaler GUI:
- Navigate to System > Network, in the Settings group, click Virtual Router Parameters.
- In Configure Virtual Router Parameter, set the Hello Interval and Dead Interval parameters.
- Click OK.
Example 1: Nodes with the Same VRRP Dead Intervals
Consider an active-active deployment consisting of NetScaler appliances NS1, NS2, and NS3. Virtual IP addresses VIP1, VIP2, VIP3 are configured on each of these appliances. Because of their priorities, VIP1 is active on NS1, VIP2 is active on NS2, and VIP3 is active on NS3.
As shown in the table below, the dead interval is set to the same value (2 seconds) on all the three nodes. The VRRP communication intervals (hello interval and dead interval) of a node apply to all the VRIDs configured on the node, and in turn, apply to all VIP addresses associated with the VRIDs on the node.
On each node, the VIP addresses that are active (master) on that node use the hello interval, and the dead interval is used by the VIP addresses that are inactive (backup) on that node. Preemption is disabled for the VIP addresses in all the three nodes.
The following table lists the settings used in this example: VRRP interval example 1 settings.
The execution flow is as follows:
- NS1 sends hello messages at a set hello interval of 400 ms to NS2 and NS3 for the VIP1 address, because VIP1 is active (the master) on NS1. Similarly, NS2 sends hello messages for VIP2, and NS3 sends hello messages for VIP3.
- On NS1, the set dead interval applies to VIP2 and VIP3, because they are inactive (backups) on NS1. Similarly, on NS2, the set dead interval applies to VIP1 and VIP3, and on NS3, the set dead interval applies to VIP1 and VIP2.
- If NS1 goes down, NS2 and NS3 consider NS1 to be down if they receive no hello messages from NS1 for 2 seconds (the dead interval). VIP1 on NS3 takes over and becomes active (master) because its VRID priority (60) is higher than that of VIP1 of NS2 (30).
Example 2: Nodes with Different VRRP Dead Intervals
Consider a VRRP deployment similar to the deployment described in Example1 but with a different dead interval on each node (NS1, NS2, and NS3). Preemption is disabled for the VIP addresses in all the three nodes.
The following table lists the settings used in this example: VRRP interval example 2 settings.
The execution flow is as follows when NS1 goes down:
- NS2 considers NS1 to be down after not receiving any hello messages from NS1 for 2 seconds (NS2’s dead interval).
- VIP1 on NS2 takes over and becomes active (master). NS2 now starts sending hello messages for VIP1.
Even though VIP1 on NS3 has a higher VRIP priority (60) than does VIP1 on NS2 (30), NS3’s larger dead interval (3 seconds, vs. 2 seconds for NS2), prevents VIP1 on NS3 from taking over before VIP 1 on NS2 has already done so.
Example 3: Nodes with Different Dead Intervals and Preemption Enabled
Consider a VRRP deployment similar to the deployment described in Example1 but with different dead intervals on the three nodes, NS1, NS2, and NS3, and with preemption enabled for the VIP1 address on NS3.
The following table lists the settings used in this example: VRRP interval example 3 settings.
The execution flow is as follows when NS1 goes down:
- NS2 considers NS1 to down after not receiving any hello messages from NS1 for 2 seconds (NS2’s set dead interval). At this time, NS3, with a dead interval of 3 seconds, does not consider NS1 to be down.
- VIP1 on NS2 takes over and becomes active (master). NS2 now starts sending hello messages for VIP1.
- Upon receiving hello messages from NS2 for VIP1, NS3 preempts NS2 for VIP1 because preemption is enabled for VIP1 of NS3 and the VRID priority (60) of VIP1 of NS3 is higher than that (30) of VIP1 of NS2.
- VIP1 on NS3 takes over and becomes active (master). NS3 now starts sending hello messages for VIP1.
Share
Share
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.