Jump to content
Welcome to our new Citrix community!

vserver pointing to another vserver


William Olmstead

Recommended Posts

I have a question. 

 

We are migrating off of F5 LB, and two of the LB vips that is moving happens to fall on the same Citrix ADC.  So I have a vserver pointing to the IP of another Vserver.  This is usually not the case but the way the networks is setup in this test env, it just happened that the two networks fell on the same ADC.  Can you point a vserver to the IP of another vserver on the same ADC ?

 

TIA

Link to comment
Share on other sites

So, you can't create a service that points to an existing service (IP:Port protocol) on this appliance and a service can't overlap with an existing vserver on this appliance.

If you wanted a LB server to point to another lb vserver, then daisy chaining between two different appliances might work.

 

A CS vserver on one VIP can then be used to sort between different LB vserver destinations; these lb vservers can then go to their respective services (backend destinations).

And you can make the lb vserver tier non-addressable (no vips).  So THIS IS WORKING and should meet your needs as long as the destinations behind lb vserver is to a service that is not a VIP on this appliance.

 

But to have traffic arrive at lb vserver 1 and then pass to new "IP2" which is actually lb vsrver 2 on this adc is problematic. 

To have multiple lb vservers behind a cs veserver and those lb vservers to send to their own destinations is exactly what cs is for.

 

I think you find a fix; just your underlying scenario didn't have enough context.

 

 

Link to comment
Share on other sites

2 hours ago, Rhonda Rowland1709152125 said:

So, you can't create a service that points to an existing service (IP:Port protocol) on this appliance and a service can't overlap with an existing vserver on this appliance.

If you wanted a LB server to point to another lb vserver, then daisy chaining between two different appliances might work.

 

A CS vserver on one VIP can then be used to sort between different LB vserver destinations; these lb vservers can then go to their respective services (backend destinations).

And you can make the lb vserver tier non-addressable (no vips).  So THIS IS WORKING and should meet your needs as long as the destinations behind lb vserver is to a service that is not a VIP on this appliance.

 

But to have traffic arrive at lb vserver 1 and then pass to new "IP2" which is actually lb vsrver 2 on this adc is problematic. 

To have multiple lb vservers behind a cs veserver and those lb vservers to send to their own destinations is exactly what cs is for.

 

I think you find a fix; just your underlying scenario didn't have enough context.

 

 

Sorry about the short context.  I was in the middle of the move and and ran into the problem when I tried to add the vserver, where it was telling me that I was getting an IP conflict.  I thought that I was getting the IP conflict because we were moving the IP from an F5 device to the Citrix ADC, but in fact I was getting the IP conflict because I had a vserver already configured on my ADC that had the IP that I was moving as a node.

 

This is where my problem came in. 

 

The path was like this "User -> LB vserver IP -> node (which was the LBvserver2 IP from the F5 that I moved) -> 2 server nodes.  So then my delmia was how to essentially daisy chain those together.  I know it is not ideal the way it was setup, it was how it was handed to me.  I ended up setting up a CS Vserver, so now it flows like " User -> CSvserver1 IP -> LBvserver IP -> server nodes".   I assigned the LBvserver as the "default LB Vserver" in the CSvserver settings.

 

Not sure this is the ideal way of doing things, but it seems to work.

Link to comment
Share on other sites

William Olmstead, it will work like that, but it does not make sense to me. Let me explain, what I see:

 

F5/1: vServer 10.0.0.1, selfIP 10.1.0.1

F5/2 vServer: 10.0.2.1, selfIP: 10.2.0.1

 

So traffic flow will be client -> 10.0.0.1, backend traffic going to vServer 2: 10.1.0.1 -> 10.0.2.1, backend traffic from there: 10.2.0.1 -> real server.

 

Your deployment:

cs-vServer: 10.0.0.1

lb-vServer: non addrssable or maybe 10.0.2.1, the IP won't be used in this scenario.

SNIP: 10.2.0.1

 

So traffic flow will be (from perspective of TCP/IP) client -> 10.0.0.1, backend traffic going from 10.2.0.1 -> real server. Why putting a CS-vServer in front? It's just extra complexity. The cs-vServer has to pass traffic to the lb-vServer internally, the policy will be a true (=always).

 

You get the same result, if you create a lb-vServer with IP 10.0.0.1, but with less complexity.

 

Cheers

 

Johannes Norz

CTA, CCE-AppDS, CCI

https://norz.at

https://wonderkitchen.network

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...