Citrix ADC SDX to VPX: Always-on reachability

Prior to Citrix ADC version 13.0, when adding any VPX instance to an SDX appliance, you needed to ensure the Management Service of SDX (SVM) was able to communicate with the VPX over the network. The SVM talks to the VPX like any other entity on/outside the VPX network and the data plane and control plane network on the SDX overlap, as shown here:

Depending on configuration or network topology, this architecture can be a challenge for some organisations. Furthermore, if the VPX became unreachable from the SVM due to a network issue, the SVM would be unable to manage that instance. Whilst the VPX is functioning normally, SVM would report the instance as down.

Why does the SVM need to communicate with the Citrix ADC VPX?

• Monitoring of VPX instances using SNMP

• Collecting and restoring Citrix ADC backups.

• Management of VPX instances including:

  • Adding/removing interfaces and VLANs
  • Certificate management
  • Firmware updates
  • Start/Shut down/Reboot/Delete instances

The SVM accesses the instances using HTTP/HTTPS, SSH, and SCP. The following ports are required for the above communication:

• TCP 22, 80, 443, and UDP 162.

Usually VPX instances are provisioned in the same network as the SVM. For environments where this is not possible, there are alternative options such as specifying Next Hop to Management Service:

or configuring L2VLAN/NSVLAN:

Always-on Reachability Between an SDX Appliance and its VPX Instances

Network reachability considerations and issues between the SVM and VPX can be a pain point for customers. To overcome this, the SDX appliances running firmware version 13.0 now include an independent internal network between the SVM and 13.0 VPX instances running on the SDX appliance. Such a network is reliable and provides always-on connectivity. Both SDX and VPX instances need to be running a 13.0 version in order to avail of this new feature.

New Architecture

Key Features

• VPX management on SDX with zero disruption: VPX is always up and reachable by management service. There is no impact of outside network on SVM-VPX connectivity.
• Complete isolation of data plane from control plane on SDX: The user can provision VPXs with NSIP unreachable from SVM.
• Enhanced troubleshooting: Connectivity deadlocks can be completely avoided.
• Complete Security: The internal network cannot be used for VPX to VPX communication.
• Seamless across all VPX deployments: The solution works seamlessly across all network topologies like HA, cluster, NSVLAN etc

What does the SVM to VPX communication look like without the internal network?

If always-on management connectivity is not enabled, then communication will be sourced from the SVM IP to the NSIP on the VPX via whatever interface has been added to the instance.

For instance, here we can see the mac address for 0/1 on the SDX:

Here’s the equivalent mac address on the VPX:

A quick nstrace on the VPX will pick up the SVM communication:

What does SVM to VPX communication look like when the internal network is enabled?

When Manage Through Internal Network is enabled on VPX via SVM, an additional internal interface is bound to the VPX. This interface will be numbered 0/1, 0/2, or 0/3 depending on whether other management interfaces are also bound.

On SDX it will be listed as 0/3 with an internal IP address in the 169.254 address space.

SDX:

VPX:

Another nstrace reveals the internal communication:

How do I enable this feature?

You’ll find the option when editing the VPX via SVM:

Note that from 13.0 52.24 we’ve improved the feature further by removing the requirement to reboot when making this change.

You can find more information here and in the release notes for build 36.27 of Citrix ADC 13.0.

A big thank you to our SDX engineering experts Himanki Jain, Deepak Gupta and Krishna Vivek for their contributions.