Integration of Third-Party Routing Stack to NetScaler CPX

The Citrix NetScaler CPX, is one of the many Application Delivery Controllers (ADCs), which is used mainly for load balancing between the application servers in a datacenter network. ADCs are typically placed in the demilitarized zone in an organization’s network, handling the connectivity of the external clients to the organization’s servers. While performing load balancing between the servers, there is need for better routing between application servers. Route Health Injection (RHI) delegates the control of routing protocol announcement to a server based on the health of a service and the connectivity of the server to the network. This paper discusses on how the current version of NetScaler CPX is integrated with a third-party routing stack, Quagga, to enable the connectivity of the clients to the servers, with the additional feature of Route Health Injection (RHI) for better routing.


Introduction
Application delivery controllers (ADC) [1], which are widely deployed as a key fixture in the enterprise, help applications adapt to the networks and protocols that are in place today. ADCs can help ensure high availability of applications by providing seamless failover. This is done by balancing application workloads across a cluster of active servers in one or multiple sites.
One side of the ADC is the server farm capable of providing services and the other side is the Internet with clients and routers. A group of servers providing the similar service can be pooled and assigned a single Virtual Internet Protocol (VIP) address. This enables load balancing the incoming request among one of the servers in the pool.
NetScaler is available as a physical appliance or as software appliance. It supports a varied functionality including load balancing, SSL offloading, HTTP compression, content filtering, etc. NetScaler CPX [2] brings the power of advanced L4-7 application delivery services to containerized microservices infrastructures [3].
Route Health Injection (RHI) [4] allows a router to publish a host route to a globally distributed website. Normally, an IP address must exist on a single host in the Internet. However, with global server load balancing, the same IP address can exist on multiple machines using the Virtual IPs. Thus, a VIP is an IP address that will associate to real servers attached to the load balancer.
In a normal configuration, a router may have multiple paths to the VIP corresponding to a server site. But the router chooses the path with minimum cost. The router's behavior works well when all the servers are available. In case of a failure of the service at a particular site, the VIP must no longer be visible to the rest of the network.
However, if the gateway routers advertise the network routes rather than host routes, then even if the VIP is down, the router still advertises the network to which the VIP belongs, thus leading a path to an unavailable server.
To avoid this problem, only the host route of the servers can be advertised instead of the network route. As a result, paths to the website those are no longer available ages out of the routing tables and only the paths to the available sites exists. Figure 1 shows an example topology wherein there are two sites serving the same website. When the site at location 1 fails, then the request is routed to the VIP of servers at location 2.
An ADC must be able to take smart real time decisions based on the status/availability of the backend servers. It must effectively ASTESJ ISSN: 2415-6698 * Shreyas K. K., Bangalore, Contact: 6360441200, shreyaskk97@gmail.com Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 6, 192-195 (2019) www.astesj.com divert traffic from any non-responsive backend server and continue to send that traffic to an alternate load balanced server that is available. The decision of advertising and removing a VIP to/from the downstream routers is made based on the availability of a VIP. To demonstrate the routing in our environment, we use a routing software package Quagga [5] that provides the features of TCP/IP based routing services. It supports routing protocols such as RIP, OSPF, BGP, IS-IS, etc. In addition to the IPv4 support, Quagga also provides support to the IPv6 routing protocols. Quagga is distributed under the GNU General Public License.

Existing System
Hogge, Jr. et al. [6] described the use of route health injection using the OSPF protocol. It explains the use of RHI in mobile SMS and MMS technology. SMS and MMS require the Short Message Service Center (SMSC). It explains the advantages of using redundant message servers. The primary message service center and the secondary message service center are typically distributed globally. When the primary service center faces a catastrophic failure, the secondary or the redundant service center is used to serve the SMS and MMS requests.
Naseh et al. [7] describes the technique of having active/standby data center to achieve high availability of applications. In normal conditions, the primary data center is functional and the secondary data center monitors the state of the primary data center. When the primary data center fails, the secondary data center injects the IP address to the Internet and makes the service. Now, any requests from the clients that arise are directed to the secondary data center. This illustration is an example of RHI used for availability in case of a disaster.
Clients request the VIP for a service. The request is then forwarded to one of the physical server based on a load balancing algorithm [8] that runs on the ADC (for example, the ADC might use Round Robin method of allocating user requests in a circular fashion). It is required to make an end to end connection from the client to the servers through the VIP. Thus, a routing stack has to be integrated in the NetScaler CPX, which makes this connection possible. Along with the integration of a routing stack, it will obviously be an added benefit to implement the Route Health Injection (RHI) functionality, wherein, only the active VIPs are advertised to the downstream routers and the inactive ones are removed, hence increasing the overall response time.
The objective is to develop a web application which does the following: monitor the health of NetScaler CPX VIPs, and inject the route using open-source routing engine.

Proposed Methodology
To achieve the main objective of establishing an end to end connectivity of the clients to the VIP, the NetScaler CPX is integrated with a routing system as shown in Figure 2. The system is composed of the NetScaler CPX container, a routing engine called Quagga, and a web application. The web application is developed to communicate to NetScaler CPX on one side and the routing engine on the other. The VIP statuses are retrieved from the NetScaler through the VIP extraction module and are parsed to determine its state. The main function of active VIPs injection and inactive VIPs removal is handled next.  The VIP details are to be retrieved from NetScaler CPX. A request from the web application is sent to NetScaler CPX asking for the VIP details. NetScaler CPX bundles the VIP details in an JSON object and delivers to the web application. The JSON object containing the VIP details are parsed to determine the VIP status. All the inactive VIPs are removes from the local routing table. All the recently active VIPs are advertised to the local routing table.
The BGP further handles the task of updating the routing tables of all neighboring routers and hence, assuring that only the active VIPs are visible throughout the network. The flow of the system is shown in Figure 3.

Experimental Analysis and Discussion of Results
The project is based on a system to make connectivity from the clients to the services. Hence, there is no specific evaluation metrics used. The only possible evaluation criteria used to verify the system is the connectivity of the client to the VIP. The system is checked with the existence of connectivity from the clients to the VIPs. It is also verified that only the active VIPs are visible and the inactive ones are not.  The Quagga routing engine 1 is local to the NetScaler CPX and Quagga routing engine 2 is used to verify the route publishing.
The following two cases illustrate the routing table contents of Quagga Routing Engine 2 which demonstrates the route advertising and removal.
If VIP is UP -VIP 172.17.4.100 is UP and it is published to all neighboring routers' routing table. Any request to the VIP will be reachable. The web application is shown in Figure 5 and the routing table in Figure 6.

Conclusion
The system is implemented to achieve the main objective of establishing an end to end connectivity of the clients to the VIP along with reducing the response time with RHI. The system, hence, integrated the third party routing stack to the NetScaler CPX. The NetScaler CPX is configured and the routing engine set up with the web application. The active VIPs are advertised while the inactive VIPs are removed from the routing tables. However, the system is compatible only with NetScaler CPX deployed environment and in the Citrix enterprise network. It also is designed specifically to the Quagga routing engine. Thus, any necessity to work with different routing engines requires modification. The system also has limited configuration capability.

Future work
The future enhancements considered to the project tries to overcome the limitations. They are described as follows: • Development of a Wrapper API to work with any kind of Routing Engine.
• Development of the system capable for many other configuration capabilities through the web interface.

Conflict of Interest
The authors declare no conflict of interest.