F5 to NetScaler Migration: A Comprehensive Guide

As organizations grow and their IT infrastructure evolves, migrating your F5 BigIP to NetScaler can become a key consideration with all the flexibility and performance the NetScaler brings. If you are new to NetScaler, or responsible to perform a migration from F5 devices, this article offers a technical overview of migrating from F5 to NetScaler, detailing common scenarios, architectures, and the differences between both platforms. Whether you’re a network engineer or system architect, this guide provides essential insights into making a smooth transition.

1. Understanding the Migration Process

Before jumping into the migration, it’s crucial to understand the current F5 BigIP deployment. Here are the key factors to assess:

• Traffic Architecture: Source NAT Translation (SNAT) or No SNAT? Is the F5 appliance acting as the backend server’s default gateway? Do you need DSR (Direct Server Return) or Auto Last Hop (Mac-Based Forwarding)?
• Configuration Conversion: Check how many VIPs (Virtual IPs) and iRules will be converted by using the NetScaler automated tools. Gauge the complexity, especially if advanced features like WAF, APM, or GTM are being used.
  • NetScaler offers an F5 configuration conversion tool which you can use to help you during the transition.
• Utilization Data: Check for current bandwidth, HTTP, and SSL data to properly size your NetScaler Virtual Machines and/or Hardware Appliances.

2. Common Deployment Scenarios to be replaced by NetScaler Seamlessly

F5 LTM Routed Architecture 

This is the most common type of deployment. It is called routed because only the load-balancing VIP traffic is routed to the BigIP.  The local L3 device (Router or L3 Switch), is the gateway to the backend servers infrastructure, not the Load Balancer.

The SNAT (Source NAT) enables the return traffic to be routed back to the Load Balancer (The source address is replaced by the F5 Self IP).
The route table and the Auto Last Hop feature (Equivalent to NetScaler MAC-based forwarding) are usually enabled.

Here’s a diagram of this deployment.

NetScaler Routed Deployment Approach:

• Migration Method: A phased or parallel migration approach is recommended (Check next sections for more details about these two approaches)
• 1-arm or 2-arm Setups: NetScaler is very flexible here; you can choose how many Physical interfaces or VLANs as needed to “mirror” the BigIP connections. This article shows the most common NetScaler topologies that can be used here.
• Replacing physical appliances by virtual appliances: Also require resizing the workloads.

BigIP F5 Inline Architecture

Inline architecture places the BigIP as the default gateway for backend servers. The load balancer is also responsible to handle non-load-balancing traffic, once this is the default Gateway. SNAT is disabled because the return traffic is always routed to the load balancers, preserving the client IP information in the IP packet.

It’s common in legacy network environments. The next picture depicts this scenario.

NetScaler Inline Deployments Approach:

Inline deployments are no longer recommended, but if you really need the inline mode, it is also possible to do it with the NetScaler. Whenever possible, move to a routed architecture. 

The  NetScaler USNIP (SNAT) mode is enabled by default and provides a more efficient traffic management solution. Disabling it (by enabling the USIP mode), create a limit of 64,000 simultaneous server connections per SNIP for the backend services, so if you have many concurrent connections, you might need to add multiple SNIPs in that VLAN to add more port connections. Please check this link for more details.

 If you didn’t use SNAT before and is enabling it for NetScaler, remember to include the X-Forwarded-For header which adds a client IP header for HTTP traffic. Check this link for more details.

• Regarding SNAT, the F5 can operate in different modes, and here are the equivalent NetScaler features:
  • SNAT Automatic mapping:
    • F5 AutoMap: The F5 device automatically selects one of its own self IPs to perform SNAT.
    • NetScaler USNIP Mode: This is the default method enabled by default. No Configuration required. NetScaler will choose the SNIP assigned to the egress VLAN, if multiple SNIPs are bound, the SNAT connections will be distributed among all the SNIPs.
  • Specify pool of IPs for SNAT:
    • SNAT Pool: A specific pool of IP addresses is defined and used for SNAT.
    • NetScaler IPSET with NetProfile: In the NetScaler you just need to create an IPSET list with the IP addresses, bind it to a Net Profile and then bind to the VIP, or just add multiple SNIPs in the same Egress VLAN. This link shows how to configure it.

3. Migration Approaches

Two major migration strategies are usually used:

Approach 1: Lift and Shift

This strategy involves minimal reconfiguration and is ideal for smaller environments. It’s the quickest approach, reusing the same IPs, but has a higher rollback risk since the entire system moves at once.

