Forum Discussion

Peter_Z's avatar
Peter_Z
Icon for Cirrus rankCirrus
Dec 11, 2017

Persist across two different Virtual Servers - One HTTP-based the other not

Hello,

 

We need to build a persistence to the same backend server across two different virtual servers, each processing different type of traffic.

 

The scenario is as follows:

 

  • known small number of clients (actually servers) connecting through frontend proxy/load balancer (Netscaler, not managed by us) with the same NAT IP address.
  • frontend load balancer connects to two different virtual servers on the BIG-IP (same VIP address, different ports: 8043 & 8843). both enabled with SSL termination
  • each virtual server load balances to the same nodes, but different ports: pool1: x.x.x.x:80, pool2: x.x.x.x:808
  • one Virtual server receives HTTPS traffic with X-Forwarded-For (or custom header) carrying Client IP info
  • 2nd Virtual server receives net.tcp traffic with client IP header encoded in hexa format in the TCP header of the fourth TCP packet (first packet after TCP handshake): https://support.citrix.com/article/CTX205670
  • the client first starts the connection to one VS (supposedly HTTPS), then starts the connection to the other VS and needs to end up on the same backend server (but different pool member port).

Is there a way to build a persistence via iRule? Client IP info from net.tcp communication can be hardcoded in irule variables: map each hexa value to corresponding IP address in decimal format.

 

Thanks.

 

1 Reply

  • Yes, it is possible to create persistence records from an iRule, either on it's own or associated with a Universal Persistence profile. I'd recommend associating the rule(s) with the profile, since that will allow you to use the 'Match Across Services' setting, allowing persistence to span multiple services, which is your situation.

     

    You need to handle two different types of traffic, where some has an X-Forwarded-For header and some does not. Here's a link to an iRule that persists based on X-Forwarded-For.

     

    For the traffic without the X-Forwarded-For, you'll need a rule that looks at client data, pulls out the significant information by length and offset, and then either decodes the client IP or determines it by looking it up in a datagroup (which is not a bad idea, provided the IP addresses used by your clients don't often change) and persists on the extracted/returned IP address.