Lessons from the Field: Citrix ADC migrations

In my over 30 years in the IT industry (yes, I’m showing my age), I have taken part in countless migration projects that have included Citrix ADCs, network switches, routers, and firewalls. I have a good overall view of what takes place when a customer and Citrix are involved in any kind of data center migration. In this post, I’ll highlight some critical decision points and considerations that can help make your next Citrix ADC migration a smooth one.

Migration Considerations

Before jumping into any migration, it’s critical to engage with customers and answer the five W’s: who, what, where, when, and why. The answers to these questions then feed into areas of focus for the migration. For example:

• Current and Forecasted Throughput (who/when) — Consider areas like concurrent users, disaster recovery (DR), SSL transactions, and growth in a solution to ensure the appliances are sized properly. For example, customers usually have a 10 Gbps network core throughput with most internet connections at 1 Gbps. If a customer is forecasting 30,000 remote ICA connections, the 1 Gb internet connection will likely be a bottleneck.
• Power / Cooling / Racking (where) — This is a topic that we may not always consider in a migration project. Does the new unit have dual power supplies? Is there space on the power distribution units (PDU)? Is there proper cooling in that data center for the new appliances or is that at capacity? I recently had a customer that hadn’t considered the data center infrastructure, and it delayed the migration by six months.
• Interface Connectivity (where) — I am sure some readers of this post have been in situations where recently purchased Citrix ADC appliances have been racked and powered on, but no SFPs have been ordered. Related to interface connectivity, an important decision is whether the customer will use single interfaces or link aggregation control protocol (LACP) channels for connectivity into the network core.

Tip — Make sure your egress matches your ingress on any network appliance or you risk buffering and/or dropping packets.

• IP addressing and VLAN/s (what) – As we look at the OSI model, the foundation for the transport layer is the IP addressing and VLAN configuration. It is vital to communicate with networking, security and virtualization teams to ensure that there are adequate IP addressing and VLAN assignments not only for the current migration, but also for the future.
  • Trunk or access port: My recommendation is to always start with a trunk port. If you want to add VLANs in the future, it’s a simple configuration both for the network and the Citrix ADC; it’s a complete re-configuration to go from an access to a trunk port.
  • New or re-use IP addressing: The Citrix ADC has the option of disabling ARP on an IP Address, except for the SNIP, which would allow the reuse of the IP addresses. The only negative I see here is that there is no real ability to test the new configurations. If the customer can provide new IP addresses, then testing can be performed ahead of time with the use of entries in the hosts file or a temporary DNS server. This also allows large migrations, let’s say a client with 100 applications, to cut over those applications to the new environment simply by changing their DNS entries for the respective services. The main consideration with using new IP addressing is firewall rules including network address translation (NAT).

• Layer 3 Considerations (what) — Layer 3 considerations have a lot to do with the customer design of the network. The obvious Citrix ADC deployment is one arm mode with the default route to the network core. But often, my experience with clients is that they have what I would call northbound and southbound layer 3 routing. Take note of any east-west traffic as well that will affect layer 3 design, such as an application calling on a SQL database.
• Protocols and Ports (what/why) — It is a very good possibility that a migration is required to accommodate new applications, new features, or complete product replacements such as an SSL VPN solution. After the infrastructure assessment, we should have a list of all protocols and ports used in the current production environment, and we also should record any new protocols and ports to document firewall rule changes. An example of this would be Citrix Application Delivery Management changing from UDP to TCP as an improvement in the product. I always recommend having the customer build an application list and all the requirements for delivery in advance.
• Licensing (what) — Who has the Citrix account and has the proper licensing been procured? Are the proper license levels purchased for a feature configuration such as one time password (OTP) with push notification?
• Monitoring and Managing (who/what) — This is an opportunity to deploy sound monitoring and managing of the new environment using lessons learned from the current production environment.
• Basic to Advanced Policies (what/when) — With the deprecation of some commands and syntax, we should always start with advanced policies. Go nFactor!

Migration Types

An ADC “migration” could consist of any of the following scenarios, each of which has differing considerations and levels of complexity:

Citrix ADC to newer platform appliances

• Hardware appliance to hardware appliance (for example, MPX 15500 to MPX 15030-50G)
• Hardware appliance to software appliance and vice versa (for example, MPX 5500 to VPX 1000)
• Software appliance to cloud software appliance (for example, VPX 1000 to cloud-based VPX 1000)
• Hardware appliance to cloud software appliance (for example MPX 5500 to VPX 1000 cloud based)

Third-party appliances to Citrix ADC

Some considerations for these different migration types are:

• Citrix ADC MPX:
  • Migrating from MPX to MPX is generally straightforward, with changes usually limited to interfaces, throughput, and horsepower.
  • This is the time to move off the access ports in the current environment to an LACP channel configured as a trunk port.
  • Common to all platforms is firmware upgrades that may deprecate code, enable or disable settings, and impact customization.

• Citrix ADC SDX:
  • The interface configuration on the Citrix ADC SDX all starts on the SVM, which is then assigned to ADC VPX instances. A good layer 2/3 design is critical to performance.
  • The Citrix ADC SDX flexibility allows for a single appliance to be configured in multiple security zones with hardware and software separation. This is a key feature as to why a customer would purchase an SDX, and of course should be considered when designing the new infrastructure for the migration. Several clients have migrated from the MPX to an SDX and saved on operational support costs by reducing the number of Citrix ADC appliances in their network.

• Citrix ADC VPX (On-Prem) :

• • One of the obvious reasons for choosing the VPX is cost and the fact that VPX(s) can run on current virtualization environments. Ensure that there are sufficient resources allocated and that you have the licensing to handle all requirements
  • When migrating from a Citrix ADC hardware appliance to the VPX, we must ensure that the throughput, including SSL transactions, is available on the purchased VPX licensing. Also, since the Citrix ADC VPX is reliant on the hypervisor, it too must be able to meet throughput requirements for the targeted use cases.

• Citrix ADC VPX (Cloud):

• • There is no question that the development of the Citrix ADC in the cloud has progressed leaps and bounds in a short amount of time. In migration projects, please monitor the cloud providers documentation because it changes frequently.
  • Of course, as part of the migration project, on any platform, licensing has to be considered and, in the cloud, there are numerous licensing strategies, including bringing your own license or subscribing with the cloud provider.
  • Load balancing of active/active standalone ADCs is accomplished by the relevant cloud provider’s load balancing entity (i.e. ALB in Azure), which may be very different from the equivalent set up on-premises (see this earlier post in our Lessons from the Field series for more information on scaling out on-premises)

This post has given you a brief overview of lessons learned on migrations for the Citrix ADC appliances. I hope this helps you with future Citrix ADC migrations and that it also scratches the surface on the multitude of other things that have to happen for a Citrix ADC appliance to go live! And make sure you check out the other Lessons from the Field posts from my Citrix Consulting colleagues:

• Lessons from the Field: Remote PC Access
• Lessons from the Field: Citrix on Azure network design
• Lessons from the Field: Scaling Citrix Gateway for business continuity