• Advantages: Fast migration, minimal reconfiguration.
• Disadvantages: Higher risk, more challenging to rollback.

Approach 2: Phased Migration

In this approach, applications are gradually migrated in waves, reducing downtime and risks. F5 and NetScaler coexist during the migration, allowing for testing in stages.

• Advantages: Lower risk, gradual testing, minimal downtime.
• Disadvantages: Extended timeline, coexistence complexity.

The following table presents the Key differences and can help you to decide which method makes more sense.

4. Migration Methods for VIPs

You can migrate VIPs (Virtual IPs) either by IP-based, or DNS-based methods or if they are natted in the firewall, NAT based.

VIP Migration – IP Based

This method uses the same IPs for both F5 and NetScaler. The diagram below depicts the method.

• Key Points:
  • This method keeps the  same VIP addresses, that are moved from one appliance to another. 
  • This migration is less Complex because doesn’t require DNS change.
  • The Rollback is quick and easy, just disables the IP in one side and enable in the other.
• Technical Requirements
  • SNIPs must be different, once both Load Balancers are implemented actively in parallel. So, make sure you open all the necessary firewall rules for new IPs.
  • ARP and Ping Must be Disabled in the NetScaler (System> Network > IPs) before the change, and enabled during the migration and after disabling it in the F5.
• Potential Risks
  • If you misconfigure the IP (forget to disable ARP/PING), it will cause IP duplication issue in the Network and can cause service unavailability.

VIP Migration – DNS Based

This approach assigns different IPs to each appliance, with DNS entries dictating to which VIP the traffic goes. The DNS-based method allows full testing before migration but may have a longer rollback process due to DNS propagation delays.

• Key Points:
  • This method uses different VIP addresses, the DNS A entry for each VIP must be changed to the new VIP IP.
  • This migration isn’t too complex, but changing DNS entries massively could cause impact.
  • The Rollback is easy but may not be quick, once DNS entry must be propagated to all client hosts.
• Technical Requirements
  • SNIPs must be different, once both Load Balancers are implemented actively in parallel. So, make sure you open all the necessary firewall rules for new IPs.
  • Both Appliances Active in parallel with ARP/Ping Enabled..
• Risks
  • Time to rollback could take from minutes to hours.

VIP Migration – NAT Based

This approach works only for environments where the VIPs are Natted in the Firewall. It’s similar to the DNS method, you will use different IPs, but instead changing the DNS entry, you will change the NAT rule in the Firewall. 

6. GTM to GSLB Migration

NetScaler GSLB replaces the F5 GTM feature perfectly. The GSLB is already included in the NetScaler licensing, so no additional licensing is required. If you are not familiar with the GSLB terminology, please check this article first.

Follow the steps below for a smooth GTM to GSLB migration.

• GTM to GSLB Migration Approach – Moving from F5 GTM to NetScaler GSLB is very straight forward, just use the GTM Config file in the NetScaler conversion tool to get the NetScaler configuration translated automatically.
• If you are not using Subdomain delegation, you just need to change each individual delegation to the NetScaler ADNS IP.
• If you are using subdomain delegation, the DNS subdomain migration will depend on your approach.
  • Lift-and-shift – If all the original IP addresses were preserved (Including the DNS IPs), no further change is required besides pre-configure the GSLB and test it after the maintenance window, this approach change all your URLs at the same time.  
  • Phased Migration – When using this method, you can just delegate a new subdomain to a new set of ADNS IPs in the NetScaler. In moment you move an App to NetScaler, you just need to change the CNAME entry in your DNS Server to the NetScaler subdomain.
    • Example:
      • F5 subdomain called gtm, URL: app.gtm.company.com
      • NetScaler subdomain called gslb, URL: app.gslb.company.com
    • During the change window, you just need to change the CNAME entry pointing to the NetScaler GSLB subdomain entry, all DNS requests will automatically send to NetScaler GSLB ADNS IP. Making it an extremely easy and straightforward change.

7. Conclusion

With proper planning and understanding of both platforms, transition from F5 to NetScaler can be smooth and quick. Whether using a lift-and-shift or phased approach, ensure that traffic flow, IP addresses, and  relevant configurations are correctly mapped. Keep in mind the terminology and feature differences between F5 and NetScaler to avoid service interruptions during migration, this article describes the main differences between both platforms.

By following the steps outlined in this guide, you can minimize risks and ensure a successful migration to NetScaler.